.netmodule filer som indata för länkare
link.exe accepterar MSIL-.obj och .netmodule filer som indata. Utdatafilen som skapas av länkaren är en sammansättning eller en .netmodule fil utan körningsberoende för någon av de .obj- eller .netmodule filer som angavs i länkaren.
Anmärkningar
.netmodule filer skapas av MSVC-kompilatorn med /LN (Skapa MSIL-modul) eller av länkaren med /NOASSEMBLY (Skapa en MSIL-modul).
.obj filer skapas alltid i en C++-kompilering. För andra Visual Studio-kompilatorer använder du alternativet /target:module compiler.
Länkaren måste skickas .obj-filen från C++-kompileringen som skapade .netmodule. Det går inte längre att skicka in en .netmodule eftersom /clr:pure och /clr:safe kompilatoralternativ är inaktuella i Visual Studio 2015 och stöds inte i Visual Studio 2017 och senare.
Information om hur du anropar länkaren från kommandoraden finns i Linker-kommandoradssyntax och Använd MSVC-verktygsuppsättningen från kommandoraden.
Att skicka en .netmodule- eller .dll-fil till den länkare som kompilerades av MSVC-kompilatorn med /clr kan resultera i ett länkfel. Mer information finns i Välja formatet för .netmodule indatafiler.
Länkaren accepterar både interna .obj-filer och MSIL-.obj filer som kompilerats med /clr. Du kan skicka blandade .obj filer i samma version. Den resulterande utdatafilens standardverifierbarhet är densamma som den lägsta indatamodulens verifierbarhet.
Du kan ändra ett program som består av två eller flera sammansättningar så att det finns i en sammansättning. Kompilera om sammansättningskällorna och länka sedan .obj filer eller .netmodule filer för att skapa en enda sammansättning.
Ange en startpunkt med /ENTRY (startpunktssymbol) när du skapar en körbar avbildning.
När du länkar med en MSIL-.obj- eller .netmodule-fil använder du /LTCG (länktidskodgenerering), annars när länkaren stöter på MSIL-.obj eller .netmodulestartar den om länken med /LTCG. Du ser ett informationsmeddelande om att länken startas om. Du kan ignorera det här meddelandet, men för att förbättra linkerprestanda anger du uttryckligen /LTCG.
MSIL-.obj- eller .netmodule-filer kan också skickas till cl.exe.
Indata för MSIL-.obj eller .netmodule filer kan inte ha inbäddade resurser. Bädda in resurser i en utdatamodul eller sammansättningsfil med hjälp av alternativet /ASSEMBLYRESOURCE (Bädda in en hanterad resurs) länkare. Du kan också använda kompilatoralternativet /resource i andra Visual Studio-kompilatorer.
Exempel
I C++-kod anropas det catch blocket för motsvarande try för ett undantag som inte ärSystem. Men som standard omsluter CLR icke-System undantag med RuntimeWrappedException. När en sammansättning skapas från C++ och icke-C++-moduler, och du vill att ett catch-block i C++-kod ska anropas från motsvarande try-sats när try-blocket genererar ett undantag som inteSystem, måste du lägga till attributet [assembly:System::Runtime::CompilerServices::RuntimeCompatibility(WrapNonExceptionThrows=false)] i källkoden för moduler som inte är C++-moduler.
// MSIL_linking.cpp
// compile with: /c /clr
value struct V {};
ref struct MCPP {
static void Test() {
try {
throw (gcnew V);
}
catch (V ^) {
System::Console::WriteLine("caught non System exception in C++ source code file");
}
}
};
/*
int main() {
MCPP::Test();
}
*/
Genom att ändra Boolean värdet för attributet WrapNonExceptionThrows ändrar du C++-kodens möjlighet att fånga ett undantag som inteSystem.
// MSIL_linking_2.cs
// compile with: /target:module /addmodule:MSIL_linking.obj
// post-build command: link /LTCG MSIL_linking.obj MSIL_linking_2.netmodule /entry:MLinkTest.Main /out:MSIL_linking_2.exe /subsystem:console
using System.Runtime.CompilerServices;
// enable non System exceptions
[assembly:RuntimeCompatibility(WrapNonExceptionThrows=false)]
class MLinkTest {
public static void Main() {
try {
MCPP.Test();
}
catch (RuntimeWrappedException) {
System.Console.WriteLine("caught a wrapped exception in C#");
}
}
}
caught non System exception in C++ source code file