Gennaio 2017

Volume 32 Numero 1

Il presente articolo è stato tradotto automaticamente.

Concetti essenziali su .NET - MSBuild essenziale: Panoramica di Build Engine per gli strumenti .NET

Da Mark Michaelis | Gennaio 2017

Coloro che hanno seguito .NET Core negli ultimi anni (è stato in tempo?) conoscono tutti troppo bene che il "sistema di compilazione" ha riscontrato una quantità significativa di flusso, se è possibile eliminazione supporto incorporato per gulp o il fallimento di Project. Per me come un giornalista, queste modifiche sono state complessa poiché non voglio, i miei lettori hanno Gentile, dedicare troppo tempo all'apprendimento sulle funzionalità e i dettagli che in definitiva avreste solo in circolazione per pochi mesi. Ecco perché, ad esempio, tutti miei articoli relativi a .NET Core sono stati compilati basate su Visual Studio .NET 4.6 *. File CSPROJ a cui fa riferimento a pacchetti NuGet di .NET Core piuttosto che in effetti compilato progetti .NET Core.

Questo mese, sono lieto di report, il file di progetto per i progetti .NET Core stabilizzato in (sarebbe si ritiene) un file MSBuild. Tuttavia, non è lo stesso file MSBuild da generazioni precedenti di Visual Studio, ma piuttosto un miglioramento, semplificata, ovvero file MSBuild. È un file (senza guerre religiosi parentesi o parentesi quadre) include tutte le funzionalità di Project, ma con il supporto dello strumento allegati del file di MSBuild tradizionali che sono stati fatti a conoscere (e probabilmente amare?) a partire da Visual Studio 2005. In breve, le funzionalità includono Apri origine, la compatibilità multipiattaforma, un formato semplificato e umane modificabili e, infine completo supporto di strumenti .NET moderno inclusi che fanno riferimento a file con caratteri jolly.

Strumenti di supporto

Per maggiore chiarezza, funzionalità quali i caratteri jolly sono sempre supportate in MSBuild, ma ora il funziona con essi, nonché strumenti di Visual Studio. In altre parole, le notizie più importanti informazioni su MSBuild sono che è strettamente integrato come base di sistema di compilazione per tutte le nuove Tooling—DotNet.exe .NET, Visual Studio 2017, codice di Visual Studio e Visual Studio per Mac e grazie al supporto di runtime .NET Core 1.0 e 1.1 di .NET Core.

Il grande vantaggio dell'accoppiamento forte tra gli strumenti di .NET e MSBuild è che qualsiasi file MSBuild creato è compatibile con tutti i .NET degli strumenti e può essere compilata da qualsiasi piattaforma.

Strumenti di .NET per l'integrazione di MSBuild è accoppiato tramite l'API di MSBuild, non solo un processo della riga di comando. Ad esempio, l'esecuzione del comando CLI .NET compilazione Dotnet.exe non internamente viene generato il processo msbuild.exe. Tuttavia, effettua una chiamata API di MSBuild nel processo per eseguire le operazioni (MSBuild.dll sia Microsoft.Build.* assembly). Anche in questo caso, l'output, indipendentemente dallo strumento, è simile in piattaforme perché è un framework di registrazione condiviso con cui registrare gli strumenti di .NET.

*. Struttura di File CSPROJ/MSBuild

Come già accennato, lo stesso formato di file è stato semplificato verso il basso il minimo. Supporta i caratteri jolly, progetto e riferimenti al pacchetto NuGet e più Framework. Inoltre, il GUID del tipo di progetto disponibili nei file di progetto Visual Studio creato in passato sono sparite.

Figura 1 Mostra un esempio *. File CSPROJ/MSBuild.

Figura 1 esempio Basic CSProj/MSBuild File

<Project>
  <PropertyGroup>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="**\*.cs" />
    <EmbeddedResource Include="**\*.resx" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NETCore.App">
      <Version>1.0.1</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.NET.Sdk">
      <Version>1.0.0-*</Version>
      <PrivateAssets>All</PrivateAssets>
    </PackageReference>
  </ItemGroup>
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

Esaminare la struttura e funzionalità in modo dettagliato:

Intestazione semplificata: Per iniziare, si noti che l'elemento radice è semplicemente un elemento del progetto. Verificato è la necessità di anche gli attributi dello spazio dei nomi e la versione:

ToolsVersion="15.0" xmlns="https://schemas.microsoft.com/developer/msbuild/2003"

(Tuttavia, vengono comunque creati gli strumenti di versione release candidate.)  Analogamente, è semplicemente facoltativa, anche la necessità per l'importazione le proprietà comuni:

<Import Project=
  "$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />

Riferimenti al progetto: Dal file di progetto, è possibile aggiungere voci per gli elementi del gruppo di elementi:

• Pacchetti NuGet:

