Failure with .NET Core 2.0.0-preview2 SDK

[nguerrera]

From @cesarbs on May 18, 2017 17:18

Got this in VS Code with the latest pre-release version of the C# extension (1.10.0-beta3):

[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        The "ResolvePackageDependencies" task failed unexpectedly.
This is an unhandled exception from a task -- PLEASE OPEN A BUG AGAINST THE TASK OWNER.
System.TypeLoadException: Could not resolve type with token 01000040
  at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageAndFileDependencies (NuGet.ProjectModel.LockFileTarget target) [0x0011f] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0 
  at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.RaiseLockFileTargets () [0x000a6] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0 
  at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.ExecuteCore () [0x00006] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0 
  at Microsoft.NET.Build.Tasks.TaskBase.Execute () [0x00000] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0 
  at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute () [0x0002a] in <6a1392588f4a45bdbe07807130f9b3d0>:0 
  at Microsoft.Build.BackEnd.TaskBuilder+<ExecuteInstantiatedTask>d__26.MoveNext () [0x002bf] in <6a1392588f4a45bdbe07807130f9b3d0>:0 
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem
        Failed to load project file '/Users/Cesar/src/aspnet/KestrelHttpServer/src/Microsoft.AspNetCore.Server.Kestrel.Core/Microsoft.AspNetCore.Server.Kestrel.Core.csproj'.
/Users/Cesar/src/aspnet/KestrelHttpServer/src/Microsoft.AspNetCore.Server.Kestrel.Core/Microsoft.AspNetCore.Server.Kestrel.Core.csproj

Happens on every project in Kestrel.

dotnet info:

$ dotnet --info
.NET Command Line Tools (2.0.0-preview2-006082)

Product Information:
 Version:            2.0.0-preview2-006082
 Commit SHA-1 hash:  6453cb4e15

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /Users/Cesar/.dotnet/sdk/2.0.0-preview2-006082/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview2-25309-07
  Build    : 41f5fc94eedc889f086800c23f35bf14a8c75a9f

Copied from original issue: dotnet/sdk#1229

[nguerrera]

@DustinCampbell that might be OK as an interim fix, but ultimately you should resolve as VS does

[DustinCampbell]

@nguerrera: I have no idea how that works. Remember that I'm not using MSBuild as VS does.

[DustinCampbell]

Incrementing the version number is good, but that'd only address Windows. It sounds like there's another issue in that Mono turns off SxS assembly loading if MONO_PATH is set (which makes sense). Since we want to have a VS Code experience where installing Mono isn't a prerequisite, that means I'd still want to ship the SDKs for running on OSX/Linux.

[DustinCampbell]

@nguerrera: Once there's a blessed SDK resolver that is packaged so that the community can use it, I'm on board. :smile:

[nguerrera]

Sounds fine. Let's get that on the books.

[DustinCampbell]

I'm not sure how it would solve the assembly resolution issue though.

[nguerrera]

It would not. So we need a versioning scheme for nuget that works. I don't want to punt on this issue because you're not resolving only to have it crop up when you do resolve again. It's important to me that we have a consistent SDK resolution story across VS, VS for Mac, and VS Code.

[nguerrera]

And we probably need to figure out the Mono SxS solution too. Basically fixing that would be a pre-req for moving to resolver.

[DustinCampbell]

Totally agree.

The Mono issue is likely because we're deploying our own Mono runtime to be self-contained. In order to make that work, MONO_PATH is set to the OmniSharp install folder and a folder of framework assemblies (also copied from Mono). It's definitely not a supported scenario.

[DustinCampbell]

@nguerrera: I just chatted with @marek-safar and he let me know about the upcoming mono --assembly-loader flag, which may be what I want to get the same assembly loading behavior on Mono as the .NET Framework. It's in Mono alpha channel builds now.

[DustinCampbell]

@emgarten, @nguerrera: I just tried VS 2017 with a .NET Core 2.0-preview2 drop and it looks like the same NuGet breaking change is breaking live unit testing as well. Here's the live unit testing output:

09:40:45.255 Verbose] - BuildManager - C:\Program Files\dotnet\sdk\2.0.0-preview2-006098\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(155,5): error MSB4018: The "ResolvePackageDependencies" task failed unexpectedly.
System.MissingMethodException: Method not found: 'System.Collections.Generic.IList`1<NuGet.Packaging.Core.PackageDependency> NuGet.ProjectModel.LockFileTargetLibrary.get_Dependencies()'.
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageDependencies(LockFileTargetLibrary package, String targetName, Dictionary`2 resolvedPackageVersions, HashSet`1 transitiveProjectRefs)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageAndFileDependencies(LockFileTarget target)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.RaiseLockFileTargets()
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
[09:40:45.286 Verbose] - BuildManager - C:\Program Files\dotnet\sdk\2.0.0-preview2-006098\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(94,5): error MSB4018: The "GenerateDepsFile" task failed unexpectedly.
System.TypeLoadException: Could not load type 'NuGet.Packaging.Core.PackageIdentity' from assembly 'NuGet.Packaging.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
   at Microsoft.NET.Build.Tasks.GenerateDepsFile.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
