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.

[stazz]

Related to the trusted framework assemblies: They're actually called "trusted platform assemblies". You can try the following in (git) bash: COREHOST_TRACE=1 dotnet build --help > trace.txt 2>&1 (the file size will be close to 1MB so there will be a lot of output). Then if the trace.txt is opened with text editor, you can see text something like this:

Processing TPA for deps entry [NuGet.Commands, 4.8.1-rtm.5435, lib/netstandard1.6/NuGet.Commands.dll]
  Considering entry [NuGet.Commands/4.8.1-rtm.5435/lib/netstandard1.6/NuGet.Commands.dll], probe dir [], probe fx level:0, entry fx level:0
    Local path query exists C:\Program Files\dotnet\sdk\2.1.403\NuGet.Commands.dll
    Probed deps dir and matched 'C:\Program Files\dotnet\sdk\2.1.403\NuGet.Commands.dll'
Adding tpa entry: C:\Program Files\dotnet\sdk\2.1.403\NuGet.Commands.dll, AssemblyVersion: 4.8.1.0, FileVersion: 4.8.1.5435

IIRC, The fact that the assembly is in TPA list means that it won't be able to be loaded from different location again. This mechanism is the same how the normal (non-dotnet build-invoked) .NET Core ensures that its critical System.XYZ.dll assemblies are loaded exactly once. I might be wrong tho, and maybe behaviour is changed after .NET Core 2.0 release. I could verify this at some point.

[arturcic]

@stazz , thanks for the detailed clarifications.

[stazz]

The 4.9.0-compatible version of UtilPack is now uploaded to nuget.org. It supports NuGet versions from 4.3.0 to 4.9.0. I have an idea about how it would be possible to lock down the NuGet version even in .NET Core environment, but maybe I should open separate issues for that.

Btw, while working on 4.9.0-compatible version of UtilPack, I checked for the NuGet assembly load behaviour, and it is still the same: the methods/events of AssemblyLoadContext never get called for NuGet assemblies.

[LordMike]

With VS2017 15.9, we get SDK 2.1.500 by default, meaning GitVersionTask by default won't work.

Workaround

Place a Globals.json at some parent (f.ex. project or solution root), with contents:

{
  "sdk": {
    "version": "2.1.403"
  }
}

Remove it when GitVersionTask is updated

EDIT: One may also include, next to <PackageReference Include="GitVersionTask" Version="4.0.1-beta*" PrivateAssets="All" /> a <PackageReference Include="UtilPack.NuGet.MSBuild" Version="2.9.0" PrivateAssets="All" /> to force the newer version from @stazz

[dazinator]

This should hopefully be fixed in the latest beta meaning if you update from nuget.org, you should no longer need to pin the sdk version. I'll leave this open until someone can confirm this.

[adamshergold]

Yes - looks like it's fixed. Latest 2.1-sdk image works with no error/warnings against beta1-49 (at least for me). Thanks to all that contributed to fixing it!

[LordMike]

I've run with 4.0.1-beta1-49, and as expected, without my own workaround, there are no warnings as the versions match :P.

[arturcic]

@Choc13 can you also conform it's working for you?

[Choc13]

Hi, I now seeing some errors. Although I should start by pointing out that I'm still using version 2.1.403 of the .NET SDK, so please let me know if this fix is only expected to work against the latest .NET SDK.

Now the first error I encountered was:

C:\Users\<username>\.nuget\packages\gitversiontask\4.0.1-beta1-49\build\functionality\GitVersionBuild.targets(6,5): error MSB4175: The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\Users\m.<username>\.nuget\packages\utilpack.nuget.msbuild\2.9.0\build\\netcoreapp1.1\UtilPack.NuGet.MSBuild.dll". Assembly with same name is already loaded [J:\Workspace\<MyApp>\src\<Proj2>\<Proj2>.csproj]

I reference GitVersion.Task in each project of the solution as this particular solution outputs multiple packages. So I tried removing it from all but one project in the solution and then it managed to get a bit further. However it still produced the following warning and and error:

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.9.0). There might occur some exotic errors. [J:\Workspace\<MyApp>\src\<Proj1>\<Proj1>.csproj]
C:\Users\<username>\.nuget\packages\gitversiontask\4.0.1-beta1-49\build\functionality\GitVersionBuild.targets(6,5): error MSB4175: The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\Users\<username>\.nuget\packages\utilpack.nuget.msbuild\2.9.0\build\\netcoreapp1.1\UtilPack.NuGet.MSBuild.dll". Could not load file or assembly 'NuGet.ProjectModel, Version=4.9.0.6, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. [J:\Workspace\<MyApp>\src\<Proj1>\<Proj1>.csproj]

