Condividi tramite


Configurare destinazioni e attività

Le attività MSBuild selezionate possono essere impostate per l'esecuzione nell'ambiente di destinazione, quando il computer di sviluppo supporta l'ambiente di destinazione. Ad esempio, quando si usa un computer Windows a 64 bit per compilare un'applicazione destinata a un'architettura Windows a 32 bit, le attività selezionate vengono eseguite in un processo a 32 bit.

Nota

Se un'attività di compilazione è scritta in un linguaggio .NET, ad esempio in Visual C# o Visual Basic, e non usa strumenti o risorse native, potrà essere eseguita in qualsiasi contesto di destinazione senza adattamento.

Attributi UsingTask e parametri dell'attività

Gli attributi UsingTask seguenti interessano tutte le operazioni di un'attività in un determinato processo di compilazione:

  • L'attributo Runtime, se presente, imposta la versione CLR (Common Language Runtime) e può assumere uno dei valori seguenti: CLR2, CLR4, CurrentRuntime o * (qualsiasi runtime).

  • L'attributo Architecture, se presente, imposta la piattaforma e il numero di bit e può assumere uno dei valori seguenti: x86, x64, CurrentArchitecture o * (qualsiasi architettura).

  • L'attributo TaskFactory, se presente, imposta la factory delle attività che crea ed esegue l'istanza dell'attività e può assumere solo il valore TaskHostFactory. Per altre informazioni, vedere la sezione Factory di attività più avanti in questo documento.

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

È anche possibile usare i MSBuildRuntime parametri e MSBuildArchitecture per impostare il contesto di destinazione di una singola chiamata a un'attività.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="MyTarget">
        <SimpleTask MSBuildRuntime="CLR2" MSBuildArchitecture= "x86"/>
    </Target>
</Project>

Prima di eseguire un'attività, MSBuild cerca un attributo UsingTask corrispondente con lo stesso contesto di destinazione. Deve essere trovata una corrispondenza anche per i parametri specificati in UsingTask ma non nell'attività corrispondente, così come per i parametri specificati nell'attività ma non nell'attributo UsingTask corrispondente. Se non sono stati specificati valori di parametro né per UsingTask né per l'attività, l'impostazione predefinita dei valori è * (qualsiasi parametro).

Avviso

Se ne esistono più UsingTask e tutti hanno attributi , Runtimee Architecture corrispondentiTaskName, il primo da valutare sostituisce gli altri. Questo comportamento è diverso da quello degli Property elementi e Target .

Se sono stati impostati parametri nell'attività, MSBuild tenta di trovare un elemento UsingTask che corrisponda, o almeno non sia in conflitto, con i parametri impostati. È possibile che più elementi UsingTask specifichino il contesto di destinazione per la stessa attività. Un'attività con vari file eseguibili per diversi ambienti di destinazione, ad esempio, avrebbe un aspetto simile al seguente:

<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 xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="MyTarget">
        <MyTool MSBuildRuntime="CLR2" MSBuildArchitecture= "x86"/>
    </Target>
</Project>

Override dell'impostazione predefinita UsingTasks

Per impostazione predefinita, MSBuild gestisce UsingTask come "first one wins". A partire dalla versione 17.2, MSBuild supporta l'override di questo comportamento tramite il Override parametro . Un oggetto UsingTask con il parametro Override impostato su true avrà la priorità su qualsiasi altro UsingTask dello stesso TaskName.

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

Avviso

Questa operazione può essere eseguita una sola volta per ogni attività. Le compilazioni che tentano di aggiungere più sostituzioni per la stessa attività riceveranno l'errore MSB4275MSBuild .

Factory di attività

Nella tabella seguente vengono illustrate le task factory fornite dall'installazione di MSBuild:

Factory di attività Descrizione
AssemblyTaskFactory Questo è il valore predefinito. Esegue l'attività in-process.
TaskHostFactory Esegue l'attività out-of-process.
RoslynCodeTaskFactory Per le attività inline scritte in C# o Visual Basic e destinate a .NET Standard; funziona sia con che dotnet buildcon msbuild.exe .
CodeTaskFactory Per le attività inline scritte in C# o Visual Basic e destinate a .NET Framework; funziona solo con msbuild.exe.