[09:40:45.286 Verbose] - BuildManager - Building project ifvm.core.tests.
[09:40:45.380 Info] - BuildManager - Build completed (failed).
[09:40:45.380 Verbose] - BuildManager - Interrupting build queue -> no new assemblies.
[09:40:45.380 Verbose] - BuildManager - Interrupting build queue -> no new assemblies.

Are we sure this change is a good idea? :smile: cc @tannergooding

[DustinCampbell]

And hopefully, this will go away if NuGet increments its assembly version.

[nguerrera]

Is LUT doing builds in proc in devenv?

[DustinCampbell]

No idea. I'm sending email on the issue now to make sure we get it fixed.

[DustinCampbell]

@nguerrera: Logically, I would expect to be doing magical builds in-proc since it needs to work on modified, unsaved files in VS.

[emgarten]

And hopefully, this will go away if NuGet increments its assembly version.

Hoping this also, it would be the easiest fix for NuGet here.

[Jonathan34]

Tried the beta 4, seems to work ok with .net core 2 preview 1. thanks!

[galvesribeiro]

Guys, did this got fixed? I'm getting the same error...

Here is my dotnet --info:

.NET Command Line Tools (2.0.0-preview2-006127)

Product Information:
 Version:            2.0.0-preview2-006127
 Commit SHA-1 hash:  946ea7980a

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.0.0-preview2-006127/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview2-25319-02
  Build    : 7983b575ebcbdc3a825eea4b141ff7fb69d25f9d

I tried VSCode insiders build but no lucky...

[Jonathan34]

Preview 2 is NOT supported AFAIK

[harisbotic]

We need Preview 2 supportttt :(

[DustinCampbell]

Preview 2 builds are not yet supported. These are still bleeding edge nightly builds which need work to properly support. I plan on looking at this in the coming week.

[galvesribeiro]

A light in the end of the tunnel!

Thanks Dustin! :)

[DustinCampbell]

JFYI to those watching that I've gotten a super-hot Mono runtime that demonstrates .NET Core 2.0-preview2 builds working on OSX. A new Mono runtime is needed that adds an --assembly-loader=script flag to replicate desktop CLR SxS assembly loading behavior.

[RainingNight]

