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.

[Xynon7]

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?

[RobSmyth]

To be clear the .NET Standard 2.0 support was dropped. It was temporarily replaced with .NET framework between releases.

But same end effect. Visual Studio support was dropped.

[RobSmyth]

Alternatively, until (or if not) support in all environments is restored, you may like to try: https://github.com/NoeticTools/Git2SemVer.MSBuild