Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

Some behind-the-scenes details about .NET Framework 2.0 SP1 and 3.0 SP1 setup

Some behind-the-scenes details about .NET Framework 2.0 SP1 and 3.0 SP1 setup

  • Comments 10

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>

 

  • PingBack from http://msdnrss.thecoderblogs.com/2008/01/18/some-behind-the-scenes-details-about-net-framework-20-sp1-and-30-sp1-setup/

  • PingBack from http://blog.deploymentengineering.com/2008/01/good-bad-or-just-different.html

  • Aaron, this is great posting.  Thank you.

  • Since the .NET Framework 2.0 SP1 and 3.0 SP1 shipped (as prerequisites for the .NET Framework 3.5 and

  • Since the .NET Framework 2.0 SP1 and 3.0 SP1 shipped (as prerequisites for the .NET Framework 3.5 and

  • PingBack from http://msdnrss.thecoderblogs.com/2008/02/19/how-to-perform-a-silent-repair-and-uninstall-of-the-net-framework-20-sp1-and-30-sp1/

  • 1stup, thanks for the very helpful blogs - I've checked out a few, including the admin install point one.

    Secondly, sorry for what is probably a foolish query here, but I really have searched high and low, tried many things, but cannot perform what I'm after: a silent install of .Net Framework 2.0 SP1, using the native "NetFx20SP1_x86.exe"

    I can happily install .Net Framework 2.0 using:

    dotnetfx.exe /Q:U /C:" install.exe /q"

    And I have read that for .Net Framework 3.0 this works:

    dotnetfx3.exe /q /norestart

    or apparently even the older style switches:

    dotnetfx3.exe /qb!

    But, it seems that no matter what switches I use for NetFx20SP1_x86.exe, it ALWAYS pops up the EULA page.

    I'd love to know how to install NetFx20SP1_x86.exe silently, and accept the EULA, ideally with "minimal UI" ie just a progress bar, rather than fully silent install.

    The Admin Install Point method is of no use to me, because all the machines I need to install .Net 2.0 SP1 onto are only available over a slow WAN link, yet they have fast local internet connections BUT autoupdate disabled for other reasons. Should also point out this is a non-domain, non-AD environment.

    So, what I'm aiming at is to be able to remote control each PC, download "NetFx20SP1_x86.exe" from MS to each local machine, then run a simple batch file to install .Net 2.0 SP1.

    Any ideas gratefully received!

  • Hi theUtmost - The netfx20sp1_x86.exe package can be installed in silent mode by running netfx20sp1_x86.exe /q /norestart.  Please note that this package will not allow you to install on Windows Vista (because the .NET Framework 2.0 is an OS component, and the service pack has to be installed by the OS servicing system and not by this MSI package).

    The only supported option to run the .NET Framework 2.0 SP1 in minimal UI mode with just a progress bar is to create an administrative install point and deploy the MSI directly with the /qb or /qb! switch.

    Hopefully this helps!  If you run into issues, the .NET Framework 2.0 SP1 setup creates log files named %temp%\dd_net_framework*.txt that can be helpful for debugging.

  • The beta version of the .NET Framework 3.5 SP1 and Visual Studio 2008 SP1 were released a few weeks ago.

Page 1 of 1 (10 items)
Leave a Comment
  • Please add 2 and 2 and type the answer here:
  • Post