Exactly how large is the .NET (3.5) Framework Class Library?

Question

I've regularly read that the framework is just too large for one developer to have experience with every part of it. Having some actual numbers would certainly help put things in perspective.

MSDN seems to list them all but there are no actual numbers (from what I could see) and spending hours counting them is not my idea of productive time.

• Number of Namespaces
• Number of Classes
• Number of Structs
• Number of Interfaces

I realize there are also delegates, enums, events, etc, but the above types are of most interest.

Also, the number of types in the Base Class Library (BCL) as well as the size of the overall Framework Class Library (FCL) would be interesting.

This information would be useful in 2 ways:

Firstly, to get a handle on how much of the overall framework you have actually worked with and how much you still have to learn.

Secondly, many programmers from other platforms (and non-technical people) are often surprised that a programmer can spend most of their time within the ".NET Framework". Having some numbers would certainly help explain why this is not an indication of narrow skills/experience.

[Update]

Using Andrew's code (on my .NET 3.5 SP1 system) I get:

Classes: 12688
Value types: 4438
Interfaces: 1296

Answer 1

These 2 blog posts address this topic:

• Brad Abrams: Number of Types in the .NET Framework (shows numbers across diff. framework versions)
• Patrick Smacchia: Number of Types in the .NET Framework (uses NDepend)

Results are broken down by number of assemblies, namespaces, types, members, and other items.

Answer 2

You could use reflection to find the number of different types in the BCL but what are you hoping to accomplish with that information?

Here is an example of how to get that information:

using System;
using System.Linq;
using System.Reflection;

class Example
{
    static void Main()
    {
        Assembly mscorlib = typeof(String).Assembly;

        // Number of classes
        Console.WriteLine(mscorlib.GetTypes().Where(t => t.IsClass).Count());
        // Number of value types (structs and enums)
        Console.WriteLine(mscorlib.GetTypes().Where(t => t.IsValueType).Count());
        // Number of interfaces
        Console.WriteLine(mscorlib.GetTypes().Where(t => t.IsInterface).Count());
    }
}

Just note that you will need to do this for every assembly in the framework to get total numbers.

Edit: Here is a quick and dirty solution that should give you a general idea of the number of types in the BCL:

using System;
using System.Linq;
using System.Reflection;
using System.IO;
using System.Runtime.InteropServices;

class Example
{
    static void Main()
    {
        // Get all DLLs in the current runtime directory
        var assemblies = Directory.GetFiles(
            RuntimeEnvironment.GetRuntimeDirectory())
            .Where(f => f.EndsWith(".dll"));

        Int32 classes = 0;
        Int32 valueTypes = 0;
        Int32 interfaces = 0;

        foreach (String name in assemblies)
        {
            // We need to catch BadImageFormatException
            // because not all DLLs in the runtime directory
            // are CLR assemblies.
            try
            {
                var types = Assembly.LoadFile(name).GetTypes();

                classes += types.Where(t => t.IsClass).Count();
                valueTypes += types.Where(t => t.IsValueType).Count();
                interfaces += types.Where(t => t.IsInterface).Count();
            }
            catch (BadImageFormatException) { }
        }

        Console.WriteLine("Classes: {0}", classes);
        Console.WriteLine("Value types: {0}", valueTypes);
        Console.WriteLine("Interfaces: {0}", interfaces);
    }
}

Answer 3

I haven't used it myself, but I think this is the sort of information that NDepend can provide to you.

Answer 4

It's so big that noone truly knows its size?

As far as file size goes, on my system the 2.0, 3.0 and 3.5 frameworks take up around 130MB disk space, and the 64 bit versions take roughly 93MB. But that's not counting the stuff that is core to Win7 itself.

Answer 5

It's a bit difficult to answer without having a definition of what 'big' means -- IL (.dll) size? Source code size? Scope of functionality? Also, are you talking about the most recent redistributable of 3.5 SP1 without any of the official add-ons (that is, F# stuff, MVC, etc.) that are fully supported parts of the 'framework' but don't ship with the 3.5 redistributable?

I am not trying to be difficult... I am just saying that there is a few variables that go into how one would even determine what is to be measured, then some questions about what kind of stick is used to measure it.