Hi,

I have a setup project which is a mix of old COM dlls and .Net applications. We (now) have the main setup project in Visual studio 2005 and it includes a mix of .Net & Com applications rolled into merge modules.

In amongst all this I have one merge module that consists of a single out of process ActiveX exe. Originally it was in a merge module built with the old visual installer using visual interdev. The registry keys for registration had been hard coded.as that software could not self register an activex exe. This merge module was simply included in my package.

This was all working fine and dandy until we started testing on Vista & Vista 64 bit. I can't remember the exact problem we had but I think it was around 64 bit needing to put the reg keys into a specific place for 32 bit apps which wasn't happening because they were hard coded.

So I decided to create a new merge module using VS2005 with the single exe (plus dependencies) inside and set it to vsdrfCOM on the assumption that this would then sort the problem out.

However I have discovered that on Vista (and possibly xp as well - I haven't tested that yet) it doesn't appear to create all of the required registry entries although it does create some. Running it with the /regserver flag cures the problem and a compare of the registry before and after shows some additional registry entries have been created.

So, my question is, can I use vsdrfCOMSelfReg instead and what are the implications of this? Does it work for an activex exe, and will the registration entries be removed when uninstalling? Is VS2008 any better at this as I have the option to build the merge module using that?

I also read somewhere that there are problems if you try and do this from a merge module - does anyone know if this is the case?

Finally does anyone know of any "best practice" for handling activex exe registration in a VS2005 package - one that will work across XP/XP64/Vista/Vista64 ??

Sorry for the long post!
Regards,
LJ

I've not noticed that before - maybe it's new. Visual Studio builds a custom action to run with the /REGSERVER command line (/unregserver at uninstall time) , so yes, that works.

What's missing when you do vsdrfCOM (on a Dll/Ocx)? I believe it watches the registry and collects all the registration data and puts it in the MSI file. That needs the registration code to run at build time, and it might be that missing dependencies don't get reported.

I don't believe vsdrfSelfReg works for exes - it's basically tells the MSI install to call DllRegisterServer when it installs a Dll/Ocx. So running the exe is what you do. The alternative would be to get the registry entries into the registry view of the IDE, manually or with a .reg file.

I don't know of problems with custom actions in merge modules, except that you probably can't order them if they require running before or after custom actions in other merge modules or MSI setups.

Hi Phil,

Thanks for replying. I've had chance to try vsdrfSelfReg and it does indeed work for an activex exe if you do it directly from the main setup package. Obviously it does /regserver on the executable rather than a regsvr32.

However there appears to be a bug when you try to do it from a merge module. It seems that visual studio creates the actions to self register the exe, but puts them in the wrong table in the msi (InstallExecuteSequence instead of ModuleInstallExecuteSequence).

In the end as it's a single exe I have included it as part of the main setup rather than it being in its own merge module. Although I'm not 100% happy with this it appears to work.

I'm still a bit unsure why using vsdrfCom doesn't include all the necessary registration information and would be interested to know if anyone knew why or had any recommendations?

Cheers,
LJ.

I've not noticed that before - maybe it's new. Visual Studio builds a custom action to run with the /REGSERVER command line (/unregserver at uninstall time) , so yes, that works.

What's missing when you do vsdrfCOM (on a Dll/Ocx)? I believe it watches the registry and collects all the registration data and puts it in the MSI file. That needs the registration code to run at build time, and it might be that missing dependencies don't get reported.