GitVersion: [Bug] Build with GitVersion.MsBuild fails because GitVersionFileExe is not set

Because GitVersionTask seems to be deprecated, I have switched to the GitVersion.MsBuild package. However, the build of my netstandard2.1 library fails with the message

C:\Users\Thomas.nuget\packages\gitversion.msbuild\5.6.1\tools\GitVersion.MsBuild.targets(3,38): error MSB4022: The result “” of evaluating the value “$(GitVersionAssemblyFile)” of the “AssemblyFile” attribute in element <UsingTask> is not valid. [C:\priv\GitVersionMsBuildIssue\src\DemoLib\DemoLib.csproj]

I have noticed that in GitVersion.MsBuild.props, GitVersionFileExe and GitVersionAssemblyFile are not set when the target framework is netstandard2.1. See https://github.com/GitTools/GitVersion/blob/69431b40003b07c1ad0b679eabeb5d1ada531901/src/GitVersion.MsBuild/msbuild/tools/GitVersion.MsBuild.props#L19-L32

I’ve fixed it on my local machine by adding following fallback:

<PropertyGroup Condition="'$(GitVersionFileExe)' == ''">
    <GitVersionFileExe>dotnet $(MSBuildThisFileDirectory)netcoreapp3.1/gitversion.dll</GitVersionFileExe>
    <GitVersionAssemblyFile>$(MSBuildThisFileDirectory)netcoreapp3.1/GitVersion.MsBuild.dll</GitVersionAssemblyFile>
</PropertyGroup>

I have created a repo to reproduce the issue at https://github.com/thoemmi/GitVersionMsBuildIssue

This fixed the build. However, on every build a gitversion.json file is generated in each project folder, which is really annoying. Is there another MsBuild property required to supress that?

Regarding the deprecation of GitVersionTask: The documentation for MSBuild Task still mentions the GitVersionTask package.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 28 (18 by maintainers)

Most upvoted comments

That works for me on the following machines/projects:

  • Windows with MSBuild (Framework) on projects using net48 + net5.0
  • macOS with MSBuild (Mono) on projects using Xamarin.Mac + Xamarin.Android

I’ve confirmed it builds the listed projects on both machines from both inside Visual Studio, but also from the CLI. The only thing I’m unable to test with my solution is dotnet build as I’m forced to use msbuild still (old project system in use by Xamarin).

I’ve run each test at least 3 times on a cleared cache, but also as an incremental build. Each time I made sure I’m building a bunch of projects concurrently, too (as that triggered the issue for me most of the time). Previously this would have hit the bug in each run, but I’m unable to reproduce now 👍

I can confirm that this works with our build server, too 😃 (With the Debian Buster Docker base image). 👍

It works for me on my dev machine 😃

@thoemmi, @bddckr, @SeppPenner, @ermshiperete do you mind to check the #2521 solution if it solves the issue? If you can confirm I will merge it

In that case maybe it makes sense to have the fallback solution @thoemmi initially suggested, but instead of

<PropertyGroup Condition="'$(GitVersionFileExe)' == ''">
   <GitVersionFileExe>dotnet $(MSBuildThisFileDirectory)netcoreapp3.1/gitversion.dll</GitVersionFileExe>
   <GitVersionAssemblyFile>$(MSBuildThisFileDirectory)netcoreapp3.1/GitVersion.MsBuild.dll</GitVersionAssemblyFile>
</PropertyGroup>

we use

<PropertyGroup Condition="'$(GitVersionFileExe)' == ''">
     <GitVersionFileExe>dotnet $(MSBuildThisFileDirectory)net5.0/gitversion.dll</GitVersionFileExe> 
     <GitVersionAssemblyFile>$(MSBuildThisFileDirectory)net5.0/GitVersion.MsBuild.dll</GitVersionAssemblyFile> 
 </PropertyGroup> 

Similar error on Ubuntu 18.04 trying to build for netcoreapp3.1. Seems like dotnet can’t load the project because of this error.

/home/user/.nuget/packages/gitversion.msbuild/5.6.1/tools/GitVersion.MsBuild.targets(3,38): error MSB4022: The result "" of evaluating the value "$(GitVersionAssemblyFile)" of the "AssemblyFile" attribute in element <UsingTask> is not valid.

Same problem trying to load the project in Rider.

Is there a need to ship a net5.0 dll and run that? Isn’t the .NET 5 SDK/runtime backwards compatible with previous .NET Core assemblies? If that’s the case the above simplification should work and there is no need to check for .NET 5 vs. .NET Core 3.1 etc. I.e. ship net48 and netcoreapp3.1 dlls only.

Actually there are differences. I’ve tried embedding only 3.1 bits and use it on .net5.0 but the exe was asking for net50 runtime Then I tried the vice-versa, to embed 5.0 bits then it was asking for netcore 3.1 runtime. Also the dlls for the tasks on each runtime have different set of dependencies in the publish output so they cannot be used by both targets.

Other tooling that integrates with MSBuild seems to ship with net46 and netstandard1.6 dlls and implements the whole logic inside that (i.e. the MSBuild tasks are inside those dlls and that is all the logic they run). So they neither invoke an .exe, nor do they invoke dotnet to point it to a dll. This is the best overview I could find.

That was the old way this package was working (when it was GitVersionTask). But we had quite a lot of issues because GitVersion relies on Libgit2Sharp with native libs embedded. There are some limitations on how the native libs are loaded by msbuild, you needed to provide a custom AssemblyLoader that needs to implement the resolving of the native dependencies depending on the RID. And in order to support all the platforms you have to update the RID manually and so on.

So plenty of issues we had in the past. Then we switched to this This way we let the executable resolve its dependencies the usual way and we just consume its ouptut