Available command line switches for .NET Framework 2.0 setup

With the release of VS 2005 and the .NET Framework 2.0, we began to use a new Windows Installer external UI handler to manage installation of several of the setups that are part of the VS 2005 family, including the .NET Framework 2.0 redistributable and SDK, J# redistributable, VS Tools for Office redistributable, language packs .NET, J# and VS Tools for Office, etc.

This new external UI handler is named install.exe, and you will find an INI file named install.ini included with each product that uses install.exe.  Install.ini expresses many configuration options for the setup in question.  I have described many of the settings used for the .NET Framework 2.0 redistributable in this blog post.

In addition to the INI file, install.exe can be configured using several command line switches.  The following list provides information about all of the command line switches that are supported by the install.exe external UI handler in the VS 2005 and .NET Framework 2.0 family of products:

  • /a – Launches setup in administrative mode.  This mode is used to create a Windows Installer administrative install point that can then be used to install or deploy the product from.  Administrative mode presents UI that allows you to choose the location to stage the files to
  • /l <log file> – Causes setup to create a verbose log in a non-default path.  Setting this value will override the value of the VerboseLog entry in the install.ini file.  If the /l switch is passed, the log file name is required.  If it is provided, it will override the LogFilePrefix entry in install.ini.  If you choose to pass a log file name and there is a space in the path, you will need to enclose the name in quotes.  Leaving this parameter off will allow setup to create a verbose log file in the %temp% directory that has a name beginning with the LogFilePrefix entry in install.ini and ending with a randomly generated character sequence.
  • /lang #### – Specifies the 4-digit language code for the language in which to display the setup UI.  This setting overrides the OS language check and the language specified in the install.ini file.  Setup looks for a file named install.res.####.dll in the same path as install.exe and attempts to load strings from that DLL.  If the DLL with the numerical value passed in via this command line parameter does not exist, install.exe falls back to English strings (located in install.res.1033.dll).  If install.res.1033.dll also does not exist, setup will display an error dialog and exit
  • /msipassthru MSI_PROP_BEGIN”<properties with quotes here>”MSI_PROP_END – Specifies additional property/value pairs that will be passed to the Windows Installer MsiInstallProduct API (or msiexec.exe). This switch also requires that a token be used to prefix/postfix the actual command line arguments.  For example: /msipassthru MSI_PROP_BEGIN”PROPERTY1=Value1 PROPERTY2=Value2″MSI_PROP_END
  • /msipassthru MSI_ARGS_FILENAME_BEGIN<path to file with properties>MSI_ARGS_FILENAME_END – Specifies the full path to a file that contains additional property/value pairs that will be passed to the Windows Installer MsiInstallProduct API (or msiexec.exe)
  • /q – Specifies quiet install mode. Suppresses the display of all setup UI during installation
  • /qb – Specifies basic UI mode for installation.  This will cause install.exe to only show a small Windows Installer progress dialog with no other user interaction required.  This is the equivalent of the msiexec.exe /qb command line switch
  • /qb! – Extends the /qb switch by hiding the cancel button on the progress dialog during installation.  This is the equivalent of the msiexec.exe /qb! command line switch
  • /qu – Specifies quiet uninstall mode.  Suppresses the display of all setup UI during uninstallation
  • /skip_all_checks – Causes install.exe to skip all prerequisites checks that are specified in install.ini.  This may result in setup failing elsewhere because some of the checks are also specified in the MSI itself.  However, this can be useful as a troubleshooting tool if you know the state of the machine(s) that you are installing on very well
  • /watsonsilent – Causes all Watson reports generated by setup in the case of failure to be silently sent to Microsoft instead of displaying a dialog.  This command line switch is only applicable if one of the /q flags is also used
  • /watsonui – Causes all Watson reports generated by setup in the case of failure to display UI informing the user of the issue
  • /? – Displays a help dialog with information about supported command line parameters.  As I was writing this article I noticed that many of the switches that are supported by install.exe are not actually listed in this dialog.  I’ll be reporting a bug to the setup team so that hopefully this will be cleaned up in a future release to present more useful information to the user

