For those of us who will ship their first product on the WinFX platform, the story on the deployment is a very important one. In fact, for all those shipping applications that use the .NET platform this has been a problem in this way or another for quite some time.

The deployment of the .NET based applications is probably the second most frequently asked question on the Internet, right after the one about protecting your IP by preventing code decompilation. It is still a mystery why hasn’t Microsoft made the .NET 1.1 and later the .NET 2.0 required system component update for Windows XP, just like Service Pack 2 was made mandatory.

It was even more confusing to predict what will happen in the Vista time-frame. There was a lot of confusion regarding the version of the .NET that will come pre-installed with the Vista. Even worse, there was rumor and speculation that there will not be a pre-installed version.

Well, now we at least now one thing for sure - the .NET platform will be pre-installed with the Vista. This is to be expected but still good new for the ISVs that will start shipping their products with the Vista wave. On the other hand, the way that naming turned out is both good and bad.

The good thing is that at least for the consumer, this is a good thing. Want to explain to the user what the dependency of your software is? It’s the .NET 3.0 (notice that there are 408(!) comments to the announcement of WinFX to .NET 3.0 name change at the time this post was written). How do you install this? Microsoft provides the installer that is smart enough to install only what’s necessary.

Turns out that the 3.0 version “envelopes” the 2.0 version in a… weird way, looking from the perspective of the previous .NET versions. You see, all the previous versions were a “single package” versions – you got 1.1 version of the compilers, runtime and all the libraries, even though the compilers and runtime might not have changed much between 1.0 and 1.1.

What is happening now is that Microsoft has decided to independently evolve the compilers, runtime and the libraries. So, the .NET version 3.0 keeps the .NET 2.0 compilers and runtime, but adds libraries like WPF, WCF and WF. The next version of the .NET (tentatively version 3.5), that’s the one that will improve on the C# (version 3.0 to confuse the matters) and VB.NET (version 9.0), will improve on the compilers (languages changed!), keep the 2.0 runtime and add libraries like LINQ. Sounds confusing? Only until you think about it a little. Compare the situation with Java 1.5 a.k.a. 5.0 – the Java compiler was upgraded to support generics, but the virtual machine (the runtime) was not changed. In the same way the new features like LINQ will require newer compilers and new libraries, but will not require a new runtime. Still confused? A detailed blog post from Jason Zander might help.

In the end, it is important to note that some confusion exists only in the realm of the .NET developers. Users will have a clean upgrade path – version 2.0, 3.0, 3.5… If I had to choose between a lot of work for me and a simple story for the customer or the other way around, I pick the former every time. As long as I can explain my dependencies to the user with a single simple sentence and have a single installer that will do all the work, I am happy.

On the other hand, I pity the developers of the Fusion sub-system in the .NET (the one responsible for finding the right version of the assembly and loading it) now that consecutive versions of the .NET get installed into several directories reusing pieces of the previous (and even the one before that!) version