GitTools/GitVersion

[ISSUE]: GitVersion not working when called from `msbuild` or `Visual Studio`, but works through `dotnet msbuild`

Titas22 opened this issue ยท 8 comments

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

please check this #3827

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?

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.

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?

I'll answer myself for anyone stumbling on this in the future - the only solution if using Visual Studio is to downgrade to 5.12. Which does indeed work

@arturcic It's unfortunate that users have to downgrade to 5.12 in order to build with Visual 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 use dotnet build in such cases.

@deAtog I can understand the frustration, but I think a good practice is to read the release notes/ breaking changes before upgrading

@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.

In my opinion, causing a build error when building from Visual Studio would have been preferable in this case.

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 build in 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 installed