Freigeben über

Debug and Retail Builds

  • Artikel

Over the weekend some of the big-brains on the CLR team (oh, and me too) are having a debate about introducing the concept debug and retail builds of the .NET Framework. The high level concept is to move some “code correctness” checks out of the retail build (the one we install with the OS, redist or Windows Update) and into a debug build that would only be intended for development time usage. I must admit that the concept of different debug and retail builds goes against my instincts for simplicity, but some smart folks feel like they are absolutely required so it is causing me to take a 2nd look and to ask you for your input.

Here is my (hopefully unbiased) thoughts on the pros\cons of the general solution.

Pros (for separate debug and retail builds)

  1. Faster performance when using the retail build
    Mitigation: the CLR\JIT could always get smarter
  2. Richer checks in the debug build
    Mitigation: FxCop, Customer Debug Probs, etc could get better to cover these types of scenarios

Cons (against multiple builds)

  1. Disconnects between development time and deployment time environment creates opportunities for hard to track down bugs.
    Mitigation: Some people’s experience on unmanaged platforms is that this is a rare case that can be dealt by runtime debug bits in production environment when required.
  2. Costs to deploy, manage and update different builds of the .NET Framework.
    Mitigation: the would be very close and could even be the same binary with different code paths enabled via a config file
  3. It is a slippery slope. We will have to define carefully and explain repeatedly which checks remain in the retail build and which go into the debug build. It seems likely that we will miss a few and allow a security check to be only in the debug build.
    Mitigation: careful review and education.
  4. At-a-glance complexity of the platform increases.
    Mitigation: That is life.

This last con deserves some reflection. Let me start by telling an unrelated story. As many of you know I teach 2-day long class to WinFX developers on how to build great managed code APIs. I had just got done covering the threading story where I explain that managed code does not have a bunch of threading models like COM does. There is not rental, free, etc. After the talk one of the developers from the original COM team came up to me and explained that COM didn’t start out with a bunch of different threading models either, but over time it was forced to “mature” into them. He predicted the same would happen for managed code… “just wait” he said….

Here is a similar story from the standardization of the C# programming language at ECMA. We were talking about adding the C# global namespace qualifier (“::”). One of the senior engineers from Intel made a very insightful comment. She said that on its merits it is hard to argue not to include this feature as there is no viable workaround, however it does seem be an affront to the simplicity of the language. In her opinion it was an orthogonal “hack” to the language design.

I hope you can see the parallels with the debug\retail debate. Part of me wants to sigh deeply and just accept that my baby is just going to get more complicated every release it is not worth fitting. And part of me wants to rage against this kind of encroachment all the more.

Questions for you:

So what do you think – should we sigh or rage?

Do you have any additional pros\cons to share?

Any experiences using debug and retail builds that could help this debate?

Standard Disclaimer:

I feel it is worth stressing that this is merely “hallway conversations” at this point. We have no concrete plans in this direction, I am just asking for very early input?

