AppDomain，运行程序集 .exe 还是 .dll? [英] AppDomain, running an assembly .exe or .dll?

问题描述

在写这个问题时:AppDomain，处理异常我也想到了一个不同的问题.

While writing this question: AppDomain, handling the exceptions I also thought of a different question.

如果您像我上面写的那样编写插件应用程序.您打算将插件编写为可执行文件还是库?

If you would write a plugin app like I wrote above. Would you go about writing the plugins as executables or as libraries?

对于通过 AppDomain.ExecuteAssembly(String) 方法运行的动态加载的可执行文件，您有多少控制权?而不是使用 AppDomain.CreateInstanceAndUnwrap(String, String) 创建对象的实例.

How much control would you have over a dynamically loaded executable that is run through the AppDomain.ExecuteAssembly(String) method? instead of creating an instance of an object using AppDomain.CreateInstanceAndUnwrap(String, String).

我目前有一个接口，其中包含在 CreateInstanceAndUnwrap 之后调用的 Start/Run + Stop + Init 方法.您对执行的程序集版本是否有相同类型的控制?如果我使用后者，我怎样才能实现这样的功能来动态停止该插件?

Where I currently have an interface which features a Start/Run + Stop + Init method that is called after CreateInstanceAndUnwrap. Would you have the same type of control over the executed assembly version? If I would use the latter, how can I achieve such functionality to dynamically stop that plugin?

还是我的想法完全错误?

Or am I thinking in the totally wrong direction?

[问题后编辑]

基本上我们得到了一个"应用程序和多种功能.

Basicly we got 'one' application, and multiple functions.

• 刻录(视频)DVD)
• 打印照片
• 从照片/摄像机下载图像
• POS
• 一个存储服务器，用作备份/配置设置/图像+视频存储库
• 在多个显示器上显示所述照片/视频
• 和其他一些，但这些是主要的功能"

一台计算机可以运行多个任务/插件.例如，我们可以选择让一台计算机处理整个图像下载/显示/打印系统.或者拥有一台带有多个下载/显示系统的中央打印计算机.

A computer can run multiple tasks/plugins. For instance, we can choose to have one computer handle the whole image download/display/print system. Or have one centralized printing computer with multiple download/display systems.

一切都通过套接字进行通信

Everything is communicating over sockets

如果插件因任何原因崩溃，则需要重新启动，并应向办公室发送邮件.如果同一崩溃在短时间内多次发生，那么它应该发送某种紧急电子邮件并关闭该插件并通知操作员.

If a plugin crashes for whatever reason it needs to be restarted and a mail should be send to the office. If the same crash occurs multiple times in a short timeframe then it should send some kind of emergency e-mail and shutdown that plugin and notify the operator.

其中一些函数使用第三方非托管代码，一些用 C++/Native 编写，一些用 C++/CLI 编写，其他用 C# 编写，所有这些都将在不同项目的同一解决方案中编写.

Some of these functions use thirdparty unmanaged code, some are written in C++/Native and some in C++/CLI others are written in C#, all will be written within the same solution as different projects.

编辑2我们还想将这个附加功能添加到系统中.它是在该插件的更新版本可用时自动更新该插件.父 AppDomain/线程应该定期检查更新，如果发现更新，它应该卸载该插件，下载新版本并重新启动它.出于这个特定原因，我认为我们需要使用 AppDomain 的

edit2 There is also this additional feature we would like to add to the system. It is to automatically update a plugin as soon as there is a newer version of that plugin available. The parent AppDomain/thread should periodically check for updates and if an update is found it should unload that plugin, download the new version and start it again. For this specific reason I think we need to use AppDomain's

推荐答案

我当然会使用 CreateInstanceAndUnwrap().您可以通过这种方式获得更多控制权，并且可以合理地与插件进行通信.当您使用 ExecuteAssembly() 时，您几乎可以启动它，然后读取返回值(一个 int).

I would certainly go with using CreateInstanceAndUnwrap(). You have much more control that way and you can reasonably communicate with the plugin. When you use ExecuteAssembly(), you can pretty much start it and then read the return value (an int).

此外，在使用 CreateInstanceAndUnwrap() 时，无论如何都不会阻止您使用 exe，如果您有充分的理由这样做.

Also, when using CreateInstanceAndUnwrap(), there is nothing stopping you from using an exe anyway, if you have a good reason to do it.

基本上，你有一个可行的解决方案，不需要改变它(至少不是在这个方向).

Basically, you have a working solution and there is no need to change it (at least not in this direction).

这篇关于AppDomain，运行程序集 .exe 还是 .dll?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！