J'ai lu régulièrement que le cadre est trop grand pour un développeur d'avoir une expérience de chaque partie. Avoir des chiffres réels aiderait certainement à mettre les choses en perspective.
MSDN semble tous les énumérer, mais il n'y a pas de chiffres réels (de ce que je pouvais voir) et de passer des heures à les compter n'est pas mon idée du temps productif.
Je me rends compte qu'il existe également des délégués, des énums, des événements, etc., mais les types ci-dessus sont de la plupart des intérêts.
En outre, le nombre de types dans la bibliothèque de la classe de base (BCL) ainsi que la taille de la bibliothèque de la classe-cadre globale (FCL) serait intéressante.
Cette information serait utile de 2 façons:
Tout d'abord, pour obtenir une poignée sur combien du cadre général que vous avez effectivement travaillé et combien vous devez encore apprendre.
Deuxièmement, de nombreux programmeurs d'autres plates-formes (et non techniques) sont souvent surpris qu'un programmeur puisse passer la majeure partie de leur temps dans le ".NET Framework". Avoir des chiffres aiderait certainement à expliquer pourquoi ce n'est pas une indication de compétences / expérience étroites.
[Mise à jour]
Utilisation du code d'Andrew (sur mon système de SP1 .NET 3.5 SP1) :
5 Réponses :
Vous pouvez utiliser la réflexion pour trouver le nombre de types différents dans la BCL mais que vous espérez accomplir avec ces informations?
Voici un exemple de comment obtenir cette information: P>
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);
}
}
1) Obtenez une idée de la meilleure façon d'apprendre de nouveaux domaines (au moins) du cadre. 2) Expliquez aux programmeurs non -.net et les personnes non techniques Quelle est la taille de la taille et de la raison pour laquelle il est possible de travailler entièrement dans les limites de .NET.
Ceci est une métrique intéressante. +1 pour l'algorithme de sommation. Mais ces chiffres ne peuvent devenir intéressants que si vous pouvez alors déterminer la quantité de FCL que vous connaissez et comment pourrait-on quantifier pratiquement cela? par exemple. Un inventaire de la section .NET de votre propre matière grise. ;-p
+1 Belle mise à jour du code, je vais l'essayer. Je n'ai pas utilisé RuntiMeenvironment avant, intéressant de savoir.
Voici ce que je suis sur mon système: classes: 12688 Types de valeur: 4438 Interfaces: 1296
C'est si gros que personne ne connaisse vraiment sa taille?
En ce qui concerne la taille du fichier, sur mon système Les cadres 2.0, 3.0 et 3.5 prennent environ 130 Mo d'espace disque et les versions 64 bits prennent environ 93 Mo. Mais cela ne compte pas les choses qui sont noyau pour Win7 lui-même.
Je ne l'ai pas utilisé moi-même, mais je pense que c'est le genre d'informations que Ndepend peut vous fournir.
Ces 2 postes de blog adressent ce sujet:
Les résultats sont décomposés par nombre d'assemblages, espaces de noms, types, membres et autres éléments.
C'est un peu difficile de répondre sans avoir de définition de ce que "gros" signifie - la taille de l'IL (.dll)? Taille de code source? Portée de la fonctionnalité? En outre, parlez-vous de la plus récente redistribuabilité de 3,5 SP1 sans aucun des compléments officiels (c'est-à-dire F # Stuff, MVC, etc.) qui sont des parties entièrement soutenues du «cadre» mais ne sont pas expédiées avec le 3.5 Redistributable?
Je n'essaie pas d'être difficile ... Je dis simplement qu'il y a quelques variables qui entrent sur la manière dont on déterminerait même ce qui doit être mesuré, alors quelques questions sur le type de bâton utilisé pour le mesurer .
Comme je le dis dans la question, la version 3.5 de la FCL (y compris la BCL). Je défini la taille que le nombre d'espaces de noms, de classes, de structures et d'interfaces.
Vous pourriez être intéressé par l'analyse rapide de Patric Smacchia de .NET 4.0: codeBetter.com/blogs/patricksmacchia/archive/2009/05/21/...
Je compile le code de Andrew dans VS2010: Classess: 12704 Types de valeur: 4416 Interface: 1287