Problemi di migrazione di .NET Framework 4

2025-06-17

Questo articolo descrive i problemi di migrazione tra .NET Framework versione 3.5 Service Pack 1 e .NET Framework versione 4, incluse correzioni, modifiche per la conformità e la sicurezza degli standard e modifiche in base al feedback dei clienti. La maggior parte di queste modifiche non richiede alcuna modifica di programmazione nelle applicazioni. Per quelli che possono comportare modifiche, 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)

Caratteristica / Funzionalità	Differenze rispetto a 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 meno recenti, ad esempio Netscape Navigator, e sono stati aggiunti browser e dispositivi più recenti, ad esempio Google Chrome e Apple iPhone. Se l'applicazione contiene definizioni di browser personalizzate che ereditano da una delle definizioni del browser rimosse, verrà visualizzato un errore. L'oggetto HttpBrowserCapabilities (esposto dalla proprietà `Request.Browse` della pagina) è guidato dai file di definizione del browser. Pertanto, le informazioni restituite accedendo a una proprietà di questo oggetto in ASP.NET 4 potrebbero 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 cartella seguente: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browser Copiare i file nella cartella \CONFIG\Browser corrispondente per ASP.NET 4. Dopo aver copiato i file, eseguire lo strumento da riga di comandoAspnet_regbrowsers.exe . Per altre informazioni, vedere il https://www.asp.net/mobile sito Web.
Applicazioni figlie in esecuzione in versioni miste di ASP.NET	Applicazioni ASP.NET 4 configurate come elementi figli di applicazioni che utilizzano versioni precedenti rispetto ad ASP.NET 4 potrebbero non essere avviate a causa di errori di configurazione o compilazione. L'errore specifico che si verifica dipende dal fatto che l'applicazione venga eseguita in IIS 6.0 o in IIS 7 o 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 "Le applicazioni figlio ASP.NET 4 non si avviano quando si trovano sotto applicazioni ASP.NET 2.0 o ASP.NET 3.5" nel documento ASP.NET 4 modifiche significative nel sito Web ASP.NET.
Modifiche di ClientID	La nuova `clientIDMode` impostazione in ASP.NET 4 consente di specificare come ASP.NET genera l'attributo `id` per gli elementi HTML. Nelle versioni precedenti di ASP.NET, il comportamento predefinito equivale all'impostazione `AutoID` di `clientIDMode`. L'impostazione predefinita è ora `Predictable`. Per ulteriori informazioni, vedere Identificazione del controllo del 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 un'impostazione al file Web.config che mantiene il comportamento delle versioni precedenti di .NET Framework. Tuttavia, se si aggiorna un'applicazione modificando il pool di applicazioni in IIS per .NET Framework 4, ASP.NET usa la nuova modalità per impostazione predefinita. Per disabilitare la nuova modalità ID client, aggiungere l'impostazione seguente al file Web.config: `<pages clientIDMode="AutoID" />`
Sicurezza dall'accesso al codice	Le funzionalità di ASP.NET 2.0 incluse in ASP.NET 3.5 utilizzano il modello di sicurezza per l'accesso al codice (.NET Framework 1.1 e .NET Framework 2.0 CAS). Tuttavia, l'implementazione del cas in ASP.NET 4 è stata sostanzialmente revisionata. Di conseguenza, le applicazioni con attendibilità parziale ASP.NET che si basano su codice attendibile in esecuzione nella Global Assembly Cache potrebbero non riuscire con diverse eccezioni di sicurezza. Le applicazioni con attendibilità parziale che si basano su estese modifiche ai criteri CAS del computer potrebbero anche non riuscire e generare eccezioni di sicurezza.	È possibile ripristinare le applicazioni ASP.NET 4 con trust parziale al comportamento di ASP.NET 1.1 e 2.0 usando il nuovo attributo `legacyCasModel` nell'elemento di configurazione `trust`, come illustrato nell'esempio seguente: `<trust level= "Medium" legacyCasModel="true" />` Importante: il ripristino del modello CAS precedente potrebbe rappresentare una riduzione della sicurezza. Per altre informazioni sul nuovo modello di sicurezza dell'accesso di codice ASP.NET 4, vedere Sicurezza dall'accesso di codice in ASP.NET 4 applicazioni.
File di configurazione	I file di configurazione radice (il file di machine.config e il file di Web.config radice) per .NET Framework e ASP.NET 4 sono stati aggiornati per includere la maggior parte delle informazioni di configurazione boilerplate trovate nei file di Web.config dell'applicazione in ASP.NET 3.5. A causa della complessità dei sistemi di configurazione di IIS 7 e IIS 7.5 gestiti, l'esecuzione di applicazioni ASP.NET 3.5 in ASP.NET 4 e in IIS 7 e IIS 7.5 può generare errori ASP.NET o errori IIS.	Aggiornare ASP.NET 3.5 applicazioni a ASP.NET 4 usando gli strumenti di aggiornamento del progetto in Visual Studio. Visual Studio 2010 modifica automaticamente il file di Web.config ASP.NET 3.5 dell'applicazione in modo da contenere le impostazioni appropriate per ASP.NET 4. Tuttavia, è possibile eseguire ASP.NET applicazioni 3.5 usando .NET Framework 4 senza ricompilazione. In tal caso, potrebbe essere necessario modificare manualmente il file di Web.config dell'applicazione prima di eseguire l'applicazione in .NET Framework 4 e in IIS 7 o IIS 7.5. La modifica specifica che è necessario apportare dipende dalla combinazione di software in uso, incluse le versioni di Service Pack (SP). Per informazioni sulle possibili combinazioni software interessate da questa modifica e su come risolvere i problemi relativi a combinazioni specifiche, vedere la sezione "Errori di configurazione correlati alla nuova configurazione ASP.NET 4 Configurazione radice" nel documento ASP.NET 4 Modifiche di rilievo nel sito Web ASP.NET.
Rendering dei controlli	Nelle versioni precedenti di ASP.NET alcuni controlli hanno generato markup che non è stato possibile disabilitare. Per impostazione predefinita, questo tipo di markup non viene più generato in ASP.NET 4. Le modifiche al rendering influiscono sui controlli seguenti: * I controlli `Image` e `ImageButton` non eseguono più il rendering di un attributo `border="0"`. * La `BaseValidator` classe e i controlli di convalida che derivano da esso non eseguono più il rendering del testo rosso per impostazione predefinita. * Il controllo non effettua il rendering di un `HtmlForm` attributo. * Il controllo non rende più l'attributo `Table`. I controlli che non sono progettati per l'input da parte dell'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 un'impostazione al file Web.config che mantiene il rendering legacy. Tuttavia, se si aggiorna un'applicazione modificando il pool di applicazioni in IIS per puntare a .NET Framework 4, ASP.NET utilizza per impostazione predefinita la nuova modalità di rendering. Per disabilitare la nuova modalità di rendering, aggiungere l'impostazione seguente al file Web.config: `<pages controlRenderingCompatibilityVersion="3.5" />`
Gestori eventi nei documenti predefiniti	ASP.NET 4 esegue il rendering del valore dell'attributo dell'elemento `form` HTML `action` come stringa vuota quando viene effettuata una richiesta a un URL senza estensione con un documento predefinito mappato. Nelle versioni precedenti di ASP.NET, una richiesta a `http://contoso.com` restituirà una richiesta di Default.aspx. In tale documento, il rendering del tag di apertura `form` verrà eseguito come nell'esempio seguente: `<form action="Default.aspx" />` In ASP.NET 4, una richiesta a `http://contoso.com` si traduce anche in una richiesta a Default.aspx, ma ora ASP.NET esegue il rendering del tag HTML di apertura `form` come nell'esempio seguente: `<form action="" />` Quando l'attributo `action` è una stringa vuota, l'oggetto IIS `DefaultDocumentModule` crea una richiesta figlio per Default.aspx. Nella maggior parte delle condizioni, questa richiesta secondaria è trasparente per il codice dell'applicazione stessa e la pagina Default.aspx viene eseguita normalmente. Tuttavia, una potenziale interazione tra codice gestito e IIS 7 o IIS 7.5 in modalità Integrata può causare l'interruzione del corretto funzionamento delle pagine .aspx gestite durante la richiesta figlia. Se si verificano le condizioni seguenti, la richiesta secondaria a un documento .aspx predefinito genererà un errore o un comportamento imprevisto. * Una pagina .aspx viene inviata al browser con l'attributo `form` dell'elemento `action` impostato su "". * Il modulo viene pubblicato di nuovo in ASP.NET. * Un modulo HTTP gestito legge parte del corpo dell'entità, ad esempio `Request.Form` o `Request.Params`. In questo modo il corpo dell'entità della richiesta POST viene letto nella memoria gestita. Di conseguenza, il corpo dell'entità non è più disponibile per i moduli di codice nativo in esecuzione in modalità integrata IIS 7 o IIS 7.5. * L'oggetto IIS `DefaultDocumentModule` viene infine eseguito e genera una richiesta figlia per il documento Default.aspx. Tuttavia, poiché il corpo della richiesta è già stato letto da una parte di codice gestito, non è disponibile alcun corpo della richiesta da inviare alla richiesta figlia. * Quando la pipeline HTTP viene eseguita per la richiesta secondaria, il gestore per i file .aspx viene eseguito durante la fase di esecuzione del gestore di richieste. Poiché non è presente alcun corpo dell'entità, non sono presenti variabili di modulo e nessun stato di visualizzazione. Non sono pertanto disponibili informazioni per il gestore di pagine .aspx per determinare quale evento (se presente) deve essere generato. Di conseguenza, nessuno dei gestori di eventi di postback viene eseguito per la pagina .aspx interessata.	Per informazioni sui modi per risolvere i problemi che potrebbero sorgere a causa di questa modifica, vedere "I gestori eventi potrebbero non essere attivati in un documento predefinito in modalità integrata di IIS 7 o IIS 7.5" nel documento Modifiche critiche di ASP.NET 4 sul sito Web ASP.NET.
Algoritmo di hashing	ASP.NET usa algoritmi di crittografia e hash per proteggere i dati, ad esempio i cookie di autenticazione basata su moduli e lo stato di visualizzazione. Per impostazione predefinita, ASP.NET 4 usa l'algoritmo HMACSHA256 per le operazioni hash sui cookie e sullo stato di visualizzazione. Nelle versioni precedenti di ASP.NET è stato usato l'algoritmo precedente HMACSHA1 .	Se si eseguono applicazioni che combinano ASP.NET 2.0 e ASP.NET 4, in cui i dati come i cookie di autenticazione basata su moduli devono funzionare tra le versioni di .NET Framework, configurare un'applicazione Web ASP.NET 4 per usare l'algoritmo precedente HMACSHA1 aggiungendo l'impostazione seguente nel file Web.config: `<machineKey validation="SHA1" />`
Controlli di hosting in Internet Explorer	Non è più possibile ospitare controlli Windows Form in Internet Explorer, perché esistono soluzioni migliori per l'hosting dei controlli sul Web. Di conseguenza, gli assembly IEHost.dll e IEExec.exe sono stati rimossi da .NET Framework.	È possibile usare le tecnologie seguenti per lo sviluppo di controlli personalizzati nelle applicazioni Web: * È possibile creare un'applicazione Silverlight e configurarla per l'esecuzione all'esterno del browser. Per ulteriori informazioni, vedere supporto per operazioni fuori dal browser. * È possibile compilare un'applicazione browser XAML (XBAP) per sfruttare le funzionalità WPF (richiede .NET Framework nei computer client). Per altre informazioni, vedere "Panoramica delle applicazioni browser XAML WPF".
Metodi HtmlEncode e UrlEncode	I metodi `HtmlEncode` e `UrlEncode` delle classi HttpUtility e HttpServerUtility sono stati aggiornati per codificare il carattere virgolette singola ('). * Il `HtmlEncode` metodo codifica le istanze delle virgolette singole come `'` * Il `UrlEncode` metodo codifica le istanze delle virgolette singole come `%27`	Esaminare il codice per individuare le posizioni in cui si usano i `HtmlEncode` metodi e `UrlEncode` e assicurarsi che la modifica nella codifica non comporti una modifica che influirà sull'applicazione.
Errori HttpException nelle applicazioni ASP.NET 2.0	Dopo aver abilitato ASP.NET 4 in IIS 6, ASP.NET applicazioni 2.0 eseguite in IIS 6 (in Windows Server 2003 o Windows Server 2003 R2) potrebbero generare errori come i seguenti: `System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.`	* Se ASP.NET 4 non è necessario per eseguire il sito Web, eseguire nuovamente il mapping del sito per usare ASP.NET 2.0. oppure * Se è necessario ASP.NET 4 per eseguire il sito Web, spostare qualsiasi directory virtuale figlio di ASP.NET 2.0 in un sito Web diverso associato ad ASP.NET 2.0. oppure * Disabilitare gli URL senza estensione. Per ulteriori informazioni, vedere "Le applicazioni ASP.NET 2.0 potrebbero generare errori HttpException che fanno riferimento a eurl.axd" nel documento ASP.NET 4: Modifiche di rilievo disponibile sul sito Web di ASP.NET.
Tipi di appartenenza	Alcuni tipi (ad esempio, MembershipProvider) usati nella gestione degli utenti di ASP.NET sono stati spostati dall'assembly System.Web.dll all'assembly System.Web.ApplicationServices.dll. I tipi sono stati spostati per risolvere le dipendenze a livelli dell'architettura tra i tipi nel client e negli SKU di .NET Framework estesi.	Le librerie di classi aggiornate da versioni precedenti di ASP.NET e che usano i tipi di appartenenza spostati potrebbero non riuscire a essere compilate quando vengono usate in un progetto ASP.NET 4. In tal caso, aggiungere un riferimento nel progetto di libreria di classi per System.Web.ApplicationServices.dll.
Modifiche al controllo menu	Le modifiche apportate al Menu controllo comportano il comportamento seguente: * Se MenuRenderingMode è impostato su `List`o se MenuRenderingMode è impostato su `Default` e ControlRenderingCompatibilityVersion è impostato su `4.0` o versione successiva, la PopOutImageUrl proprietà non ha alcun effetto. * Se il percorso impostato nelle StaticPopOutImageUrl proprietà e DynamicPopOutImageUrl contiene una barra rovesciata (\), le immagini non eseguono il rendering. Nelle versioni precedenti di ASP.NET, il percorso potrebbe includere una barra rovesciata.	Invece di impostare la proprietà PopOutImageUrl per le singole voci di menu, impostare la StaticPopOutImageUrl o DynamicPopOutImageUrl del controllo padre Menu. oppure Impostare MenuRenderingMode su `Table`, o impostare MenuRenderingMode su `Default` e impostare ControlRenderingCompatibilityVersion su `3.5`. Queste impostazioni fanno sì che il Menu controllo usi il layout basato su tabella HTML usato nelle versioni precedenti di ASP.NET. * Se il percorso nella proprietà StaticPopOutImageUrl o DynamicPopOutImageUrl contiene una barra rovesciata (\), sostituire con un carattere barra (/).
Assemblaggio di dispositivi mobili nel file Web.config	Nelle versioni precedenti di ASP.NET, un riferimento all'assembly System.Web.Mobile.dll è stato incluso nel file radice Web.config 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 obsoleti.	Se si desidera utilizzare tipi dell'assembly, aggiungere un riferimento all'assembly nel file radice Web.config oppure in un file dell'applicazione Web.config.
Caching dell'output	In ASP.NET 1.0, un bug ha fatto sì che le pagine memorizzate nella cache che specificavano `Location="ServerAndClient"` come impostazione di output-cache generassero un'intestazione `Vary:` HTTP nella risposta. Questo ha avuto l'effetto di indicare ai browser client di non memorizzare mai nella cache la pagina in locale. In ASP.NET 1.1 è stato aggiunto il SetOmitVaryStar metodo , che può essere chiamato per eliminare l'intestazione `Vary:` . Tuttavia, i report sui bug suggeriscono che gli sviluppatori non sono a conoscenza del comportamento esistente `SetOmitVaryStar` . In ASP.NET 4, l'intestazione `Vary:` HTTP non viene più generata dalle risposte che specificano la direttiva seguente: `<%@ OutputCache Location="ServerAndClient" %>` Di conseguenza, il SetOmitVaryStar metodo non è più necessario per eliminare l'intestazione `Vary:` . Nelle applicazioni che specificano "ServerAndClient" per l'attributo `Location` , le pagine saranno memorizzate nella cache nel browser senza che sia necessario chiamare SetOmitVaryStar.	Se le pagine nell'applicazione devono generare `Vary:`, chiamare il AppendHeader metodo come illustrato nell'esempio seguente: `System.Web.HttpResponse.AppendHeader("Vary","");` In alternativa, è possibile modificare il valore dell'attributo della cache dell'output `Location` in "Server".
Analisi delle pagine	Il parser di pagine per ASP.NET pagine Web (file .aspx) e i controlli utente (file con estensione ascx) è più restrittivo in ASP.NET 4 rispetto alle versioni precedenti di ASP.NET e contrassegna più markup come non valido rispetto alle versioni precedenti.	Esaminare i messaggi di errore generati quando viene eseguita una pagina e correggere gli errori risultanti da markup non valido.
Tipi di passaporto	Il supporto passport integrato in ASP.NET 2.0 è obsoleto e non è supportato a causa delle modifiche apportate a Passport (ora Live ID SDK). Di conseguenza, i tipi correlati a Passport in System.Web.Security sono ora contrassegnati con l'attributo `ObsoleteAttribute` .	Modificare qualsiasi codice che usa i tipi Passport nello spazio dei nomi System.Web.Security (ad esempio, PassportIdentity) per usare il "Windows Live ID SDK".
Informazioni pathInfo nella proprietà FilePath	ASP.NET 4 non include più il `PathInfo` valore nei valori restituiti da proprietà come FilePath, AppRelativeCurrentExecutionFilePathe CurrentExecutionFilePath. Le informazioni sono disponibili invece in `PathInfo`PathInfo. Immagina, ad esempio, il seguente frammento di URL: `/testapp/Action.mvc/SomeAction` Nelle versioni precedenti di ASP.NET le HttpRequest proprietà hanno i valori seguenti: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (vuoto) In ASP.NET 4 le HttpRequest proprietà hanno invece i valori seguenti: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Esaminare il codice per individuare le posizioni in cui ci si basa sulle proprietà della HttpRequest classe per restituire informazioni sul percorso. Modificare il codice in modo da riflettere le modifiche apportate alle informazioni sul percorso restituite.
Convalida della richiesta	Per migliorare la convalida delle richieste, la convalida della richiesta di ASP.NET viene richiamata in precedenza nel ciclo di vita della richiesta. Di conseguenza, la convalida delle richieste viene eseguita per le richieste che non sono per i file .aspx, ad esempio per le chiamate al servizio Web e per i gestori personalizzati. La convalida delle richieste sarà attiva anche quando i moduli HTTP personalizzati sono in esecuzione nella pipeline di elaborazione delle richieste. In seguito a questa modifica, le richieste di risorse diverse da .aspx file potrebbero generare errori di convalida delle richieste. Il codice personalizzato eseguito nella pipeline di richiesta (ad esempio moduli HTTP personalizzati) potrebbe anche generare errori di convalida delle richieste.	Se necessario, è possibile ripristinare il comportamento precedente di avere solo .aspx pagine che attivano la convalida delle richieste usando 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 altro codice personalizzato esegua controlli per input HTTP potenzialmente non sicuri che potrebbero essere vettori di attacco XSS.
Instradamento	Se si crea un sito Web del file system in Visual Studio 2010 e il sito Web si trova in una cartella contenente un punto (.) nel nome della cartella, il routing url non funzionerà in modo affidabile. Viene restituito un errore HTTP 404 da alcuni percorsi virtuali. Ciò si verifica perché Visual Studio 2010 avvia Visual Studio Development Server usando un percorso non corretto per la directory virtuale radice.	* Nella pagina Proprietà del sito Web basato su file modificare l'attributo Percorso virtuale in "/". oppure * Creare un progetto di applicazione Web invece di un progetto di sito Web. I progetti dell'applicazione Web non presentano questo problema e il routing degli URL funziona anche se la cartella del progetto ha un punto nel nome. oppure * Creare un sito Web basato su HTTP ospitato in IIS. I siti Web ospitati in IIS possono avere punti nel percorso virtuale e nella cartella del file di progetto.
Siti di SharePoint	Se si tenta di eseguire un sito Web ASP.NET 4 distribuito come figlio di un sito Web di SharePoint contenente un livello di attendibilità parziale personalizzato denominato `WSS_Minimal`, verrà visualizzato l'errore seguente: `Could not find permission set named 'ASP.Net'.`	Attualmente, nessuna versione di SharePoint è compatibile con ASP.NET. Di conseguenza, non è consigliabile tentare di eseguire un sito Web ASP.NET 4 come figlio di un sito Web di 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 genereranno codice HTML conforme a XHTML 1.1. Questo rendering è abilitato usando l'opzione seguente nel file Web.config all'interno dell'elemento `<system.Web>` : `<pages controlRenderingCompatibilityVersion="4.0"/>` Questa opzione è impostata per impostazione predefinita su 4.0. I progetti Web aggiornati da Visual Studio 2008 hanno l'impostazione 3.5 abilitata per la compatibilità.	Nessuno.

Nucleo

Funzionalità generali

Caratteristica / Funzionalità	Differenze rispetto a 3.5 SP1	Modifiche consigliate
CardSpace	Windows CardSpace non è più incluso in .NET Framework; viene fornito separatamente.	Scarica Windows CardSpace dal Centro Download Microsoft.
File di configurazione	Sono state apportate correzioni nel modo in cui .NET Framework accede ai file di configurazione dell'applicazione.	Se il file di configurazione dell'applicazione è denominato application-name.config, rinominarlo in application-name.exe.config. Ad esempio, rinominare MyApp.config in MyApp.exe.config.
Compilatore di codice C#	Le classi `Compiler`, `CompilerError` e `ErrorLevel` presenti nello spazio dei nomi Microsoft.CSharp non sono più disponibili, e il loro assembly (cscompmgd.dll) non è più incluso in .NET Framework.	Usare la classe CodeDomProvider e altre classi nel namespace System.CodeDom.Compiler. Per altre informazioni, vedere Uso di CodeDOM.
Hosting (API non gestita)	Per migliorare le funzionalità di hosting, alcune delle API di attivazione dell'hosting sono state deprecate. Le funzionalità di esecuzione side-by-side in-process consentono a un'applicazione di caricare e avviare più versioni di .NET Framework nello stesso processo. Ad esempio, è possibile eseguire applicazioni che caricano componenti aggiuntivi (o componenti) basati su .NET Framework 2.0 SP1 e componenti aggiuntivi basati su .NET Framework 4 nello stesso processo. I componenti meno recenti continuano a usare la versione precedente di .NET Framework e i nuovi componenti usano la nuova versione di .NET Framework.	Usare le configurazioni descritte in In-Process esecuzione affiancata.
Nuovo modello di sicurezza	I criteri di sicurezza dall'accesso al codice (CAS) sono stati disattivati e sostituiti con un modello semplificato, come descritto in Modifiche alla sicurezza in .NET Framework 4.	Le modifiche possono essere necessarie se si fa affidamento su CAS nelle applicazioni. Per altre informazioni, vedere Compatibilità e migrazione dei criteri di sicurezza dell'accesso al codice.

Data e ora

Namespace: System

Assembly: mscorlib (in mscorlib.dll)

Caratteristica / Funzionalità	Differenze rispetto a 3.5 SP1	Modifiche consigliate
Ora Legale	Per essere coerenti con l'orologio di sistema, le proprietà dell'ora (ad esempio Local e Now) ora usano regole del sistema operativo anziché altri dati di .NET Framework per le operazioni di ora legale.	Nessuno.
Formattazione di stringhe	Per supportare la formattazione sensibile alle impostazioni cultura, la struttura TimeSpan include nuovi overload dei metodi `ToString`, `Parse` e `TryParse`, oltre ai nuovi metodi `ParseExact` e `TryParseExact`.	Nessuno.

Globalizzazione

Per un elenco delle nuove culture neutrali e specifiche, vedere Novità nella globalizzazione e localizzazione.

Namespace: System.Globalization

Assembly: mscorlib (in mscorlib.dll)

Caratteristica / Funzionalità	Differenze rispetto a 3.5 SP1	Modifiche consigliate
Nomi delle culture	Le seguenti modifiche al nome influiscono sulle culture tedesca, divehi e africana. * CurrencyEnglishName: Il nome della valuta per la cultura tedesco (Svizzera) (de-CH) è cambiato da "sFr." a "Fr.". * LongDatePattern: Il formato di data lunga per la cultura Divehi (Maldive) (dv-MV) è cambiato da "dd/MMMM/yyyy" a "dd/MM/yyyy". * PMDesignator: il designatore P.M. delle impostazioni cultura afrikaans (Sudafrica) (af-ZA) è cambiato da "nm" a "PM".	Annotare le modifiche al nome della cultura.
Parametro LCID	Per garantire coerenza con il comportamento previsto nelle impostazioni del server di automazione, il CLR non passa più la cultura corrente per il parametro `LCID` alle applicazioni basate su COM non gestite. Invece, passa 1033 (en-us) per le impostazioni culturali.	Nessuna modifica necessaria ad eccezione delle applicazioni native che richiedono una cultura specificata.
Tipi di cultura obsoleti	I tipi di cultura CultureTypes e CultureTypes sono ora obsoleti. Per garantire la compatibilità con le versioni precedenti, CultureTypes ora restituisce culture neutre e specifiche che erano incluse nelle versioni precedenti del .NET Framework, mentre CultureTypes ora restituisce un elenco vuoto.	Utilizzare altri valori dell'enumerazione CultureTypes .
Recupero della cultura	A partire da Windows 7, .NET Framework 4 recupera le informazioni culturali dal sistema operativo anziché archiviare i dati. .NET Framework viene inoltre sincronizzato con Windows per l'ordinamento e la gestione delle maiuscole e minuscole.	Nessuno.
Standard Unicode 5.1	.NET Framework supporta ora tutti i caratteri Unicode 5.1, un'aggiunta di circa 1400 caratteri. I caratteri aggiuntivi includono nuovi simboli, frecce, segni diacritici, punteggiatura, simboli matematici, tratti CJK e ideogrammi, caratteri numerici malayalam e Telugu, e vari caratteri numerici Myanmar, latino, arabo, greco, mongolo e cirillico. I nuovi script seguenti sono supportati con Unicode 5.1: Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu e Caratteri malayalam e Cham.	Nessuno.

Eccezioni

Namespace: System, System.Runtime.ExceptionServices

Assembly: mscorlib (in mscorlib.dll)

Caratteristica / Funzionalità	Differenze rispetto a 3.5 SP1	Modifiche consigliate
Eccezioni per lo stato del processo danneggiato	CLR non recapita più eccezioni per lo stato del processo danneggiato ai gestori di eccezioni nel codice gestito.	Queste eccezioni indicano che lo stato di un processo è stato danneggiato. Non è consigliabile eseguire l'applicazione in questo stato. Per ulteriori informazioni, vedere il HandleProcessCorruptedStateExceptionsAttribute e la voce Gestione delle eccezioni di stato corrotto nella rivista MSDN Magazine.
Eccezioni del motore di esecuzione	ExecutionEngineException è ora obsoleto, perché un'eccezione intercettabile consentirà l'esecuzione di un processo instabile. Questa modifica migliora la prevedibilità e l'affidabilità nel runtime.	Usare un InvalidOperationException per segnalare la condizione.

Riflessione

Namespace: System.Reflection

Assembly: mscorlib (in mscorlib.dll)

Caratteristica / Funzionalità	Differenze rispetto a 3.5 SP1	Modifiche consigliate
Algoritmi hash dell'assembly	La proprietà HashAlgorithm ora restituisce AssemblyHashAlgorithm, perché il runtime non conosce l'algoritmo hash dell'assembly a cui si fa riferimento, quando l'assembly non viene caricato. Questo si riferisce all'uso della proprietà in un assembly a cui si fa riferimento, come quello che viene restituito dal metodo GetReferencedAssemblies.	Nessuno.
Caricamento dell'assembly	Per evitare il caricamento ridondante degli assembly e per risparmiare spazio indirizzi virtuale, CLR carica ora gli assembly usando solo la funzione Win32 `MapViewOfFile` . Non chiama più la funzione `LoadLibrary`. Questa modifica influisce sulle applicazioni di diagnostica nei modi seguenti: * Un ProcessModuleCollection oggetto non conterrà più moduli di una libreria di classi (.dll file), come ottenuto da una chiamata a `Process.GetCurrentProcess().Modules`. * Le applicazioni Win32 che usano la `EnumProcessModules` funzione non vedranno tutti i moduli gestiti elencati.	Nessuno.
Dichiarazione del tipo	La DeclaringType proprietà restituisce ora correttamente null quando il tipo non dispone di un tipo dichiarante.	Nessuno.
Delegati	Un delegato genera ora un'eccezione ArgumentNullException anziché un oggetto NullReferenceException quando viene passato un valore nullo al costruttore del delegato.	Assicurarsi che qualsiasi gestione delle eccezioni risolva ArgumentNullException.
Modifica del percorso della Global Assembly Cache	Per gli assembly .NET Framework 4, la Global Assembly Cache è stata spostata dalla directory di Windows (%WINDIR%) alla sottodirectory Microsoft.Net (%WINDIR%\Microsoft.Net). Gli assembly delle versioni precedenti rimangono nella directory precedente. L'enumerazione ASM_CACHE_FLAGS non gestita contiene il nuovo `ASM_CACHE_ROOT_EX` flag. Questo flag ottiene il percorso della cache per gli assembly .NET Framework 4, che possono essere ottenuti dalla funzione GetCachePath .	Nessuno, presupponendo che le applicazioni non usino percorsi espliciti per gli assembly, che non è una procedura consigliata.
Strumento Global Assembly Cache	Il Gacutil.exe (Strumento Global Assembly Cache) non supporta più il visualizzatore del plug-in di shell.	Nessuno.

Interoperabilità

Namespace: System.Runtime.InteropServices

Assembly: mscorlib (in mscorlib.dll)

Caratteristica / Funzionalità	Differenze rispetto a 3.5 SP1	Modifiche consigliate
Lunghezza del buffer (API non gestita)	Per risparmiare memoria, la funzionalità per il parametro per il `pBufferLengthOffset` metodo ICorProfilerInfo2::GetStringLayout è stata modificata in modo che corrisponda al `pStringLengthOffset` parametro . Entrambi i parametri ora puntano alla posizione di offset della lunghezza della stringa. La lunghezza del buffer è stata rimossa dalla rappresentazione della classe stringa.	Rimuovere qualsiasi dipendenza dalla lunghezza del buffer.
Debugging JIT	Per semplificare la registrazione per il debug JIT (Just-In-Time), il debugger di .NET Framework usa ora solo la chiave del Registro di sistema AeDebug, che controlla il comportamento di debug JIT per il codice nativo. Questa modifica comporta quanto segue: * Non è più possibile registrare due debugger diversi per codice gestito e nativo. * Non è più possibile avviare automaticamente il debugger per un processo non interattivo, ma è possibile richiedere all'utente un processo interattivo. * Non si riceve più una notifica quando l'avvio del debugger non riesce o quando non è presente alcun debugger registrato che deve essere avviato. * I criteri di avvio automatico che dipendono dall'interattività dell'applicazione non sono più supportati.	Modificare le operazioni di debug in base alle esigenze.
Platform invoke	Per migliorare le prestazioni di interoperabilità con codice non gestito, le convenzioni di chiamata non corrette in una piattaforma invoke ora causano un errore dell'applicazione. Nelle versioni precedenti, il livello di marshalling ha risolto questi errori nello stack.	Il debug delle applicazioni in Microsoft Visual Studio avvisa l'utente di questi errori in modo da poterle correggere. Se si dispone di file binari che non possono essere aggiornati, è possibile includere l'elemento <NetFx40_PInvokeStackResilience> nel file di configurazione dell'applicazione per consentire la risoluzione degli errori di chiamata allo stack come nelle versioni precedenti. Tuttavia, ciò può influire sulle prestazioni dell'applicazione.
Interfacce rimosse (API non gestita)	Per evitare confusione per gli sviluppatori, le interfacce seguenti sono state rimosse, perché non hanno fornito scenari di runtime utili e CLR non ha fornito o accettato alcuna implementazione: * INativeImageINativeImageDependency * INativeImageInstallInfo * INativeImageEvaluate * INativeImageConverter * ICorModule * IMetaDataConverter	Nessuno.

Dati

In questa sezione vengono descritti i problemi di migrazione per l'uso di set di dati e client SQL, Entity Framework, LINQ to SQL e WCF Data Server (in precedenza noti come ADO.NET Data Services).