Roslyn: Microsoft.Net.Compilers is only supported on MSBuild v16.3 and above

[zhuxb711]

Version Used: 3.4.0

Steps to Reproduce:

1. Using VisualStudio 2019 16.4
2. Build UWP project

Tips: Same project work well in Microsoft.Net.Compilers 3.3.1

Expected Behavior:
Build succeed
Actual Behavior:

[UweKeim]

See also:

https://developercommunity.visualstudio.com/content/problem/842373/microsoftnetcompilers-is-only-supported-on-msbuild.html

[UweKeim]

Trying "3.5.0-beta1-final" of Microsoft.Net.Compilers still shows the erroneous behaviour.

[dev-masih]

i can't get rid of this, reverted back to Microsoft.Net.Compilers 3.3.1

[jeremycook]

I hit this when attempting to publish a .NET 4.6.1 MVC 5 web application from Visual Studio 16.3.5 after upgrading my Nuget packages. Reverting to 3.3.1 worked around the error. Note that I could build locally and preview the publish without any errors. Trying to publish triggered the error.

[UweKeim]

Commenting out the <Error> tag helped me:

1. Use (e.g.) Notepad++ to search in all *.props files for the text "on MSBuild v16.3 and above"
2. Sourround the "<Error Text="Microsoft.Net.Compilers is only supported on MSBuild v16.3 and above" Condition="'$(MSBuildToolsVersion)' &lt; '16.3'" />" with XML comments "<!--" and "-->"
3. Save all files.

After that, I can again compile all my solutions, even if they use 3.4.0 of Microsoft.Net.Compilers.

---

Update 2019-12-14:

A better self-quick-fix is to replace "$(MSBuildToolsVersion)" with "$(MSBuildVersion)" in the *.props files, as done in the PR.

[JesperNoerregaard]

I found that the variable $(MSBuildToolsVersion) returned "latest" instead of a number

[jamaljaj]

Commenting out the <Error> tag helped me:

1. Use (e.g.) Notepad++ to search in all *.props files for the text "on MSBuild v16.3 and above"
2. Sourround the "<Error Text="Microsoft.Net.Compilers is only supported on MSBuild v16.3 and above" Condition="'$(MSBuildToolsVersion)' &lt; '16.3'" />" with XML comments "<!--" and "-->"
3. Save all files.

After that, I can again compile all my solutions, even if they use 3.4.0 of Microsoft.Net.Compilers.

thnks work fro me.

[jaredpar]

PR #40349 should fix this issue.

The package is indeed restricted to MSBuild 16.3 but the check we are using today isn't using the correct MSBuild property to do the check. This PR fixes the check to be correct.

Also please note Microsoft.Net.Compilers.nupkg is deprecated. Beginning in 16.5 we will no longer be officially producing this anymore. Please migrate to Microsoft.Net.Compilers.Toolset instead.

[UweKeim]

Thanks. So a better self-quick-fix would be to replace "$(MSBuildToolsVersion)" with "$(MSBuildVersion)" in the *.props files, as done in the PR.

[nil4]

@jaredpar NuGet has a supported method for marking packages as deprecated, and suggesting available alternatives, documented here https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages.

It looks like this would highlight the deprecation in the VS UI as well as the NuGet gallery. Would it make sense to do this for Microsoft.Net.Compilers?

[wstaelens]

Microsoft.Net.Compilers is only supported on MSBuild v16.3 and above

had to revert to 3.3.1 to get it working again.

[dev-masih]

@wstaelens Microsoft.Net.Compilers is now deprecated, try to use Microsoft.Net.Compilers.Toolset instead.

[UweKeim]

@wstaelens Microsoft.Net.Compilers is now deprecated, try to use Microsoft.Net.Compilers.Toolset instead.

Is there some instruction on how to migrate a project that uses Microsoft.Net.Compilers to Microsoft.Net.Compilers.Toolset?

Is it as simple as uninstalling the Microsoft.Net.Compilers NuGet package and installing the Microsoft.Net.Compilers.Toolset NuGet package?

[dev-masih]

Is it as simple as uninstalling the Microsoft.Net.Compilers NuGet package and installing the Microsoft.Net.Compilers.Toolset NuGet package?

yes, it's actually as simple as that

[wstaelens]

Is it as simple as uninstalling the Microsoft.Net.Compilers NuGet package and installing the Microsoft.Net.Compilers.Toolset NuGet package?

yes, it's actually as simple as that

had to restart the solution because nuget package didn't completely uninstall.

[headygains]

Is it as simple as uninstalling the Microsoft.Net.Compilers NuGet package and installing the Microsoft.Net.Compilers.Toolset NuGet package?
yes, it's actually as simple as that

had to restart the solution because nuget package didn't completely uninstall.

Yeah that's typically how things go when messing with these compiler packages.

[sinanaltaii]

I had the same problem, i downgraded to 3.3.1. Visual studio had to restart, rebuilt and voila, it worked.
The question is. Should i still install Microsoft.Net.Compilers.Toolset instead?

[jaredpar]

Should i still install Microsoft.Net.Compilers.Toolset instead?

No. You should uninstall Microsoft.Net.Compilers and not install another package. These packages have two purposes:

1. Active servicing events with customers
2. Distributing binaries between the .NET builds

Unless you're in one of those two situations you should avoid using these packages. Any other use is unsupported.

[sinanaltaii]

Should i still install Microsoft.Net.Compilers.Toolset instead?

No. You should uninstall Microsoft.Net.Compilers and not install another package. These packages have two purposes:

1. Active servicing events with customers
2. Distributing binaries between the .NET builds

Unless you're in one of those two situations you should avoid using these packages. Any other use is unsupported.

Actually i dont even know what those two situations are which means no, im not in the situations you mentioned, its just i simple umbraco website project. I simply uninstalled the package and everyting seems to run fine.
Thank you very much for the help :) @jaredpar

[rroman81]

@jaredpar Could you elaborate on case when we do need Microsoft.CodeDom.Provider.DotNetCompilerPlatform and subsequent dependency Microsoft.Net.Compilers. Most folks would get these packages when selecting Full Framework Web template.

[jaredpar]

@rroman81 the newer versions of Microsoft.CodeDom.Provider.DotNetCompilerPlatform should not depend on Microsoft.Net.Compilers anymore. The 1.0 versions did have this dependency but starting in 2.0 this dependency does not exist.

[stijnherreman]

No. You should uninstall Microsoft.Net.Compilers and not install another package. These packages have two purposes:

1. Active servicing events with customers

2. Distributing binaries between the .NET builds

Unless you're in one of those two situations you should avoid using these packages. Any other use is unsupported.

@jaredpar I started depending on that package a couple years ago, IIRC because I wanted to upgrade to net471 and the build server was outdated. I imagine there are many others using it in that scenario, unaware that it is not supported at all. https://stackoverflow.com/a/34548597 is a popular answer promoting this practice.

[jaredpar]

@stijnherreman thanks for letting me know about that particular question. I added my own response to try and get the correct message out there.

[JackArbiter]

Thanks @jaredpar I linked your response in my answer to the Stack Overflow question concerning this issue.