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 220.127.116.11 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.
BCL team is dropping framework, and goto nuget for distributing libraries, because framework release cycles are too slow. MS Build the same, because VS is releasing annually. Looks like Framework is evolving much slower than in the past. Do framework join Silverlight as 'supported, but not further developed' ?
> Each version of Visual Studio will have a corresponding version of the Microsoft® Build Tools
Ha! MS will need 20 more years to discover that MSBuild IS NOT a part of VS, but just a "build tool" and ANY version of build tools should be usable with any VS.
The children are running Microsoft
Yet another reason to switch to Linux!
>Ha! MS will need 20 more years to discover that MSBuild IS NOT a part of VS, but just a "build tool" and ANY version of build tools should be usable with any VS.
Agreed. Which IDE we use should be irrelevant. We should be able to update the build chain without updating the IDE.
>So, I assume the Build Tools package will also contain the C++ compiler, right? Because anything else would be silly.
It's probably too much to hope for in this release. Hopefully they'll get on the bandwagon soon though and maybe we'll actually get language updates without having to switch IDEs
Just to clarify, you don't need Visual Studio to install and it's free (All SKU's means express too)? What's the point of even linking it to Visual Studio? Just release as it's own package, maybe even as nuget package if possible?
@MalcolmS - serves me right for not reading the entire article before commenting. Thanks!
Hello! Thanks for this great news. Looks promising.
Will the Microsoft® Build Tools Package still maintain registry key HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\MSBuildToolsPath, or is ToolLocationHelper.GetPathToBuildToolsFile() the only way?
I wish there would be one common path to msbuild.exe across different versions. And let msbuild select the right version from the information <Project ToolsVersion=”12.0”...> in project files. Especially when using msbuild in continous integration. Avoid the hustle of creating own scripts just for building.
I noticed aspnet_compiler is not there anymore. How do I manually precompile an application ?
Are you bringing back the Setup/Deployment Project Type back? Please bring it back to VS2013 and VS2012.
Hello everyone and thanks for the comments!
First, I would like to reiterate that MSBuild and the compilers are available as a standalone installer. They are also bundled with Visual Studio and Team Build, but the standalone installer can be used without a Visual Studio license and can be deployed to build servers.
@13xforever, Drew, Jeff, and Linac
Keeping the 64-bit version of the tools under an amd64 directory is a convention used across a number of Microsoft Visual Studio and .NET SDKs. Almost all of MSBuild's tasks, and targets, and other resource files are architecture independent and reside in the x86 Program Files as well. To avoid unnecessary duplication of these assets, since so many of them are architecture independent, the $MSBuildExtensionsPath is always set to the x86 directory even for the 64-bit versions of the tools.
The Build Tools package has no dependency on a DirectX capable video card. We are removing that from the list of requirements :)
The Build Tools package does not currently contain the C++ compilers and related tools. They are unlikely to be added for Visual Studio 2013 RTM, but it is possible they will be in a future release.
Thanks for the suggestion. We still maintain the MSBuildToolsPath registry keys. The new GetPathToBuildToolsFile method is just there as an alternative.
The aspnet_compiler is still available as part of the .NET Framework. There are currently no plans to move it into this package.
What about the setup/deployment project type? There wasn't anything wrong with it. Please put it back. 
Does this mean we can finally define a solution level extension that will run in MsBuild and visual studio? or anything that will extend the build process for all projects in the solution for both Visual studio and MsBuild?
May I just say that this is one of the poorly written blog entries I've ever read on MSDN. There are a lot of repetitious information with the idea going back and forth and never seem to go anywhere. I expect more from MSDN writers.
Looks like my other question didn't show up....
Can you have Team Build 2012 use the VS2013 MSBuild (Assuming they're both installed on the build server)? If so, where/how do you specify that? In the past you could use the TFSBuildServiceHost.exe.config file - but that doesn't seem to work anymore.