Instructions for chaining installation of Visual Studio 2005 and MSDN

I got a question from a customer who found this blog post describing how to chain silent installation of VS .NET 2003 prerequisites, VS .NET 2003 and MSDN. They wanted to know what the equivalent set of steps would be for chaining silent installation of VS 2005. There have been some modifications to how setup works behind the scenes in VS 2005, most notably the elimination of the separate step that used to be required to install prerequisite components for VS, so happily I can say these steps are much simpler than in the past. Here are the steps for VS 2005 (using the same format as my previous post).

To start with you should stage Visual Studio bits to a network share so that you can use this as your installation source later on. You can accomplish that with the following steps (also described in the VS readme located in the file adminreadme.htm in the Setup subdirectory on VS Disk 1):

  1. Create a folder on your server, such as \\server\vs2005
  2. Create subfolders named \\server\vs2005\vs and \\server\vs2005\msdn
  3. Copy the contents of all CDs labeled Visual Studio 2005 to \\server\vs2005\vs. If prompted, choose yes to overwrite existing files.
  4. Copy the contents from all the CDs labeled MSDN Library for Visual Studio 2005 to \\server\vs2005\msdn. If prompted, choose yes to overwrite existing files.
    NOTE: You can substitute a different MSDN Quarterly Library for the version of MSDN that shipped with Visual Studio 2005 if you choose

Now that you have a network image, you can create the unattended INI file to install VS 2005 and MSDN using the following steps:

  1. Locate a test computer that has the same operating system that you want to deploy Visual Studio to in your network, and make sure that it does not already have Visual Studio 2005 installed
  2. Install .NET Framework 2.0 on your test computer (because this is required for creating an unattend file for Visual Studio in the next step)
  3. Run \\server\vs2005\vs\setup\setup.exe /createunattend \\server\vs2005\datafiles\vs.ini /vsupdate=\\server\vs2005\MSDN\setup.exe /vsupdateargs="qn"
  4. Open \\server\vs2005\datafiles\vs.ini, go to the [PostSetupLaunchList] section and change """qn""" to /qn
  5. Go to a clean computer without Visual Studio 2005 installed and run \\server\vs2005\vs\setup\setup.exe /unattendfile \\server\vs2005\datafiles\vs.ini to test the unattended installation process

There are a couple of gotchas that I have seen that you should keep an eye out for when following these instructions:

  • Make sure to note the extra \setup\ directory for the Visual Studio setup.exe in the steps above. Unattended installation will not work correctly if you run the setup.exe in the root of the \\server\vs2005\vs folder; you must use \\server\vs2005\vs\setup\setup.exe.
  • Make sure that you have write permission for the location that you create your data file at in step 3 (in this example I used \\server\vs2005\datafiles). You will get an error if you try to create the data files on a share that you do not have write permissions for.
  • Make sure that you create the INI file on a computer that does NOT already have Visual Studio 2005 installed. If you have VS installed, you will end up creating an INI file for a maintenance mode update instead of an initial install of VS.
  • The INI file for VS is unique to each version of VS (such as Pro, Standard, Team System), and also unique to the OS that you want to install on (Windows 2000, Windows XP, etc). Make sure that you create INI files on computers that match what you will eventually be deploying to.

There is an advanced trick that you can use when creating this unattend script as well:

  • If you want to perform a full install of MSDN to the local hard drive instead of a default installation, you can read the steps at this blog post to learn how to update your vs.ini file to call MSDN setup with the correct parameters to accomplish this.

In the VS 2003 instructions there was an additional advanced trick regarding waiting for the setup process to exit and checking the return code. The workaround I listed in my previous post is not necessary in VS 2005 because setup now has specific logic to not copy itself to the %tmep% folder and start a new process if it detects it is being run in administrative installation mode.