Auto-magic class registration

[ACordner]

My company is working on an application that uses the VS 2010 Isolated Shell. I created an InstallShield MSI project to deploy the application. The install is designed to simply copy the project's files to a folder on the target system. Everything seemed to be fine until we deployed this on a computer that had Visual Studio 2008 installed on it. After deployment, the VS2008 debugger now fails to run and gives the following error:

Error trying to run project. Unable to start debugging.

An error occurred that usually indicates a corrupt installation (0x80004002). If the problem persists, repair your Visual Studio installation via 'Add or Remove Programs' in Control Panel.


After hours of testing, I found that a VS2008 debugger registry entry was being overwritten during the MSI engine's RegisterClassInfo action.

Registry node prior to install:
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{C5621364-87CC-4731-8947-929CAE75323E}\InProcServer32]
@="C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\VS7Debug\\msdbg2.dll"
"ThreadingModel"="Both"

Registry node after install:
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{C5621364-87CC-4731-8947-929CAE75323E}\InProcServer32]
@="C:\\Program Files (x86)\\Fluke Calibration\\METCAL 8 Beta\\Editor\\DebuggerProxy.dll"
"ThreadingModel"="Both"
"InprocServer32"=hex(7):52,00,27,00,37,00,6a,00,28,00,47,00,42,00,4f,00,7b,00,\
40,00,7d,00,6d,00,51,00,38,00,31,00,2b,00,45,00,48,00,4a,00,6c,00,4d,00,65,\
00,74,00,43,00,61,00,6c,00,45,00,64,00,69,00,74,00,6f,00,72,00,46,00,65,00,\
61,00,74,00,75,00,72,00,65,00,3e,00,62,00,31,00,57,00,46,00,2a,00,75,00,32,\
00,6b,00,7d,00,40,00,68,00,6a,00,4a,00,35,00,2b,00,35,00,5a,00,25,00,43,00,\
50,00,00,00,00,00

Simply restoring this node to it's former settings allows VS2008 debugger to start working normally again.

Since I did not manually setup InstallShield to do anything other than simply copy the files to the target machine, it appears either it or MSI auto-magically detects that this registry node (and possibly others) needed to be written to in order to register the DebuggerProxy.dll library. This library is part of the project.

Investigating our Isolated Shell's main project, I find the DebuggerProxy.dll.manifest file assigns the same GUID to this library that the msdbg2.dll file apparently already uses.

The InstallShield help suggests that the RegisterClassInfo action pulls its data from the AppId table, but this table is empty (initially anyway). So, where is InstallShield or MSI getting the idea that the DebuggerProxy.dll file needs to be registered? Is it the existence of the DebuggerProxy.dll.manifest file that triggers it? I really just want the files copied to the target computer - nothing more!

[manomatt]

hi, this is a long shot at the dark, try to see if dependency and property are set for the file DebuggerProxy.dll's properties? set it to none if you are intended just to copy the file to the machine.

[Christopher_Pai]

Have you considered simply creating a setup prereq file for VS 2010 Isolated Shell? Generally you shouldn't repackage third party MSI's, you should just chain them.

http://blog.deploymentengineering.com/2006/11/using-installshield-12-to-install-net.html