我们有一个企业管理软件，我们的客户将其部署到Windows网络共享文件夹中，来自多个终端服务器的几个用户从该文件夹启动我们的程序。
我们试图实现的是一种在用户使用程序来应用补丁来修复错误时替换DLL的方法。现在奇怪的是，我们能够重命名旧的DLL来替换和应用新的DLL，而不会出现任何关于所使用文件的错误。
这给我们带来了两个问题：
- 如果同一应用程序的实例仍在使用旧DLL，则应用程序不会加载新DLL(我认为这是https://en.wikipedia.org/wiki/DLL_Hell#Shared_in-memory_modules(
- 替换之前运行的应用程序会左右抛出异常，因为它们只被部分加载(延迟加载(，并且当需要在文件中查找所请求的丢失部分时，IL代码不再与内存中的内容匹配
我认为我们正在做一些不应该做的事情：重命名正在使用的东西。
到目前为止，我发现了两种可能的解决方案：
- 使用启用了卷影复制的新AppDomain启动应用程序，但这并不可靠，因为每个客户端都有自己的环境，我们可能会遇到意外的权限错误或类似的情况
- 加载程序集而不锁定它们。在这一点上，我们已经研究过使用反射(我们实际上在某种程度上使用了反射(，但我们不确定如何通过DLL已经在项目中引用的反射程序集加载(我们有多个DLL引用了引用其他DLL的其他DLL，等等(
你们中有人对如何安全地克服这个问题有其他想法吗？或者，如何通过反思来解决我上面提到的最后一点？
您可以尝试穷人版本的蓝色/绿色部署。
将您的应用程序文件部署到两个相同的文件夹
\SomeMachined$MyAppGreen
\SomeMachined$MyAppBlue
现在在根文件夹中放一个快捷方式，如下所示：
\SomeMachined$MyAppMyApp.lnk
从指向绿色文件夹中.exe的快捷方式开始。
告诉用户始终只使用快捷方式启动应用程序(而不是导航到绿色或蓝色文件夹并在那里启动(。
当需要更新DLL时，请遵循以下过程：
- 在Blue文件夹中进行修改
- 在Blue文件夹中执行任何需要的测试
- 一旦您确定它有效，请更新
MyApp.lnk快捷方式以指向Blue
在更新之前启动应用程序的用户将继续点击绿色文件夹，直到退出应用程序。任何重新启动应用程序的人都会点击Blue文件夹。
下次必须更新DLL时，请反向执行此过程。在Green文件夹中进行修改，然后更新快捷方式以指向Green。
这样，你总是更新一个没有人使用的文件夹，然后通过快捷方式使其可用。只要人们不时退出应用程序，您就应该能够无缝部署。
如果你不想使用.lnk文件(例如，你的客户端不在Windows上(，还有其他类似的方法可以通过映射驱动器号或使用符号链接来实现。但原则是不变的。