Kod czystej i zweryfikowania (C + +/ CLI)
Podczas programowania .NET, Visual C++ obsługuje tworzenie trzy różne typy składników i aplikacji: mieszane, czysty i możliwe do zweryfikowania.Wszystkie trzy są dostępne za pośrednictwem / CLR (kompilacja wspólnej Language Runtime) opcję kompilatora.
Uwagi
Aby uzyskać więcej informacji na temat możliwych do sprawdzenia zestawów zobacz:
Porównanie funkcji mieszanych, czysty i zweryfikowania (C + +/ CLI)
Za pomocą zestawów zweryfikowania z programem SQL Server (C + +/ CLI)
Najważniejsze wskazówki dotyczące zabezpieczeń dla języka C++
Konwertowanie projektów z trybu mieszanego do czystego Intermediate Language
Mieszane (/ clr)
Mieszane zestawów (skompilowane z /clr), zawierają zarówno niezarządzanych i zarządzanych części, co umożliwia korzystanie z funkcji .NET, ale nadal zawiera kod niezarządzany.Dzięki temu aplikacji i składników, należy zaktualizować korzystać z funkcji .NET bez konieczności ponownego napisania całego projektu.Za pomocą języka Visual C++ mieszać kod zarządzany i niezarządzany w ten sposób nazywa C ++ Interop.Aby uzyskać więcej informacji, zobacz Mieszane (macierzystych i zarządzanych) i Macierzysty i.NET interoperacyjności.
Czysty (/ clr: pure)
Czyste zestawy (skompilowane z /clr:pure) mogą zawierać oba typy danych macierzystych i zarządzanych, ale tylko zarządzane funkcje.Podobnie jak mieszanych zestawów, czystych zestawów umożliwiają współdziałania z macierzystego dll poprzez P/Invoke (zobacz Za pomocą jawnego PInvoke w C++ (atrybut DllImport)), ale nie są dostępne funkcje C ++ Interop.Ponadto, czystych zestawów nie można eksportować funkcje, które są można wywoływać ze macierzystych funkcji, ponieważ używają punktów wejścia w czysty zebranie __clrcall konwencji wywoływania.
.gif "85344whh.collapse_all(pl-pl,VS.110).gif")
Zalety/CLR: pure
Lepszą wydajność: Ponieważ czystych zestawów zawierają tylko MSIL, nie ma żadnych funkcji macierzystego, a zatem żadnych zarządzanych/niezarządzanych przejść są niezbędne.(Wywołania funkcji za pośrednictwem P/Invoke są wyjątkiem tej zasady).
Świadomość elementu AppDomain: Zarządzanej funkcji i typów danych CLR istnieje wewnątrz Application Domains, które wpływają na ich widoczność i dostępności.Czyste zestawy są świadomi domeny (__declspec (elementu AppDomain) jest implikowane dla każdego typu) tak, aby dostęp do ich typy i funkcje z innych składników .NET jest łatwiejsze i bezpieczniejsze.W rezultacie czystych zestawów łatwiej współdziałać z innymi składnikami systemu .NET niż mieszanych zestawów.
Ładowanie na dysk non: czystych zestawów może być załadowany w pamięci i nawet strumieniowo.Jest to istotne dla przy użyciu zestawów .NET jako procedur przechowywanych.To różni się od mieszanych zestawów, które ze względu na zależność od Windows ładowanie mechanizmy, musi istnieć na dysku w celu wykonania.
Odbicie: To nie można odzwierciedlać przestrzeni mieszanych pliki wykonywalne, czystych zestawów przewidują wsparcie Pełne odbicie.Aby uzyskać więcej informacji, zobacz Odbicie (C + +/ CLI).
Możliwości kontroli hosta: Ponieważ czystych zestawów zawierają tylko MSIL, zachowują sposób bardziej przewidywalny i elastycznie niż mieszane zestawów używanych w aplikacjach obsługujących środowisko CLR i jego zachowanie domyślne.
Ograniczenia/CLR: pure
W tej sekcji omówiono funkcje nie są obecnie obsługiwane przez /clr:pure.
Nie można wywołać czystych zestawów przez funkcje niezarządzanego.Dlatego czystych zestawów nie mogą implementować interfejsów COM lub narażać rodzimych wywołań zwrotnych.Czystych zestawów nie można wyeksportować funkcji za pomocą __declspec(dllexport) lub.Pliki DEF.Ponadto funkcje zadeklarowane z Konwencją __clrcall nie można zaimportować za pośrednictwem __declspec(dllimport).Funkcje w moduły macierzyste mogą być wywoływane z czystego zestawu, ale czystych zestawów nie może ujawnić nieopłacona w trybie macierzystym funkcje, a więc narażając funkcjonalność w czysty zebranie muszą być wykonywane przez zarządzanej funkcji w zestawie mieszanym.Aby uzyskać więcej informacji, zobacz Jak: Migrowanie do/CLR: czysty (C + +/ CLI).
Biblioteki ATL i MFC nie są obsługiwane przez kompilacji w trybie wyłącznie w programie Visual C++.
Czysty.netmodules nie są akceptowane jako dane wejściowe do programu łączącego Visual C++.Jednak pliki .obj czystego będą akceptowane przez program łączący, a pliki .obj zawierają nadzbiór informacji zawartych w netmodules.Aby uzyskać więcej informacji, zobacz pliki .netmodule jako dane wejściowe Linker.
Obsługa kompilatora COM (#import) nie jest obsługiwana, jak to wprowadzi niezarządzanego instrukcje w czysty zebranie.
Zmiennoprzecinkowych opcje wyrównania i obsługi wyjątków nie są regulowane dla czystych zestawów.W rezultacie nie można użyć __declspec(align).To czyni niektóre pliki nagłówkowe, takich jak fpieee.h, niezgodne z/CLR: czysty.
Funkcja GetLastError w PSDK może dać niezdefiniowane zachowanie podczas kompilowania z /clr:pure.
Możliwe do zweryfikowania (/ clr:safe)
/clr:safe Opcję kompilatora generuje zestawów możliwych do sprawdzenia, jak makra napisane w języku Visual Basic i C#, zgodne z wymaganiami, które pozwalają common language runtime (CLR), aby zagwarantować, że kod nie narusza bieżące ustawienia zabezpieczeń.Na przykład jeśli ustawienia zabezpieczeń uniemożliwiają składnik od pisania na dysku, środowisko CLR można określić, czy składnik możliwe do zweryfikowania spełnia to kryterium, przed wykonaniem kodu.Brak obsługi CRT zestawów możliwe do zweryfikowania.(CRT obsługa jest dostępna do czystych zestawów przy użyciu czystego MSIL wersji biblioteki C Runtime).
Możliwe do zweryfikowania zestawów oferują następujące zalety w porównaniu do czystych i mieszanych zestawów:
Zwiększone bezpieczeństwo.
Niektórych przypadkach jest konieczne go (na przykład składniki SQL).
Coraz bardziej będzie wymagać kolejnych wersjach systemu Windows, składniki i aplikacje nie będą możliwe do zweryfikowania.
Jedną z wad jest, że nie są dostępne funkcje współdziałania C++.Możliwe do zweryfikowania zestawów nie może zawierać żadnych funkcji niezarządzanych lub macierzyste typy danych, nawet jeśli nie są one wywoływane przez kod zarządzany.
Mimo użycia słowa "bezpieczne", kompilowania aplikacji z /clr:safe nie oznacza, nie są wolne od błędów; po prostu oznacza, że środowisko CLR można zweryfikować ustawienia zabezpieczeń w czasie wykonywania.
Niezależnie od typu zestawu połączeń z zestawów zarządzanych do macierzystych bibliotek DLL za pomocą P/Invoke skompiluje, ale może się nie powieść w czasie wykonywania, w zależności od ustawień zabezpieczeń.
[!UWAGA]
Istnieje jeden scenariusz kodowania, która przemija kompilator, a w efekcie w zespole niemożliwy do sprawdzenia: wywołanie funkcji wirtualnych za pośrednictwem instancji obiektu za pomocą operator zakres rozpoznawania.Na przykład: MyObj -> A::VirtualFunction();.