harriyott.com

Thursday, December 01, 2005

Installer setup project not registering COM DLLs

I'm current using Visual Studio 2005 beta to create an installer which contains both .NET assemblies and a Delphi COM DLL. Reading the documentation, the DLL can be registered during installation by setting its Register property to vsdrfCOM. Unfortunately, when building the installer, the following warning appears:

Unable to create registration information for file named 'Component.dll'

(As an aside, this should really be an error, as the component isn't registered when the installer runs.) I did what everyone does with an error message, and pasted it into the Google. There were only a few results, some of which were duplicates, and none of which were helpful.

So I did what everyone else does, and randomly tried the other settings: vsdrfCOMSelfReg caused the warning to disappear, but caused errors when the installer ran. So I set it back to vsdrfDoNotRegister, which (clearly) didn't register the DLL after installing it.

So, back to basics. I checked that the DLL would actually register with regsvr32, and it did. The next logical step would be to write a batch file to run regsvr32 on the component as a custom action in the installer. Upon adding a custom action, I found that the only actions that can be added are .exe, .dll, .vbs and .js files. VBScript seemed the easiest, so I wrote a script that called regsvr32 through a shell object:

Dim WshShell
Set WshShell = CreateObject("Wscript.Shell")
WshShell.run "regsvr32 /s Component.dll"
Set WshShell = nothing

and added this to the Install section of the of the custom actions. I did the reverse (using the /u regsvr32 flag) and added this to the Uninstall section. This works, but the .vbs files are deployed with the application. It's a bit messy, but it's the first thing that works. Ideally, Visual Studio would understand the DLL, and maybe it does it the RTM version.

13 Comments:

Anonymous Len Holgate said...

Simon

Does your dll include the "OleSelfRegister" string in its version info? (see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/fb5dcb2b-b0e3-4f37-a8e7-b84b9a265227.asp). If not then it may just be that the installer is playing by the rules ;)

December 01, 2005 4:09 PM  
Blogger Simon said...

Thanks Len,

No it doesn't, and unfortunately I don't have the option of changing it.

December 01, 2005 4:51 PM  
Anonymous Len Holgate said...

Why not? It's just a resource, extract it, update it, put it back... (he says, having only done the first two steps himself ;) )

This implies it can be done though... http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/introductiontoresources/resourcereference/resourcefunctions/updateresource.asp

December 01, 2005 10:32 PM  
Blogger Simon said...

Thanks, that's an interesting link.
It seems that techically there's no reason why not, so I might try it out just to see. I can't use it as a permanent solution though, for a couple of reasons. The DLL is used in other products that I'm not involved with. I don't have access to the relevant source control database, so I couldn't change the source (and I don't have Delphi). The component will be replaced with a .NET assembly in the near future, so it's only a temporary measure.

Thanks for looking up the link for me though.

December 02, 2005 12:35 AM  
Blogger Simon said...

Gaah, I'm going to have to sort out my CSS. The long URLs are playing havoc!

December 02, 2005 12:40 AM  
Anonymous Len Holgate said...

It wasn't much effort to look up the links they were the top answers on google for whatever I typed as the question; now, if I could remember that bit...

It would be interesting to see if you created a simple ATL COM object with and without the OleSelfRegister thing if one worked and one didn't; at least then you'd know...

I'd know too ;)

December 02, 2005 11:26 PM  
Anonymous Kim said...

Hey Simon,

Thanks a lot for your post, it was a great help! Just thought I'd add some minor changes I made to it in order to specify the location of the DLL without having to hardcode it, in case there are any other VBScript newbies (like me) out there who might want to do the same.

The following gets the "Program Files" directory and uses that to figure out the path to the DLL being installed:
-------------
Set WshProEnv = WshShell.Environment("PROCESS")

strProgramFiles = WshProEnv("ProgramFiles")

strCommand = "regsvr32 /s """ & strProgramFiles & "\CompanyName\Component.dll"""

WshShell.run strCommand
-------------

The rest of the script is the same.

February 27, 2006 3:40 AM  
Anonymous Simon said...

Hi Kim,

Thanks for that - a useful tip.

February 27, 2006 8:22 AM  
Blogger jm0rd3tsky said...

Just came across this and wanted to say thanks for posting. Has had me stuck for a little while now.

I wish there was a better way, but I can't mod my dll either.

August 16, 2006 6:13 PM  
Blogger Simon said...

Hey Joe, glad it was useful. That's why I posted it - so someone might stumble upon it.

August 17, 2006 8:51 AM  
Blogger [/j03m] said...

I once again find myself back here (jmordetsky).

Thanks again for posting.

October 11, 2007 10:38 PM  
Blogger Sam said...

I tried the .vbs above, but I get an error when it runs and it rolls back the installation. Is the .vbs file supposed to return some sort of return value that would avoid this?

Thanks,

SB

March 26, 2008 1:18 PM  
Anonymous Simon said...

Hi Sam,

I didn't originally put in a return value, but try it and see. Does the regsvr32 command work for your DLL outside of the VBS?

March 26, 2008 1:33 PM  

Post a Comment

Links to this post:

Create a Link

<< Home