VS15.5: The "SharedCompilationId" parameter is not supported by the "Csc" task (ASP.NET Web Forms projects)

[vsfeedback]

After updating to Visual Studio 15.5, the two ASP.NET Web Forms projects in our solution are failing to build with the following errors:

29>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets(137,10): error MSB4064: The "SharedCompilationId" parameter is not supported by the "Csc" task. Verify the parameter exists on the task, and it is a settable public instance property.
29>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets(84,5): error MSB4063: The "Csc" task could not be initialized with its input parameters.
I can work around the issue by removing the line SharedCompilationId="$(SharedCompilationId)" from the Csc element in Microsoft.CSharp.Core.targets.

Every project in our solution is using the latest version of Microsoft.Net.Compilers (2.4.0) and the web projects are using the latest version of Microsoft.CodeDom.Providers.DotNetCompilerPlatform (1.0.8). Our ASP.NET MVC and ASP.NET Web API projects are building without issue.

A new Web Forms project with the same Nuget compiler packages installed doesn't exhibit the issue.

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/162531/vs155-the-sharedcompilationid-parameter-is-not-sup.html
VSTS ticketId: 534553
These are the original issue comments:

Bobby Cannon on 12/6/2017, 06:19 PM (54 days ago): I'm having the same issue. My local roslyn is newer (2.6 beta) than what I'm referencing via nuget (2.4 latest stable).
Bobby Cannon on 12/6/2017, 06:21 PM (54 days ago): My web projects references rosyln 2.4 latest stable, however I think VS 15.5 installed 2.6 (beta3) and now I get an error of "The SharedCompilationId parameter is not supported by the csc task"
David Warner on 12/6/2017, 07:28 PM (54 days ago):

Good tip regarding Microsoft.Net.Compilers 2.6.0-beta3 - updating to that package also resolves the issue. I'd rather not be forced to update to a pre-release version of the compiler just to make our solution work in a stable release of Visual Studio, however.

David Warner on 12/6/2017, 07:06 PM (54 days ago):

@Bobby Cannon Are you also seeing this only for Web Forms projects? What's strange is that the same Microsoft.CSharp.Core.targets reference is included in our other CSPROJ files and they're fine.

Candy Zhang [MSFT] on 12/6/2017, 10:13 PM (54 days ago):

We appreciate you taking the time to report this problem. We are currently prioritizing problems that are impacting a broad set of our customers, so we may not be able to investigate this one immediately. We know this problem is important to you, so we will continue to monitor it.

David Warner on 12/7/2017, 03:34 PM (53 days ago):

Is there any indication of when a stable version of Microsoft.Net.Compilers 2.6.0 will be released?

David Warner on 12/10/2017, 07:01 PM (50 days ago):

It looks like 2.6.0 was published soon after I wrote my last comment. We'll target this version to work around the VS15.5 issue.

These are the original issue solutions:
(no solutions)

[BobbyCannon]

Still very interested in this issue being resolved. ;)

[Quppa]

As a general comment it's disappointing that 2 of the last 3 minor releases (15.5 and previously 15.3 - see https://github.com/dotnet/corefx/issues/23229) have broken our (not particularly exotic) solution. This sort of issue means we need to be very careful about updating Visual Studio as there is no way to downgrade.

[jcouv]

Tagging @agocke who likely has some context on SharedCompilationId.

[agocke]

@jaredpar this could be node reuse, combined with using the Microsoft.Net.Compilers package in only some of the projects in the solution. Does that sound possible to you?

[jaredpar]

this could be node reuse, combined with using the Microsoft.Net.Compilers package in only some of the projects in the solution. Does that sound possible to you?

That sounds like what is happening here. I'm not quite sure how to combat this tough. It sounds like in this scenario there are multiple versions of the compiler being brought into a single solution via NuGet and ASP Codedom Provider.

When that happens it's pretty much a race condition as to which C# compiler / msbuild task is going to win. Not sure there is really anything in MSBuild that we can leverage here.

CC @rainersigwald for input.

