C#-kompilatoralternativ som anger indata

Följande alternativ styr kompilatorindata. Den nya MSBuild-syntaxen visas i Fetstil. Den äldre csc.exe syntaxen visas i code style.

• Referenser / -reference eller -references: Referensmetadata från den angivna sammansättningsfilen eller filerna.
• AddModules-addmodule / : Lägg till en modul (skapad med target:module i den här sammansättningen.)
• EmbedInteropTypes: Bädda in metadata från de angivna interop-sammansättningsfilerna / -link.

Referenser

Alternativet Referenser gör att kompilatorn importerar information av offentlig typ i den angivna filen till det aktuella projektet, så att du kan referera till metadata från de angivna sammansättningsfilerna.

<Reference Include="filename" />

filename är namnet på en fil som innehåller ett sammansättningsmanifest. Om du vill importera mer än en fil inkluderar du ett separat referenselement för varje fil. Du kan definiera ett alias som ett underordnat element i referenselementet :

<Reference Include="filename.dll">
  <Aliases>LS</Aliases>
</Reference>

I föregående exempel LS är den giltiga C#-identifieraren som representerar ett rotnamnområde som innehåller alla namnområden i sammansättningen filename.dll. Filerna som du importerar måste innehålla ett manifest. Använd AdditionalLibPaths för att ange den katalog där en eller flera av sammansättningsreferenserna finns. I avsnittet AdditionalLibPaths beskrivs också de kataloger där kompilatorn söker efter sammansättningar. För att kompilatorn ska kunna identifiera en typ i en sammansättning, och inte i en modul, måste den tvingas att matcha typen, vilket du kan göra genom att definiera en instans av typen. Det finns andra sätt att lösa typnamn i en sammansättning för kompilatorn: om du till exempel ärver från en typ i en sammansättning identifieras typnamnet av kompilatorn. Ibland är det nödvändigt att referera till två olika versioner av samma komponent inifrån en sammansättning. Det gör du genom att använda aliaselementet i elementet Referenser för varje fil för att skilja mellan de två filerna. Det här aliaset används som en kvalificerare för komponentnamnet och matchas mot komponenten i en av filerna.

Kommentar

I Visual Studio använder du kommandot Lägg till referens . Mer information finns i Så här lägger du till eller tar bort referenser med hjälp av referenshanteraren.

AddModules

Det här alternativet lägger till en modul som skapades med växeln <TargetType>module</TargetType> till den aktuella kompileringen:

<AddModule Include=file1 />
<AddModule Include=file2 />

file2 Där fileär utdatafiler som innehåller metadata. Filen får inte innehålla ett sammansättningsmanifest. Om du vill importera mer än en fil separerar du filnamn med antingen ett kommatecken eller semikolon. Alla moduler som läggs till med AddModules måste finnas i samma katalog som utdatafilen vid körning. Du kan alltså ange en modul i valfri katalog vid kompileringstillfället, men modulen måste finnas i programkatalogen vid körning. Om modulen inte finns i programkatalogen vid körning får du en TypeLoadException. file får inte innehålla en sammansättning. Om utdatafilen till exempel skapades med targettype-alternativet för modulen kan dess metadata importeras med AddModules.

Om utdatafilen skapades med ett annat TargetType-alternativ än modulen kan dess metadata inte importeras med AddModules utan kan importeras med alternativet Referenser.

EmbedInteropTypes

Gör att kompilatorn gör COM-typinformation i de angivna sammansättningarna tillgängliga för det projekt som du för närvarande kompilerar.

<References>
  <EmbedInteropTypes>file1;file2;file3</EmbedInteropTypes>
</References>

Var file1;file2;file3 finns en semikolonavgränsad lista över sammansättningsfilnamn. Om filnamnet innehåller ett blanksteg omger du namnet inom citattecken. Med alternativet EmbedInteropTypes kan du distribuera ett program med inbäddad typinformation. Programmet kan sedan använda typer i en körningssammansättning som implementerar information om inbäddade typer utan att kräva en referens till körningssammansättningen. Om olika versioner av runtime-sammansättningen publiceras kan programmet som innehåller den inbäddade typinformationen fungera med de olika versionerna utan att behöva kompileras om. Ett exempel finns i Genomgång: Bädda in typer från hanterade sammansättningar.

Det är särskilt användbart att använda alternativet EmbedInteropTypes när du arbetar med COM-interop. Du kan bädda in COM-typer så att programmet inte längre kräver en primär interop-sammansättning (PIA) på måldatorn. Alternativet EmbedInteropTypes instruerar kompilatorn att bädda in COM-typinformationen från den refererade interopsammansättningen i den resulterande kompilerade koden. COM-typen identifieras av CLSID-värdet (GUID). Därför kan programmet köras på en måldator som har installerat samma COM-typer med samma CLSID-värden. Program som automatiserar Microsoft Office är ett bra exempel. Eftersom program som Office vanligtvis har samma CLSID-värde i olika versioner kan ditt program använda de refererade COM-typerna så länge .NET Framework 4 eller senare installeras på måldatorn och programmet använder metoder, egenskaper eller händelser som ingår i de refererade COM-typerna. Alternativet EmbedInteropTypes bäddar bara in gränssnitt, strukturer och ombud. Inbäddning av COM-klasser stöds inte.

Kommentar

När du skapar en instans av en inbäddad COM-typ i koden måste du skapa instansen med hjälp av lämpligt gränssnitt. Försök att skapa en instans av en inbäddad COM-typ med hjälp av CoClass orsakar ett fel.

Precis som kompilatoralternativet Referenser använder kompilatoralternativet EmbedInteropTypes svarsfilen Csc.rsp, som refererar till ofta använda .NET-sammansättningar. Använd kompilatoralternativet NoConfig om du inte vill att kompilatorn ska använda Csc.rsp-filen.

// The following code causes an error if ISampleInterface is an embedded interop type.
ISampleInterface<SampleType> sample;

Typer som har en allmän parameter vars typ är inbäddad från en interop-sammansättning kan inte användas om den typen kommer från en extern sammansättning. Den här begränsningen gäller inte för gränssnitt. Tänk till exempel på det Range gränssnitt som definieras i Microsoft.Office.Interop.Excel sammansättningen. Om ett bibliotek bäddar in interop-typer från Microsoft.Office.Interop.Excel sammansättningen och exponerar en metod som returnerar en allmän typ som har en parameter vars typ är Range gränssnittet, måste metoden returnera ett allmänt gränssnitt, enligt följande kodexempel.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Office.Interop.Excel;

public class Utility
{
    // The following code causes an error when called by a client assembly.
    public List<Range> GetRange1()
    {
        return null;
    }

    // The following code is valid for calls from a client assembly.
    public IList<Range> GetRange2()
    {
        return null;
    }
}

I följande exempel kan klientkoden anropa metoden som returnerar det IList allmänna gränssnittet utan fel.

public class Client
{
    public void Main()
    {
        Utility util = new Utility();

        // The following code causes an error.
        List<Range> rangeList1 = util.GetRange1();

        // The following code is valid.
        List<Range> rangeList2 = (List<Range>)util.GetRange2();
    }
}