我已经使用 Topshelf 3 年了,但仅限于简单的用例。我开始了一项新工作并建议使用 Topshelf,但它们覆盖了 Installer 类的 Rollback 方法。例如他们用它来调用“http delete urlacl ...”。
Topshelf 不公开 BeforeRollback 或 AfterRollback。我不反对提交拉取请求,但我想事先知道我是否需要回滚功能?也可能已经有一种方法可以使用 Topshelf 来处理这个问题?
我已经使用 Topshelf 3 年了,但仅限于简单的用例。我开始了一项新工作并建议使用 Topshelf,但它们覆盖了 Installer 类的 Rollback 方法。例如他们用它来调用“http delete urlacl ...”。
Topshelf 不公开 BeforeRollback 或 AfterRollback。我不反对提交拉取请求,但我想事先知道我是否需要回滚功能?也可能已经有一种方法可以使用 Topshelf 来处理这个问题?
就 TopShelf 而言,他们可能有一个很好的模式来创建服务(我不知道,我从来没有使用过它们)但是如果他们仍然在他们的部署中使用自定义操作,那么他们仍然错过了如何使用 Windows安装程序旨在工作。我不会责怪他们,因为从 MSI 的角度来看,关于这个主题的文章很多都是次优的。
6年前我第一次写到这个:
问题始于 Visual Studio 部署项目,它没有公开 MSI 的底层本机功能。相反,创建的安装程序类自定义操作鼓励使用更脆弱的解决方案重新发明轮子。MSI 不是关于注入进程命令式代码,而是关于声明式编程。
可以在此处找到处理服务的更简洁的方法:
使用 Windows Installer XML 增强 InstallShield - Windows 服务
其概念是将服务封装为合并模块并添加到 InstallShield。它也可以添加到 Visual Studio 部署项目中,或者可以重构为纯 WiX。
netsh 命令也是如此。您不必拥有所有这些自定义代码并尝试使所有服务策略正确。而是使用 WiX 内置的FirewallException Element(防火墙扩展)(同样可以封装并与其他工具一起使用),让它为您完成艰苦的工作。
如果这看起来很有趣但无法实现,请联系我,我会告诉你。在有人费心重写这些书之前,我只需要一次说服一位开发人员。
所以我最终所做的是将 BeforeRollback 和 AfterRollback 事件与暴露的其他安装程序事件一起显示到 Topshelf 的公共界面。我已经向开发人员提交了一个拉取请求,但在他们接受之前,您可以在此处找到我的更新源:https ://github.com/developmentalmadness/Topshelf