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.