On previous projects, I am used to setup plugins as one project, resulting in one plugin assembly. Each class created was an event, e.g. AccountPreValidate, AccountPreCreate,... External libraries were included via ILMerge.
As a PoC, I started to divide plugins per functionality, in a class per functionality: e.g. Account.SetDefaultBusiness or Account.CreateMasterdataTask. This seems to lead to much cleaner steps, with matching filtering attributes and allows to disable functionality when needed (e.g. during data migration). However it leads to other questions:
- Can you better create one big plugin assembly or an assembly per entity for example?
I have seen projects having an assembly per triggering entity, e.g. AccountPlugin and ContactPlugin assemblies. In large projects, this leads to up to 50+ projects. How does it affect performance, maintainablility, caching? What are the pro's and cons of both?
- We are setting up plugins in such way that they contain a few lines of code, and then call a function/method in a separate library, containing all business logic. However the customer's shared library should contain some of our common logic used on every customer project, which we were planning to distribute via nuget.
Since the use of ILMerge is unsupported/discouraged (community.dynamics.com/.../if-you-re-using-ilmerge-with-your-plugins-make-sure-you-read-this), how can we share code over multiple projects? I was thinking on Shared projects in VS, but those do not allow nuget to include our vendor specific code. Are there other solutions?
- When using a shared project for the library, we could add our early bound classes there? Would you include all generated early bound classes in each plugin project (if working with multiple projects)?
Kind regards
Kim
*This post is locked for comments
I have the same question (0)
