MSBuild is now part of Visual Studio!

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:

MSBuild and the VB/C# compilers are now available as a standalone package, Microsoft® Build Tools. This package is installed with Visual Studio 2013.

We are simplifying MSBuild’s versioning story. Each version of Visual Studio will have a corresponding version of the Microsoft® Build Tools including MSBuild, the VB/C# compilers, and common tasks and targets that make up the 2013 Toolset. There will no longer be any sub Toolset versions. Visual Studio 2013 will exclusively use 2013 MSBuild and VB/C# compilers (assembly version 12.0) and the 2013 Toolset (ToolsVersion 12.0).

The way MSBuild selects Toolset versions for command line builds is now identical to the way Visual Studio builds projects. If your projects build in VS, they will build from the command line. No more manually overriding Toolset versions and hunting down missing dependencies.

MSBuild has a dependency on the latest Framework, .NET 4.5.1.

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.

The New Microsoft® Build Tools Package

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.

MSBuild and its Toolset now Version with Visual Studio

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.

MSBuild’s New Binaries Location

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

To help locate the tools at this new location, we added a GetPathToBuildToolsFile method to Microsoft.Build.Utilities’ ToolLocationHelper class. Example call:

ToolLocationHelper.GetPathToBuildToolsFile(

“msbuild.exe”, “12.0”,

DotNetFrameworkArchitecture.Bitness64);

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.

Command Line Builds and Asset Compatibility in MSBuild 2013

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

Moving Forward

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.

Tags

What about the setup/deployment project type? There wasn't anything wrong with it. Please put it back.

4 years ago

Robert McLaws

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.

4 years ago

Craig Berntson

What is the licensing for non-TFS build servers? How would we install the package on the build server?

4 years ago

Dean J.

@Robert McLaws

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.

WHY? What's wrong with using more obvious C:Program FilesMSBuild12.0bin ?

4 years ago

Drew Marsh

Same comment as 13xforever: why not just place the 64-bit components where 64-bit components belong on Windows?

4 years ago

Oscar

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

Why on would build tools have the requirement of "DirectX 9-capable video card that runs at 1024 x 768 or higher display resolution"?

4 years ago

jalf

So, I assume the Build Tools package will also contain the C++ compiler, right? Because anything else would be silly.

4 years ago

Tristan

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

4 years ago

Thorn

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

>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

4 years ago

Mladen Mihajlovic

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?

4 years ago

Iain

@MalcolmS – serves me right for not reading the entire article before commenting. Thanks!

4 years ago

RogOTM

Hello! Thanks for this great news. Looks promising.

Will the Microsoft® Build Tools Package still maintain registry key HKLMSOFTWAREMicrosoftMSBuildToolsVersions12.0MSBuildToolsPath, 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.

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.

@Craig

The Build Tools package has no dependency on a DirectX capable video card. We are removing that from the list of requirements 🙂

@jalf

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.

@RogOTM

Thanks for the suggestion. We still maintain the MSBuildToolsPath registry keys. The new GetPathToBuildToolsFile method is just there as an alternative.

@Frank

The aspnet_compiler is still available as part of the .NET Framework. There are currently no plans to move it into this package.

4 years ago

Sandro

What about the setup/deployment project type? There wasn't anything wrong with it. Please put it back. [2]

4 years ago

Brandon Dimperio

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?

4 years ago

nsj

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.

4 years ago

Andy

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.

4 years ago

Nunya Bizness

When is this being released? I see that the Preview download link was removed.

I thought there's going to be a separate installer version for build servers…

4 years ago

Frustrated

How might one solve the problem of spaces introduced into path names? Now that the msbuild.exe is in the 'program files' folder, there is now a space in the path and I'm getting "'C:Program' is not recognised as an internal or external command".

Seems to be looking for Microsoft.Common.CurrentVersion.targets(1069,5) – error MSB3073 – exited with code 9009, in the same bin directory under Program Files.

This is a fresh install of VS2013 on Windows 8.1 in a new VM.

Before MSBuild was integrated into VS, the build script had no issue as the path to it contained no spaced (it was calling Windows directory).

4 years ago

hYam

I cannot build VS2013 project via TFS2012.

TFSBuild2012 uses MSBuild 4.0.

C:Program Files (x86)MSBuildMicrosoft.Cppv4.0V110Microsoft.Cpp.Platform.targets (44): The builds tools for v120 (Platform Toolset = 'v120') cannot be found. To build using the v120 build tools, either click the Project menu or right-click the solution, and then select "Update VC++ Projects…". Install v120 to build using the v120 build tools.

4 years ago

DissMan

Man, how old have you been programming vb4? 😉

4 years ago

Mobile Geek

The link to the new package appears to not exist anymore. Where is the package now? I'm trying to install this on a build server without having to install Visual Studio 2012 or 2013.

4 years ago

Scott Forbes

The link here appears to not work now, and it seems near to impossible to find the standalone MSBuild package to install. I have an automated build server and I do not want to install VS2013. Anyone have any suggestions?

How does this new MSBuild model affect the ability to build solutions that contain Unit Tests? Will we be able to build projects containing Unit Tests without separately having to reference MSTest or will the MSTest model still be required. If the new MSBuild model would now incorporate the ability to build MSTest based projects, that would be an incredible and most welcome relief!

4 years ago

Kevin T.

I have two VS 2013 Express setups one at my work and one at home. I use team explorer. I uploaded a change to my project from work, and when I did a pull from home, I got an error where I couldn't open any of the projects in the solution because it says "Missing microsoft.csharp.targets." On my work machine they are there. On my home machine, I don't have the program files (86x)msbuild12.0 nor the program filesmsbuild12.0 folders. I have in fact the old msbuild (it seems). On my work computer these folders are there!

I wanted to avoid having to reinstall the visual studio express because I have it configured already so nicely with all these packages and want to avoid that trouble.

any suggestions? I tried download msbuild directly but that doesn't seem to change anything.

Help!

4 years ago

Yves de Montaudouin

Very Nice, so how do you use it?

4 years ago

Shakti Mohanty

I am getting this error C:Program Files (x86)MSBuildMicrosoft.Cppv4.0PlatformsWin32Microsoft.Cpp.Win32.Targets(518,5): error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected on VS2012.

3 years ago

Georges

Hi,

On my system with only VS2013 installed, I am just trying to build a VB.Net project, and I get this exit 9009 code. What exactly do have to do to fix that issue ?

The same project is building fine on anotgher system where I have 2012 and 2013 version inslalled.

Just been through the pain of trying to create a build server without Visual Studio. This is therefore welcome however it does feel half baked.

To get a machine to actually build anything useful without Visual Studio you still have to install an awful lot of software and copy a large number of files from a Visual Studio install such as PublicAssemblies and the ReferenceAssemblies from Program Files. There is a UserVoice request for creating a build package that does not Visual Studio. It would be great to see this get lots of votes: visualstudio.uservoice.com/…/5786689-support-net-builds-without-requiring-visual-studi

Worth noting for anyone doing the same and using MSTest you can now also install the testing framework as a separate package: Agents for Visual studio 2013: http://www.microsoft.com/…/details.aspx

Thanks for the post

3 years ago

Lex Li

The link to Microsoft® Build Tools is no longer valid.

3 years ago

Sean Feldman

As was outlined a while ago, the link to Build Tools is no longer valid.

Please fix it.

3 years ago

Radhika Tadinada - MSFT

@ Lex Li

@ Sean Feldman

Thanks for pointing out the broken links. The links have now been fixed. You can get the build tools here –