Using GAC Assemblies during install and Rollback Implications

[sgoldstein]

The documentation for the MSAssembly table states:

"The assemblies are not committed until successful execution of the InstallFinalize Action. This means that if you author a custom action or resource that relies on the assembly, it must be sequenced after the InstallFinalize Action. For example, if you need to start a service that depends on an assembly in the Global Assembly Cache (GAC), you must schedule the starting of that service after the InstallFinalize Action. This means you cannot use the ServiceControl Table to start the service, instead you must use a custom action that is sequenced after InstallFinalize."

However, if I were to schedule custom actions after InstallFinalize, it means there is no way for me to rollback any of those actions if one of them were to fail.

Is there an easy solution here or do I have to manufacture my own rollback mechanism?

Thanks.

Scott

[Ron_Schaeffer]

If the install is complete and successful all the way through the InstallFinalize action, why not just ignore any errors thrown by subsequent CAs?

Now before you flame me, I am thinking specifically about starting a service (because I am in the middle of trying to deal with that myself). If the only issue is that there is an error return when starting the service which has just been installed, I am ignoring the error and letting the install complete. Why? Because if I uninstall (rollback) there is nothing left for me to debug what the issue is. Plus, I don't expect that this would be a common scenario anyway.

My two cents.

[sgoldstein]

The problem here is that the installation is not complete. Here is the sequence:

1. Complete everything up unti InstallFinalize
2. Install Assemblies into GAC
3. Run all installation custom actions that rely on the assemblies

The items in #3 are required to complete the installation. If they fail, the installation fails. However, they can't be run before InstallFinalize because they require the assemblies. So, there is no way to rollback if these fail

[Reureu]

Hi,

I faced a similar situation when I wanted to perform a custom action using some .NET assemblies whose destination was the global assembly cache.

Just as a suggestion, would it help to add the few files you need for your custom action in the DuplicateFile table, and specify another destination folder in the DestFolder column (anywhere but the GAC)?

This would allow to have the files available after the "DuplicateFiles" action, so that you can run your custom actions that rely on these files before InstallFinalize.

Is it worth a try?

One downside of this approach is to use more disk space as some files are duplicated, but this is no longer a problem on modern PC's.

Regards

[joshstechnij]

In addition to the other suggestions, you may also try using a commit custom action. This type of action runs when the installation is being commited to the machine and should run after GAC assemblies are available. Because commit actions are part of the installation transaction, they are also able to roll back the installation if an error occurs and run in system context if elevated privileges are required.

[Tim_Mayert]

Okay have any of you found a solution that you are happy with?

We are working with a bunch of sxs assemblies and we have some services that need to be registered and started that rely on these assembiles. So what is the best option to go with?

If you trigger these custom actions after InstallFinalize does these custom actions still have the correct elevation to register and start the service. Our Service is does not use the built in Services table and therefore has to run the install/registration through custom actions.

Also where after InstallFinalize are the assemblies actually registered so that we know when to trigger the custom actions, if we go that route?

[Ron_Schaeffer]

We have a similar circumstance, in that we deliver some assemblies to the GAC and also want to start our service which depends on them.

Going by memory - in regards GAC delivery - I believe we had one InstallExecute sequence revision, making RemovingExistingProducts the very last CA in the sequence (after InstallFinalize, after ISXmlFinalize).

In regards starting a service which is dependent on your own delivered GAC assemblies - we wrote an InstallScript CA to start the service and placed it immediately after StartServices in the sequence: condition: Not Installed; Return Processing: Synchronous (ignores exit code); In-script Execution: Commit Execution in System Context. We also configured the service in the normal manner (i.e., stop & delete on uninstall), except we didn't try to start it.

Hope this helps.