Why so many individual System.Web.* DLLs?

I've been thinking about ways to refactor a fairly expansive class/utility library I have, and one thing I think I want to do is split off any higher-level help开发者_如何学Goer utilities that introduce new dependencies. I read some previous questions here, and one that I particularly noticed was a comment about how Microsoft freely uses namespaces across DLLs. The example given was System.Web - it's in the base framework, but there's also a System.Web.dll that adds more functionality to the namespace if you want it.

I also noticed several other System.Web.* DLLs available, and I was wondering if there's a reason why they wouldn't be combined into a single DLL. Could it be that they have their own individual dependencies and Microsoft (like me) wanted to separate assemblies along those lines? Or is it for easier maintenance? Something else entirely?

The reason they are not 1 .dll is because different versions of the framework.

System.Web under version 2.0

System.Web.Abstractions, System.Web.DymanicData, System.Web.DymanicData.Design, etc. . . . System.Web.Extensions

are all written under the 3.5 framework.

If you changed System.Web to be 1 .dll and then all users would have to change the .NET 3.5 framework, IIS still uses 2.0.

Well, there could be other answers, but the one that is most important to me is the security angle. You grant permissions on assemblies, not namespaces. This would allow you to group classes logically by intention via namespaces, but have classes that access resources grouped together in an assembly.

Oh, and you also can have language neutral assemblies, allow you to group language-dependent routines in a different assembly.

Many of the System.web assemblies are in use only when a ASP.net server is processing and serving up a page or web-service. They are, generally, not required for client side .Net applications, and are not included in the .Net Client Profile smaller; a slimed down, version of the .Net framework. (ref: http://msdn.microsoft.com/en-us/library/cc656912.aspx)