Is 'Just my Code' for you?
The debugger has a new feature this time around called 'Just my code'. This is a new-for-Whidbey managed debugging feature.
Philosophy of Just my code:
The basic idea is that when you debug an application, you want to debug the code in the application, and not all the code that is in the Framework. Specifics:
- If you step into some non-user code (say the Framework), and that non-user code invokes your callback, you want to step into the callback, not step into the Framework
- If you step out of your code, you don't want to step into all that glue code, you want to break on your next event handler.
- If an exception is thrown and caught in someone else's code. You don't care.
- If your code failed to catch an exception, then you don't want to let it get swallowed by some big exception filter that a bad person has installed.
- Sometimes you want to break when an exception is thrown, but not every exception. You only care when your code throws the exception.
What does the debugger consider 'your code'?
- If the code is compiled optimized, it is not your code
- If you don't have symbols, it is not your code
When we were first coming up with this feature, I was thinking that this feature would be helpful to everyone. After all, everyone at least occasionally has the experience where code written by someone else gets in the way of debugging a problem in your code. However, after playing with the feature for a while, I have changed by mind. It’s a great feature if you want a simplified debugging experience. However, that isn't me. If you are a hard core dev, do yourself a favor and turn the feature off (Tools->Options->Debugging->General->Just My Code).
Also, one technical note for those who like the feature – if exceptions pass out of user code and are swallowed by certain parts of the Runtime (not the framework), the debugger will not be given a chance to break on the exception. The CLR is working to address this problem, but it is a difficult problem to solve. In Beta 1, one such location is the reflection engine.
Comments
- Anonymous
July 29, 2004
This problem happens the other way too - occasionally you cannot debug your own code!
Try this:
* Create a solution with two projects
* Create a custom control in one project
* Compile the control project
* Add the new control to the toolbox using browse (to the release or debug build dll of the user control project). There is no other way to use the control! (I'm talking about inherited controls, not user controls. User controls occasionally show up in the toolbox by themselves)
* Open the second project, and drop the control onto a form.
* Place a breakpoint somewhere in the control project, ie/ the constructor
* Run the application (the one with the form). The breakpoint never gets hit, even though the DLL for the control is in the solution..
A tricky problem, but a very frustrating one for developers who program "private" custom controls for their applications. - Anonymous
July 29, 2004
I don't know why that would be. What does the modules window say for your control? - Anonymous
July 29, 2004
When I run the entire solution (including the controls) I get the following modules:
mscorlib.dll
HealthSpace.EhsManager.DesktopClient.exe
system.dll
healthspace.ehsmanager.desktopclient.core.dll
system.xml.dll
system.windows.forms.dll
healthspace.data.dll
healthspace.ehsmanager.businesslogic.dll
purecomponents.navigator.dll
system.drawing.dll
dotnetwidgets.dll
documentmanager.dll
microsoft.visualbasic.dll (we use C#! probably a 3rd party control.. ;-)
activereports.dll
activereports.viewer.dll
dundaswinchart.dll
healthspace.ehsmanager.desktopclient.plugins.foodui.dll
healthspace.ehsmanager.desktopclient.plugins.mainui.dll
healthspace.errorreporting.dll
healthspace.visualcontrols.dll (the one that won't debug)
janus.windows.common.dll
janus.windows.explorerbar.dll
janus.windows.gridex.dll
system.data.dll
system.enterpriseservices.dll
system.enterpriseservices.thunk.dll
Bear in mind that it won't debug in 2003 - I don't have a full beta 1 install of 2005 in virtual pc yet - just C# express at home.
I always assumed that it never could debug because I manually browsed to the .dll when adding the controls to the toolbox.
If you need any more information you can contact me at ebickle (at) healthspace.ca
Thanks! - Anonymous
July 29, 2004
The problem is that VC# Express 2005 does not have the option to turn this feature off. So everytime I start the debugging session I get a warning about "Just My Code", complete with instructions to turn it off by navigating to a non-existent configuration dialog. Kind of annoying. - Anonymous
July 29, 2004
How about the ability to specify what namespaces you step into while debugging instead? Something like:
System.Xml.* [NO]
System.Windows.Forms.* [YES]
MyNamespace.Objects.* [YES]
ThirdParty.Object.* [NO]
I've seen a similar feature to this in some Java IDEs. - Anonymous
July 30, 2004
Greg: I will try and find out why C# express doesn't have an option for this. You can always use the ultimate options editor -- regedit.
HKEY_CURRENT_USERSoftwareMicrosoftVCSExpress8.0DebuggerJustMyCode = 0
BTW: What are you doing that you have a project that is optimized or doesn't have a PDB? - Anonymous
July 30, 2004
Ryan: Good feadback. I decieded to post a seperate blog topic about customizations (http://blogs.msdn.com/greggm/archive/2004/07/30/202436.aspx) - Anonymous
July 30, 2004
Greg,
I talked to some coworkers about your problem. I found out two things:
1) There is aparently a bug where sometimes the warning comes up when it shouldn't. We are still tracking down why.
2) There is a button in tools options to show all options, if you click this, there should be an option to turn off just my code. - Anonymous
August 02, 2004
The comment has been removed - Anonymous
January 18, 2009
PingBack from http://www.keyongtech.com/2391205-attach-to-process-does-not