Omnisharp-vscode: 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]

_From @cesarbs on May 18, 2017 20:1_

I forgot to add, this happened on macOS.

[nguerrera]

@cesarbs Does it only fail in VS Code or also when doing dotnet restore && dotnet build on the command line?

cc @DustinCampbell

[nguerrera]

_From @DustinCampbell on May 18, 2017 23:21_

I believe the issue is that OmniSharp is using NuGet.ProjectModel 4.0.0, but the latest SDK is using 4.3. I'm updating OmniSharp now.

FWIW, this can be moved to the C# for VS Code repo (https://github.com/OmniSharp/omnisharp-vscode).

[DustinCampbell]

I hope to have a new beta of C# for VS Code tomorrow that will hopefully address this problem.

[DustinCampbell]

Hmmm... I'm running into some problems here. @nguerrera: I'm starting to see signs that there are breaking API changes in the NuGet packages that the SDK is using. I'm digging further and will let you know what I find.

[DustinCampbell]

@nguerrera: It looks like the there's a major NuGet breaking change in the more recent bits that the SDK is using. NuGet.Packaging.Core no longer includes a reference to NuGet.Packaging.Core.Types. Instead, it looks like all of the types that were in NuGet.Packaging.Core.Types have been moved to NuGet.Packaging.Core. Do you know anything about this, or could you loop in somebody who does?

[nguerrera]

@emgarten

[nguerrera]

We had a world of hurt upgrading things in the sdk due to these changes.

[DustinCampbell]

I bet. I'm feeling it now. :smile:

[DustinCampbell]

FWIW, this is very tricky to fix without breaking project.json support.

[DustinCampbell]

Hey @nguerrera, do you know how VS deals with this problem? Essentially, the problem boils down to using MSBuild in-proc. So, the assemblies referenced by a task get to use the ones already loaded in proc.

[nguerrera]

I think our tasks are always loaded out of proc by CPS, but P2P from non CPS can cause problems, which we've hit before. I think we're only ok if VS also loads a compatible nuget in that case.

[nguerrera]

I'm tempted to il-merge our build task dependencies.

[nguerrera]

Actually, if asm versions are different nuget should load sxs in devenv. I think the past issues were build to build breaks with same asm version.

[DustinCampbell]

but what's a compatible NuGet? Any members in other packages that exposed types from NuGet.Packaging.Core.Types will now cause MissingMethodExceptions. The first one I hit is NuGet.ProjectModel.LockFileTargetLibrary.get_Dependencies because it returns an IList<PackageDependency>, which has moved. At the moment, I can get this to work for .NET Core SDK 1.0.0->2.0.0-preview1, _or_ I can get it to work for .NET Core SDK 2.0.0-preview2.

[nguerrera]

Our tasks don't exchange nuget types with anything else. So it should be possible to load 4.0 and 4.3 sxs and not break us. I don't know if that's doable in your runtime environment, though.

[DustinCampbell]

MSBuild is doing the loading and we use it in-proc. I'm not sure how I'd do it sxs.

[nguerrera]

What runtime is this?

[DustinCampbell]

Mono on OSX/Linux, .NET Framework on Windows.

[nguerrera]

Does the same problem happen on Windows?

[DustinCampbell]

It may be that there's a hole in my MSBuild knowledge. Maybe there's a way to tell MSBuild to use AppDomains for any task? @rainersigwald?

[DustinCampbell]

Does the same problem happen on Windows?

My Windows machine isn't quite clean enough to verify. We have code in OmniSharp that tells it to just use MSBuild from VS 2017 if it's there. Give me a few minutes to remove that and try.

[DustinCampbell]

I've been unsuccessful getting the issue to repro on Windows so far :smile:

[DustinCampbell]

other than in tests

[nguerrera]

Can you see in the debugger if both versions are successfully loaded SxS on Windows, but not on Mono?

[DustinCampbell]

honestly, I wouldn't even know how to debug that on Mono :smile:

I'm not confident I've got things right on Windows at the moment. Tests are failing.

[rainersigwald]

