Microsoft. Net. Compilers 的目的是什么？

这个编译器的重要性是什么？这是必须的还是可以没有的？拥有另一个编译器的目的是什么，或者它只是一个未来的项目？请简要介绍一下情况。

29393 次浏览
小开

It's a package that provides open-source C# and Visual Basic compilers with rich code analysis APIs.

You can find extensive documentation on github:

https://github.com/dotnet/roslyn

小开
最佳答案

The point of the Microsoft.Net.Compilers package is that the compilers distributed with that package will be used for compiling your project, rather than the compiler that comes with .NET Framework or with Visual Studio. The most practical direct benefit is that it allows your projects to use C# 6 features, and then allows those projects to be built on a system that doesn't have a C# 6 compiler installed, for instance on a continuous integration server where you don't want to install the full Visual Studio 2015.

小开

As others have said, it contains the .NET compilers for C# and VB.NET.

An interesting aspect of this being a package is that you can specify a specific build of the compiler to for your project, including a version that hasn't been shipped with Visual Studio yet.

We use this in https://github.com/dotnet/project-system which is an open source component of Visual Studio. It allows us to use pre-release versions of the compiler to dogfood language features not supported by the compiler that ships with VS.

小开

At present there is no purpose to Microsoft.Net.Compilers. This is a NuGet package that is deprecated and will stop being produced after Visual Studio 16.5. There is a successor package named Microsoft.Net.Compilers.Toolset. This package has much the same functionality as Microsoft.Net.Compilers but works with both .NET Desktop and .NET Core MSBuild instances.

Even so Microsoft.Net.Compilers.Toolset is not meant for general consumption. This package serves two specific uses:

  1. Acts as a short term vehicle for unblocking customers that hit crashing bugs in the compiler. For such customers we can use this package to unblock their scenarios just an hour or so after we merge the fix into the Roslyn repository. This serves as a bridge until the fix makes it into the associated Visual Studio or .NET SDK servicing release. When that happens the customer is asked to remove the package from their solution and rely on the officially released toolsets.
  2. Serves as a mechanism to move binaries between Roslyn and the official builds of the .NET SDk.

This package is not meant for general long term consumption by customers for their build. I understand that some customers choose to do this but such use is also not supported. The package can and will regularly cause breaks by taking dependencies on new versions of MSBuild or tasks / targets in the .NET SDK.

Customers who want to use new versions of the compiler for their builds are instead encouraged to use one of the official distributions of the compiler:

  1. Use the Visual Studio Build Tools SKU.
  2. Use the .NET SDK

Note: the Microsoft.Net.Compilers package was officially supported as a part of the Microsoft.CodeDom.Providers.DotNetCompilerPlatform package several years ago as it was a dependency. Beginning in version 2.0 though the dependency on Microsoft.Net.Compilers was removed and it now stands as a completely independent package. At the same time we've moved to deprecate Microsoft.Net.Compilers as there are no longer any explicit use cases for it.

This does mean that some customers unexpectedly find themselves with Microsoft.Net.Compilers in their project file because it wasn't removed when Microsoft.CodeDom.Providers.DotNetCompilerPlatform dropped the dependency. The advice for such customers is to simply delete the reference to the package. It is not needed anymore.


提交答案