GitVersion.MsBuild v6 seems to have forgotten about Visual Studio developers

[Szaamaan]

Is this intended?

I've created a simple console application, just one line of code:
Console.WriteLine(GitVersionInformation.Sha);

With an equally "simple" project file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="GitVersion.MsBuild" Version="6.0.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>

</Project>

If I run dotnet build it'll compile. If I try to compile via Visual Studio it won't (GitVersionInformation won't be available).

D:\GIT\GitVerTest\GitVerTest\Program.cs(2,19,2,40): error CS0103: The name 'GitVersionInformation' does not exist in the current context

This seems to be a deliberate change in v6 but... this can't be right, can it? You're effectively leaving every user of Visual Studio stranded at version 5...

[arturcic]

Is this intended?

I've created a VERY simple console application, just one line of code:
Console.WriteLine(GitVersionInformation.Sha);

With an equally "simple" project file:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="GitVersion.MsBuild" Version="6.0.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>

</Project>

If I run dotnet build it'll compile. If I try to compile via Visual Studio it won't (GitVersionInformation won't be available).

D:\GIT\GitVerTest\GitVerTest\Program.cs(2,19,2,40): error CS0103: The name 'GitVersionInformation' does not exist in the current context

This seems to be a deliberate change in v6 but... this can't be right, can it? You're effectively leaving every user of Visual Studio stranded at version 5...

Unfortunately we do not have people to maintain the codebase for the .net framework, so we decided to focus on LTS .NET only

[hotchkj]

Or just multi-targetting as @hotchkj mentioned?) ...Is that how every MSBuild-task Nuget is done?

Purely answering this, having written a few - you typically have to multi-target, as MSBuild libraries do not work consistently with netstandard2.0. See their docs:

The netstandard2.0 target of this build is configured only to output reference assemblies; at runtime MSBuild will be net8.0 or net472. Please use the net8.0-targeted assemblies for .NET 8+ scenarios.

In addition, each version of Microsoft.Build.Utilities.Core targets a different set of frameworks as NET SDKs advance, so if you want to ensure you load the task correctly and don't end up depending on new APIs not present in earlier MSBuilds, you need to target the relevant minimum version that builds with the matching target of NET SDK (so in this case a version for NET 6 and a version for NET 8).

loosing all the benefits net6.0 and up and the corresponding c# version include

It is feasible to target later versions of the C# language even against NET Framework. Certainly I've yet to encounter bugs with 9 or 10. It is just not a strictly tested/supported scenario by Microsoft.

It's unfortunate there aren't any statistics handy on MSBuild usage of 'normal' vs the 'sdk' variants - that would help inform, though anyone building anything other than pure bare-bones NET will inevitably have to use Visual Studio MSBuild.

[Szaamaan]

@Szaamaan , @Xynon7 would you want to invest some time on improving these and contribute to the code base, and also maintain it long term whenever it's needed?

With the upfront caveat that I've never created a custom msbuild task before (best I've done were some templates, but that's not the same) I actually might take a peak, if only to understand better what the hell's going on in there. ;)

On the one hand it seems like the tasks do very little - parse some output and apply that. On the other it seems the GitVersion team / maintainers seem (based on your reply) set on using references to quite a bit of the existing codebase, which makes me think these tasks aren't as simple as they seems in my head.

[Xeri7]

I'm sad to be honest to see nobody wants to use his personal time in contributing to a project they are using, and still waiting for someone else to spend that personal time. I do understand that Visual Studio is an important IDE, I used it myself for a long time, but now most of the time I'm using either vscode / command line or Rider.

At this point no one in the team has the time to invest in investigating how to solve the issue, as to be frank, we have regular, paid jobs, families, and other priorities. I don't say we will not invest time on this issue, but don't ask instant fixes as you would ask from commercial, paid tools.

I apologize then, because this was mainly due to the way your comments sounded like this would NOT be getting time invested into it. I do not expect instant fixes. As you say, this is not a commercial paid tool! My concern was that the way I read the comments was this was intentional and not planned to be fixed at all, ever.

[arturcic]

@Szaamaan , @Xynon7 would you want to invest some time on improving these and contribute to the code base, and also maintain it long term whenever it's needed?

With the upfront caveat that I've never created a custom msbuild task before (best I've done were some templates, but that's not the same) I actually might take a peak, if only to understand better what the hell's going on in there. ;)

