AppDomain隔离问题

Question

我设计了一个后端，将业务逻辑放在运行时加载的dll中。使用ShadowCopyFiles = true和文件系统监视，我能够在不重新启动主机进程的情况下修改业务逻辑。

到目前为止一切顺利..。

让我们将主机命名为appdomain A，并将其中一个子项称为B。

不幸的是，如果我在B引用而不是A引用的程序集C中进行更改，这些更改在重新加载B时不会反映出来。我认为这是因为A本身加载了C。我必须采取什么步骤来防止A加载C？

这是A用来加载B的代码：

        AppDomainSetup appDomainSetup = new AppDomainSetup();
        appDomainSetup.CachePath = ServiceDLLPath + @"\Shadow";
        appDomainSetup.ShadowCopyFiles = "true";

        ad = AppDomain.CreateDomain(assemblyName, null, appDomainSetup);
        ad.InitializeLifetimeService();
        try
        {
            service = (IService)ad.CreateInstanceFromAndUnwrap(assemblyName, 
                                  "AppName.Services." + typeName);
            service.Start();
        }
        catch (Exception e)
        {
            LogManager.Log("AppDomain load failed: " + e.Message);
            return false;
        }

Answer 1

如果A引用C，并且A是“主机”，则在不停止并重新启动进程的情况下，您无法重新加载C。

一种可能性是创建一个极薄的填充AppDomain来引导A AppDomain (并可以重新启动它)，但重新评估该进程可能具有相同的性能配置文件。

另一种(看起来更明智的)方法是让A及其依赖项独立于C使用的依赖项，对于重叠的程序集来说，只需使它们足够稳定，您就不需要经常更改它们。

Answer 2

我通过创建一个“接口”程序集解决了这个问题。

因此，如果这个程序集被称为X，那么链现在是：

A -> X <- B -> C

(原文:A -> B -> C)

我现在可以在B或C中进行更改，这些更改在appDomain B被A销毁并重新启动时得到反映。

根据Tim的要求，编辑，了解更多细节。

appdomain A中的代码没有更改，您可以在我的问题中看到它。唯一需要注意的是IService类型定义的位置：

 service = (IService)ad.CreateInstanceFromAndUnwrap(assemblyName, 
                              "AppName.Services." + typeName);

一旦IService被移到一个专门构建的程序集上，我就能够删除B和A中的引用，这些引用以某种方式最终将A连接到C。基本上，克里斯所说的一切都是正确的，只是路径并不总是很清楚。

Answer 3

阅读答案和评论，听起来您最好将业务逻辑包装到WCF服务中。您可以使用网络管道来最小化在同一台pc上运行的开销。您还应该考虑使用MEF来构建应用程序的可扩展性。不幸的是，MEF也没有设计成允许您在不重新启动主机应用程序的情况下动态卸载和替换插件