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

[thoemmi]

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

GitVersion/src/GitVersion.MsBuild/msbuild/tools/GitVersion.MsBuild.props

Lines 19 to 32 in 69431b4

	<PropertyGroup Condition="'$(MSBuildRuntimeType)' == 'Full' Or '$(MSBuildRuntimeType)' == 'Mono'">
	<GitVersionFileExe>$(MSBuildThisFileDirectory)net48/gitversion.exe</GitVersionFileExe>
	<GitVersionAssemblyFile>$(MSBuildThisFileDirectory)net48/GitVersion.MsBuild.dll</GitVersionAssemblyFile>
	</PropertyGroup>
	<PropertyGroup Condition="'$(TargetFramework)' == 'netcoreapp3.1'">
	<GitVersionFileExe>dotnet $(MSBuildThisFileDirectory)netcoreapp3.1/gitversion.dll</GitVersionFileExe>
	<GitVersionAssemblyFile>$(MSBuildThisFileDirectory)netcoreapp3.1/GitVersion.MsBuild.dll</GitVersionAssemblyFile>
	</PropertyGroup>
	<PropertyGroup Condition="'$(TargetFramework)' == 'net5.0'">
	<GitVersionFileExe>dotnet $(MSBuildThisFileDirectory)net5.0/gitversion.dll</GitVersionFileExe>
	<GitVersionAssemblyFile>$(MSBuildThisFileDirectory)net5.0/GitVersion.MsBuild.dll</GitVersionAssemblyFile>
	</PropertyGroup>

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.

[arturcic]

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

Unfortunately the docs are not up to date. There are different areas in the docs that have to be updated. I'll add an issue for that

This fixed the build. However, on every build a gitversion.json file is generated in each project folder
That is on purpose. There is a Target that generats it and the other targets in the GitVersion.MsBuild are consuming it. As a solution would be to have an additional target that removes the file after all the other targets

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>

Wouldn't it be easier if you just add an additional condition for the

<PropertyGroup Condition="'$(TargetFramework)' == 'netcoreapp3.1'">

that will also handle the netstandard?

[thoemmi]

My library targets netstandard2.1. Using the condition '$(GitVersionFileExe)' == '' was must my naive attempt to get my build working. Of course this shouldn't go into production.

[arturcic]

Do you mind spending some time for a PR? so that we can review and eventually merge to fix it?

[bddckr]

When I encountered this (to add Mono MSBuild support) I ultimately thought this shouldn't check the TargetFramework and instead should check for the available SDKs installed on the machine. That's a huge task in itself AFAIK, though.

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.

Any thoughts on this? It feels a bit involved for this library to maintain a list of all possible TargetFrameworks to check.

[thoemmi]

I would provide you with a PR, but I don't know the proper way to fix the issue. Currently GitVersion.Msbuild.props sets GitVersionFileExe and GitVersionAssemblyFile for Mono, Full Framework, .NET Core 3.1 and .NET 5. All other frameworks are not supported ATM, and I would resist adding all of them. Having a decent fallback (like I did, using the netcoreapp3.1 version) would be helpful.

[thoemmi]

@bddckr sounds reasonable. However, I wouldn't go for netstandard1.6 anymore but netstandard2.0, which is supported by Full Framework since 4.7.2.

[bddckr]

Yeah that makes sense. I was thinking of supporting older MSBuild usages and I don't seem to be able to find what versions it supports (or requires), but I guess assuming the build machine has at least a .NET Standard 2.0 compatible framework installation is OK.

[arturcic]

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

[bddckr]

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

Ha, I should have found that post instead!

TL;DR Just don’t. Use a console tool instead. MSBuild tasks have limitations. It’s typically easier to write a console tool and start a new process from MSBuild using Exec.

I see. Definitely makes a lot of sense to me. I really like @thoemmi's suggestion on resolving this with a catch-all fallback.

---

So to summarize I wonder if this would work:

1. For Full (or '' as noted in the linked posts) and Mono run the net48 exe.
2. For Core run dotnet + dll.

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.

[arturcic]

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.

[SeppPenner]

I can see the same issue /root/.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. when building a net5.0 ASP.Net project in our Docker environment (Base image is dotnetsdk:5.0-buster-slim with the dependencies installed as described in #2466).

[SeppPenner]

I guess, I found the issue in my case. What about the TFMs introduced in Net5.0? If you use e.g. net5.0-windows instead of net5.0, you get the same issue as they're not included in the build props (As @thoemmi stated with netstandard already).

[ermshiperete]

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.