Roslyn: MSB4062 Assembly with same name already loaded for DotNetCompilerPlatform NuGet

[jamescrowley]

Apologies if this is not the correct repo - came here via the DotNetCompilerPlatform NuGet package that we're consuming to use C# 7 in our MVC razor views. Switching to the 'dotnet build' toolchain but can't get our project to compile due to issues with this NuGet

Version Used:

Microsoft.CodeDom.Providers.DotNetCompilerPlatform (1.0.7)
Microsoft.Net.Compilers (2.3.2)
.NET Core SDK 2.0.2

Steps to Reproduce:

1. From an ASP.NET MVC 5 project with the following in the project file:

<Import Project="..\..\packages\Microsoft.Net.Compilers\build\Microsoft.Net.Compilers.props" Condition="Exists('..\..\packages\Microsoft.Net.Compilers\build\Microsoft.Net.Compilers.props')" />

and this in the web.config:

<system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.7.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:7 /nowarn:1659;1699;1701" /> </compilers> </system.codedom>

1. Run a build using "dotnet build" (rather than the old msbuild toolchain).

Expected Behavior:

Project should compile

Actual Behavior:

I get

C:\DevelopmentXX\packages\Microsoft.Net.Compilers\tools\Microsoft.CSharp.Core.targets(84,5): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded from the assembly C:\DevelopmentXX\packages\Microsoft.Net.Compilers\build..\tools\Microsoft.Build.Tasks.CodeAnalysis.dll. Assembly with same name is already loaded Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

This fails every time on a clean build, but passes on a 'dirty' build.

Any ideas how I can track this down further?

[jamescrowley]

Closing as I believe this is due to a bug in the NuGet restoration process instead.

[AdamPew]

Have you managed to find any solutions for the first build error issue?

[jamescrowley]

@AdamPew no, I got blocked by this and was intending to come back and try again at a later stage.

[nattress]

I saw this issue today and it happens when MSBuild nodes are recycled and load a different version of the same assembly from two different projects being compiled in parallel. Passing /nodeReuse:false to msbuild fixes this for me.

[Pegolon]

Had the same problem with dotnet build / publish on the commandline on a Mac. Since msbuild is used by dotnet build you can also pass the /nodeReuse:false as an additional commandline parameter, like dotnet build /nodeReuse:false which fixed my problem, too. Thanks @nattress for the hint, saved my day.

[fluffynuts]

I've had the same problem -- more than once. This can especially happen if you have, eg, more than one solution open, and they use different compiler versions (eg one uses Microsoft.Net.Compilers, and another doesn't). One would see an error like:

 error MSB4062: The "Microsoft.CodeAnalysis
.BuildTasks.Csc" task could not be loaded from the assembly [user home]\.nuget\packages\microsoft.net.compilers\3.3.1\build\..\tools\Microsoft.
Build.Tasks.CodeAnalysis.dll. Assembly with same name is already loaded Confirm that the <UsingTask> declaration is correct, that the assembly and all it
s dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

I've also seen this happen when I have multiple projects open in an IDE (or building at CI) where one is, eg, a legacy MVC application targeting net462 and the other is a modern asp.net core application targeting netcoreapp[X].

I've been bitten before on a CI server by this. It seems like nodeReuse should be _opt-in_ instead of _opt-out_: reliability should trump performance any day. It's gotten to the point where I've had to opt out for all of my build scripts to avoid this kind of confusion.