[BUG]: .NET 8.0 - MSB4062 The "WriteVersionInfoToBuildLog" task could not be loaded - reloaded

[sanghel-orbyta]

Prerequisites

• I have written a descriptive issue title
• I have searched issues to ensure it has not already been reported

GitVersion package

GitVersion.MsBuild

GitVersion version

6.0.0

Operating system

Windows

What are you seeing?

I'm seeing the error:

D:\packages\.nuget\gitversion.msbuild\6.0.0\tools\GitVersion.MsBuild.targets(25,9):
error MSB4062: The "WriteVersionInfoToBuildLog" task could not be loaded from the assembly
D:\packages\.nuget\gitversion.msbuild\6.0.0\tools\net8.0\GitVersion.MsBuild.dll.
Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' 
or one of its dependencies.
The system cannot find the file specified.
Confirm that the <UsingTask> declaration...

#3787 and #3704 suggest that after the betas, version 6.0.0 should work with .NET 8.

After the above error is triggered, even reverting to 5.12.0 yields:

MSB4062	The "WriteVersionInfoToBuildLog" task could not be loaded from the assembly
D:\packages\.nuget\gitversion.msbuild\5.12.0\tools\net48/GitVersion.MsBuild.dll.
Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> .....

which weirdly tries to use net48, even though I'm not on the .NET Framework anywhere in my solution.