Comments

  • Anonymous
    February 29, 2004
    I have some experience using checked builds of Windows, and I think it's a great tool. I have found many bugs in the projects I've been working on simply by running them on a checked build, or by copying checked versions of system dlls to a retail build.

    However, I still think that you shouldn't release debug builds of the framework, and here's why.

    Checked builds of Windows were nice but mostly because tools like AppVerifier were not available at the time. The AppVerifier approach is superior because AppVerifier can be easily turned on on any system in a matter of minutes, whereas with a debug build you have to reinstall everything.

    If you do decide to make debug builds available, I still think that you should invest at least 90% of efforts in instrumenting retail builds to make them easier to debug, with things like Customer Debug Probes, tracing that can be turned on in retail, etc. Don't add any checks into debug builds unless they are impossible to implement in retail.

  • Anonymous
    February 29, 2004
    <Pavel>
    If you do decide to make debug builds available, I still think that you should invest at least 90% of efforts in instrumenting retail builds to make them easier to debug, with things like Customer Debug Probes, tracing that can be turned on in retail, etc. Don't add any checks into debug builds unless they are impossible to implement in retail.
    </Pavel>
    totally agree with you.
    +1 against separation.

  • Anonymous
    February 29, 2004
    The comment has been removed

  • Anonymous
    February 29, 2004
    The comment has been removed

  • Anonymous
    February 29, 2004
    Brad Abrams is thinking out loud whether we should be subject to a split personality for the CLR by re-introducing the ghastly debug build. However, reflecting on my earlier experience, I would say to let Moore's Law have it's way.

  • Anonymous
    March 01, 2004
    Very simple: If it's not on by default, 99% of developers won't use it.

    Because most developers are Mort. If you ask them, "Do you ever run your program on a checked build?" or "with the debugging flag enabled?" they will say, "What's a checked build? What's the debugging flag?"

    How many C# developers use Customer Debug Probes? Probably less than 1%.

    How many C# programming books teach you about Customer Debug Probes? Probably none.

  • Anonymous
    March 01, 2004
    If additional, expensive checks can be solved by adding CDP and maybe [Conditional/DebugOnly] attribute (not the C# trick, but CLR feature) I am all for it.
    Although this would not be significantly different from having a debug build!

    Raymond you are correct 99% of programmers don't use/know about those feature, but I am not sure inflicting 50% (for different values of 50) speed degradation on all users is worth it.

    So my prefs would be CDP/Attribute for libraries or a separate debug build.

  • Anonymous
    March 01, 2004
    The comment has been removed

  • Anonymous
    March 01, 2004

    The core os team loves checked builds alas we frequently find people who didn't use them to test their stuff.

  • Anonymous
    March 01, 2004
    The comment has been removed

  • Anonymous
    March 01, 2004
    Please don't "solve" performance problems before you identify that there is a performance problem. For the apps I've written, network access and database queries of large databases have always been the slow areas. Those issues were always resolve at the application level by getting "smarter" i.e. improviing network data requests and adding indexes.

    My job as a developer is difficult enough without having multiple builds for libraries/frameworks. You should hear some of the choice words I have to say when I have to use a debug version of a 3rd-party library. I definitely try to stay in Raymond Chen's 99% Mort group... by choice.

    If you are developing software and depending on debug checks for verifying code correctness, I'd say that's a big RED flag.

  • Anonymous
    March 02, 2004
    I wonder if there could be a solution like the one used by products like BoundsChecker? Doesn't it hook the Windows API or something like that? The nice thing about providing some sort of API or API-hooking would be to open it up to third parties like Compuware & IBM/Rational. There's a big security consideration there but perhaps that can somehow be mitigated? For the record, I am not against a debug build. We use the CRT debug runtime checks during our beta phases. Usually on our last beta we switch back to non-debug CRT libs and turn off assertions and such. We have found a lot of otherwise hard to find bugs with the CRT debug libs using the heap check functionality.

  • Anonymous
    March 03, 2004
    The comment has been removed

  • Anonymous
    March 05, 2004
    #ifdef DEBUG in IL? This is a bad idea. Just another complexity that's not needed 99% of the time, so don't add it.

    In addition to the CONs listed by Brad, what if:

    *the debug flag is turned on accidentally on user's machine
    *a developer finds his app only works in debug mode, so he codes his app to turn on debug flag at start.

    If you really want to help developers (well, the few developers that care anyway), just make it like the checked build of Windows: it's a different set of binary files intended to help developer debugging only, not to be use in any production environment, and it will be ignored by 99% of developers anyway. But no run-time IL DEBUG flag.

  • Anonymous
    March 05, 2004
    The comment has been removed

  • Anonymous
    March 08, 2004
    > just make it like the checked build of Windows: it's a different set of binary files intended to help developer debugging only, not to be use in any production environment...

    What if the problem happens only in production environment?

    Where I work, we have test environments that take several days or even weeks to build (they are intended to be the mirrors of what we have in production). There is no way the owner of this environment would allow me to do something as intrusive as install a debug build on it (and sometimes you can't even reboot to create an image, because the system is under constant load trying to reproduce a memory leak or something).

    The ability to do debugging on a retail build is very important to me.

    > and it will be ignored by 99% of developers anyway.

    That's one of the main arguments for building all debugging functionality into the retail build. The only way these 99% of developers will ever use it is if they can turn it on with a couple of mouse clicks from Visual Studio.

  • Anonymous
    June 15, 2009
    PingBack from http://einternetmarketingtools.info/story.php?id=20286

  • Anonymous
    June 15, 2009
    PingBack from http://workfromhomecareer.info/story.php?id=33086