[ISSUE]: GitVersion.MsBuild no longer supports GitVersionInformation namespace is breaking change

[conorvahland]

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

Operating system

Windows

What are you seeing?

When using GitVersion.MsBuild it seems the GitVersionInformation class is no longer existing, causing build processes to break.
Using GitVersion.MsBuild v5.x I could display build variables within the application itself, eg BranchName, ShortSha or CommitDate on a version information page.
There is no mention in the documentation of this functionality being removed and this doesnt seem to be documented as a breaking change.

What is expected?

Build information accessible within the application to display variables on a version page when using GitVersion.MsBuild

Steps to Reproduce

create Visual Studio 2022 web application

• dotnet new mvc
• install GitVersion.MsBuild v6.0.0-rc.2
• add a using statement for GitVersionInformation
• fails to resolve the namespace

RepositoryFixture Test

No response

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

No response

[arturcic]

dotnet new console --name test  
cd test
dotnet add package GitVersion.MsBuild --version 6.0.0-rc.2

git init 
git add .
git commit -m "Init" 

echo 'Console.WriteLine(GitVersionInformation.FullSemVer);' > .Program.cs 
dotnet run

I ran this in terminal and it works as expected

[conorvahland]

Thanks for your time with testing. I have run the same commands and yes using dotnet run it does correctly compile and run as expected.

However, when building the exact same project through Visual Studio (2022) it does not build giving the following error The name 'GitVersionInformation' does not exist in the current context.

For reference here is the complete Build log
Build started at 8:22 PM... 1>------ Build started: Project: testconsole, Configuration: Debug Any CPU ------ 1>Build started 17/07/2024 8:22:08 PM. 1>Target GenerateTargetFrameworkMonikerAttribute: 1> Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files. 1>Target CoreGenerateAssemblyInfo: 1> Skipping target "CoreGenerateAssemblyInfo" because all output files are up-to-date with respect to the input files. 1>Target _GenerateSourceLinkFile: 1> Source Link is empty, file 'obj\Debug\net8.0\testconsole.sourcelink.json' does not exist. 1>Target CoreCompile: 1> C:\CODE\temp\testconsole\Program.cs(1,19,1,40): error CS0103: The name 'GitVersionInformation' does not exist in the current context 1> CompilerServer: server - server processed compilation - testconsole (net8.0) 1>Done building target "CoreCompile" in project "testconsole.csproj" -- FAILED. 1> 1>Done building project "testconsole.csproj" -- FAILED. 1> 1>Build FAILED. 1> 1>C:\CODE\temp\testconsole\Program.cs(1,19,1,40): error CS0103: The name 'GitVersionInformation' does not exist in the current context 1> 0 Warning(s) 1> 1 Error(s) 1> 1>Time Elapsed 00:00:00.11 ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== ========== Build completed at 8:22 PM and took 00.349 seconds ==========

i wonder if this is a dotnet build vs msbuild problem. Can you please confirm your project can successfully build through Visual Studio?

[arturcic]

@conorvahland I don't use Visual Studio, only command line and Rider.

In Visual Studio it will not work as we dropped support for .net framework 4.8 (and by consequence Visual Studio)

https://github.com/GitTools/GitVersion/blob/main/src/GitVersion.MsBuild/msbuild/tools/GitVersion.MsBuild.props#L22-L28

[conorvahland]

thank you for the explanation

[Szaamaan]

@conorvahland I don't use Visual Studio, only command line and Rider.

In Visual Studio it will not work as we dropped support for .net framework 4.8 (and by consequence Visual Studio)

https://github.com/GitTools/GitVersion/blob/main/src/GitVersion.MsBuild/msbuild/tools/GitVersion.MsBuild.props#L22-L28

So... how is anyone using Visual Studio supposed to use GitVersion.MsBuild with version 6? Note that I'm having the same issues in VS when creating an MVC Core or WPF (DotNet 8.0) apps...

Building and launching apps from VS is pretty common for people using this IDE... does this mean we're stuck using version 5, effectively forever?

[arturcic]

@conorvahland I don't use Visual Studio, only command line and Rider.

In Visual Studio it will not work as we dropped support for .net framework 4.8 (and by consequence Visual Studio)

https://github.com/GitTools/GitVersion/blob/main/src/GitVersion.MsBuild/msbuild/tools/GitVersion.MsBuild.props#L22-L28

So... how is anyone using Visual Studio supposed to use GitVersion.MsBuild with version 6? Note that I'm having the same issues in VS when creating an MVC Core or WPF (DotNet 8.0) apps...

Building and launching apps from VS is pretty common for people using this IDE... does this mean we're stuck using version 5, effectively forever?

You can still load the project that contains the package in Visual Studio without problems, it's just the GitVersion disabled. I suppose you need a version whenever you do a release, and its most probably done in a CI/CD manner, and most probably using dotnet msbuild or dotnet build

[Szaamaan]

But if "GitVersion is disabled" then references to the static class will fail to compile.

At best you could say the tool is now non-deterministic, as it now gives different results based on the IDE. But I'd argue it just no longer works as expected in VS.

[arturcic]

@Szaamaan I can understand your frustration. In the last years there was a lot of effort put into maintaining compatibility with .Net Framework, sometimes most of the effort, and a lot of issues we had to solve just to keep .Net Framework in the list of supported. At some point during the release of 6.0 we had to decide to drop it as it was slowing us down because of too many issue and limited time and people that are maintaining the project.

My frustration and I guess of other maintainers is, the effort is not always appreciated, taking in consideration we all have full time jobs and families, and the free time we can find sometimes at night to keep the project running. I would expect the community that uses the tool to contribute back and help solve their problem, and keep maintaining the code they contribute with, and not just expect we will solve all the problems. That's how myself I started contributing and in the end maintaining the project.

Sometimes we have to take decisions that will affect people using the tool, but that's needed to keep the project running.

As for your case, you can use #if preprocesor in release mode for the references to the static class, and in debug mode you will have the code still compiling

[Szaamaan]

There must be some key detail that I'm missing, because this issue affects any kind of project opened in VS, not just ones targeting the old .NET Framework (or using the old csproj definitions).

I can certainly understand dropping suport for the old runtimes, really I do. But this seems like a case where you're not actually checking the target runtime, rather the build tool...?

And while using #if is certainly a workaround it's not really a good one because of the need to introduce new build flags which would be IDE specific (not to mention the need to refactor any references to GitVersionInformation but that's actually secondary).

[arturcic]

#3787 (comment)

[LaXiS96]

@arturcic please pin this issue because it affects pretty much all use cases for people using Visual Studio, which is the most popular (and first-party-supported) way to develop for .NET.

Reading the changelog, it is not obvious that removing support for .NET Framework also breaks compatibility with Visual Studio, but it does makes sense if VS uses the Framework MSBuild.

In my case, this change broke both in-IDE builds (Run/Debug) and publishing EXEs, which I rely on to deploy all my applications.
It could be that most users of GitVersion are using it in CI/CD environments, but the rest which aren't are now limited to 5.12.0 or forced to switch to a different tool, since workarounds on a tool touted for its zero-config and magic It Just Works™ are deal breakers sometimes.

Just my 2 cents, no hard feelings as I can understand the trade offs that must be made when maintaining open source projects.

[arturcic]

Agree, hopefully I can find time to check for solutions