Problemi di migrazione di .NET Framework 4

Articolo
03/30/2023

Questo articolo descrive i problemi di migrazione tra .NET Framework 3.5 Service Pack 1 e .NET Framework 4 e include correzioni, modifiche per la conformità agli standard e la protezione e modifiche basate sul feedback degli utenti. La maggior parte di queste modifiche non richiede alcuna modifica a livello di codice delle applicazioni. Per quelle che possono comportare la modifica del codice, vedere la colonna Modifiche consigliate della tabella. Le modifiche rilevanti sono suddivise in base all'area, ad esempio ASP.NET e Windows Presentation Foundation (WPF).

Per una panoramica generale dei problemi in questo articolo, vedere Guida alla migrazione a .NET Framework 4.

Per informazioni sulle nuove funzionalità, vedere Novità di .NET Framework 4.

ASP.NET e Web

Spazi dei nomi: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls

Assembly: System.Web (in System.Web.dll)

Funzionalità	Differenze rispetto alla versione 3.5 SP1	Modifiche consigliate
File di definizione del browser	I file di definizione del browser sono stati aggiornati per includere informazioni su browser e dispositivi nuovi e aggiornati. Sono stati rimossi browser e dispositivi precedenti come Netscape Navigator e sono stati aggiunti browser e dispositivi più recenti come Google Chrome e Apple iPhone. Se l'applicazione in uso contiene definizioni del browser personalizzate che derivano da una delle definizioni del browser rimosse, viene visualizzato un errore. L'oggetto HttpBrowserCapabilities esposto dalla proprietà `Request.Browse` della pagina è gestito dai file di definizione del browser. Pertanto le informazioni restituite mediante accesso a una proprietà di quest'oggetto in ASP.NET 4 possono essere diverse dalle informazioni restituite in una versione precedente di ASP.NET.	Se l'applicazione si basa sui file di definizione del browser precedenti è possibile copiarli dalla seguente cartella: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Copiare i file nella cartella \CONFIG\Browsers corrispondente per ASP.NET 4. Dopo la copia dei file eseguire lo strumento della riga di comando Aspnet_regbrowsers.exe. Per altre informazioni, vedere il sito Web di https://www.asp.net/mobile.
Applicazioni figlio in esecuzione in versioni diverse di ASP.NET	Le applicazioni ASP.NET 4 configurate come elementi figlio di applicazioni che eseguono versioni precedenti di ASP.NET potrebbero non avviarsi a causa di errori di compilazione o di configurazione. Gli errori specifici variano a seconda che l'applicazione sia eseguita in IIS 6.0, in IIS 7 o in IIS 7.5.	È possibile apportare modifiche ai file di configurazione delle applicazioni interessate in modo che il sistema di configurazione riconosca correttamente l'applicazione ASP.NET 4. Per informazioni sulle modifiche da apportare, vedere la sezione "ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications" (Le applicazioni figlio ASP.NET 4 non si avviano se dipendono da applicazioni ASP.NET 2.0 o ASP.NET 3.5) nel documento ASP.NET 4 Breaking Changes (Modifiche di rilievo in ASP.NET 4) sul sito Web ASP.NET.
Modifiche a ClientID	La nuova impostazione `clientIDMode` in ASP.NET 4 consente di specificare la modalità con cui ASP.NET genera l'attributo `id` per gli elementi HTML. Nelle versioni precedenti di ASP.NET il comportamento predefinito era equivalente all'impostazione `AutoID` di `clientIDMode`. L'impostazione predefinita è ora `Predictable`. Per altre informazioni, vedere ASP.NET Web Server Control Identification (Identificazione del controllo server Web ASP.NET).	Se si usa Visual Studio per aggiornare l'applicazione da ASP.NET 2.0 o ASP.NET 3.5, lo strumento aggiunge automaticamente al file Web.config un'impostazione che mantiene il comportamento delle versioni precedenti di .NET Framework. Se tuttavia si aggiorna un'applicazione modificando il pool di applicazioni in IIS per impostare come destinazione .NET Framework 4, ASP.NET usa la nuova modalità per impostazione predefinita. Per disattivare la nuova modalità ID client, aggiungere l'impostazione seguente al file Web.config: `<pages clientIDMode="AutoID" />`
Sicurezza dall'accesso di codice (CAS, Code Access Security)	Le funzionalità .NET di ASP.NET 2.0 aggiunte in ASP.NET 3.5 usano il modello di sicurezza dall'accesso di codice .NET Framework 1.1 e .NET Framework 2.0. Tuttavia l'implementazione di CAS in ASP.NET 4 è stata modificata in modo sostanziale. Di conseguenza le applicazioni ASP.NET con attendibilità parziale che si basano su codice attendibile in esecuzione nella Global Assembly Cache possono bloccarsi, generando diverse eccezioni di sicurezza. Le applicazioni parzialmente attendibili che si basano su modifiche estese ai criteri CAS del computer potrebbe a loro volta bloccarsi e generare eccezioni di sicurezza.	È possibile ripristinare il comportamento di ASP.NET 1.1 e 2.0 per le applicazioni ASP.NET 4 con attendibilità parziale usando il nuovo attributo `legacyCasModel` nell'elemento di configurazione `trust`, come visualizzato nell'esempio seguente: `<trust level= "Medium" legacyCasModel="true" />` Importante: il ripristino del modello di sicurezza CAS meno recente può comportare una riduzione della protezione. Per altre informazioni sul nuovo modello di sicurezza dall'accesso di codice di ASP.NET 4, vedere Sicurezza dall'accesso di codice per applicazioni ASP.NET 4.
File di configurazione	I file di configurazione radice (il file machine.config e il file radice Web.config) per .NET Framework e ASP.NET 4 sono stati aggiornati e includono la maggior parte delle informazioni di configurazione boilerplate che erano disponibili nei file Web.config delle applicazioni ASP.NET 3.5. Data la complessità dei sistemi di configurazione gestiti IIS 7 e IIS 7.5 l'esecuzione di applicazioni ASP.NET 3.5 in ASP.NET 4 e in IIS 7 e IIS 7.5 può determinare errori ASP.NET o errori IIS.	Aggiornare le applicazioni ASP.NET 3.5 ad ASP.NET 4 con gli strumenti di aggiornamento progetto di Visual Studio. Visual Studio 2010 modifica automaticamente il file Web.config dell'applicazione ASP.NET 3.5 in modo che contenga le impostazioni appropriate per ASP.NET 4. È tuttavia possibile eseguire applicazioni ASP.NET 3.5 usando .NET Framework 4 senza ricompilazione. In tal caso può essere necessario modificare manualmente il file Web.config dell'applicazione prima di eseguire l'applicazione stessa in .NET Framework 4 e in IIS 7 o IIS 7.5. La modifica specifica da apportare dipende dalla combinazione di software in uso, inclusi i Service Pack (SP). Per informazioni sulle possibili combinazioni di software interessate da questa modifica e sulla risoluzione dei problemi con combinazioni specifiche, vedere la sezione "Configuration Errors Related to New ASP.NET 4 Root Configuration" (Errori di configurazione associati alla nuova configurazione radice di ASP.NET 4) nel documento ASP.NET 4 Breaking Changes (Modifiche di rilievo in ASP.NET 4) sul sito Web ASP.NET.
Rendering dei controlli	Nelle versioni precedenti di ASP.NET alcuni controlli generavano markup che non era possibile disabilitare. Per impostazione predefinita i markup di questo tipo non vengono generati in ASP.NET 4. Le modifiche per il rendering interessano i controlli seguenti: * I controlli `Image` e `ImageButton` non eseguono più il rendering di un attributo `border="0"`. * La classe `BaseValidator` e i controlli di convalida che derivano da tale classe non eseguono più il rendering del testo in rosso per impostazione predefinita. * Il controllo `HtmlForm` non esegue il rendering di un attributo `name`. * Il controllo `Table` non esegue più il rendering di un attributo `border="0"`. I controlli non progettati per l'input utente (ad esempio il controllo `Label`) non eseguono più il rendering dell'attributo `disabled="disabled"` se la loro proprietà `Enabled` è impostata su `false` (o se ereditano questa impostazione da un controllo contenitore).	Se si usa Visual Studio per aggiornare l'applicazione da ASP.NET 2.0 o ASP.NET 3.5, lo strumento aggiunge automaticamente al file Web.config un'impostazione che mantiene il rendering delle versioni precedenti. Se tuttavia si aggiorna un'applicazione modificando il pool di applicazioni in IIS per impostare come destinazione .NET Framework 4, ASP.NET usa la nuova modalità di rendering per impostazione predefinita. Per disattivare la nuova modalità di rendering aggiungere l'impostazione seguente al file Web.config: `<pages controlRenderingCompatibilityVersion="3.5" />`
Gestori eventi nei documenti predefiniti	In ASP.NET 4, nell'elemento HTML `form` il rendering del valore dell'attributo `action` restituisce una stringa vuota quando viene effettuata una richiesta a un URL senza estensione al quale è mappato un documento predefinito. Nelle versioni precedenti di ASP.NET una richiesta a `http://contoso.com` dava come risultato una richiesta a Default.aspx. In tale documento il tag di apertura `form` veniva restituito come nell'esempio seguente: `<form action="Default.aspx" />` Anche in ASP.NET 4 una richiesta a `http://contoso.com` restituisce una richiesta a Default.aspx, ma ora in ASP.NET il tag di apertura HTML `form` viene restituito come nell'esempio seguente: `<form action="" />` Quando l'attributo `action` è una stringa vuota, l'oggetto `DefaultDocumentModule` IIS crea una richiesta figlio a Default.aspx. Nella maggior parte dei casi la richiesta figlio è trasparente per il codice dell'applicazione e la pagina Default.aspx viene eseguita normalmente. Tuttavia una potenziale interazione tra il codice gestito e la modalità integrata di IIS 7 o IIS 7.5 può interrompere il funzionamento corretto delle pagine gestite con estensione aspx durante la richiesta figlio. La richiesta figlio a un documento predefinito con estensione aspx restituisce un errore o un comportamento imprevisto se si verificano le condizioni seguenti: * Viene inviata al browser una pagina con estensione aspx con l'attributo `action` dell'elemento `form` impostato su "". * Il modulo viene reinserito in ASP.NET. * Un modulo HTTP gestito legge una sezione del corpo dell'entità, ad esempio `Request.Form` o `Request.Params`. Di conseguenza il corpo dell'entità della richiesta POST viene letto nella memoria gestita. Pertanto il corpo dell'entità non è più disponibile per i moduli di codice nativo che sono in esecuzione in modalità integrata IIS 7 o IIS 7.5. * L'oggetto `DefaultDocumentModule` IIS viene eseguito in una fase successiva e crea una richiesta figlio al documento Default.aspx. Tuttavia poiché il corpo dell'entità è già stato letto da un frammento di codice gestito, non è disponibile alcun corpo di entità da inviare alla richiesta figlio. * Quando la pipeline HTTP viene eseguita per la richiesta figlio, il gestore per i file con estensione aspx viene eseguito durante la fase handler-execute. Poiché non è presente nessun corpo dell'entità, non sono presenti variabili del modulo né uno stato di visualizzazione. Di conseguenza il gestore della pagina con estensione aspx non dispone di informazioni per determinare quale evento vada eventualmente generato. Pertanto non viene eseguito nessun gestore dell'evento di postback per la pagina con estensione aspx interessata.	Per informazioni sulla risoluzione dei problemi che possono verificarsi in seguito a questa modifica, vedere "Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode" (I gestori eventi potrebbero non essere attivati in un documento predefinito in modalità integrata IIS 7 o IIS 7.5) nel documento ASP.NET 4 Breaking Changes (Modifiche di rilievo in ASP.NET 4) sul sito Web ASP.NET.
Algoritmo hash	Per la protezione di dati come i cookie di autenticazione modulo e lo stato di visualizzazione, ASP.NET usa sia la crittografia che gli algoritmi hash. Per impostazione predefinita, ASP.NET 4 usa l'algoritmo HMACSHA256 per le operazioni di hash sui cookie e lo stato di visualizzazione. Le versioni precedenti di ASP.NET usano l'algoritmo meno recente HMACSHA1.	Se si eseguono applicazioni che combinano ASP.NET 2.0 e ASP.NET 4 in cui i dati quali i cookie di autenticazione moduli devono funzionare con tutte le versioni di .NET Framework, è possibile configurare un'applicazione Web ASP.NET 4 per l'uso dell'algoritmo meno recente HMACSHA1 aggiungendo la seguente impostazione nel file Web.config: `<machineKey validation="SHA1" />`
Hosting di controlli in Internet Explorer	Non è più possibile eseguire l'hosting di controlli Windows Form in Internet Explorer, perché esistono soluzioni migliori per l'hosting di controlli sul Web. Di conseguenza gli assembly IEHost.dll e IEExec.dll sono stati rimossi da .NET Framework.	Per lo sviluppo di controlli personalizzati è possibile usare le tecnologie seguenti nelle applicazioni Web: * È possibile creare un'applicazione Silverlight e configurarla per l'esecuzione fuori dal browser. Per altre informazioni, vedere Out-of-Browser Support (Supporto out-of-browser). * È possibile compilare un'applicazione browser XAML (XBAP) per sfruttare i vantaggi delle funzionalità WPF (nei computer client deve essere presente .NET Framework). Per altre informazioni, vedere Panoramica delle applicazioni browser XAML di WPF.
Metodi HtmlEncode e UrlEncode	I metodi `HtmlEncode` e `UrlEncode` delle classi HttpUtility e HttpServerUtility sono stati aggiornati per codificare il carattere virgoletta singola (') come indicato di seguito: * Il metodo `HtmlEncode` codifica le istanze della virgoletta singola come `'` * Il metodo `UrlEncode` codifica le istanze della virgoletta singola come `%27`	Esaminare le aree del codice in cui si usano i metodi `HtmlEncode` e `UrlEncode` e verificare che la variazione della codifica non produca alterazioni che possono avere effetto sull'applicazione.
Errori HttpException nelle applicazioni ASP.NET 2.0	Dopo l'abilitazione di ASP.NET 4 in IIS 6, le applicazioni ASP.NET 2.0 in esecuzione su IIS 6 (in Windows Server 2003 o Windows Server 2003 R2) possono generare errori come il seguente: `System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.`	* Se ASP.NET 4 non è necessario per l'esecuzione del sito Web, modificare il mapping del sito e abilitare l'uso di ASP.NET 2.0. oppure * Se ASP.NET 4 è necessario per l'esecuzione del sito Web, spostare le directory virtuali figlio ASP.NET 2.0 in un altro sito Web che esegue il mapping ad ASP.NET 2.0. oppure * Disabilitare gli URL senza estensione. Per altre informazioni, vedere "ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd" (Le applicazioni ASP.NET 2.0 possono generare errori HttpException con riferimenti a eurl.axd) nel documento ASP.NET 4 Breaking Changes (Modifiche di rilievo in ASP.NET 4) nel sito Web ASP.NET.
Tipi di appartenenza	Alcuni tipi (ad esempio MembershipProvider) usati nell'appartenenza di ASP.NET sono stati spostati da System.Web.dll a System.Web.ApplicationServices.dll. I tipi sono stati spostati per risolvere dipendenze dei livelli di architettura tra i tipi nel client e negli SKU estesi di .NET Framework.	La compilazione di librerie di classi aggiornate da versioni precedenti di ASP.NET che usano tipi di appartenenza spostati potrebbe non riuscire quando tali librerie vengono usate in un progetto ASP.NET 4. In questo caso aggiungere un riferimento a System.Web.ApplicationServices.dll nel progetto della libreria di classi.
Modifiche al controllo Menu	Le modifiche apportate al controllo Menu danno origine al comportamento seguente: * Se MenuRenderingMode è impostato su `List` o se MenuRenderingMode è impostato su `Default` e ControlRenderingCompatibilityVersion è impostato su `4.0` o versioni successive, la proprietà PopOutImageUrl non ha alcun effetto. * Se il percorso impostato nelle proprietà StaticPopOutImageUrl e DynamicPopOutImageUrl contiene una barra rovesciata (\), il rendering delle immagini non viene eseguito. Nelle versioni precedenti di ASP.NET il percorso poteva includere una barra rovesciata.	* Anziché impostare la proprietà PopOutImageUrl per singole voci di menu, impostare StaticPopOutImageUrl o DynamicPopOutImageUrl del controllo Menu padre. oppure Impostare MenuRenderingMode su `Table` o impostare MenuRenderingMode su `Default` e impostare ControlRenderingCompatibilityVersion su `3.5`. Con queste impostazioni il controllo Menu usa il layout basato su tabella HTML che usava anche nelle versioni precedenti di ASP.NET. * Se il percorso nella proprietà StaticPopOutImageUrl o DynamicPopOutImageUrl contiene una barra rovesciata (\), sostituirla con un carattere barra (/).
Assembly Mobile nel file Web.config	Nelle versioni precedenti di ASP.NET un riferimento all'assembly System.Web.Mobile.dll è incluso nel file Web.config radice nella sezione `assemblies`, sotto `system.web`/`compilation`. Per migliorare le prestazioni, il riferimento a questo assembly è stato rimosso. Nota: l'assembly System.Web.Mobile.dll e i controlli mobili ASP.NET sono inclusi in ASP.NET 4, ma sono deprecati.	Per usare tipi di questo assembly aggiungere un riferimento all'assembly nel file Web.config radice o in un file Web.config dell'applicazione.
Caching dell'output	In ASP.NET 1.0 a causa di un bug le pagine nella cache che specificavano `Location="ServerAndClient"` come impostazione cache di output includevano nella risposta un'intestazione HTTP `Vary:`. Questa intestazione comunicava ai browser client di non memorizzare mai la pagina nella cache in locale. In ASP.NET 1.1 è stato aggiunto il metodo SetOmitVaryStar che può essere chiamato per eliminare l'intestazione `Vary:`. Tuttavia i report sui bug indicano che gli sviluppatori non sono a conoscenza del comportamento `SetOmitVaryStar` esistente. In ASP.NET 4 l'intestazione HTTP `Vary:` non viene più generata dalle risposte che specificano la direttiva seguente: `<%@ OutputCache Location="ServerAndClient" %>` Di conseguenza il metodo SetOmitVaryStar non è più necessario per eliminare l'intestazione `Vary:`. Nelle applicazioni che specificano "ServerAndClient" come attributo `Location` le pagine possono essere memorizzate nella cache del browser senza che sia necessario chiamare SetOmitVaryStar.	Se è necessario che le pagine dell'applicazione emettano `Vary:`, chiamare il metodo AppendHeader come illustrato nell'esempio seguente: `System.Web.HttpResponse.AppendHeader("Vary","");` In alternativa è possibile impostare su "Server" il valore dell'attributo di memorizzazione nella cache dell'output `Location`.
Analisi della pagina	Il parser di pagina per le pagine Web (file con estensione aspx) e i controlli utente (file con estensione ascx) di ASP.NET è più restrittivo in ASP.NET 4 rispetto alle versioni precedenti di ASP.NET e rileva una quantità di markup non valido superiore a quella rilevata nelle versioni precedenti.	Esaminare i messaggi di errore generati durante l'esecuzione di una pagina e correggere gli errori risultanti da markup non valido.
Tipi Passport	Il supporto per Passport incorporato in ASP.NET 2.0 è obsoleto e non è più riconosciuto a causa delle modifiche apportate a Passport (ora denominato SDK Live ID). Di conseguenza i tipi associati a Passport in System.Web.Security ora sono contrassegnati con l'attributo `ObsoleteAttribute`.	Modificare qualsiasi codice che usi i tipi Passport nello spazio dei nomi System.Web.Security (ad esempio, PassportIdentity) per usare Windows Live ID SDK.
Informazioni PathInfo nella proprietà FilePath	In ASP.NET 4 il valore `PathInfo` non è più incluso nei valori restituiti da proprietà quali FilePath, AppRelativeCurrentExecutionFilePath e CurrentExecutionFilePath. Le informazioni `PathInfo` ora sono disponibili in PathInfo. Considerare ad esempio il frammento di URL seguente: `/testapp/Action.mvc/SomeAction` Nelle versioni precedenti di ASP.NET le proprietà HttpRequest hanno i valori seguenti: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (vuoto) In ASP.NET 4 invece i valori delle proprietà HttpRequest sono i seguenti: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Esaminare le aree del codice che usano le proprietà della classe HttpRequest per restituire informazioni sul percorso e modificare il codice in modo che rifletta le modifiche delle modalità di restituzione delle informazioni sul percorso.
Convalida delle richieste	Per migliorare la convalida delle richieste, la convalida della richiesta ASP.NET viene chiamata in una fase precedente del ciclo di vita della richiesta. Di conseguenza la convalida delle richieste viene eseguita per richieste che non sono destinate a file con estensione aspx, ad esempio per chiamate al servizio Web e per gestori personalizzati. La convalida delle richieste resta attiva anche quando nella pipeline di elaborazione richieste sono in esecuzione moduli HTTP personalizzati. In seguito a questa modifica le richieste di risorse diverse da file con estensione aspx possono generare errori di convalida delle richieste. Anche il codice personalizzato eseguito nella pipeline delle richieste (ad esempio moduli HTTP personalizzati) può generare errori di convalida delle richieste.	Se necessario è possibile ripristinare il comportamento precedente in cui la convalida richieste veniva attivata solo dalle pagine con estensione aspx. Per fare ciò usare l'impostazione seguente nel file di configurazione Web: `<httpRuntime requestValidationMode="2.0" />` Avviso: se si ripristina il comportamento precedente, assicurarsi che tutto il codice in gestori moduli e altri elementi di codice personalizzato esistenti esegua controlli degli input HTTP potenzialmente non sicuri, che potrebbero essere vettori di attacco XSS.
Routing	Se si crea un sito Web di file system in Visual Studio 2010 e il sito Web si trova in una cartella il cui nome contiene un punto (.), il routing dell'URL non funziona in modo affidabile. Alcuni percorsi virtuali restituiscono un errore HTTP 404. Questo errore si verifica perché Visual Studio 2010 avvia Visual Studio Development Server usando un percorso non corretto per la directory radice virtuale.	* Nella pagina Proprietà del sito Web basato su file impostare l'attributo Percorso virtuale su "/". oppure * Creare un progetto di applicazione Web anziché un progetto di sito Web. I progetti di applicazione Web non presentano questo problema e il routing di URL funziona anche se il nome della cartella del progetto contiene un punto. oppure * Creare un sito Web basato su HTTP ospitato in IIS. Sia il percorso virtuale sia la cartella del file di progetto dei siti Web ospitati in IIS possono includere punti.
Siti di SharePoint	Se si prova a eseguire un sito Web ASP.NET 4 distribuito come figlio di un sito Web SharePoint che contiene un livello di attendibilità parziale personalizzato denominato `WSS_Minimal`, viene visualizzato l'errore seguente: `Could not find permission set named 'ASP.Net'.`	Attualmente nessuna versione di SharePoint è compatibile con ASP.NET. Pertanto evitare di eseguire un sito Web ASP.NET 4 come figlio di un sito Web SharePoint.
Standard XHTML 1.1	Per abilitare la conformità XHTML 1.1 per i nuovi siti Web, i controlli ASP.NET in .NET Framework 4 generano codice HTML conforme a XHTML 1.1. Il rendering viene abilitato con l'opzione seguente nel file Web.config all'interno dell'elemento `<system.Web>`: `<pages controlRenderingCompatibilityVersion="4.0"/>` L'impostazione predefinita di questa opzione è 4.0. Nei progetti Web aggiornati da Visual Studio 2008 l'impostazione attivata è 3.5, per garantire la compatibilità.	Nessuno.

Memoria centrale