Home/ Questions/Q 8027859
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T23:56:34+00:00

I am writing a WinForms based IDE-style application. As part of that application it

  • 0

I am writing a WinForms based IDE-style application. As part of that application it loads plugins which implement an interface called IFeature. Features are loaded by the main IDE framework via MEF, and then asked to instantiate an instance of Control, which is then added to a tab page to form the main working surface for the plugin. So far so good.

I’m now working on trying to protect the IDE from badly implemented plugins, and I am out of good ideas on how to do that, exactly. If, for example, a plugin is a button which throws an exception, then the IDE framework code is not involved in that call-stack at all, so there is no place for me to inject a try-catch. I have hooked onto the AppDomain.CurrentDomain.UnhandledException and Application.ThreadException events, which provide a top-level protection against exceptions thrown in that manner, but I was hoping to be able to catch them with some context so that the exception could be tied to the IFeature instance that was responsible for the problem.

I did have the idea of creating a class derived from Control – and then over-riding all sorts of methods and implementing try-catch – but that

a. Seems clumsy.
b. Wouldn’t protect against controls which in turn over-ride the method.
c. Would prevent any non-custom controls as being used (for example, Panel)

Are there any other methods I can use to provide closer-to-the-cause protection for my framework, or am I stuck with the handling the very broad scope events as above.

Thanks

Matt

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In general I would not burden myself too much with this.

    Just tell the plug-in developers that when you catch an exception that their control let slip you will remove all references to the control.

    It is too hard to do anything else because you will have to envision everything a control could do wrong.

    For a non-UI plugin I would kill the appdomain.

    Removing all references might not be as safe and that’s probably why many programs that allow UI plugins do not allow the UI to be drawn by the plugin but instead draw the UI for the plugin based on what the plugin suggests through an interface.

    • 0