Elenco di controllo pre-migrazione per il passaggio da .NET Framework a .NET

Scarica la checklist Excel con fogli giapponesi e inglesi

Cambia TargetFramework in .csproj in net10.0, aggiorna alcuni pacchetti NuGet e, una volta completata la compilazione, il gioco è fatto.

…Se questa fosse la migrazione, la vita sarebbe piuttosto tranquilla. In realtà, di solito non lo è.

Le basi di codice .NET Framework sono piene di presupposti dormienti a cui normalmente non pensi mai: System.Web, WCF, Web Form, vecchi file packages.config, web.config.install.xdt, nativo DLLs, COM / ActiveX, controlli di terze parti che funzionano solo in fase di progettazione, presupposti impliciti x86, dipendente dal designer ResX, vecchio serializzatori e altro ancora.

Pertanto, ciò che conta davvero in una migrazione da .NET Framework a .NET è il lavoro di inventario prima di iniziare l’implementazione. Se riesci a scomporre i problemi prima di iniziare, la migrazione smetterà di essere “una grande scommessa” e diventerà “un elenco di elementi da eliminare in ordine”.

In questo articolo vengono riepilogati gli elementi da verificare prima di eseguire la migrazione di un’applicazione line-of-business .NET Framework 4.x esistente all’attuale .NET. Gli obiettivi principali sono da queste parti:

• Biblioteche di classi
• Applicazioni della console
• Servizi Windows
• WinForms / WPF
• Framework ASP.NET (MVC / API Web / Moduli Web)
• Applicazioni che utilizzano WCF
• Applicazioni che utilizzano EF6

Questo è stato scritto il 15-03-2026. Le finestre di supporto e i consigli ufficiali sugli strumenti cambiano, quindi se stai leggendo questo articolo molto più tardi, controlla anche le informazioni ufficiali.

1. Prima la conclusione

Innanzitutto, le conclusioni che sono difficili da sbagliare.

• Ripulisci il lato .NET Framework prima della migrazione. La guida ufficiale di Microsoft consiglia inoltre di eseguire l’aggiornamento a .NET Framework 4.7.2 o versione successiva prima del porting e di completare prima la conversione PackageReference, la conversione in stile SDK e gli aggiornamenti delle dipendenze.
• La difficoltà è determinata dal modello dell’app, non dal volume del codice. Le librerie di classi e le app console sono relativamente leggere; ASP.NET Framework, Web Form, server WCF e WF tendono ad essere pesanti.
• WinForms / WPF può migrare a .NET ma rimane solo per Windows. Se fraintendi questo, cadrai nella classica mina terrestre della migrazione solo per scoprire che l’app non verrà eseguita in un contenitore Linux.
• ASP.NET Framework → ASP.NET Core è effettivamente una migrazione dell’architettura. Le piccole app a volte possono essere completate in un colpo solo, ma per i sistemi di produzione di grandi dimensioni è più sicuro pianificare una migrazione incrementale.
• WCF e EF6 a volte possono essere disaccoppiati dalla migrazione del runtime. I client WCF hanno pacchetti supportati per .NET e EF6 può essere migrato a EF Core separatamente dopo il passaggio al moderno .NET.
• D’altra parte, la creazione di AppDomain, .NET Remoting, CAS, COM+, Workflow Foundation e le dipendenze BinaryFormatter sono luci rosse. Trovateli presto, altrimenti lo sforzo esploderà più tardi.
• packages.config / install.ps1 / XDT / content asset / nativi DLLs / COM / ActiveX / x86 presupposti tendono a fallire in fase di esecuzione o di progettazione anche quando la compilazione viene completata, quindi eliminali prima di iniziare.
• A partire dal 03 / 2026, .NET 10 è LTS. Per le nuove migrazioni, è naturale prendere di mira l’attuale LTS come punto di approdo.
• Una migrazione senza test, misurazioni e un piano di rollback è pericolosa. La migrazione non è tanto un’attività di implementazione quanto un lavoro volto a rendere visibili le ipotesi, una alla volta.

2. Decidi innanzitutto se è il caso di migrare adesso

La prima cosa da decidere non è “come eseguire la migrazione”, ma se è davvero il caso di eseguire la migrazione di questa app in questo momento.

Se lasci questo concetto sul vago, finirai per ritrovarti con una migrazione tecnicamente corretta ma troppo pesante per l’azienda, o il contrario: posticipare troppo a lungo quando la migrazione è chiaramente la scelta giusta.

2.1 Rimanere nel .NET Framework è una decisione perfettamente valida

.NET Framework 4.8.1 continua a essere supportato purché venga eseguito su un sistema Windows supportato. In altre parole, non è così semplice come “se non sposti tutto sul moderno .NET adesso, sei immediatamente a rischio”.

Restare, tuttavia, comporta vincoli chiari.

• Non puoi evitare di essere solo Windows
• Continui a portare con te ASP.NET Web Form e vecchi stack di server
• È più difficile trarre vantaggio dai nuovi miglioramenti delle prestazioni di .NET, delle funzionalità linguistiche e dell’ecosistema

• Ti allontani dai presupposti moderni di cloud, container e CI / CDAl contrario, se le dipendenze come le seguenti sono forti, è razionale consolidarsi su .NET Framework 4.8.1 per un funzionamento stabile per ora, pianificando la sostituzione su un percorso separato.

• Un ampio stock di schermate di moduli Web
• È necessario preservare la rigorosa compatibilità del server WCF
• Dipendenze di Deep Workflow Foundation o COM+
• I componenti in fase di progettazione di terze parti non supportano il moderno .NET
• L’azienda non consente modifiche sostanziali alle specifiche

