在工作计算机上部署和运行 .NET 程序集
我有一个基本的任务框架，其中诸如：
- 执行一些内容处理、
- 报告生成、
- 错误日志观察
- 程序、邮件程序
- 等
任务被封装在一个 ITask 接口中，该接口有一个 Run 方法，以及其他与状态相关的成员。
这些任务要么按计划连续运行，要么按需运行。 它们要么作为 Windows 服务托管，要么作为工作计算机上的控制台应用程序托管。
主机应用程序使用 TaskRunner 类运行一组任务，该类可能使用计划、线程等。
我希望能够以比执行发布并进行更新。
基本上，我希望能够发送 ITask 接口（或另一个子组件）的进程和实现，以按某个时间表或某些设置运行。
我知道我可以动态加载程序集，而且我还看到：MEF。
解决这个问题的最佳方法是什么？ 我是否应该构建一个实现并将 DLL 发布到工作进程可以读取它们的已知目录？ 我应该将 DLL 作为二进制文件发布到数据库中以供工作人员读取吗？
I have a basic task framework, where tasks such as:
- doing some content processing
- report generation
- error log watcher
- mailer
- etc.
are encapsulated in an ITask interface, which has a Run method, and other status related members.
These tasks are either run continuously on a schedule, or on demand. They are hosted either as a windows service, or as a console application on a worker machine.
The host application runs a set of tasks with a TaskRunner class, which may use a schedule, threading, etc.
I would like to be able to deploy a task to a worker machine in a more automated way than performing a release and doing an update.
Basically, I would like to be able to send a process and implementation of an ITask interface (or another sub-component) to be run on some schedule, or with some settings.
I know that I can load assemblies dynamically, and I have also seen: MEF.
What is the best way to go about this? Should I build an implementation and publish the DLLs to a known directory where the worker process can read them? Should I publish the DLL as a binary to a database, for the worker to read?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
无论哪种方式都会起作用。 在我看来，您更喜欢哪一种取决于您的操作要求。
如果您已经安装了一个良好的数据库，并且您希望任务能够被严格管理和查询，并且如果您有许多其他属性想要与任务关联，那么数据库及其强制执行的能力严格的模式和查询/更新功能将是关键。
相反，如果您的环境比较宽松，没有安装数据库服务器，并且您只是希望能够将任务推出，那么共享文件系统或只是文件删除会更有意义。
如果您对其中任何一个都没有强烈的偏好，并且如果您希望模型具有灵活性，请在任一端封装发布和加载内容，以便您可以轻松配置文件系统或数据库或其他提供程序。
无论哪种情况，动态加载程序集并调用它都会很容易。
Either way will work. It seems to me the one you prefer will depend on your operational requirements.
If you have a good database installed already, and you would like the tasks to be tightly managed and queryable, and if you have a number of other attributes that you would like to associate to a task, then a database, with its ability to enforce a strict schema and query/update capability will be the thing.
If instead you have a looser environment, you have no db server installed, and you just want to be able to push tasks out, a shared filesystem or just a file drop would make more sense.
If you don't see a strong preference for either, and if you want flexibility in the model, encapsulate the publish and load stuff, on either end, so that you can easily configure either a filesystem or a database, or some other provider.
In either case, loading the assembly dynamically and calling into it will be easy.
我的建议是查看 Codeplex 上的 WPF CAB 项目。 在该项目中，它具有将新 dll 注册为实现接口 IModule 的模块的概念。
您可以遵循相同的模式，仅使用 ITask，然后调用 ITask.RunTask() 或等效函数。
My recommendation would be to look at the WPF CAB project on Codeplex. Within the project it has the concept of registering new dlls as Modules which implement an interface IModule.
You could follow the same pattern only use ITask and then call the ITask.RunTask() or equivalent.