Konfigurera mål och uppgifter

Valda MSBuild-uppgifter kan ställas in på att köras i den miljö som de riktar in sig på, när utvecklingsdatorn stöder målmiljön. När du till exempel använder en 64-bitars Windows-dator för att skapa ett program som är avsett för en 32-bitars Windows-arkitektur, körs valda uppgifter i en 32-bitarsprocess.

UsingTask-attribut och aktivitetsparametrar

Följande UsingTask attribut påverkar alla åtgärder för en aktivitet i en viss byggprocess:

• Attributet Runtime , om det finns, anger CLR-versionen (Common Language Runtime) och kan ta något av följande värden: CLR2, CLR4, CurrentRuntimeeller * (valfri körning).

• Attributet Architecture , om det finns, anger plattform och bitness och kan ta något av dessa värden: x86, x64, CurrentArchitectureeller * (valfri arkitektur).

• Attributet TaskFactory , om det finns, anger den aktivitetsfabrik som skapar och kör aktivitetsinstansen och tar bara värdet TaskHostFactory. Mer information finns i Aktivitetsfabriker senare i det här dokumentet.

<UsingTask TaskName="SimpleTask"
    Runtime="CLR2"
    Architecture="x86"
    AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.Core.dll" />

Du kan också använda parametrarna MSBuildRuntime och MSBuildArchitecture för att ange målkontexten för en enskild uppgiftsanrop.

<Project>
    <Target Name="MyTarget">
        <SimpleTask MSBuildRuntime="CLR2" MSBuildArchitecture= "x86"/>
    </Target>
</Project>

Innan MSBuild kör en uppgift letar den efter en matchning UsingTask som har samma målkontext. Parametrar som anges i UsingTask men inte i motsvarande uppgift anses matchas. Parametrar som anges i aktiviteten men inte i motsvarande UsingTask anses också matchas. Om parametervärdena inte anges i antingen UsingTask aktiviteten eller , är värdena standardvärdena * (valfri parameter).

Om parametrar har angetts för uppgiften försöker MSBuild hitta en UsingTask som matchar dessa parametrar eller åtminstone inte står i konflikt med dem. Mer än en UsingTask kan ange målkontexten för samma uppgift. Till exempel kan en uppgift som har olika körbara filer för olika målmiljöer likna den här:

<UsingTask TaskName="MyTool"
    Runtime="CLR2"
    Architecture="x86"
    AssemblyFile="$(MyToolsPath)\MyTool.v2.0.dll" />

<UsingTask TaskName="MyTool"
    Runtime="CLR4"
    Architecture="x86"
    AssemblyFile="$(MyToolsPath)\MyTool.4.0.dll" />

<Project>
    <Target Name="MyTarget">
        <MyTool MSBuildRuntime="CLR2" MSBuildArchitecture= "x86"/>
    </Target>
</Project>

Åsidosätta standardvärdet UsingTasks

Som standard hanterar MSBuild UsingTasks som "första vinner". Från och med 17.2 har MSBuild stöd för att åsidosätta det här beteendet via parametern Override . En UsingTask med parametern Override inställd på true prioriteras framför alla andra UsingTask av samma TaskName.

<UsingTask TaskName="MyTool"
    Runtime="CLR4"
    Architecture="x86"
    Override="true"
    AssemblyFile="$(MyToolsPath)\MyTool.4.0.dll" />

Aktivitetsfabriker

I följande tabell visas de aktivitetsfabriker som tillhandahålls av MSBuild-installationen:

Mekanismen för aktivitetsfabriken är utökningsbar, så du kan också använda dem som skapats av tredje part eller skapa egna. En orsak till att skapa en skulle vara att stödja ett annat språk för att skriva infogade uppgifter.

TaskHostFactory

Innan den kör en uppgift kontrollerar MSBuild om den är avsedd att köras i den aktuella programvarukontexten. Om uppgiften är så utsedd skickar MSBuild den till AssemblyTaskFactory, som kör den i den aktuella processen. Annars skickar MSBuild uppgiften till TaskHostFactory, som kör aktiviteten i en process som matchar målkontexten. Även om den aktuella kontexten och målkontexten matchar kan du tvinga en aktivitet att köras ut ur processen (av isolering, säkerhet eller andra orsaker) genom att ange TaskFactory till TaskHostFactory.

<UsingTask TaskName="MisbehavingTask"
    TaskFactory="TaskHostFactory"
    AssemblyFile="$(MSBuildToolsPath)\MyTasks.dll">
</UsingTask>

När TaskHostFactory anges explicit är processen som kör uppgiften kortvarig. Detta gör att operativsystemet kan rensa alla resurser som är relaterade till aktiviteten omedelbart efter att den har körts. Därför anger du TaskHostFactory när du refererar till uppgifter som skapats i samma byggprocess som deras användning för att undvika fil-i-användning-fel när du uppdaterar aktivitetssammansättningen efter en version.

RoslynCodeTaskFactory

Tillhandahåller RoslynCodeTaskFactory en mekanism genom vilken du kan skriva C# eller Visual Basic-kod för en uppgift i en projektfil för omedelbar användning. Koden kompileras under byggprocessen för att skapa en uppgift som du kan köra i samma version. Koden du skriver riktar sig till .NET Standard, så att den kan användas när du kör dotnet build, som använder .NET Core-versionen (och .NET 5 och senare) av MSBuild, samt msbuild.exe, som använder .NET Framework. RoslynCodeTaskFactory är bäst för anpassning som är lite för svår att göra i MSBuild-logik, men inte tillräckligt komplex för att skapa ett separat projekt. Se Skapa en infogad MSBuild-uppgift med RoslynCodeTaskFactory.

CodeTaskFactory

CodeTaskFactory är en äldre version av RoslynCodeTaskFactory som är begränsad till .NET Framework-versionen av MSBuild. Se INLINE-uppgifter i MSBuild. Den här aktivitetsfabriken stöds, men nyare kod bör användas RoslynCodeTaskFactory för bredare tillämplighet.

Fantomaktivitetsparametrar

Precis som andra uppgiftsparametrar MSBuildRuntime och MSBuildArchitecture kan ställas in från byggegenskaper.

<Project>
    <PropertyGroup>
        <FrameworkVersion>3.0</FrameworkVersion>
    </PropertyGroup>
    <Target Name="MyTarget">
        <SimpleTask MSBuildRuntime="$(FrameworkVerion)" MSBuildArchitecture= "x86"/>
    </Target>
</Project>

Till skillnad från andra aktivitetsparametrar MSBuildRuntime och MSBuildArchitecture är inte uppenbara för själva aktiviteten. Om du vill skriva en uppgift som är medveten om kontexten där den körs måste du antingen testa kontexten genom att anropa .NET Framework eller använda byggegenskaper för att skicka kontextinformationen via andra uppgiftsparametrar.

Parametrarna MSBuildRuntime och MSBuildArchitecture är det mest flexibla sättet att ange målkontexten, men också det mest begränsade i omfånget. Å ena sidan, eftersom de är inställda på själva aktivitetsinstansen och inte utvärderas förrän aktiviteten är på väg att köras, kan de härleda sitt värde från det fullständiga omfånget av egenskaper som är tillgängliga vid både utvärderingstid och byggtid. Å andra sidan gäller dessa parametrar endast för en viss instans av en uppgift i ett visst mål.

Relaterat innehåll

• Konfigurera mål och uppgifter
• UsingTask-element