<PackageReference Include="Microsoft.Extensions.Configuration">
  <Version>1.1.0</Version>
</PackageReference>

• Riferimenti al progetto:

<ProjectReference Include="..\ClassLibrary\ClassLibrary.csproj" />

• Riferimenti ad assembly:

<Reference Include="MSBuild">
  <HintPath>...</HintPath>
</Reference>

Un riferimento diretto assembly deve essere l'eccezione viene in genere preferibile un riferimento di NuGet.

Sono inclusi caratteri jolly: File di codice compilato e i file di risorse possono essere inclusi tramite caratteri jolly.

<Compile Include="**\*.cs" />
<EmbeddedResource Include="**\*.resx" />
<Compile Remove="CodeTemplates\**" />
<EmbeddedResource Remove="CodeTemplates\**" />

Tuttavia, è comunque possibile selezionare file specifici per ignorare l'utilizzo dell'attributo remove. Si noti che il supporto per i caratteri jolly viene spesso definito come il glob.

Il multitargeting: Per identificare quale piattaforma di destinazione, insieme al tipo di output (facoltativo), è possibile utilizzare un gruppo di proprietà con gli elementi TargetFramework:

<PropertyGroup>
  <TargetFramework>netcoreapp1.0</TargetFramework>
  <TargetFramework>netstandard1.3</TargetFramework>
</PropertyGroup>

Dato queste voci, l'output per ogni destinazione verrà compilato nella directory bin\Debug o bin\Release (a seconda di quale configurazione specifica). Se è presente più di una destinazione, l'esecuzione della compilazione inserirà l'output in una cartella corrispondente al nome di framework di destinazione.

Nessun GUID di tipo di progetto: Si noti che non è più necessario includere un GUID del tipo di progetto che identifica il tipo di progetto.

Integrazione con Visual Studio 2017

Quando si parla di Visual Studio 2017, Microsoft continua a fornire un'interfaccia utente completa per la modifica del file di progetto CSPROJ/MSBuild. Figura 2, ad esempio, Mostra Visual Studio 2017 caricato con un file CSPROJ file elenco, leggermente modificato da figura 1, che include gli elementi del framework di destinazione per netcoreapp1.0 e net45, insieme ai riferimenti del pacchetto per Microsoft.Extensions.Configuration, Microsoft.NETCore.App e Microsoft.NET.Sdk, oltre a un riferimento all'assembly di MSBuild e un progetto di fare riferimento a SampleLib.                                                                                                           

Esplora soluzioni nella figura 2 è una UI Rich in un CSProj File

Si noti come tipo di ogni dipendenza, assembly, il riferimento di progetto o pacchetto NuGet, con un nodo di gruppo corrispondente all'interno della struttura di dipendenze in Esplora soluzioni.

Inoltre, Visual Studio 2017 supporta il ricaricamento dinamico del progetto e soluzione. Ad esempio, se viene aggiunto un nuovo file nella directory del progetto, ovvero uno che corrisponda a uno dei caratteri jolly il glob, Visual Studio 2017 automaticamente rileva le modifiche e vengono visualizzati i file in Esplora soluzioni. Analogamente, se si esclude un file da un progetto di Visual Studio (tramite l'opzione di menu di Visual Studio o nella finestra proprietà di Visual Studio), Visual Studio aggiornerà automaticamente il file di progetto di conseguenza. (Ad esempio, aggiungerà un <Compile remove="CommandLine.cs"></Compile> elemento da escludere il file CommandLine.cs dalla compilazione all'interno del progetto.) 

Inoltre, le modifiche apportate ai file di progetto verranno automaticamente rilevate e ricaricate in Visual Studio 2017. Infatti, il nodo del progetto Visual Studio all'interno di Esplora ora supporta una modifica incorporata <Project file="">opzione di menu che apre il file di progetto all'interno della finestra di modifica di Visual Studio senza richiedere prima che si scarica il progetto.</Project>

Non esiste supporto di migrazione incorporati all'interno di Visual Studio 2017, conversione di progetti nel nuovo formato di MSBuild. Se si accetta la richiesta, il progetto verrà aggiornato automaticamente da un Project.json/*. Tipo XPROJ MSBUILD / *. Tipo di file CSPROJ. Si noti che un aggiornamento di questo interromperà la compatibilità con i progetti di Visual Studio 2015 .NET Core, in modo che non sia parte del team lavorano sullo stesso progetto .NET Core in Visual Studio 2017 mentre altri utilizzano Visual Studio 2015.

MSBuild

Citerò di non segnalare nel mese di marzo 2016, Microsoft ha rilasciato MSBuild come open source su GitHub (github.com/Microsoft/msbuild) e hanno contribuito a .NET Foundation (dotnetfoundation.org). La definizione di MSBuild come Apri origine inserirlo nella traccia per la portabilità della piattaforma per Mac e Linux, in definitiva, in modo che possa diventare sottostante motore di compilazione per tutti i .NET degli strumenti.

