NuGet, come sappiamo, è il sistema principale nella tecnologia .NET per condividere codice tra diversi progetti?, tant'è che in .NET Core ogni progetto di tipo class library può essere convertito in un pacchetto distribuibile semplicemente aggiungendo il flag GeneratePackageOnBuild al file di progetto.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
  </PropertyGroup>

</Project>

Si tratta di un sistema che riesce a scalare bene all'aumentare della complessità del nostro codice, perché anche le dipendenze (per esempio riferimenti ad altre nostre class library) vengono gestite in maniera automatica. Immaginiamo per esempio di avere due class library come nella figura in basso, in cui Package2 ha una dipendenza da Package1:

Sebbene si tratti di una semplice project reference, nel momento in cui generiamo Package2, succederenno alcune cose interessanti:

• come previsto, il progetto Package1 sarà compilato in automatico, in quanto reference, e il file Package1.dll risultante sarà incluso nella cartella bin\Debug di Package2, così da permetterci di effettuare il debug in maniera usuale;
• la libreria Package1.dll però, non sarà inclusa nel contenuto del pacchetto NuGet creato, contrariamente a quanto ci aspetteremmo e a quanto presente invece in bin\Debug, dove ;
• DotNet Build inietterà automaticamente una dipendenza verso il package Package1 nel manifest di Package2, di fatto trasformando una project reference quindi in una vera e propria dipendenza NuGet, così che quando installiamo Package2, anche Package1 venga automaticamente installato.

Infatti, se andiamo a controllare il contenuto del manifest generato, troveremo qualcosa di simile al XML seguente:

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
  <metadata>
    ...
    <dependencies>
      <group targetFramework=".NETStandard2.0">
        <dependency id="Package1" version="1.0.0" exclude="Build,Analyzers" />
      </group>
    </dependencies>
  </metadata>
</package>

Questa dipendenza viene ovviemente riconosciuta da NuGet in fase di download di Package2, scaricando anche Package1:

In conclusione, il supporto di Visual Studio alla creazione di pacchetti NuGet semplifica di molto l'esperienza di sviluppo, perché compilare un progetto scatena la compilazione a cascata anche di tutte le sue project reference, permettendo quindi lo step in in fase di debug anche su queste ultime, come se fossero dei semplici progetti Class Library.

Allo stesso tempo, però, i pacchetti generati dal compilatore, come da best practice, rimangono isolati, così da poter essere distruibuiti in maniera indipendente ed efficiente, magari tramite GitHub Packages o Azure Artifacts, di cui abbiamo accennato in un articolo su DopsItalia.com (https://www.dopsitalia.com/articoli/DevOps/intro-azure-devops-p-3.aspx#title_6).

Nei prossimi script torneremo ad occuparci di questo argomento dal punto di vista pratico, in particolare vedremo un sistema per gestire il versioning di solution complesse sia dal punto di vista del publisher che del consumer.