Difference between MSBuild version and MSBuild ToolsVersion?


Could someone help me understand the difference between the MSBuild version and the MSBuild ToolsVersion?  For example, which decides what version of the C#/VB compiler is used?  How are they different?  When would I set them to different versions of the framework?


Comment actions Permalink

MSBuild version is the version of .NET where msbuild was taken.
ToolsVersion is the version of tools (i.e. c# version) that used to compile.

Actually, MSBuild supports compilation to older versions, so one may use MSBuild 4.0 with ToolsVersion 2.0 to produce .NET 2.0 assemblies.

Please have a look to msdn for more details and further reading

Comment actions Permalink

Hi Eugene,

Could you clarify what you mean by "MSBuild version is the version of .NET where msbuild was taken"?  What do you mean by "taken"?

And specifically what "tools" are part of the Tools? =)  Actually I'm still confused about the difference.  I looked at MSDN but couldn't find an explanation.  Can you point me to the right page?

As I see it...there are three major components to a build:
- MSBuild.exe / build tasks
- csc compiler (or vb...)
- Various version of .NET that are targeted by .csproj files

Why does the build system care that msbuild was "taken" with Framework 4.0?  My csproj files tell the system which version of the framework to target.  It seems like there should only be 1 setting - the ToolsVersion?  What am I missing?


Comment actions Permalink

I think there is a right place to find aswer to your question:
Do not forget to select .NET 3.5 or 4.0 to read actual data.

MSBuild Version == .NET Framework version.
Each .NET Framework contains MSBuild.exe inside. I used 'taken' for this.

There could be some differences between running a build from MSBuild v2.0 and from MSBuild v4.0 targeted to 2.0.
We simply let used decide what version is required to build their project.

On the other hand, there is no easy way for TeamCity build runner to guess msbuild version to tools version for a particular
build. I believe, users should know the version of MSBuild thet is required to build their project.

If you do not know the tools version for your build, you may select 'none' to let MSBuild decide.
Setting tools version from TeamCity web UI will be equivalent to setting /toolsversion: commandline argument.

Comment actions Permalink

Ok...I read the MSDN pages and your post and I think I'm getting a better idea.

Here's another way to ask the question:

What does TeamCity do with the MSBuild Version?  Does it use this to find path MSBuild.exe lives on?  For example if I set Framework 2.0, does MSBuild say "ok, then use C:\Windows\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe to build."  Is that all it does?

What does TeamCity do with the MSBuild ToolsVersion?  Does this generate a "/toolsversion" argument to the MSBuild.exe?  Is that all it does?

I think the best answer to help me understand this is to understand what specifically TeamCity does when these settings are set.


Comment actions Permalink

MSBuild version is used only to find a path to MSBuild.exe process.

TeamCity generates an msbuild stript to wrap user's msbuild script. Actually toolsversion will be set to <Project> element of the generated MSBuild script.
It generates <Import> task if user specifies msbuild project and <MSBuild> task if user specifies .sln file (e.g. sln2008 build runner)

Comment actions Permalink

OH!  Got it!

So when ToolsVersion is set in <Project> element of generated MSBuild script does that override the ToolsVersion of the individual projects?  I hope not...

I think the MSBuild ToolsVersion is an unncessary and confusing parameter in TeamCity.  As a developer, I have the option to put a ToolsVersion in my own build project file.  If I omit it then its my own fault.  Since TeamCity is simply creating a wrapper, does it matter what ToolsVersion its running under?  I guess it matters if I omit ToolsVersion from all my project files...

anyways, I think I got it.  Thanks!


Please sign in to leave a comment.