2013-06-11 9 views
7

Dokumentacja Microsoft deklaruje, że , .NET ma więcej niż jeden Hosty Runtime do obsługi i wykonywania kodu naszej aplikacji, moje pytanie brzmi: Skąd mogę wiedzieć, które hosty środowiska wykonawczego hostów Microsoft, hostuje mój kod.Skąd mogę wiedzieć, który Host środowiska wykonawczego jest aktualnie uruchamiany przez mój kod?

Używam języka C# do opracowania biblioteki klasy DLL, która może być używana i/lub hostowana przez różne hosty środowiska wykonawczego, dlatego muszę wiedzieć, który host środowiska wykonawczego hostuje teraz mój kod, aby spełnić określone warunki.

+0

Czy sugerujesz, że "udostępniony" kod DLL środowiska wykonawczego może korzystać z nowszej wersji środowiska .net Runtime niż kod, który wywołuje ten kod? Czy czytanie/zapisywanie do pliku * .config to jedyny problem? –

Odpowiedz

0

Interfejs API hosta .NET Framework 4 udostępnia funkcję CLRCreateInstance, która może zwrócić interfejs ICLRMetaHost. Następnie możesz wywołać metodę GetRuntime na tym interfejsie, aby uzyskać określony interfejs ICLRRuntimeInfo, biorąc pod uwagę konkretną wersję CLR. Ta procedura zastępuje metodę CorBindToRuntimeEx używaną przez interfejs API hosta .NET Framework 2.0.

Interfejs API hosta .NET Framework w wersji 2.0 udostępnia funkcję CorBindToRuntimeEx służącą do inicjowania środowiska wykonawczego. Możesz wybrać wersję środowiska uruchomieniowego do załadowania, ale proces może obsługiwać tylko jedną wersję. Jeśli załadowano wersję 2.0, 3.0 lub 3.5, funkcja zwraca interfejs ICLRRuntimeHost, który służy do uruchamiania środowiska wykonawczego i wykonywania zarządzanego kodu.

Źródło: http://msdn.microsoft.com/en-us/library/dd380850.aspx

+0

Jak mogę wywołać te funkcje i czy istnieje inne prostsze podejście? –

+0

Po dogłębnym wykryciu MSDN i google doszedłem do wniosku, że interfejsy dostarczone przez MSCorEE.dll nie zawierają metody definiowania nazwy hosta lub wersji do CLR, interfejsy zapewniają tylko funkcje hostingu i zarządzania CLR, One peace of informacje, które można poznać za pomocą tych interfejsów, to wersja środowiska CLR z uruchomionym kodem NIE host obsługujący sam CLR. –

+0

Proszę sprawdzić http://msdn.microsoft.com/en-us/library/a51xd4ze.aspx, aby dokładnie sprawdzić –

1

Jest całkiem łatwy sposób określić aktualną wersję runtime CLR. Tak się składa, że ​​Environment.Version zwróci inną wersję, jeśli twój kod jest aktualnie uruchamiany w innym CLR z powodu wykonania SxS (Side-by-Side).

Aby zobaczyć, jak to działa w praktyce w aplikacji, która może mieć jednocześnie dwa środowiska wykonawcze, sprawdź numer this article on Demonstrating Side by Side execution.

if(Environment.Version.StartsWith("2.0")) 
    System.Console.WriteLine("Inside .NET CLR 2.0"); 
else if(Environment.Version.StartsWith("4.0")) 
    System.Console.WriteLine("Inside .NET CLR 4.0"); 
else 
    System.Console.WriteLine("Unknown .NET version"); 

Należy pamiętać, że program ładujący .NET 2.0 załaduje najnowszą wersję środowiska CLR .NET 2.0, która będzie w większości przypadków .NET 3.5. Nie jest możliwe uruchamianie różnych wersji programu .NET 2.0 obok siebie w jednym procesie. Nie jest to również możliwe to run .NET 1.0 or .NET 1.1 side by side with .NET 2.0 in .NET 4.0 (możliwe jest jednak uruchomienie 1.0 lub 1.1 obok siebie w .NET 4.0).

Powiązane problemy