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 #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?