CODEWITHSUNDEEP
c#.netbuildmsbuild
Murphybro2
Murphybro2

Reputation: 2679

What's the difference between using dotnet and MSBuild for building .NET applications?

I've just had to do some builds without using Visual Studio for the first time, and clearly there is a gap in my knowledge regarding MSBuild and the build process.

So, what are the differences between the two build processes below?

Option 1:

dotnet build C:\Dev\trunk\Mvc.sln

This option uses "Build Engine version 16.8.3+39993bd9d for .NET" - I presume this means this way can be used for .NET Core as it has no reference to "Framework"?

Option 2:

msbuild C:\Dev\trunk\Mvc.sln

This option uses "Build Engine version 16.8.2+25e4d540b for .NET Framework".

My assumption was that the "dotnet build" command was just a shorthand way of using MSBuild. However, the logging provided by both is pretty different and they both produce different results.

Upvotes: 85

Views: 57172

Answers (2)

Neits
Neits

Reputation: 458

MSBuild stands for "Microsoft Build Engine", which is a platform for building applications. Before the appearance of the platform-independent .NET with .NET Core, MSBuild was a Windows-only tool and could only be obtained as part of a Visual Studio licence.

With the appearance of .NET Core it is possible to get MSBuild by installing a .NET SDK, which is not bound to Visual Studio and platform independent. When using .NET SDK via CLI, running dotnet build is equivalent to dotnet msbuild --restore. Under the hood, the latter command also runs MSBuild, but in this case the one that comes with .NET SDK.

As far as I know, running the msbuild CLI command is only possible on windows with Visual Studio installed (haven't tried on a Mac with VS for Mac). This command, however, is equivalent to running dotnet msbuild on a system with .NET SDK. So, in a way, both commands that you mention are essentially the same, except that dotnet build also silently call restores the project before running dotnet msbuild (which, as mentioned, is equivalent to msbuild on Windows with Visual Studio.

Upvotes: 14

canton7
canton7

Reputation: 42225

Roslyn -- the C# compiler platform -- is a .NET Standard 2.0 library, meaning that it can run on both .NET Framework 4.6.1+ and .NET Core 2.0+(1).

Visual Studio, which includes MSBuild, runs on .NET Framework. When you build a project using Visual Studio (or directly using MSBuild), it runs Roslyn on .NET Framework. Visual Studio knows how to process both SDK-style csprojs and the legacy non-SDK-style csprojs, and invoke Roslyn accordingly. The version of Roslyn which is used is tied to the Visual Studio version.

dotnet build is a separate tool, and is a .NET Core application. It knows how to build SDK-style csprojs only, and it does this by running Roslyn on .NET Core. Roslyn is distributed with the .NET Core SDKs, and dotnet build loads Roslyn from one of these installed SDK versions (normally the latest).

These two ways of building a C# project are more-or-less equivalent, and they invoke the same compiler code. However, they differ on where they can run (Visual Studio is .NET Framework and Windows-only, dotnet build is .NET Core and can run on multiple platforms), and whether they can build legacy non-SDK-style csprojs. dotnet build is also a bit nicer to use from the command-line.

Note that the runtime which Roslyn is loaded into has no bearing on the compiled IL which Roslyn can emit: Roslyn running on .NET Framework can emit IL which is executed by .NET Core just fine, and vice versa.

If you are using analyzers which target .NET Core (unlikely, as Analyzers are encouraged to target .NET Standard 2.0), these will only run from dotnet build.

(1) I'm using ".NET Core" to refer to both .NET Core and .NET 5+.

Upvotes: 115

Related Questions