.NET Framework è la piattaforma di sviluppo ed esecuzione Microsoft che per molti anni ha costituito la base di applicazioni Windows, software aziendali e applicazioni web ASP.NET. È ancora supportato e utilizzato, ma oggi occupa un ruolo molto diverso rispetto al passato: serve soprattutto per eseguire, mantenere o estendere software che dipende già dal suo ecosistema.
Per un nuovo progetto, invece, il riferimento Microsoft è .NET moderno, attualmente multipiattaforma e sviluppato con un ciclo di release distinto. La stessa documentazione Microsoft sul confronto tra .NET e .NET Framework indica .NET come scelta preferenziale per il nuovo sviluppo server-side, salvo esigenze specifiche di compatibilità.
Questa distinzione è il punto più importante da chiarire. .NET Framework, .NET Core e le versioni moderne di .NET appartengono alla stessa storia tecnologica, ma non sono semplicemente tre nomi intercambiabili dello stesso prodotto.
Se hai incontrato un’applicazione che richiede “Microsoft .NET Framework”, stai mantenendo un vecchio progetto oppure devi scegliere lo stack per un nuovo software, vediamo come orientarti senza confondere versioni, runtime e piattaforme.
Cos’è .NET Framework e perché esiste ancora
.NET Framework è un ambiente Microsoft per creare ed eseguire applicazioni principalmente su Windows.
La piattaforma combina un runtime, librerie riutilizzabili, un modello di tipi comune e strumenti che consentono a linguaggi differenti di produrre codice eseguibile sotto il controllo del Common Language Runtime, o CLR.
Microsoft lo descrive oggi come una tecnologia Windows distinta da .NET moderno. La documentazione ufficiale sull’installazione di .NET Framework identifica .NET Framework 4.8.1 come la release più recente della linea.
Il fatto che non sia più la piattaforma consigliata per la maggior parte dei nuovi progetti non significa però che sia scomparsa.
Runtime, librerie e applicazioni Windows: il modello mentale corretto
Il modo più semplice per capirlo è separare tre livelli.
Il primo è il codice dell’applicazione, scritto per esempio in C#, Visual Basic o F#.
Il secondo è costituito dalle librerie e dalle API disponibili nell’ecosistema .NET Framework: raccolte di classi già pronte per lavorare con file, rete, interfacce, dati, XML, servizi e molte altre funzioni.
Il terzo è il Common Language Runtime, che gestisce l’esecuzione del codice.
Il modello può essere sintetizzato così:
codice sorgente → compilatore → CIL + metadata → assembly → CLR/JIT → codice macchina
Questa architettura spiega perché .NET Framework non è soltanto una libreria da installare e nemmeno un linguaggio di programmazione.
È l’ambiente nel quale il software viene compilato, descritto attraverso metadata ed eseguito sotto il controllo del runtime.
Chi ne ha bisogno oggi
Ci sono soprattutto due categorie di utenti.
La prima è composta da persone che devono eseguire un programma Windows esistente. Un gestionale, un’applicazione interna o un vecchio software può richiedere una versione specifica del Framework per avviarsi correttamente.
La seconda comprende sviluppatori e aziende che mantengono applicazioni già costruite su questa piattaforma.
In questi casi, passare immediatamente a .NET moderno potrebbe non essere necessario o conveniente. Microsoft stessa distingue esplicitamente i casi in cui un’applicazione esistente può continuare su Framework da quelli in cui ha senso scegliere o migrare verso .NET moderno.
Se invece stai iniziando un progetto completamente nuovo, la domanda cambia: non è più “.NET Framework funziona ancora?”, ma “esiste una dipendenza concreta che mi obbliga a usarlo?”.
Se la risposta è no, normalmente partirei da .NET moderno.
Cosa non è: .NET Framework non coincide con .NET moderno
Uno dei motivi per cui il tema crea ancora confusione è il naming.
Per anni Microsoft ha sviluppato .NET Framework come piattaforma principale per Windows. In seguito è nato .NET Core, progettato con una maggiore attenzione alla modularità e al funzionamento multipiattaforma.
Da .NET 5 in poi il ramo moderno ha assunto semplicemente il nome .NET.
Al 27 settembre 2026, .NET 10 è l’attuale release LTS supportata attivamente. Il ciclo di vita delle release moderne può essere verificato direttamente nella policy di supporto ufficiale di .NET, che è indipendente dal lifecycle di .NET Framework.
Quindi:
.NET Frameworkindica la piattaforma Windows storica ancora supportata;.NET Coreindica il ramo precedente a .NET 5;.NETindica oggi la piattaforma moderna.
La somiglianza dei nomi non deve nascondere questa separazione.
Come funziona .NET Framework
Per capire davvero a cosa serve .NET Framework, conviene osservare cosa accade tra il codice scritto dallo sviluppatore e le istruzioni eseguite dalla CPU.
L’idea centrale è che il programma non viene normalmente trasformato direttamente e una volta per tutte nel codice macchina definitivo della CPU.
Esiste un livello intermedio gestito dal runtime.
Dal codice C#, Visual Basic o F# al CIL
Quando compili un progetto .NET, il compilatore produce un linguaggio intermedio chiamato Common Intermediate Language, spesso abbreviato in CIL o IL.
Nello stesso artefatto vengono memorizzati anche metadata che descrivono tipi, membri, dipendenze e altre informazioni utili al runtime.
La documentazione Microsoft sugli assembly descrive questi file come unità che possono contenere manifesto, metadata dei tipi, codice CIL e risorse.
Questo passaggio intermedio permette a linguaggi differenti di convergere su una rappresentazione compatibile con il runtime.
Un programma scritto in C# e uno scritto in Visual Basic non devono quindi condividere la stessa sintassi sorgente. Ciò che conta è che il compilatore produca output compatibile con la Common Language Infrastructure.
CLR, JIT e garbage collection
Quando l’applicazione viene eseguita entra in gioco il Common Language Runtime.
Il Common Language Runtime fornisce l’ambiente nel quale gira il codice gestito e coordina servizi come gestione della memoria, controllo dei tipi, eccezioni e compilazione del codice intermedio.
Il compilatore Just-In-Time, o JIT, trasforma il codice intermedio necessario in istruzioni macchina eseguibili dalla CPU.
In forma semplificata:
CIL → JIT → codice macchina
Il runtime gestisce inoltre una parte importante della memoria attraverso il garbage collector. Gli oggetti vengono allocati nell’heap gestito e il garbage collector recupera la memoria associata agli oggetti che non risultano più utilizzati dall’applicazione.
Questo non significa che lo sviluppatore possa ignorare completamente memoria, risorse o performance. File, socket, handle nativi, query inefficienti o oggetti mantenuti inutilmente in memoria possono comunque creare problemi.
Significa che una parte della gestione che in altri contesti deve essere svolta manualmente viene coordinata dal runtime.
Framework Class Library, assembly e codice gestito
Le librerie sono l’altro grande pezzo della piattaforma.
Uno sviluppatore non deve implementare da zero funzioni per manipolare stringhe, leggere file, creare collezioni o interagire con molti componenti della piattaforma.
Le class library forniscono API già disponibili.
Il codice compilato e le relative informazioni vengono organizzati in assembly, normalmente file .dll o .exe. L’assembly possiede un manifesto che descrive identità, versione, file e dipendenze.
Il termine codice gestito indica invece il codice la cui esecuzione è controllata dal runtime.
È una distinzione utile perché chiarisce il ruolo del CLR: non è soltanto un programma che “avvia” un file, ma l’ambiente che coordina l’esecuzione e fornisce servizi a quel codice.
.NET Framework vs .NET: le differenze che contano oggi
Il confronto .NET vs .NET Framework ha senso solo se si parte da una domanda concreta: devi mantenere qualcosa che esiste già oppure devi progettare un nuovo sistema?
Per il nuovo sviluppo, Microsoft considera .NET moderno la scelta preferenziale. .NET Framework rimane la soluzione corretta quando un’applicazione o una dipendenza richiede specificamente quella piattaforma.
| Aspetto | .NET Framework | .NET moderno |
|---|---|---|
| Sistema operativo | Windows | Windows, Linux, macOS e altri ambienti supportati |
| Scenario principale oggi | applicazioni esistenti e compatibility requirement | nuovo sviluppo e modernizzazione |
| Versioning | ramo 4.x con aggiornamenti in-place | major release distinte |
| Release corrente | 4.8.1 | .NET 10 LTS al 27/09/2026 |
| Web | ASP.NET storico, Web Forms e stack legacy | ASP.NET Core |
| Deployment | fortemente legato a Windows e al Framework installato | modelli più flessibili e versioni affiancabili |
| Evoluzione | manutenzione e supporto | sviluppo attivo della piattaforma |
La tabella non significa che un’applicazione moderna sia automaticamente migliore di un’applicazione Framework esistente.
Descrive piuttosto due contesti di progetto differenti.
Windows-only e sviluppo multipiattaforma
.NET Framework è una tecnologia Windows.
Questo vincolo può essere irrilevante se stai mantenendo un software desktop aziendale che funzionerà sempre su Windows. Diventa invece importante se stai progettando un servizio che deve essere distribuito anche su Linux o vuoi mantenere maggiore libertà sull’ambiente di hosting.
.NET moderno è multipiattaforma e consente di sviluppare ed eseguire applicazioni su sistemi operativi differenti.
Nel web, questa separazione riguarda soprattutto il backend.
Un frontend costruito con Angular, per esempio, può comunicare tramite API con un backend .NET senza che il framework client imponga la tecnologia server-side.
È la stessa separazione che conviene mantenere quando si ragiona sul ruolo di un full stack developer: front-end, backend e dati collaborano, ma restano livelli distinti.
Runtime, versioni e modello di aggiornamento
Qui emerge una differenza meno evidente.
Le release .NET Framework 4.x sono aggiornamenti in-place. Su Windows può essere presente una sola versione 4.x e una release successiva sostituisce quella precedente, come chiarisce la guida Microsoft alle versioni di .NET Framework su Windows.
.NET moderno segue invece un modello nel quale release maggiori differenti possono convivere e vengono gestite con un proprio ciclo di supporto.
Questa differenza ha conseguenze concrete.
Con Framework non devi pensare a 4.7, 4.8 e 4.8.1 come a tre runtime 4.x completamente indipendenti installati affiancati.
Con .NET moderno il versioning e il deployment sono progettati in modo diverso.
Perché per i nuovi progetti Microsoft raccomanda .NET
La motivazione non si riduce al fatto che “è più nuovo”.
.NET moderno offre un modello multipiattaforma, un ciclo di sviluppo attivo e gli stack correnti per applicazioni web e server.
Microsoft limita i motivi per scegliere ancora Framework a scenari specifici: applicazioni esistenti, dipendenze non disponibili sul nuovo stack o tecnologie Framework che non hanno un equivalente diretto.
Per questo non sceglierei .NET Framework per un nuovo backend soltanto perché il team conosce già C#.
C# non implica Framework.
Puoi utilizzare C# anche con .NET moderno.
Se stai confrontando gli stack possibili per il server, la guida dedicata al ruolo del web developer aiuta a distinguere linguaggio, runtime e responsabilità backend senza trasformare la scelta in una classifica assoluta di tecnologie.
Versioni di .NET Framework: cosa è ancora supportato
L’ultima release della linea è .NET Framework 4.8.1, pubblicata nel 2022.
Microsoft continua a indicare come supportate diverse release 4.x, oltre a .NET Framework 3.5 SP1. Il supporto delle versioni moderne del ramo 4.x segue però anche il lifecycle del sistema operativo Windows sul quale sono installate.
Per pianificare una manutenzione di lungo periodo conviene verificare direttamente le informazioni ufficiali sul ciclo di vita di .NET Framework, perché date e condizioni di supporto sono dati soggetti a cambiamento.
La documentazione corrente elenca ancora:
- .NET Framework 4.8.1;
- 4.8;
- 4.7.2;
- 4.7.1;
- 4.7;
- 4.6.2, con fine supporto prevista il 12 gennaio 2027;
- .NET Framework 3.5 SP1, con fine supporto prevista il 9 gennaio 2029.
Questa fotografia è inevitabilmente volatile: prima di pianificare un deployment o mantenere per anni una versione specifica, controlla sempre il lifecycle Microsoft corrente.
.NET Framework 4.8.1: la versione più recente
4.8.1 è il punto di arrivo del ramo .NET Framework 4.
Microsoft lo include nelle versioni recenti di Windows supportate e lo gestisce nel contesto del sistema operativo.
Questo produce una conseguenza pratica importante: molti utenti Windows recenti non devono scaricare manualmente l’ultima versione del Framework per il normale utilizzo.
È possibile che sia già presente nel sistema.
Se un’applicazione richiede una release 4.x meno recente, la soluzione normalmente non consiste nel disinstallare la versione nuova per tornare indietro.
Perché le versioni 4.x sono aggiornamenti in-place
Tutte le release dalla famiglia .NET Framework 4 sono aggiornamenti in-place.
Quando installi una versione successiva, quella release prende il posto della precedente nel ramo 4.x.
Microsoft specifica inoltre che, se Windows include già una versione 4.x più recente, non puoi installarne una precedente sullo stesso sistema.
Questo comportamento evita di accumulare più runtime 4.x indipendenti, ma rende importante verificare la compatibilità delle applicazioni legacy prima degli aggiornamenti in ambienti sensibili.
.NET Framework 3.5 e il caso Windows 11
Il ramo 3.5 è diverso.
.NET Framework 3.5 può convivere con il ramo 4.x e viene ancora usato per applicazioni che dipendono dalle generazioni precedenti della piattaforma.
Su Windows 11 c’è inoltre un cambiamento recente da conoscere.
Fino a Windows 11 25H2, .NET Framework 3.5 può essere gestito come componente opzionale di Windows.
A partire da Windows 11 26H1, build 28000, Microsoft distribuisce invece .NET Framework 3.5 tramite installer standalone e non più come normale componente Windows installabile nello stesso modo.
La procedura corrente è documentata nella guida Microsoft dedicata a .NET Framework 3.5 su Windows 11.
Questa è una delle ragioni per cui vecchie guide che spiegano semplicemente “apri Funzionalità Windows e seleziona .NET Framework 3.5” non sono più universalmente corrette.
La procedura dipende dalla versione di Windows.
Devo installare .NET Framework?
Non necessariamente.
Se utilizzi una versione recente di Windows, una release corrente del ramo 4.x può essere già inclusa nel sistema.
La prima regola è quindi non installare versioni a caso finché non sai cosa richiede il software.
Quando un programma Windows lo richiede davvero
Il caso più semplice è un’applicazione che mostra esplicitamente un requisito relativo a .NET Framework.
Può accadere con software aziendali, vecchi programmi desktop o applicazioni progettate per tecnologie che non sono state migrate al nuovo .NET.
Se il programma richiede il ramo 3.5 e non è presente, Windows può chiederti di installarlo.
Prima di procedere, controlla però:
- quale versione di Windows stai usando;
- quale Framework richiede realmente l’app;
- se il produttore offre una versione più recente del software;
- se il requisito riguarda 3.5 oppure il ramo 4.x.
Per un programma molto vecchio ha spesso più senso verificare prima se esiste una release aggiornata piuttosto che aggiungere immediatamente componenti legacy al sistema.
Come capire quale versione serve
Se devi semplicemente usare un programma, parti dalla documentazione del software.
Se invece devi diagnosticare un computer o un’applicazione aziendale, puoi verificare le versioni presenti.
Microsoft documenta diversi metodi per determinare quali versioni di .NET Framework sono installate, dal controllo delle applicazioni installate fino alla lettura del valore Release nel Registro di sistema per le release 4.5 e successive.
Non userei però il Registro come prima procedura per un utente che vuole soltanto avviare un’app.
È più utile seguire questa sequenza:
requisito del software → versione Windows → Framework già presente → installazione solo se necessaria
Runtime, Developer Pack e download: cosa cambia
Un altro errore frequente è scaricare il pacchetto sbagliato.
Il runtime serve a eseguire applicazioni.
Il Developer Pack è rivolto invece agli sviluppatori che devono creare un progetto destinato a una specifica release .NET Framework tramite strumenti come Visual Studio.
Quindi:
- devi usare un’app → ti interessa il runtime o il componente Windows richiesto;
- devi sviluppare o compilare verso una versione Framework precisa → può servirti il Developer Pack.
Per i download conviene utilizzare i canali ufficiali Microsoft, soprattutto perché installer e modalità di distribuzione possono cambiare con Windows.
Quando usare ancora .NET Framework e quando scegliere .NET
La decisione corretta dipende soprattutto dallo stato del software.
Un’app esistente ha vincoli che un progetto nuovo non possiede.
Mantenere un’applicazione esistente
Un software stabile che funziona su Framework non deve essere riscritto soltanto perché esiste una piattaforma più moderna.
Una migrazione ha costi, introduce rischio e richiede test.
Microsoft stessa osserva che, in molti casi, un’applicazione esistente può continuare su Framework mentre nuove componenti o servizi vengono sviluppati usando .NET moderno.
Questo approccio può essere particolarmente razionale in sistemi aziendali maturi dove:
- il software soddisfa ancora il business;
- le dipendenze sono stabili;
- il sistema operativo resta supportato;
- non esiste un requisito immediato per Linux, container o nuovi stack;
- il costo di una riscrittura sarebbe superiore al beneficio.
“Mantenere” non significa però congelare il software.
Sistema operativo, dipendenze, sicurezza e lifecycle continuano a richiedere attenzione.
Dipendenze e tecnologie realmente legate a .NET Framework
Alcune applicazioni non sono facilmente trasferibili perché utilizzano tecnologie disponibili soltanto nel Framework o dipendenze che non sono state portate a .NET moderno.
Microsoft cita esplicitamente, fra gli esempi, ASP.NET Web Forms, ASP.NET Web Pages e diversi scenari legati a Windows Workflow Foundation.
Le dipendenze di terze parti possono essere altrettanto importanti.
Un’applicazione può avere:
- librerie proprietarie;
- componenti commerciali;
- integrazioni con software aziendale;
- API obsolete;
- controlli desktop;
- sistemi di autenticazione o deployment specifici.
Prima di decidere una migrazione, l’inventario di queste dipendenze è più utile di qualsiasi slogan sul fatto che “il nuovo è migliore”.
Nuovi progetti, API e applicazioni moderne
Per un nuovo servizio web o una nuova API, la baseline cambia.
Se non hai dipendenze legacy, .NET moderno offre il percorso corrente.
Lo stesso vale quando stai scegliendo fra ecosistemi server-side diversi.
Node.js, Java, PHP, Python e .NET possono tutti essere utilizzati per costruire backend; la scelta dovrebbe derivare da carico applicativo, team, ecosistema, manutenzione e infrastruttura.
Quando l’applicazione viene distribuita in cloud, conta anche il contratto della piattaforma.
Una piattaforma PaaS può gestire runtime e sistema operativo per te, ma devi comunque verificare quali versioni .NET supporta, come gestisce gli aggiornamenti e quali vincoli introduce.
È un altro motivo per cui partire da .NET moderno tende a offrire più opzioni nei nuovi progetti.
Migrare da .NET Framework a .NET: quando ha senso
La migrazione ha senso quando risolve un problema reale o abilita una capacità che oggi manca.
Può essere importante se devi:
- adottare uno stack corrente per il nuovo sviluppo;
- eseguire il servizio su Linux;
- modernizzare un’applicazione web;
- passare ad ASP.NET Core;
- semplificare deployment e containerizzazione;
- eliminare dipendenze non più supportate;
- preparare il prodotto a una manutenzione di lungo periodo.
Non è invece una decisione da prendere soltanto perché il progetto contiene un numero di versione vecchio.
Perché non tutte le applicazioni devono migrare subito
Una migrazione porta valore quando il beneficio compensa complessità e rischio.
Se l’applicazione è stabile, interna, limitata a Windows e supportata dalle tecnologie utilizzate, mantenere Framework può essere una scelta razionale.
La situazione cambia quando il sistema diventa difficile da aggiornare, dipende da componenti fuori supporto oppure limita nuove esigenze architetturali.
La domanda corretta è quindi:
Quale problema risolve la migrazione?
Se non riesci a rispondere, è difficile stabilire una priorità seria.
Librerie, ASP.NET Web Forms, WCF e altri vincoli
Prima di migrare serve un inventario.
Controlla almeno:
- target Framework dei progetti;
- pacchetti NuGet;
- librerie proprietarie;
- API Windows-specific;
- componenti COM o nativi;
- ASP.NET Web Forms;
- WCF e workflow;
- autenticazione;
- accesso ai dati;
- sistemi di configurazione;
- build e deployment.
Alcuni componenti possono essere portati con poche modifiche. Altri richiedono una riprogettazione.
Web Forms, per esempio, non viene semplicemente “ricompilato” in ASP.NET Core.
Anche per questo una modernizzazione incrementale può essere migliore di una grande riscrittura unica.
Valutare la migrazione partendo dalle dipendenze, non dal numero di versione
Il tooling Microsoft è cambiato anche recentemente.
Per anni molte guide indicavano .NET Upgrade Assistant come strumento principale per analizzare e convertire progetti.
Oggi Microsoft lo considera deprecato: la documentazione dell’Upgrade Assistant rimanda al percorso di modernizzazione corrente integrato nell’ecosistema Visual Studio.
È un buon esempio di come affrontare una migrazione: non partire da un tutorial vecchio e applicare meccanicamente gli stessi strumenti.
Parti invece da:
dipendenze → incompatibilità → priorità → strategia → strumenti correnti → test
Anche il tooling di modernizzazione è una parte volatile del processo e va verificato prima di iniziare.
Domande frequenti su .NET Framework
.NET Framework è obsoleto?
Non nel senso di “prodotto abbandonato”.
Microsoft continua a supportare .NET Framework nelle versioni e nei sistemi operativi previsti dal lifecycle. 4.8.1 resta la release più recente e il ramo 4.x continua a ricevere aggiornamenti nel contesto delle versioni Windows supportate.
È però una piattaforma legacy-oriented rispetto al nuovo sviluppo.
Per un progetto nuovo, senza vincoli specifici, il riferimento è .NET moderno.
Quindi “supportato” e “consigliato per iniziare un progetto nuovo” sono due domande differenti.
Posso disinstallarlo da Windows?
Dipende dalla versione.
Le release moderne del ramo 4.x sono strettamente integrate con Windows e, nelle versioni recenti del sistema operativo, una release Framework è già inclusa.
.NET Framework 3.5 può invece essere un componente opzionale o, a partire da Windows 11 26H1, essere installato separatamente tramite il modello standalone.
Non rimuoverei un componente soltanto perché appare “vecchio”.
Prima controlla se qualche applicazione dipende da quella versione. Rimuovere un runtime richiesto può semplicemente impedire al programma di avviarsi.
.NET Framework funziona su Linux o macOS?
.NET Framework propriamente detto è una tecnologia Windows.
Se devi progettare un’applicazione che deve funzionare nativamente su Windows, Linux e macOS, devi guardare a .NET moderno, non a Framework.
Questa distinzione vale soprattutto per i nuovi progetti.
Un software Framework esistente non diventa automaticamente multipiattaforma cambiando ambiente di deployment: potrebbe richiedere una vera migrazione.
Conclusione
Il modo più utile per interpretare .NET Framework oggi è smettere di chiedersi se sia “morto” o “ancora moderno”.
Sono domande troppo generiche.
Se devi eseguire un vecchio programma, installa o abilita solo la versione realmente richiesta e verifica prima ciò che Windows contiene già.
Se devi mantenere un’applicazione esistente, Framework può continuare a essere una piattaforma legittima finché sistema operativo, dipendenze e lifecycle restano supportati.
Se devi iniziare un nuovo progetto, salvo un requisito concreto di compatibilità, partirei da .NET moderno.
Se devi modernizzare un sistema, non iniziare dalla riscrittura: inventaria dipendenze, tecnologie legacy e vincoli di deployment, poi decidi quali parti spostare e in quale ordine.
La distinzione decisiva è questa: .NET Framework oggi è soprattutto una piattaforma di compatibilità e continuità; .NET moderno è il percorso principale per costruire il futuro dell’ecosistema.