Repository navigation
[ISSUE]: GitVersion not working when called from msbuild or Visual Studio, but works through dotnet msbuild #4118
Description
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?
When I try building a project that includes GitVersion.MSBuild package, the GitVersion does not run during the build and the variables are left unset. This is the case both in case of building from CLI and through Visual Studio 2022 (both community and professional editions).
What is expected?
I expect the tool to work correctly like it does if I build with dotnet msbuild instead of msbuild, however I cannot (or don't know how to) change this in Visual Studio when building there.
Steps to Reproduce
Simple console app:
Program.cs
// See https://aka.ms/new-console-template for more information
Console.WriteLine("Hello, World!");
Console.ReadLine();ConsoleApp1.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="GitVersion.MsBuild" Version="6.0.0" PrivateAssets="all">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
</ItemGroup>
<Target Name="PreVersion" DependsOnTargets="GetVersion" BeforeTargets="BeforeBuild">
<Message Text="Repo sha: $(GitVersion_Sha)" Importance="high" />
<Message Text="Repo version: $(GitVersion_FullSemVer)" Importance="high" />
</Target>
<Target Name="Git2" AfterTargets="AfterBuild">
<Message Text="Repo sha: $(GitVersion_Sha)" Importance="high" />
<Message Text="Repo version: $(GitVersion_FullSemVer)" Importance="high" />
</Target>
</Project>
RepositoryFixture Test
No response
Output log or link to your CI build (if appropriate).
When building using dotnet the version and sha get set successfully:
C:\Users\titas\Code\ConsoleApp1>dotnet msbuild --restore ConsoleApp1.csproj
MSBuild version 17.10.4+10fbfbf2e for .NET
Determining projects to restore...
All projects are up-to-date for restore.
Repo sha: 417a2e18e2591412c799798c709a7dc3af701e31
Repo version: 0.2.3
ConsoleApp1 -> C:\Users\titas\Code\ConsoleApp1\bin\Debug\net6.0\ConsoleApp1.dll
Repo sha: 417a2e18e2591412c799798c709a7dc3af701e31
Repo version: 0.2.3
When building using msbuild the version and sha are left empty (also the case when running from Visual Studio):
C:\Users\titas\Code\ConsoleApp1>msbuild --restore ConsoleApp1.csproj /v:minimal
MSBuild version 17.10.4+10fbfbf2e for .NET Framework
Determining projects to restore...
All projects are up-to-date for restore.
Repo sha:
Repo version:
ConsoleApp1 -> C:\Users\titas\Code\ConsoleApp1\bin\Debug\net6.0\ConsoleApp1.dll
Repo sha:
Repo version:
I noticed that the `msbuild` when called directly uses a version for `.NET Framework` while `dotnet msbuild` uses `.NET`. Not sure if that's the cause but I would expect the tool to work in both cases? Or is that not possible? Or am I missing something? that
Activity
arturcic commentedon Jul 25, 2024
please check this #3827
Titas22 commentedon Jul 25, 2024
Thanks @arturcic, I see that it's turned off but is there a solution or workaround to get it working in visual studio? Or a plan to turn it on in the future?
arturcic commentedon Jul 25, 2024
It's turned off because we do not support .Net Framework anymore and we are focused only on support for the LTS versions of .NET.
Because Visual Studio currently runs on .Net Framework that means it will be turned off always.
Titas22 commentedon Jul 25, 2024
I'll answer myself for anyone stumbling on this in the future - the only solution if using
Visual Studiois to downgrade to5.12. Which does indeed workdeAtog commentedon Aug 27, 2024
@arturcic It's unfortunate that users have to downgrade to
5.12in order to build withVisual Studio. Additionally, it's extremely frustrating that the latest version gives no indication when building with Visual Studio that it has been automatically disabled. No one should have to expend time or effort to determine why this package doesn't work as anticipated when you could simply output a message informing users to either downgrade to the last supported version or usedotnet buildin such cases.arturcic commentedon Aug 27, 2024
@deAtog I can understand the frustration, but I think a good practice is to read the release notes/ breaking changes before upgrading
deAtog commentedon Aug 28, 2024
@arturcic Let's be honest, no one reads release notes. People expect new versions to either break upon upgrade or to continue to function as they did previously. In my opinion, causing a build error when building from Visual Studio would have been preferable in this case. It would have immediately highlighted the fact that Visual Studio was no longer supported by the package.
In my particular case, I was adding the package to an existing project and was caught off-guard when it didn't work as expected.
arturcic commentedon Aug 28, 2024
Actually when this issue initially appeared after removal of .net48 most of the community members requested to disable because it was failing for them to locally build with VS, and they were using
dotnet buildin any case in CI environment where it's enabled. So I think as a compromise would be to have a warning shown in VS when the package is installeddorssel commentedon Dec 2, 2024
FYI, I created https://www.nuget.org/packages/Dorssel.GitVersion.MsBuild, which does support Visual Studio even with version 6 GitVersion tool.
arturcic commentedon Dec 2, 2024
@dorssel thanks for sharing, I had a similar idea to decouple the MsBuild from Core