2.2 Cosa cambia con ciascuna opzione

Ciò che conta non è decidere prima se vuoi migrare ma dove vuoi sbarcare dopo la migrazione.

3. Quattro politiche da decidere in anticipo

3.1 La versione target .NET

Al momento in cui scrivo, secondo la politica di supporto di Microsoft, .NET 10 è LTS. Nel frattempo, .NET 8 LTS e .NET 9 STS dovrebbero entrambi raggiungere la fine del supporto il 2026-11-10.

Quindi, se stai iniziando una nuova migrazione al largo del .NET Framework, salvo circostanze eccezionali, atterrare sull’attuale LTS è la scelta naturale.

Il ragionamento pratico qui è semplice.

• Per una piccola migrazione che desideri eseguire rapidamente, atterra direttamente sull’attuale LTS
• Per un sistema principale destinato al funzionamento a lungo termine, considerare comunque l’attuale LTS come riferimento
• “Vogliamo il precedente LTS a causa di una libreria esistente” è un motivo legittimo, ma giudicalo controllando l’effettiva data di fine della manutenzione

3.2 Rimanere solo su Windows o puntare al multipiattaforma in un secondo momento?

Questa decisione cambia radicalmente le questioni a cui devi prestare attenzione.

• Se rimani solo su Windows, puoi intraprendere prima il percorso pragmatico di modernizzazione del runtime, utilizzando WPF / WinForms e il pacchetto di compatibilità Windows.
• Se si intende puntare a Linux / alla containerizzazione in un secondo momento, è necessario eseguire in anticipo l’inventario di API associato a Windows: System.Drawing.Common, il registro, WMI, EventLog, servizi Windows, COM, Office Interop e così via.

Inizia la migrazione senza decidere e, a metà strada, la conversazione si trasforma: “Dopo tutto andava bene solo Windows?” “No aspetta, volevamo correre in container.”

3.3 One Shot o Incrementale?

Esistono sostanzialmente tre forme di migrazione.

• Migrazione quasi sul posto, completa
• Migrazione affiancata che esegue il vecchio e il nuovo in parallelo
• Migrazione incrementale, spostamento percorso per percorso o biblioteca per biblioteca

Soprattutto per le app ASP.NET Framework, le indicazioni di Microsoft consigliano esplicitamente la migrazione incrementale. Se non è possibile interrompere la produzione, si hanno molte funzionalità e molte dipendenze circostanti, è meno faticoso progettare una migrazione incrementale fin dall’inizio.

3.4 Cosa escludere da questa migrazione

Le migrazioni tendono a fallire perché si accumulano troppe risorse.

Ad esempio, fare tutte queste cose contemporaneamente tende a diventare pesante:

• .NET Framework → .NET
• ASP.NET Quadro → ASP.NET Core
• EF6 → EF Nucleo
• Server Windows → Contenitori Linux
• Modifica dell’infrastruttura di autenticazione
• Modifica dell’infrastruttura di registrazione / monitoraggio
• Migrazione del database

Naturalmente, alla fine potrebbero essere tutti necessari. Ma se debbano essere fatti contemporaneamente è una questione separata.

In realtà, separare cose come questa funziona meglio:

1. Per prima cosa modernizzare il runtime e la struttura del progetto
2. Quindi sposta il modello dell’app
3. Infine aggiorna ORM, autenticazione, cloud e monitoraggio

4. Le basi da preparare prima di iniziare

La guida pre-porting di Microsoft è abbastanza pratica. In sostanza: prima della migrazione, porta i tuoi attuali progetti .NET Framework a un punto di ingresso moderno.

4.1 Aggiornamento a .NET Framework 4.7.2 o successivo

La guida ufficiale consiglia di scegliere come target .NET Framework 4.7.2 o versione successiva prima del porting. Il motivo è che anche quando .NET Standard non supporta un’API esistente così com’è, diventa più semplice spostarsi verso alternative API più recenti.

In pratica, è più chiaro utilizzare 4.8.1 come riferimento, se possibile.

• Semplice dal punto di vista del supporto
• Facile da trattare come punto stabile finale sul lato .NET Framework
• Semplifica l’attuazione della politica di “primo risanamento del quadro attuale”.

Cosa cambia se lo fai prima

• La gestione delle librerie condivise .NET Standard 2.0 si stabilizza più facilmente
• Il rumore proveniente dal vecchio runtime è stato ridotto in anticipo
• Diventa più semplice capire se un problema di compatibilità è causato dal “quadro vecchio” o dal “passaggio al moderno .NET”

4.2 Sposta a PackageReference

La guida pre-porting consiglia di convertire i riferimenti nel formato PackageReference. Eseguire prima questa operazione migliora significativamente la visibilità nella gestione delle dipendenze.

Cosa cambia con PackageReference

• I riferimenti ai pacchetti sono consolidati in csproj
• Le dipendenze transitive diventano più facili da vedere
• I presupposti del ripristino sono in linea con il lato moderno .NET
• Migliore compatibilità con CLI / CI

Tuttavia, qui ci sono mine antiuomo.

Tipiche mine antiuomo

La documentazione ufficiale di NuGet elenca esplicitamente questi vincoli per la migrazione da packages.config a PackageReference:

• La migrazione integrata diVisual Studio non può essere utilizzata per progetti ASP.NET
• I pacchetti che dipendono da install.ps1 / uninstall.ps1 potrebbero non funzionare come previsto
• Le risorse nella cartella content potrebbero essere ignorate
• Le trasformazioniXDT come web.config.install.xdt non vengono applicate
• I pacchetti con vecchi layout di assieme direttamente sotto lib potrebbero non risolversi bene

