Roslyn: MSbuild issue

[PhilPJL]

Version used: 2.1

Use TFS 2013 build to build our solution and would like to use C#7. There was no problem using C#6 and .NET compilers 1.x.

Expected Behavior: Build successfully
Actual Behavior: Fails with

 ...\Sources\packages\Microsoft.Net.Compilers.2.1.0\build\Microsoft.Net.Compilers.props(13,5): error : Microsoft.Net.Compilers is only supported on MSBuild v14.0 and above [....\SubSystems-Main\Sources\Hexcel.Services.Shared\Hexcel.Services.Shared.csproj]

Also confused by this statement on the Nuget page:

.Net Compilers package. Referencing this package will cause the project to be built using the specific version of the C# and Visual Basic compilers contained in the package, as opposed to any system installed version.

This package can be used to compile code targeting any platform, _but can only be run using the desktop .NET 4.6+ Full Framework_.

Is it not possible to use .NET compilers 2 via TFS Build?

[jcouv]

Relates to https://github.com/dotnet/roslyn/issues/18533 (the requirements of the compiler packages need to be documented).

[PhilPJL]

Do I understand from #18533 that the .NET compiler V2+ is not supported on anything less than MS Build 15? In which case we probably need TFS Build 2017?

[jaredpar]

@PhilPJL at a high level yes.

The actual compiler bits don't depend on MSBuild and hence can be used in MSBuild 14, if you're willing to do a bit of work. But our actual MSBuild task that drives the compiler is dependent on MSBuild 15.0 for C# 7.0 and above.

[PhilPJL]

What's the 'bit of work'. My experience so far is that using TFS build 2015 with a XAML build definition and specifying MSbuild arguments of /P:VisualStudioVersion=14.0 /tv:14.0 when referencing the .NET compiler V2 nuget package all of the .exe projects build successfully. However many (but not all) of the class library projects fail with "Microsoft.Net.Compilers is only supported on MSBuild v14.0".

Which is deeply frustrating.

We will get to TFS 2017 in October so the issue will go away, but it should just have worked like it did for V1.

[mihailik]

Just got this package from nuget using Visual Studio 2015, and it started to fail arbitrarily for SOME projects, but not all.

If it's not compatible with VS 2015, why is it suggested as upgrade?

Nuget has enough ways to enforce package affinity and exposure to the right set of tools. Can't Microsoft use its own tools correctly? We need it to work, and on a commercial project too. We have bought our VS2015 and want it to work.

In addition to that, this issue isn't having a clear response from the vendor: what's causing the bug, what's the workaround, when are you planning to fix it?

[jaredpar]

Just got this package from nuget using Visual Studio 2015, and it started to fail arbitrarily for SOME projects, but not all.

Can you provide more information here: an error message, stack trace, etc ...

[mihailik]

Totally same as the original issue:

| Severity | Code | Description | Project | File | Line | Suppression | State |
|--|--|--|--|--|--|--|--|
|Error | | Microsoft.Net.Compilers is only supported on MSBuild v15.0 and above | PortfolioManagement.Tests | C:\Users\n599754\code\AB-Portmang\packages\Microsoft.Net.Compilers.2.6.1\build\Microsoft.Net.Compilers.props | 13 |
|Error | | Microsoft.Net.Compilers is only supported on MSBuild v15.0 and above | PortfolioManagement.Tests | C:\Users\n599754\code\AB-Portmang\packages\Microsoft.Net.Compilers.2.6.1\build\Microsoft.Net.Compilers.props | 13 |

That comes up in VS.

The solution consists of 5 projects, of which only one blows up — the test one (see above). The rest seem to be fine.

[mihailik]

By the way, no idea why VS repeats it twice.

[jaredpar]

The error is expected. This NuPkg file, at the current 2.* version, is only supported on MSBuild 15.0 / VS 2017 and above. The earlier versions, 1.*, were supported on MSBuild 14.0 / VS 2015. Given that you're using VS 2015 I would expect this error when compiling with the package.

As to why the error only shows up 2 times vs. 5 there are a couple of potential reasons:

1. There are only 2 projects at the root of your build. MSBuild fails on both of them and hence doesn't proceed to the Compile step of the other 3.
2. The package is only installed on 2 of the 5 projects.

My suspicion though is that it's the first one.

[mihailik]

Visual Studio 2015 suggested upgrading to an incompatible version - no, the error is not expected.

Also as I mentioned, the other projects using that package build fine inside that same solution.

Also you should see: both times the error refer to the exact same CSPROJ. That's a test project referring to 2 other projects.

