How to work around the issue when opening Office applications repairs Visual Studio

Heath Stewart

Microsoft Visual Studio 2010 Beta 1 customers have been reporting that when they start Outlook or any of the Office applications, VS2010 is repaired. This issue can also happen for VS2005 and VS2008, and for any products using Visual Basic for Applications (VBA).

Besides being an annoyance and potentially taking a while to complete, the repair attempt can prompt for source. Picking the right source may not always be obvious from the dialog caption especially if it is truncated. And all the while Outlook or whichever application you started is probably waiting to finish starting up.

Even if you successfully complete the repair operation, this issue may continue each time you start the same application.

How to work around this issue

Windows Installer logs an event that describes the requested feature and which product it is repairing. For this simple workaround, you need to find the latest event log entry. Using information in that event log entry, you’ll remove and re-add a feature and all its components into directory that should always be available.

1. Click on Start
2. Click on Run
3. Type “eventvwr” (without quotes) and click OK. If you are prompted to elevated on Vista or newer, click Continue.
4. Expand Windows Logs and click Application
5. Find the recent warning where the Source is MsiInstaller. In Vista and newer,
   1. Click Filter Current Log… in the right action pane
   2. Check Warning
   3. Type “MsiInstaller” (without quotes) in the Event sources edit control
   4. Type “1001” (without quotes) in the event IDs edit control
   5. Click OK

You should see a message similar to the follow,

Detection of product ‘{316EE0C1-DB94-30BA-95E6-F4959035EE4B}’, feature ‘VB_for_VS_7_Ent_28_x86_enu’ failed during request for component ‘{DD68FEE8-C369-11D1-A173-00A0C90AB50F}’

I’ve also attached an event viewer filter you can unzip and import as a custom view.

Keep the log viewer open with the recent warning of type 1001 and open an elevated command prompt.

• On XP as an administrator,
  1. Click on Start
  2. Click on Run
  3. Type “cmd” (without quotes) and click OK
• On Vista and newer.
  1. Click on Start
  2. Type “Command Prompt” (without quotes)
  3. Right click on Command Prompt and click Run as administrator. If you are prompted to elevated, click Continue.

You’ll now use the information in the warning message to run two commands consecutively. The first command removes the feature, and the second command reinstalls it locally. The reason you need to do this for this simple workaround is explained in detail below. Use the GUID after “product” along with the feature name as shown in the corresponding example below.

start /wait msiexec.exe /i {316EE0C1-DB94-30BA-95E6-F4959035EE4B} /L*vx "%TEMP%\1.remove.log" REMOVE=VB_for_VS_7_Ent_28_x86_enu
start /wait msiexec.exe /i {316EE0C1-DB94-30BA-95E6-F4959035EE4B} /L*vx "%TEMP%\2.addlocal.log" ADDLOCAL=VB_for_VS_7_Ent_28_x86_enu TARGETDIR="%ProgramFiles%\Microsoft Visual Studio 10.0"

You will likely be prompted for your installation media when running the second command, so be sure to have your installation DVD loaded or ISO mounted. If you installed from the web or your media is not available, you will be prompted to download the media from the web.

How to avoid this issue

If you have any external drives connected to your machine, consider disconnecting them when installing Visual Studio or make sure that they are plugged in when starting applications like Outlook if you have any add-ins for those applications installed.

Description of the issue

Some components in Visual Studio are authored to support advertised installations. By default, advertised components will not be installed until they are needed. For COM servers, Windows Installer writes encoded data to the server library registry value like InProcServer32. This information contains information about the product and feature that will install the component. Windows Installer will always trigger a health check when advertised data is present for COM objects since, inherently, the COM server path isn’t registered.

Even though the feature that installs these components is typically installed locally, Windows Installer still writes this encoded data to the registry. This isn’t normally a problem unless the components to be advertised also install to TARGETDIR or a descendant of TARGETDIR that is not otherwise redirected.

Because TARGETDIR must be the root directory of any Windows Installer package, technically every directory is a descendant of TARGETDIR; however, directories like ProgramFilesFolder are automatically redirected to their corresponding directories like C:\Program Files. Custom actions can also redirect directories, and this is typical in Visual Studio. If TARGETDIR itself isn’t redirected, it defaults to ROOTDRIVE which is the fixed drive with the most free space available, and “fixed drive” doesn’t necessarily mean its an internal drive. External drives these days are growing more common. Any descendants of TARGETDIR are also located relative to ROOTDRIVE then.

So if you have an external drive with a lot of free space connected when you installed Visual Studio, a number of components may have gotten installed there. Even if you do not see any files mysteriously appear after installing Visual Studio, components may still have gotten registered to the other drive. This can actually happen for any Windows Installer products.

Now if you start a product like Outlook that might have add-ins installed that use Visual Studio Tools for Office system Runtime (VSTOR) or Visual Basic for Applications (VBA), creating COM objects they install triggers a repair. This happens because Windows Installer requires the COM server path and this, in turn, triggers a health check. Since the component installation directory – TARGETDIR or a descendant when the component was installed – is no longer available, a repair begins but will ultimately fail in this case since the installation directory is unavailable.

Other problems may manifest. For example, if a file within the same feature is missing for unrelated reasons, Windows Installer installer may prompt for source to replace that file.

So if you had an external drive connected when you installed Visual Studio, make sure you keep it connected when starting applications like Outlook if you have add-ins installed – or at least if you’re experiencing this issue. Better yet for VS 2010 Beta 1, disconnect it when installing Beta 1 unless you intend to install Beta 1 to that drive but remember to keep it connected. On a related note, keep in mind that disk space on your Windows system drive is still consumed by Windows Installer, .NET Framework, and a few other components.

We are working to identify all possible components that may cause this issue for future releases, including VS2010.

Filter.zip

Heath Stewart Senior Software Engineer, Azure SDK

Follow