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)
That works for me on the following machines/projects:
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 buildas I’m forced to usemsbuildstill (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
we use
Similar error on Ubuntu 18.04 trying to build for
netcoreapp3.1. Seems like dotnet can’t load the project because of this error.Same problem trying to load the project in Rider.
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.
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