We have a lot of C++ code that we have been moving to .NET.
When enabling the /clr on our projects, we have found that we can
debug *either* the managed code OR the unmanaged code.

In order to debug the unmanaged code, we select "Native Only" as the
debugger type.
In order to debug the managed code, we select "Managed Only" as the
debugger type.

No matter which mode we chooose, even if it is Mixed or Auto, we can
only debug one set of code or the other.

If debugging "Managed", then unmanaged breakpoints are not hit.
If debugging "Native", then managed breakpoints are hit, but we get a
message that no source could be found, but we can look at the
disassembly.

Any tips here? This appears to have gotten worse from VS.NET 2002 to

[quoted text, click to view]

The key here turned out to be the /ASSEMBLYDEBUG linker switch. Once
I turned that on, I could step into both managed and unmanaged code
just fine. Still having problem with viewing all variable data in
different scenarios, but I'll keep looking into that.

I'm not sure why MS chose to change behavior from 2002 to 2003, but:

In version 1.0 of the .NET Framework, the Microsoft Visual C++
compiler adds the DebuggableAttribute when the /clr and /Zi compiler
options are specified.
In version 1.1 of the .NET Framework, you must either add the
DebugabbleAttribute manually in your code or use the