Le C# 4 optimise-t-il l'élimination des espaces de noms d'une manière que les versions précédentes du C# ne faisaient pas ?

Question

Cette question est posée à titre d'intérêt. Je travaille avec une bibliothèque tierce et je suis tombé sur la documentation suivante sur une CMS.Security.Dummy classe :

NE PAS SUPPRIMER CETTE CLASSE - Cette classe empêche le compilateur de de supprimer l'espace de nom entier sous .NET 4.0.

Quelqu'un sait-il, ou peut-il spéculer sur la raison pour laquelle .NET 4 supprimerait l'espace de nom si la classe factice était supprimée ?

Comme .NET 4 est explicitement nommé dans le commentaire du code source, je suppose que les versions précédentes de C# ont un comportement qui ne nécessite pas cette classe factice. Mais c'est purement spéculatif.

Capture d'écran

Code source décompilé

#region Assembly CMS.SettingsProvider.dll, v4.0.30319
// ...\solution\wwwroot\Bin\CMS.SettingsProvider.dll
#endregion

using System;

namespace CMS.Security
{
    // Summary:
    //     DO NOT DELETE THIS CLASS - This class prevents the compiler from dropping
    //     entire namespace under .NET 4.0.
    public class Dummy
    {
        // Summary:
        //     DO NOT DELETE THIS CLASS - This class prevents the compiler from dropping
        //     entire namespace under .NET 4.0.
        public Dummy();
    }
}

Answer 1

Un fait peu apprécié est qu'il n'existe pas d'"espace de noms" du point de vue du système de type CLR sous-jacent. Il s'agit plutôt d'un convention que nous disons qu'un type qui contient des points dans son nom est "membre d'un espace de nom". Logiquement il n'y a pas de différence du tout entre le code juridique :

namespace N
{
    class C  {}
}

et le psuedo-code :

class N.C {}

Le C# vous oblige à faire comme si cette agréable fiction était la réalité, mais ce n'est qu'une fiction du point de vue du système de type CLR, bien sûr. Du point de vue du compilateur C#, les espaces de noms sont bien sûr "réels". Ils ne correspondent simplement à rien dans les métadonnées, si ce n'est à une partie du nom d'un type.

En bref : si vous créez un assemblage avec un espace de noms "vide", l'espace de noms n'existe pas du tout dans le binaire compilé. Un "espace de noms" n'existe que lorsqu'il y a un type dans la bibliothèque qui a des périodes dans son nom.

Je n'ai aucune idée de la raison pour laquelle vous souhaitez vous assurer qu'un espace de noms "vide" est présent dans la forme binaire.

Je suppose que les versions précédentes de C# ont un comportement qui ne nécessite pas cette classe factice.

Nope. Chaque version de C# depuis la 1.0 rejette les espaces de noms vides.

Answer 2

Étant donné que l'espace de nom ne contient pas de membres (sans cette classe), je ne suis pas sûr qu'il y ait même l'option concept d'un espace de nom à ce stade... et je ne m'attendrais pas à ce que ce soit utile de toute façon.

Je viens d'essayer de reproduire ce problème avec le compilateur C# 2, et je ne vois aucune trace d'un espace de nom vide dans l'IL.

Answer 3

Le seul problème semi-relié auquel je peux penser est que lors de la compilation d'un projet dans msbuild, les références indirectes ne sont pas toujours copiées dans le répertoire bin de l'application courante. Si la bibliothèque B fait indirectement référence à la bibliothèque A et que la bibliothèque C ne fait référence qu'à B, la sortie de la bibliothèque A ne sera pas nécessairement copiée dans le répertoire bin lors de la compilation de la bibliothèque C. Dans le passé, j'ai utilisé une référence de champ nul sur une classe pour m'assurer que la dépendance est explicite et que la sortie est déployée correctement. Peut-être que les développeurs d'origine ont connu quelque chose de similaire et que c'était leur solution ?