Espace de noms ou assemblée?
Je deviens très confus entre Namespaces et Assemblies. Les System.Data Et System.Web Sont-ils des espaces de noms ou des assemblages?
J'ai remarqué que ces espaces s'appellent des espaces de noms et qu'ils sont en même temps présents dans le dossier GAC_32. Alors qu'est-ce qu'ils sont exactement?
System.Data est un espace de noms, System.Data.DLL (le fichier) est un Assembly.
Un espace de noms est un regroupement logique de types (principalement pour éviter les conflits de noms). Un assembly peut contenir des types dans plusieurs espaces de noms (System.DLL contient quelques-uns ...), et un seul espace de noms peut être réparti sur des assemblys (par exemple, System.Threading).
Espace de noms est un groupe logique de classes appartenant à la même fonctionnalité. Alors System.Web et System.Data sont des espaces de noms
MSDN le décrit comme suit:
Les espaces de noms sont fortement utilisés dans la programmation C # de deux manières. Premièrement, le .NET Framework utilise des espaces de noms pour organiser ses nombreuses classes. Deuxièmement, la déclaration de vos propres espaces de noms peut aider à contrôler la portée des noms de classe et de méthode dans des projets de programmation plus importants.
Assembly est un bloc de code (précompilé) pouvant être exécuté par l'environnement d'exécution .NET. Il contient un ou plusieurs espaces-noms. Un programme .NET consiste en un ou plusieurs assemblys.
System.Web.dll et System.Data.dll sont des assemblées.
MSDN le décrit comme suit:
Les assemblages sont les éléments constitutifs des applications .NET Framework; ils constituent l'unité fondamentale du déploiement, du contrôle de version, de la réutilisation, de l'étendue de l'activation et des autorisations de sécurité. Un assemblage est un ensemble de types et de ressources conçus pour fonctionner ensemble et constituer une unité logique de fonctionnalités. Un assembly fournit au Common Language Runtime les informations nécessaires pour connaître les implémentations de types. Pour l'exécution, un type n'existe pas en dehors du contexte d'un assembly.
En bref:
Assemblée:
Un assemblage fournit une unité fondamentale de regroupement de code physique. C'est une unité de sortie. C'est une unité de déploiement et une unité de gestion de versions. Les assemblées contiennent le code MSIL.
Espace de noms:
Un espace de noms fournit une unité fondamentale de regroupement de codes logiques. Il s'agit d'une collection de noms dans laquelle chaque nom est unique. Ils forment la limite logique d'un groupe de classes. L'espace de noms doit être spécifié dans les propriétés du projet.
Ce sont des espaces de noms. Les assemblées contiennent plusieurs espaces de noms. Par exemple: System.dll Contient les espaces de noms suivants (et plus):
De plus, un espace de noms peut contenir des espaces de noms imbriqués. Ce ne sont que des noms logiques pour organiser le code. Notez que les fichiers DLL sont des assemblys contenant des espaces de noms.
GAC est Global Assembly Cache . Selon MSDN:
Le cache global Assembly stocke des assemblys spécifiquement désignés pour être partagés par plusieurs applications sur l'ordinateur.
Les assemblages généralement utilisés stockés dans GAC et vous n'avez donc pas besoin de copier tous les fichiers d'assembly dans le répertoire de projet que vous référencez à partir de votre projet. Les assemblys stockés dans GAC sont - Strong-Named assemblies.Normally lorsque vous ajoutez une référence à un assembly de votre projet qui n'est pas Strong-Named, Une copie de votre fichier .dll Sera créée sur votre bin\Debug Dossier..Si vous le souhaitez, vous pouvez créer votre assembly (projet de bibliothèque de classes, par exemple) Strong-Named.See: Procédure: signer un assembly avec un nom fort
En bref:
- Assembly est stocké sous forme de fichier .exe ou dll.
- L'espace de noms permet de regrouper les noms de types et de réduire les risques de collision.
Conseils.
Un assembly contient une collection de types (par exemple, l'Assembly System contient de nombreux espaces de noms inclus System, System.IO, ecc). Généralement, le nom d'assembly est identique à celui d'un espace de noms qu'il contient, mais pas toujours.
Autre exemple d'assemblys et d'espaces de noms.
Assembly 1 ( CoreAssembly.DLL )
Contient les espaces de noms Namespace1.subnamespace1
Assembly 2 ( ExtensionCoreAssembly.DLL )
Contient les espaces de noms Namespace1.subnamespace1
Il est possible d'utiliser le nom d'assembly qui contient différents espaces de noms et d'étendre un assemblage existant avec un autre assemblage par cette technique.
DÉFINITIONS.
Assemblées
Un assemblage est un ensemble de types et de ressources constituant une unité logique de fonctionnalités. Tous les types du .NET Framework doivent exister dans des assemblys; le common language runtime ne prend pas en charge les types en dehors des assemblys. Chaque fois que vous créez une application Microsoft Windows®, un service Windows, une bibliothèque de classes ou une autre application avec Visual Basic .NET, vous créez un seul assembly. Chaque assemblage est stocké dans un fichier .exe ou .dll. Remarque Bien qu'il soit techniquement possible de créer des assemblages couvrant plusieurs fichiers, il est peu probable que vous utilisiez cette technologie dans la plupart des situations.
Espaces de nommage
Un autre moyen d'organiser votre code Visual Basic .NET consiste à utiliser des espaces de noms. Les espaces de noms ne remplacent pas les assemblys, mais constituent une seconde méthode d'organisation qui complète les assemblys. Les espaces de noms permettent de regrouper les noms de types et de réduire les risques de collision. Un espace de noms peut contenir d'autres types et espaces de noms. Le nom complet d'un type inclut la combinaison d'espaces de nommage contenant ce type.
D'autres ont donné de très bonnes réponses détaillées à cette question. Mais je tiens à souligner que lorsque vous n'êtes pas sûr, vous pouvez regarder sur MSDN. La bibliothèque MSDN explique très clairement et simplement les namespace et Assembly dans lesquels tout type donné réside. Il dit même le nom du fichier (in System.Data.dll) donc il n'y a pas d'ambiguïté.
Le fichier que vous voyez dans GAC est System.Data.dll qui est un assembly et qui contient des espaces de noms comprenant System.Data. Si vous affichez les propriétés de référence dans Visual studio, vous verrez:
Plus tard, si vous cliquez avec le bouton droit de la souris sur la référence et que vous sélectionnez la vue dans le navigateur d’objets, vous verrez des espaces de noms dans cet assemblage particulier.
Comme @amdluigi le dit, "Habituellement, le nom de Assembly est identique à un espace de noms qu'il contient, mais pas toujours".
Il y a une capture d'écran ci-dessus de System.Data.dll dans le navigateur d'objets de Studio. C'est un excellent exemple pour explorer les problèmes ici. Notez que la plupart des espaces de noms contenus dans l'assembly sont System.Data ou un sous-espace de noms de System.Data.
En règle générale, il est judicieux d'associer les noms d'assemblés aux espaces de noms qu'ils contiennent. Notez que lorsque Studio crée un projet pour la première fois pour construire un assemblage, l'une des propriétés du projet est un espace de noms par défaut. Au début, Studio attribue à l'espace de noms par défaut le même nom que le projet lui-même. Si vous choisissez de renommer un projet, envisagez également de modifier son espace de noms par défaut.
Il existe deux espaces de noms supplémentaires: Microsoft.SqlServer est compréhensible. Certains types SQL Server qu'ils ne voulaient pas empaqueter dans un assembly séparé.
Mais qu'est-ce qui se passe avec System.Xml ???? Il existe un assembly System.Xml.dll. Pourquoi cet espace de noms apparaît-il également dans System.Data.dll?
Notez qu'un assembly peut rouvrir un espace de noms et en ajouter d'autres. C'est exactement ce que System.Data.dll fait avec l'espace de noms System.Xml.
La raison en est que les espaces de noms n’ont aucune incidence sur les performances, contrairement aux assemblages. Si vous avez 1000 classes avec des quantités substantielles de code, vous ne voulez pas d'un assembly avec une très grande empreinte mémoire. Vous ne voulez pas non plus 1000 assemblages avec une classe. Tout assemblage doit être chargé en mémoire avant que son contenu puisse être exécuté. Vous voulez qu'un assembly contienne un nombre raisonnable de classes interdépendantes. Ainsi, une fois que votre application a chargé un assembly pour obtenir l'une de ses classes, elle obtient gratuitement les autres classes dont l'application aura probablement besoin. La granularité est importante: pas trop grande, pas trop petite, juste bien.
Notez que System.Data.dll rouvre System.Xml et ajoute exactement une classe: XmlDataDocument. Il arrive que cette classe soit utilisée pour interpréter des données relationnelles en tant que document XML. Si votre application utilise uniquement XML, elle n'aura pas besoin de cette classe. Si votre application traite des données relationnelles, cela pourrait être le cas. Ainsi, bien que XmlDataDocument hérite de XmlDocument et se trouve dans l'espace de noms System.Xml, il est packagé dans l'assembly System.Data.dll.
Tout cela est particulièrement important si vous avez une expérience de base avec Java, où il n'y a qu'un seul concept, le package. Dans .NET, il y en a deux, l'assembly et le namespace. Les deux sont orthogonaux. Une assemblée peut évidemment contenir plusieurs espaces de noms. Un assembly peut rouvrir un espace de nommage et en ajouter davantage. En d'autres termes, les types d'un espace de nommage peuvent s'étendre sur plusieurs assemblys.
L'assemblage est un regroupement physique d'unités logiques. L'espace de noms regroupe logiquement les classes.
L'espace de noms peut s'étendre sur plusieurs assemblys