[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
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