Condividi tramite

Red Bits and Compatibility

  • Articolo

Doesn't Side by Side Cure All?

Soma posted in his blog how we plan to produce an updated version of the .NET Framework that maintains compatibility. This particular subject always draws a lot of passionate opinions. I've heard the opinions from the polar extremes. This is a common example:

"There is absolutely NO reason to maintain backwards compatibility with previous versions of .NET with new versions. First you're artificially tying your hands, second, since the frameworks can live side-by-side (except the web.config bug between .net 2.0 and .net 1.1 virtual directories) there is absolutely no reason for for it. (ship the version that your application requires with your application!)"

Automatic roll forward is the biggest problem with this. When you do a LoadLibrary (or cause one such as in COM activation) and the CLR has never been loaded into the process, we have to pick one to execute the code. We could pick the version that matches the file you are loaded. But if that version were older and you subsequently loaded an assembly that required a new version, it would fail. To fix this, we automatically roll forward to the latest and greatest CLR on the machine and maintain backwards compatibility to the best of our ability.

I have also talked with Fortune 100 companies who like to reduce their TCO by standardizing on one version of the .NET Framework. To these groups, it is cheaper to have their IT staff manage one flavor in their data center. The cost to target a new version can be expensive, especially if each new version were to take carte blanche with compatibility. By keeping our compatibility high between versions, we make the transition easier.

I posted a great deal of information on how we do our compatibility work (see this link). If you do find compatibility issues between the versions, please do report them! 

Trade Offs

All that said, I do agree with some underlying sentiment from the comments. I would like to see the .NET Framework be able to evolve over time and get rid of legacy. We created System.ObsoleteAttribute to help.

There are a few attributes that any solution should have:

Simplicity - Any solution needs to be easy to describe and figure out. Ideally using a design pattern that is easy to understand and doesn't require a lot of moving parts.

Predictability - Developers like to know what to expect, especially in large enterprises. Having a system that allows you to know how many more compatible versions to expect helps you plan your releases and roll outs accordingly.

Pragmatic - There needs to be a sunset policy for old versions to avoid have too many permutations to track and service.

We have been working on a solution that factors in these attributes called Compatibility Blocks. Think of a block as a set of compatible versions where an application written for a block can safely roll forward to the newest version in the block. Such a concept allows developers (and in particular the enterprise) to plan around a set of compatible versions. At the same time, it allows us to pick a transition point to obsolete old functionality (e.g. at the creation of a new block). You can think of V1.0, V1.1, and V2.0 as a compatibility block. New versions we create (including Red Bits) that continue this pattern extend the block. At some point we will pick an inflection point to create a new block (we'll give you plenty of warning when that happens; there is nothing formally planned at this point).

We'll have more details to share as designs firm up. In the meanwhile, keep your opinions and requirements coming. They are truly valuable to help define the technology as it evolves!

In Closing

Finally on Don's comment about our favorite Canadian sitcom ever to hit PBS:

"This sounds like a really dumb idea, and the whole "Red Green" thing just makes it sound worse. Ever seen the "Red Green" show? Not the guy I want planning my version compatibility scenarios."

As it would have it, I am the Approver for Red Bits changes in Orcas and am reviewing each with a small group of experts. The DDCPX team owns driving a high level of quality for the release thereafter. I can assure you there is no duct tape being used in this production ;-)

Comments