应用更新而不重新启动应用程序

Question

最近我接受了.NET职位的采访。出于问题，我在回答一个问题时遇到了麻烦。我希望有人能帮助我。

场景（问题）：应用程序的第一个版本（可能是winform / wpf UI应用程序）已经发布到客户端，他们开始使用该应用程序。但不幸的是，QA团队后来在当前版本中发现了一个严重的问题。现在的挑战是，我们应该能够发送和应用补丁（修复）而不强制应用程序重新启动。假设应用程序是一个实时应用程序，无法重新启动以应用补丁程序。

就个人而言，我在给出一个令人信服的答案时遇到了麻烦，这个答案在应用补丁时不会影响正在运行的应用程序。

答案：

感谢所有贡献到目前为止。我已经设法为这个问题找到了解决方案。不确定这是否是面试官的要求。尽管如此，我很高兴看到微软的ClickOnce，这几乎可以实现我想要的......

Answer 1

对于当前运行的可执行文件，您几乎陷入困境 - 您无法明智地修改在内存中运行的进程。

但是，从DLL加载的东西要灵活得多。程序集可以在运行时动态加载，并且可以在单个应用程序中启动多个AppDomain。一种解决方案可能是这样的：

• 您的可执行文件是一个将所有功能传递给DLL的瘦包装器
• 您的DLL功能已加载并通过单独的AppDomain运行
• 当需要补丁时，新的DLL被复制（与现有的DLL并排）
• 自动或响应用户交互，新的AppDomain与现有AppDomain一起启动，运行新补丁
• 在应用程序中的适当位置（例如，全屏切换或定时刷新），新的AppDomain成为“实时”的
• 旧的AppDomain已关闭并被丢弃

然而，这是非常高级的。在现实情况下，您很可能会拥有一个包含缓存和实时数据以及许多其他注意事项的多层应用程序。例如，可能有必要将应用程序的前端逻辑与缓存或数据处理部分分开，以便可以在不干扰其余部分的情况下切换任何一个部分。

根据具体要求，某些不常见的技术可能在这里很有用。高级缓存可以允许交换数据层，而前端不会丢失显示数据的能力。命令队列或可靠的消息传递机制可以允许UI在业务层被换出时保持响应，然后新的业务层可以处理队列。如果您假设一个（逻辑上）基于服务器的应用程序，那么每个层的冗余可以允许更新层的一个冗余“服务器”，而另一个服务器继续处理...等等。

Answer 2

如果从一开始就有这个要求，你可以将你的应用程序分成两个不同的应用程序 - UI部分，以及在单个原子函数调用中完成所有工作的服务。最有可能的是，您的错误在服务中，因此您可以随时替换该应用程序，而不会中断用户体验。

Answer 3

首先，您需要知道此应用程序是否依赖于配置文件，例如xml，ini或任何形式的基于文本的文件。如果是这样，补丁可以作为配置插入，只要它们可以在当前进程的范围之外编辑。

如果第一个解决方案不可行，那么第二个解决方案是确定正在运行的应用程序是否具有可靠的dll以及是否通过引用dll注入补丁作为依赖关系将暂时解决问题直到重新启动被调用。

Answer 4

将旧文件重命名为其他内容（例如将“旧”添加到文件名中），然后在新的可执行文件中复制相同的文件名。下次运行时，新的可执行文件将运行。