views:

308

answers:

6

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
+3  A: 

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);
    }
}
Andrew Hare
1) Get an idea of how best to learn new areas (to me at least) of the framework. 2) Explain to non-.NET programmers and non-technical people how big .NET is and why it is possible to work entirely within the bounds of .NET.
Ash
This is an interesting metric. +1 for the summing algorithm. But these numbers can only become interesting if you can then figure out how much of the FCL you know and how could one practically quantify that? e.g. An inventory of the .Net section of your own gray matter. ;-p
Paul Sasik
+1 Nice update to the code, I'll try it out. I haven't used RuntimeEnvironment before, interesting to know.
Ash
Here's what I get on my system: Classes: 12688 Value types: 4438 Interfaces: 1296
Ash
A: 

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.

slugster
+2  A: 

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

Seth Petry-Johnson
+6  A: 

These 2 blog posts address this topic:

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

Ahmad Mageed
+1 Excellent links, exactly what was looking for.
Ash
A: 

You may think that .NET 3.5 is big, but I'll bet you a dollar it is an order of magnitude smaller than any version of J2EE.

rmalayter
anyone able to say if that is true or not? I'm curious.
Kevin Won
My frameworks bigger than yours! ;)
Ash
Don't just bet, prove it. Do you have any links regarding J2EE equivalent the ones posted by Ahmad. From memory J2EE is primarily server side ie no System.Windows.Forms, System.Windows equivalent). Whereas .NET Framework encompasses both.
Ash
A: 

It's a bit difficult to answer without having a def of what 'big' means--IL (.dll) size? source code size? scope of functionality? Also, are you talking about the most recent redist of 3.5 sp1 w/o any of the official add-ons (i.e F# stuff, MVC, etc) that are fully supported parts of the 'framework' but don't ship with the 3.5 redist?

Not trying to be difficult... just saying that there is a few vars 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.

Kevin Won
As I say in the question, version 3.5 of the FCL (including the BCL). I'm defining size as the number of namespaces, classes, structs and interfaces.
Ash