I've reproduced your scenario in terms of project types and order of debugging, etc. But I can't reproduce the flakey behavior. Breakpoints continue to always work, as does stepping, etc... This is on XP Pro with SP1 of the .NET framework applied.
-Mike http://staff.develop.com/woodring http://www.develop.com/devresources ----- Original Message ----- From: "Andrew Cherry" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 12, 2002 9:49 AM Subject: [DOTNET] Weird debug occurrence... Managed debug fails after unmanaged debug??? > Hi all - > > At first I thought it was a fluke, but I can replicate it: > > I am using VS.Net for both managed and unmanaged development. I ran > VS.Net, setup breakpoints in my unmanaged program (C++, obviously. :) ), > a console application. Debugging works fine. I can go into function, > step through functions, go down to the assembly level... Everything > works fine. > > HOWEVER! (There's always a however...) if I then open a C# project in > the same VS.Net instance -- I can run programs "under" the debugger -- > but breakpoints aren't resolved. So I can debug only so much... > Breakpoints remain active, but while the debug executable is running, > white question marks overlay the red circles (default coloration for the > most part). > > And an additional twist: if I then open up a second C# project, I can > debug that one. And if I reopen the first, I can debug that one then, > too. > > So it seems to be that attempting to debug a managed executable > immediately following debugging a managed executable fails -- at least > on my machine. > > Does anyone else see this? > > Thanks, > Andrew > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.