# Monday, May 09, 2005
« Whidbey .NET Framework Compatibility -- ... | Main | CLR Roadtrip heading to Phoenix -- May 1... »

Brad sent me mail on Friday night asking about our plans (or non-plans) to change the assembly version number again for Whidbey. The mail was the result of a developer -- let's call him Marc -- who had pinged Brad earlier in the week through his blog asking that exact question ...

Here is the basic question from Marc:

I'm using Beta 2 of the .NET Framework SDK 2.0 ... I'm curious, if I roll this app out, built on a beta ... Would the app continue to function or would it need to be rebuilt with the 2.0 final SDK?

There's too many exciting features to stick with the 1.x version of .NET. :-) Every day I find something new and exciting that can be done. It makes programming fun again!

I'm glad to hear that Marc likes Whidbey. That's definitely the plan from building 42 (where the CLR team works)! Back to the original question: will Marc's app continue to work or is a re-compile required? Marc isn't specific about which beta he is using, so I'm going to have to resort to a multi-part answer, unfortunately ...

1. If Marc is on Whidbey Beta 1 (or earlier), then the answer is "yes ... a recompilation is in your future".

2. If Marc is on Whidbey Beta 2 (or later), then the answer is "no ... your app should work just fine".

W/rt (2), I do recommend re-compiling against the final product even though it isn't strictly required (from a technical perspective). Naturally, there will have been further changes/fixes in the compilers and the metadata sub-system that will very likely result in a better built assembly.

Some of you might wonder what this is all about. I'll attempt to explain w/o going on any tangents. Please email if there are some tangents that you are interested in ;)

We set the assembly version number of each of the assemblies (all the same version fortunately) in the .NET Framework at major milestones, treating it as an contract between the .NET Framework and it's consumers. We then break that contract by changing the assembly version number again when we start a new milestone (i.e. Beta 1 versus Beta 2; Everett versus Whidbey). Why do we do that? We change the assembly version number for two reasons: (A) the contract has changed since the code inside the assemblies is very substantially different, and (B) a strong identifier (i.e. a version number) needs to be changed to remain a strong identifier.

We changed the assembly version number last early in the Beta 2 milestone, for the reasons described above. We will not change it again in the Whidbey product since the rate of changes to the product has slowed down and because we only want to make changes at this point that are absolutely required to ship the product.

As a result of how we've changed the assembly number and since the assembly binder binds strictly on the whole version number, apps built with Whidbey Beta 2 will continue to reference Whidbey RTM .NET Framework assemblies since their version number will be the same as what the Whidbey Beta 2 app is expecting.

Hope that helps Marc!