Partager via

Undocumented unattended install switch for .NET Framework 1.1

  • Article

I was helping a customer last week who wanted to push the .NET Framework 1.1 to a series of computers in a corporate network, but wanted to show some kind of progress UI on the client computers. I realized that we added an unattended switch to the setup wrapper for .NET Framework 1.1 based on some customer feedback from 1.0.

You can run .NET Framework 1.1 setup with the following command line switches to install using MSI basic UI:

dotnetfx.exe /q:a /c:"install.exe /qb /l"

This command line will cause the .NET Framework 1.1 to install with no user interaction required, but a small MSI progress bar will appear during installation so the user knows that something is happening on their machine. Note that as stated above, this /qb switch was added in .NET Framework 1.1, so this switch will not work in 1.0 setup.

Those of you with some knowledge of MSI command line parameters might ask why not just have customers extract the contents of dotnetfx.exe and then install netfx.msi directly. Or better yet, why not have them run dotnetfx.exe /q:a /c:"msiexec /i netfx.msi /qb /l*v" or something like that to achieve the same effect without needing to write new code to support the /qb switch for install.exe.

The answer to this is that we want customers who install the .NET Framework 1.0 and 1.1 to use install.exe to do so. There are several reason for this:

  • We shipped .NET Framework 1.0 with some bugs that caused problems if you install using netfx.msi directly instead of going through install.exe. Fortunately, these bugs are fixed in .NET 1.1 and beyond, but they can potentially cause servicing and uninstall problems if .NET 1.0 is installed using the MSI directly.
  • Install.exe will bootstrap and install Windows Installer 2.0 if it is not already installed on the computer. If the .NET Framework is installed by running the MSI directly, it becomes the responsibility of the 3rd party application or administrator who is deploying the .NET Framework to ensure that Windows Installer 2.0 or higher is already installed on the machine.
  • (most importantly and most complicated to explain) Install.exe stops the Windows Installer service (named msiserver) before starting installation of the .NET Framework and after completing installation. This helps eliminate 1935 errors that might otherwise happen while installing the .NET Framework. Windows Installer added support for installing assemblies via native tables (MsiAssembly and MsiAssemblyName) beginning in Windows Installer version 2.0, but it requires the .NET Framework to be present becauses it uses a .NET Framework feature (called fusion) to install assemblies. That logic works fine for "normal" applications but becomes tricky for the .NET Framework itself (which is also an MSI package and needs to install assemblies as part of its own setup). This is what we call a "chicken and egg" problem - one has to come first but which one? The solution we use for .NET 1.0 and 1.1 setup is to copy the the minimal pieces of the .NET Framework needed to install assemblies, and then if Windows Installer detects that the .NET Framework is not present it will use these minimal pieces to install assemblies instead of the normal mechanism. At a really high level, the Windows Installer service will check to see if mscoree.dll exists in %windir%\system32, and if it does not, it will use the minimal pieces (located in the %windir%\system32\urttemp folder) to install assemblies. The complicating factor here is that the Windows Installer service continues to run in the background for 10 minutes after completing any installation activity. If Windows Installer has loaded the minimal pieces of the .NET Framework from %windir%\system32\urttemp, it will still have this version loaded in memory and if another setup needs to install assemblies within the next 10 minutes before the Windows Installer service shuts down, it will skip searching for mscoree.dll and instead use the minimal .NET Framework already loaded into memory. If that version of the .NET Framework in memory is not compatible with the assemblies in the next setup package, Windows Installer will not know this and will try to install the new assemblies with the incompatible .NET Framework in memory, which will fail with a 1935 and/or 2908 error. This problem is not very likely because the .NET Framework is generally designed to be backwards compatible and because it requires 2 setups to be run within 10 minutes. A couple examples of problematic scenarios are the following: Install .NET 1.0 and then try to install .NET 1.1 within 10 minutes by installing netfx.msi directly; and install and uninstall .NET 1.1 and then try to install .NET 1.0 within 10 minutes by installing netfx.msi directly.

