Aaron Stebner's WebLog

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

How to deploy the .NET Framework 2.0 by using the MSI directly

How to deploy the .NET Framework 2.0 by using the MSI directly

  • Comments 38

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:

.NET Framework 2.0 block dialog

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:

  1. 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)
  2. To create an administrative install point - c:\temp\install.exe /a
  3. 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:

.NET Framework 2.0 blank progress dialog

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.

 

  • Thanks for posting this it really helps
    Now i just need to figure out how to make Install Shield 8 do what aspnet_regiis.exe does after installing 2.0
  • Hello

    Thanks for posting this, it really helps.
    Unfortunately I have a problem. I installed via msi installation. Eeach .NET Framework 2.0 application which I run, produce the follow error.
    http://burger.studentspace.ch/temp/error_net.jpg

    Have you some ideas?

    Thanks
  • Hi Karsten - I am not sure what would be causing this error you're seeing.  I don't believe that your method of installing via the MSI directly would cause this.  You may want to check the user and system security settings as well as any application-specific settings and see if you have sufficient permissions to run .NET applications in your environment.
  • Thanks for you answer. I can't check the configuration. The installation doesn't create the management console. Is there an other way to check this settings?

    Karsten
  • Hi Karsten - the configuration wizard comes with the .NET Framework SDK, so you will need to install that to get it.  You can also use caspol.exe that comes with the .NET Framework redistributable, but it only has a command line interface.
  • Question
    You previously posted a set of instructions that can be used to run the .NET Framework 2.0...
  • seems to work - thanks a lot.  I was banging my head for a while before I found this on the web.  
  • Thanks for the instructions. This guide worked a treat. Thank you for posting the info.
  • What if you whant to installe it using an active directory policy? Then you can't add the ADDEPLOY=1 to the commandline.
  • Hi Mean - You can use the steps listed at http://blogs.msdn.com/astebner/archive/2006/02/10/529987.aspx to deploy the .NET Framework 2.0 using Group Policy.  The steps are very similar, but Group Policy sets a property named ADVERTISED that is equivalent to the ADDEPLOY switch listed in this blog post.
  • This guide is intended to serve as a collection of links to articles, tools, tips and tricks that explain...
  • Thank you for positing this article. I was trying to figure out why the progress dialog has a title bar and a cancel button but is otherwise blank for one whole day. Managed to resolve that now!  
  • Hi Aaron!
    I'd like to join the thanksgiving, you've done a great job here. I do have one question, though; is it possible to deploy .NET FW 2.0 with elevated privileges only? I seem to get different errors depending on how I go about the task, but no problems with my admin account.
  • Hi SmilPent - Yes, it should be possible to deploy the .NET Framework 2.0 with elevated privileges, but you have to use machine assignment - the .NET Framework 2.0 setup does not support per-user deployment.  What kind of errors are you receiving when you try this?
  • Hi again,
    The ALLUSERS=1 has not been modified, so I believe the installation is per-machine.
    I seem to encounter the same issue as a previous commenter on another page; firstly, the MSCOREE.DLL issue, which I can now get around. Secondly, the Microsoft.VisualBasic.Vsa.dll access denied issue. I ran Filemon, and tried running gacutil on the file, with "Failure adding assembly to the cache: Access denied." etc as a result. Like I mentioned, I try to install the package with AlwaysInstallElevated, and the user with which I ran gacutil has very limited rights.
Page 1 of 3 (38 items) 123
Leave a Comment
  • Please add 3 and 2 and type the answer here:
  • Post