1

I really want to jump all over CoreCLR. The new project structure, the merging of nuget into the build system, the automatic refreshing of solutions when the file system reports changes, and the targeting of multiple platforms are just some of the reasons I want to move on from the old csproj/.net 4.x stuff.

One of my primary use cases is exploring multiplatform game engine design with C#, but there's some interop involved for specific platforms (hidden away in SharpDX in my case) - debug messages that come from the unmanaged side of DirectX bubble up from native code into managed code if you "enable native code debugging" in the project's debug options. CoreCLR projects don't have that option though in the project's debug settings, which means no useful debug messages, which means debugging DirectX calls is nightmarish.

I'd appreciate some insight into what's going on in this regard.

Nathan Ridley
  • 33,766
  • 35
  • 123
  • 197
  • There's only one good reason to jump on the CoreCLR band-wagon, you get to run your program on a Linux or OSX machine. DirectX on such a machine, hehe, miracles can happen but that's a big No right now. Native debugging has the same problem, such a debugger has a very heavy OS dependency. That might actually happen some day. Don't hold your breath for it though, you'll turn blue first. – Hans Passant Jul 22 '15 at 10:09
  • @HansPassant The DirectX stuff was for the windows distribution of my code (naturally i wouldn't assume i can make that work elsewhere!). I disagree regarding cross-platform reasons being the only reason to jump on the bandwagon though. What about the lovely new unified, JSONified project structure? Or the auto-refreshing projects in VS2015? Or the nice clean platform management via dnvm? Just... everything is nicer! Feels like a tease that all this stuff is only supposed to be for specific use cases and for anything else we're supposed to stick with the old crusty XML-ridden legacy... – Nathan Ridley Jul 23 '15 at 11:47

1 Answers1

3

The tooling doesn't have support for native debugging when running from VS. However, if you attach the debugger manually to the process, select both native and CoreClr (the option is in Debug -> Attach to Process) and you'll achieve what you want.

If you are using dnx then you can pass the --debug flag when the app starts, similar to this:

dnx --debug . run <args>

and it will wait for the native debugger to be attached.

PS: Caveat: if you pass --debug you must attach a native debugger. You cannot attach only the managed one.

Victor Hurdugaci
  • 28,177
  • 5
  • 87
  • 103