On the one hand it seems like the tasks do very little - parse some output and apply that. On the other it seems the GitVersion team / maintainers seem (based on your reply) set on using references to quite a bit of the existing codebase, which makes me think these tasks aren't as simple as they seems in my head.

If you want to start looking at this, you can start with this and see the dependencies and their usages.
All those dependencies are referenced from the Core or other modules.

You can see there are like 4 custom tasks that we created. And here you can check the unit tests we built.

The idea was use the references from the other modules instead of having it's own version. So that whenever we improve in the Core it also works in MsBuild.

[RobSmyth]

Hi @arturcic ,

I'm sad to be honest to see nobody wants to use his personal time in contributing to a project they are using, and still waiting for someone else to spend that personal time. I do understand that Visual Studio is an important IDE, I used it myself for a long time, but now most of the time I'm using either vscode / command line or Rider.

At this point no one in the team has the time to invest in investigating how to solve the issue, as to be frank, we have regular, paid jobs, families, and other priorities. I don't say we will not invest time on this issue, but don't ask instant fixes as you would ask from commercial, paid tools.

I think it would help me/others to contribute if you could give some more information on why .NET Standard 2.0 support was removed. Without understanding what the problem was/is it is hard to find a solution. I believe support was removed in a commit that moved project settings to Directory.Build.props file. Why was the multi-targeting for some assemblies dropped? ... or perhaps the question is what was the cost of keeping it?

Can you give background enable somebody to restore it?

[RobSmyth]

I'm using GitVersion.MSBuild and I did hit a different problem with 6.0.2 not being able to build with Visual Studio. It may shed light.

The build error was:

MSB4062	The "WriteVersionInfoToBuildLog" task could not be loaded from the assembly .....\.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.	

It did compile fine with dotnet cli. I found a work around of removing the following line from my csproj:

<WriteVersionInfoToBuildLog>true</WriteVersionInfoToBuildLog>

Rob

[RobSmyth]

Hi @Szaamaan

I've had a go at reproducing your issue and it seems that GitVersion is not running as DisableGitVersionTask is set to true during the build. Hence GitVersionInformation does not exist. Yes GitVersion does run using dotnet cli.

So ... I enabled DisableGitVersionTask in the csproj and then got the error:

The "GetVersion" task could not be loaded from the assembly .......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. 

I do not know why DisableGitVersionTask is being set ... dive a bit deeper later. I can see the error above has been reported a few times over the last few years.

Interesting. GitVersion.MSBuild is being loaded as .NET 8.0 when I thought it ran in the MSBuild .NET framework ... not at all sure. Maybe that explains why it compiles for dotnet clie and not the full MSBuild.

[RobSmyth]

Ah, I see: #4116

[RobSmyth]

Digging a little more I notice that 5.12.0 show .NET Standard 2.0 dependency while 6.0.0 does not. I believe that .NET 2.0 works with both dotnet cli and VS.

[Dunge]

I'm doing a pass of nuget upgrades in my project and noticed GitVersion.MsBuild stopped working too (my files became 1.0.0).

What's the use of this nuget if it doesn't support Visual Studio? On my release build pipeline it's going through dotnet-gitversion and dotnet publish and it work, so this nuget is not required. But on a developer machine machine running the solution via Visual Studio, I was expecting the nuget task to run to stamp the version. Even had a "Condition="'$(Configuration)'=='Debug'" on the PackageReference. Is there any different workflow I could use, or should I simply remain on 5.12.0?

[RobSmyth]

I believe the current advice is stay on 5.12.0.

[RobSmyth]

On my release build pipeline it's going through dotnet-gitversion and dotnet publish and it work,

Quite apart from GitVersion dropping Visual Studio support ...

If you do not mind my asking ... why do you use dotnet-gitversion on the build system and not the nuget MSBuild task? I'm wondering why 2 approaches and the extra build step?

[Dunge]

I was trying to remember and searched my history. Apparently it was due to a bug documented here #1381 and it got fixed in 5.6.9 a few years later.

[mpdunlop]

I've ran into a scenario that requires us to upgrade to 6.X from 5.12.0 (#3699) but quite quickly discovered that 6.X isn't supported by Visual Studio.

