Undocumented unattended install switch for .NET Framework 1.1

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 (17)
  1. Chris Lennon says:

    1. Re /qb Wow, great tip! Is there a switch that will suppress any re-boots?

    2. And pardon my ignorance but what is setup.exe in this context and how is it different from simply having your install package execute dotnetfx.exe with the various switches?



  2. 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?

  3. What is the Un-attended Un-install command for .Net Framework 1.1. Add/remove program requires user interfaction.

  4. Hi Jennifer – Here is a command line you can use to perform an unattended uninstall of the .NET Framework 1.1:

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

  5. Question

    You have written blog posts in the past describing the command line parameters that can be…

  6. Jeremy Weber says:

    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?

  7. 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).

  8. Jeremy Weber says:

    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…



    Neither seem to be working. Any suggestions?

  9. Hi Jeremy – If you run install.exe /q or install.exe /qb, then I thought that setup would not automatically reboot.  However, I am not 100% sure because I have not tried this installation in a scenario that would cause a reboot.

    If you find that reboots still happen, you might want to try the following command line:

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

    Hopefully this helps….

  10. Jeremy Weber says:

    /qb definitely does suppress the reboot, however because the small dialog is missing text I can not use it.

    I will try adding /msipassthru MSI_PROP_BEGIN"" REBOOT=ReallySuppress ""MSI_PROP_END".  Even though it looks crazy:)

    Thanks for all your help.

  11. Jeremy Weber says:


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

    Would a reboot be supressed during a repair?

  12. Hi Jeremy – Theoretically, that same commmand line should suppress reboots during initial install and repair, but I haven’t had time to try  it out yet to confirm for sure.  If you have a chance to try it out, please post your findings here if possible.

  13. Ok,problem understood. It’s related to the bullet in the blog about how install.exe shuts down WindowsInstaller.  Ouch…

  14. pwinant says:

    Does anyone know how to suppress the reboot dialog after installing .NET 1.1 service pack 1? According to Microsoft there’s no way to prevent it, but there must be *some* way since InstallShield installers can do it. I can’t believe MS has a simple command line switch to prevent reboots for the framework but didn’t include a similar mechanism for the service pack.



  15. 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.

  16. steve says:

    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.

  17. 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.

Comments are closed.

Skip to main content