When the error is triggered, the only way to recover (remaining on 5.12.0) is to close and re-open solution (I'm not sure but it seems the error leaves a dotnet.exe process.. )

What is expected?

Task works as with version 5.12.0

Steps to Reproduce

With:

**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.10.4
**********************************************************************
dotnet msbuild -version
MSBuild version 17.10.4+10fbfbf2e for .NET
17.10.4.21802

dotnet --info
.NET SDK:
 Version:           8.0.303
 Commit:            29ab8e3268
 Workload version:  8.0.300-manifests.34944930
 MSBuild version:   17.10.4+10fbfbf2e

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22631
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\8.0.303\

.NET workloads installed:
.... omitted ....

Host:
  Version:      8.0.7
  Architecture: x64
  Commit:       2aade6beb0

.NET SDKs installed:
  8.0.303 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

My csproj has:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <LangVersion>latest</LangVersion>
    <NoWarn>$(NoWarn);CS1591</NoWarn>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <GenerateDocumentationFile>true</GenerateDocumentationFile>
  </PropertyGroup>

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>

  <PropertyGroup>
    <WriteVersionInfoToBuildLog>true</WriteVersionInfoToBuildLog>
    <UpdateAssemblyInfo>true</UpdateAssemblyInfo>
    <GenerateGitVersionInformation>true</GenerateGitVersionInformation>
    <GetVersion>true</GetVersion>
    <GenerateGitVersionWixDefines>false</GenerateGitVersionWixDefines>
    <UpdateVersionProperties>true</UpdateVersionProperties>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="GitVersion.MsBuild" Version="6.0.0">
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>

</Project>

RepositoryFixture Test

No response

Output log or link to your CI build (if appropriate).

No response

[Szaamaan]

I'm guessing you're using VS due to the Visual Studio 2022 Developer Command Prompt v17.10.4 header visible in one of your logs?

Apparently the GitVersion team dropped support for Visual Studio entirely, regardless of the target framework being used. 😕 Or at least that's the way I understand the replies...

[sanghel-orbyta]

@Szaamaan , you're seeing that header because that's the CLI I've used to output local versions of msbuild, sdk, ecc..

But yes, I'm using VS2022., but I'm not trying to use GitVersion with anything .NET Framework related, I'm all on .NET 8.

[Szaamaan]

@Szaamaan , you're seeing that header because that's the CLI I've used to output local versions of msbuild, sdk, ecc..

But yes, I'm using VS2022., but I'm not trying to use GitVersion with anything .NET Framework related, I'm all on .NET 8.

Yes, I know. But despite this, apparently, something doesn't work quite the same way with Visual Studio's msbuild vs the one that's used by dotnet. The end result is that you can have the simplest "hello world" console app targeting the latest NET 8.0 and it just won't compile under Visual Studio if you add GitVersion.MsBuild and reference GitVersionInformation.

On that note - do you get the same results if you run dotnet build outside of the VS Command line (i.e. run it from a regular Powershell / CMD)?

[sanghel-orbyta]

I've just tried building with 6.0.0 via dotnet build from project folder.
...build fails with 3 occurrences of

error CS0579: Duplicate 'System.Reflection.AssemblyFileVersionAttribute' attribute

Reverting to 5.12.0 builds correctly (with both VS and from terminal dotnet build)...

Maybe it's me, but 6.0.0 doesn't seem "RTM"-ready....
Without the MSBuild version working correctly, there is no version retrieval at runtime as illustrated in the Accessing injected Variables section here.

I'm staying on 5.12.0, hoping that these issues might be fixed...

[M0n7y5]

I have the same issue. MSBuild task won't generate static GitVersionInformation class. I can't compile any of my projects after upgrading from 5.12.0 to 6.x.x.

[ashleyjlive]

Same issue here. 6.0.0 and 6.0.1 are both faulty.

[sanghel-orbyta]

@ashleyjlive any chance you could retry it with 6.0.2, just to keep this issue relevant?

[AnrovaJens]

@sanghel-orbyta I've got the same issue with VS 2022 and .NET 8.0 and version 6.0.2 didn't resolve this for me.

[arturcic]

@ashleyjlive any chance you could retry it with 6.0.2, just to keep this issue relevant?

If an issue is closed and there is a comment similar to #4157 (comment), only in that case the issue is considered fixed, or if we explicitly mention. At this moment VS is not supported because of the reasons mentioned #4130. Hopefully we will have the time to find a solution, but at this point if you need to use the MsBuild package together with Visual Studio I would recommend to stick to version 5.12.0 for now

[M0n7y5]

@ashleyjlive any chance you could retry it with 6.0.2, just to keep this issue relevant?

Tested with 6.0.2 -> Still an issue. I have the same error but for GenerateGitVersionInformation

My error is:

GitVersion.MsBuild.targets(105,9): error MSB4062: The "GenerateGitVersionInformation" task could not be loaded from the assembly 
C:\Users\REDACTED\.nuget\packages\gitversion.msbuild\6.0.2\tools\net8.0\GitVersion.MsBuild.dll.
Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. 
The system cannot find the file specified. Confirm that the <UsingTask> 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.

Many things inside GitVersion.MsBuild.targets are undefined for some reason:

[RobSmyth]

@ashleyjlive - I was able to work around that by adding to the csproj:

<WriteVersionInfoToBuildLog>false</WriteVersionInfoToBuildLog>

I have it (I think) working a project but not another. See also: #4130

[RobSmyth]

Wow ... I misunderstood the "not supported" as "we do not have the time". But alas it has actually explicitly been removed (my bad). This is from the props file:

   <!-- The GitVersion task is explicitly disabled when running on the .NET Framework because it's no longer supported. 
   If a project that uses GitVersion.MsBuild is opened in Visual Studio, 
   the task will be turned off because Visual Studio operates on the .NET Framework's version of MSBuild. 
   However, you can still execute GitVersion.MsBuild as part of the `dotnet build` or `dotnet msbuild` commands. -->
   <DisableGitVersionTask Condition=" '$(MSBuildRuntimeType)' != 'Core' ">true</DisableGitVersionTask>

I now see it in the breaking changes (good). Missed it before. :-(

@arturcic - Perhaps the GitVersion site (https://gitversion.net/docs/usage/msbuild) should mention GitVersion.MSBuild's Visual Studio retirement . Could save a lot of time.

I think there is a big difference between a bug that may take a while to fix and a retirement of support for Visual Studio.

Is there any point looking into it if the team does not plan to support VS?

[RobSmyth]

BTW - .NET Framework support is not actually required to work in VS. As a minimum it needs to support .NET Standard 2.0 and that was removed in 6.0.0.

[RobSmyth]

@arturcic - had a bit more of a look and I think the .NET Standard 2.0 support, and hence Visual Studio support, was dropped in a commit Jan 9, 2023 (merged Feb 18, 2023). There is another possibly related commit Nov 6, 2023. I think, these are your commits. Can you tell me if loss of VS support was a side affect here or intentional?

It looks like it may be a clean-up moving stuff to the root folder.

Commits:

• Dropping .NET standard 2.0: bdcfd1b
• Possibly related: 0fa6c70

Thanks

[arturcic]

@RobSmyth the idea was we wanted to start using the new APIs in the newer versions of .NET and targeting netstandard put too much maintenance on us. Same for the .net framework. Then we saw it was broken in VS and we had to decide to either spend time on building new features, take advantage of new APIs, or be stuck on netstandard.

At this point netstandard was needed mainly for GitVersion.MsBuild package which is not the most used package we publish, it's like 5% of the usage and was like 60% or so of the effort.

That still does not mean we will not get back to this issue at some point, but that will take time, and it will require a different approach

[RobSmyth]

Thanks @arturcic - Shame but I understand. Blocker for me as I've always seen the dotnet tool approach as a workaround and would rather see MSBuild do it. Also kills a project I was about to release GitVersion.Afterburner!! :-)

That clarifies it so i'll do something else.

But ... I do think it would be good to update both the breaking changes and also the site. Not supporting .NET 4.8 does not read as "Dropped VS support". It will save a lot of angst making it clear.

Thanks :-)

[tammha]

Hi everyone, I have just come across GitVersion as we are planning to use this with our company projects.
I downloaded 6.0.2 and all seems working fine via dotnet build. However if I set UseProjectNamespaceForGitVersionInformation to true in my directory.build.props, dotnet build will result in

obj\Debug\Debug\net8.0\GitVersionInformation.g.cs(28,1): error CS1022: Type or namespace definition, or end-of-file expected

The file GitVersionInformation.g.cs seems to only get generated if you set UseProjectNamespaceForGitVersionInformation to true. Inside GitVersionInformation.g.cs , I think GitVersion is trying to inject the "RootNameSpace" or if not, it will inject the project name.

The compile/build error I traced back to a potential bug in the class:

internal sealed class GitVersionInfoGenerator(IFileSystem fileSystem) : IGitVersionInfoGenerator

in Modules.GitVersion.Output.GitVersionInfo

The line of code that seems to be causing the issue is commented below:

string getTargetNamespace(string extension) => extension switch
{
".vb" => context.TargetNamespace ?? "Global",
// ".cs" => context.TargetNamespace != null ? $"{PathHelper.NewLine}namespace {context.TargetNamespace};" : "",
".cs" => context.TargetNamespace != null ? $"{PathHelper.NewLine}namespace {context.TargetNamespace}" : "",
".fs" => context.TargetNamespace ?? "global",
_ => targetNamespaceSentinelValue,
};

there seems to be an extra semi colon here: ....... namespace {context.TargetNamespace};" : ""

This I think caused the GitVersionInformation.g.cs to be created like :

namespace MyChosenRootNS;
{
{
[global::System.Runtime.CompilerServices.CompilerGenerated]
[global::System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage]
static class GitVersionInformation
{........... the rest

If that extra semcolon is removed from that class, it should result in the namespace to be injected without ";". And donet build works fine in creating the GitVersionInformation.g.cs file

I am not really sure, but just a hunch, and hope this helped out.

Regards,
tam

[arturcic]

@tammha if you want please submit a PR with the fix

[MrMTaylor]

I'm keen on this functionality being returned. It's great to output the SemVer in the footer and as a response header so the users know what version of the app they are using/testing. I get it's for the build, which works well for NuGet packages and naming file downloads, but we've come to rely on GitVersion for this feature.