We need Preview 2 support on Windows ttt :(

[daxian-dbw]

PowerShell needs Preview 2 support on Windows, OSX and Linux for our development need.

[DustinCampbell]

Support will come folks. 😀 When it's fixed, it'll be fixed for all OSs. I was just giving a bit of status since OSX and Linux require more effort.

@daxian-dbw: I'm not sure how getting C# for VS Code working with the latest nightly .NET Core SDK 2.0-preview2 builds help PoweShell. Could you clarify?

[daxian-dbw]

@DustinCampbell we want to move to the latest 2.0.0-preview2 .NET Core packages to get some fixes from CoreFx, but then we cannot use VS Code C# for the development because it will fail to load the projects with this error:

[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        The version of Microsoft.NET.Sdk used by this project is insufficient to support this package.  Please ensure you are using the .NET Core SDK 2.0 or higher, which is included in Visual Studio 2017 Update 15.3.  This error may be suppressed by setting PackagingToolsInsufficientSDKVersion=false.

Therefore, we cannot move to latest .NET Core 2.0-preview2 packages until this issue is resolved.

[DustinCampbell]

@daxian-dbw: Note that the failure there is different than the failure reported in this thread.

[daxian-dbw]

Ah, yes, that error was what I got when using .NET Core SDK 2.0.0-preview1-005952 with 2.0.0-preview2-25402-02 netcoreapp2.0 runtime framework version. Then I switch to .NET Core SDK 2.0.0-preview2-006195 and got the following error when loading the projects in VS Code:

[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        The "ResolvePackageDependencies" task failed unexpectedly.
System.MissingMethodException: Method not found: 'System.Collections.Generic.IList`1<NuGet.Packaging.Core.PackageDependency> NuGet.ProjectModel.LockFileTargetLibrary.get_Dependencies()'.
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageDependencies(LockFileTargetLibrary package, String targetName, Dictionary`2 resolvedPackageVersions, HashSet`1 transitiveProjectRefs)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageAndFileDependencies(LockFileTarget target)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.RaiseLockFileTargets()
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem
        Failed to load project file 'd:\PowerShell\src\System.Management.Automation\System.Management.Automation.csproj'.
d:\PowerShell\src\System.Management.Automation\System.Management.Automation.csproj

[DustinCampbell]

Got it. I'm going to try to get a beta released today that at least fixes this for Windows. I'm still awaiting the latest Mono bits from Xamarin to address OSX/Linux.

[DustinCampbell]

OK. v1.11.0-beta2 is released. Follow the steps at Installing Beta Releases to get it.

[DustinCampbell]

Note that this only works for Windows until I get those Mono bits.

[brendandixon]

@DustinCampbell Any updates?

[DustinCampbell]

The latest beta fixes the problem on Windows. For OSX/Linux, the new Mono bits dropped on the alpha channel a little while ago and I'll be taking them soon. Once that happens, I'll push another beta that enables OSX/Linux.

[DustinCampbell]

I've just pushed the v1.11.0-beta3 release which includes updated Mono 5.2 bits from the alpha channel. This should fix .NET Core 2.0 support on OSX/Linux. Please try the beta out! You can download it from v1.11.0-beta3. Follow the instructions in Installing Beta Releases to install.

[daxian-dbw]

Thanks @DustinCampbell! Any idea when the v1.11.0 release will be made public?

[DustinCampbell]

Not for awhile yet. Note that we don't necessarily want to officially ship this until the bits it's using are more officially released. After all, the .NET Core 2.0-preview2 bits aren't official yet either.

[julielerman]

Just checking that with this new beta extension running on macOS, is it expected that I would not get Intellisense or document formatting? If I should be seeing those ...any hints as to what I'm doing wrong? :) This is the net core 2.0.0 build I'm using: https://github.com/dotnet/cli/tree/release/2.0.0

[DustinCampbell]

Unfortunately, we discovered an issue just today that breaks .NET Core 2.0-preview2 support in C# for VS Code on OSX/Linux. The most recent .NET Core SDK has some changes that exasperate an issue in the Mono runtime. A PR is out for the Mono issue, so this will come soon. However, for now VS Code won't work for the very latest, super-hot builds on OSX/Linux.

[julielerman]

okey doke. And for my purposes, it's sufficient. Though I keep surprising myself when things build. :) Thanks!

[DustinCampbell]

Sorry for the delay on this @julielerman!

[julielerman]

no apology needed. I'm just exploring for now. Not stressing over production code.

[julielerman]

p.s. I'll try it out in windows

[harisbotic]

Download leatest Mono 5.2 alpha, delete current C# plugin in vs code (reload vs), download leatest C# plugin (from this repo) which is in beta and install it manually in vs code with .vsix file that you downloaded

[DustinCampbell]

@harisbotic: you don't need to download Mono 5.2. C# for VS Code includes a local Mono 5.2. As I mentioned earlier, the very latest .NET Core 2.0-preview2 SDK doesn't work due to some recent changes in the SDK that collides with a but in Mono 5.2.

[DustinCampbell]

@julielerman: You can track https://github.com/OmniSharp/omnisharp-vscode/issues/1566 to track OSX/Linux support on the very latest .NET Core 2.0 Preview 2 builds. If you're curious, there are specific details about what is actually broken.

[julielerman]

Thanks. In the meantime, things seem to be working well in windows VS Code. :)

[DustinCampbell]

Yup. The difference here is that we run on OmniSharp on the desktop CLR on Windows and a local Mono runtime on OSX/Linux. I'm tracking one last bug on the Mono runtime that should fix this problem.

[DustinCampbell]

FYI: I just put up a new beta release of C# for VS Code that actually fixes this issue on OSX/Linux. :smile:

[galvesribeiro]

Lets hope next build of CLR don't break it again, ehhehehe :P