Dynamics CRM 2011 - Does each plugin that related

问题:

I am creating a series of related plugins. Each plugin is for a different entity. Does each plugin have to have it's own assembly? I'm using Visual Studio and I created a second project within the same solution but I can't see the new step in registration tool.

Thanks

回答1:

It can do, but doesn't have to. That is pretty much your design decision. Consider if you had several classes all implementing IPlugin

public class MyFirstPlugin : IPlugin
{
    //implemented as per usual
}

public class MySecondPlugin : IPlugin
{
    //implemented as per usual
}

If you were to register that DLL in the plugin registration tool, you would see the following structure:

- Server
    - DLL
        - MyFirdtPlugin
        - MySecondPlugin

You can then add steps to each plugin as desired.

The alternative would be to have one plugin per DLL, which would give you

- Server
    - DLL1
        - MyFirstPlugin
    - DLL2
        - MySecondPlugin

I must admit it seems like overkill - but it can also depend on how you are using your solutions.

回答2:

In addition to glosrob's answer, I'm guessing that you're using the plugin registration tool to register your plugin. If so, you'll need to make sure that after you add your new plugin to the same dll, that you update the plugin dll itself with the registration tool, so you can register the new plugin method that you've created.

回答3:

Yes, you can create each plugin in a different class library project but this is not a good practice. I'd prefer to collect all plugins into one class library.

Note that after selecting your assembly from the File Dialog you have to click on Load Assembly button to load all classes which implement the IPlugin interface.

回答4:

To answer the question - no, each new plugin doesn't have to be contained in a new assembly.

To elaborate - it's technically possible to put in all the plugin code in just one project and a single file.

To warn - the above would be a nightmare to manage with all the ifs and buts, so it's a good example of can-but-shouldn't.

To suggest - I usually have a separate project for each entity's plugin and handle all the messages using a switch. On occasion, I might have two or three assemblies but you'll know when it's time to do so as you get there. Usually, one DLL is just enough.