This project is read-only.

MSBuildExtensionsPath on 64 bit machines

May 7, 2012 at 11:09 AM

I am under the impression that MsBuild always return the 32bit path in MSBuildExtensionsPath even when running on 64bit machines in a 64bit process?

Am I missing something? How do people get around this using MsBuildExtensions?

May 7, 2012 at 9:06 PM

Yip. What's the problem you are having?


May 7, 2012 at 9:41 PM

Just that. If I install just the 64bit version of MsBuildExtensionPack, it will always still look in the Program Files (x86) directory and not Program Files. I've had to install both the x86 and x64 versions just to get my builds to work on both a x86 and x64 build server...


May 8, 2012 at 6:23 PM

I apologize in advance for some similar newbie questions, but I couldn't find a clear direction in the online docs or discussion list.

On a 64-bit Server 2008 R2 SP1 machine with Visual Studio 2010 SP1, I installed only "MSBuild Extension Pack 4.0 (x64).msi". Is that the correct install or do I also (or only) need "MSBuild Extension Pack 4.0.msi"? I am using this with VS2010, MSBuild and TeamCity (but not TFS).

"MSBuild Extension Pack 4.0 (x64).msi" installs to the 64-bit C:\Program Files\MSBuild\ExtensionPack\4.0, as expected. However it appears that MSBuild is a 32-bit process (when launched from the VS2010 Command Prompt window), as the MSBuildExtensionsPath* variables have a 32-bit world view when displayed with <Message Text="MSBuildExtensionsPath : $(MSBuildExtensionsPath)"/>:
  MSBuildExtensionsPath : C:\Program Files (x86)\MSBuild
  MSBuildExtensionsPath32 : C:\Program Files (x86)\MSBuild
  MSBuildExtensionsPath64 : C:\Program Files\MSBuild

If that is true, what PropertyGroup and Import statements should we use to access the MSBuild Extension Pack tasks? It seems like we need to explicitely reference the 64-bit install path, however the tasks don't load corretly with these statements:

    <Import Project="$(TPath)"/>

The MSBuild Extension Pack code samples imply that the tasks should be copied to a local directory relative to the project (see below). Is this the recommended approach, and if so, what files need to be copied?

        <TPath Condition="Exists('$(MSBuildProjectDirectory)\..\..\Common\MSBuild.ExtensionPack.tasks')">$(MSBuildProjectDirectory)\..\..\Common\MSBuild.ExtensionPack.tasks</TPath>
    <Import Project="$(TPath)"/>

May 8, 2012 at 7:56 PM

Hey Dean, this is exactly my question as well. I have 2 build servers, one x86 and the other x64. How to make the same build script work on both?

May 8, 2012 at 9:04 PM

You can ignore all those TPath imports from the samples. This was just done to get the samples working form both the install directory and from within VS to use the development code.

On your build servers and in most circumstances you should be fine with only installing the 32 bit version and then reference the tasks in your scripts using

  • 3.5 --- <Import Project="$(MSBuildExtensionsPath)\ExtensionPack\MSBuild.ExtensionPack.tasks"/>
  • 4.0 --- <Import Project="$(MSBuildExtensionsPath)\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks"/>

That will work in 32 and 64 bit build processes.

The 32 and 64 bit assemblies are identical and compiled for anycpu. I think the 64bit installer was created at a time when $(MSBuildExtensionsPath) behaved differently. There may have been another reason, I'll have to think about it, but I'm not convinced we need different flavors now. Some people use the binaries checked into TFS or from a file share and avoid any flavor issues.

Does that help?


May 9, 2012 at 5:07 PM

Hi Mike,

Thanks for the reply. Before I got your message, I had tried just what you suggested (installing only the 32-bit version of MSBuild Extension Pack and importing the tasks directly from the installed files ($(MSBuildExtensionsPath)\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks), and that seems to work great!

I have found with VS and other Windows components (.Net, COM, 3rd-party controls, etc), that when working in a mixed world (32- and 64-bit), we have the most success dealing with 32-bit by default and only leveraging 64-bit (or the AnyCPU setting) when *every* component is 64-bit enabled.

Thanks again. We are migrating from a proprietary build environment to more industry-standard tools, and the MSBuild Extension Pack looks to be very helpful and robust.