.NET Core SDK 3.1.200 breaks build which is using GitVersionTask

Question

.NET Core SDK 3.1.200 breaks build which is using GitVersionTask

mconnew opened this issue 5 years ago · 16 comments

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]

Answer 1 · 2020-03-17T18:45:52.000Z

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?

Answer 2 · 2020-03-17T19:54:07.000Z

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

Answer 3 · 2020-03-18T02:04:04.000Z

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

Answer 4 · 2020-03-18T11:25:48.000Z

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

I'll pursue them on their individual bugs.

Answer 5 · 2020-03-18T19:17:27.000Z

@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.

Answer 6 · 2020-03-27T10:23:13.000Z

experiencing the same issue here.

Answer 7 · 2020-04-01T19:34:57.000Z

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
...

Answer 8 · 2020-04-01T20:00:53.000Z

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

Answer 9 · 2020-04-05T10:43:43.000Z

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".

Answer 10 · 2020-04-06T14:32:29.000Z

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

@onyxmaster can you elaborate on that, please?

Answer 11 · 2020-04-06T16:02:40.000Z

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.

Answer 12 · 2020-04-06T21:20:53.000Z

@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.

Answer 13 · 2020-04-06T22:17:20.000Z

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

Answer 14 · 2020-04-07T06:57:55.000Z

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

Answer 15 · 2020-04-07T06:58:44.000Z

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.

Answer 16 · 2020-05-26T16:13:38.000Z

Tracked by dotnet/msbuild#5202