.NET come piattaforma per web, cloud, desktop e integrazioni che devono durare

.NET come piattaforma: perché la distinzione cambia tutto

Molti sviluppatori usano .NET come sinonimo di ASP.NET Core o di Entity Framework.

È un errore concettuale che porta a sottovalutare cosa .NET offre davvero e a non sfruttarlo appieno.

.NET è una piattaforma: un runtime, un ecosistema di librerie, un toolchain e un modello di deployment che supporta web, cloud, desktop, mobile, IoT, AI e sistemi embedded.

ASP.NET Core, EF Core, MAUI, ML.NET, Blazor, Orleans: sono tutti applicazioni che girano su questa piattaforma, non la piattaforma stessa.

Questa distinzione è importante perché le scelte che si fanno a livello di piattaforma influenzano tutto il resto: la versione di .NET target, la strategia di deployment, il modello di threading, le ottimizzazioni del runtime.

Chi capisce .NET come piattaforma prende decisioni più informate su ogni livello superiore.

.NET 10, la versione LTS attuale, è un punto di maturità significativo: performance native competitive con C e Go nei benchmark di I/O-bound, tooling maturo, ecosistema stabile e supporto a lungo termine.

Non è più la piattaforma che richiede giustificazione: è la scelta ovvia per qualsiasi sistema .NET greenfield.

.NET vs altri runtime: quando è la scelta giusta e quando no

.NET non è la risposta giusta a tutti i problemi.

Ma per una famiglia specifica di problemi, è difficile fare meglio.

Dove .NET eccelle: applicazioni enterprise con logica di dominio complessa, sistemi web ad alta concorrenza, applicazioni che devono girare su Windows e Linux con lo stesso codice, ecosistemi che usano già Azure e i servizi Microsoft, team che vogliono un unico linguaggio (C#) per backend, frontend Blazor, mobile MAUI e script di automazione.

Dove le alternative hanno senso: Node.js per team che vogliono unificare JavaScript su frontend e backend; Python per data science e ML dove l'ecosistema scientifico è dominante; Go per microservizi che richiedono footprint minimo e startup ultraveloce; Rust per sistemi embedded o dove la sicurezza della memoria senza GC è un requisito.

Il criterio non è mai la tecnologia preferita in astratto.

È: quale runtime dà al team le competenze già esistenti, le librerie necessarie e le performance adeguate al carico previsto, con il minor costo di manutenzione nel tempo?

Per la maggior parte dei team .NET con stack enterprise, la risposta è .NET.

Non per campanilismo, ma per pragmatismo.

Versionamento di .NET: STS, LTS e cosa usare in produzione

.NET esce con una nuova versione ogni novembre.

Le versioni pari sono LTS (Long-Term Support, 3 anni di supporto); le dispari sono STS (Standard-Term Support, 18 mesi).

In produzione su sistemi enterprise la regola pratica è: usare sempre la versione LTS più recente, a meno di ragioni specifiche.

Questo massimizza il periodo di supporto senza aggiornamenti forzati e garantisce accesso alle ottimizzazioni di runtime più consolidate.

La migrazione tra versioni major di .NET è generalmente poco traumatica grazie alla compatibilità backward dell'ecosistema.

I breaking change esistono ma sono documentati e spesso riguardano API rare o deprecate da versioni precedenti.

Il tooling (dotnet upgrade-assistant) automatizza la maggior parte delle modifiche meccaniche.

Il vero costo della migrazione non è la modifica del target framework: è aggiornare le dipendenze NuGet che non supportano la nuova versione.

Per questo motivo mantenere le dipendenze aggiornate versione per versione è meno costoso che farlo in un unico salto ogni tre anni.

Ecosistema NuGet e dipendenze: come gestirle senza perdersi

NuGet è l'ecosistema di pacchetti più grande dopo npm per numero di pacchetti.

La qualità varia enormemente: ci sono librerie mantenute da Microsoft e dalla community con migliaia di download al giorno, e ci sono pacchetti abbandonati da anni con vulnerabilità note.

I criteri che uso per valutare una dipendenza NuGet: supporta la versione .NET target?

È mantenuta attivamente?

Ha vulnerabilità note (controllabili con dotnet list package --vulnerable)?

Ha alternative mantenute da Microsoft o da fondazioni affidabili?

Central Package Management, introdotto con .NET SDK, permette di centralizzare le versioni dei pacchetti in un file Directory.Packages.props invece di ripeterle in ogni csproj.

In soluzioni con molti progetti è la differenza tra aggiornare una riga e aggiornarne cinquanta.

Le dipendenze transitive sono il rischio silenzioso: un pacchetto che sembra innocuo può portare con sé dipendenze con vulnerabilità. dotnet list package --include-transitive --vulnerable è il comando da eseguire in ogni pipeline CI prima del deploy in produzione.