[jaredpar]

Visual Studio 2015 suggested upgrading to an incompatible version

This is a limitation of NuGet. It is simply looking at the package versions here. It doesn't consider what version of MSBuild will be used to built a given project. The latter is what is relevant here.

Going forward we're going to attempt to make this package more resilient to the version of MSBuild that is used to invoke it. That work wasn't able to happen in time for the 14.0 / 15.0 change though.

Also as I mentioned, the other projects using that package build fine inside that same solution.

The check for the MSBuild version can be subverted if one of the following is done:

1. The target ValidateMSBuildToolsVersion is overridden which prevents us from running the check.
2. The initial targets for our props file are overridden.
3. The package is installed but not actually used during build due to another portion of the build suppressing its usage.

I think the most likely option is 3 but I'd need to see a binary / diagnostic log to be sure. If you have a binary / diagnostic log that you can share out I can take a look and see if any of these is happening.

[RubixRevenge]

Using VS 2017 Pro and TFS 2017 Express, I am getting this error in the Visual Studio Build step:

##[error]WebPortal\packages\Microsoft.Net.Compilers.2.6.1\build\Microsoft.Net.Compilers.props(13,5): Error : Microsoft.Net.Compilers is only supported on MSBuild v15.0 and above

I made sure to have Visual Studio 2017 as the version. This is a completely new project & solution. It's the default MVC project you get when you create a .NET Framework MVC project. I made sure that all the Nuget packages were updated to the current version & verified my build worked locally. I pushed the commits to TFS, and I can't past this error in the Visual Studio Build step.

I'd be happy to post any relevant log excerpts or screenshots. In my scenario (VS 2017 and TFS 2017 Express), is this a bug or an indication I need to configure something that I have not seen in the tutorials?

[mmu69]

Local with VS2017 i've got not problem using the 2.6.0 and 2.6.1 Microsoft.Net.Compilers, but building in VSTS gives the MSBuild v15 error. Is there any option to use the latest Microsoft.Net.Compilers with VSTS (Visual Studio Build)?

[error]packages\Microsoft.Net.Compilers.2.6.1\build\Microsoft.Net.Compilers.props(13,5): Error : Microsoft.Net.Compilers is only supported on MSBuild v15.0 and above

[Swellenator]

I have been building on a TFS 2015 build server with v2.3.x for some time without any problems. Now after updating the v2.6.x I get the error saying it only supports v15. It looks like the check for MSBuild versions was only added in v2.6.x - adding this check seems like a breaking change.

What was happening before with v2.3.x? If I downgrade to v2.4.x it will still compile on my build server, so why not just let me build v2.6.x as well?

[rshackleton]

@mmu69 also experiencing the same issue on VSTS.

error : Microsoft.Net.Compilers is only supported on MSBuild v15.0 and above

I can't immediately tell if MSBuild 15.0 is available on the hosted build servers.

[rainersigwald]

Folks that are seeing problems on VSTS: what hosted agent queue are you running under? You should select Hosted VS2017 to use MSBuild 15.

[PhilPJL]

@jaredpar

You said

The actual compiler bits don't depend on MSBuild and hence can be used in MSBuild 14, if you're willing to do a bit of work. But our actual MSBuild task that drives the compiler is dependent on MSBuild 15.0 for C# 7.0 and above.

I've just tried this:
Created a test solution with one WCF, WPF, class library and ASP.NET MVC project. Set them all to use the latest .NET compiler package 2.7. Used C# 7 features. The solution builds fine on TFS Build 2013.

Therefore I thought the latest package had fixed things. I changed a WCF service in our production solution to use compiler 2.7. Disappointingly the build failed with the usual - "C:\Builds\111\Scrum\SubSystems-MainSources\packages\Microsoft.Net.Compilers.2.7.0\build\Microsoft.Net.Compilers.props (13): Microsoft.Net.Compilers is only supported on MSBuild v15.0 and above".

But if I edit the Compiler.props file and disable the ValidateMSBuildToolsVersion condition then the build works fine.

Can you explain some things?
1) is the Microsoft.Net.Compilers package self contained? Does it contain everything required to build C# 7.x or not?
2) if it is self contained why is there a seemingly artificial restriction on the build tool version? Why is the restriction there?
3) if I remove the restriction and the build apparently works fine is there anything I'm missing - is the compiled code good or not?
4) why do .exe projects allow us to use .net.compilers 2.4 (but not later), but class library projects only allow 1.3.2 (but not later) all in the same solution?

[jaredpar]

is the Microsoft.Net.Compilers package self contained? Does it contain everything required to build C# 7.x or not?

