Jason, also thanks for the data binding example. Lets make a scenario out of that and see what happens.
So, you find a bug in the data binding code in WinForms 2.0 during the LINQ dev cycle that prevents some nice integration of LINQ code with data binding in WinForms. Consequently, you fix that bug in FX 3.5, i.e. you make a red bit change to the WinForms 2.0
DLLs that gets deployed whenever someone installs FX 3.5 (whether that is then packaged as FX 2.0 SP1 or some other way is not really important for my example).
Now, vendor A has a nice little WinForms 2.0 app, developed long before he ever heard anything about LINQ. He discovered the bug in the data binding code as well, and programmed around it. Because that is what happens all the time. So app A (that is vendor
A's app) depends on the bug being there to run.
Now, vendor B comes out with app B that uses LINQ, all shiny, all new. He of course integrates the FX 3.5 bootstrapper into his setup, as a silent part of his installation. Some innocent customer installs B, but had A installed previously. The red bit change
in the data binding code breaks app A.
Now, the user is fairly sophisticated and recognises that A stopped working after installing B. So, he uninstalls B. But, I suspect this will not uninstall FX 3.5, right? So, it doesn't solve his problem. A is still broken.
To me, this does not look like an unlikely scenario at all, but rather the norm. At the same time, it is an absolute nightmare scenario. It is pre-Windows 2000 system file protection (or however that technology that prevents replacement of system files is called)
DLL hell. Third party apps can replace system files silently in their setup that break other apps.
Quite frankly, I am scared to death. If this is the sort of servicing you are considering, it will end really, really bad.
Now, I do see your point that you want a nice integrated experience between WinForms data binding (again, just an example) and LINQ, and lets assume the only way to get this is to fix the bug in the data binding code. What to do?
I believe it is quite helpful to have a look how the Windows group would handle this. First, I doubt that if a team that develops a new feature (like DLINQ) comes to a group with an old feature (data binding) and requests a bug fix that could break old apps
that they would do it. The bug is part of the platform, apps rely on it, so the new feature has to live with it. Platform stability in terms of not breaking deployed binaries should always trump nice integration of new features. But, lets assume they agree.
They would certainly NOT allow third party apps to silently deploy this with their setup. They might include that fix in some larger package, like a new OS revision, when people expect app problems anyways. So, maybe the team with the new feature will not
get the nice integration in their first release, but only once the underlying platform has one of its official "something might break" points.
And then, even when they make a breaking change like that, they have a side-by-side story! In Windows. It just is an elite side-by-side story called skimming. If such a fix would break a popular app, they would supply a skim with the fix that makes sure the
old app continues to run. Never ever would they dare to break Photoshop in order to enable nice integration of the new desktop search with explorer, eve with a major OS revision.
This is getting too long, so what would I suggest? I know this is terribly complicated and I probably missed things, but here we go anyways
1) Never ever do red bit changes to deployed DLLs because it will break apps on customers desktops
2) In case of security vulnerabilites, break rule 1
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. The new stuff has to wait for the next side-by-side revision of the base component for the nice integration
to happen. This doesn't have to mean that DLINQ has to ship later, it just means one particular integration scenario doesn't work with FX 3.5, but will only be enabled with the next full revision of the framework
4) Maybe, maybe, maybe allow red bit changes to deployed binaries sometimes. But IF that has to happen (and I have not thought much about what would justify this, but make the bar super high), NEVER allow these changes to be silently deployed by third party
apps as part of their setup. Do not, ever, provide a bootstrapper that third party ISVs can integrate into their setup experience. Otherwise we will go back to pre Windows 2000 days, when people were afraid to install anything, because it could break their
already installed apps. Windows does this in the forms of Service Packs: Everyone knows that they might be problematic and they are never silently integrated into third party apps (at least I hope). But if there is any way you can avoid that at all, I would
much prefer that.