ender_shadow
6th June 2010 15:59 UTC

COM DLL registration
Dear NSIS gods...

I am relatively new to NSIS, but have managed (with the help of the great wiki) build a decent installation of the product I am responsible for.

However, I encountered a strange problem, I am relatively sure that it's only on Windows Vista and Windows 7.. The problem deals with the registration of a COM DLL.

Part of the product I am responsible for includes a COM DLL which has to be registered as part of the installation. I use the internal NSIS command RegDLL (If memory serves) to register the DLL. However, on Windows 7, only for the first time you install the software, this fails... I have a workaround solution for this, so when you run the software it checks if the component is registered, and if not, registers it itself, however, I would prefer a solution through the install.

During my digging around I stumbled upon the following text:

"Note that DLLs & OCXs sometimes fail to register automatically at install time because they depend on a newer version of some runtime library (msvcrt.dll and msvcp60.dll being common culprits). These can't yet be upgraded because it's being used by the installer itself, so registration will fail and if it's not storing the result to DllRegisterServer (or just shelling to regsvr32 /s) you won't notice until you launch the app."

This is from: http://www.fredshack.com/docs/nsis.html

Now, I assume that this is a known issue with NSIS, the question is, does anyone have a good solution to this as part of NSIS itself? or is my solution the best that currently be achieved?

Many thanks

AP

Anders
6th June 2010 16:50 UTC

NSIS and the official plugins do not depend on any runtime dll's (Except the native windows api dll's of course) (Are you using 3rd party plugins?)

Run http://www.dependencywalker.com/ on the dll you want to register (on a clean system) and see if there are any missing dependency's. You could also try to register the dll manually; run cmd.exe, run regsvr32 c:\path\your.dll

And just to make sure, we are talking x86 and not x64 Win7?

ender_shadow
6th June 2010 16:57 UTC

Hi Anders,

Thanks for the really quick reply...

I'll start from the end :) yes, you are correct, it's an x86 (i.e. 32 bit) machine.

Registering the DLL manually works fine each time (as I stated, that's my workaround), which makes it seems strange that it's some dependancy that I'm missing... also, since this does not happen on an XP machine, it doesn't seem like that's the case...

I am using 3rd party plugins, but nothing that's related to registering a COM DLL... if you'll note the quote I gave, it specifically states the situation I am facing... so, from your reply, I assume that you never encountered this situation...

Some more information about my install - I also deploy (and install) the VC++ redistributable... could this by the root cause of the problem?

Anders
6th June 2010 21:53 UTC

You could try running Process Monitor during the install... (Might want to add MessageBox before and after you register the dll in your .nsi so you can start/stop monitoring with minimal useless output)

ender_shadow
7th June 2010 06:56 UTC

Hi Anders,

Just to make sure, what you're saying is that because the VC++ redistributable is still running, that's what is screwing up my COM registration? If so, that's an interesting direction, which I haven't considered, but since they are both in two separate sections wouldn't that protect me?

Also, the section that registers the COM dll is done before the VC++ redist... might that be the cause?

Many thanks again.

Anders
7th June 2010 07:28 UTC

I don't know what the problem is, but it would be helpful to know if loading a dll is the problem, or something else

ender_shadow
8th June 2010 07:52 UTC

Hi Anders, thank you for your advice, I will try and see how it pans out.