Sorry, thinking about this, my wording was not very nice. I guess I just wanted to make the point that regardless of the process you choose inside MS, there is no way that you can make sure to not break some apps out in the wild when you do red bit changes.
David - no worries, your point is valid and well taken.
If this is the sort of servicing you are considering, it will end really, really bad.
I don't believe your scenario is new to NETFX 3.5, however. This is how things work today. For example if vendor C, authoring a 2.0 application, requests the hot fix (QFE) for the error or makes the V2.0 SP that contains the fix a pre-requisite, then installation
of 2.0 application C will break application A. It no longer becomes necessary to construct the transitive case of NETFX 3.5 being involved (app B).
Our choice here is to either try to push for some kind of application isolation (each app gets its own copy of the runtime), or to push our compatibility bar high and move things forward. The blog posts I have linked to above provide some background on the
pro's and con's of these two scenarios. I believe the con's of app local install outweigh the benefits.
In Windows. It just is an elite side-by-side story called skimming.
We actually do have a level of shimming the .NET FX as well. As an example, we implemented deterministic COM apartment initialization in the 2.0 product. We found that too often in the v1.x product the "first one in wins" semantics would break applications
in random ways. We added an app compat switch (e.g. a shim) that allows you to turn this behavior back to the old ways. We have a CLR version binding shim that allows us at managed code startup to check the registry to see if this process has overrides on
which version of the CLR should be loaded. We can deploy the shim to make sure a particular version of an application is not broken by deployment of a new NETFX.
I will argue that shims are a necessary evil but not a silver bullet. Windows fixes a high number of QFE's and do not always catch/shim behavior. The easiest example to consider is the line of business application inside of a corporation (say the WinForms
app you use to fill out employee performance review data, as I just did last week). There is no way for us to ever test that application directly before shipping a bug fix. We all do our best based on coverage and vendor reporting. Some things require a
So I agree there is a healthy tension here between breaking old apps vs the down sides of pure isolation (as outlined in my other blog entries).
1) Never ever do red bit changes to deployed DLLs because it will break apps on customers desktops
The problem here is that the simplest red bit change is just a bug fix. I think it becomes too constraining to never fix bugs in deployed DLLs. What we do instead is try to set a very firm bar on what is acceptable, we do due diligence on reviews, we test
the heck out of it, and we fall back to shimming when we are truly between a rock and a hard place.
3) In particular, don't service deployed binaries with red bit changes in order to enable cool new stuff, like integration of DLINQ with data binding.
This provides insight on another set of tension points. One of the key values of Visual Studio + NETFX is the seamless integration of the entire stack. It really makes it far easier to author your applications. We could solve this problem by releasing a
new SxS NETFX frequently with the features. This is not desirable to many of our customers: enterprises don't want to take big new releases very frequently, and ISV's like to see something get out to a lot of machines so they don't have to redistribute new
versions along the way. Internally we have the pressure of servicing a lot of product versions in parallel (we only have so much capacity). So we need the right kind of balance here.
This is an excellent debate with hard trade offs to make. I can tell you that we wrestled with all the same kinds of questions ourselves before arriving at the plan we have in place now. Later this year we will have out CTP's of the NETFX 3.5 stack. I'm
looking forward to having people try it out and tell us how things are going.