Support debugging .net standard library used in a .NET Framework (4.6.2) application.

[rmadsen-ks]

I am not sure if this is the right place to post this, but it was the closes match I could find.

I am working on an application that centered around loading .NET based plugins. We want to move to supporting .NET Standard primarily because we want cross platform support. Our primary application is a .NET 4.6.2 WPF application for Windows, but we also support using it with .NET Core from the command line. Hence we want to support developing plugins in .NET Standard, to help ensure that the code will run anywhere.

When using .NET Framework with VS this has always given our customers a more or less flawless developing experience, but we are currently unable to introduce .NET Standard support due to an issue with debugging.

This issue relates to debugging a NET Standard 2.0 library that is used in a .NET framework 4.6.2 application. We want to be able to debug them from visual studio by pointing to the application in launchSettings.json and launching the application with the debugger. However, when I do this the application is launched, and it attaches a debugger but it is unable to load any symbols used in the application, including those of the .NET Standard libraries.

I can manually attach to the process in VS and debug, but the F5 debug command using launchSettings.json does not work. This provides an extra step that our customers need to take and hence hurts the development experience.

I have concluded that it selects the wrong debugger (.NET Core debugger instead of a .NET Framework debugger) for the job, but this is really just a guess.

[livarcocc]

@tmat any idea how to triage this and where this issue should be filled?

@rmadsen-ks I would file a VS Feedback item in VS itself.

[chuckries]

@rmadsen-ks which project are you trying to debug, the .NET Framework WPF Application? Can you share your launchSettings.json file? I'm a little confused why you have a launchSettings.json for a wpf app, I thought these were only used for asp.net debugging.

[rmadsen-ks]

@chuckries, I primarily want to debug the plugin library. But I would also like to debug the application. in case any error is happening there. Most of the time the plugin library is being used from a WPF application. But it should also support .Net Core.

My launchSettings.json file is fairly generic:

{
  "profiles": {
    "Start": {
      "commandName": "Executable",
      "executablePath": "path-to-executable"
    }
  }
}

As mentioned the executable is a .NET Framework 4.6.2 WPF application.

Our current solution is to develop plugin libraries as a .NET Framework 4.6.2 project, which is mostly compatible with .NET Core 2, but if we could move to .NET standard this compatibility would ensured at compile time.

[livarcocc]

I am going to close the issue as this is not really an SDK problem. However, you are welcome to continue talking, this is just an indication that there is not an action here for the SDK team.

I would also file a VS Feedback item for this.

[chuckries]

@rmadsen-ks Here's my guess as to what's happening: The launchSettings.json file is in a .NET Core project that does not actually build the WPF app, but the settings file has an absolute path to the WPF app which has been built somewhere else. All that launchSettings.json is doing is attempting to kick off the executable that it is pointed to and start debugging it. However, since the project is a .NET Core project, it is going to use the .NET Core debugger.

What you want to do is set the solution's startup project to be the WPF project itself. This will cause F5 to debug the WPF app with the .NET Framework debugger.

If you are in a scenario where you do not have the actual WPF project and only have the WPF executable, I would encourage you to create an Exe Project. This is very simple to do: File -> Open -> Project -> browse to your WPF app exe. This will create a new project node in the solution. If you right click on the exe project and select properties, you can change the debugging settings, which includes setting the specific debug engine to Managed V4, V4.5, which is what you will want for WPF.

[rmadsen-ks]

@chuckries, Thanks for your suggestion!

My scenario is close to the next. We are building an Application that is used with a VS SDK plugin, so our users does not have access to the Application code. I think it's a good workaround. It is not optimal, because now we'll have to explain that extra project to the users of our VS SDK plugin, but it's better than having to manually attach.

I think in an ideal world we'd have a bit more flexibility in the launchSettings.json file.

@livarcocc, In my understanding, launchSettings.json is also used when using "dotnet run" from the command line and can be used completely separately from VS. So excuse me, but it seems very dotnet related.