Option 1 may be the best. All of that "install/upgrade/uninstall stuff" you listed on that line is good stuff and difficult to do well.
I think Option 2 won't work because your CustomAction will not be elevated after InstallFinalize and thus will not be able to make the COM+ configuration then. (thank you Fusion for a faulty GAC design, I don't care much for Fusion as you might guess). Option 3 has the issues you list. Option 4 would require that tool to elevate... multiple elevations annoy users... ideal to avoid it. Personally, I'd probably go with Option 1. Don Benson wrote: >> Windows Installer does not commit files to the GAC until >> InstallFinalize >> (the end of the transaction). This prevents GAC assemblies from being >> used or even referenced really during the installation transaction. I >> think this design limitation is the root of your issue. >> > > So, now I know the problem. The next question is, what is a recommended > solution to the problem? Is there a best practice? > > I tried scheduling the ComPlusInstallExecute custom action after > InstallFinalize, but this generates an ICE77 validation error because the > action is an in-script action and must be between InstallInitialize and > InstallFinalize. Then I tried scheduling ComPlusInstallPrepare after > InstallFinalize. This compiled, but then errored off during the installation > with the same message about where it is allowed to be scheduled. > > How do I get the COM Plus registration to occur after the InstallFinalize? > > The documentation for the ComPlusAssembly element implies that setting the > RegisterInCommit attribute to "yes" should schedule the assembly to be > registered after the InstallFinalize action. I have that attribute set, but > the registration is definitely getting scheduled before InstallFinalize. Is > this a bug in the latest build of the ComPlus extension? > > As I see it, I have several options with current version... > > Option 1: > Include the .NET DLL in the GAC and in a folder, which requires separate > components for the file. I've seen threads about deploying .Net assemblies to > both places. The ComPlus configuration can reference the DLL component that > installs to a folder. If there is an error during the COM+ registration, the > entire installation will be rolled back. Upgrades and removals are handles > automatically through the built-in functionality. > > Option 2: > Do not reference the .NET assembly in a ComPlusAssembly element. Create my > own custom action to register the .NET assembly into the existing COM+ App. > The custom action will be scheduled after InstallFinalize. If this custom > action fails, the app will still be installed, but non-functional. I will > also have to also deal with upgrades and removals. > > Option 3: > Package the COM+ application separately using the export option from the > COMAdminCatalog API. The package would have to be built into a bootstrapper > that installs the rest of our server-based utilities. This creates another > entry in Add/Remove programs just for the COM+ application. > > Option 4: > Manage the COM+ application with all custom code. The server includes a > "heartbeat" service. We could add functionality to the heartbeat service to > validate that the COM+ configuration is correct and try to fix it. Upgrades > and removals are still a complication. > > Option 1 seems to be the simplest choice for now, and I do have some time > pressure to get the installation working soon. I would appreciate any other > ideas or thoughts on my options. > > Sincerely, > - Don Benson - > > CONFIDENTIALITY NOTICE: This email and any files transmitted with it are the > property of Tribute Inc. and/or its affiliates. The contents of this > communication are confidential and may contain information that is privileged > and/or exempt from disclosure under applicable law. It is intended solely for > use of the individual or entity to whom this email is addressed. If you are > not one of the named recipient(s) or otherwise have reason to believe that > you have received this message in error, please notify the sender and > immediately delete this message and any attachments. Any unauthorized use, > retention, dissemination, forwarding, printing, or copying of this email is > strictly prohibited. > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
