Installer classes dependent on assemblies in the GAC

[Andy Elmhorst]

We have been using .Net installer classes successfully to handle a large
number of installation tasks for our server applications.

Now we are starting to migrate some of our shared assemblies into the GAC.
Some of our installer classes are dependent upon these shared assemblies.
It appears that Windows Installer does not install our assemblies into the
GAC before it calls the install methods on our custom actions, which
causes our installation to fail.

Does anyone know of a way to get Windows Installer to finish registering
the shared assemblies in the GAC before calling our Installer classes?
This seems like it would be a common problem for anyone using Installer
classes.

We could install the assemblies into the GAC manually, earlier on in the
installation process by using GACUTIL, but then we loose the reference
counting that Windows Installer automatically handles for us in the GAC.

Regards,

Andy Elmhorst

(Sorry for the cross-posting, but no one seems to be answering these types
of questions on Microsoft.public.windows.msi) I inadvertantly also posted
this on the sdk_install list by accident.

[Phil Wilson]

I've noticed the same issue. I've also seen it without installer classes - actions like
StartServices fail if they require assemblies to be in the GAC. There seems no detour to that except
to not start the services with StartServices but add a custom action script after InstallFinalize to
start services. I played with moving MsiPublishAssemblies around in the sequence but to no avail.
Losing the reference counting and kludging a fix with a gacutil custom action (after first copying
the assembly to the system) is what people are doing. Note that Gacutil itself is not in the base
1.0 framework, but it showed up in SP2; It's not in the 1.1 redist framework, but it is on Server
2003, so finding it can be awkward. I don't know whether it's officially redistributable
--
Phil Wilson [MVP Windows Installer]

"Andy Elmhorst" <andye...@yahoo.com> wrote in message
news:eE4ZbJzD...@TK2MSFTNGP10.phx.gbl...

[Andy Elmhorst]

Thanks for the reply . . .

I am hoping I don't have to go the GACUTIL route. So far my current strategy
seems to be working.

We install all dlls with custom actions in a shared folder under
CommonFiles\OurCompanyName. We also deploy a copy of the dlls that they are
dependent on into that folder, even though they will eventually be also
deployed in the GAC. The custom actions then run fine. Because of this, we
tend to create seperate assemblies to run our custom actions, rather than
putting the installer classes directly into our application.

For .Net services, the ServiceInstaller and ServiceProcessInstaller classes
have been doing the job well for us.

Regards,

Andy

"Phil Wilson" <phil....@unisys.spamcom> wrote in message
news:e8bKnN1D...@TK2MSFTNGP12.phx.gbl...