使用 32 位“程序文件” msbuild 中的目录
在 64 位版本的 Windows 中，32 位软件安装在“c:\program files (x86)”中。 这意味着您无法使用 $(programfiles) 获取（32 位）软件的路径。 所以我需要一个 $(ProgramFiles32) 来克服我的 MSBuild 项目中的这个问题。 我不想根据项目运行的操作系统来更改项目。
我有一个将发布的解决方案，但也许有一个更简单/更好的方法。
In 64 bit versions of windows, 32 bit software is installed in "c:\program files (x86)". This means you cannot use $(programfiles) to get the path to (32 bit) software. So I need a $(ProgramFiles32) to overcome this in my MSBuild project. I don't want to change the project depending on the os it is running on.
I have a solution that I will post, but maybe there is a easier/better way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在 MSBuild 4.0+ 中，有 一个
$(MSBuildProgramFiles32)属性 ，您可以放心地直接使用它（特别是如果您准备将ToolsVersion="4.0"放在文件顶部以保证它可用并且< a href="http://en.wikipedia.org/wiki/Fail-fast" rel="noreferrer">快速失败（如果不是）。如果您不是并且需要即使在 MSBuild 2.0 或更高版本环境中执行（即回到 VS 2005 环境）也能做正确的事情，完整的解决方案是：
不幸的是 渐进增强 / polyfill 覆盖MSBuild 保留属性 通过
MSBuildProgramFiles32被 MSBuild 4.0+ 拒绝，因此无法创建更整洁并且仍然支持.NET 2.0。In MSBuild 4.0+, there's a
$(MSBuildProgramFiles32)property for it, which you can confidently employ directly (especially if you're prepared to put aToolsVersion="4.0"at the top of the file to guarantee it's going to be available and Fail Fast if it's not).If you're not and need something that can Do The Right Thing even when executed in an MSBuild 2.0 or later environment (i.e., back to VS 2005 environments), the complete solution is:
Unfortunately Progressive enhancement / polyfill overriding of the MSBuild reserved property name
MSBuildProgramFiles32via either a<PropertyGroup>or<CreateProperty>is rejected by MSBuild 4.0+ so it can't be made tidier and still support .NET 2.0.我的解决方案是查看“c:\program files (x86)”是否存在，如果存在，假设这是一个64位操作系统。 否则使用普通的程序文件目录：
我可以这样使用它
My solution is to look whether "c:\program files (x86)" exists, if it exists, asume this is a 64 bit os. Otherwise use the normal program files directory:
I can use it like this
在 MSBuild 4.0 中，
$(MSBuildProgramFiles32)将为您提供 32 位 Program Files 目录。In MSBuild 4.0,
$(MSBuildProgramFiles32)will give you the 32-bit Program Files directory.尝试
“$(MSBuildExtensionsPath32)\..”Try
"$(MSBuildExtensionsPath32)\.."我认为稍微更可靠的方法是获取环境变量“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
I think a slighly more reliable way is to grab the Environment variable "ProgramFiles(x86)". In a 64 bit process on Windows this will point to the 32 bit program files directory. It will be empty on a 32 bit version of windows and I believe on a wow64 process
I ran into virtually same problem recently with some PowerShell scripts. I wrote a blog entry on how a worked around the program files directory issue. Different language obviously but it may help you out.
http://blogs.msdn.com/jaredpar/archive/2008/10/21/program-files-i-just-want-the-32-bit-version.aspx
我偶然发现了这个问题，试图在 MSbuild 中找到一种通用方法来查看它是 32 位还是 64 位操作系统。 如果其他人也发现了这一点，我使用了以下内容：
显然
%ProgramW6432%仅在 64 位系统上设置。I stumbled across this question trying to find a generic way in MSbuild to see if it was a 32- or 64-bit os. In case someone else also find this, I used the following:
Apparently
%ProgramW6432%is only set on 64-bit systems.如果您运行 32 位版本的 Visual Studio 工具（尤其是在 VS2012 中，有 3 种不同的命令提示符可供选择），$(ProgramFiles) 指向“Program Files (x86)”
If you run the 32-bit version of the Visual Studio tools (especially in VS2012, there are like 3 different command prompts you can choose from), $(ProgramFiles) points to "Program Files (x86)"