As a side note, in the .NET Framework 2.0, we implemented a custom action to install assemblies using fusion APIs directly, in part to eliminate the "chicken and egg" problem. As a result, we see nearly no 1935 errors while installing .NET Framework 2.0. The install.exe setup wrapper still stops the Windows Installer service before and after installation because of possible interactions with other versions of .NET Framework setup due to copies of other versions of fusion being loaded into memory during the 10 minute window that the service would otherwise stay running after installation. Also, .NET 2.0 does not carry Windows Installer 2.0 because of the high market penetration of Windows Installer and because Windows Installer 3.1 has been posted as a mandatory update on Windows Update. That makes bullet #2 above much less of an issue for administrators and 3rd party developers. However, we still recommend installing .NET Framework 2.0 using the install.exe wrapper even though we've improved the scenario of installing using netfx.msi directly.

Even though we recommend using install.exe to install the .NET Framework 1.1 and 2.0, setup will work in most cases when running the MSI directly. It requires more care on the part of administrators or 3rd party setup developers who redistribute the .NET Framework. In controlled environments (such as OEM pre-installations of the .NET Framework), it is much easier to control cases where the Windows Installer service might be running and shut it down separately by running net stop msiserver for example.

Comments

  • Anonymous
    January 31, 2006
    The comment has been removed

  • Anonymous
    January 31, 2006
    Hi Chris - if you use the /q switch or the /qb switch with install.exe it will suppress any possible reboots. If you have an application that calls .NET Framework setup in silent mode, you should listen for the return code - 0 means success with no reboot required, 3010 means success with a reboot required, and anything else means failure. You can theoretically suppress the reboot if you get a 3010 code, but you do so at your own risk and I strongly suggest you reboot if it is requested.

    I am not sure what you mean by setup.exe in this context. There is not a file named setup.exe that is part of the .NET Framework installer. Can you elaborate on this question so I can better understand what you are asking here?

  • Anonymous
    February 07, 2006
    What is the Un-attended Un-install command for .Net Framework 1.1. Add/remove program requires user interfaction.

  • Anonymous
    February 07, 2006
    The comment has been removed

  • Anonymous
    February 07, 2006
    The comment has been removed

  • Anonymous
    April 17, 2006
    dotnetfx.exe /q:a /c:"install.exe /qb /l" seems to be what i am looking for with one. However, the small dialog presented has no text, so it looks funny. Is there a way to show text in that dialog?

  • Anonymous
    April 17, 2006
    Hi Jeremy - I have only seen this blank dialog during unattended install for the .NET Framework 2.0, but not for .NET 1.1.  Are you trying to install 2.0 in this scenario?  If so, there is an underlying bug in Windows Installer that causes the dialog to appear blank.  Unfortunately there is not any available workaround other than to not use unattended mode (you could use fully silent mode or show the whole setup UI but I'm guessing that isn't really ideal for your scenario).

  • Anonymous
    April 18, 2006
    You're right I am trying to install version 2.0.  The crux of the issue is this, the /qb works wonderfully to suppress any reboot prompts that occur, however, I have been unable to suppress them any other way.  I have seen and tried some switches including...

    /norestart
    /REBOOT=ReallySuppress

    Neither seem to be working. Any suggestions?

  • Anonymous
    April 18, 2006
    The comment has been removed

  • Anonymous
    April 18, 2006
    The comment has been removed

  • Anonymous
    April 18, 2006
    Given...

    Dotnetfx.exe /q:a /c:"install.exe /msipassthru MSI_PROP_BEGIN"" REBOOT=ReallySuppress ""MSI_PROP_END"

    Would a reboot be supressed during a repair?

  • Anonymous
    April 18, 2006
    The comment has been removed

  • Anonymous
    June 09, 2006
    The comment has been removed

  • Anonymous
    February 01, 2007
    The comment has been removed

  • Anonymous
    February 01, 2007
    Hi Pwinant - There is not a supported way to suppress only the reboot dialog but still show other UI in the service pack installer.  You can use the /q switch to perform a fully silent install, which will suppress the reboot dialog along with all other UI.

  • Anonymous
    March 11, 2014
    Fortunately, there are several solutions. A silent or unattended install is the most common way to accomplish this. Explain what an unattended install does and how it works.

  • Anonymous
    March 11, 2014
    Hi Steve - Unattended installation means that setup will show UI but won't require the user to click on anything in order to install the product.  Typically, this means that setup will show a progress bar during installation so that the user knows that something is being installed, but it won't require the user to press Next, Install or Finish buttons to start or finish the setup process.