Error on Linux with beta0014

[ermshiperete]

When I try to build a project on Linux that uses GitVersionTask 4.0.0-beta0014, I get the following error:

$HOME/.nuget/packages/gitversiontask/4.0.0-beta0014/build/functionality/GitVersionBuild.targets(6,5): 
error MSB4175: The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded 
from the assembly "$HOME/.nuget/packages/utilpack.nuget.msbuild/2.4.0/build/net45
/UtilPack.NuGet.MSBuild.dll". Could not resolve type with token 01000024 from typeref (expected class 
'NuGet.Protocol.LocalNuspecCache' in assembly 'NuGet.Protocol, Version=4.5.0.4, Culture=neutral, 
PublicKeyToken=31bf3856ad364e35') [/tmp/fd8baae02180f2156dc0c5bbf166b29d
/GitVersionIssue1458.csproj]

msbuild version 15.6.0.0
mono version 5.14.0.177

[dazinator]

You may want to reach out to UtilPack for this one: https://github.com/CometaSolutions/UtilPack

[dazinator]

Also there is a beta15 package with an updated utilpack version you can try (on our appveyor nuget feed not nuget.org at present)

[ermshiperete]

@dazinator Where do I find the beta15 package? What's the URL of the appveyor nuget feed?

[dazinator]

@ermshiperete info can be found at the top of this PR: #1269

[ermshiperete]

Thanks! I overlooked the beta15 because it's so far down the list 😄 .

With beta15 it still fails:

