应用更新而不重新启动应用程序
本文关键字：重新启动 应用程序 更新 应用 | 更新日期: 2023-09-27 18:06:14
最近我参加了一个。net职位的面试。在被问到的问题中，有一个问题我真的很难回答。我希望有人能在这方面帮助我。
场景(问题):应用程序的第一个版本(可能是winform/wpf UI应用程序)已经发布给客户端，他们开始使用该应用程序。但不幸的是，QA团队后来在当前版本中发现了一个严重的问题。现在的挑战是，我们应该能够发送和应用补丁(修复)，而不强制应用程序重新启动。假设应用程序是实时应用程序，不能重新启动以应用补丁。
就我个人而言，我很难给出一个令人信服的答案，而这个答案在应用补丁时不会影响应用程序的运行。
答:
感谢您迄今为止所做的贡献。我已经设法找到了解决这个问题的办法。不确定这是不是面试官问的问题。尽管如此，我还是很高兴看到了微软的ClickOnce，它几乎满足了我的需求。
对于当前运行的可执行文件，您几乎卡住了-您无法明智地修改内存中运行的进程。
然而，从dll加载的东西要灵活得多。程序集可以在运行时动态加载，并且可以在单个应用程序中启动多个appdomain。一个解决方案可能是这样的:
- 你的可执行文件是一个薄包装器，通过DLL传递所有功能
- 您的DLL功能通过一个单独的AppDomain加载并运行。
- 当需要一个补丁时，新的DLL被复制到(与现有的并行)
- 自动或响应用户交互，在现有的AppDomain旁边启动一个新的AppDomain，运行新的补丁
- 在应用程序的适当点(例如，全屏切换或定时刷新)，新的AppDomain成为"活"的一个
- 旧的AppDomain被关闭并丢弃
然而，这是非常高级的。在现实情况下，你很可能会有一个带有缓存、实时数据和许多其他考虑因素的多层应用程序。例如，可能有必要将应用程序的前端逻辑与缓存或数据处理部分分开，这样任何一部分都可以在不干扰其余部分的情况下切换出来。
某些不常见的技术可能在这里有用，这取决于确切的需求。高级缓存允许交换数据层，而前端不会失去显示数据的能力。命令队列或可靠的消息传递机制可以允许UI在业务层被换出时保持响应，然后新的业务层可以处理队列。如果你假设一个(逻辑上)基于服务器的应用程序，那么每个层的冗余可以允许一个冗余的"服务器"更新，而另一个服务器继续处理…等。
如果你从一开始就有这个需求，你可以把你的应用分成两个不同的应用——UI部分，以及在单个原子函数调用中完成所有工作的服务。最有可能的是，你的错误在服务中，所以你可以随时替换该应用程序，而不会破坏用户体验。
首先，你需要知道这个应用程序是否依赖于配置文件，如xml, ini或任何形式的基于文本的文件。如果是这样，可以将补丁作为配置插入，只要它们在当前进程范围之外可编辑。
如果第一个解决方案不可行，那么第二个解决方案是找出正在运行的应用程序是否有一个可靠的dll，以及通过参考dll注入补丁作为依赖是否会暂时解决问题，直到调用重新启动。
将旧文件重命名为其他文件(如在文件名中添加" old ")，并在其位置复制新的可执行文件，相同的文件名。下次运行时，新的可执行文件将运行。