Question

如果我即将发表的解释没有足够的意义，我现在道歉。我为此而闻名，尽管我试着这样做。

我正在编写一个使用用户定义插件的服务。我正在尝试隔离它们 - 通过使用共享程序集中定义的接口将它们的程序集保留在服务的appdomain之外。

让我感到害怕的是使用抽象基类。有些功能对于某些接口的所有实现都是通用的，因此抽象基类是有意义的。如果抽象基础在服务程序集中，那么子类化的任何插件都会将其程序集拖入服务的appdomain。但是，在服务使用的抽象基础（具有内部setter和公共getter的属性）中有内部成员，因此它需要与服务在同一个程序集中才能实现。

似乎我想要的是不可能的，但我也相信这是因为我采取了错误的做法。我正拼命想在这个练习中更好地利用好的模式和实践，并一路学习。

Answer 1

你可能想要的是一个带有抽象基类的接口，它实现了接口，派生类可以继承。在这种情况下，您可以使用接口维护您的分离，但仍然提供实现的抽象基类。这也具有抽象基类是可选的优点。

Answer 2

如果您要避免的问题是将插件程序集泄漏到服务AppDomain中，那么无论您是否有内部成员，都不会遇到此问题。您只需要在插件域内提供服务程序集（而不是相反），您可能必须在服务程序集中定义共享类型而不是单独的程序集（如果确实需要“内部”）另一个集会）。

想象一下，您在ServiceLib.dll中定义了抽象基类PluginBase。然后，您可以在主服务AppDomain中使用这样的代码：

// Create a new AppDomain for the plugin
AppDomain pluginDomain = AppDomain.CreateDomain("PluginDomain", null, new AppDomainSetup());

// Instantiate the plugin type (in the new AppDomain)
// Note: assumes that PluginBase is MarshalByRefObject
PluginBase plugin = (PluginBase)domain.CreateInstanceAndUnwrap("PluginLib", "PluginLib.PluginImp");

// Set any internal stuff now
plugin.InternalDetails = "...";

Answer 3

（对于我和其他人未来的参考）

事实证明这是一个毫无意义的练习。

一旦插件创建的对象的代理在其他appdomains中可用，那个服务定义的基类中以内部方式使用服务的任何东西（比如对集合的查找），它都会对照副本插件的appdomain中的服务对象，而不是我试图提供的单例。

我认为我要放弃我的多appdomain任务或放弃在内部做任何事情。如果没有内部操作，基类可以从服务中拆分，但是它必须像其他所有操作一样与服务进行交互。

我喜欢学习，但我并不欣赏沿途的头部碰撞。

抽象基类和appdomains

3 个答案: