search

dotnet / vscode-csharp

Official C# support for Visual Studio Code
MIT License
2.86k stars 672 forks source link

Failure with .NET Core 2.0.0-preview2 SDK #1495

Closed nguerrera closed 7 years ago

nguerrera commented 7 years ago

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 commented 7 years ago

From @cesarbs on May 18, 2017 20:1

I forgot to add, this happened on macOS.

nguerrera commented 7 years ago

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

cc @DustinCampbell

nguerrera commented 7 years ago

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 commented 7 years ago

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

DustinCampbell commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@emgarten

nguerrera commented 7 years ago

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

DustinCampbell commented 7 years ago

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

DustinCampbell commented 7 years ago

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

DustinCampbell commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

nguerrera commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

nguerrera commented 7 years ago

What runtime is this?

DustinCampbell commented 7 years ago

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

nguerrera commented 7 years ago

Does the same problem happen on Windows?

DustinCampbell commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

DustinCampbell commented 7 years ago

other than in tests

nguerrera commented 7 years ago

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

DustinCampbell commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

nguerrera commented 7 years ago

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 commented 7 years ago

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

DustinCampbell commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

nguerrera commented 7 years ago

@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 commented 7 years ago

yeah, yeah. :smile:

Just looking to lay blame. 😈

emgarten commented 7 years ago

😆 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 commented 7 years ago

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

DustinCampbell commented 7 years ago 
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 commented 7 years ago

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 commented 7 years ago

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

image

nguerrera commented 7 years ago

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

DustinCampbell commented 7 years ago

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 commented 7 years ago

(This isn't confusing at all)

DustinCampbell commented 7 years ago

right.

DustinCampbell commented 7 years ago

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

image

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 commented 7 years ago

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

DustinCampbell commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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.