Debug adapter process has terminated unexpectedly on OpenSUSE 42.2

[weinand]

From @matteopasqualin on November 22, 2016 8:59

• VSCode Version: Code 1.7.1 (02611b40b24c9df2726ad8b33f5ef5f67ac30b44, 2016-11-03T13:46:46.244Z)
• OS Version: Linux x64 4.4.27-2-default
• Extensions: C#

Extension	Author	Version
csharp	ms-vscode	1.5.3

Hello, I'm running a simple web app with Linux distro OpenSUSE 42.2.
My project.json file:

{ "dependencies": { "Microsoft.NETCore.App": { "version": "1.1", "type": "platform" }, "Microsoft.AspNetCore.Diagnostics": "1.1.0", "Microsoft.AspNetCore.Mvc": "1.1.0", "Microsoft.AspNetCore.Razor.Tools": { "version": "1.0.0-preview2-final", "type": "build" }, "Microsoft.AspNetCore.Routing": "1.1.0", "Microsoft.AspNetCore.Server.IISIntegration": "1.1.0", "Microsoft.AspNetCore.Server.Kestrel": "1.1.0", "Microsoft.AspNetCore.StaticFiles": "1.1.0", "Microsoft.Extensions.Configuration": "1.1.0", "Microsoft.Extensions.Configuration.EnvironmentVariables": "1.1.0", "Microsoft.Extensions.Configuration.Json": "1.1.0", "Microsoft.Extensions.Configuration.CommandLine": "1.1.0", "Microsoft.Extensions.Logging": "1.1.0", "Microsoft.Extensions.Logging.Console": "1.1.0", "Microsoft.Extensions.Logging.Debug": "1.1.0", "Microsoft.Extensions.Options.ConfigurationExtensions": "1.1.0", "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.1.0", "Microsoft.EntityFrameworkCore": "1.1.0", "Microsoft.EntityFrameworkCore.Tools": "1.1.0-preview4-final", "MySql.Data.Core": "7.0.4-ir-191", "MySql.Data.EntityFrameworkCore": "7.0.6-ir31" }, "tools": { "BundlerMinifier.Core": "2.0.238", "Microsoft.AspNetCore.Razor.Tools": "1.0.0-preview2-final", "Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final", "Microsoft.EntityFrameworkCore.Tools.DotNet": "1.1.0-preview4-final" }, "frameworks": { "netcoreapp1.1": { "imports": [ "dotnet5.6", "portable-net45+win8", "dnxcore50" ] } }, "buildOptions": { "emitEntryPoint": true, "preserveCompilationContext": true, "copyToOutput": { "include": "appsettings.json" } }, "runtimeOptions": { "configProperties": { "System.GC.Server": true } }, "publishOptions": { "include": [ "wwwroot", "**/*.cshtml", "appsettings.json", "web.config" ] }, "scripts": { "precompile": [ "dotnet bundle" ], "prepublish": [ "bower install" ], "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ] }, "tooling": { "defaultNamespace": "WebApplicationBasic" } }

Steps to Reproduce:

1. Run debug from VS Code

Copied from original issue: microsoft/vscode#15867

[gregg-miskelly]

@matteopasqualin my guess is that openSUSE 42.2 isn't going to work yet - with the bits you have, the debugger is using the openSUSE 13.2 version of .NET Core, and I am guessing it is crashing at startup. For .NET Core 1.1 there is now an openSUSE 42.1 version of .NET Core. We are in the process of moving to 1.1 and I expect our next release to add this. So if openSUSE 42.2 is binary compatible with 42.1 for the APIs that .NET Core cares about, our next release should resolve your issue.

Are you using the official 42.1 .NET Core binaries? Or did you build your own? If you are using the official ones, does everything besides debugging seem to work?

[matteopasqualin]

Hello Gregg,
I'm glad you will fix it. Yes I confirm I saw somewhere in the docs refrencing to 42.1 LTS version and not 42.2, but I thought there is no big change of pacakges between the two versions.

Are you using the official 42.1 .NET Core binaries? Or did you build your own?

The official ones, I did a fresh install from the link below:
https://www.microsoft.com/net/core#linuxopensuse

I did another try before this post, this time with the "Hello World" simplest example from the above link.
I get the same result, please have a look at the screenshot.
I've just updated the Editor, my current version is: 1.7.2

I am overall sutisfied, restoring and building projects works fine, both from the shell and the Editor.
2/3 months ago, to me, was almost impossible to work with .NET Core on openSUSE.

Please, feel free to ask for further feedback or tests.
Thanks a lot and keep up with the good job.

[gregg-miskelly]

Thanks @matteopasqualin. I will try to get a beta release out soon that you can try to confirm/deny if this is the issue.

[matteopasqualin]

Fine, all right.

[gregg-miskelly]

@matteopasqualin I've created a v1.6-beta3 release of the C# extension that I hope addresses this. See this page for information on installing beta releases.

[matteopasqualin]

Hello Gregg, yes, it works now with the .vsix release. Here are the screenshots as feedback. 1. Updated dependencies after installing the new extension:  2. Console app at debugging  I did a test also with .NET Core web app in an IActionResult method and it works fine. PS. Maybe the task is up to developers at the Editor: if you did a "dotnet run" and then start debugging, the framework throws an exception saying Kestrel is already in use. If possible and as a suggestion, I would intercept the case at start debugging and: - prevent debug from executing - show a warning about the service is running. Thanks Matteo ​ ​ 2016-11-30 21:16 GMT+01:00 Gregg Miskelly <[email protected]>:

…

@matteopasqualin <https://github.com/matteopasqualin> I've created a v1.6-beta3 <https://github.com/OmniSharp/omnisharp-vscode/releases/tag/v1.6-beta3> release of the C# extension that I hope addresses this. See this page for information on installing beta releases <https://github.com/OmniSharp/omnisharp-vscode/wiki/Installing-Beta-Releases> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#978 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQI2qvJic1kqqr6Sn-MFVUMgi6z-oE_5ks5rDdmRgaJpZM4K5X4p> .

[gregg-miskelly]

@matteopasqualin Thanks for verifying!

The debugger (or the build system if you get a build error) doesn't have any understanding of what port the app is going to run on when we start debugging. So there isn't much we can do about that.

[gregg-miskelly]

@matteopasqualin not sure if you were seeing the exception from the running program, or the build error, but I decided that the exception experience was a little confusing in this case, so I did open up this bug to try and improve that: #1007.

I am closing this one since the original issue is now fixed.

[matteopasqualin]

Hello Gregg,
clear, I see. Thanks.