Czy C # 4 optymalizuje przestrzenie nazw w sposób, w jaki poprzednie wersje C# nie?

To pytanie jest dla zainteresowania. Pracuję z biblioteką innej firmy i natknąłem się na następującą dokumentację klasy CMS.Security.Dummy:

Nie usuwaj tej klasy - ta klasa uniemożliwia kompilatorowi upuszczanie całej przestrzeni nazw pod. NET 4.0.

Czy ktoś wie lub może spekulować, dlaczego. NET 4 porzuciłby przestrzeń nazw, gdyby Klasa dummy została usunięta?

Ponieważ. NET 4 jest jawnie nazwany w komentarzu kodu źródłowego, zakładam poprzednie wersje C# wykazują zachowanie, które nie wymaga tej atrapy. To tylko spekulacje.

Screen shot

dokumentacja

Dekompilowany Kod Źródłowy

#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();
    }
}
Author: John K, 2012-03-06

3 answers

Mało docenianym faktem jest to, że nie ma czegoś takiego jak "przestrzeń nazw" z punktu widzenia bazowego systemu typów CLR. Zamiast tego, po prostu mówimy, że typ, który zawiera kropki w swojej nazwie, jest "członkiem przestrzeni nazw". logicznie nie ma żadnej różnicy między kodeksem prawnym:

namespace N
{
    class C  {}
}

I Kod psuedo:

class N.C {}

C# zmusza do udawania, że ta przyjemna fikcja jest rzeczywistością, ale to tylko fikcja -- z perspektywa systemu typu CLR, oczywiście. Z punktu widzenia kompilatora C#, przestrzenie nazw są oczywiście "prawdziwe". Po prostu nie odpowiadają nic w metadanych innych niż część nazwy typu.

W skrócie: jeśli tworzysz asemblację z "pustą" przestrzenią nazw, to" przestrzeń nazw " w ogóle nie istnieje w skompilowanym pliku binarnym. "Przestrzeń nazw" pojawia się tylko wtedy, gdy w bibliotece znajduje się typ, który ma kropki w nazwie.

Teraz, dlaczego miałbyś dbając o to, aby "pusta" przestrzeń nazw była obecna w postaci binarnej, nie mam pojęcia.

Zakładam, że poprzednie wersje C# wykazują zachowania, które nie wymagają tej atrapy

Nie. Każda wersja C# od 1.0 wyrzuca puste przestrzenie nazw.
 90
Author: Eric Lippert,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-03-05 22:22:41

Biorąc pod uwagę, że przestrzeń nazw nie zawiera żadnych członków (bez tej klasy), nie jestem pewien, czy w tym momencie istnieje nawet koncepcja przestrzeni nazw... i tak nie spodziewam się, że się przyda.

Próbowałem odtworzyć to za pomocą kompilatora C # 2 i nie widzę żadnego śladu pustej przestrzeni nazw w IL.

 23
Author: Jon Skeet,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-03-05 21:45:21

Jedyną częściowo związaną kwestią, o której myślę, jest to, że podczas kompilacji projektu w msbuild, pośrednie odniesienia nie zawsze są kopiowane do katalogu bin bieżącej aplikacji. Jeśli Biblioteka B pośrednio odwołuje się do biblioteki A, A biblioteka C odwołuje się tylko do B, to wyjście biblioteki a nie musi być skopiowane do folderu bin podczas kompilacji biblioteki C. w przeszłości używałem referencji pola null NA klasie, aby upewnić się, że zależność jest jawna i wyjście jest poprawnie wdrożone. Maybe the oryginalni deweloperzy doświadczyli czegoś podobnego i to było ich rozwiązanie?

 7
Author: Chris,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-03-05 21:50:25