Il meccanismo della factory delle attività è estendibile, quindi è anche possibile usare quelli creati da terze parti o crearne di personalizzati. Un motivo per crearne uno sarebbe quello di supportare un'altra lingua per la scrittura di attività inline.

TaskHostFactory

Prima di eseguire un'attività, MSBuild verifica di essere stato designato per l'esecuzione nel contesto software corrente. Se l'attività è così designata, MSBuild lo passa a AssemblyTaskFactory, che lo esegue nel processo corrente; in caso contrario, MSBuild passa l'attività a TaskHostFactory, che esegue l'attività in un processo che corrisponde al contesto di destinazione. Anche se il contesto corrente e il contesto di destinazione corrispondono, è possibile imporre l'esecuzione out-of-process di un'attività (per motivi di isolamento, sicurezza o di altri tipo) impostando TaskFactory su TaskHostFactory.

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

Quando TaskHostFactory viene specificato in modo esplicito, il processo che esegue l'attività è di breve durata. In questo modo il sistema operativo può pulire tutte le risorse correlate all'attività immediatamente dopo l'esecuzione. Per questo motivo, specificare TaskHostFactory quando si fa riferimento alle attività compilate nello stesso processo di compilazione usato, per evitare errori di utilizzo dei file durante l'aggiornamento dell'assembly attività dopo una compilazione.

RoslynCodeTaskFactory

RoslynCodeTaskFactory fornisce un meccanismo in base al quale è possibile scrivere codice C# o Visual Basic per un'attività in un file di progetto per un uso immediato. Il codice viene compilato durante il processo di compilazione per produrre un'attività che è possibile eseguire nella stessa compilazione. Il codice scritto è destinato a .NET Standard, quindi può essere usato durante l'esecuzione dotnet builddi , che usa la versione .NET Core (e .NET 5 e successive) di MSBuild, nonché msbuild.exe, che usa .NET Framework. RoslynCodeTaskFactory è ideale per la personalizzazione che è un po 'troppo difficile da eseguire nella logica di MSBuild, ma non abbastanza complesso per creare un progetto separato. Vedere Creare un'attività inline di MSBuild con RoslynCodeTaskFactory.

CodeTaskFactory

CodeTaskFactory è una versione precedente di RoslynCodeTaskFactory limitata alla versione .NET Framework di MSBuild. Vedere Attività inline di MSBuild. Questa factory di attività è supportata, ma il codice più recente deve essere usato per un'applicabilità RoslynCodeTaskFactory più ampia.

Parametri fantasma dell'attività

Come qualsiasi altro parametro dell'attività, MSBuildRuntime e MSBuildArchitecture possono essere impostati dalle proprietà di compilazione.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <FrameworkVersion>3.0</FrameworkVersion>
    </PropertyGroup>
    <Target Name="MyTarget">
        <SimpleTask MSBuildRuntime="$(FrameworkVerion)" MSBuildArchitecture= "x86"/>
    </Target>
</Project>

A differenza di altri parametri di attività, MSBuildRuntime e MSBuildArchitecture non vengono visualizzati per l'attività stessa. Per scrivere un'attività che considera il contesto in cui viene eseguita, è necessario verificare il contesto tramite una chiamata a .NET Framework o usare le proprietà di compilazione per passare le informazioni sul contesto tramite altri parametri di attività.

Nota

Gli attributi UsingTask possono essere impostati dalle proprietà del set di strumenti o dell'ambiente.

I parametri MSBuildRuntime e MSBuildArchitecture offrono il metodo più flessibile per impostare il contesto di destinazione ma anche il più limitato relativamente all'ambito. Da un lato, poiché vengono impostati nell'istanza dell'attività e vengono valutati solo prima dell'esecuzione dell'attività, possono derivare il valore dall'ambito completo di proprietà disponibili in fase di valutazione e in fase di compilazione. Dall'altro, questi parametri vengono applicati solo a una particolare istanza di un'attività in una determinata destinazione.

Nota

I parametri dell'attività vengono valutati nel contesto del nodo padre, non nel contesto dell'host dell'attività. Le variabili di ambiente dipendenti dal runtime o dall'architettura, come ad esempio, il percorso di Programmi, restituiranno il valore che corrisponde al nodo padre. Tuttavia, se la stessa variabile di ambiente viene letta direttamente dall'attività, verrà valutata correttamente nel contesto dell'host di attività.