Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
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:
The .NET Framework 2.0 SP1 and 3.0 SP1 setup packages include logic to do the following:
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:
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
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:
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.