在撰写此问题时：AppDomain, handling the exceptions我还想到了另一个问题。
如果您要编写我上面写的插件应用程序。你会把插件写成可执行文件还是库？
对于通过AppDomain.ExecuteAssembly(String)方法运行的动态加载的可执行文件，您将获得多少控制权？而不是使用AppDomain.CreateInstanceAndUnwrap(String, String)创建对象的实例。
我目前有一个接口，其中包含在CreateInstanceAndUnwrap之后调用的Start / Run + Stop + Init方法。您是否对执行的装配版本具有相同类型的控制权？如果我使用后者，我怎样才能实现动态停止该插件的功能？
或者我是在想错误的方向？
[编辑后的问题]
基本上我们得到了“一个”应用程序和多个功能。
计算机可以运行多个任务/插件。例如，我们可以选择让一台计算机处理整个图像下载/显示/打印系统。或者有一台带有多个下载/显示系统的集中式打印计算机。
一切都是通过套接字进行沟通
如果插件因任何原因崩溃，则需要重新启动并将邮件发送到办公室。如果在短时间内多次发生相同的崩溃，那么它应该发送某种紧急电子邮件并关闭该插件并通知操作员。
其中一些函数使用第三方非托管代码，一些使用C ++ / Native编写，一些使用C ++ / CLI编写，其他函数使用C＃编写，所有函数都将在与不同项目相同的解决方案中编写。
EDIT2 我们还希望在系统中添加此附加功能。只要有更新版本的插件可用，它就会自动更新插件。父AppDomain /线程应定期检查更新，如果发现更新，则应卸载该插件，下载新版本并重新启动。由于这个特殊原因，我认为我们需要使用AppDomain的
答案 0 :(得分：2)
我肯定会使用CreateInstanceAndUnwrap()。您可以通过这种方式获得更多控制权，并且可以合理地与插件进行通信。当您使用ExecuteAssembly()时，您几乎可以启动它，然后读取返回值（int）。
此外，当使用CreateInstanceAndUnwrap()时，如果你有充分的理由这么做就没有什么能阻止你使用exe。
基本上，你有一个有效的解决方案，没有必要改变它（至少不是这个方向）。
答案 1 :(得分：0)
您还应该考虑替代设计。根据这些信息：
我目前有一个具有开始/运行+停止功能的界面 + Init方法
...
计算机可以运行多个任务/插件。例如，我们可以选择 让一台计算机处理整个图像下载/显示/打印 系统。或者有一台集中打印的计算机有多个 下载/显示系统。
...
一切都是通过套接字进行沟通
通信已由套接字完成，唯一缺少的功能是“管理”：
你可以简单地利用已经存在的东西 - Windows服务。如果将插件部署为Windows服务，则已经实现了1,2和3。您不必担心AppDomains，本机代码崩溃等问题。管理员可以很好地进行实施，测试和理解。你可以manage windows services programaticaly。您唯一需要做的就是编写一个'WatchDog'服务，该服务将发送电子邮件并处理自动更新。