Plugin Project Development

(0) Share

Report

Posted on by matthew.mickas

505

I've joined onto a project where there are a large number of plugins and plugin steps in the environment, that currently all consists in a 2 projects and 2 DLLs. From what I've been told the only reason the 2nd DLL was created because when registering the first DLL it was starting to timeout.

With that said I was curious what the community thoughts are about separating out the plugins to have one DLL for each entity. Is there a restriction or performance impact in having a large number of DLLs registered? I also feel that this could limit the possible impact when deploying the plugins. Thoughts?

The project is currently on CRM 2011 but will be upgrading soony, in case that has any bearing.

*This post is locked for comments

I have the same question (0)

All responses (5)

Answers (1)

Suggested answer

Mahadeo Matre 17,021 on at

Like (0)

Report

Hi Matthew,

For improved performance, Microsoft Dynamics CRM caches plug-in instances. The plug-in's Execute method should be written to be stateless because the constructor is not called for every invocation of the plug-in. Also, multiple system threads could execute the plug-in at the same time. All per invocation state information is stored in the context, so you should not use global variables or attempt to store any data in member variables for use during the next plug-in invocation unless that data was obtained from the configuration parameter provided to the constructor. Changes to a plug-ins registration will cause the plug-in to be re-initialized.

Here are more details on plugin

msdn.microsoft.com/.../gg328263.aspx

msdn.microsoft.com/.../hh372952.aspx

msdn.microsoft.com/.../gg509027.aspx

Hope this will help

Was this reply helpful? Yes No
matthew.mickas 505 on at

Like (0)

Report

Thanks for the response Mahadeo! Those are great suggestions around the plugin performance, which by caching the plug-in instances could cause some performance issues if I have multiple DLLs. However, my question is more around solution/project structure for plugin development. I'm thinking about breaking out the plugins based on Entity and creating a new DLL for each entity. This is due to the number of steps in the current DLL.

Was this reply helpful? Yes No
Verified answer

Mahadeo Matre 17,021 on at

Like (0)

Report

you can do that.. creating DLL for each entity...

There are advantages and disadvantages.

Advantages

1. If one entity plugin is failing you can register / update plugin for only that entity..

2. Test is very isolated to one entity if there are any changes in plugin

Disadvantages:

1. You need to register all dlls,

2. Need to create multiple project and maintain them.

Was this reply helpful? Yes No
Suggested answer

ScottDurow 21 on at

Like (3)

Report

This is an excellent question!

Reasons to keep in a single plugin assembly:

1. Lower memory footprint at run time due to there being only a single set of proxy classes (and any other common code)

2. Easier to compile and version control. You know when you update the assembly that you have the latest versions of all plugins that have been tested to work together.

3. Easier to re-use common code between different plugins - and therefore easier to maintain. This can be alleviated by adding linked files in your project but then adds to point 1.

Reasons to split up:

1. Easier to re-use discrete functionality on other projects

2. Quicker to upload/update individual plugins due to the size

Personally I try to keep all plugins in a single assembly as much as possible - especially due to point 2 - easier to compile and version control

I would never recommend splitting up by entity - but rather by feature.

Hope this helps,

Scott

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Scott can you explain the "Lower memory footprint" concept.

Was this reply helpful? Yes No