Looking behind the scenes of the setup wrapper used for the .NET Framework 2.0
In the past, I've written a little bit about the packaging for the .NET Framework setup, including changes that have been made for the .NET Framework 2.0 (notably, the post here). I wanted to talk a little bit more about the underlying setup wrapper package and how it works. The setup wrapper is an MSI external UI handler that we specifically designed to be generic so that different types of MSI-based setup packages could use it. In fact, the same underlying wrapper is used to install the .NET Framework 2.0, the J# redistributable 2.0, the .NET Framework 2.0 SDK, .NET Framework and J# redistributable language packs, and a lot of the smaller MSI-based products that are a part of Visual Studio setup.
Let's take a quick look at the contents of the setup wrapper by downloading a build of the .NET Framework 2.0 (for example, from here). You'll see the following files:
- install.exe - the main setup executable
- install.ini - the settings file that controls some of the behaviors and appearances of the setup
- install.res.XXXX.dll - languages resource DLL that provides strings for the setup UI in each supported UI language
- eula.XXXX.txt - EULA files for each supported UI language
- unicows.dll - support DLL used to enable the setup wrapper to work on ANSI operating systems like Windows 98 and ME
- netfx.bmp - bitmap to display in the top right corner of the setup UI pages; it is specified in install.ini; in the case of the .NET Framework this bitmap is just a blank picture
- netfx.msi - the MSI for the product
- mscoree.dll - this file is included specifically because the product being installed is the .NET Framework and we are trying to optimize some files-in-use scenarios to minimize reboots
Since this setup wrapper is designed to be generic, it can actually be used to install most MSI packages and not just the one it is packaged with. As an exercise, I decided to try to swap out the UI handler and use this setup wrapper to install the Orca MSI viewer/editor package. Here are the steps I took:
- Download the .NET Framework 2.0 from here
- Run dotnetfx.exe /t:c:\temp /c to extract it to a temporary folder
- Download Orca from here and save it to the same folder as in step 2
- Install Orca so that I can use it to edit the Orca MSI
- Open the Orca MSI in Orca and drop all of the contents of the Dialog table (because we are not going to use the built-in UI)
- Open install.ini and change the ProductName and ProductMsi
- Save and close install.ini
- Right-click and choose to uninstall Orca so that we can test the installation scenario
- Run install.exe from the temporary folder used in steps 2 and 3 above and install Orca using the same UI as the .NET Framework
- Re-run install.exe and choose the uninstall radio button
I will explore more details about this setup wrapper in a future blog post, including the following:
- Describing the settings in the install.ini
- Outlining strengths and weaknesses of this setup wrapper and explain why some of the design decisions were made the way they were
- Show an example about how to configure a more complex setup (such as the .NET Framework 2.0 SDK) using this setup wrapper.
Comments
Anonymous
August 16, 2005
Reasons for setting ARPSYSTEMCOMPONENT to 1 despite the dangers.Anonymous
August 17, 2005
I found a couple of recent posts by Heath Stewart that describe the ARPSYSTEMCOMPONENT property that...Anonymous
July 12, 2006
With the release of VS 2005 and the .NET Framework 2.0, we began to use a new Windows Installer external...Anonymous
November 10, 2006
A while back, Quan To posted an item on his blog that briefly described a project he worked on to helpAnonymous
February 10, 2007
Question: I am building an MSI-based setup for my application. I would like the setup to contain UI stringsAnonymous
February 21, 2007
Reasons for setting ARPSYSTEMCOMPONENT to 1 despite the dangers.