<update date=”12/7/2005″> Added a note to the /l log file switch indicating that you need to put quotes around the file name if there are spaces in the name </update>


Comments (39)

  1. Ashith Raj says:

    Can we install Visual studio 2005 Pro on MCE or a Tablet PC?

  2. astebner says:

    Hi Ashith – you can definitely install VS 2005 on MCE or Tablet. I’m actually running VS 2005 on one of the MCE computers in my office right now! Please let me know if you run into any difficulties.

  3. Imtiaz Khan says:

    Hi, My client has only framework 2.0 installed on his machine(only framework 2.0 not VS 2005). I want to add some security settings but there is no shortcut available in administrative tools for "Framwwork 2.0 configuration".

    Can you tell me how i can have framwwork 2.0 configuration shortcut when only framework 2.0 is installed. Thanks

  4. Question

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

  5. What does the "/q:a" do?  /q is supposed to be for silent install but I can find nothing ANYWHERE on what "/q:a" means and it is used in almost every silent install I have looked at.


  6. astebner says:

    Hi Joshua – the /q:a switch is an IExpress self-extracting setup package switch.  Any setup that is built using IExpress will accept that switch.  It suppresses the "are you sure you want to launch setup" and extraction progress dialog that can appear when extracting the contents of an IExpress package at the beginning of a setup.

  7. Manoj Aggarwal says:

    are there any Command Line Switches available for .net1.1

  8. I previously posted a list of command line switches for .NET Framework 2.0 setup.&amp;nbsp; One of the customers…

  9. astebner says:

    Hi Manoj – I have just posted a new list with command line switches for the .NET Framework 1.0 and 1.1 setup packages.  You can find it at http://blogs.msdn.com/astebner/archive/2006/03/18/554535.aspx.

  10. This guide is intended to serve as a collection of links to articles, tools, tips and tricks that explain…

  11. jc says:

    Not truely silent unless you add "/q:a"

  12. astebner says:

    Hi JC – The /q:a switch is used for the IExpress wrapper (named dotnetfx.exe).  The above command line switches are specific to the .NET Framework setup EXE (named install.exe) It is correct that you have to use that switch as well as the silent switch for the setup EXE wrapper.  The full command line for a silent install of the .NET Framework 2.0 is the following:

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

  13. I’ve extracted the dotnetfx.exe to it’s files and I’m trying to install it with the command line of:

    install.exe /msipassthru MSI_PRO_BEGIN"REBOOT="ReallySuppress"MSI_PROP_END /qb!

    And I get a dialog that pops up saying "Cancel, Retry, Ignore" … it looks like a locked file costing dialog.  

    Shouldn’t I not get this?  I’m going to run it with a logfile next and see if my REBOOT public property is realy being set or not.

  14. So I see there is a log by default and I can see REBOOT=ReallySuppress was already being called.  So now I’m just calling it twice.  I also see that Install.exe is the ExternalUI that’s implementing the FilesInUse pattern.

    I’m also calling this package in /qb! so why should I be getting this dialog?  I know the reason is "mscoree.dll" is loaded by another process but it should just do a MoveFileEx resulting in a pendingrenameop and a 3010 exit code.

  15. astebner says:

    Hi Christopher – You should be able to run the following to suppress reboots for the .NET Framework setup:

    install.exe /qb!

    You don’t need to pass through REBOOT=REALLYSUPPRESS in this case.

    If you really want to pass through the REBOOT property, you need to update your command line switches to look like the following:

    install.exe /qb! /msipassthru MSI_PROP_BEGIN"" REBOOT=ReallySuppress ""MSI_PROP_END

    Notice the double quotation marks, and also the spelling of MSI_PROP_BEGIN that you misspelled in your first comment.

  16. Hi Arron-

    The typo was only on the internet. :)

    So here is my bizare usecase.  I have written a bootstrapper purely in MSI.  I use the setup.exe and msistuff from the platform SDK to do WindowsInstaller it self but from within CA’s in the UI sequence after the execute action I call out to literally dozens of applications.  Everything I’ve thrown at it has worked so far except .NET 2.0.

    I read your section about how .NET 2.0 restarts MSI.  I read in the verbose log that it was complaining about the mscoree.dll.  I think that I’m observing that in the ExternalUI generating the FilesInUse style dialog that it’s ignoring the /QB and REBOOT=ReallySuppress.

    It looks like I’m going to have to extend setup.exe to move .net 2.0 before the UI sequence.  I know what I’ve just described sounds crazy, but if I was to show it to you it would probably make alot of sense.

  17. astebner says:

    Hi Christopher – I strongly recommend against using this kind of nested install to chain together multiple MSI packages.  There are some pretty bad issues that nesting in this way can cause – most importantly, it does not allow future hotfixes and service packs for the nested packages to be installed.  You should use some kind of chainer application that is an EXE instead of an MSI to install multiple MSIs one ather the other.  Alternatively, you can deploy the MSIs sequentially using a deployment technology such as SMS or Active Directory.

  18. You have misunderstood me, I’m not doing nested installations. I’m chaining installations together with by calling msiexec /i in the UI Sequence very similar to what a EXE or SMS tool would do.  This gets around the 2 mutex’s that are in WindowsInstaller ( one execute sequence per machine and one ui sequence per process )

    The MSI doing this work doesn’t technically install any software.  It is used as a framework for UI, Costing, File Transfer and CA sequencing.  It looks like it’s a single installer but in reality it fires off a lot of installs in /QB! mode just like you would do with a setup.exe only very little code had to be written.

  19. astebner says:

    Hi Christopher – From what I know, the technical definition of a nested install is calling one MSI from inside another MSI.  That sounds like what you are doing here, regardless of whether or not the parent MSI actually installs anything, and that causes the problems related to installing hotfixes that I described earlier.  I will ask around and figure out if I have a correct understanding of this scenario and let you know if I hear back anything different.

  20. Hi Aaron-  I like your blog and respect you alot so I’m trying to say this very gentle.  What you are referring to is called a Type 7 Custom Action and is called a concurrent installation.


    This type of CA *IS* very bad and has all the problems that you describe.  What happens is the component data from the nested install is merged into your component data and installed in one transaction.  This is because the WindowsInstaller engine has a mutex that only allows one execute sequence at a time.   Both MSI’s end up installed as 1 ProductCode and hence can’t be properly patched.

    This is not what I’m doing nor would I ever, ever do this.  I am using the UI sequence only as a driver process ( similar to a bootstrapper ) to shell out to new processes each one being an msiexec /i.  In this way each package gets properly installed.

    What does this have to do with .Net?  I’m realizing now from your other blog about Dll Images inuse in memory and the way the external UI restarts MSIEXEC that I can’t use my model to install .Net 2.0 without some clever hacking.  So I will move that particular package up to a setup.exe bootstrapper prior to calling into my MSI based bootstrapperr.

  21. astebner says:

    Hi Christopher – I talked to Heath (http://blogs.msdn.com/heaths) a bit and found out that your method is not what I’m thinking of as a typical "nested install" scenario.  I’m sorry for my confusion here and there’s no need to be gentle with me if I’m wrong  :-)

    You should be able to install the .NET Framework 2.0 by calling the MSI directly to avoid this problem you’re seeing.  Doing that will take install.exe out of the picture (it is the one that stops and restarts the Windows Installer service).  You can find instructions for how to do this at http://blogs.msdn.com/astebner/archive/2005/11/17/494312.aspx.

    Please note that the stopping/restarting of the Windows Installer service is designed to minimize scenarios where an old version of mscoree.dll is held in memory by the Windows Installer service, so depending on your scenarios there is a slight chance that deploying the .NET Framework 2.0 MSI directly could lead to errors while trying to install assemblies to the GAC.  However, if you know that these systems will not be installing the .NET Framework 1.0 or 1.1 within the 10 minutes immediately before installing the .NET Framework 2.0, you’ll be safe from that issue.

    Hopefully this helps.  I’m sorry again for my lack of knowledge in this area….

  22. I’m gentle because we are all professionals and I need all the friends I can get. :-)

    I will have to keep the install.exe.  Our bootstrappers tend to install everything and the kitchen sink.  This includes multiple .Net runtimes and loads upon loads of setup prerequisite type redistributables.  

    You guys put quite a bit of effort into an external process/ui handler that could achieve very high levels of reliability… I’m not going to work against the pattern now that I understand what it is trying to do.

  23. astebner says:

    Hi Christopher – Fair enough, thank you for your patience with me while I learned more about this scenario.  Please let me know if you run into any additional questions as you work through building your installer.

  24. I previously posted a couple of blog items (here and here) where I mentioned the verbose logging command…

  25. dinceryelen says:

    framwwork 2.0 configuration shortcut when only framework 2.0 is installed. Thanks

  26. astebner says:

    Hi Dinceryelen – I’m not sure if you are asking a question or making a statement.  If you are asking a question, can you please clarify exactly what you are asking about so that I can try to help?

  27. Details about the .NET Framework 2.0 setup packaging Available command line switches for .NET Framework

  28. Question: I have seen some of your other posts regarding how to install various parts of Visual Studio

  29. I received a question from a customer about how to perform a sequential unattended install of the .NET

  30. Desi says:


    Is it possible to do an unattended "Repair" of .NET 2.0, and specify that the undo information not be stored? I have a very space limited machine, and I get a dialog that notifies me that there is not enough space to continue unless I click on "Ignore" and continue without undo information.

    I’d like to script this to do the repair operation automatically.



  31. astebner says:

    Hi Desi – You should be able to use the DISABLEROLLBACK property (http://msdn2.microsoft.com/en-us/library/aa372899.aspx) to accomplish this.  For example, I’d suggest trying the following command line:

    dotnetfx.exe /q:a /c:"msiexec /fvecms netfx.msi DISABLEROLLBACK=1"

    Or if you are running install.exe instead of dotnetfx.exe in this scenario, you can use something like the following:

    install.exe /q /msipassthru MSI_PROP_BEGIN"" DISABLEROLLBACK=1 ""MSI_PROP_END

    Hopefully this helps.

  32. This guide is intended to serve as a collection of links to articles, tools, tips and tricks that explain

  33. spudnik10 says:

    Hi Aaron,

    I have a scenario when my setup runs an unattended install of dotnetfx20. However, the install can be interrupted by the user at any point. Assuming the install is incomplete, how can I perform an unattended rollback of any files/registry components that have been installed up to this point?

    Thanks in advance,


  34. astebner says:

    Hi Spudnik10 – How is the installation being interrupted in this case?  If it is a "normal" interruption via the cancel button on the progress dialog, the rollback will happen automatically.  If it is not normal (killing the process in task manager for example), then the system will be left in whatever partial install state it was in at the time the install was interrupted and there isn’t a way to trigger Windows Installer to do a rollback.  This is one of the reasons it is bad to kill a setup process instead of following normal cancellation procedures (which of course isn’t always possible due to things like power outages, etc).

    Also, one of the unattended options listed above will suppress the cancel button, so that might be an option for you in this scenario too.

  35. spudnik10 says:


    Thanks for your quick reply – my setup runs the dotnetfx install in quiet mode also, so it’s the cancel button in my setup.exe app that effectively kills the process, leaving the install in an unknown state. My other thought was to extract the msi from the dotnet wrapper, run an MSIInstallProduct on it, thereby allowing me to use the MSIExternalUI callback feature and trap my cancel there. Since I have to do all this dotnet stuff silently though, I need to also suppress the UI for the extraction of the msi files too…

  36. astebner says:

    Hi Spudnik10 – In general, if another setup process is kicking off the .NET Framework setup, it should wait for it to finish and not kill the process in the middle.  That is what Visual Studio setup does if you press cancel during .NET Framework setup for example.  Killing a setup process in the middle of installation will always leave a user’s system in an unknown state and is not a good thing.

    If you extract and run the MSI directly, you can pass a cancel message through to the MSI if a user clicks cancel on your setup.  That will trigger a standard MSI rollback and will not leave your users’ systems in an unknown state.