Desktop projects have

I can't find this option in .NET Core project. I need to F5 with mixed mode debugging in order to debug some interop code.
Oh, I guess I know why:

Seems like the debugger doesn't support interop debugging with CoreCLR :(
@noahfalk I hear this is CoreCLR issue but I couldn't find an issue in the coreclr repo that would be tracking it.
@mikem8361 might be able to point you at something or you can create one now
The latest coreclr master branch (.NET Core 2.0) has mixed mode debugging enabled for Windows.
Since this checkbox will apparently not be implemented in VS2017, is there any workaround apart from starting the program and attaching the debugger manually? This is extremely cumbersome as I have to guess the right "dotnet" process in the process list, since I have multiple dotnet core applications running concurrently, but I only want to debug a specific one.
I tried adding <EnableUnmanagedDebugging>true</EnableUnmanagedDebugging> to a PropertyGroup of the csproj file, but unfortunately, it had no effect. Would it be possible to implement support for the functionality even without exposing it in the UI, if there is not enough time to do both?
Hmm, looks like we don't currently respect the legacy debugger settings with the new debugger provider that we wrote. This is where we control it: https://github.com/dotnet/project-system/blob/master/src/Microsoft.VisualStudio.ProjectSystem.Managed.VS/ProjectSystem/VS/Debug/ProjectDebuggerProvider.cs#L76, that's really unfortunate, because the provider that this replaces does support it.
@srivatsn Given interop debugging is supported in 2.0, we should enable this for 2.0.
Keep in mind that this also affects SDK-style projects that only target .NET Desktop. I have a .NET Framework exe using the SDK project system and have a need to do mixed mode debugging. I need a cumbersome hack (use a start program from a legacy project pointing to the output of the SDK project)
@onovotny: I have the exact same setup (.NET Desktop with new-style csproj).
Any updates on when this checkbox will be added to VS for Common Project System-based csprojs? Is it likely to make it into 15.4? (or there's a 15.7?)
@davidmatson Oren has a PR out - this will make 15.5.
Let's leave this open to track the UI side of things.
What is the "non-UI" way of doing things? The PR instructions make little sense to me...I just want a setting that I can add to my csproj or something.
It doesn't look like there is a way yet, but starting in Visual Studio 2017 version 15.5 you should be able to set <EnableUnmanagedDebugging>true</EnableUnmanagedDebugging> in your .csproj file.
@borrrden add the following to your profile in launchsettings.json
"nativeDebugging" : true
I've never heard of this file before...nor used it. I see it is a grab from ASP .NET Core. Do I just need to put this file in the same directory as the csproj file? I tried that but still I cannot step into native code in VS 2017 (or am I misunderstanding what is going on here?)
EDIT Also tried putting the file into the Properties folder so that it shows up in the solution explorer.
@Pilchie Does your comment above about the XML still stand now that 15.5 is out? I see that this milestone was moved to 15.6
@borrden - what type of file do you have?
@Pilchie .csproj file. Basically I still want a way to debug native code the same as I did two months ago, and I am wondering if adding <EnableUnmanagedDebugging>true</EnableUnmanagedDebugging> is included in 15.5 since the milestone for this issue has changed to 15.6. I honestly don't know what launchSettings.json is...I've never used it before, so I was more looking forward to the csproj feature.
There are different "styles" of .csproj files - traditional ones targeting .NET Framework, or new ones targeting .NET Core that have the "SDK=" attribute on the first line.
What type of project are you building?
Sorry, I thought that this issue was referring purely to the .NET Core style projects. I have a .NET Core style csproj.
Great - just making sure we were on the same page. With 15.5 this setting should work in launchSettings.json under Properties.
You'll need a valid schema for it. You can create one automatically by going to "Project Properties/Debug" and changing any of the settings there.
Then you need to edit the file to have "nativeDebugging" : true inside your profile.
(This feature allows you to define multiple profiles with different settings and then switch between them using the dropdown to the right of the "Play" button on the toolbar).
Keeping this bug open to tracking adding a UI affordance for this to Project Properties.
Alright, at least I know where that is now. I had to abandon 15.5 because of a Xamarin bug (I wish you could choose Xamarin versions independently of the VS installer, because moving the entire installation back from 15.5 to 15.4.5 is a gigantic 30GB+ pain) but once the Xamarin bug is fixed I will try again.
I also just stumbled over this problem, but in my scenario I have unit tests which I'd like to debug. I wrote a new managed c++ wrapper for one of our native components and wanted to start testing, but the lack of this setting is now really a hurdle for me.
My unit test project is a new-style-csproj (with MSTest NuGets) and I tried to launch my unit test DLL with the vstest.console.exe as startup executable and using the nativeDebugging. But for some reason the debugger does not break in my tests. Likely due to the fact that I need to upgrade the test execution to 64-bit which will result in a separate exeuctionengine process where I am not attached to.
It would be great if this problem gets fixed soon so I can debug my tests normally as usual even when I need to step into native code. Also I'd appreciate if somebody can find a workaround how to debug my tests now.
Here my launchSettings.json I tried to use:
{
"profiles": {
"MyWrapper.Tests": {
"commandName": "Executable",
"executablePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Professional\\Common7\\IDE\\CommonExtensions\\Microsoft\\TestWindow\\vstest.console.exe",
"commandLineArgs": "\"$(TargetPath)\" /Platform:x64 /Tests:MyWrappedClassTests",
"nativeDebugging": true
}
}
}
Hey,
I'm trying to enable debug with a new csproj having a net461 target framework by adding the property:
<EnableUnmanagedDebugging>true</EnableUnmanagedDebugging>
But I can't get the mixed debugger to run, only the managed one is working. I'm using VS 2017 15.6.2 installed.
This is supposed to be possible right? (Maybe messing something here...)
If you have an sdk style project you need to do it in a launchSettings.json as above, not in the csproj itself.
han, all good, it works, thanks a lot for the quick answer! 馃帀
I can't find any info in this thread or elsewhere on how to enable native code debugging for VB.net projects. It used to work. Now the debugger says to enable it but I don't see how to do that. Any advice would be greatly appreciated.
@nbettin If you have a traditional .vbproj file, you would use <EnableUnmanagedDebugging>true</EnableUnmanagedDebugging> inside a property group in the .vbproj, or in the .vbproj.user file.
If it's an SDK style project, you would use a launchSettings.json file as described above.
To enable native code debugging set the following property in launchsettings.json
"nativeDebugging" : true
@Pilchie Thanks. I did try that previously on an earlier release of VS17 and again today on the latest release. But the debugger doesn't return object properties like it does in v9 and v10 even though it is "enabled". So there's definitely something more to this. For background I have been making windows apps using the CATIA API to automate CAD tasks with VB.NET and C#.NET for about 8 years. Typically I set a breakpoint and inspect the properties of a CATIA object by hovering on it or setting a watch. But I don't get any properties now in V17.
@nbettin Sounds like you have a breakpoint in the VB code, and you're inspecting a COM object? That doesn't require native debugging, but it might be an EE issue. @tmat any ideas what might be wrong here?
@cston Do you remember any differences in displaying COM objects between legacy EE and managed EE?
@Pilchie I didn't think it was a native debugging issue but that's the message being displayed when I try to inspect the COM objects.
Should I submit this issue on a separate thread?
I would suggest using Visual Studio's "Report a problem" mechanism to record the problem. That will help us get it to the right team, and collect some telemetry that might help identify the problem.
Is there any update on this? The setting EnableUnmanagedDebugging still isn't recognised as of 15.8.4, and there is still no such file as launchsettings.json.
This is really annoying. :-(
You can create a launchSettings.json by using the "Debug" property page, it's just that once it exists you have to manually add that entry to it.
Thanks Pilchie but it still doesn't seem to work when I run tests in the Test Explorer (they are NUnit tests if that makes a difference). I'm about to try attaching the debugger externally. Is there anything else I can do?
I think this was a bug that we addressed - @AbhitejJohn @davkean do you remember the details?
This should be fixed in 15.8. @bachowny , can you share your launchsettings.json file please?
Here is the file, which lives in my test project in Properties:
{
"profiles": {
"JpxTests": {
"commandName": "Project",
"nativeDebugging" : true
}
}
}
At the point where the access violation occurs (and I have since verified that that is what's happening, using external debugging), NUnit 3.10.1 exits like this:
[19/09/2018 9:46:43 AM Error] The active test run was aborted. Reason:
Actually it is working now after restarting Visual Studio, doing a rebuild, and adding PDBs for the native code. Not sure which of those steps got me over the line, but thanks for your assistance, this is much better! :-)
Now that it works properly in launchsettings.json, I suppose it should be added back to Project Properties > Debug panel?
Indeed - that's why this issue is Open and not Closed....
Indeed - that's why this issue is Open and not Closed....
Yeah we're all just wondering how many more months or years it might take someone to add a single checkbox to a GUI...
Indeed - that's why this issue is Open and not Closed....
Great, thanks!
Given that there is a fairly easy workaround, this isn't high in our priority list. If you'd like to contribute a PR though...
nativeDebugging
This worked for me!
Thanks!
Given that there is a fairly easy workaround, this isn't high in our priority list. If you'd like to contribute a PR though...
So how do I apply this workaround in a new .Net Core console app?
I just created a .Net Core console project in VS2017 (15.8.9).
There is no launchsettings.json file :(
@jeroenwalter Change a default in _Debug -> [Project] Properties_ and one will be created.
I'm running into this issue which is effecting xUnit / .NET Standard.
<EnableUnmanagedDebugging>true</EnableUnmanagedDebugging>
Does not work in xUnit.
Trying to debug some C# NamedPipes with C ones in a single Unit Test.
What version? I think 15.8 or 15.9 Test Explorer was changed to respect this setting.
I'm on:
Win10 x64
VS 15.9.2
xUnit + .NET Core 2.1 (Testing .NET Standard 2.0 and external C API)
VC++ 10.0.17763.0
My csproj settings look like:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<IsPackable>false</IsPackable>
<EnableUnmanagedDebugging>true</EnableUnmanagedDebugging>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.8.0" />
<PackageReference Include="xunit" Version="2.3.1" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.3.1" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\VRstudios.Networking\VRstudios.Networking.csproj" />
</ItemGroup>
<ItemGroup>
<Reference Include="Newtonsoft.Json">
<HintPath>Newtonsoft.Json</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<None Update="HttpRootResourcePath\index.html">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
</Project>
We don't currently respect that property, you need to add "nativeDebugging" : true to your launchprofile, here's an example: https://github.com/dotnet/project-system/blob/master/src/ProjectSystemSetup/Properties/launchSettings.json#L24.
Ok that works for me tnx! VS C# proj control panel should really have this option for .NET Core apps.
Humans are visual creatures after all.
{
"profiles": {
"Start (with native debugging)": {
"nativeDebugging": true
}
}
}
That's exactly what this bug is tracking. :)
This will get more important for .NET Core 3.0 when C++/CLI is enabled, since it will only support mixed-mode assemblies.
Jumping on the "me too" bandwagon to see if we can get this prioritized higher.
It's mostly annoying because I spent 15 minutes searching for the option in VS options, then project properties, and then implementing the hack.
How about the exception intellisense have an option to enable native debugging when it detects a native exception?
Would be nice if this could be prioritized and fixed in Dev16 soon. Given how often we in the WPF team tend to debug into the native stack, our development processes frequently involve native debugging.
I just stumbled upon this and figured out how to enable native-debugging for Sdk style projects. Now it's one more thing that has to be turned on for every test project or application we investigate for problems. Just being able to turn it on in the VS UI would be nice.
Win10 x64
VS2017
Nunit 3.11
c++ v141
Resharper
For anyone using Resharper, the launchsettings.json nativedebugging flag is ignored and breakpoints are not hit. Once I disabled it and ran from Test Explorer the breakpoints hit.
Fixed in #4624
Hi, is there a way to start debugging C# and then step into T-SQL, like it was possible with older versions of Visual Studio and pre-SDK projects?
My use case is described here.
@branko-d can you please file a new issue on this repo?
@branko-d can you please file a new issue on this repo?
Created: #4935.
We don't currently respect that property, you need to add
"nativeDebugging" : trueto your launchprofile, here's an example: https://github.com/dotnet/project-system/blob/master/src/ProjectSystemSetup/Properties/launchSettings.json#L24.
Do you know how to achieve the same using VSCode?
Most helpful comment
Keep in mind that this also affects SDK-style projects that only target .NET Desktop. I have a .NET Framework exe using the SDK project system and have a need to do mixed mode debugging. I need a cumbersome hack (use a start program from a legacy project pointing to the output of the SDK project)