64ビットバージョンのWindowsでは、32ビットソフトウェアが「c:\ programfiles(x86)」にインストールされます。これは、$(programfiles)を使用して(32ビット)ソフトウェアへのパスを取得できないことを意味します。したがって、MSBuildプロジェクトでこれを克服するには、$(ProgramFiles32)が必要です。実行中のOSに応じてプロジェクトを変更したくありません。
投稿する解決策がありますが、もっと簡単で良い方法があるかもしれません。
MSBuild 4.0+には、 $(MSBuildProgramFiles32)
property があり、自信を持って直接使用できます(特に、ファイルの先頭に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>
残念ながら プログレッシブエンハンスメント / polyfillMSBuild予約済みプロパティ 名前MSBuildProgramFiles32
の<PropertyGroup>
または<CreateProperty>
によるオーバーライドはMSBuild 4.0+によって拒否されるため、 'より整理され、.NET2.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ビットのProgramFilesディレクトリを提供します。
"$(MSBuildExtensionsPath32)\.."
を試してください
もう少し信頼できる方法は、環境変数「ProgramFiles(x86)」を取得することだと思います。 Windowsの64ビットプロセスでは、これは32ビットのプログラムファイルディレクトリを指します。 32ビットバージョンのWindowsでは空になり、wow64プロセスではIbelieve
最近、いくつかのPowerShellスクリプトで実質的に同じ問題が発生しました。プログラムファイルディレクトリの問題を回避する方法についてのブログエントリを作成しました。明らかに異なる言語ですが、それはあなたを助けるかもしれません。
http://blogs.msdn.com/jaredpar/archive/2008/10/21/program-files-i-just-want-the-32-bit-version.aspx
32ビットバージョンのVisualStudioツールを実行する場合(特にVS2012では、3つの異なるコマンドプロンプトから選択できます)、$(ProgramFiles)は「ProgramFiles(x86)」を指します。
私は、MSbuildで一般的な方法を見つけて、それが32ビットまたは64ビットのOSであるかどうかを確認しようとして、この質問に出くわしました。他の誰かもこれを見つけた場合に備えて、私は以下を使用しました:
<PropertyGroup>
<OSBits Condition="$(ProgramW6432) != ''">x64</OSBits>
<OSBits Condition="$(OSBits) == ''">x32</OSBits>
</PropertyGroup>
どうやら%ProgramW6432%
は64ビットシステムでのみ設定されます。