[AndersMad]

I think I can confirm that: If I uninstall nuget Microsoft.Net.Compilers I no longer get The "EmbedAllSources" parameter is not supported by the "Csc" task in all the solution projects.

[Quppa]

The same thing is happening in Visual Studio 15.6 Preview 4, which appears to include a preview of Rosyln 2.7.0 (csc.exe's version is 2.7.0-beta3-62604).

This time it's the EmbedAllSources parameter that is missing.
C:\Program Files (x86)\Microsoft Visual Studio\Preview\Professional\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets(101,10): error MSB4064: The "EmbedAllSources" parameter is not supported by the "Csc" task. Verify the parameter exists on the task, and it is a settable public instance property.

As before, this only occurs with the ASP.NET Web Forms projects in our solution. All projects in the solution reference version 2.6.0 of the Microsoft.Net.Compilers Nuget package.

[chucker]

I have the same issue in Visual Studio 15.6 Preview 7. Unlike Quppa, this is in several projects of a solution — some WinForms and some WPF; some VB.NET and C#. I haven't been able to figure out what they have in common (possibly referencing COM code?). None of them appear to use the Microsoft.Net.Compilers package.

[tmat]

Seems similar to #25257

[Quppa]

I hope Microsoft.Net.Compilers version 2.7.0 will be pushed in the near future so we can work around this issue - until then, we can't update to Visual Studio 15.6.

[jaredpar]

@Quppa can you elaborate on how this is blocking? The only scenarios where we think this can occur is when a project tries to override the version of the compiler that comes with Visual Studio. If you're waiting for 2.7 to be released to upgrade to 15.6 then the simpler solution would be to no longer try and override the compiler version here. Then it would just work.

[Quppa]

@jaredpar That's a fair point - we don't actually need the Microsoft.Net.Compilers package since all our devs (and build server) are running VS15.5, so we might as well just use the included version of the compiler. However, I just tried removing the Nuget package reference from all the projects in our solution and still encountered the same error regarding EmbedAllSources (as before, only with the ASP.NET Web Forms projects).

We reference Microsoft.CodeDom.Providers.DotNetCompilerPlatform in the Web Forms projects, which has a dependency on Microsoft.Net.Compilers >=2.4.0, so I wonder if this explains why removing the explicit reference to 2.6.0 doesn't solve the issue.

[chucker]

In VS Preview, explicitly referencing Microsoft.Net.Compilers 2.6.1 appears to resolve my issue, even of the projects in the solution use any version of the package.

In VS non-Preview, however, I am oddly not encountering the issue, even though both versions appear to be using 2.7.0-beta3.

[jaredpar]

We reference Microsoft.CodeDom.Providers.DotNetCompilerPlatform in the Web Forms projects, which has a dependency on Microsoft.Net.Compilers >=2.4.0, so I wonder if this explains why removing the explicit reference to 2.6.0 doesn't solve the issue.

That may be the root of the issue. Referencing the CodeDom package is the equivalent of referencing the Microsoft.Net.Compilers package as concerns the issues around EmbedAllSources and SharedCompilationId.

I've poked again asking for the new packages to be published. Longer term though I think we're going to need a feature from MSBuild here to work around this.

[Quppa]

Thanks for following this up.

Deleting EmbedAllSources (and previously SharedCompilationId) from Microsoft.CSharp.Core.targets causes the build to succeed, but is there any danger to this? I presume this means our Web Forms projects are ending up being built by the system compiler version rather than the local Microsoft.Net.Compilers version.

[agocke]

@Quppa I'm worried that either that will break when you update something else, or that NuGet restore will just bring down old files (or, if you're pulling from VS, a new VS update will just overwrite the old files).

I may be misremembering how it works, but could you just also delete the Microsoft.CodeDom.Providers.DotNetCompilerPlatform package? Wouldn't that just cause the Web Forms project to pull in the machine compiler, thus resolving the versioning difference problem?

[Quppa]

