>Frameworks should be multiple DLLs, that have specific needs, not general. Can you imagine if the .Net framework was a single assembly?

I never considered .NET framework to be a framework otherwise we wouldn't have to build a framework. And, sitting on this nationwide product, the last thing I would want would be to start breaking it up. When an update has to be sent, or request for an adjustment, I only have to send one file to the client and it does it all, no matter if this is the Web, Desktop or Web Service. This is a vision that is not shared by that much developers because it costs a lot at first, and in time as well, but I wouldn't change it for anything at this point. We just do miracles with it and this vision is shared by all the clients who use it.

>I suggest a good reading of this book (also available online for free)

Thanks for the reference but, while I am sure there are good things to read in it, I could write one on my own as well as not too many persons in this world have achieved the release of two major frameworks for two different development environments in their life. So, it allowed me to reach a new level with a set of skills that I need on my daily basis. Frameworks are also time intensive resource demanding and usually, this goes on R & D for corporations who can afford to spend times on such architecture. Most of the .NET developers I know are still coding everything directly from the .NET Framework. When that will be gone, and we have seen that before witih VFP, they will be stucked to start all over. The architecture I have built over the years allows me to bypass that. I did not say it was easy. I can't remember the overnight shifts I have done. But, for classes and training I have offered on frameworks, I do not think I have to go back in the kindergarden.