The warning makes me think that this is because I need to update to the latest .NET SDK. Is that correct?

[dazinator]

Hi @stazz quick question about @Choc13's error above, should util pack 4.9.0 still work with sdk 2.1.403 or did you drop support for 2.1.403 when adding support for >= 2.1.500 ?

[stazz]

The first error is a bit weird, and it is probably caused by the second error:
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.9.0).

The NuGet.Commands version 4.8.1 never got released to nuget.org ( nuget site has only versions 4.8.0 and 4.9.0-rtm.5658 ). My guess is that it tries to use 4.9.0-compiled task factory for 4.8.1 NuGet and that causes the 2nd line of 2nd error message.

I really wasn't prepared for NuGet assemblies to be left out from nuget.org publishing route like that, and there is no clear strategy for the code to use to choose version. I guess I could match just major + minor version but that would most likely cause some new errors in the future. Another way would be to add support for some kind of environment variable to make the task factory use the version of itself which is compiled against NuGet version x.y.z, specified by the environment variable.

[dazinator]

I see thats annoying about the missing nuget publish! Sdk 2.1.500 is when the nuget binary compatibility was broken so it would be great (even if hard coded) for utilpack to only load the task factory compiled for 4.9.0 when on sdk >= 2.1.500. The previous task factory should work for less than sdk 500. Interesting idea about perhaps having a policy like matching on major and minor. Its annoying because semver dictates that breaking changes should increment major version number, but in this case with nuget there appears to be a breaking change but they only bump the minor version. I suspect part of the truth is they are trying to keep major version numbers aligned, and another part is they dont see a strict enough obligation to keep API's stable and backwards / binary compatible - in which case their stuff really should still be in prerelease status, but whatever the reason it seems not a proper use of semver in my view :-( which is a bit ironic that nuget themselves don't follow semver.

[stazz]

The Sdk 2.1.500 includes the 4.9.0 version, and with that the UtilPack works ok. I'll try to release a new version this weekend, which would work with 4.8.1.

How to get my hands on 2.1.403 SDK, by downloading correct docker image and copy the assemblies to mounted folder? :)

[dazinator]

You can get it from here: https://www.microsoft.com/net/download/dotnet-core/2.1

[stazz]

Thanks, that is suspiciously convenient looking site by MS! ;) I'll try to come up with something on sunday!

[LordMike]

@stazz like my workaround above, you can make a Globals.json file containing the desired SDK to run with.

[stazz]

I've released a new version of the task factory, which uses smarter logic to choose version when there is no exact match. It now defaults to use 4.8.0 NuGet on 2.1.403 SDK instead of 4.9.0. Furthermore, there is now ability to completely override the version it uses by specifying UTILPACK_NUGET_VERSION environment variable.

Let me know how it goes - it successfully worked for me in my tests. It still prints out a message in any version mismatches, just not a warning if only build version is mismatched.

[arturcic]

4.0.1-beta1-50 has the latest version of Utilpack included. @Choc13 , @adamshergold , @LordMike , can you give it a try?

[LordMike]

Builds progress without issue with 4.0.1-beta1-50 and utilpack 2.9.1 on my desktop (Windows, SDK 2.1.500). I'll report back if we have more issues with this. :)

[Choc13]

4.0.1-beta1-50 worked on my project using version 2.1.403 of the .NET SDK. There were still version mismatch messages printed out as @stazz said there would be, but no other warnings or errors were present. Good job 👍

[dazinator]

Excellent stuff. Let's close this for now based on that positive feedback ;-)
I don't think having a warning about mismatched versions is a bad thing, and I believe you can ignore / surpress msbuild warnings if you want..

[kieranbenton]

I think I'm still getting issues related to this - using 4.0.1-beta1.50 the build works fine on SDK 2.1.500... BUT when using vscode and omnisharp 1.32.8 I'm getting failures - meaning that intellisense etc isn't working for me. On windows btw.

Exception is:

[info]: OmniSharp.MSBuild.ProjectManager
        Loading project: c:\Source\xxxxxxxx\xxxxxx.csproj
