C#-kompilatoralternativ som styr kompilatorns utdata
Följande alternativ styr kompilatorns utdatagenerering.
MSBuild | csc.exe | beskrivning |
---|---|---|
DokumentationFil | -doc: |
Generera XML-dokumentfil från /// kommentarer. |
OutputAssembly | -out: |
Ange sammansättningsfilen för utdata. |
PlatformTarget | -platform: |
Ange målplattformens CPU. |
ProduceReferenceAssembly | -refout: |
Generera en referenssammansättning. |
TargetType | -target: |
Ange typ av utdatasammansättning. |
DokumentationFil
Med alternativet DocumentationFile kan du placera dokumentationskommentar i en XML-fil. Mer information om hur du dokumenterar koden finns i Rekommenderade taggar för dokumentationskommentare. Värdet anger sökvägen till XML-utdatafilen. XML-filen innehåller kommentarerna i kompileringsfilens källkodsfiler.
<DocumentationFile>path/to/file.xml</DocumentationFile>
Källkodsfilen som innehåller huvud- eller toppnivåinstruktioner matas först ut i XML-koden. Du vill ofta använda den genererade .xml-filen med IntelliSense. Det .xml filnamnet måste vara samma som sammansättningsnamnet. Filen .xml måste finnas i samma katalog som sammansättningen. När sammansättningen refereras till i ett Visual Studio-projekt hittas även .xml-filen. Mer information om hur du genererar kodkommentare finns i Ange kodkommentare. Om du inte kompilerar med <TargetType:Module>
innehåller <assembly>
file
och </assembly>
taggar som anger namnet på filen som innehåller sammansättningsmanifestet för utdatafilen. Exempel finns i Så här använder du XML-dokumentationsfunktionerna.
Kommentar
Alternativet DocumentationFile gäller för alla filer i projektet. Om du vill inaktivera varningar relaterade till dokumentationskommenterar för en specifik fil eller ett visst kodavsnitt använder du #pragma varning.
Det här alternativet kan användas i alla .NET SDK-projekt. Mer information finns i Egenskapen DocumentationFile.
OutputAssembly
Alternativet OutputAssembly anger namnet på utdatafilen. Utdatasökvägen anger mappen där kompilatorns utdata placeras.
<OutputAssembly>folder</OutputAssembly>
Ange det fullständiga namnet och tillägget för den fil som du vill skapa. Om du inte anger namnet på utdatafilen använder MSBuild namnet på projektet för att ange namnet på utdatasammansättningen. Gamla formatprojekt använder följande regler:
- En .exe tar sitt namn från källkodsfilen som innehåller metoden eller toppnivåinstruktionerna
Main
. - En .dll eller .netmodule tar sitt namn från den första källkodsfilen.
Alla moduler som skapas som en del av en kompilering blir filer som associeras med alla sammansättningar som också skapas i kompilering. Använd ildasm.exe för att visa sammansättningsmanifestet för att se de associerade filerna.
Alternativet OutputAssembly-kompilator krävs för att ett exe ska vara målet för en vänsammansättning.
PlatformTarget
Anger vilken version av CLR som kan köra sammansättningen.
<PlatformTarget>anycpu</PlatformTarget>
- anycpu (standard) kompilerar sammansättningen så att den körs på valfri plattform. Ditt program körs som en 64-bitarsprocess när det är möjligt och återgår till 32-bitars när endast det läget är tillgängligt.
- anycpu32bitpreferred kompilerar sammansättningen för att köras på valfri plattform. Programmet körs i 32-bitarsläge på system som stöder både 64- och 32-bitarsprogram. Du kan bara ange det här alternativet för projekt som är avsedda för .NET Framework 4.5 eller senare.
- ARM kompilerar sammansättningen för att köras på en dator som har en ARM-processor (Advanced RISC Machine).
- ARM64 kompilerar sammansättningen så att den körs av 64-bitars CLR på en dator som har en ARM-processor (Advanced RISC Machine) som stöder A64-instruktionsuppsättningen.
- x64 kompilerar din sammansättning som ska köras av 64-bitars CLR på en dator som har stöd för instruktionsuppsättningen AMD64 eller EM64T.
- x86 kompilerar din sammansättning som ska köras av den 32-bitars, x86-kompatibla CLR.
- Itanium kompilerar din sammansättning som ska köras av 64-bitars CLR på en dator med en Itanium-processor.
På ett 64-bitars Windows-operativsystem:
- Sammansättningar som kompilerats med x86 körs på 32-bitars CLR som körs under WOW64.
- En DLL som kompilerats med anycpu körs på samma CLR som den process som den läses in i.
- Körbara filer som kompileras med anycpu körs på 64-bitars CLR.
- Körbara filer som kompilerats med anycpu32bitpreferred körs på 32-bitars CLR.
Inställningen anycpu32bitpreferred är endast giltig för körbara filer (.EXE) och kräver .NET Framework 4.5 eller senare. Mer information om hur du utvecklar ett program som ska köras på ett Windows 64-bitars operativsystem finns i 64-bitarsprogram.
Du anger alternativet PlatformTarget från sidan Skapa egenskaper för projektet i Visual Studio.
Beteendet för anycpu har några ytterligare nyanser i .NET Core- och .NET 5- och senare versioner. När du anger anycpu publicerar du din app och kör den med x86 dotnet.exe
eller x64 dotnet.exe
. För fristående appar paketeras dotnet publish
det körbara steget för att konfigurera RID.
ProduceReferenceAssembly
Alternativet ProduceReferenceAssembly styr om kompilatorn skapar referenssammansättningar.
<ProduceReferenceAssembly>true</ProduceReferenceAssembly>
Referenssammansättningar är en särskild typ av sammansättning som endast innehåller den minsta mängd metadata som krävs för att representera bibliotekets offentliga API-yta. De innehåller deklarationer för alla medlemmar som är viktiga när de refererar till en sammansättning i byggverktyg. Referenssammansättningar utesluter alla medlemsimplementeringar och deklarationer av privata medlemmar. Dessa medlemmar har ingen observerbar inverkan på deras API-kontrakt. Mer information finns i Referenssammansättningar i .NET-guiden.
Alternativen ProduceReferenceAssembly och ProduceOnlyReferenceAssembly utesluter varandra.
Vanligtvis behöver du inte arbeta direkt med referenssammansättningsfiler. Som standard genereras referenssammansättningar i en ref
undermapp för den mellanliggande sökvägen (dvs. obj/ref/
). För att generera dem under utdatakatalogen i stället (d.v.s. bin/ref/
) inställt ProduceReferenceAssemblyInOutDir
på true
i projektet.
.NET SDK 6.0.200 gjorde en ändring som flyttade referenssammansättningar från utdatakatalogen till den mellanliggande katalogen som standard.
TargetType
Alternativet TargetType-kompilator kan anges i något av följande formulär:
- bibliotek: för att skapa ett kodbibliotek. biblioteket är standardvärdet.
- exe: för att skapa en .exe fil.
- modul för att skapa en modul.
- winexe för att skapa ett Windows-program.
- winmdobj för att skapa en mellanliggande .winmdobj-fil .
- appcontainerexe för att skapa en .exe fil för Windows 8.x Store-appar.
Kommentar
För .NET Framework-mål, såvida du inte anger modul, gör det här alternativet att ett .NET Framework-sammansättningsmanifest placeras i en utdatafil. Mer information finns i Sammansättningar i .NET och Vanliga attribut.
<TargetType>library</TargetType>
Kompilatorn skapar bara ett sammansättningsmanifest per kompilering. Information om alla filer i en kompilering placeras i sammansättningsmanifestet. När du skapar flera utdatafiler på kommandoraden kan endast ett sammansättningsmanifest skapas och det måste gå till den första utdatafilen som anges på kommandoraden.
Om du skapar en sammansättning kan du ange att hela eller delar av koden är CLS-kompatibla med CLSCompliantAttribute attributet.
bibliotek
Biblioteksalternativet gör att kompilatorn skapar ett DLL -bibliotek (Dynamic Link Library) i stället för en körbar fil (EXE). DLL:en skapas med tillägget .dll . Om inget annat anges med alternativet OutputAssembly tar utdatafilens namn namnet på den första indatafilen. När du skapar en .dll fil Main
krävs ingen metod.
exe
Exe-alternativet gör att kompilatorn skapar ett körbart (EXE), konsolprogram. Den körbara filen skapas med tillägget .exe. Använd winexe för att skapa ett körbart Windows-program. Om inget annat anges med alternativet OutputAssembly tar utdatafilens namn namnet på den indatafil som innehåller startpunkten (Main-metoden eller toppnivåinstruktionerna). En och endast en startpunkt krävs i källkodsfilerna som kompileras till en .exe fil. Med kompilatoralternativet StartupObject kan du ange vilken klass som innehåller Main
metoden, i de fall där koden har mer än en klass med en Main
metod.
modul
Det här alternativet gör att kompilatorn inte genererar ett sammansättningsmanifest. Som standard har utdatafilen som skapas genom kompilering med det här alternativet ett tillägg av .netmodule. En fil som inte har ett sammansättningsmanifest kan inte läsas in av .NET-körningen. En sådan fil kan dock införlivas i sammansättningsmanifestet för en sammansättning med AddModules. Om fler än en modul skapas i en enda kompilering blir interna typer i en modul tillgängliga för andra moduler i kompilering. När kod i en modul refererar till internal
typer i en annan modul måste båda modulerna införlivas i ett sammansättningsmanifest med AddModules. Det går inte att skapa en modul i Visual Studio-utvecklingsmiljön.
winexe
Alternativet winexe gör att kompilatorn skapar ett körbart (EXE), Windows-program. Den körbara filen skapas med tillägget .exe. Ett Windows-program är ett som tillhandahåller ett användargränssnitt från .NET-biblioteket eller med Windows-API:erna. Använd exe för att skapa ett konsolprogram. Om inget annat anges med alternativet OutputAssembly tar utdatafilens namn namnet på den indatafil som innehåller Main
metoden. En och endast en Main
metod krävs i källkodsfilerna som kompileras till en .exe fil. Med alternativet StartupObject kan du ange vilken klass som innehåller Main
metoden, i fall där koden har mer än en klass med en Main
metod.
winmdobj
Om du använder alternativet winmdobj skapar kompilatorn en mellanliggande .winmdobj-fil som du kan konvertera till en binär Windows Runtime-fil (.winmd). . winmd-filen kan sedan användas av JavaScript- och C++-program, förutom hanterade språkprogram.
Winmdobj-inställningen signalerar till kompilatorn att en mellanliggande modul krävs. . winmdobj-filen kan sedan matas via WinMDExp exportverktyget för att skapa en Windows-metadatafil (.winmd). . winmd-filen innehåller både koden från det ursprungliga biblioteket och WinMD-metadata som används av JavaScript eller C++ och av Windows Runtime. Utdata från en fil som kompileras med hjälp av kompilatoralternativet winmdobj används endast som indata för exportverktyget WimMDExp. Själva .winmdobj-filen refereras inte direkt. Om du inte använder alternativet OutputAssembly tar utdatafilens namn namnet på den första indatafilen. En Main
metod krävs inte.
appcontainerexe
Om du använder kompileringsalternativet appcontainerexe skapar kompilatorn en körbar Windows-fil (.exe) som måste köras i en appcontainer. Det här alternativet motsvarar -target:winexe men är utformat för Windows 8.x Store-appar.
För att kräva att appen körs i en appcontainer anger det här alternativet lite i PE-filen (Portable Executable ). När den biten har angetts uppstår ett fel om metoden CreateProcess försöker starta den körbara filen utanför en appcontainer. Om du inte använder alternativet OutputAssembly tar utdatafilens namn namnet på den indatafil som innehåller Main
metoden.