If you try to extract the contents of the .NET Framework 2.0 setup package and install it using the MSI directly, you will see a blocking dialog that looks like the following:
This type of blocking dialog does not appear when trying to install the .NET Framework 1.0 or 1.1 using the MSI directly.
If you look at the .NET Framework 2.0 netfx.msi in Orca, you can see that there is a custom action that starts with the name CA_BlockDirectInstall_GUIH_SKU_URT. Then, if you look at the InstallExecuteSequence table of the MSI, you will see that this custom action has the following condition: ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1) ) AND ( NOT (ADDEPLOY = 1 OR USING_EXUIH = 1 OR USING_EXUIH_SILENT = 1 OR ADVERTISED = 1 OR ProductState >= 1) ). As you can see from these conditions, this custom action will fire and show this block dialog unless one of those properties is passed on the command line or the product is already installed.
As I previously described in this blog post, we created a new external UI handler for the .NET Framework 2.0. Along with this external UI handler, we added this custom action to block the user from installing via the MSI directly as a means of more strongly encouraging people to install using the external UI handler (side note – this is the technique described in this post on the Windows Installer team blog for using external UI handlers).
The external UI handler for the .NET Framework 2.0 includes a command line parameter (described in this previous post) to invoke administrator mode – you can enter this mode by running install.exe /a. This administrator mode is essentially a UI wrapper around the standard msiexec.exe /a command line parameter for creating an administrative install point (AIP) for an MSI. It requires you to accept a EULA, then allows you to specify a location to stage the files for the administrative install point. The interesting thing is that if you run install.exe /a and then look at the verbose MSI log file (named %temp%\dd_netfx20_a_msi*.txt), you will see that the property ADDEPLOY=1 is set while creating the AIP. However, this property is not used at all during creation of the AIP, and it is not saved as a part of the staged MSI. Therefore, even if you try to install the .NET Framework 2.0 using the AIP created using install.exe /a, you will still run into the block dialog shown above.
To make a long story short, you can use the following command lines to create an administrative install point and install the .NET Framework 2.0 using the MSI directly:
- To extract the contents of the setup package – dotnetfx.exe /t:c:\temp /c (or you can substitute any path of your choosing for c:\temp)
- To create an administrative install point – c:\temp\install.exe /a
- To install using the MSI directly – msiexec.exe /i netfx.msi ADDEPLOY=1
If you are interested, you can combine the steps above if you do not care about being able to extract the contents of dotnetfx.exe or create an administrative install point:
- To combine steps 1 and 2 above to create an administrative install point without extracting dotnetfx.exe first – dotnetfx.exe /c:”install.exe /a”
- To combine steps 1, 2 and 3 above to directly install the MSI – dotnetfx.exe /q /c:”msiexec.exe /i netfx.msi ADDEPLOY=1 /qn”
One other item I should point out here – you will also notice when you install the MSI directly with basic UI (using the /qb switch instead of the /qn switch above), the progress dialog has a title bar and a cancel button but is otherwise blank like the following:
The .NET Framework 2.0 MSI has been configured to be language-neutral (described in more detail here if you’re interested), and there is a bug in Windows Installer that when a language-neutral MSI with no action text or error text is installed in basic UI mode, it will not display any of the standard messages in the progress dialog. Unfortunately, this bug is present in all current versions of Windows Installer up to and including version 3.1. I tried an installation scenario using basic UI mode on a recent Windows Vista build and verified that this bug has been fixed in Windows Installer 4.0 (which is included in Vista).
One final thing – all of the details in this blog post apply to all .NET Framework 2.0 and VS 2005 products that use the new external UI handler we have created. This includes the .NET Framework 2.0 SDK, the J# redistributable package, the VS Tools for Office Runtime, Document Explorer, etc. Essentially, any setup package included as part of Visual Studio that is packaged as a self-extracting executable and contains install.exe, install.ini and install.res.####.dll will behave the same way.
I realize this topic is a bit involved and confusing and represents a change from previous versions of the .NET Framework, so please let me know if you have any questions or run into any problems getting things to work for you.