[Bug] FileNotFoundException: The file or assembly "System.Runtime, Version = 5.0.0.0" or a dependency on it was not found.

[SeppPenner]

Describe the bug

When building my project with the latest GitVersion.MsBuild and after the workaround described in #2502 (I have added the following snippet as fallback for the C:\Users\Nutzer\.nuget\packages\gitversion.msbuild\5.6.1\tools\GitVersion.MsBuild.props file):

<PropertyGroup Condition="'$(GitVersionFileExe)' == ''">
    <GitVersionFileExe>dotnet $(MSBuildThisFileDirectory)net5.0/gitversion.dll</GitVersionFileExe>
    <GitVersionAssemblyFile>$(MSBuildThisFileDirectory)net5.0/GitVersion.MsBuild.dll</GitVersionAssemblyFile>
</PropertyGroup>

In the command line, the build runs properly when using dotnet build.

Expected Behavior

The build in Visual Studio should just work normally.

Actual Behavior

Build fails with error message:

FileNotFoundException: The file or assembly "System.Runtime, Version = 5.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" or a dependency on it was not found. The system can not find the stated file.
    at GitVersion.MsBuild.GitVersionTasks.BuildServiceProvider (GitVersionTaskBase task)
    at GitVersion.MsBuild.GitVersionTasks.ExecuteGitVersionTask [T] (T task, Action`1 action) in D:\a\GitVersion\GitVersion\src\GitVersion.MsBuild\GitVersionTasks.cs: line 24.
ExampleProject C:\Users\Users\.nuget\packages\gitversion.msbuild\5.6.1\tools\GitVersion.MsBuild.targets

Fun fact: I have no idea why it wants to access the folder D:\a\GitVersion\ (D is my secondary drive which is used for nothing at all at the moment and the folder called a doesn't even exist).

Possible Fix

No idea.

Steps to Reproduce

I have upgraded my projects from netcoreapp3.1 to net5.0 and switched from GitVersionTask to GitVersion.MsBuild. The project is an ASP.Net Blazor server side project (If this is relevant).

Context

Regular / daily work.

Your Environment

• ASP.Net Blazor server side project.
• GitVersion.MsBuild Version: 5.6.1
• Net Version: .Net 5.0
• ASP.NET Core libraries version: 5.0.1
• Visual Studio Community 2019, 16.8.30804.86
• dotnet --info:

.NET SDK (gemäß "global.json"):
 Version:   5.0.101
 Commit:    d05174dc5a

Laufzeitumgebung:
 OS Name:     Windows
 OS Version:  10.0.19041
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.101\

Host (useful for support):
  Version: 5.0.1
  Commit:  b02e13abab

.NET SDKs installed:
  2.1.806 [C:\Program Files\dotnet\sdk]
  3.1.201 [C:\Program Files\dotnet\sdk]
  3.1.202 [C:\Program Files\dotnet\sdk]
  3.1.300 [C:\Program Files\dotnet\sdk]
  3.1.402 [C:\Program Files\dotnet\sdk]
  5.0.100 [C:\Program Files\dotnet\sdk]
  5.0.101 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.18 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.18 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.18 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[bddckr]

Fun fact: I have no idea why it wants to access the folder D:\a\GitVersion\ (D is my secondary drive which is used for nothing at all at the moment and the folder called a doesn't even exist).

That's just the location of the source from the build machine that built the used GitVersion release - what we see here is GitVersion failing in its implementation of the MSBuild task from its dll that was loaded into MSBuild.

---

I've been getting this same issue repeatedly now. It's sometimes gone completely, other times you can just build again and it will fix itself.

In my case I have multiple Xamarin projects (which use the old non-SDK-style project system), as well as a .NET 5.0 project all in the same solution. All projects use GitVersion, via the MSBuild package.

It seems like it's due to concurrent project builds, which explains why I can get it to work by repeatedly building: I only build a single project when I got hit by the bug, one after the other.

Here's a workaround:
Close Visual Studio and edit %userprofile%\.nuget\packages\gitversion.msbuild\5.6.1\tools\GitVersion.MsBuild.props to only use the net48 dlls and exe (I build with the Full and Mono MSBuild tooling only).

I wonder if we're looking at a case of the MSBuild nodes getting reused and not liking the idea to load multiple different versions of the dependency dlls of the GitVersion tasks into memory... That could explain why building non-concurrently works perhaps. Now I'm wondering if this and #2502 basically mean we have to ensure only one set of MSBuild task dlls is used by GitVersion.

[SeppPenner]

That's just the location of the source from the build machine that built the used GitVersion release - what we see here is GitVersion failing in its implementation of the MSBuild task from its dll that was loaded into MSBuild.

Ah, okay.

Here's a workaround:
Closed Visual Studio and edit %userprofile%.nuget\packages\gitversion.msbuild\5.6.1\tools\GitVersion.MsBuild.props to only use the net48 dlls and exe (I build with the Full and Mono MSBuild tooling only).

For me, it would mean to use only Net5, I guess :D Framework 4.8 won't compile my projects either way. I will try that.

I wonder if we're looking at a case of the MSBuild nodes getting reused and not liking the idea to load multiple different versions of the dependency dlls of the GitVersion tasks into memory... That could explain why building non-concurrently works perhaps. Now I'm wondering if this and #2502 basically mean we have to ensure only one set of MSBuild task dlls is used by GitVersion.

Quite difficult to find if that is the issue :)

[bddckr]

For me, it would mean to use only Net5, I guess :D Framework 4.8 won't compile my projects either way. I will try that.

This is all only used in MSBuild! So at compile-time only the MSBuild tooling will

1. Load GitVersion's dlls into the process(es) MSBuild spawns to build your project(s).
2. Run the specified exe from GitVersion.

So if your dev/build machine has .NET Framework 4.8 installed this will all work. There's no relationship to what your projects use.

But you're right there... As folks will want a cross-platform solution we should aim for .NET Core or 5.0+ 😄

---

I've added a suggestion to the linked issue. Let me know if the workaround works for you (using .NET 5 in your case)!

[SeppPenner]

So if your dev/build machine has .NET Framework 4.8 installed this will all work. There's no relationship to what your projects use.

Oh, of course. My mistake :D

I've added a suggestion to the linked issue. Let me know if the workaround works for you (using .NET 5 in your case)!

I have now tried to run it with netframework 4.8 inside Visual Studio and can confirm that it works. :)

On our build server, things will get a bit more difficult as it runs a docker image based on sdk:5.0-buster-slim, but I will check this as well.