Oltre a CSPROJ\MSBuild file PackageReference elemento identificato in precedenza, MSBuild versione 15 non introduce molte funzionalità aggiuntive oltre aprire l'origine e multipiattaforma. Infatti, il confronto la Guida della riga di comando Mostra che le opzioni sono identiche. Per coloro che ancora non conoscono, ecco un elenco di opzioni più comuni che è necessario avere familiarità con dalla sintassi generale MSBuild.exe [opzioni] [file di progetto]:

/target:<target>: identifica la destinazione di compilazione all'interno del file di progetto per eseguire insieme a eventuali dipendenze potrebbe avere (/t è l'abbreviazione).</target>

/Property:<n>=<v>:</v> </n> Imposta o esegue l'override di qualsiasi proprietà del progetto (identificata nell'elemento ProjectGroup di un file di progetto). Ad esempio, è possibile utilizzare la proprietà per modificare la configurazione o la directory di output, come in /property:Configuration = Release; OutDir = bin \ (/ p è l'abbreviazione).

/maxcpucount [: n]: Specifica il numero di CPU da utilizzare. Per impostazione predefinita, msbuild esegue su una singola CPU (a thread singolo). Se la sincronizzazione non è un problema è possibile aumentare che specificando il livello di concorrenza. Se si specifica l'opzione /maxcpucount senza fornire un valore, msbuild utilizzerà il numero di processori nel computer.

/ pre-elaborazione [: file]: Genera un file di progetto aggregato effettuando l'inlining di tutti i destinatari inclusi. Questo può essere utile per il debug quando si è verificato un problema.

@file: Fornisce i file di risposta (più) che contiene le opzioni. Tali file hanno ciascuna opzione della riga di comando su una riga separata (commenti preceduti da "#"). Per impostazione predefinita, MSBuild importerà un file denominato rsp dal primo progetto o soluzione compilata. È utile per identificare la proprietà di compilazione diverse e destinazioni a seconda di quale ambiente (sviluppo, Test, produzione) si sta creando, ad esempio il file di risposta.

Dotnet.exe

Circa un anno fa, come un meccanismo multipiattaforma per la generazione, creare ed eseguire progetti basati su .NET Core è stata introdotta la riga di comando dotnet.exe per .NET. Come già accennato, è stato aggiornato in modo che ora si basa soprattutto su MSBuild come motore interno per la maggior parte dei casi in cui ha senso.

Di seguito viene fornita una panoramica dei vari comandi:

dotnet nuovo: Crea il progetto iniziale. Impostazione predefinita il generatore di progetto supporta i tipi di progetto Console, Web, Lib, MSTest e XUnitTest. Tuttavia, in futuro è probabile che consente di creare modelli personalizzati, pertanto non è possibile generare tipi di progetto. (In questo caso, il nuovo comando non fare affidamento su MSBuild per la generazione del progetto).

ripristino dotnet: Legge le dipendenze di progetto specificate nel file di progetto e scarica tutti i pacchetti NuGet mancanti e gli strumenti sono identificati. Il file di progetto può essere specificato sia come un argomento o essere implicito dalla directory corrente (se è presente più di un file di progetto nella directory corrente, quale utilizzare è necessario specificare). Si noti che poiché ripristino sfrutta il motore MSBuild per il proprio lavoro, il comando dotnet consente per altre opzioni della riga di comando di MSBuild.

dotnet compilazione: Chiamate sul motore di MSBuild per eseguire la destinazione di compilazione (per impostazione predefinita) all'interno del file di progetto. Ad esempio il comando di ripristino, è possibile passare argomenti di MSBuild per il comando di compilazione dotnet. Ad esempio, un comando, ad esempio dotnet compilare /property:configuration = versione attiverà una build di rilascio output anziché una build di Debug (impostazione predefinita). Analogamente, è possibile specificare la destinazione di MSBuild utilizzando /target (o /t). Il dotnet compilare /t:compile comando, ad esempio, verrà eseguita la destinazione di compilazione.

dotnet parziale: Rimuove una compilazione di output in modo che verrà eseguita una compilazione completa anziché una compilazione incrementale.

eseguire la migrazione dotnet: Aggiorna un Project.json/*. Progetto basato su XPROJ nel *. Formato di file CSPROJ/MSBuild.

dotnet pubblicazione: Combina tutti la compilazione di output insieme a tutte le dipendenze in un'unica cartella, pertanto, di gestione temporanea per la distribuzione in un altro computer. Ciò è particolarmente utile per la distribuzione completa che include non solo l'output di compilazione e i pacchetti dipendenti, ma anche il runtime .NET Core. Tutti i prerequisiti che una particolare versione della piattaforma .NET già installato nel computer di destinazione non dispone di un'applicazione indipendente.

dotnet eseguire: Avvia il Runtime .NET e ospita il progetto e/o gli assembly compilati per l'esecuzione del programma. Si noti che per ASP.NET, la compilazione non è necessaria come il progetto può essere ospitato.

Esiste una sovrapposizione significativa tra l'esecuzione di msbuild.exe e dotnet.exe, lasciando la scelta di cui uno per l'esecuzione. Se si sta creando la destinazione di msbuild predefinita è possibile eseguire semplicemente il comando "msbuild.exe" dalla directory del progetto e verrà compilato e la destinazione di output per l'utente. Il comando equivalente dotnet.exe è "dotnet.exe msbuild". D'altra parte, se si sta eseguendo il comando a una destinazione "pulita" è "msbuild.exe /t: clean" con MSBuild, e "dotnet.exe pulita" con dotnet. Inoltre, entrambi gli strumenti supportano le estensioni. MSBuild è un framework di estensibilità completa all'interno del file di progetto stesso sia tramite assembly .NET (vedere bit.ly/2flUBza). Analogamente, può essere esteso dotnet ma troppo, l'indicazione a tale scopo, riguarda essenzialmente l'estensione MSBuild più un po' più lineare.

Mentre apprezza l'idea di dotnet.exe, alla fine sembra che non offrono molto utili su MSBuild, ad eccezione di eventuali operazioni che non supporta MSBuild (di cui dotnet nuovo e dotnet eseguire sono probabilmente più significativi). Al termine, ritengo che MSBuild consente di eseguire facilmente operazioni semplici, consentendo comunque il materiale complicato quando necessario. Inoltre, anche il materiale complicata in MSBuild può essere semplificata verso il basso, fornendo valori predefiniti ragionevole. Infine, se è preferibile dotnet o MSBuild riguarda in base alle preferenze e tempo indicherà che lo sviluppo della community in genere liquida in per il front-end CLI.

Global

Funzionalità di Project migrato a CSPROJ, Global è ancora completamente supportato. Il file consente di specificare directory di progetto e di directory dei pacchetti e identifica la versione del SDK da utilizzare. Di seguito è riportato un file Global esempio:

{
  "projects": [ "src", "test" ],
  "packages": "packages",
  "sdk": {
    "version": "1.0.0-preview3",
    "runtime": "clr",
    "architecture": "x64"
  }
}

Le tre sezioni corrispondono agli scopi principali del file Global:

progetti: Identifica la directory radice in cui .NET si trovano i progetti. Il nodo dei progetti è fondamentale per il debug nel codice sorgente .NET Core. Dopo la clonazione del codice sorgente, è possibile aggiungere la directory nel nodo dei progetti e Visual Studio verrà quindi caricherà automaticamente di un progetto all'interno della soluzione.

pacchetti: Indica il percorso della cartella dei pacchetti NuGet.

SDK: Specifica la versione del runtime da utilizzare.

Conclusioni

In questo articolo ho fornito un'ampia panoramica di tutte le posizioni che MSBuild viene utilizzato all'interno del gruppo di strumenti di .NET. Prima di essere chiuso, è possibile offrire un bit di consigli dalla mia esperienza si lavora su progetti con migliaia di righe di MSBuild. Non rientrano nell'errore di esecuzione di script troppo in un linguaggio dichiarativo, fortemente tipizzato come lo schema XML MSBuild. Non è lo scopo. Piuttosto, i file di progetto devono essere relativamente thin wrapper che identificano l'ordine e le dipendenze tra le destinazioni di compilazione. Se si lascia il file di progetto MSBuild ottenere troppo grande, può diventare un problema di mantenere. Non attendere troppo tempo prima refactoring in qualcosa come attività di MSBuild in c# che possono essere sottoposti a debug e facilmente gli unit test.

Mark Michaelisè fondatore di IntelliTect, dove ha serve come responsabile dell'architettura tecnico e istruttore.  Per quasi due decenni lavora un Microsoft MVP e un Microsoft Regional Director poiché 2007. Michaelis viene utilizzato in diversi software progettazione revisione team Microsoft, tra cui c#, Microsoft Azure, SharePoint e Visual Studio ALM. Ha come relatore a conferenze per gli sviluppatori e ha scritto numerosi libri, tra cui il suo più recente, "Essential c# 6.0 (5 ° edizione)" (itl.tc/EssentialCSharp). È possibile contattarlo su Facebook al facebook.com/Mark.Michaelis, sul suo blog all'indirizzo IntelliTect.com/Mark, su Twitter: @markmichaelis o tramite posta elettronica all'indirizzo mark@IntelliTect.com.

Grazie per i seguenti esperti tecnici IntelliTect per la revisione dell'articolo: Kevin Bost, Grant Erickson, Chris Finlayson, Phil Spokas e Michael Stokesbary