The .NET Framework is a bit on the big side.
As anyone who has ever tried to find docs on MSDN already knows, the .NET Framework is big. Real big.
I can see the feedback already: Thanks, Mike for stating the bloody obvious....
Seriously, though, how big is this library that we have been building applications, web sites, critical line-of-business apps, and other frameworks on top of?
Brad Abrams posted all about the Number of Types in the .NET Framework. This includes info about the different versions of the .NET Framework, and the numbers of assemblies, namespaces, types, and members.
As a counterpoint, Patrick Smacchia posted Number of Types in the .NET Framework. using the numbers that he generated with nDepend. (Note from the lawyers: This is a link to an external Web site that provides software. Please note that Microsoft is not responsible for the content of external Internet sites. ) These numbers are a little differnt than Brad's.
With that in mind, it is no wonder that I forget how things in the framework work, every once in a while.
As a personal aside: I am a very happy, licensed user of nDepend, and it rocks. I have used it to help simplify APIs and frameworks like the Composite Web Application Block in WCSF. nDepend allowed me to file bugs against my team's code because methods were too big and complex, or types were too tightly coupled, or classes/interfaces needed to be moved from one assembly to another. One of my current projects is to data mine all the p&p build logs from the past 6 months+ to glean information about our code and improvements we should be making. nDepend results in those build logs provide a lot of data. I may post more about that project later.