MSBUILD : Task factory error NMSBT001: Exception in initialization: System.TypeLoadException: Could not resolve type with token 01000025 from typeref (expected class 'NuGet.Protocol.LocalNuspecCache' in assembly 'NuGet.Protocol, Version=4.5.0.4, Culture=neutral, PublicKeyToken=31bf3856ad364e35') [/tmp/GitVersion4Pre14/ClassLibrary1/ClassLibrary1.csproj]
MSBUILD : Task factory error NMSBT001:   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory+<>c__DisplayClass35_2.<Initialize>b__2 (UtilPack.NuGet.MSBuild.RestorerCacheKey _) [0x00007] in <7ee63561a3e9407ebb192a8d4f4b9613>:0  [/tmp/GitVersion4Pre14/ClassLibrary1/ClassLibrary1.csproj]
MSBUILD : Task factory error NMSBT001:   at System.Collections.Concurrent.ConcurrentDictionary`2[TKey,TValue].GetOrAdd (TKey key, System.Func`2[T,TResult] valueFactory) [0x00034] in <2943701620b54f86b436d3ffad010412>:0  [/tmp/GitVersion4Pre14/ClassLibrary1/ClassLibrary1.csproj]
MSBUILD : Task factory error NMSBT001:   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.Initialize (System.String taskName, System.Collections.Generic.IDictionary`2[TKey,TValue] parameterGroup, System.String taskBody, Microsoft.Build.Framework.IBuildEngine taskFactoryLoggingHost) [0x001fb] in <7ee63561a3e9407ebb192a8d4f4b9613>:0  [/tmp/GitVersion4Pre14/ClassLibrary1/ClassLibrary1.csproj]
$HOME/.nuget/packages/gitversiontask/4.0.0-beta0015/build/functionality/GitVersionMultiTargetBuild.targets(6,5): error MSB4175: The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "$HOME/.nuget/packages/utilpack.nuget.msbuild/2.6.0/build/net45/UtilPack.NuGet.MSBuild.dll". Object reference not set to an instance of an object [/tmp/GitVersion4Pre14/ClassLibrary1/ClassLibrary1.csproj]

[dazinator]

@ermshiperete can you check this dir: HOME/.nuget/packages/utilpack.nuget.msbuild/2.6.0/

Does utilpack exist there or is that directory empty?

[dazinator]

P.s im glad to see from the stacktrace it is atleast using the multi target build targets now - so thats your merged PR taking effect there.

[ermshiperete]

yes, $HOME/.nuget/packages/utilpack.nuget.msbuild/2.6.0/ exists (and has the content I'd expect).

[dazinator]

Can you provide further details about your linux setup, distro, etc?
Do you have mono installed? Or dotnet sdk? or both? and which version?

[ermshiperete]

Ubuntu 16.04.5 LTS
mono 5.14.0.177
msbuild 15.6.0.0

$ dotnet --list-sdks
1.0.4 [/usr/share/dotnet/sdk]
2.1.401 [/usr/share/dotnet/sdk]
$ dotnet --list-runtimes
Microsoft.AspNetCore.All 2.1.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 1.0.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Is it working for you on Linux?

[dazinator]

I'm a windows user, never used linux, but I was going to make the dive to try and repro this.

[dazinator]

@ermshiperete - please could you try again with:

<PackageReference Include="GitVersionTask" Version="4.0.0-pullrequest1470-1617">
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>

the above package is available from our appveyor nuget feed.

The reason I ask is because we fixed a null ref issue with msbuild recently in #1458 and I am wondering if it might be the same thing.

[ermshiperete]

We're half way there.

Running dotnet build works now with 4.0.0-pullrequest1470-1617, but running msbuild /restore /t:Build crashes msbuild (see output: https://gist.github.com/ermshiperete/18bd905ca9155f3052dca0864a85d0da)

[dazinator]

Progress then!
Please forgive my lack of linux knowledge.. so it looks like msbuild runs under mono on your ubuntu environment. Is this some IDE you are using? I assume you can't just switch to using `dotnet msbuild' :-)

[stazz]

Hi @ermshiperete , the guy behind UtilPack task factory here. I wasn't prepared for the task factory to be used in Mono environment when I was writing the code, as I thought .NET Core was supposed to practically replace it (at least at some point there was some talk about it). The task factory thus autodetects the runtime framework to be .NETFramework,Version=v4.6.1, and I am very sure that this is the root cause for the error.

How can I repro this issue? Or, if it requires some special permissions or is too hard to explain, could you try to switch the contents of net45 and netcoreapp1.1 folders within the $HOME/.nuget/packages/utilpack.nuget.msbuild/2.6.0/build folder, and check how the build proceeds then? This might cause other errors, but at least it would answer the question of "if assemblies compiled for .NET Desktop can't be loaded in Mono under Linux, can it still load assemblies compiled for .NET Core". Answer to this question determines how I proceed with the fix.

[ermshiperete]

@dazinator I run msbuild on the command line with Mono 5. Unfortunately it is currently not possible for the projects I'm working on to switch to use dotnet msbuild.

[ermshiperete]

@stazz Thanks for looking into this!

To reproduce you can use the minimal project: https://gist.github.com/fd8baae02180f2156dc0c5bbf166b29d.git

I'd recommend to install Mono 5.x from https://www.mono-project.com/download/stable/ - the mono versions that come with the Linux distros are usually much older and so other Mono bugs might come into play.

Then run msbuild /restore /t:Build.

Switching net45 and netcoreapp1.1 doesn't make a difference and produces the same error.

[stazz]

@ermshiperete Thanks - I'll try to reproduce it locally and see if actually compiling task factory against Mono framework could solve this issue.

[stazz]

@ermshiperete Sorry for late message, I unfortunately only now got time to try this out. It seems that the required version of GitVersionTask is in AppVeyor feed. Is there any way for me to pull the package from AppVeyor without registering? I remember sometimes @dazinator sending me a link for some repro case, but I guess each link has to be explicitly generated? If I register to AppVeyor, would I automatically get access to the required (all?) versions of GitVersionTask?

[dazinator]

@stazz yeah you should be able to pull nuget packages from the appveyor feed without registering..
You just need to configure your nuget source as https://ci.appveyor.com/nuget/gitversion-8nigugxjftrw
Then you can query this nuget feed and download any packages without any authentication.
Let me know if you need any assistance with anything and I'll do my best to help

[stazz]

Thank you @dazinator for quick reply! Good to know that link is apparently covering all GitVersionTask versions - I thought it was specific to some version last time you posted it. I have now successfully reproduced the issue. As a side-note, it seems the crash happens also in Docker container, so it is relatively easily to test by running docker run --rm -it mono:latest command, and doing git clone and msbuild commands within.

Next, I'll try to compile UtilPack.NuGet.MSBuild task factory against Mono framework (instead of just .NET Desktop and Core), and see if that would fix the problem. :)

[stazz]

I've googled around a bit, and it doesn't look good. More specifically, apparently compiling against Mono is just compiling against .NET Desktop with different environment. Then, there is xunit/xunit#1357 , and these quotes especially:

Specifically, there have been some long-standing bugs in app domains on Mono that would require you to turn them off. It still may not work even after that, but app domains are very likely never going to work with Mono.

We have taken bug fixes from time to time for Mono issues, but even so, we will never actively support it and will rely on the community to do so. In this case (app domains being broken in Mono) there is simply nothing that could be done on our side; the fix must be done in Mono itself. As others who have approached the issue have told me, they are reluctant to take any fixes like that because their primary focus is on devices, not desktops. You're welcome to try.

And the Desktop version of UtilPack.NuGet.MSBuild specifically uses AppDomains, as they are the sole sandboxing mechanism in Desktop.

One not-so-pretty fix that springs to my mind is that everything could be done within the same AppDomain, if the task factory detects it is running Desktop version within non-Windows OS ( = Mono, in this case at least). Thus the usage of custom, newly-created AppDomains could be avoided, at the cost of polluting the current AppDomain with the assemblies loaded from task (which might have some negative impact on subsequent task factory usages within same MSBuild process). What do you think of this?

[stazz]

I've now verified that this issue does not happen when I use current AppDomain to execute task instead of creating a dedicated AppDomain. I'll see if I can get the auto-detection code to work so that the task factory would use current AppDomain instead of dedicated one if the task factory automatically detects to be running in Mono environment. Will post a follow-up of how it went.

[stazz]

@dazinator @ermshiperete I've fixed this now in 2.8.0 version of UtilPack.NuGet.MSBuild, which I just published. At least the repro now builds successfully.

[dazinator]

@stazz - excellent news. Thank you for going the extra mile and turning this around for mono users :-)

[stazz]

No problems - it is important for me that stuff I make actually works. Let me know if there are still issues with this! :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.