For some additional background context: We build pre-release nuget packages on our own machines using Visual Studio and depend on these packages elsewhere via local NuGet feeds. These pre-release packages can then be used for testing in the project that depends on it. Once the feature is complete, only then are the changes merged and pushed to origin triggering a dotnet build command (which GitVersion.MsBuild still works fine with).

My understanding is that .NET Framework MSBuild support was dropped, leading to Visual Studio no longer being supported. What needs to happen for this to become viable again?

[M0n7y5]

Because it will hardcode the version as a constant string into binary that is then build via CI/CD pipeline. Also it does not need Reflection API and its more NativeAOT friendly. I managed to get version 5.12 in our CI/CD pipeline, so its fine for now.

[RobSmyth]

Because it will hardcode the version as a constant string into binary that is then build via CI/CD pipeline. Also it does not need Reflection API and its more NativeAOT friendly. I managed to get version 5.12 in our CI/CD pipeline, so its fine for now.

Thanks @M0n7y5 , I appreciate your taking the time to reply.

Sounds like I misunderstood, you were referring to the generated cs assembly info like file.
I think you value having the version as a constant string in code to avoid calling GetType().Assembly.GetName().Version.
I guess it reduces the compiled NativeAOT app size.
Not something I had valued as I do not use NativeAOT deployment.

I had always avoided that generated file as I use solution versioning, with common time-of-build build number, and any change to a common file triggers recompile of every project on any one project rebuild regardless of dependencies (when using solution versioning). But I do get it.

