Using TransactedInstaller - do I still need to use Rollback?

Question

I've been using Topshelf for 3 years now, but only in simple use cases. I've started a new job and suggested using Topshelf but they override the Rollback method of the Installer class. For example they use it to call "http delete urlacl ...".

Topshelf doesn't expose BeforeRollback or AfterRollback. I'm not against submitting a pull request, but I want to know beforehand if I even need rollback functionality or not? Also possibly is there already a way of handling this using Topshelf?

Answer 1

So what I ended up doing was surfacing the BeforeRollback and AfterRollback events to Topshelf's public interface along side the other installer events that are exposed. I've submitted a pull request to the developers, but until they accept it you may find the source with my updates here: https://github.com/developmentalmadness/Topshelf

Answer 2

With all respect to TopShelf, they might have a good pattern for creating services ( I don't know, I've never used them ) but if they are still using custom actions in their deployment then they still have missed the boat with how Windows Installer is designed to work. I don't fault them because there is much out there written on the subject that is suboptimal from an MSI perspective.

I first wrote about this 6 years ago:

MSI vs .NET

The problem started with Visual Studio Deployment Projects which didn't expose the underlying native capabilities of MSI. Instead the created Installer Class custom actions which encourages reinventing the wheel with more fragile solution. MSI isn't about injecting out of process imperative code, it's about declarative programming.

A cleaner way to handling a service can be found here at:

Augmenting InstallShield using Windows Installer XML - Windows Services

The concept is to encapsulate the service as a merge module and add to InstallShield. It could also be added to a Visual Studio Deployment Project or it could be refactored to be pure WiX.

Same goes for netsh commands. You shouldn't have to have all this custom code and try to get all the servicing strategies correct. Instead use the built in FirewallException Element (Firewall Extension) of WiX ( again can be encapsulated and used with other tools ) and let it do the hard work for you.

If this seems interesting but unachievable, just hit me up and I'll show you. Until someone bothers to rewrite the books, I just have to convince one developer at a time.