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)
- Faster performance when using the retail build
Mitigation: the CLR\JIT could always get smarter
- 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)
- 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.
- 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
- 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.
- 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?
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?