views:

55

answers:

3

I have a project that uses a few 3rd party DLLs, and am working on the setup project for deployment. The program runs fine when running (debugging) from within Visual Studio 2005, but does not when "installed".

The DLLs get copied to the application folder correctly. My understanding is that the DLLs are not being registered by the installer. "Retreiving the COM class factory for component with CLSID { GUID } failed due to the following error: 80040154"

In the setup project, each DLL assembly has the "Register" property set to "vsdraCOM", which I thought was supposed to trigger registration.

Edit: It appears they are all .NET assemblies as is my application, and registration should not be an issue. Title changed to reflect this.

This seems like it should be pretty basic, but I don't What should I be doing?

A: 

Use Dependency Walker (http://dependencywalker.com/) to check what else the DLLs may be trying to load.

Then try searching for your GUID in the registry under HKCR\CLSID where InprocServer32 should contain a path to a successfully registered DLL.

PhilMY
It looks like these are .NET assemblies. According the Dependency Walker, each is only dependent on MSCOREE.DLL, which appears to be the .NET runtime (?). Interestingly, buried in the house of cards, MSJAVA.DLL seems to be missing.Visual Studio also shows each as being dependent on the .NET Framework, but also an additional dependancy of one on another (both included). This last one is not shown in Dependency Walker.Finally, I am unable to locate the GUID in the registry.
mbmcavoy
Ah, I was digging in to the missing MSJAVA.DLL issue, and per the Dependency Walker FAQ, it is an optional component and it is OK to be missing...
mbmcavoy
A: 

If those are normal COM object (not .NET assemblies) that are self registering (i.e. you can register them with regsvr32) then you want vsdraCOMSelfReg not vsdraCOM. vsdraCOM is used to register .NET assemblies for COM interop.

Yeah, it's not intuitive at all.

shf301
I believe these are .NET assemblies, due to dependencies, and they fail to register with regsrv32.
mbmcavoy
A: 

The DLLs in use had come in an SDK package with documentation, code examples, etc. from the vendor, in an installer. I had all the loose files which transferred when moving to a new computer, but didn't catch that I had not actually run the installer on the new computer.

Installing the SDK must do whatever registration was needed - my application now runs properly. I can install on a target machine by running both installers, which is acceptable.

mbmcavoy