I am implementing several different functionalities in the Event System, one of which connects to an external system. I would like to isolate these from each other and am thinking to create separate assemblies, and register multiple DLLs in the EventSystem section of the Tridion ContentManager.config file.

Are there any performance penalties or things to consider when using more than 1 Event System DLL?

  • which version of SDL Tridion are we talking about here exactly? Jan 12, 2015 at 12:46
  • Tridion 2013 SP1 (but could apply to Tridion 2011+)
    – robrtc
    Jan 12, 2015 at 13:40
  • Bookmarklet challenge on 'Featured Meta on right'
    – robrtc
    Jan 12, 2015 at 15:48

3 Answers 3


I'm not aware of any performance issues or other things to consider. So I'd say go for it, as long as it logically makes sense to split them up and you don't create hundreds of them :)

  • Thanks Peter. Yes, I am thinking 2-3 separate DLLs, based on user functionality, as they will have a different rate of change, where some might never change and others more frequently.
    – robrtc
    Jan 12, 2015 at 12:09

For 2011 and up I would actually say it is preferred to use multiple DLLs, specifically so you can isolate different features and have a better control over what events you want enabled or not.

You see SDL doing it already by themselves, ECL for example comes with it own event DLL and so do a few other extensions.

Personally I would separate the DLLs purely by their extension/feature. If you implement some feature and it requires an event handler, add an assembly for that. If your feature has several options that you want different event handlers for (for instance optionaly a Component and Page Save event handler), the you could even create multiple assemblies for them. So that you can enable them separately.

As Nick and Peter already indicated, there is no known downside to having many DLLs.


When it comes to specifics around Tridion, the thing to consider with multiple event DLLs is that it may not be clearly visible what all the subscribed events are. For example, several DLLs may subscribe to Component save where the events potentially do the same logic. This scenario could come up in large organizations where there is no single owner of the event system, whilst the admins who deploy the DLLs don't know the logic within to catch anything that should not be.

Performance impact of having multiple event system DLLs should not be of concern with just a few DLLs. This can become an issue with loading and JIT compiling hundreds of DLLs, but generally shouldn't be of concern for just a few assemblies that we could chunk our Event System into. More on the general topic of having multiple DLLs here: https://stackoverflow.com/q/3406739/1284894

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.