D365 CE>管理插件的标准方法是什么? [英] D365 CE > What is the standard way to manage plugins?

问题描述

我正在寻找有关在D365 CE中实现插件的标准方法或Microsoft推荐的一些指导.

我通常会遵循这种做法-
1.对于所有这些插件步骤，只有一个CRM解决方案和一个插件程序集(DLL).
2.对于此项目中的每个插件，都有一个单独的".cs"文件.
3.每个插件对应于特定功能.因此，以防万一，我们想禁用任何功能，无需更改代码即可轻松完成.
4.所有这些插件只有一个CRM解决方案.

期待一些专家指导.

谢谢！

解决方案

在

.Cmd项目是控制台应用程序.带有双菱形图标的图标是共享项目(不能单独编译-必须由一个或多个可编译项目引用).

I am looking for some guidance on the standard way of implementing plugins in D365 CE or what Microsoft recommends.

I generally follow this practice -
1. Have only 1 CRM Solution and one plug-in assembly (DLL) for all these plugin steps.
2. Have a separate ".cs" file for each plugin in this project.
3. Each plugin corresponds to specific functionality. So in case, we want to disable any functionality, it could be easily done without changing the code.
4. Have only 1 CRM Solution for all these plugins.

Looking forward to some expert guidance.

Thanks!

解决方案

In this video former MVP Mitch Milam talks three plugin solution layout options. He recommends the approach you outline above, and that is the one I typically use.

I also generally use a Console app to test and debug plugins. For maximum flexibility, I often put all the business logic into a Visual Studio shared project. Then I reference that shared project from both the plugin project and the Console App.

While the Console app could reference a DLL, having the logic in a shared project easily allows me to also use the logic in a workflow project if I want. Ultimately, the shared project gives me the option run the code as a plugin, a workflow, or a Console app.

Here's an example:

The .Cmd project is the console app. The one with the double diamond icon is the shared project (which cannot be compiled on its own - it must be referenced by one or more compilable projects).

这篇关于D365 CE>管理插件的标准方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！