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.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Autenticarsi in modo sicuro su Azure tramite GitHub Actions
Sfruttare al massimo i topic space di Event Grid MQTT
Utilizzare un service principal per accedere a Azure Container Registry
Controllare gli accessi IP alle app con Azure Container Apps
Creazione di componenti personalizzati in React.js con Tailwind CSS
Specificare il versioning nel path degli URL in ASP.NET Web API
Utilizzare Tailwind CSS all'interno di React: installazione
Eseguire attività pianificate con Azure Container Jobs
Utilizzare le collection expression in C#
Modificare i metadati nell'head dell'HTML di una Blazor Web App
Utilizzare i primary constructor in C#
Miglioramenti nell'accessibilità con Angular CDK
I più letti di oggi
- PWAConf 2020 - Online
- Effettuare il binding di date in Blazor
- What's new in Azure Functions and Extensions
- Mantenere sempre reattiva una Lambda di AWS
- Proteggersi dagli attacchi di Open Redirect in ASP.NET Core MVC
- Gestire errori funzionali tramite exception in ASP.NET Core Web API
- Sblocca le performance della tua applicazione con .NET 8