FYI: The inbuilt csx (C# scripting) does allow for such compile time customisation but it is not "out of the box". It would be simple to generate that file.

Thank you, food for thought

[M0n7y5]

I guess it reduces the compiled NativeAOT app size. Not something I had valued as I do not use NativeAOT deployment.

The main issue is the Reflection API which needs to be avoided when targeting NativeAOT. GetType().Assembly.GetName().Version uses reflection under the hood.

[RobSmyth]

Hi @M0n7y5,

The main issue is the Reflection API which needs to be avoided when targeting NativeAOT. GetType().Assembly.GetName().Version uses reflection under the hood.

Thanks,

Can you explain why this reflection an issue here? I ask as you challenge some assumptions I have here, please correct me. I'm assuming:

• Reading the version is something probably only done once during start.
• GetType().Assembly.GetName().Version is a fast operation as there is little or no iterating resources. (I have not measured it)

I'm of the opinion that reflection gets a bad name as it is often used to iterate through all types in many assemblies for some sort of discovery.

[RobSmyth]

@M0n7y5,

The main issue is the Reflection API which needs to be avoided when targeting NativeAOT. GetType().Assembly.GetName().Version uses reflection under the hood.

Disregard my prior questions as I think it all comes down to what is "fast" (or acceptable) is relative to domain and context. Thanks for your feedback ... compiled class with constant strings beneficial/desired (out of box).

If you feel like it, it would be great if you could raise a feature request.

Thanks

[stephenquan]

I’m not sure if this helps, but I’ve come up with the following workaround:

• In your .csproj, add a post-GetVersion step that:
  • Runs dotnet gitversion and captures the output in the default obj\gitversion.json file.
  • Loads the contents of gitversion.json into your assembly attribute metadata.
• In your C# code:
  • Deserialize the JSON from the assembly attribute.
  • Create a static class with properties that expose the relevant GitVersion fields.

This approach is demonstrated in my test Console application, but the concept should apply to any project type.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="GitVersion.MsBuild" Version="6.4.0">
    <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
  </ItemGroup>

  <!--#region Enables GitVersion to work with Visual Studio-->

  <Target Name="GetVersionForVisualStudio" AfterTargets="GetVersion">
    <Exec Command="dotnet gitversion -output file -outputfile $(ProjectDir)\$(GitVersionOutputFile)" />
    <ReadLinesFromFile File="$(ProjectDir)\$(GitVersionOutputFile)">
      <Output TaskParameter="Lines" PropertyName="GitVersionInformation" />
    </ReadLinesFromFile>
    <ItemGroup>
      <AssemblyAttribute Include="System.Reflection.AssemblyMetadataAttribute">
        <_Parameter1>GitVersionInformation</_Parameter1>
        <_Parameter2>$(GitVersionInformation)</_Parameter2>
      </AssemblyAttribute>
    </ItemGroup>
  </Target>

  <!--#endregion-->

</Project>

and here's the sample console application reading the GitVersionInformation:

// Program.cs

using System.Reflection;
using System.Text.Json;
using System.Text.Json.Nodes;

Console.WriteLine($"Sha: {GitVersionInfo.Sha}");
Console.WriteLine($"InformationalVersion: {GitVersionInfo.InformationalVersion}");
Console.WriteLine($"MajorMinorPatch: {GitVersionInfo.MajorMinorPatch}");

public static class GitVersionInfo
{
    public static int Major => GetJsonProperty<int>("Major");
    public static int Minor => GetJsonProperty<int>("Minor");
    public static int Patch => GetJsonProperty<int>("Patch");
    public static string PreReleaseTag => GetJsonProperty<string>("PreReleaseTag");
    public static string PreReleaseTagWithDash => GetJsonProperty<string>("PreReleaseTagWithDash");
    public static string PreReleaseLabel => GetJsonProperty<string>("PreReleaseLabel");
    public static string PreReleaseLabelWithDash => GetJsonProperty<string>("PreReleaseLabelWithDash");
    public static int? PreReleaseNumber => GetJsonProperty<int?>("PreReleaseNumber");
    public static int BuildMetaData => GetJsonProperty<int>("BuildMetaData");
    public static string BuildMetaDataPadded => GetJsonProperty<string>("BuildMetaDataPadded");
    public static string FullBuildMetaData => GetJsonProperty<string>("FullBuildMetaData");
    public static string MajorMinorPatch => GetJsonProperty<string>("MajorMinorPatch");
    public static string SemVer => GetJsonProperty<string>("SemVer");
    public static string LegacySemVer => GetJsonProperty<string>("LegacySemVer");
    public static string LegacySemVerPadded => GetJsonProperty<string>("LegacySemVerPadded");
    public static string AssemblySemVer => GetJsonProperty<string>("AssemblySemVer");
    public static string AssemblySemFileVer => GetJsonProperty<string>("AssemblySemFileVer");
    public static string FullSemVer => GetJsonProperty<string>("FullSemVer");
    public static string InformationalVersion => GetJsonProperty<string>("InformationalVersion");
    public static string BranchName => GetJsonProperty<string>("BranchName");
    public static string EscapedBranchName => GetJsonProperty<string>("EscapedBranchName");
    public static string Sha => GetJsonProperty<string>("Sha");
    public static string ShortSha => GetJsonProperty<string>("ShortSha");
    public static string NuGetVersionV2 => GetJsonProperty<string>("NuGetVersionV2");
    public static string NuGetVersion => GetJsonProperty<string>("NuGetVersion");
    public static string NuGetPreReleaseTagV2 => GetJsonProperty<string>("NuGetPreReleaseTagV2");
    public static string NuGetPreReleaseTag => GetJsonProperty<string>("NuGetPreReleaseTag");
    public static string VersionSourceSha => GetJsonProperty<string>("VersionSourceSha");
    public static int CommitsSinceVersionSource => GetJsonProperty<int>("CommitsSinceVersionSource");
    public static string CommitsSinceVersionSourcePadded => GetJsonProperty<string>("CommitsSinceVersionSourcePadded");
    public static int UncommittedChanges => GetJsonProperty<int>("UncommittedChanges");
    public static string CommitDate => GetJsonProperty<string>("CommitDate");
    public static JsonNode? Json { get; }
        = (Assembly.GetExecutingAssembly() is Assembly assembly
            && assembly.GetCustomAttributes(typeof(AssemblyMetadataAttribute), false)
            .Select(a => a as AssemblyMetadataAttribute)
            .Where(ma => ma is not null && ma.Key.StartsWith("GitVersionInformation"))
            .FirstOrDefault() is AssemblyMetadataAttribute attribute
            && attribute.Value is string text
            && !string.IsNullOrEmpty(text)
            && JsonNode.Parse(text.Replace(";", "")) is JsonNode json)
            ? json
            : null;
    public static T GetJsonProperty<T>(string key, T defaultValue = default(T))
        => Json is JsonObject obj
            && obj.TryGetPropertyValue(key, out var value)
            && value is not null
            && value.GetValue<T>() is T v
            ? v
            : defaultValue;
}

For a working demo: https://github.com/stephenquan/GitVersionTest