42

在 64 位版本的 windows 中，32 位软件安装在“c:\program files (x86)”中。这意味着您不能使用 $(programfiles) 来获取（32 位）软件的路径。所以我需要一个 $(ProgramFiles32) 在我的 MSBuild 项目中克服这个问题。我不想根据正在运行的操作系统更改项目。

我有一个我会发布的解决方案，但也许有一个更简单/更好的方法。

4

7 回答 7

48

在 MSBuild 4.0+ 中，它有一个$(MSBuildProgramFiles32)属性，您可以放心地直接使用它（特别是如果您准备将 aToolsVersion="4.0"放在文件顶部以保证它可用，如果不可用，则快速失败）。

如果您不需要并且需要即使在 MSBuild 2.0 或更高版本的环境中执行（即回到 VS 2005 环境）也能做正确的事情，完整的解决方案是：

<PropertyGroup>
    <!--MSBuild 4.0 property-->
    <ProgramFiles32>$(MSBuildProgramFiles32)</ProgramFiles32> 
    <!--Use OS env var as a fallback:- 32 bit MSBuild 2.0/3.5 on x64 will use this-->
    <ProgramFiles32 Condition=" '' == '$(ProgramFiles32)'">$(ProgramFiles%28x86%29)</ProgramFiles32>

    <!-- Handle MSBuild 2.0/3.5 running in 64 bit mode - neither of the above env vars are available. http://stackoverflow.com/questions/336633
       NB this trick (Adding a literal " (x86)" to the 64 bit Program Files path) may or may not work on all versions/locales of Windows -->
    <ProgramFiles32 Condition ="'$(ProgramFiles32)'=='' AND 'AMD64' == '$(PROCESSOR_ARCHITECTURE)'">$(ProgramFiles) (x86)</ProgramFiles32>

    <!--Catch-all - handles .NET 2.0/3.5 non-AMD64 and .NET 2.0 on x86 -->
    <ProgramFiles32 Condition=" '' == '$(ProgramFiles32)' ">$(ProgramFiles)</ProgramFiles32>
</PropertyGroup>

不幸的是， MSBuild 保留属性名称的渐进增强/ polyfill覆盖通过 a或被MSBuild 4.0+ 拒绝，因此它不能变得更整洁并且仍然支持 .NET 2.0。MSBuildProgramFiles32<PropertyGroup><CreateProperty>

于 2011-04-13T14:20:11.830 回答
16

我的解决方案是查看“c:\program files (x86)”是否存在，如果存在，假设这是一个 64 位操作系统。否则使用正常的程序文件目录：

<PropertyGroup>
  <ProgramFiles32 Condition="Exists('$(PROGRAMFILES) (x86)')">$(PROGRAMFILES) (x86)</ProgramFiles32>
  <ProgramFiles32 Condition="$(ProgramFiles32) == ''">$(PROGRAMFILES)</ProgramFiles32>
</PropertyGroup>

我可以这样使用

<Exec WorkingDirectory="src\app1" Command='"$(ProgramFiles32)\doxygen\bin\doxygen" Doxyfile' />
于 2008-12-06T10:38:30.150 回答
12

在 MSBuild 4.0 中，$(MSBuildProgramFiles32)将为您提供 32 位的 Program Files 目录。

于 2010-12-07T19:50:51.120 回答
10

尝试"$(MSBuildExtensionsPath32)\.."

于 2009-06-27T06:37:36.357 回答
4

我认为更可靠的方法是获取环境变量“ProgramFiles(x86)”。在 Windows 上的 64 位进程中，这将指向 32 位程序文件目录。在 32 位版本的 Windows 上它将是空的，我相信在 wow64 进程上

我最近在使用一些 PowerShell 脚本时遇到了几乎相同的问题。我写了一篇关于如何解决程序文件目录问题的博客文章。显然不同的语言，但它可能会帮助你。

http://blogs.msdn.com/jaredpar/archive/2008/10/21/program-files-i-just-want-the-32-bit-version.aspx

于 2008-12-06T10:52:20.030 回答
1

我偶然发现了这个问题，试图在 MSbuild 中找到一种通用方法来查看它是 32 位还是 64 位操作系统。如果其他人也发现了这个，我使用了以下内容：

<PropertyGroup>
  <OSBits Condition="$(ProgramW6432) != ''">x64</OSBits>
  <OSBits Condition="$(OSBits) == ''">x32</OSBits>
</PropertyGroup>

显然%ProgramW6432%只在 64 位系统上设置。

于 2010-03-25T21:08:48.960 回答
1

如果您运行 32 位版本的 Visual Studio 工具（尤其是在 VS2012 中，您可以选择 3 种不同的命令提示符），$(ProgramFiles) 指向“Program Files (x86)”

于 2013-07-15T16:46:16.053 回答