DockPanel Suite assembly contains a reference to System.Design, and some classes are especially for design time support.
This prevents users from using it in a project that targets client profile (.NET 3.5/4).
We can split such design time support to a separate assembly.
I did the same for Crad's ActionList,
Is System.Design truly required in the first place? It appears the only usage is in the DockPanel for the Designer attribute, however we're not actually setting a custom designer.
I never use the Designer due to its limitations.
Is there any side effect if we remove [Designer(typeof(System.Windows.Forms.Design.ControlDesigner))] from DockPanel definition?
If no side effect, we might remove System.Design completely.
I believe the purpose is to prevent controls from being parented by the dockpanel via the designer. For example, currently if you drop a control on top of a dockpanel it will not be added to the dockpanel's controls. The designer attribute is overriding the PanelDesigner set on the base class, which will allow you to drop a control onto the dockpanel itself (as you could with any panel).
So the purpose of the designer attribute here is desired, although I wonder if it can be accomplished another way.
If that's the usage of that attribute we can change it from using typeof to using a string.
Ah yes, good call. That should work perfectly!
According to this page, we should be able to replace [Designer(typeof(System.Windows.Forms.Design.ControlDesigner))] with [Designer("System.Windows.Forms.Design.ControlDesigner, System.Design"))] and then remove System.Design from reference list,
Can you test it? @roken
Looks good, you can check that in.
#42 Removed dependency on System.Design.