В 64-битных версиях Windows 32-битное программное обеспечение установлено в "c:\program files (x86)". Это означает, что вы не можете использовать $(программные файлы), чтобы получить путь к (32-разрядному) программному обеспечению. Поэтому мне нужно $(ProgramFiles32), чтобы преодолеть это в моем проекте MSBuild. Я не хочу менять проект в зависимости от того, на котором он работает.
У меня есть решение, которое я опубликую, но, возможно, есть более простой/лучший способ.
В MSBuild 4.0+ для этого есть a $(MSBuildProgramFiles32) свойство, которое вы можете уверенно использовать напрямую (особенно если вы готовы поместите a ToolsVersion="4.0" в начало файла, чтобы гарантировать его доступность, и Fail Fast, если это не так.)
Если вам не нужно и нужно что-то, что можно сделать правильно, даже если оно выполняется в среде 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>
К сожалению Прогрессивное усовершенствование/polyfill переопределение зарезервированное свойство MSBuild имя MSBuildProgramFiles32 через либо <PropertyGroup>, либо <CreateProperty> отклоняется MSBuild 4.0+, поэтому его нельзя сделать tidier и по-прежнему поддерживают .NET 2.0.
Мое решение состоит в том, чтобы посмотреть, существует ли "c:\program files (x86)", если он существует, это 64-разрядный os. В противном случае используйте каталог нормальных файлов программ:
<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' />
В MSBuild 4.0, $(MSBuildProgramFiles32) предоставит вам 32-разрядный каталог программных файлов.
Попробуйте "$(MSBuildExtensionsPath32)\.."
Я думаю, что более надежным способом является захват переменной Environment "ProgramFiles (x86)". В 64-битном процессе в Windows это укажет на 32-битный каталог программных файлов. Он будет пустым в 32-битной версии окон и я полагать на процесс wow64
Недавно я столкнулся с практически той же проблемой с некоторыми сценариями PowerShell. Я написал запись в блоге о том, как работает проблема с каталогом файлов программ. Разумеется, различный язык, но это может помочь вам.
http://blogs.msdn.com/jaredpar/archive/2008/10/21/program-files-i-just-want-the-32-bit-version.aspx
Я наткнулся на этот вопрос, пытаясь найти общий способ в MSbuild, чтобы узнать, является ли это 32- или 64-разрядным os. Если кто-то еще это обнаружит, я использовал следующее:
<PropertyGroup>
<OSBits Condition="$(ProgramW6432) != ''">x64</OSBits>
<OSBits Condition="$(OSBits) == ''">x32</OSBits>
</PropertyGroup>
По-видимому, %ProgramW6432% устанавливается только в 64-битных системах.
Если вы запустите 32-разрядную версию инструментов Visual Studio (особенно в VS2012, есть 3 разных командной строки, которые вы можете выбрать), $(ProgramFiles) указывает на "Program Files (x86)"