@agocke I mean the Microsoft.CSharp.Core.targets stored in C:\Program Files (x86)\Microsoft Visual Studio\2017\<VisualStudioEdition>\MSBuild\15.0\Bin\Roslyn, so yes, it will presumably be reset with the next Visual Studio update, but in the meantime it lets me build locally.

We rely on Microsoft.CodeDom.Providers.DotNetCompilerPlatform to enable support for newer C# features in ASP.NET files, so I can't just remove that package.

[chucker]

That depends on Microsoft.Net.Compilers (>= 2.4.0), so 2.6.1 should satisfy that requirement. Have you tried adding that package reference explicitly?

[Quppa]

Sure, but I thought EmbedAllSources was added in 2.7.0, so that wouldn't help.

Come to mention it, could the parameter possibly be part of 2.6.1? I haven't actually tried that version yet - I just assumed I needed 2.7.0 since that's the build included in VS15.6. I'll try it out.

[chucker]

You're probably right. VS 15.6 final appears to ship with 2.7.0-beta3, and the build parameter was committed Dec 8 and merged Jan 4. 2.6.1, OTOH, has some backported fixes, but was tagged on Dec 5, before the commit.

However, there's now a tag for 2.7.0-beta3 (as of just ten hours ago), so they're probably about to push a newer NuGet package. It strikes me as odd that a final VS would ship with a beta compilers package?

[Quppa]

I did wonder about that, too, but VS15.5 shipped with 2.6.0-beta3, so it's not without precedent.

I just tried and failed to make a minimal repro with a new Web Forms project, so I'll take the opposite approach of deleting code from our existing codebase until it works.

[saschanm]

Updating Microsoft.CodeDom.Providers.DotNetCompilerPlatform to 1.0.8 and Microsoft.Net.Compilers 2.7 (available as of 8hrs ago) solved this for me.

[Quppa]

Here's a fairly minimal csproj file that reproduces the issue: https://gist.github.com/Quppa/dae4eacf58d9b23009bcc447b4d9cb93

Probably the key lines are:

<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />

and

<PackageReference Include="Microsoft.CodeDom.Providers.DotNetCompilerPlatform">
  <Version>1.0.8</Version>
</PackageReference>

[jaredpar]

@saschanm, @Quppa thanks for getting that minimal repo together. That confirms my suspicion that this is an issue in the DotNetCompilerPlatform package.

I think we should move this issue over to the https://github.com/aspnet/RoslynCodeDomProvider repository as this is where that package is built.

[jaredpar]

Migrating issue to aspnet/RoslynCodeDomProvider#33

[Quppa]

Upon further investigation the issue is that our csproj files were missing this line:
<Import Project="..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" />

Microsoft.Net.Compilers.props sets the value of CSharpCoreTargetsPath, which appears to override the <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" /> line.

The above import is included for a new ASP.NET Web Forms project, and I'm not quite sure how we ended up without it. This might have been a casualty of our conversion from packages.config to PackageReference - I thought maybe the csproj modification was happening in install.ps1 (unsupported by PackageReference), but I can't actually see what does it.

Creating a new project produces a csproj with these lines at the top:

  <Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
  <Import Project="..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" />

and at the bottom:

  <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
    <PropertyGroup>
      <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    </PropertyGroup>
    <Error Condition="!Exists('..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props'))" />
    <Error Condition="!Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
  </Target>

[mrnams]

Install-Package Microsoft.Net.Compilers -Version 2.8.2
This will solve above mentioned error

[RDavis3000]

Apologies if this is not valuable.
I encountered this error trying to complie the Auth0 quick start project for .Net Core 2.0.

It doesn't reference the Microsoft.Net.Compilers package at all. Just Microsoft.AspNetCore.App and Microsoft.VisualStudio.Web.CodeGeneration.

I was not able to build from VS2017, but 'dotnet run' worked fine!

The workaround was to "Install-Package Microsoft.Net.Compilers -Version 2.8.2" but this seems pretty ugly and hopefully a real solution will be forthcoming.

[fxpatrick]

@mrnams thank you, works like a charm