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