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.
What about the setup/deployment project type? There wasn't anything wrong with it. Please put it back.
Why not call the new path to the .NET Framework $(DotNetFrameworkPath) to reduce any ambiguity? That makes it crystal clear it's function.
Dean J, Microsoft said a long time ago that it was deprecating the Setup/Deployment project, and in VS2013 they completed the deprecation cycle. That doesn't specifically have anything to do with MSBuild specifically.
What is the licensing for non-TFS build servers? How would we install the package on the build server?
You're right, it's not specifically related to MSBuild. Apparently it's not important to you, but it is to many others. You probably didn't see the numerous comments on the "2013 Preview survey" post on this blog (few posts ago), so you probably don't know just how many people are still asking for it to be put back.
> and the 64-bit tools under: C:\Program Files (x86)\MSBuild\12.0\bin\amd64
WHY? What's wrong with using more obvious C:\Program Files\MSBuild\12.0\bin ?
Same comment as 13xforever: why not just place the 64-bit components where 64-bit components belong on Windows?
Hi. We use Msbuild on our servers for the deployment of our software. It is part of our Continuous Integration process. If Msbuild will be part of VS, does than mean we will have to install someversion of VS on our production
"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"
This is baffling.
Sounds interesting, the next logical step is to ship a test runner built into msbuild that does it require vs to be installed or downloading a separate nuget tool package.
Sounds more reasonable.
@13xforever & others
I guess these are the compilers to _create_ 64-bit components, they aren't 64-bit themselves. If I'm wrong, then of course this doesn't make any sense.
Please provide a standalone installer for MSBuild for those of us who try to avoid deploying Visual Studio onto our CI Build Servers.
@Iain - the installer you desire is linked in the article: www.microsoft.com/.../details.aspx
Why on would build tools have the requirement of "DirectX 9-capable video card that runs at 1024 x 768 or higher display resolution"?
So, I assume the Build Tools package will also contain the C++ compiler, right? Because anything else would be silly.