Exception when creating task: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at UtilPack.NuGet.AssemblyLoading.NuGetRestorerWrapper.ResolveNuGetPackageAssemblies(String[] packageID, String[] packageVersion, MarshaledResultSetter`1 setter)
   at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.UseResolver(String[] packageIDs, String[] packageVersions)
   at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.<LoadNuGetAssemblies>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at E_UtilPack.<LoadNuGetAssembly>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.LoadTaskType(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, ConstructorInfo& taskConstructor, Object[]& constructorArguments, Boolean& usesDynamicLoading)
   at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
   at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.CreateExecutionHelper(String taskName, XElement taskBodyElement, String taskPackageID, String taskPackageVersion, String taskAssemblyFullPath, String taskAssemblyPathHint, BoundRestoreCommandUser restorer, ResolverLogger resolverLogger, GetFileItemsDelegate getFiles, String assemblyCopyTargetFolder, AppDomainSetup& appDomainSetup)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.<>c__DisplayClass36_5.<Initialize>b__7()

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

[fail]: OmniSharp.MSBuild.ProjectLoader
        Exception in initialization: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at UtilPack.NuGet.AssemblyLoading.NuGetRestorerWrapper.ResolveNuGetPackageAssemblies(String[] packageID, String[] packageVersion, MarshaledResultSetter`1 setter)
   at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.UseResolver(String[] packageIDs, String[] packageVersions)
   at UtilPack.NuGet.AssemblyLoading.NuGetAssemblyResolverImpl.<LoadNuGetAssemblies>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at E_UtilPack.<LoadNuGetAssembly>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.LoadTaskType(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, ConstructorInfo& taskConstructor, Object[]& constructorArguments, Boolean& usesDynamicLoading)
   at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
   at UtilPack.NuGet.MSBuild.TaskReferenceCreator.CreateTaskReferenceHolder(String taskTypeName, NuGetAssemblyResolver resolver, String packageID, String packageVersion, String assemblyPath, String msbuildFrameworkAssemblyName, ResolverLogger logger)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.CreateExecutionHelper(String taskName, XElement taskBodyElement, String taskPackageID, String taskPackageVersion, String taskAssemblyFullPath, String taskAssemblyPathHint, BoundRestoreCommandUser restorer, ResolverLogger resolverLogger, GetFileItemsDelegate getFiles, String assemblyCopyTargetFolder, AppDomainSetup& appDomainSetup)
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.<>c__DisplayClass36_5.<Initialize>b__7()
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.LazyInitValue()
   at UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory.Initialize(String taskName, IDictionary`2 parameterGroup, String taskBody, IBuildEngine taskFactoryLoggingHost)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

[fail]: OmniSharp.MSBuild.ProjectLoader
        The task factory "UtilPack.NuGet.MSBuild.NuGetTaskRunnerFactory" could not be loaded from the assembly "C:\Users\kiera\.nuget\packages\utilpack.nuget.msbuild\2.9.1\build\\net46\UtilPack.NuGet.MSBuild.dll". Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

[dazinator]

@kieranbenton can you raise the issue with utilpack and omnisharp over here: https://github.com/stazz/UtilPack

[kieranbenton]

Sure. Reported as: stazz/UtilPack#35

[adamshergold]

@arturcic 4.0.1-beta1-50 works fine for me with microsoft/dotnet-sdk:latest so all good!

[kieranbenton]

@adamshergold do you mind me asking what dev environment you use? VS.NET or vscode?

[adamshergold]

@kieranbenton : I develop on a mac using the dotnet sdk (local install) using JetBrains Rider IDE. For CI builds I'm using CircleCI using the microsoft/dotnet-sdk docker image for building. Happy to share more details if helpful for you!

[stazz]

Yeah @kieranbenton 's stack trace is from .NET Desktop version. Interesting, I wonder how and what got broken. Omnisharp has been known to be a little tricky based on @dazinator 's few months old issue. I'll discuss more in issue @kieranbenton opened. :)

[kieranbenton]

@stazz just to be clear (and will continue with this in the other ticket) but this is .NET Core 2.1 NOT '.NET desktop'

[kieranbenton]

@dazinator do you want to reopen this issue or shall I open a new one here for this? This is definitely a problem - and I'm using what I'd consider a pretty common setup.

[dazinator]

If you are just seeing a build warning due to version mismatch, but the build suceeds then this is expected in some situations. It should be possible to disable the msbuild warning if it annoys you. If however you are also seeing an error (i.e with the task factory) then please open a new issue and detail your stack (or provide repro)! Cheers!

[dazinator]

@kieranbenton im addition to above, didn't you already open OmniSharp/omnisharp-roslyn#1350 for your issue? (Assuming its omnisharp)