Customization of Just My Code (JMC)

Customization of JMC is something that we wanted to do, but ultimately got cut. We were planning to allow customization on a module basis, but we could have done it on a namespace basis. The downside of namespaces is performance. I believe that Java has a strong correlation between modules and namespaces (sorry if I am wrong here, I have never used Java). .NET doesn’t have this. In order to determine what namespaces are in a module, I believe you need to grock through every type in that module – clearly expensive. Maybe we could have found a way around this. The other problem with namespaces is that clearly you will have lots of types that are in a namespace that is not in your chart. What do you do about those? You could have the setting determined by a characteristic of their module...

Would you like to customize what is considered user code? My opinion as of today is that people who want to customize JMC are the same people who shouldn’t be using JMC. The philosophy of JMC is rooted in the idea that the debugging experience should be simpler, while customization comes from the desire for control. However, I may be jaded by my own experience -- when I first started using JMC I wanted to customize it. People (or at least me) have a tendency to want to use every new cool feature. Even features that they would be better off without. However, I am very open to the possibility that this is wrong, and that customization would be useful, so I would love to get feedback either way.

Comments (3)
  1. Ryan Dorrell says:

    Gregg –

    Sorry to hear that feature is getting cut. I believe there is some very high value in providing an much more customizable model that what is planned. I even forsee the need to even be able to ignore certain chunks of code inside your own application while debugging. Here’s a (grossly oversimplified) scenario:

    1) Your application consists of two classes: MyApp.Data.SQLHelper and MyApp.Forms.MainForm.

    2) You know MyApp.Data.SQLHelper to be stable, but you have a bug somewhere in MyApp.Forms.MainForm.

    3) As you are debugging stepping through the code in MyApp.Forms.MainForm you keep accidentally stepping into the code in MyApp.Data.SQLHelper.

    4) You "turn off" stepping into any code in the MyApp.Data namespace or just for the MyApp.Data.SQLHelper class

    5) Now as you step through code in MyApp.Forms.MainForm, you automatically step over (without stepping into) the MyApp.Data.SQLHelper class.

    Maybe I’m oversimplifying this (which is quite possible as I have unfortunately spent less time coding lately than I’d like to admit), but this seems like an extremely helpful feature, particulary with larger applications. Perhaps there can be a shortcut for "Just My Code" which sets up the appropriate namespace/class configuration for achieving the same functionality that is currently planned for JMC.

    FYI: one Java tool that has the feature I noted in my comment in your prior blog post is Eclipse. The feature is called "Step Filtering" and it enables precisely the scenario I describe above. A screenshot is here:

    <a href=’‘>step filtering screenshot</a>

    Eclipse is open source, so it would be possible to dig into their source to see how that is implemented, but you are correct, the implementation may not map well to how .NET works internally…

    I finally had time to get VS2005 Beta 1 installed today, and look forward to providing more feedback. So far from what I’ve seen in demos and today, the debugging features are incredible – keep up the good work!

    Thanks –


    ryan.dorrell (at)

  2. Gregg Miskelly says:

    Thanks for the feadback Ryan. Just to be clear, customization was cut from 2005, but Just my code will definately ship. Customization may come back in the next version. That will depend on what kind of customer feadback we get, so this is very helpful.

    Also, its not that namespace based customization is impossible, just that the current format for a .NET assembly makes this impracticle from a performance perspective. Future assembly formats could enhance the metadata format for namespaces and make this more feasible.



Comments are closed.

Skip to main content