MSBUILD : Task factory warning NMSBT010: There is a mismatch between SDK NuGet version (4.8.1) and the NuGet version the task factory was compiled against (4.8.0). There might occur some exotic errors.

[Choc13]

Hi,

I have just updated a .NET Core project to Gitversion.Task 4.0.0. It seems to be working fine and it's nice to see this now working with the .NET Core SDK enabling us to call dotnet build and have versioning work. Great job!

However, there are some warnings generated by the tool. Namely:

MSBUILD : Task factory warning NMSBT010: There is a mismatch between SDK NuGet version (4.8.1) and the NuGet version the task factory was compiled against (4.8.0). There might occur some exotic errors.

This is only a warning and doesn't cause the build to fail and as far as I can tell there are no issues with the version numbers being generated. However, I did notice #1467 and I wonder if this NuGet version mismatch is going to be a problem every time there is an update to the NuGet version in the .NET Core SDK. I do not have any experience building tools for the .NET Core SDK so I have no idea what the best practice is here for avoiding these kinds of warnings. I can imagine it would be a pain to have to release this library every time NuGet is updated in the .NET Core SDK.

For reference the .NET Core SDK version I am using is 2.1.403. Our Travis build uses the same SDK version and reports the same warnings, however AppVeyor is using 2.1.402 and doesn't report any warnings.

[hellfirehd]

I'm getting the exact same warning with v4.0.1-beta1-26. Here is my dotnet --info if it helps:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.403
 Commit:    04e15494b6

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.403\

Host (useful for support):
  Version: 2.1.5
  Commit:  290303f510

.NET Core SDKs installed:
  1.1.0 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.402 [C:\Program Files\dotnet\sdk]
  2.1.403 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

[LordMike]

Bump. Affects us too. :)

[LordMike]

Still happens on 4.0.1-beta1-29 -- and 4.0.1-beta-31

[LordMike]

Still happens in 4.0.1-beta1-38

[adamshergold]

I've started seeing this as an ERROR now instead of the warning when using microsoft/dotnet:2.1-sdk

MSBUILD : Task factory warning NMSBT010: There is a mismatch between SDK NuGet version (4.9.0) and the NuGet version the task factory was compiled against (4.8.0). There might occur some exotic errors. [/app/example.serialisation/example.serialisation.fsproj] MSBUILD : Task factory error NMSBT001: Exception in initialization: System.MissingMethodException: Method not found: 'Void NuGet.Commands.RestoreRequest..ctor(NuGet.ProjectModel.PackageSpec, NuGet.Commands.RestoreCommandProviders, NuGet.Protocol.Core.Types.SourceCacheContext, NuGet.Common.ILogger)'. [/app/example.serialisation/example.serialisation.fsproj]

If I'm more specific then microsoft/dotnet:2.1.403-sdk works (with warning) but microsoft/dotnet:2.1.500-sdk fails with the error.

[arturcic]

@dazinator can you have a look? I guess you had this issue here stazz/UtilPack#19

[dazinator]

@adamshergold afaik gitversiontask wont work on sdk >= 2.1.0 yet - there is an ongoing PR that adds support for sdk 2.1.0 and drops support for sdk 1.1.0 as it updates libgit2sharp dependency among other things, but this PR not yet merged. (note: Im talking about gitversiontask only. gitversion from comnand line (or dotnet global tool) should work on sdk 2.1.0 fine.)

As for the warnings, for the most part, unless the msbuild version increment has snuck in breaking changes, then there shouldn't be any problems. I believe you can disable this warning - so simply disabling might be the best bet. I'll look up how best to disable it.

[adamshergold]

@dazinator thanks for the update. I was successfully using 2.1:latest for a number of week (with warnings only) but at some point in the last week it started failing (so one of the recent SDK releases must have broken it). Apart from the warnings everything works very well so for now I'll just pin to 2.1.403 and carry on. thanks!

[dazinator]

@adamshergold

I was successfully using 2.1:latest for a number of week

That's news! Was that with GitVersionTask? One of the main purposes of the pr over here #1422 is to get things working for 2.1. @kll any ideas why it would already work on 2.1 without those PR changes?

[adamshergold]

Yep! Included like this in .fsproj file

    <PackageReference Include="GitVersionTask" Version="4.0.0">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>

Compilation is using CircleCI with docker image specified as microsoft/dotnet:2.1-sdk. Last time this compiled and worked (with warnings) was 2 weeks ago. I just re-triggered a build now (I hadn't made any commits in 2 weeks) and it fails with the error from previous comment.

Thanks!

[Choc13]

We are also using GitVersionTask as a build time dependency and using the 2.1 SDK. Our csproj file contains:

<PackageReference Include="GitVersionTask" Version="4.0.0" PrivateAssets="All" />

[LordMike]

@dazinator I think all in this thread have been running 2.1.403 SDK in builds, with 4.x builds of GitVersionTask. Is this the news? :P

But thanks for the heads up. We'll hold on updating to 2.1.500 for as long as possible.

[dazinator]

fyi this is raised over here: stazz/UtilPack#34

Ultimately, there is some exotic code in utilpack msbuild's task factory, that depends on nuget. However it can't know which version of NuGet MSBuild has already loaded (it depends upon the version of MSBuild being used, which depends on the version of the dotnet core sdk being used). This means it uses reflection and things to find the loaded nuget assembly and types and invoke methods. However what has happened here, is that there have been breaking changes in the NuGet API between these two versions, and so UtilPack is now failing. I am sure the UtilPack author would welcome suggestions on how UtilPack could overcome this here: stazz/UtilPack#34

[stazz]

Hi all,

Yes, the UtilPack task factory, in .NET Core version uses reflection at runtime to detect the version of NuGet.Commands and then choose the actual task factory implementation compiled against that version. The warning that you see is emitted when it can't find a match - meaning that the user's NuGet.Commands assembly is typically newer than the newest one that the task factory was compiled against.

The obvious solution would be to lock down the NuGet version and ship the assemblies with the task factory. That is actually how it is done in .NET Desktop version. However, on .NET Core, when one invokes dotnet build, everything that is in C:\Program Files\dotnet\sdk\<version> folder (on Windows, on Linux it's prolly a bit different, but you get the idea) is marked as "trusted framework assembly". That folder contains all the NuGet assemblies, and once they become trusted framework assemblies, they are not manipulatable via any custom AssemblyLoadContext implementations (at least when I was investigating this few months ago). So there is no way to lock down NuGet version on .NET Core when using dotnet msbuild and it loads the task factory. This leads to the unpleasant reality that @Choc13 correctly observed: every time the user updates his or hers .NET Core SDK, things might break, and I have to re-release the version of task factory which has binary compatibility with the newer NuGet packages.

One solution could be to use global.json to lock down the .NET SDK version to a specific one. That would require most likely custom build scripts within the GitVersionTask that would emit such a file before actual build, or rely on user to provide such a file by himself. Not exactly elegant solution, but is an option. More documentation is available.

Another solution could be using the NuGetUtils.Tool.Exec/ .NET Core Global Tool. Since the global tools don't rely to be ran under dotnet build command, the tool is able to in this case, lock down the NuGet assembly version, thus eliminating this whole problem. The downside is that none of the MSBuild-specific stuff (tasks, logs, etc) is present, so you'd need to replace that with something else. Furthermore, the user of the GitVersionTask would need to have the tool installed, and it only works in .NET Core environment.

To be honest, I don't have a clear solution for this. But I hope I've provided some starting points for a discussion about this.