dotnet build raise error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded from the assembly #1173

[moh-hassan]

This question was asked in dotnet project then advised to move it here.

Environment
vs2019 v16.4.0 is installed
last netcore 3.1.100 is installed.
Console project.csproj SDK style , net461
reference a class library project netstandard2.0, net461
The class library reference the package: Microsoft.Net.Compilers.Toolset v 3.4.0 to support c# 8 nullable in VS2017 .

Building the project using vs2019 IDE success.
Building the project using msbuild command success.: msbuild /t:build
Building the project using dotnet build fail with the error

error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded from the assembly C:\Program Files\dotnet\sdk\3.1.100\Roslyn\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. [F:\experiment\test.csproj]

Removing the package "Microsoft.Net.Compilers.Toolset and run dotnet build success.

How to stop this error in dotnet build?

[QuellaZhang]

Hello, anyone can help me? I encountered the same issues.

Build step:
git clone git clone https://github.com/dotnet/runtime.git F:\gitP\dotnet\runtime
cd F:\gitP\dotnet\runtime\src\coreclr
set ___SDKVersion="-DCMAKE_SYSTEM_VERSION=10.0.17763.0"
.\build.cmd x86 release -- /clp:ShowCommandLine > build.log
.\build-test.cmd x86 release -- /clp:ShowCommandLine > buildTest.log

F:\gitP\dotnet\runtime.dotnet\sdk\5.0.100-alpha1-015772\Roslyn\Microsoft.CSharp.Core.targets(59,5): error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded from the assembly F:\gitP\dotnet\runtime.dotnet\sdk\5.0.100-alpha1-015772\Roslyn\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.

[jaredpar]

@moh-hassan

The class library reference the package: Microsoft.Net.Compilers.Toolset v 3.4.0 to support c# 8 nullable in VS2017 .

This is not the intended use of this package. That package is meant to be used to deliver bits between .NET repositories and to hot fix issues on customer machines. It's not meant to be used to allow for using C# 8 features, such as nullable, in previous versions of Visual Studio.

True it can often be used to create this effect but it's not a behavior that we designed the package for. There are a number of corner cases around this scenario that do not work.

error MSB4062: The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded from the assembly C:\Program Files\dotnet\sdk\3.1.100\Roslyn\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. [F:\experiment\test.csproj]

This occurs because the MSBuild process is attempting to load the csc task from two different locations:

1. The Csc task installed with the .NET SDK
2. The Csc task that comes with the Microsoft.Net.Compilers.Toolset package

The dotnet build process does not support loading a task from two different locations and hence you run into this error (see dotnet/msbuild#1754 for more info).

This is another reason why this package isn't supported for general purpose usage and geared towards hot fixes.

[moh-hassan]

@jaredpar

True it can often be used to create this effect but it's not a behavior that we designed the package for.

The documentation didn't mention any limitation for the package.
from documentation:

This package contains the C# and Visual Basic compiler toolset for .NET Desktop and .NET Core. This includes the compilers, msbuild tasks and targets files. When installed in a project this will override the compiler toolset installed in MSBuild.

Note: this package is intended as a replacement for Microsoft.Net.Compilers (which is a Windows-only package) and Microsoft.NETCore.Compilers. Those packages are now deprecated and will be deleted in the future.

Version 3.1 includes a preview of C# 8.0 (Visual Studio 2019 version 16.1)
Version 3.2 includes a preview of C# 8.0 (Visual Studio 2019 version 16.2)
Version 3.3 includes C# 8.0 (Visual Studio 2019 version 16.3, .NET Core 3.0)
Version 3.4 includes C# 8.0 (Visual Studio 2019 version 16.4, .NET Core 3.1)

As you said,

This occurs because the MSBuild process is attempting to load the csc task from two different locations:

The Csc task installed with the .NET SDK
The Csc task that comes with the Microsoft.Net.Compilers.Toolset package

But the build success with MSBuild.

in my post:

Building the project using vs2019 IDE success.
Building the project using msbuild command success.: msbuild /t:build

so, why success here and fail with dotnet build.

Some projects use this package with vs2017 image in appveyor to build in c#8 with Nullable reference types (without moving to vs 2019).

Please

• Modify the documentation and mention the limitation and scope of use of this package.

[jaredpar]

@moh-hassan

The documentation didn't mention any limitation for the package.
from documentation:

The WIKI is out of date. I've updated it to have the relevant information.

The official documentation on the NuGet Gallery has the relevant lines:

This package is primarily intended as a method for rapidly shipping hotfixes to customers. Using it as a long term solution for providing newer compilers on older MSBuild installations is explicitly not supported. That can and will break on a regular basis.

As for

But the build success with MSBuild.

That's due to differences in how .NET Desktop and .NET Core work with respect to assembly loading. In .NET Desktop it's possible for two assemblies with the same name but different versions and strong name signed to load into the same AppDomain. The same is not true of .NET Core where only one assembly with a given name, irrespective of version, can be loaded into an AssemblyLoadContext.

Our Csc task is contained in an assembly that meets those specifications. Hence with MSBuild, which uses .NET Desktop, the different versions load into the process without any real issue. On dotnet build though, which uses .NET Core, the assemblies cannot both be loaded into the same process and you get the MSB4062 error.

[moh-hassan]

Thanks @jaredpar
Now it's clear.