I don't think there's a way to force MSBuild to use AppDomain isolation--it has to be opted in in code (task derives from AppDomainIsolatedTask or process isolation must be opted into with a UsingTask.

@radical might have thoughts about Mono behaviors here.

[DustinCampbell]

that's what I thought @rainersigwald, just wanted to be sure there wasn't something awesome I was missing. :smile:

[nguerrera]

Why do you think AppDomains are required? Assemblies can be SxS loaded in same domain and that is what I'd expect to happen if a Task has a newer version sitting next to it on full fx.

[DustinCampbell]

I don't think AppDomains are necessarily required. I was just curious if MSBuild had any special magic to isolate things.

[DustinCampbell]

Assemblies can be SxS loaded in same domain and that is what I'd expect to happen if a Task has a newer version sitting next to it on full fx

@nguerrera: I would expect that too, but I'm not seeing it happen on Mono. I wonder if that's a side-effect of using an embedded Mono runtime and setting MONO_PATH specifically. Perhaps when MSBuild does an Assembly.LoadFrom(...) on the task, it doesn't look next to the task for its dependencies because MONO_PATH is set?

[emgarten]

NuGet merged several assemblies in 4.3.0 as mentioned earlier.

It sounds like this may be related to https://github.com/dotnet/cli/issues/4214
MSBuild favors the nuget assemblies in the msbuild folder.

[radical]

If you run with MONO_LOG_LEVEL=debug MONO_LOG_MASK=asm then you should see messages about mono searching for assemblies, adding to domains or failing to do etc.

[DustinCampbell]

@emgarten: Isn't that a semver breaking change?

[nguerrera]

@DustinCampbell It is. And if it were v5, you'd still be in the same world of hurt, which is what I keep telling semver fanboys.

[DustinCampbell]

yeah, yeah. :smile:

Just looking to lay blame. 😈

[emgarten]

😆 yes

I'm all for SemVer but it would be like @nguerrera said, plus every NuGet assembly would have a different major version and none of it would align with the CLI or VS.

[nguerrera]

Or your could, you know, stop making breaking changes every release.

[DustinCampbell]

Mono: Assembly Loader probing location: '/usr/local/share/dotnet/sdk/2.0.0-preview2-006080/Sdks/Microsoft.NET.Sdk/build/../tools/net46/Microsoft.NET.Build.Tasks.dll'.
Mono: Image addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> /usr/local/share/dotnet/sdk/2.0.0-preview2-006080/Sdks/Microsoft.NET.Sdk/tools/net46/Microsoft.NET.Build.Tasks.dll[0x7f7f5c00]: 2
Mono: Prepared to set up assembly 'Microsoft.NET.Build.Tasks' (/usr/local/share/dotnet/sdk/2.0.0-preview2-006080/Sdks/Microsoft.NET.Sdk/tools/net46/Microsoft.NET.Build.Tasks.dll)
Mono: Assembly Microsoft.NET.Build.Tasks[0x7e6bab30] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/usr/local/share/dotnet/sdk/2.0.0-preview2-006080/Sdks/Microsoft.NET.Sdk/build/../tools/net46/Microsoft.NET.Build.Tasks.dll'.
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> Microsoft.Build.Utilities.Core[0x7e237ba0]: 2
Mono: Assembly Ref addref Microsoft.Build.Utilities.Core[0x7e237ba0] -> Microsoft.Build.Framework[0x7be6b360]: 4
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> mscorlib[0x7a76f910]: 68
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> System.Core[0x7b98d0b0]: 24
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.ProjectModel.dll'.
Mono: Image addref NuGet.ProjectModel[0x7e5bb490] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.ProjectModel.dll[0x7addd800]: 2
Mono: Prepared to set up assembly 'NuGet.ProjectModel' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.ProjectModel.dll)
Mono: Assembly NuGet.ProjectModel[0x7e5bb490] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.ProjectModel.dll'.
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> NuGet.ProjectModel[0x7e5bb490]: 2
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> mscorlib[0x7a76f910]: 69
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> Microsoft.Build.Framework[0x7be6b360]: 5
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Frameworks[0x7e254610]: 4
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Common.dll'.
Mono: Image addref NuGet.Common[0x7e5c12a0] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Common.dll[0x7adfc200]: 2
Mono: Prepared to set up assembly 'NuGet.Common' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Common.dll)
Mono: Assembly NuGet.Common[0x7e5c12a0] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Common.dll'.
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> NuGet.Common[0x7e5c12a0]: 2
Mono: Assembly Ref addref NuGet.Common[0x7e5c12a0] -> mscorlib[0x7a76f910]: 70
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Common[0x7e5c12a0]: 3
Mono: Assembly Ref addref NuGet.Frameworks[0x7e254610] -> System[0x7b97e680]: 24
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> Newtonsoft.Json[0x7a727960]: 5
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> System[0x7b97e680]: 25
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Versioning[0x7e25b2a0]: 4
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.Types.dll'.
Mono: Image addref NuGet.Packaging.Core.Types[0x7e2120e0] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.Types.dll[0x7b660800]: 2
Mono: Prepared to set up assembly 'NuGet.Packaging.Core.Types' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.Types.dll)
Mono: Assembly NuGet.Packaging.Core.Types[0x7e2120e0] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.Types.dll'.
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Packaging.Core.Types[0x7e2120e0]: 2
Mono: Assembly Ref addref NuGet.Packaging.Core.Types[0x7e2120e0] -> mscorlib[0x7a76f910]: 71
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> System.Core[0x7b98d0b0]: 25
Mono: Assembly Ref addref NuGet.Frameworks[0x7e254610] -> System.Core[0x7b98d0b0]: 26
Mono: Assembly Ref addref NuGet.Packaging.Core.Types[0x7e2120e0] -> NuGet.Versioning[0x7e25b2a0]: 5
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.LibraryModel.dll'.
Mono: Image addref NuGet.LibraryModel[0x7e6c89a0] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.LibraryModel.dll[0x7f1f3a00]: 2
Mono: Prepared to set up assembly 'NuGet.LibraryModel' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.LibraryModel.dll)
Mono: Assembly NuGet.LibraryModel[0x7e6c89a0] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.LibraryModel.dll'.
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.LibraryModel[0x7e6c89a0]: 2
Mono: Assembly Ref addref NuGet.LibraryModel[0x7e6c89a0] -> mscorlib[0x7a76f910]: 72
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.RuntimeModel.dll'.
Mono: Image addref NuGet.RuntimeModel[0x7e20b6d0] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.RuntimeModel.dll[0x7b669a00]: 2
Mono: Prepared to set up assembly 'NuGet.RuntimeModel' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.RuntimeModel.dll)
Mono: Assembly NuGet.RuntimeModel[0x7e20b6d0] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.RuntimeModel.dll'.
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.RuntimeModel[0x7e20b6d0]: 2
Mono: Assembly Ref addref NuGet.RuntimeModel[0x7e20b6d0] -> mscorlib[0x7a76f910]: 73
Mono: Assembly Ref addref NuGet.RuntimeModel[0x7e20b6d0] -> Newtonsoft.Json[0x7a727960]: 6
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Configuration.dll'.
Mono: Image addref NuGet.Configuration[0x7e2094a0] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Configuration.dll[0x7b60b200]: 2
Mono: Prepared to set up assembly 'NuGet.Configuration' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Configuration.dll)
Mono: Assembly NuGet.Configuration[0x7e2094a0] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Configuration.dll'.
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Configuration[0x7e2094a0]: 2
Mono: Assembly Ref addref NuGet.Configuration[0x7e2094a0] -> mscorlib[0x7a76f910]: 74
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.dll'.
Mono: Image addref NuGet.Packaging.Core[0x7e208980] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.dll[0x7b685c00]: 2
Mono: Prepared to set up assembly 'NuGet.Packaging.Core' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.dll)
Mono: Assembly NuGet.Packaging.Core[0x7e208980] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.dll'.
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Packaging.Core[0x7e208980]: 2
Mono: Assembly Ref addref NuGet.Packaging.Core[0x7e208980] -> mscorlib[0x7a76f910]: 75
Mono: Assembly Ref addref NuGet.RuntimeModel[0x7e20b6d0] -> System.Core[0x7b98d0b0]: 27
Mono: Assembly Ref addref NuGet.RuntimeModel[0x7e20b6d0] -> NuGet.Frameworks[0x7e254610]: 5
Mono: Assembly Ref addref NuGet.LibraryModel[0x7e6c89a0] -> System.Core[0x7b98d0b0]: 28
Mono: Assembly Ref addref NuGet.LibraryModel[0x7e6c89a0] -> NuGet.Versioning[0x7e25b2a0]: 6
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> NuGet.Frameworks[0x7e254610]: 6
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> NuGet.Versioning[0x7e25b2a0]: 7
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> NuGet.Packaging.Core[0x7e208980]: 3
[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 <bdf083ca20c84af487947992fd9a4a29>:0 
  at Microsoft.Build.BackEnd.TaskBuilder+<ExecuteInstantiatedTask>d__26.MoveNext () [0x002bf] in <bdf083ca20c84af487947992fd9a4a29>:0 

Mono's clearly preferring them in the application folder as I expected. My gut is that this is because MONO_PATH is specifically set. @radical, do you have any ideas?

[DustinCampbell]

FWIW, I see the same problem when I use a machine-wide mono rather than the embedded one. It does not seem like Mono wants to load different assemblies SxS. Note that these are technically the same versions. Both are 4.3.0 since the NuGet breaking change was made without changing assembly versions _(shakes fist at @emgarten)_.

[DustinCampbell]

OK @nguerrera: I can verify that it does work on Windows. At least, I can see the libraries double-loaded correctly:

[nguerrera]

I'm surprised if it worked on Windows if both sets have same assembly version. LoadFrom doesn't work like that.

[DustinCampbell]

In the above case, it didn't. This is a build of OmniSharp where I've referenced the 4.3 NuGet versions. Note that the project I opened was using SDK 1.0.4.

[nguerrera]

(This isn't confusing at all)

[DustinCampbell]

right.

[DustinCampbell]

And I can prove that doesn't work by trying a project created with .NET Core SDK 2.0.0-preview1.

And of course, it fails:

[info]: OmniSharp.MSBuild.MSBuildProjectSystem
        Loading project: c:\Projects\test-2.0.0-preview1-005952\test-2.0.0-preview1-005952.csproj
[dbug]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        Using MSBuildSDKsPath: C:\Program Files\dotnet\sdk\2.0.0-preview1-005952\Sdks
[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()

[DustinCampbell]

Essentially, I can either support .NET Core 2.0.0-preview1 or .NET Core 2.0.0-preview2, but not both.

[DustinCampbell]

It seems like the cheapest thing I could do is just go back to shipping the SDKs with OmniSharp and not trying to resolve them at all.

[nguerrera]

@emgarten can you bump the nuget version? Then preview 2 can take that and preview 1 can keep 4.3. Then there'd only be interim preview 2 builds that are broken.

[nguerrera]

At one point nuget tried bumping every build, and that causes problems of its own. Moving forward, should only bump on breaking changes. But also, seriously, ease off the pace at which those happen.

[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

[DustinCampbell]

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

I'm not sure what you mean. The CLR hasn't been an issue in this thread.

[galvesribeiro]

@DustinCampbell It happened with very last netcore 2.0 bits and that include the SDK, CLR, right? I meant that we are not sure if a new build of netcore would not break again, just like in this issue. But in all cases, good work :) thanks for get it back working for us :)

[julielerman]

thanks. The simple things I was missing like formatting an intellisense an help to do things like "hey you need a ref to this assembly" are all working again as expected! :)

[DustinCampbell]

@galvesribeiro: C# for VS Code doesn't run OmniSharp on .NET Core. On Windows, it runs on the desktop CLR that's already installed. On OSX/Linux, it runs on a local Mono that C# for VS Code installs.

There were three problems that sort of cascaded into a perfect storm of fail. :smile:

1. NuGet made API breaking changes without updating their assembly version numbers. When those changes were deployed with the .NET Core SDK, many things broke, such as C# for VS Code and Live Unit Testing in Visual Studio 2017. This has been fixed and included in newer .NET Core SDK builds.
2. On OSX/Linux, we needed to deploy a new Mono runtime with a new "strict assembly loader" feature to ensure that assemblies with different versions can be loaded side-by-side (just like they are on the CLR on Windows). This was necessary because of the NuGet changes above. OmniSharp itself deploys 4.0.0.0 versions of some NuGet assemblies and the latest .NET Core SDK deploys newer versions. Since these two versions have different API surface area, they collided badly.
3. There was a bug in the "strict assembly loader" feature on Mono that I discovered yesterday. There are more details on that issue in https://github.com/OmniSharp/omnisharp-vscode/issues/1566.

Now, we're in a much better place for not getting broken in the future.

[DustinCampbell]

thanks. The simple things I was missing like formatting an intellisense an help to do things like "hey you need a ref to this assembly" are all working again as expected! :)

Excellent! I'll expect a hug and a beer when I see you next. :grin:

[galvesribeiro]

Yay! Good news @DustinCampbell! Thanks for the clarification.