The package is a self contained MSBuild plugin. That means it contains the tasks and targets necessary fro MSBuild plus the supporting EXEs to actually compile binaries. They EXEs are also self contained and if needed could be shipped as an independent package but generally they're only ever used via MSBuild.

if it is self contained why is there a seemingly artificial restriction on the build tool version? Why is the restriction there?

The restriction is there because it's not officially supported. There is exactly zero work done to ensure our MSBuild tasks continues to function on MSBuild 14.0. At this point it's likely to continue doing so as we haven't taken any new API dependencies. Yet there have been several cases where we have considered doing and that definitely would've broken MSBuild 14.0 support.

The restriction exists because we want customers to understand the dependency they are taking here. This package may continue to work in MSBuild 14.0 but it also may not at the very next version. The supported way of using the C# 7.X compiler is to use MSBuild 15.0.

if I remove the restriction and the build apparently works fine is there anything I'm missing - is the compiled code good or not?

The EXEs themselves have no particular MSBuild limitation. They just need the 4.6 framework and they will execute just fine.

why do .exe projects allow us to use .net.compilers 2.4 (but not later), but class library projects only allow 1.3.2 (but not later) all in the same solution?

Not sure what you are asking here.

[PhilPJL]

@jaredpar

why do .exe projects allow us to use .net.compilers 2.4 (but not later), but class library projects only allow 1.3.2 (but not later) all in the same solution?

We have a large solution containing various projects some of which compile to .exe, some to .dll. It appears that for .dll projects using .net.compilers 2.x results in an error but 1.3.2 is ok.
The .exe projects can be build with .net compilers 2.1 - 2.4. Later than 2.4 gives the error.

The supported way of using the C# 7.X compiler is to use MSBuild 15.0.

I would love to use MSBuild 15.0 but still stuck. Out my control. It would be useful if you displayed this as a dependency.

[mihailik]

@jaredpar @PhilPJL that has been reported up on the thread:

https://github.com/dotnet/roslyn/issues/19128#issuecomment-352048471

[mihailik]

The whole point of this nuget package is to allow using a given C# compiler version regardless of the build environment.

Nobody needs no nuget package to build C# if we have latest MSBuild already there.

Please fix this bug urgently, or at least at medium speed.

Alternatively make it clear: is that nuget package no longer supported? is it out of scope? are you intentionally dropping commercial enterprise use cases in favour of all those 347 mobile C# app developers you have across the world?

[jaredpar]

The whole point of this nuget package is to allow using a given C# compiler version regardless of the build environment.

Sorry but that is not an accurate statement. I've explained several times in this thread what our intent is here.

Please fix this bug urgently, or at least at medium speed.

As stated there is no bug here.

Alternatively make it clear: is that nuget package no longer supported?

This package is supported for it's intended use. As stated several times in this thread the package is supported for a particular major version of MSBuild. Any other use is unsupported.

The supported use of the C# 7.0 compiler MSBuild Task is with MSBuild 15.0 and higher.

[mihailik]

@jaredpar the intended use is described quite clearly https://www.nuget.org/packages/Microsoft.Net.Compilers :

Referencing this package will cause the project to be built using the specific version of the C# and Visual Basic compilers contained in the package, as opposed to any system installed version.

But as you've described, that intended purpose impossible to achieve: in order to use latest official C# coming from nuget, you have to have latest official C# installed.

Microsoft.Net.Compilers nuget package
...depends on fresh modern MSBuild,
...which includes fresh modern C# as part of installation.

[mihailik]

The target use case customers are asking for — is to be able to build using latest C# compiler, but without installing anything system-wide.

But instead we are getting wide color choice for our cars: from shiny dark black to jet black. Yeah, thanks for that choice, you must have worked real hard to achieve it.

[jaredpar]

@mihailik

But as you've described, that intended purpose impossible to achieve: in order to use latest official C# coming from nuget, you have to have latest official C# installed.

That is incorrect. You need only MSBuild 15.0 in order to run these binaries. That comes with C# 7.0, the latest is C# 7.2. Additionally this package is also intended to deliver fixes rapidly to customers when we find bugs in say the emit phase of the compiler.

The target use case customers are asking for — is to be able to build using latest C# compiler, but without installing anything system-wide.

That is the target use case a small number of customers are asking for on this thread. It is not the use case this package is intended for which is used by a fairly large number of customers. The use case of "use C# in any MSBuild that has ever shipped" is not a goal of this package.

Yeah, thanks for that choice, you must have worked real hard to achieve it.

How do you feel this is contributing positively to the conversation?