In altre parole, non considerarlo come un semplice cambiamento del formato del pacchetto. Il classico ASP.NET in particolare aveva una forte cultura della riscrittura di web.config al momento dell’installazione del pacchetto NuGet, quindi i presupposti impliciti emergono facilmente durante la migrazione.

4.3 Passare a progetti in stile SDK

La guida pre-porting consiglia inoltre la conversione al formato di progetto in stile SDK.

Questo ripaga sostanzialmente.

Cosa cambia con lo stile SDK

• Il csproj diventa notevolmente più conciso
• Funziona bene con PackageReference
• Il multi-targeting diventa facile
• Più facile centrare CI / CD su dotnet build / dotnet test / dotnet publish
• La configurazione si avvicina al lato moderno .NET, riducendo la differenza nella fase successiva

Mettiamola al contrario: saltare direttamente al moderno .NET con i vecchi file csproj e la vecchia gestione NuGet produce una differenza troppo grande.

4.4 Aggiornare prima le dipendenze

Anche questo segue la guida ufficiale: spostare le dipendenze nelle ultime versioni disponibili e, ove possibile, nelle .NET versioni compatibili con Standard.

Perché farlo prima

• Scopri in anticipo se “questo pacchetto funziona sul moderno .NET”
• Impedisce che le vecchie dipendenze diventino rumore
• Semplifica la conversione delle librerie condivise in netstandard2.0
• Consente al successivo lavoro di migrazione di concentrarsi sul “porting del codice”

4.5 Verificare anche le ipotesi degli strumenti ufficiali

A partire dal 2026-03, il centro di gravità delle linee guida di Microsoft si è spostato verso la GitHub Modernizzazione dell’app Copilot. Piuttosto che assumere solo i tradizionali strumenti di assistenza alla migrazione, è meglio considerarlo come un flusso di supporto end-to-end che copre valutazione, pianificazione, correzioni del codice e convalida.

Tuttavia, la documentazione attuale presuppone Visual Studio 2026 o una linea Visual Studio 2022 supportata, GitHub Copilot e C# codice.

Perché è necessario questo controllo

• Cambia ciò che puoi aspettarti dagli strumenti ufficiali
• Puoi allineare le ipotesi del team su IDEs / build agent / estensioni
• Puoi effettuare la chiamata per non fare eccessivo affidamento sull’automazione per le soluzioni VB.NET

Le basi di codice con VB.NET mescolato non sono rare. Quindi vale la pena confermare, fin dall’inizio, “fino a che punto gli ultimi strumenti ufficiali saranno effettivamente di aiuto”.

5. Stima della difficoltà per tipo di progetto

La migrazione tende a essere discussa come un unico blocco - da “.NET Framework a .NET” - ma in realtà ogni tipo di progetto è un gioco diverso.

5.1 Un senso approssimativo di difficoltà

5.2 Per le librerie di classi, la chiave è come tagliare il “confine condiviso”

Le librerie di classi sono relativamente facili da spostare. Ma solo quando la biblioteca è veramente separata come una biblioteca.

Dipendenze come le seguenti aumentano la difficoltà:

• Toccando System.Web
• Leggere direttamente HttpContext.Current
• Esposizione dei tipi WPF / WinForms nell’API pubblica
• Appoggiarsi pesantemente su Windows API come il registro, WMI, EventLog
• A seconda di AppDomain o Remoting

Un’inquadratura utile: se riesci a estrarre la pura logica aziendale, è leggero; se la libreria ha fagocitato il modello dell’app, è pesante.

5.3 WinForms / WPF Migra facilmente, ma rimani solo Windows

WinForms e WPF possono essere migrati a .NET. Tuttavia, entrambi rimangono framework solo Windows.

Sbagliare le aspettative qui è pericoloso.

• Cosa migliora
  • Ottieni il runtime, la lingua e lo stile SDK moderni .NET
  • CI / CD e la gestione dei pacchetti possono essere aggiornati
  • Vengono apportati alcuni miglioramenti alle prestazioni e alla manutenibilità
• Cosa non cambia
  • È ancora solo per Windows
  • Permangono problemi di compatibilità con i controlli dell’UI e i componenti in fase di progettazione
  • I problemi ActiveX / COM / nativi DLL non scompaiono

Inoltre, WinForms / WPF può richiedere una revisione dell’impatto BinaryFormatter. Soprattutto quando i tipi personalizzati sono coinvolti negli appunti, nel trascinamento della selezione, in ResX o nella serializzazione in fase di progettazione, il problema tende a emergere quando si aumenta la destinazione a .NET 9 o versione successiva.

5.4 ASP.NET Framework è una “migrazione del modello di app” e non una “migrazione del runtime”

La migrazione da ASP.NET Framework a ASP.NET Core è esplicitamente descritta come non banale nelle linee guida di Microsoft. Non semplicemente perché i nomi delle API cambiano, ma perché l’architettura sottostante è diversa.

Le differenze tendono a manifestarsi da queste parti:

• Modello di hosting
• Pipeline del middleware
• Modello di elaborazione della richiesta
• Sessione / Cache
• Autenticazione / Autorizzazione
• Configurazione
• Iniezione di dipendenze
• Registrazione / monitoraggio

Per un’app ASP.NET Framework, le cose da controllare prima sono qui:

• Quali percorsi / endpoint possono essere spostati per primi
• Se le dipendenze System.Web possono essere rimosse dalle librerie condivise
• Come allineare autenticazione / sessione / gestione delle eccezioni / registrazione
• Se migrare in modo incrementale senza interrompere la produzione

