智能软件安装程序 - 在上次失败时恢复
有没有人在 .Net 中编写过自己的软件安装程序，并且具有“在最后一次失败时恢复”的功能？
例如，假设安装复制了一堆文件，注册了一些 DLL，设置/操作数据库 (MS SQL)，并设置使用所述数据库的数据驱动网站 (IIS)。
如果数据库操作部分失败，请退出安装程序，解决问题，然后重新运行 - 只是这次安装程序会跳过文件复制和 DLL 注册，并继续进行数据库工作。
我当然可以编写自己的 XML 日志文件，安装程序可以找到并驱动该过程，但我不是重新发明轮子，而是想知道是否存在既定的模式和模式。实践或行业标准方法来做到这一点？
我在网上搜索了“软件安装简历”，当然，我得到了各种简历写作技巧。是否有人可以建议更多主题准确的关键字？
谢谢你， 蒂姆D
Has anyone out there ever written your own software installer in .Net that has a "pickup at last failure" ability baked in?
e.g. Let's say the install copies a bunch of files, registers some DLLs, sets up/manipulates a database (MS SQL), and sets up a data driven web site (IIS) that uses said database.
If the database manipulation part fails, exit the install program, fix the issue, then rerun - only this time the installer skips over the file copying and DLL registration, and picks up with the database work.
I could certainly write my own XML log file that the installer can find and drive the process, but rather than reinvent the wheel, I'm wondering if there is an established pattern & practice, or industry standard way to do this?
I searched the web for "software install resume" and, of course, I'm getting all kinds of résumé writing tips. Are there more topically-accurate keywords that anyone can suggest?
Thank you,
TimD
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不知道您想要此功能的情况或理由，但这听起来不是最好的主意。从管理的角度来看，我真的很喜欢安装程序以原子方式运行 - 它们要么成功，要么失败，并撤消对系统所做的任何更改。
这样，当我重新运行安装程序时，我不必担心以前的组件被“遗留”并导致问题。在理想的情况下，我也不想被提示诸如覆盖现有文件之类的事情，因为我不知道应用程序应该使用某些第三方 DLL 的哪个版本。
因此，对于设置或操作 SQL Server 数据库之类的操作，我希望数据库语句在事务中执行，然后可以回滚。根据更改的程度，进行数据库备份可能是明智的做法，但您可能不必将其烘焙到应用程序中。我喜欢 Red Gate 工具在其数据同步过程中内置的备份步骤，这样既可以保证我的安全，又可以使过程保持简单和简化。
这是我的推理。如果我运行安装并将其命名为“MySite”，它会创建一个名为 MySite 的数据库和 IIS 虚拟目录，并且安装失败，根据您的推理，DB 和 IIS 目录将被保留。现在，如果我是管理员，我不想假设您的安装程序会干净地处理现有部分，因此我进行下一次安装 MySite2，然后进入并尝试手动清除 MySite 的部分。
I don't know your case or reasoning for wanting this feature, but it doesn't sound like the best idea. From an administrative standpoint, I really like it when installers function atomically - they either succeed or fail and undo any changes that they've made to the system.
That way when I re-run the installer, I don't have to worry about previous components being "left behind" and causing issues. In an ideal world, I also don't want to be prompted for things like overwriting existing files, because I don't know what version of some third-party DLL should be used for the application.
So for something like setting up or manipulating a SQL Server database, I'd want the database statements to execute within a transaction that could then be rolled back. It'd probably be smart to take a database backup, depending on the extent of the changes, but you might not have to bake that into the application. I like how Red Gate tools have a step for taking a backup built into their data synchronization process, so it keeps me safe and still keeps the process simple and streamlined.
Here's my reasoning. If I run an install and call it "MySite," and it makes a database and IIS virtual directory called MySite, and that install fails, under your reasoning, the DB and IIS directory are going to be left hanging around. Now if I'm an admin, I don't want to assume that your installer will cleanly deal with the existing pieces, so I make the next install MySite2, and go in and try to manually clear out the pieces of MySite.