Wybieranie formatu plików wejściowych .netmodule
Plik .obj MSIL (skompilowane z /CLR) może również służyć jako plik .netmodule. pliki .obj zawierają metadane i symbole macierzystego. .netmodules zawiera tylko metadane.
Można przekazać pliku Intermediate .obj do innych kompilatora Visual Studio za pomocą opcji kompilatora /addmodule (ale należy pamiętać, że plik .obj staje się częścią Wynikowy zestaw i musi być dostarczany z zestawu). Na przykład Visual C# i Visual Basic mają opcję kompilatora /addmodule.
[!UWAGA]
W większości przypadków będziesz musiał przejść linker pliku .obj kompilacji, że utworzony moduł .net. Jedynym wyjątkiem jest, jeśli .netmodule został utworzony za pomocą /CLR: pure. Przekazywanie pliku .dll lub .netmodule MSIL moduł do linker może spowodować LNK1107.
pliki .obj, wraz z ich .h skojarzone pliki, które można odwołać się za pomocą #include w źródle, umożliwiają aplikacjom C++ zużywają rodzimych typów w module, natomiast w pliku .netmodule, typy zarządzane mogą być spożywane przez aplikacji C++. Jeśli podczas próby przekazania pliku .obj do #using, informacji na temat typów macierzystego nie będą dostępne; # zamiast include plik .h pliku .obj.
Inne kompilatory Visual Studio mogą spożywać tylko typy zarządzane z poziomu modułu.
Umożliwia określenie, czy należy użyć .netmodule lub .obj pliku jako dane wejściowe modułu Visual C++ linker następujące:
Jeśli jest konstruowany z kompilatorem Visual Studio innych niż Visual C++, produkcji .netmodule i użyć .netmodule jako dane wejściowe do linker.
Jeśli używasz kompilator języka Visual C++ do produkcji modułów i jeśli będzie używana przy module lub modułach zbudować coś innego niż biblioteki korzystać z plików .obj produkowane przez kompilator jako dane wejściowe modułu linker; nie należy używać pliku .netmodule jako dane wejściowe.
Jeśli moduły będą stosowane do budowy biblioteki (nie zarządzanego) w trybie macierzystym, użyj pliki .obj jako dane wejściowe modułu linker i generowanie pliku .lib biblioteki.
Jeśli moduły będą używane do budowy zarządzane biblioteki, a wszystkie dane wejściowe modułu linker będzie sprawdzalne (wyprodukowane z /clr:safe), użyj pliki .obj jako dane wejściowe modułu linker i wygenerować .dll (Zgromadzenie) lub plik biblioteki .netmodule (moduł).
Jeśli moduły będą używane do budowy zarządzane biblioteki, a wszystkie dane wejściowe modułu linker będą produkowane z/CLR: pure lub /clr:safe, użyj pliki .obj jako dane wejściowe modułu linker i generować .dll (Zgromadzenie) lub .netmodule (moduł), jeśli chcesz udostępnić typy zarządzane z biblioteki. Jeśli chcesz udostępnić typy zarządzane z biblioteki, a jeśli chcesz także aplikacji C++ zużyje rodzimych typów w bibliotece, biblioteki będzie się składał z pliki .obj dla modułów składowych bibliotek (również chcesz statek plików .h dla każdego modułu, więc można się odwoływać z #include z kodu źródłowego).
Jeśli moduły będą używane do budowy zarządzane biblioteki i jeden lub więcej modułów danych wejściowych linker będą produkowane z tylko/CLR, użyj pliki .obj jako dane wejściowe modułu linker i generowanie .dll (zestawu). Jeśli chcesz udostępnić typy zarządzane z biblioteki, a jeśli chcesz także aplikacji C++ zużyje rodzimych typów w bibliotece, biblioteki będzie się składał z pliki .obj dla modułów składowych bibliotek (również chcesz statek plików .h dla każdego modułu, więc można się odwoływać z #include z kodu źródłowego).