Take the 2-minute tour ×

I want to have an abstract UserControl, BaseControl, that implements an interface IBaseControl. However, setting the class to abstract breaks VisualStudio designer (This is a known issue with Visual Studio (e.g., see this StackOverflow posting for more info), and as far as I know, there's no change expected in the near future

So, to work around this, I make BaseControl not abstract, and its implementation of IBaseControl methods virtual. However, since these methods make no sense for a BaseControl (e.g., not all components have been added yet), I make them throw:

public class BaseControl : UserControl, IBaseControl
    /// <summary>
    /// This IBaseControl method is not abstract because 
    /// that breaks the Designer
    /// </summary>
    public virtual void LoadSettings()
        throw new NotImplementedException("Implement in derived class.");

    private void BaseControl_Load(object sender, EventArgs e)
        // intention: derived methods automagically load their settings

In the derived control, I have the corresponding override:

public partial class DerivedControl : BaseControl
    public override void LoadSettings()
        // load settings

Despite this, when I try to open the control in the designer, I get an error indicating that the BaseControl.LoadSettings has thrown an exception.

Now, remember LoadSettings is called in the base class, so when the Designer loads the DerivedControl, it in turn calls the load method for the BaseControl, which throws.

Have you encountered a similar problem? How have you dealt with this? I'd like to have an elegant solution, if possible.

share|improve this question
No repro, I didn't expect one. You've got two controls on the toolbar now, don't pick the wrong one. You really should override OnLoad instead of using the Load event. –  Hans Passant Jun 9 '11 at 20:53

1 Answer 1

up vote 6 down vote accepted

The reason that the exception is thrown is because, oddly enough, the designer doesn't compile or instantiate the class your are designing at all! It only compiles and instantiates the base class of the control you are designing.

Why this is the case becomes obvious when you realize that adding new subcontrols to the element would require further recompilation. Also, every event handler that you add modifies the class and again would require recompilation. Since event handlers will never be called in the designer anyway, this is all completely unnecessary. You design with a class that resembles your class but isn't your class; it's a work in progress.

Since only the base class is instantiated, the base class cannot be abstract and it needs to be functional as is. If you throw exceptions, then the designer will see them. The only practical solution is to either:

  • Not throw exceptions from the base class, or
  • Conditionally not throw exceptions based on whether it is design-time or not.

Either will work; use whichever you prefer or works best for your design. This is just the way the designer works and as you mention it is not likely to change.

share|improve this answer
Awesome, this is it! I'm now using the if (!DesignMode) to throw conditionally. –  Gustavo Mori Jun 9 '11 at 20:57

Your Answer


