[ACCEPTED]-Use 32bit "Program Files" directory in msbuild-program-files

In MSBuild 4.0+, there's a $(MSBuildProgramFiles32) property for it, which 12 you can confidently employ directly (especially 11 if you're prepared to put a ToolsVersion="4.0" at the top 10 of the file to guarantee it's going to be 9 available and Fail Fast if it's not).

If you're not 8 and need something that can Do The Right 7 Thing even when executed in an MSBuild 2.0 6 or later environment (i.e., back to VS 2005 5 environments), the complete solution is:

<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>

Unfortunately 4 Progressive enhancement / polyfill overriding of the MSBuild reserved property name MSBuildProgramFiles32 via either 3 a <PropertyGroup> or <CreateProperty> is rejected by MSBuild 4.0+ so it 2 can't be made tidier and still support .NET 1 2.0.

My solution is to look whether "c:\program 4 files (x86)" exists, if it exists, asume 3 this is a 64 bit os. Otherwise use the normal 2 program files directory:

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

I can use it like 1 this

<Exec WorkingDirectory="src\app1" Command='"$(ProgramFiles32)\doxygen\bin\doxygen" Doxyfile' />

In MSBuild 4.0, $(MSBuildProgramFiles32) will give you the 32-bit 1 Program Files directory.

Try "$(MSBuildExtensionsPath32)\.."

0

I think a slighly more reliable way is to 10 grab the Environment variable "ProgramFiles(x86)". In 9 a 64 bit process on Windows this will point 8 to the 32 bit program files directory. It 7 will be empty on a 32 bit version of windows 6 and I believe on a wow64 process

I ran into virtually 5 same problem recently with some PowerShell 4 scripts. I wrote a blog entry on how a 3 worked around the program files directory 2 issue. Different language obviously but 1 it may help you out.

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

I stumbled across this question trying to 4 find a generic way in MSbuild to see if 3 it was a 32- or 64-bit os. In case someone 2 else also find this, I used the following:

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

Apparently 1 %ProgramW6432% is only set on 64-bit systems.

If you run the 32-bit version of the Visual 4 Studio tools (especially in VS2012, there 3 are like 3 different command prompts you 2 can choose from), $(ProgramFiles) points 1 to "Program Files (x86)"