The official source of product insight from the Visual Studio Engineering Team
We made a number of exciting changes to MSBuild for Visual Studio 2013, including rethinking the fundamental relationship between MSBuild, Visual Studio, and the .NET Framework. MSBuild has shipped as a component of the .NET framework since it was first introduced in 2005 with .NET 2.0, despite the fact that it is, first and foremost, a development tool leveraged primarily by Visual Studio developers. Starting with Visual Studio 2013, the 2013 version of MSBuild will ship as a part of Visual Studio instead of the .NET Framework. This transition allows us to more rapidly evolve MSBuild.
Most of the important changes this release stem from MSBuild’s transition into Visual Studio:
This change does not mean that we are removing previously shipped versions of MSBuild from the .NET Framework. MSBuild 4.5 is still part of the .NET 4.5.1 Framework. The Framework’s MSBuild will still be used by Visual Studio 2012, and is able to build any projects that round trip from Visual Studio 2013 to Visual Studio 2012. However, future innovation, new features, and support for new project types will not be ported to the Framework MSBuild.
MSBuild is now a component of Visual Studio and will ship with all SKUs of Visual Studio, including Team Build so if you use Visual Studio all of your build needs should be covered. We understand that there are a great number of reasons that you may want to use MSBuild and other build tools without needing to install Visual Studio so we are making the tools available as a new standalone package called Microsoft® Build Tools. The package includes MSBuild and the VB/C# compilers. The new package can be acquired here on the MSDN Download Center.
This standalone package is great for build servers requiring fine grain control of their build process. With this new approach to evolving MSBuild, you have more control over build behavior and are not impacted by .NET Framework versions.
We plan to evolve our build tools with each version of Visual Studio from now on. Each release of the Micrsoft® Build Tools will have a new version of MSBuild, the VB/C# Compilers, and Toolset. They will all version together. Visual Studio will use its corresponding version of MSBuild exclusively. For instance, Visual Studio 2013 will exclusively use MSBuild 2013 and ToolsVersion=”12.0”. To align with Visual Studio’s versioning we have updated MSBuild’s assembly version from 4.0 to 12.0 as well.
Shipping MSBuild separately from the .NET Framework required us to relocate MSBuild and the VB/C# compilers.
On 32-bit machines they can be found in: C:\Program Files\MSBuild\12.0\bin
On 64-bit machines the 32-bit tools will be under: C:\Program Files (x86)\MSBuild\12.0\bin
and the 64-bit tools under: C:\Program Files (x86)\MSBuild\12.0\bin\amd64
To help locate the tools at this new location, we added a GetPathToBuildToolsFile method to Microsoft.Build.Utilities’ ToolLocationHelper class. Example call:
There is a new property in ToolLocationHelper, CurrentToolsVersion, which maps to the latest version of the build tools.
Visual Studio 2013, the Visual Studio 2013 Developer Command Prompt and Team Build have been updated to look in these new paths when executing build tools, so normal builds will use the Microsoft® Build Tools 2013 by default. If you have customized build infrastructure you will need to update it to look in these new paths to use the latest version of MSBuild.
Both $(MSBuildToolsPath) and $(MSBuildBinPath) continue to point to the directory in which MSBuild is installed, however we discovered during testing that a few of our targets files also used these properties to point to components in the .NET Framework that were not strictly part of MSBuild, and have not moved to the new location with us. We don’t think this is too common, but if you have custom build process and run into any errors that indicate something cannot be found under “C:\Program Files (x86)\MSBuild\12.0\bin” a good first bet is to look for use of $(MSBuildToolsPath).
For build process that wants to reference components that remain in the .NET Framework, we introduced a new parameter, $(MSBuildFrameworkToolsPath), which points to the .NET Framework 4.5.1 directory.
In MSBuild 2013 we are removing a long standing discontinuity between command line builds and builds from within Visual Studio. Visual Studio has always overridden the Toolset version specified by project files in favor of the Toolset corresponding to the version Visual Studio building the projects. This technique is what allows you to round trip projects created in a different version of Visual Studio without needing both versions of Visual Studio installed on the machine.
MSBuild 2013 brings this same technique to command line builds as well. For most projects, this should greatly simplify the process of making sure that all your Toolset dependencies are available. As a general rule of thumb, any project that builds in Visual Studio will also build on the command line with minimal intervention. If your build process is sensitive to the specific ToolsVersion in your projects we have provided a number of ways to disable this new behavior, but be aware, compiling most ToolsVersion 4.0 projects will require Visual Studio 2012 to be installed on the machine alongside MSBuild 2013.
Referencing the latest MSBuild is as simple as it was in .NET 4.5. Since MSBuild 2013 is not a Framework component, it now shows up in the Extensions tab for assemblies. MSBuild’s latest assemblies are versioned 126.96.36.199 and assemblies such as Microsoft.Build.Utilities that have their version number appended to their names are now suffixed v12.0.dll. If your application references tasks or other assemblies that were compiled against an older version of MSBuild, you should use binding redirects if you reference the latest version of MSBuild.
We hope that the changes we are making to MSBuild 2013 with the introduction of the Microsoft® Build Tools package will help us better and more rapidly address the requirements of our customers and build predictability and confidence in the future of our build tools. We would love to hear your comments, concerns, and suggestions for the future of the Microsoft® Build Tools.
Will Buik – Program Manager, Visual Studio IDE Project and Build
Will is a long time user of Visual Studio and recently joined the Visual Studio Project and Build team at Microsoft. Since his foray into programing with Visual Basic 4, he has loved programming, software development, and hardware hacking. He is glad to have the opportunity to work on the development tools that he has leveraged for many years.