Since the .NET Framework 3.5 shipped, I've written a few blog posts about some of the setup and deployment issues that can affect this product.  Behind the scenes, the installer for the .NET Framework 3.5 has some architectural differences from previous releases of the .NET Framework that I've alluded to in a few of those previous posts, and I wanted to take a little time to describe these differences in a bit more detail.

How the .NET Framework 2.0, 3.0 and 3.5 fit together

The .NET Framework 3.5 is essentially an add-on that introduces new features to the .NET Framework 2.0 and 3.0 products but continues to run on the version of the common language runtime (CLR) that shipped in the .NET Framework 2.0.  This is similar to the model introduced in the .NET Framework 3.0, which is essentially an add-on for the .NET Framework 2.0 but did not introduce a new version of the CLR.  As a result of this add-on model, the .NET Framework 3.0 setup requires the .NET Framework 2.0 as a prerequisite, and the .NET Framework 3.5 requires both the .NET Framework 2.0 and the .NET Framework 3.0 as prerequisites.  This is sometimes called a "nesting doll" model for creating a product.

.NET Framework 3.5 setup includes service packs for both the .NET Framework 2.0 and 3.0.  These service packs install as prerequisites because some of the new features introduced in the .NET Framework 3.5 require updates to the originally released versions of both the .NET Framework 2.0 and 3.0.

When the .NET Framework 3.5 project first got started, the service packs for the .NET Framework 2.0 and 3.0 were being built as a series of Windows Installer patches (MSP files).  It quickly became clear that the number of files being changed by these service packs was going to lead to the service packs being nearly as large as the original versions of the products.  This would mean that any customers needing to redistribute the .NET Framework 3.5 with their products would have to include the original versions of the .NET Framework 2.0 and 3.0 and nearly equal-sized service packs for each of them, which would have caused the overall size to grow even larger than it already has.

As a result, the decision was made to create slipstream releases for both the .NET Framework 2.0 SP1 and 3.0 SP1.  These slipstream releases include the original payload plus all of the fixes that are a part of the service packs.  They will successfully install on systems that had the original releases of the .NET Framework 2.0 and 3.0 as well as on systems that did not yet have either version installed (whereas, standalone service packs only install if the original version of the product was previously installed).

.NET Framework 2.0 SP1 and 3.0 SP1 slipstream behind-the-scenes details

Typical slipstreams for MSI-based products are produced by building a layout that is identical to the original release, but with updated binary content.  However, the slipstream releases of the .NET Framework 2.0 and 3.0 are constructed differently behind the scenes than a typical slipstream release.

The .NET Framework 2.0 SP1 and 3.0 SP1 setup packages consist of the following payload:

• A base MSI that contains no files of its own - it only writes some registry values used for product-level detection
• A series of MSPs that contain the file payload for .NET Framework features, divided up logically into sub-features that will likely need to be updated as a unit in the future

The .NET Framework 2.0 SP1 and 3.0 SP1 setup packages include logic to do the following:

• Detect the processor architecture and install the base MSI and the appropriate set of MSPs during the initial installation transaction.  The ability to install multiple patches in a single transaction like this is a new feature available starting in Windows Installer 3.0.
• Use the Windows Installer major upgrade feature to automatically uninstall the original version of the .NET Framework 2.0 or 3.0 during SP1 setup if they are present on the system.  This ensures that all systems are baselined at the new service pack level after installing the slipstream package.

Each of the MSPs installed during .NET Framework 2.0 and 3.0 SP1 setup is marked to not allow uninstall, which is why you see a series of updates that do not have Uninstall buttons listed in Add/Remove Programs for each of these products (if you check the Show updates box at the top of the Add/Remove Programs control panel).

Implications of this slipstream design

There are a few interesting results that fall out of this slipstream design that warrant a bit more in-depth discussion:

• Because all of the files that are a part of the .NET Framework 2.0 SP1 and 3.0 SP1 are installed via patches, the source files are cached automatically by Windows Installer so they will be available for repair and uninstall scenarios.  The original releases of the .NET Framework 2.0 and 3.0 had to include specific logic to cache the source files for repair scenarios, but this logic is no longer needed in the slipstream service packs.
• The original version of the .NET Framework 3.0 consisted of multiple MSIs with payload for different features (Windows Communication Foundation, Windows Presentation Foundation, Windows Workflow Foundation).  The slipstream 3.0 SP1 release consolidates this payload down to a single MSI with a set of associated MSPs.  This means that repairing or uninstalling the .NET Framework 3.0 SP1 only requires interacting with one MSI instead of several.
• The .NET Framework 2.0 and 3.0 both support installing on 32-bit and 64-bit platforms.  In the original releases, the 64-bit packages were separate from the 32-bit packages and carried both 32-bit and 64-bit payload.  This meant that customers who needed to redistribute both the 32-bit and 64-bit versions had to carry the 32-bit payload twice - once in the 32-bit setup package and a second time in the 64-bit setup package.  Splitting the payload of the .NET Framework 2.0 SP1 and 3.0 SP1 into MSPs allows the .NET Framework 2.0 SP1 and 3.0 SP1 to use the same 32-bit source files for both 32-bit and 64-bit setup.  This will reduce the overall package size for customers who need to redistribute both the 32-bit and 64-bit versions of 2.0 SP1 and/or 3.0 SP1.
• Partitioning the payload of the .NET Framework 2.0 SP1 and 3.0 SP1 into a series of patches allows for more easy creation of future slipstream packages that include updates to a subset of the collection of patches.  It becomes as simple as building the patches that include updated payload and then packaging them with the MSI and the rest of the MSPs that are included with SP1.  These future patches could also be delivered as standalone hotfixes that can be independently uninstalled if desired.

Additional information

• There are links in this blog post to more detailed information about the fixes included in the .NET Framework 2.0 SP1, 3.0 SP1 and 3.5 and the install locations of each version.
• You can find instructions for creating an administrative install point for the .NET Framework 2.0 SP1 in this blog post
• You can find instructions for creating an administrative install point for the .NET Framework 2.0 SP1 in this blog post

It is also interesting to note that the Silverlight 1.0 installer uses a similar packaging scheme behind the scenes.  It includes an MSI that does not have any files of its own, and an MSP that includes the file payload.

<update date="1/21/2008"> Added links to the instructions for creating administrative install points for the .NET Framework 2.0 SP1 and 3.0 SP1 so they'll be easier to find </update>