Per le app di grandi dimensioni in particolare, è più realistico ipotizzare una migrazione incrementale fin dall’inizio.

5.5 Per i moduli Web, iniziare con “Scomposizione delle responsabilità” e non con “Migrazione delle risorse”

Web Forms non è lo stesso modello di app di ASP.NET Core. Pertanto, a fini di stima, è più sicuro non dare per scontato che le risorse dello schermo possano essere trasferite così come sono.

In pratica, il solito punto di ingresso è questa scomposizione:

• Separare la logica dello schermo dalla logica aziendale
• Suddividere le responsabilità sepolte in Page / UserControl / ViewState
• Sposta la logica aziendale e l’accesso ai dati nelle librerie condivise
• Ricostruisci l’UI su un modello diverso: Razor Pages / MVC / Blazor, ecc.

In altre parole, per i progetti Web Form, l’eventuale presenza di un piano di scomposizione delle responsabilità conta più della migrazione del runtime stessa.

5.6 Trattare separatamente i client WCF e i server WCF

Non raggrupparli insieme.

WCF clienti

Il client WCF ha supportato i pacchetti NuGet per i moderni .NET. Quindi se chiami solo WCF, il lavoro può essere più leggero di quanto sembri.

WCF server

L’hosting dei servizi WCF, d’altra parte, è una storia diversa. Le linee guida di Microsoft presentano due ampi percorsi di modernizzazione:

• Utilizzare CoreWCF per preservare la compatibilità con i client esistenti
• Passa ai moderni stack basati su RPC / HTTP come gRPC

Tieni presente che CoreWCF è un sottoinsieme: non riporta tutto WCF così com’è. È adatto a preservare la compatibilità con i client esistenti, ma le modifiche al codice e i test sono scontati.

6. Elimina le tecnologie che non funzionano su .NET o si bloccano facilmente

Questo è qualcosa che vuoi assolutamente fare prima di iniziare. Microsoft mantiene un elenco di tecnologie disponibili su .NET Framework che non sono disponibili su .NET 6+.

6.1 Tecnologie che tendono ad essere luci rosse

6.2 AppDomain: “Alcuni API rimangono, ma la creazione è un’altra questione”

L’area AppDomain è un po’ complicata. Parte della superficie API rimane su .NET, ma il modello di utilizzo di creazione di un nuovo AppDomain per l’isolamento non è supportato.

Pertanto, se hai utilizzato AppDomains per i seguenti scopi, è necessaria una riprogettazione:

• Isolamento dei plugin
• Scaricamento del codice caricato dinamicamente
• Isolamento del codice parzialmente attendibile
• Separazione temporanea degli ambienti di esecuzione

Quello che dovresti controllare prima della migrazione non è solo se appare la parola AppDomain, ma per cosa veniva utilizzato AppDomain.

6.3 La comunicazione remota è “più profonda di quanto sembri”

Il servizio remoto stesso, ovviamente, ma anche le chiamate asincrone dei delegati come BeginInvoke() / EndInvoke() sui delegati possono rientrare nell’area interessata. Non si tratta di servizi remoti di per sé, ma non è supportato sui moderni .NET, quindi deve essere eliminato prima della migrazione.

Quindi, durante la ricerca, è più sicuro guardare insieme questo set:

