.NET Core SDK 3.1.200 breaks build which is using GitVersionTask

[mconnew]

Using GitVersionTask 5.1.2 with CoreWCF builds successfully with .NET Core SDK 3.1.101, but when the SDK was updated by a recent VS update, it broke the build. I have also tried GitVersion 5.1.3 and the latest 5.2.3 with the same result. Reinstalling .NET Core SDK 3.1.101 (as VS updater removes it) and adding a global.json file to specify using that version of the SDK results in the build succeeding again. Here is the error message I get from the build:

 error MSB4018: The "WriteVersionInfoToBuildLog" task failed unexpectedly. [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018: System.TypeInitializationException: The type initializer for 'GitVersion.MSBuildTask.TaskProxy' threw an exception. [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:  ---> System.IO.FileNotFoundException: Could not load file or assembly 'GitVersionTask.MsBuild, Version=5.1.3.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified. [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018: File name: 'GitVersionTask.MsBuild, Version=5.1.3.0, Culture=neutral, PublicKeyToken=null' [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:  ---> System.IO.FileNotFoundException: Could not load file or assembly 'GitVersionTask.MsBuild, Version=5.1.3.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified. [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018: File name: 'GitVersionTask.MsBuild, Version=5.1.3.0, Culture=neutral, PublicKeyToken=null' [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, RuntimeAssembly assemblyContext, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, AssemblyLoadContext assemblyLoadContext) [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, StackCrawlMark& stackMark, AssemblyLoadContext assemblyLoadContext) [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at System.Reflection.Assembly.Load(AssemblyName assemblyRef, StackCrawlMark& stackMark, AssemblyLoadContext assemblyLoadContext) [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyName(AssemblyName assemblyName) [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at GitVersion.MSBuildTask.LibGit2Sharp.GitLoaderContext.Load(AssemblyName assemblyName) in D:\a\1\s\src\GitVersionTask.MsBuild\LibGit2Sharp\GitLoaderContext.cs:line 30 [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(AssemblyName assemblyName) [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName) [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:  [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:  [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at System.Reflection.RuntimeAssembly.GetType(QCallAssembly assembly, String name, Boolean throwOnError, Boolean ignoreCase, ObjectHandleOnStack type, ObjectHandleOnStack keepAlive, ObjectHandleOnStack assemblyLoadContext) [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at System.Reflection.RuntimeAssembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase) [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at System.Reflection.Assembly.GetType(String name, Boolean throwOnError) [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at GitVersion.MSBuildTask.TaskProxy..cctor() in D:\a\1\s\src\GitVersionTask.MsBuild\TaskProxy.cs:line 22 [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:  [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:  [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    --- End of inner exception stack trace --- [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at GitVersion.MSBuildTask.Tasks.WriteVersionInfoToBuildLog.Execute() in D:\a\1\s\src\GitVersionTask.MsBuild\Tasks\WriteVersionInfoToBuildLog.cs:line 5 [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]
 error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [C:\git\CoreWCF\src\CoreWCF.Primitives\src\CoreWCF.Primitives.csproj]

[SabotageAndi]

I think we in SpecFlow (https://github.com/SpecFlowOSS/SpecFlow/) have a similar issue.
If you compile the master with SDK 3.1.102, everything works. If you use 3.1.200, we will get errors in our MSBuild task, which loads dynamically .NET Standard 2.0 assemblies.

As this MSBuild task is used by our users, they are also broken if they use the new SDK.
The issue for it is here: SpecFlowOSS/SpecFlow#1912

Are we doing something wrong, what worked by accident in the past? Is there something broken?

[dasMulli]

One of the things that changed in .200 is how msbuild loads tasks - dotnet/msbuild#4916
cc @rainersigwald

[dasMulli]

You could set MSBUILDSINGLELOADCONTEXT=1 and see if that escape hatch works for you

[rainersigwald]

I'll assign this bug to me, but for now it looks like there are two different failure cases:

• the combination of VS 2019 Version 16.5.0 Preview 2.0 and .NET Core 3.1.200-preview-014883 fails dotnet build GitTools/GitVersion#2063
• SpecFlow doesn't work with .NET Core 3.1.200 SDK SpecFlowOSS/SpecFlow#1912

I'll pursue them on their individual bugs.

[mconnew]

@rainersigwald, just an FYI using assembly load context will break anyone who is using XmlSerializer or DataContractSerializer. It will break anyone who if using RefEmit and referencing types loaded in the ALC.

[bonesoul]

experiencing the same issue here.

[bkragl]

What could be the reason that the workaround with MSBUILDSINGLELOADCONTEXT=1 works on one of my machines, but not the other? Both have exactly the same .NET Core SDK installed.

On this Ubuntu 16.04 machine it works.

> dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.201
 Commit:    b1768b4ae7

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.201/

Host (useful for support):
  Version: 3.1.3
  Commit:  4a9f85e9f8
...

On this Ubuntu 18.04 machine the build still fails.

> dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.201
 Commit:    b1768b4ae7

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  18.04
 OS Platform: Linux
 RID:         ubuntu.18.04-x64
 Base Path:   /usr/share/dotnet/sdk/3.1.201/

Host (useful for support):
  Version: 3.1.3
  Commit:  4a9f85e9f8
...

[dasMulli]

Can you try a dotnet build-server shutdown before the run with changed ENV var to make sure there are no leftover msbuild nodes?

[onyxmaster]

Well, the workaround with MSBUILDSINGLELOADCONTEXT=1 works, but is this considered a bug that is going to be fixed?
If I understand this correctly, for example no Fody weaver would work. Being required to force the specific SDK version (especially not the one shipped with latest VS) or adding envvars in build scripts and Dockerfiles to fix build that magically broke overnight isn't exactly what I call "backwards compatible release".

[rainersigwald]

If I understand this correctly, for example no Fody weaver would work.

@onyxmaster can you elaborate on that, please?

[onyxmaster]

If I understand this correctly, for example no Fody weaver would work.

@onyxmaster can you elaborate on that, please?

Sure, thanks for looking into this. Please see the repro.

[rainersigwald]

@onyxmaster Thanks! This appears to have been fixed in Fody 6.0.4, probably by Fody/Fody@7f4f425. I was able to get your repro working by forcing an updated ref:

diff --git a/Independent.csproj b/Independent.csproj
index c915944..294ba7b 100644
--- a/Independent.csproj
+++ b/Independent.csproj
@@ -5,5 +5,6 @@
 
   <ItemGroup>
     <PackageReference Include="ModuleInit.Fody" Version="2.1.0" PrivateAssets="all"/>
+    <PackageReference Include="Fody" Version="6.0.4" PrivateAssets="all"/>
   </ItemGroup>
 </Project>

FYI @SimonCropp.

[SimonCropp]

thats why every fody addin has this explicitly in the readme

The Install-Package Fody is required since NuGet always defaults to the oldest, and most buggy, version of any dependency.

https://github.com/Fody/ModuleInit#nuget-installation

[onyxmaster]

@onyxmaster Thanks! This appears to have been fixed in Fody 6.0.4, probably by Fody/Fody@7f4f425.
Thank you very much!

[onyxmaster]

thats why every fody addin has this explicitly in the readme

The Install-Package Fody is required since NuGet always defaults to the oldest, and most buggy, version of any dependency.
Thanks, Simon, well this isn't the first time the transitive dependency is biting me in the back, I hope it would be the last one.

[rainersigwald]

Tracked by dotnet/msbuild#5202