Unmanaged debugger support #2696
Conversation
| { | ||
| // The engine depends on the framework | ||
| if (IsDotNetCoreFramework(targetFramework)) | ||
| { | ||
| if (mixedMode) throw new Exception(VSResources.UnmanagedDebuggingNetCoreNotSupported); |
There was a problem hiding this comment.
I thought this was supported in NETCore 2.0.. @gregg-miskelly is unmanaged debugging supported for .NET Core 2.0?
There was a problem hiding this comment.
@srivatsn looking at the DebuggingEngines type, I see this:
public static readonly Guid ManagedLegacyEngine;
public static readonly Guid SqlEngine;
public static readonly Guid NativeOnlyEngine;
public static readonly Guid ManagedOnlyEngine;
public static readonly Guid MixedNativeAndManagedEngine;
public static readonly Guid ScriptEngine;
public static readonly Guid GPUDebugEngine;
public static readonly Guid ManagedCoreEngine;
I didn't see one for MixedNativeAndCoreEngine?
There was a problem hiding this comment.
It is supported in .NET Core 2.0. To enable it - pass ManagedCoreEngine as the launching engine, and NativeOnly in the additional engines. However, there is a bug in VS 2017 15.3 where it doesn't work very well. We can port it to 15.4 if you are trying to enable this scenarios for an earlier VS.
There was a problem hiding this comment.
Thanks, I'll update this PR to do that for net core. Is that also the right way for net framework, or is returning the MixedNativeAndManagedEngine value the right way?
There was a problem hiding this comment.
The most common way that project systems do it is with MixedNativeAndManagedEngine, but passing both engines should work as well. So you should be able to just add on the native engine if you want to be consistent.
clairernovotny
changed the title
|
Perfect, consistency helps keep this code cleaner, so I'll do that and verify. Is there an issue tracking the net core native debugger issue? I'd love to see the fix in 15.4, but that's not my call :) |
|
I'll look over this tomorrow - but this does not meet our bar for 15.4, at this point it will be for 15.5. |
clairernovotny
changed the title
|
The debugger bug is https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_queries?id=446401 (note: you must be a Microsoft employee to access this). |
|
Closing in favor of #2766 |
Customer scenario
The scenario is enabling mixed-mode debugging with .NET Framework and .NET Core targets
Bugs this fixes:
Partial fix for #1125 (adds setting to lauchsettings.json but does not have a UI to configure)
Workarounds, if any
None. Must use a legacy project as the startup project and point to a CPS project output.
Risk
Low? The change is to add a new property to
launchSettings.jsonand pass it through related code to the location which determines which debugger GUID to use.Performance impact
Low? Passing one extra boolean from config to use to return the correct GUID.
Is this a regression from a previous update?
No. This project system never supported mixed mode debugging
Root cause analysis:
Simply not supported?
To use
Create a new .NET Framework exe project with this project system. Edit the
launchSettings.jsonto add the following property:"enableUnmanagedDebugging": true. Now debug. You'll get the mixed mode debugger instead of the managed only debugger.This PR does implement support for mixed mode debugging of .NET Core projects, but at least with .NET Core 2 preview 2, it wouldn't work for me. I didn't hit the managed breakpoint when enabled. Seems like there's an additional fix for this that's needed according to @gregg-miskelly.