Static delegates and third-party extensions

Sep 24, 2010 at 1:15 AM

I really like the way Caliburn Micro can be extended/configured by overwriting delegates.  I prefer this mechanism over subclassing and overriding methods, like you had to do many times with Caliburn.

But, I've run into a problem with this approach.  My application loads third-party extensions containing screens, views, etc.  Because the delegates are static, these third-party extensions can overwrite them just like my application can overwrite them.  Given this power, they could inadvertently crash the main application, or worse could threaten security of the main application or any other extensions.

One way I see to fix this is to make all the delegates instance-level, providing instances to the bootstrapper so they can be configured.  I don't have a feel for how much work this might involve, so I just wanted to throw it out and see if anyone else had ideas.

Thanks (again) for all the hard work done on Caliburn!


Sep 27, 2010 at 2:03 PM


Sep 27, 2010 at 4:07 PM

I'm hesitant to make changes to the CM source.  But, in your case, I would take the CM source into your project and alter it so that the framework methods were not overridable. 

Sep 27, 2010 at 10:09 PM

That's cool.  It will be a while before I need to worry about this, but I may look into doing that as some point in the future.  Thanks!

Sep 28, 2010 at 10:08 AM

A simple workaround would be to have your 'overrides configuration' in a method somewhere that you call after loading every plugin.

Sep 28, 2010 at 3:07 PM

That sort-of works, but then the plugins could override something that would prevent my configuration from loading.  Or, the plugin could override it at some point after it is loaded, e.g. when its main screen is first displayed.

Sep 29, 2010 at 7:24 PM

If you're willing to consider making a change to the source code for this, then one option might be to change the public delegate fields into properties and add a static LockConfiguration() method that would set a flag to prevent future changes (presumably, the property setters would then either do nothing or throw an exception if something later on tried to set the property to a different value).  This way, all the configuration could be set up by the main application and then locked before the plugins are loaded.

Oct 18, 2010 at 12:22 AM
Edited Oct 18, 2010 at 3:04 AM

I did as Nereidum suggested, and created a fork of CM at

See this thread for more information: