This documentation is archived and is not being maintained.

Troubleshooting Windows Installer Deployment 

The topics in this section cover various problems that you might encounter when creating deployment projects and deploying applications.

Any application that references the System.Data namespace has a dependency on Microsoft Data Access Components (MDAC) version 2.7 that cannot be detected by the deployment tools. If MDAC 2.7 or later is not installed on the target computer, the application will fail. For more information, see Deployment and Dependencies.

To prevent this error, you should add a launch condition that can check for the correct version of MDAC and stop the installation if it is not found. For more information, see How to: Add a Launch Condition for Microsoft Data Access Components.


An alternative to adding a launch condition is to include an MDAC merge module in your deployment project that will automatically install MDAC if needed. A merge module for MDAC is not included in Visual Studio; however, one may be available at a later date on the Microsoft Web site.

When you deploy an MFC application using a Visual Studio deployment project, dependencies for the localized merge modules Mfc_loc_e.msm and Mfc_loc_fe.msm are not detected. The merge modules are included with Visual C++; the default installation location is \Program File\Common\Merge Modules. In order to distribute a localized MFC application, you need to manually add the two merge modules to your deployment project. For more information, see Deployment and Dependencies.

When a project output group, assembly, or merge module is added to a deployment project, any dependent assemblies are automatically detected and added to the project. If a dependent assembly is loaded at run time by means of code, it cannot be detected by the deployment tools. You should avoid loading assemblies from code, if possible, or manually add the dependent assemblies to your deployment project. For more information, see Deployment and Dependencies.

When you install a Web Setup to a Web server, the VirtualDirectory property for the Web Application folder and any Web Custom Folders determines where files placed in those folders will be installed relative to the Web root. If this property is left blank, the files will be installed in the Web root folder (inetpub\wwwroot). For more information, see VirtualDirectory Property.

By default, when you install a Web application using a Web Setup deployment project, files are installed to a folder with the same name as the deployment project directly beneath the Web root folder. The VirtualDirectory property of the Web Application folder determines where the files are installed. To install to the Web root directory, change the VirtualDirectory property to null. (Delete the default value.) For more information, see VirtualDirectory Property.

This section is new for Visual Studio 2005 SP1.

When you create a Web Setup deployment project in Visual Studio 2005 on Windows Vista, you need to turn on the Windows feature IIS Metabase and IIS 6 configuration compatibility, and you need to be logged on as an Administrator; otherwise you will be unable to run setup.exe to install the project.

When a Web application is copied to a Web server using the Xcopy command, Internet Information Services (IIS) is not automatically configured for your application. Debugging will not work because the application folder is not recognized as an application root.

After copying, you will need to set the new folder as an application root using the IIS Manager. In addition, you should set the permissions for the application's Bin folder to prevent DLLs from being downloaded.


Rather than using the Xcopy command, consider using the Copy Project command or a Web Setup deployment project. For more information, see Deployment Alternatives.

Unfortunately, there is no direct way to turn off dependency-analysis searching and resolution. However, there is a workaround: you can clear the Include standard search paths option in the dialog box that appears when you click the SearchPath property.

There are a few additional points to consider:

  • You need to add your files using the Add File command. (On the Project menu, point to Add, and then click File.) If you use Add Project Output (on the Project menu, point to Add, and then click Project Output), dependencies reported from the code project will be included.

  • When you build, you may see one or more Unable to find dependency warnings, but you can ignore these in this case.

  • If you want to turn off dependency analysis only for some files, you can put those files in a merge module project with standard search paths turned off. Then use Add Merge Module (on the Project menu, point to Add, and then click Add Merge Module) to include the .msm in a regular Setup project with standard search paths turned on.

Visual Studio creates advertised shortcuts so that, upon launch, the program verifies that all of its files exist. To change this behavior so that Visual Studio does not repair the file, select the files in the Setup project and change the Condition property to NOT REINSTALL so that the file will not get reinstalled on a repair. Set its Transitive property to TRUE so that the condition is re-evaluated. This will cause the installer to appear briefly on the screen the first time after the file is deleted, while it verifies that the file should not be reinstalled, but you will not see the installer after that.

