OmniSharp does not support .NET Core SDK 2.0-preview2 builds #865
Comments
|
The log above appears to be running OmniSharp from 1.10-beta2, not 1.10-beta3, is that correct? Also, could you set |
|
@DustinCampbell Yeah, I forgot to re-capture the log after testing on beta3. Sorry about that! I can say that beta3 breaks exactly the same as beta2 does, however. I will get you a more detailed log later today. Thanks! |
|
Note that the biggest difference is that OmniSharp no longer includes the various .NET SDKs. Instead, it tries to locate the .NET CLI relevant for a project and use the SDKs from there. I suspect the issue is going to be something around that. |
|
Here is the debug log for OmniSharp. Note that this problem only occurs on my Mac workstation; my Windows 10 workstation loads the solution just fine. |
|
OK. I see that you are using bleeding edge .NET Core SDK bits. Let me try that and see if something's been broken. |
|
OK. I can repro this with the latest .NET CLI. It looks like the most recent nightlies are busted. There are working for me if I use the latest 2.0.0-preview1 build from https://github.com/dotnet/cli/tree/release/2.0.0. cc @livarcocc |
|
Reopening I can verify that this is really fixed. |
|
@DustinCampbell Unfortunately, at least for me, it still doesn’t work. Having built omnisharp-roslyn from source, I instructed VSCode to use the |
|
Yup, I'm actively looking at this. I'm rebuilding OmniSharp locally right now using the same NuGet package version that the SDK does: https://github.com/dotnet/sdk/blob/master/build/DependencyVersions.props#L13 Note: I'm also tracking this on the C# for VS Code repo here: dotnet/vscode-csharp#1495 |
|
@wjk: It looks like there's a significant break in the NuGet API between 4.0.0 and 4.3.0 Apparently, NuGet.Packaging.Core.Types is being removed and its types are inlined into NuGet.Packaging.Core. This is causing some headaches. |
|
@DustinCampbell so am I seeing the same issue you've just described? I'm using 1.10.0-beta5 and my .NET Core 2.0.0 projects fail to load with: |
|
Yup. This is a problem if you use .NET Core SDK 2.0-preview2 builds. The issue stems from the fact that several types were moved around in NuGet binaries within their 4.3.0 preview builds without updating the assembly version numbers. This also breaks the Live Unit Testing for .NET Core feature in Visual Studio 2017 15.3 preview 1 for the same reason. The problem is compounded in OmniSharp because the Mono 4.8 runtime doesn't support SxS loading of assemblies that differ by version number. I'll be taking a newer Mono runtime build that fixes this issue. |
DustinCampbell
changed the title
|
I've pushed a new release that should fix the issue on Windows and netcoreapp builds of OmniSharp. Mono builds are still busted because they require a new version of Mono that is not yet (5.2) which includes a brand new |
|
@DustinCampbell It works, all right! My .NET Core 2.0 project now loads successfully with full IntelliSense. I would appreciate knowing when the Mac version is fixed as well, though. I'll let you decide when it would be appropriate to close this issue. Thank you very much! |
|
Glad to hear it! I'll close this once the new 5.2 Mono bits show up in the channel and I can update omnisharp-vscode with them. I'm told that will likely happen this week. |
|
OK. I've gotten newer 5.2 Mono bits and updated omnisharp-vscode. There is a new beta available there that should fix this on OSX and Linux. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using the version of OmniSharp included with
omnisharp-vscodeversion 1.10.0-beta3 with Visual Studio Code on my (proprietary) .NET Core project, I get a very strange error on eachcsprojin my solution. The full OmniSharp log is included:What makes this so hard to diagnose, is that it doesn’t tell me which type it is failing to load! It simply says
token 01000040, which could mean anything. My best guess is that it can’t find or can’t load the NuGet build-time assembly, because the stack frame just before the error includes a type from that assembly in the signature.The version of OmniSharp included in
omnisharp-vscode1.9.0 parses this solution without complaint. Any pointers? Thanks!The text was updated successfully, but these errors were encountered: