2016-01-14 5 views
5

Zasadniczo mam plik CS definiujący klasę wewnętrzną, a następnie kopiuję do różnych projektów CS. A zespoły tych projektów CS zostaną załadowane do aplikacji. Program wydaje się działać dobrze.Klasy wewnętrzne mające te same przestrzenie nazw, ale w różnych złożeniach?

Jednak posiadanie wielu klas o tej samej nazwie klasy w tej samej przestrzeni nazw sprawia, że ​​czuję się nieswojo, nawet jeśli są one wewnętrzne w każdym zespole.

Czy klasa jest jednoznacznie identyfikowana poprzez nazwę klasy, przestrzeń nazw, a także montaż w AppDomain?

+1

Dlaczego używasz tej samej przestrzeni nazw w różnych złożeniach? To brzmi jakby wymagało kłopotów. –

+0

@NickBailey Używanie tych samych nazw przestrzeni nazw w różnych złożeniach nie jest takie złe, jak 'System.Collections.Generic' zarówno w systemach' System.dll' i 'System.Core.dll'. –

Odpowiedz

8

Czy klasa jest jednoznacznie identyfikowana poprzez nazwę klasy, przestrzeń nazw, a także montaż w AppDomain?

Krótka odpowiedź: tak.

Dłuższa odpowiedź:

Istnieje kilka subtelnych punktów do rozważenia.

Po pierwsze, z perspektywy CLR nie ma czegoś takiego jak "przestrzeń nazw". Nazwa typu łańcucha to System.String w odniesieniu do CLR. Tak więc dokładniej jest powiedzieć, że z perspektywy CLR typ jest jednoznacznie identyfikowany poprzez nazwę i złożenie.

Po drugie, typy mogą być zagnieżdżone. Tak więc typy są faktycznie identyfikowane przez ich nazwę, zawierającą typ (jeśli istnieje) i montaż.

Po trzecie, typy mogą być ogólne. Foo.Bar i Foo.Bar<T> to różne typy. Tak więc typy są identyfikowane przez ich nazwę, zawierającą typ, złożenie i ogólną arność.

Po czwarte, a to jest dziwne, CLR uważa, że ​​typy w zespołach załadowanych Load różnią się od typów w tym samym zespole obciążonym LoadFrom. Możesz skończyć z sytuacjami, w których CLR mówi ci, że typ Foo na pasku zespołu nie jest zgodny z typem Foo na pasku zespołu, a chłopiec, jest to mylące.

1

Podczas gdy rzeczy sprawia, że ​​mylące wszystkie klasy wewnętrzne istnieją tylko w ich odpowiednich zespołów, więc są one autonomiczne i nie będą widoczne dla innych klas w drugim zespole.

Jednak z punktu widzenia konserwacji i prostoty należy go umieścić w górnej części domu, zachowując zadania.

+1

tak, to jest hack. Moje pytanie dotyczy raczej informatyki, a nie inżynierii oprogramowania. Więc CLR nie będzie narzekać we wszystkich scenariuszach? – ZZZ

1

Tak, CLR używa zespołu do identyfikacji każdego typu. Jeśli skompilować prostą aplikację Hello World i spojrzeć na IL:

.method private hidebysig static void Main(string[] args) cil managed 
{ 
    .entrypoint 
    // Code size  13 (0xd) 
    .maxstack 8 
    IL_0000: nop 
    IL_0001: ldstr  "Hello world" 
    IL_0006: call  void [mscorlib]System.Console::WriteLine(string) 
    IL_000b: nop 
    IL_000c: ret 
} // end of method Program::Main 

Można zobaczyć, jak System.Console jest określana poprzez uwzględnienie nazwiska montaż, przestrzeni nazw i klas. Jeśli jednak odwołujesz się do typu w tym samym zespole, nazwa zespołu może być domniemana, np .:

.method private hidebysig static void Main(string[] args) cil managed 
{ 
    .entrypoint 
    // Code size  13 (0xd) 
    .maxstack 8 
    IL_0000: nop 
    IL_0001: ldstr  "Hello world" 
    IL_0006: call  void ConsoleApplication1.Foo::Write(string) 
    IL_000b: nop 
    IL_000c: ret 
} // end of method Program::Main 
Powiązane problemy