You can use one of the following methods:

  • Add a call in your code to System.Diagnostics.Debugger.Launch. This method opens Just-In-Time debugging and allows you to attach a new debugger to your code.

  • Add a call in your code to MessageBox.Show("Debug Me"). When the message box appears, use Visual Studio to attach to the MessageBox process. Then place breaks (for Visual C# projects) or stops (for Visual Basic projects) in the code.

  • Set your debugging preferences to start InstallUtil.exe (which is located in \winnt\\Framework\version) and pass it your assembly as a parameter. When you press F5, you hit your breakpoint. InstallUtil.exe will run your custom actions in the same way that MSI does.

This is a known Regasm bug. If your assembly has a dependency, for example on another class library, RegisterCOM might not work because Regasm is called to get the registration information. Because Regasm is called in the \obj directory, the dependency is not found, and Regasm fails without notification. The best workaround is to add the assembly manually from the \bin directory. Another workaround is to use RegisterSelfReg.

Also, make sure that you manually register the assembly using Regasm/Codebase. If your assembly is not in a shared location, it is not found unless it is in the same directory as the calling code. /Codebase enters the directory into the registry.

Windows Installer logs the operations that occur while it installs programs in a log file. The log file is located in the directory where the .msi file resides.

There are two ways to do this:

  • Run the following command from the command line, using the logging switch:

    misexec /i mysetup.msi /l*v mylog.txt
  • Save the following as a .reg file and load it into your registry:


    Then go to your \temp directory and sort the log files by date. The most recent msi*.log file is from the most recent install or uninstall.

  1. Assume that the previously installed product, Product 1, is installed and has a file named MyFile.txt.

  2. Use ORCA (from the Windows Installer SDK) to view the File table, and find the row that represents MyFile.txt.

  3. Note the value of the Component_ column and then open the Component Table.

  4. In the Component Table, find the row that has the appropriate Component_ value in the Component column, and copy the value of ComponentID to the Clipboard. Close ORCA.

  5. In your Setup project, open the Launch Conditions Editor and add a Windows Installer Component Search. For the ComponentID property of the new search, paste the ComponentID that you copied in the previous step.

  6. Copy the Property property. It should be something like COMPONENTEXISTS1.

  7. Open the File System Editor and select the Application Folder.

  8. Edit the DefaultLocation property to be something like [COMPONENTEXISTS1]MySubFolder (because the path in COMPONENTEXISTS1 includes a trailing '\').

After step 6 above, you might want to add a condition to the Launch Conditions Editor to check whether the component was found, and to block installation and show a message if it was not. The condition would be COMPONENTEXISTS1 (which means it is okay to run the installer if COMPONENTEXISTS1 is not empty).

To install custom Web folders to a port that is not designated by default, run your installation from the command line. The command must include the Property property values for each of your Web Custom Folders. Typically, a value would be something like NEWWEBPROPERTY1. You also need to include TARGETPORT for the Web Application Folder.

For example, if your Web server is on Port 20, your command line should look like this:

msiexec /i mywebsetup.msi TARGETPORT=20 NEWWEBPROPERTY1PORT=20

The above command is for only one Web folder. If you have more than one Web folder, add more PROPERTY=VALUE pairs as specified above for each folder to redirect each listed folder's port to the specified port.

You might want to remove the Installation Address dialog box, because if someone changes the port in the user interface during installation, the Custom Web Folders will use the command-line value.

To install to the root of a Web site, for example, c:\inetpub\wwwroot, set the VirtualDirectory to an empty string, either in the Web Setup project, or during installation.

If you try to install a ServicedComponent into the global assembly cache (GAC) and configure it in the COM+ catalog, you might receive the following compilation error:

"Unable to build custom action named 'Primary output from RegServer (Active)' because the file's Folder property is set to Global Assembly Cache."

This installation is not supported, because assemblies in the GAC are not always available (committed to the GAC) when the custom actions are run.

The workaround is to put your code into different files and put your custom action code into a file that is not going to the GAC, if possible. Sometimes it is not possible to distribute the code in this way.

  1. Create a .vbs file containing the following code:

    Set WshShell = CreateObject("WScript.Shell")
    WshShell.Run """" & Property("CustomActionData") & """",7,False
    Set WshShell = Nothing
  2. Open your Setup project and go to the Custom Actions Editor.

  3. Select the Commit node, right-click, and add a new Custom Action.

  4. Browse the file system to add the .vbs file you created in step 1.

  5. Edit the CustomActionData property by adding the following, where YourApp.exe is the name of your startup application file:

    [TARGETDIR] YourApp.exe

  1. In your Setup project's directory, create a new Uninstall.bat file.

  2. In your Setup project, copy the ProductCode property (a value like [12345678-1234-1234-1234-123412341234]).

  3. Edit Uninstall.bat so that it has one line containing the following, where ProductCode is the value you copied in step 2:

    Msiexec /x ProductCode

  4. Add Uninstall.bat to your Setup project's application folder.

  5. Right-click Uninstall.bat and click Create Shortcut to create a shortcut.

  6. Put the shortcut in the appropriate Start menu folder in the Setup project.

  7. Rename the shortcut; for example, "Uninstall Application Name."

For information on how to modify security on a computer during installation, see the MSDN article "Increasing Permissions for Web-Deployed Windows Forms Applications" at

This guide will give you the information necessary to plan and implement the effective deployment of your .NET Framework–based applications: "Deploying .NET Framework-based Applications" at

Updated software and merge modules can be installed from the Downloads page on the Web site:

The Microsoft .NET Framework Setup.exe Bootstrapper Sample can be found at this location:

The Visual Studio .NET Framework Bootstrapper Plug-in can be found at this location:

If you are receiving an "Unrecoverable Build Error" error message when you build Setup and Deployment Projects, read this article:

"PRB: 'Unrecoverable build error' error message when you build Setup and Deployment projects" at

If you are receiving error messages such as An error occurred when validating. HRESULT = '80040155', see "PRB: "Unrecoverable build error" error message when you build Setup and Deployment projects" at and follow the steps under the heading Missing registrations.

The article "Modifying Internet Information Services During Deployment with Custom Actions" at explains how to fix several problems, including:

  • How to modify settings for an IIS folder that are not available on a Web Folder in the File System Editor.

  • How to deploy a hybrid application that uses both Visual Basic 6.0 and Visual Basic .NET (or later).

  • Changes in deploying Visual Studio .NET (or later) applications as compared to Visual Basic 6.0 applications.

For information on deploying an ASP.NET application using Visual Studio .NET, see "Deploying an ASP.NET App Using Visual Studio .NET" at

The following Knowledge Base Articles provide information about Windows Installer deployment issues: