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.

Reply via email to