[mihailik]

That is the target use case a small number of customers are asking for on this thread.

Encourage you to look at the issue description at the very top of the page.

May also help to take off the shoes of a Microsoft dev team, and put on those your commercial customers are wearing. In my years of experience toiling in GUI/C# I'd struggle to recall a single case where devs were excited about .1 version features.

Tell you more, during last 10 years not a single interviewee had ever been able to identify a single .1 C# version feature. And I've interviewed for a fair few top financial institutions.

Effectively everybody considers post-LINQ features glorified toys.

Compatibility across major release versions, without needing to install system-wide toolkit — yes, that is a major concern. That is one of the key driving factors delaying upgrade, leaving teams stuck on older platform, and demotivating developers from Microsoft platform. If you can't upgrade your CI without wasting months on approvals, no point even trying any of the newest C# compiler stuff.

How do you feel this is contributing positively to the conversation?

Tons! An honest feedback is a fantastic way to improve vendor's service quality. If you understand and help your customer better, it helps both you, your employer, and the community.

[TheRealWormbo]

For someone who's sort-of stuck with MSBuild v14 (VS2015) for now, and considering there doesn't seem to be any will to continue supporting that version, which version of the Microsoft.Net.Compilers package is the last one to support my available build tools? (I guess that would be 1.3.2?)
Also, regarding the "it's mentioned in the documentation" argument - that doesn't show up in the NuGet description of the package in Visual Studio. And weirdly enough, it doesn't seem to affect all projects.

[jmarolf]

@TheRealWormbo 1.3.2 is the latest version of the roslyn packages that work against MSBuild v14

[biltongza]

@jmarolf So if we want to use Roslyn via the Microsoft.CodeDom.Providers.DotNetCompilerPlatform package, it has framework target dependency on .NET 4.5 which allows us to use 1.3.2. If we target 4.6, then we have to upgrade to 2.4.0 (as of 1.0.8)? So that means on TFS2015 agents we can't use .NET 4.6?

[jmarolf]

@biltongza Microsoft.CodeDom.Providers.DotNetCompilerPlatform version 1.0.8 has this problem. Microsoft.CodeDom.Providers.DotNetCompilerPlatform 2.0.0 should not as that was the main reason they stopped depending on the roslyn compiler package directly, however any deployment issues with that nuget package should be filed on https://github.com/aspnet/RoslynCodeDomProvider

[PhilPJL]

@jmarolf @biltongza
When I started this thread I thought I would soon be moving to TFS 2017. Unfortunately, still stuck on 2013 and TFS Build 2015. However I am now referencing .NET Compilers 2.8.2 and .NET 4.7.1 successfully. I'm currently using DotNetCompilerPlatform 1.0.8 but just about to switch to 2.0.0.
All you need to do is remove this error condition

from Microsoft.Net.Compiler.props. I guess this is 'unsupported' but it's working for now.

The next thing to do is fix the .props file in the DotNetCompilerPlatform package - see https://github.com/aspnet/RoslynCodeDomProvider/issues/52. Then we can set the environment variable 'UseSharedCompilation' to 'true' on your local dev environment (not the build server). For me this gives 5x build speed (yes 500%). See https://github.com/dotnet/roslyn/issues/27975 as well.

[biltongza]

Yesterday I switched over to DotNetCompilerPlatform 2.0.0 and removed Microsoft.Net.Compilers and that made my build agent happy, don't seem to be having any issues yet.

[PhilPJL]

@biltongza Ok interesting. Could tell me which version of TFS build you have, if you have VS 2012 installed and if you have any non-web projects using C#7 features?

[jaredpar]

@PhilPJL

All you need to do is remove this error condition from Microsoft.Net.Compiler.props. I guess this is 'unsupported' but it's working for now.

This check is deliberate as we do not support our package on these versions of MSBuild. The product may at this moment "function" on those versions of MSBuild but that is no guarantee they will continue to work tomorrow, or when you make subtle changes to your build that exercise different parts of our MSBuild package.

[PhilPJL]

@jaredpar I keep nagging away to get our build server updated, but no luck yet. So if it works for now it's better than nothing. I don't want to make life harder for myself, but I notice that Microsoft.CodeDom.Providers.DotNetCompilerPlatform doesn't have the same error condition. You may want to put it in there - and I'll remove it as necessary :)

[biltongza]

@PhilPJL TFS2015 update 3, not using C#7 features (yet). VS2012 not installed.

[rrmora]

You need download TypeScript tool, this is the link: https://www.microsoft.com/en-us/download/details.aspx?id=48593