• System.Runtime.Remoting
• MarshalByRefObject
• RealProxy
• BeginInvoke( / EndInvoke(

6.4 BinaryFormatter viene improvvisamente alla ribalta a seconda della versione di destinazione

Più vecchia è la base di codice, più è probabile che BinaryFormatter venga utilizzato “senza consapevolezza”.

• Dati persistenti
• Cache
• Sessione storage
• Stato del plugin
• Appunti / trascina e rilascia
• ResX
• WinForms / WPF ambienti di design

In .NET 9 e versioni successive, l’implementazione di BinaryFormatter non è inclusa nel runtime e l’API genera sempre PlatformNotSupportedException. Quindi questo non è un elemento “pensaci più tardi” — è un elemento di controllo nel momento in cui decidi la versione di destinazione.

6.5 Cercare innanzitutto i termini in Grep

Prima di iniziare, basta eseguire ricerche sull’intera soluzione con i seguenti termini per cambiare notevolmente il quadro.

System.Web
HttpContext.Current
System.Runtime.Remoting
MarshalByRefObject
AppDomain
BinaryFormatter
ServiceHost
ChannelFactory
System.EnterpriseServices
Workflow
packages.config
web.config.install.xdt
install.ps1
DllImport
AxInterop
Microsoft.Office.Interop

Trovarne anche solo uno non significa fallimento immediato. È una mappa per sapere quali parti possono migrare sul percorso standard e quali diventare una traccia separata.

Comandi di ricerca concreti

Lo strumento può essere rg (ripgrep) o PowerShell.

# PowerShell: cerca sotto l'intera soluzione
Get-ChildItem -Recurse -Include *.cs,*.vb,*.config,*.csproj,*.vbproj |
    Select-String -Pattern 'BinaryFormatter|System\.Runtime\.Remoting|MarshalByRefObject|AppDomain\.CreateDomain' |
    Select-Object Path, LineNumber, Line

# ripgrep: per capire la mole prima di entrare nel dettaglio
rg -n --stats "BinaryFormatter|System\.Runtime\.Remoting|AppDomain\.CreateDomain" --glob "*.cs" --glob "*.vb"

Trovato: cosa fare dopo

La ricerca è solo l’ingresso; la decisione successiva è quella che conta. Per ogni termine, la prossima cosa da guardare è più o meno fissata.

Arrivati a questo punto, la domanda non è più “possiamo migrare?” ma “quali parti sono sul percorso standard e quali richiedono una stima separata”. Questa tabella è esattamente ciò che vuoi prima di iniziare.

7. Decidere quanta dipendenza solo Windows accettare

Un malinteso comune nelle migrazioni è “una volta che siamo su .NET, siamo multipiattaforma”. Non esiste una tale magia. Se l’app è profondamente legata a Windows, chiaramente rimane solo per Windows dopo la migrazione.

7.1 La migrazione rimanendo solo su Windows è del tutto realistica

Microsoft fornisce Windows Compatibility Pack, un modo per utilizzare molti servizi API orientati a Windows (il registro, WMI, EventLog, Windows servizi, servizi di directory e così via) dal moderno .NET.

La sua esistenza conta molto nella pratica.

• Prima vogliamo passare al moderno .NET
• Ma non lasceremo il Windows per ora
• Quindi per il momento vogliamo accettare le dipendenze Windows API

Per le squadre in quella situazione, è un’opzione forte.

Il primo obiettivo di una migrazione non deve essere necessariamente il passaggio alla piattaforma multipiattaforma.

7.2 Ma i API solo per Windows sono anche “debiti che mordono più tardi”

L’esistente Windows Compatibility Pack non rende tutto sicuro.

• Vuoi eseguire in contenitori Linux
• Vuoi eseguire Kubernetes
• Vuoi che gli sviluppatori macOS / Linux eseguano la stessa build
• Un giorno vuoi ridurre Windows VMs nel cloud

Se hai obiettivi come questi, è meglio rendere visibili le dipendenze Windows API ora.

7.3 System.Drawing.Common è particolarmente spesso frainteso

System.Drawing.Common è una libreria solo Windows su .NET 6 e versioni successive. Se disponi di codice che lo utilizza per l’elaborazione delle immagini o il rendering del testo, devi prima decidere quale strada percorrere.

• Continuare a operare su Windows?
• O vuoi che venga eseguito su Linux / macOS in futuro?

Nel primo caso, lasciare tutto così com’è per ora può andare bene. In quest’ultimo caso, nel piano di migrazione deve essere presente fin dall’inizio un sostituto: SkiaSharp, ImageSharp, ecc.

7.4 Odori tipici che indicano Windows Lock-In

Quando sono presenti riferimenti o API come i seguenti, è più sicuro fare una stima partendo dal presupposto di “migrare rimanendo solo su Windows, almeno all’inizio”.

• Microsoft.Win32.Registry
• System.Management
• System.Diagnostics.EventLog
• System.ServiceProcess
• System.DirectoryServices
• System.Drawing
• DllImport / P/Invoke
• Riferimenti COM
• AxInterop.*
• Microsoft.Office.Interop.*

8. Il modo in cui si ritagliano le librerie condivise cambia la difficoltà

Per soluzioni più grandi, non è esagerato affermare che il successo della migrazione è determinato dal modo in cui vengono eliminate le librerie condivise.

8.1 Classificare prima

Le biblioteche sono più facili da organizzare se divise in tre grandi tipologie.

1. Pura logica aziendale / logica di dominio
2. Strati intermedi con qualche dipendenza dal modello di app
3. Livelli strettamente collegati a UI / Web / Windows API

Di questi, il primo a migrare dovrebbe essere il tipo 1.

• Calcoli
• Valutazione delle regole
• DTOs / contratti
• Servizi di dominio
• Trasformazioni semplici di dati

Se riesci a estrarlo in modo pulito, la difficoltà diminuisce drasticamente.

8.2 netstandard2.0 è ancora un ponte valido

Secondo le indicazioni di Microsoft, per una libreria condivisa che deve coesistere anche con il lato .NET Framework, la linea di base è considerare prima .NET Standard 2.0.

Qui contano due punti.

• .NET Framework non supporta .NET Standard 2.1
• Se desideri una libreria condivisa con riferimenti sia vecchi che nuovi, 2.0 tende ad essere la risposta pratica

8.3 Cosa cambia con netstandard2.0

8.4 La modalità di compatibilità non è una panacea

.NET Standard 2.0 ha una modalità di compatibilità che consente di fare riferimento alle librerie .NET Framework. Tuttavia, questa non è una magia che fa funzionare tutto in modo trasparente.Ad esempio, le librerie che presuppongono API specifico del modello di app come WPF sono chiaramente difficili. In altre parole, anche quando si parla di “biblioteca condivisa”, è importante restringere il campo alle responsabilità che possono veramente essere condivise.

8.5 Per le biblioteche legate a ASP.NET, la battaglia è se si riesce a staccare System.Web

Durante la migrazione incrementale di ASP.NET Framework, avere librerie condivise che si bloccano direttamente su HttpContext.Current o System.Web è piuttosto doloroso.

Le strategie di base a quel punto sono una di queste:

• Spingere la dipendenza System.Web all’esterno dell’interfaccia
• Modificare il codice per ricevere informazioni derivate da HttpContext come DTOs
• Utilizzare gli adattatori durante il periodo di transizione
• Se il problema persiste, rimuovilo gradualmente con il multi-targeting

8.6 Creazione delle librerie con la prima foglia

La guida alla migrazione incrementale ASP.NET dice esplicitamente di aggiornare le librerie di supporto postorder deep-first, ovvero dalle foglie in su.

Questo è abbastanza efficace anche per soluzioni generali, non solo per il web.

• Poiché le dipendenze vengono aggiornate per prime, i livelli superiori diventano più facili da vedere
• I problemi di compatibilità sono più facili da localizzare
• Il test per libreria diventa più semplice

9. Fai l’inventario di NuGet / Dipendenze esterne / Componenti di terze parti

Se lo fai in modo sciatto, soffrirai il dolore peggiore nella seconda metà della migrazione.

9.1 Le dipendenze sono più facili da organizzare in 4 categorie

1. Pacchetti pubblici NuGet
2. Pacchetti privati interni / biblioteche interne
3. Riferimenti DLL locali
4. COM / ActiveX / nativo DLLs / SDKs

Guardare solo alla categoria 1 non è sufficiente. Quelli veramente pericolosi sono 3 e 4.

9.2 Cosa verificare per ciascuna dipendenza

Per ogni dipendenza, verifica almeno questo:

• Ha come target il moderno .NET?
• Supporta PackageReference?
• Va bene con i progetti in stile SDK?
• Eventuali vincoli x86 / x64 / ARM64?
• Dipende dagli strumenti in fase di progettazione o dalle estensioni Visual Studio?
• Presuppone script di installazione / trasformazioni di configurazione?
• È ancora supportato?

9.3 Stima separata dell’UI / dei report / dei componenti in fase di progettazione di terze parti

Per le migrazioni WinForms / WPF / ASP.NET, quest’area è molto importante.

• Griglie
• Motori di reporting
• Componenti di uscita PDF
• Componenti grafici
• Librerie dell’UI integrate nel designer
• Involucri ActiveX

Questi riguardano il supporto in fase di progettazione, non solo il runtime. Se la tua stima di migrazione controlla solo “è compilato”, chiaramente ti mancheranno.

9.4 Controlla sempre Native DLLs e Bitness

Anche se le cose sembravano andare come AnyCPU nell’era .NET Framework, in realtà potrebbero dipendere da cose come:

• COM fisso su x86
• Solo 32 bit ActiveX
• Una versione specifica del runtime VC__++
• Firmato nativo DLLs

Questi non sono problemi emersi improvvisamente con il passaggio al moderno .NET: vincoli che sono sempre stati presenti semplicemente emergono. Proprio per questo vale la pena renderli visibili prima della migrazione.

10. Tratta EF6, serializzatori e livello dati come problemi separati

La migrazione del runtime e la riprogettazione dell’accesso ai dati e della serializzazione funzionano meglio se trattate come problemi separati, ove possibile.

10.1 EF6 → EF Core non è un aggiornamento diretto

Le linee guida EF di Microsoft affermano inoltre che EF Core è una riscrittura totale di EF6 e non esiste un percorso di aggiornamento diretto.

Pertanto, per le app che utilizzano EF6, questo ordine è realistico:

1. Primo passaggio al moderno .NET
2. Conserva EF6 se necessario ed esegui l’app
3. Quindi migrare a EF Core come progetto separato

Non combinare la migrazione del runtime con la migrazione del ORM. Questo da solo riduce notevolmente la difficoltà.

10.2 Cosa cambia se mantieni EF6

• Aspetti positivi
  • La differenza del livello di accesso ai dati può essere differita
  • Puoi concentrarti sulla migrazione della logica aziendale e del modello di app
  • Le “EF differenze comportamentali fondamentali” non vengono confuse
• Avvertenze
  • Per i nuovi sviluppi, EF Core è la linea principale
  • I modelli di utilizzo di EF6 Designer / EDMX hanno vincoli separati

10.3 Per EDMX-Based EF6, guarda fino al “Design Time”

La documentazione di EF6 afferma che il EF Designer non è direttamente supportato nei progetti .NET / .NET Standard o nei progetti SDK in stile .NET Framework.

Per le app basate su EDMX, devi considerare questi tre punti separatamente:

• Funziona in fase di runtime?
• È possibile utilizzare il Designer?
• Come verrà gestito il codice generato?

Se usi molto EDMX, è più sicuro inserirlo nel preventivo fin dall’inizio.

10.4 BinaryFormatter e la serializzazione personalizzata diventano facilmente “dipendenze nascoste”

I serializzatori sono facili da perdere con la sola ricerca del codice.

• Formati di persistenza
• Messaggistica
• Cache
• Vecchi contratti WCF / SOAP
• ResX
• Appunti / trascina e rilascia

Quest’area riguarda anche la compatibilità dei dati. Cioè, devi verificare non solo “fa costruire”, ma può ancora leggere i vecchi dati.

11. Includere Configurazione, Distribuzione, Operazioni e CI / CD nell’ambito della migrazione

L’obiettivo della migrazione non è solo il codice sorgente.

11.1 File di configurazione

Sul lato .NET Framework, si può pedalare parecchio in app.config / web.config.

• Stringhe di connessione
• Sezioni di configurazione personalizzate
• Configurazione dell’endpoint WCF
• Reindirizzamenti vincolanti
• Diagnostica
• Varie impostazioni ASP.NET
• I risultati delle trasformazioni applicate al momento dell’installazione del pacchetto

Dal punto di vista moderno .NET, il modo in cui la configurazione viene mantenuta e caricata cambia in alcuni punti. Quindi “file di configurazione successivi” è pericoloso.

La prima cosa da fare è un inventario della configurazione.

• Cosa risiede nei file di configurazione
• Quali voci sono richieste all’avvio dell’app
• Quali sono le differenze per ambiente
• Che sono stati auto-iniettati da NuGet o dagli installatori

11.2 Metodo di distribuzione

Guarda anche la forma della distribuzione prima di iniziare.

• Ospitato sotto IIS?
• Un servizio Windows?
• Un’attività pianificata?
• ClickOnce / MSI / un programma di installazione personalizzato?
• Si presuppongono server locali?
• È preferibile la soluzione autonoma o dipendente dal framework?

Anche se l’eseguibile stesso migra, alla fine rimani bloccato se il meccanismo di distribuzione e avvio presuppone ancora il vecchio mondo.

11.3 Procedure di registrazione, monitoraggio e operative

Anche il lato operativo è facile da trascurare.

• Viene presunto il registro eventi Windows?
• I contatori delle prestazioni vengono monitorati?
• Monitoraggio basato su WMI?
• Gli account di servizio e le autorizzazioni sono corretti?
• I log presuppongono l’output del file locale?

“Il codice viene eseguito dopo la migrazione, ma le operazioni non possono funzionare” accade chiaramente.

11.4 CI / CD e agenti di creazione

Prima della migrazione, controlla anche:

• È possibile installare il .NET SDK richiesto sugli agenti di compilazione?
• Cosa fare con le condutture che presuppongono nuget.exe / msbuild.exe
• Ti trasferirai al dotnet CLI?
• Come aggiornare il test, la copertura e pubblicare i lavori
• I modelli interni o le pipeline riutilizzabili assumono i vecchi formati?

“Funziona sulla mia macchina ma CI muore” è un classico della migrazione.

12. Un modo realistico per eseguire la migrazione

Considerato tutto quanto sopra, un approccio realistico di solito si assesta più o meno in questa forma.

12.1 Innanzitutto, mettere in ordine il lato corrente della struttura

1. Passare a .NET Framework 4.7.2 o versione successiva, idealmente 4.8.1
2. Aggiornare le dipendenze
3. Rivedi packages.config
4. Passa allo stile PackageReference e SDK ove possibile
5. Conferma che l’app corrente funziona davvero in quello stato

Solo facendo questo si riduce considerevolmente la differenza nella fase successiva.

12.2 Salvare prima le librerie condivise

Successivamente, sposta la logica aziendale e i contratti comuni verso netstandard2.0 o multi-targeting. L’ordine di aggiornamento è, di regola, prima foglia.

12.3 Per l’applicazione stessa, variare la strategia in base al modello di app

• Librerie di classi / console / alcuni servizi Relativamente semplice
• WinForms / WPF Modernizza restando solo Windows
• ASP.NET MVC /API Web Tutto in una volta se piccolo; incrementale se pesante
• Moduli Web Supporre la sostituzione dello schermo; spostare prima la logica condivisa
• WCF server Decidi prima: resta con CoreWCF o riprogetta con gRPC

12.4 Attenersi a “Non tutto in una volta”

Gli abbinamenti da evitare particolarmente:

• Migrazione runtime + scambio completo ORM
• Migrazione del runtime + modifica dell’infrastruttura di autenticazione
• Migrazione runtime + migrazione completa al cloud
• Migrazione del runtime + monitoraggio del cambiamento dell’infrastruttura
• Migrazione del runtime + aggiornamento del framework dell’UI

Anche se sono necessari tutti, non impilarli nello stesso sprint di solito funziona meglio.

12.5 Effettuare test e linee di base prima di spostarsi

Come minimo, vuoi che questo sia a posto prima di trasferirti:

• Test unitari
• Test di integrazione dei principali flussi aziendali
• Verifica in stile snapshot di schermate rappresentative / API
• Una base di prestazione
• Un modo per controllare i log principali
• Una procedura di rollback

Procedere in uno stato in cui non è possibile identificare “cosa si è rotto” dopo la migrazione è piuttosto pericoloso.

13. Lista di controllo pre-avvio

Eccolo in un modulo che puoi incollare direttamente nel tuo strumento di gestione del progetto.

13.1 Politica

• Puoi indicare in una frase il motivo per cui stai migrando
• Il punto di destinazione è deciso: moderno .NET solo per Windows o futuro multipiattaforma
• La versione target .NET è decisa
• Ciò che è escluso da questo ambito (conversione EF Core, aggiornamento di autenticazione, migrazione completa al cloud, ecc.) viene deciso

13.2 Preparazione del lato corrente .NET Framework

• Spostato in .NET Framework 4.7.2 o successivo, idealmente 4.8.1
• Dipendenze aggiornate verso le ultime
• Controllato per packages.config
• Verificata fattibilità della conversione a PackageReference
• Verificata fattibilità della conversione allo stile SDK
• L’app corrente compila, avvia e supera i test in quello stato

13.3 Tipi di app e scelte tecnologiche

• Suddividi la difficoltà per tipo: libreria di classi / desktop / web / WCF, ecc.
• Resta inteso che WinForms / WPF rimangono solo per Windows
• Capito che ASP.NET Framework indica una migrazione del modello di app a ASP.NET Core
• Inclusa la sostituzione del livello dell’UI dei moduli Web nel preventivo
• Client e server WCF valutati separatamente

13.4 Tecnologie non supportate / API che richiedono attenzione

• Eliminate le dipendenze AppDomain
• Remotazione eliminata / MarshalByRefObject / BeginInvoke / EndInvoke
• Eliminato CAS / Trasparenza della sicurezza / COM+ / WF
• Eliminate le dipendenze BinaryFormatter
• Eliminate le dipendenze System.Web

13.5 Dipendenze solo per Windows

• Utilizzo eliminato del registro, servizi WMI, EventLog, Windows, servizi di directory
• Utilizzo eliminato di System.Drawing.Common
• Eliminato COM / ActiveX / Office Interop / P/Invoke / nativo DLLs
• Vincoli x86 / x64 / ARM64 verificati

13.6 Librerie condivise e accesso ai dati

• Librerie condivise classificate in logica di business / livelli accoppiati al modello di app
• Eliminato ciò che può essere convertito in netstandard2.0
• Eliminate le librerie che necessitano di multi-targeting
• Ha deciso se il runtime può spostarsi per primo mantenendo EF6
• Verificato EDMX / Dipendenze del designer

13.7 Operazioni e costruzione

• Ha fatto l’inventario dei file di configurazione
• Verificato il metodo di distribuzione (IIS / service / MSI / ClickOnce, ecc.)
• Presupposti verificati per registrazione / monitoraggio / autorizzazioni / account di esecuzione
• Verificato se CI / CD e gli agenti di compilazione necessitano di aggiornamento
• Creata una procedura di rollback

14. Riepilogo

Ciò che conta nella migrazione da .NET Framework a .NET non è “con quale comando migrare” ma vedere, prima di iniziare, cosa rimane così com’è e qual è un problema separato.

Ridotti all’essenziale, si tratta di questi sei punti:

• Pulire il lato .NET Framework prima della migrazione
• Difficoltà suddivisa per modello di app
• Prima elimina le tecnologie inutilizzabili
• Decidi quanta dipendenza solo da Windows accettare
• Decidi come ritagliare le librerie condivise
• Non accumulare ORM, autenticazione e migrazioni cloud contemporaneamente

L’accuratezza della stima cambia notevolmente nella prima settimana di migrazione. In altre parole, se riesci a risolvere i problemi in quella settimana, la seconda metà può essere indirizzata abbastanza vicino allo sviluppo ordinario.

“Proviamo a cambiarlo in net10.0” non è male come esplorazione. Ma come migrazione della produzione, ci sono cose a cui prestare attenzione prima. Ciò che questo articolo ha organizzato è esattamente questo.

15. Riferimenti

• Prerequisiti per il porting del codice
• Panoramica del trasferimento da .NET Framework a .NET
• Tecnologie .NET Framework non disponibili su .NET 6+
• Che cos’è la modernizzazione dell’app Copilot GitHub
• Installa GitHub Modernizzazione dell’app Copilot
• Politica di supporto ufficiale .NET
• .NET Framework politica di supporto ufficiale
• Utilizza gli strumenti per migrare ASP.NET Framework a ASP.NET Core
• Migrazione da ASP.NET Framework a ASP.NET Core
• Inizia con la migrazione incrementale da ASP.NET a ASP.NET Core
• Utilizza Windows Compatibility Pack per trasferire il codice su .NET
• .NET Standard
• Targeting multipiattaforma per librerie .NET
• Migrazione da packages.config a PackageReference
• PackageReference nei file di progetto
• BinaryFormatter guida alla migrazione
• BinaryFormatter guida alla migrazione per le applicazioni Windows Forms
• WCF Politica di supporto clienti
• CoreWCF Politica di supporto
• Perché migrare WCF a ASP.NET Core gRPC
• Porta da EF6 a EF Core
• Novità in EF6

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Cosa devo fare prima di migrare da .NET Framework a .NET?

Pulisci prima il lato .NET Framework. La guida ufficiale di Microsoft consiglia l'aggiornamento a .NET Framework 4.7.2 o successivo (in pratica 4.8.1 è la linea di base più chiara), la conversione dei riferimenti a PackageReference, il passaggio a progetti in stile SDK e l'aggiornamento delle dipendenze alle ultime versioni disponibili prima del porting. Fare questo prima riduce significativamente la differenza nella fase successiva e diventa più facile capire se un problema di compatibilità deriva dal vecchio Framework o dal passaggio al moderno .NET. Conferma inoltre che l'app corrente continua a essere creata, avviata e supera i test in quello stato.

Quali tecnologie .NET Framework non funzionano sui moderni .NET?

Gli elementi a luci rosse sono la creazione di AppDomain (come AppDomain.CreateDomain), .NET Remoting, Sicurezza dall'accesso di codice, System.EnterpriseServices (COM+), Workflow Foundation e hosting del server WCF in-box. BinaryFormatter merita un'attenzione speciale: su .NET 9 e versioni successive la sua implementazione genera sempre PlatformNotSupportedException e si nasconde in dati persistenti, cache, appunti e drag & drop, ResX e serializzazione del designer WinForms / WPF. Per i server WCF, i percorsi sono CoreWCF (un sottoinsieme che preserva la compatibilità del client) o una riprogettazione attorno a gRPC o HTTP API.

La mia app sarà multipiattaforma dopo la migrazione a .NET?

Non automaticamente. WinForms e WPF migrano al moderno .NET ma rimangono framework solo per Windows e System.Drawing.Common è solo per Windows su .NET 6 e versioni successive. Le dipendenze legate a Windows come il registro, i servizi WMI, EventLog, Windows, COM, Office Interop e P/Invoke rimangono con te dopo lo spostamento. La migrazione rimanendo solo su Windows è del tutto realistica (il Windows Compatibility Pack esiste esattamente per questo), ma se i contenitori Linux sono un obiettivo futuro, inventariare in anticipo i API legati a Windows e pianificare le sostituzioni come SkiaSharp o ImageSharp per il codice di imaging.

Devo migrare EF6 a EF Core contemporaneamente alla migrazione del runtime?

No. EF Core è una riscrittura totale di EF6 senza percorso di aggiornamento diretto, quindi combinare la migrazione ORM con la migrazione runtime aumenta sostanzialmente la difficoltà. L'ordine realistico è passare prima al moderno .NET, mantenere EF6 in esecuzione se necessario, quindi migrare a EF Core come progetto separato. Lo stesso principio si applica in modo più ampio: evitare di impilare la migrazione del runtime con modifiche all'autenticazione, migrazione al cloud, modifiche al monitoraggio o un aggiornamento del framework dell'UI nello stesso sforzo, anche se alla fine saranno tutti necessari.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.