Why System.design.dll?

Someone recently asked me why we separated out System.Design.dll from System.dll and System.Drawing.Design.dll from System.Drawing.dll.   They are essentially trying to decide how to factor their assemblies… In general fewer, larger assemblies are better from a load time perspective if most of the functionality will be loaded.  There is a per-assembly overhead.  But of course, factoring functionality into different assemblies is good from a versioning, identity and deployment point of view. 


Anyway, Brian Pepin gives the history here… I thought you’d enjoy it.. Notice I think that 2 is much more important than 1…


1)       We wanted to reserve the right at a later date of shipping just a “runtime” redist that was lighter weight.  System.Design would only go in a heavier SDK Redist.

a.       In order to do this, we placed all “interface apis” in System while the implementations of these apis we placed in System.Design.  In this regard, System behaves a little like a header file for design time apis.

2)       Designers are often cross-discipline chunks of code.  The Windows Forms designer may rely on System.Data or System.Xml, but we wouldn’t want to have those assemblies referenced by System.Windows.Forms.


Comments (11)

  1. Matthew W. Jackson says:

    I would like to some guidelines regarding design-time-only code. Many custom control libraries I have seen (including ones I have written in the past) have design-time code built in.

    It took me a while to realize you could move the designers/type editors/etc. to an separate assembly without referencing that assembly explicitly.

  2. Tony Williams says:

    Reasons 1 and 2 are actually the same reason. At some point if you want a lightweight runtime redist you need a decoupling both from the designer classes, and from everything they depend on.

  3. Mitch Denny says:

    My question would be – why is all the good stuff private – eg CompositionUI!

  4. Brian Pepin says:

    I’ve publshed a set of guidelines that we use when deciding whether to put a class in a runtime or design time assembly here: http://www.urbanpotato.net/Default.aspx?document=1936.

    Mitch — quite a lot of the good stuff is private because we don’t yet feel comfortable enough with the API to commit to it forever. CompositionUI, for example, may get completely rewritten in future versions of the framework. The feature it provides – the "component designer" – is something that we consistently get negative usability feedback on. Had we made this class public, we would have to live with it forever. We designed a few key classes to be public, and as time goes I suspect you’ll see more private classes become public as we hone their API and behavior to better support reuse and derivation.

  5. Edward Diener says:

    One may want a TypeConverter only for design time, in order to convert back and forth between a property’s actual type and a string. But this is impossible with the way you have done things, insisting that TypeConverters, even when used only for design time support, must be in a run-time assembly.

    Further toolbox bitmaps, which are also used only at design time, must be in the run-time assembly, or distributed as separate files which is equally as bad.

    Fix these two problems and then truly you can say that it is possible to separate all design-time code from run-time code when creating components.

  6. Access denied attempting to launch a DCOM Server DCOM was unable to communicate with the computer MATRIX using any of the configured protocols. The driver has detected that this HID keyboard has bad firmware. It is issuing redundant report packets….

Skip to main content