Problemi relativi alla migrazione di .NET Framework 4

Articolo
08/11/2011

In questo argomento vengono descritti i problemi di migrazione tra .NET Framework 3.5 Service Pack 1 e .NET Framework versione 4, incluse le correzioni, le modifiche per la conformità con gli standard e per la sicurezza e le modifiche basate sui commenti e i suggerimenti dei clienti. La maggior parte di queste modifiche non richiede alcuna modifica a livello di codice delle applicazioni. Per quelle che possono comportare modifiche al codice, vedere la colonna Modifiche consigliate della tabella.

In questo argomento vengono descritte le modifiche significative nelle aree riportate di seguito.

ASP.NET e Web
Core
Dati
Windows Communication Foundation (WCF)
Windows Presentation Foundation (WPF)
XML

Per dei cenni preliminari di livello superiore sui problemi presenti in questo argomento, vedere Guida di migrazione a .NET Framework 4.

Per problemi di migrazione successivi a Beta 2, vedere la sezione relativa ai problemi di migrazione per le applicazioni .NET Framework 4: da Beta 2 a RTMhttps://go.microsoft.com/fwlink/?LinkId=191505.

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 sui browser e sui dispositivi nuovi e aggiornati. I browser e i dispositivi meno recenti, quali ad esempio Netscape Navigator, sono stati rimossi, mentre sono stati aggiunti i browser e i dispositivi più recenti, quali Google Chrome e Apple iPhone. Se l'applicazione contiene definizioni del browser personalizzate che ereditano dalle definizioni di uno dei browser rimossi, verrà visualizzato un errore. L'oggetto HttpBrowserCapabilities (esposto dalla proprietà della pagina Request.Browser) è determinato 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 precedente, è possibile copiarli dalla cartella seguente: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Copiare i file nella cartella \CONFIG\Browsers corrispondente per ASP.NET 4. Dopo avere copiato i file, eseguire lo strumento da riga di comando Aspnet_regbrowsers.exe. Per ulteriori informazioni, vedere il sito Web https://www.asp.net/mobile.
Applicazioni figlio che sono 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 riuscire ad avviarsi a causa di errori di configurazione o compilazione. L'errore specifico che si verifica dipende da se l'applicazione è in esecuzione 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 eseguire, vedere la sezione relativa all'errore di avvio delle applicazioni figlio di ASP.NET 4 in ASP.NET 2.0 o ASP.NET 3.5 del documento relativo alle ultime modifiche di ASP.NET 4 Beta 2 nel sito Web ASP.NET.
Modifiche a ClientID	La nuova impostazione ClientIDMode in ASP.NET 4 consente di specificare la modalità in 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 ulteriori informazioni, vedere Identificazione dei controlli server Web ASP.NET.	Se si utilizza Visual Studio 2010 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 di versioni precedenti di .NET Framework. Tuttavia, se si aggiorna un'applicazione modificando il pool di applicazioni in IIS in modo da essere destinato a .NET Framework 4, ASP.NET utilizzerà la nuova modalità per impostazione predefinita. Per disabilitare la nuova modalità per client ID, aggiungere la seguente impostazione al file Web.config: <pages ClientIDMode="AutoID" / >
Sicurezza dall'accesso di codice (CAS, Code Access Security)	Le funzionalità di ASP.NET 2.0 NET aggiunte in ASP.NET 3.5 utilizzano il modello di sicurezza dall'accesso di codice (CAS) di .NET Framework 1.1 e .NET Framework 2.0. Tuttavia, l'implementazione della sicurezza dall'accesso di codice (CAS) in ASP.NET 4 ha subito una sostanziale revisione. Di conseguenza, le applicazioni ASP.NET parzialmente attendibili che si basano su codice attendibile in esecuzione nella Global Assembly Cache potrebbero non riuscire e generare varie eccezioni di sicurezza. Anche le applicazioni parzialmente attendibili che si basano su modifiche estese ai criteri di sicurezza dall'accesso di codice del computer potrebbero non riuscire e generare eccezioni di sicurezza.	Per le applicazioni di ASP.NET 4 parzialmente attendibili è possibile ripristinare il comportamento di ASP.NET 1.1 e 2.0 utilizzando il nuovo attributo legacyCasModel nell'elemento di configurazione trust, come illustrato nell'esempio riportato di seguito. <trust level= "Medium" legacyCasModel="true" /> Nota sulla sicurezza Il ripristino del modello CAS precedente potrebbe costituire una riduzione della sicurezza. Per ulteriori informazioni sul nuovo modello di sicurezza dall'accesso di codice di ASP.NET 4, vedere Using Code Access Security in ASP.NET Applications.
File di configurazione	I file di configurazione radice (il file machine.config e il file Web.config radice) per .NET Framework e ASP.NET 4 sono stati aggiornati in modo da includere la maggior parte delle informazioni di configurazione del boilerplate presenti nei file Web.config delle applicazioni in ASP.NET 3.5. A causa della complessità dei sistemi di configurazione di IIS 7 e IIS 7.5 gestiti, l'esecuzione delle 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 applicazioni ASP.NET 3.5 a ASP.NET 4 utilizzando gli strumenti di aggiornamento del progetto presenti in Visual Studio 2010. In visual Studio 2010 il file Web.config di un'applicazione ASP.NET 3.5 viene modificato automaticamente in modo da contenere le impostazioni appropriate per ASP.NET 4. È tuttavia possibile eseguire applicazioni ASP.NET 3.5 utilizzando .NET Framework 4 senza ricompilazione. In tal caso, potrebbe essere necessario modificare manualmente il file Web.config dell'applicazione prima di eseguire l'applicazione in .NET Framework 4 e in IIS 7 o IIS 7.5. Le modifiche specifiche da apportare dipendono dalla combinazione di software in uso, incluse le versioni di Service Pack (SP). Per informazioni sulle possibili combinazioni di software interessate da questa modifica e sulle modalità di risoluzione dei problemi con le combinazioni specifiche, vedere la sezione sugli errori di configurazione correlati alla nuova configurazione radice di ASP.NET 4, nel documento relativo alle ultime modifiche di ASP.NET 4 nel sito Web ASP.NET.
Rendering di controlli	Nelle versioni precedenti di ASP.NET, alcuni controlli generavano markup che non era possibile disabilitare. Per impostazione predefinita, tale tipo di markup non viene più generato in ASP.NET 4. Le modifiche al rendering interessano i controlli riportati di seguito. 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 che non sono progettati per ricevere input dell'utente (ad esempio, il controllo Label) non eseguono più il rendering dell'attributo disabled="disabled" se la relativa proprietà Enabled viene impostata su false (o se ereditano tale impostazione da un controllo contenitore).	Se si utilizza Visual Studio 2010 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 la modalità di rendering legacy. Tuttavia, se si aggiorna un'applicazione modificando il pool di applicazioni in IIS in modo da essere destinato a .NET Framework 4, ASP.NET utilizzerà la nuova modalità di rendering per impostazione predefinita. Per disabilitare la nuova modalità di rendering, aggiungere la seguente impostazione al file Web.config: <pages controlRenderingCompatibilityVersion="3.5" />
Gestori eventi nei documenti predefiniti	ASP.NET 4 esegue il rendering del valore dell'attributo action dell'elemento HTML form come una stringa vuota quando viene effettuata una richiesta a un URL senza estensione a cui è mappato un documento predefinito. Nelle versioni precedenti di ASP.NET, una richiesta a https://contoso.com avrebbe generato una richiesta a Default.aspx. In tale documento, il rendering del tag form di apertura verrebbe eseguito come nell'esempio seguente: <form action="Default.aspx" /> Anche in ASP.NET 4, una richiesta a https://contoso.com genera una richiesta a Default.aspx, tuttavia ASP.NET ora esegue il rendering del tag HTML form di apertura come nell'esempio seguente: <form action="" /> Se l'attributo action è una stringa vuota, l'oggetto DefaultDocumentModule di IIS crea una richiesta figlio a Default.aspx. Nella maggior parte delle condizioni, tale richiesta figlio sarà trasparente al codice dell'applicazione e la pagina Default.aspx verrà eseguita normalmente. Tuttavia, una potenziale interazione tra il codice gestito e la modalità integrata di IIS 7 o IIS 7.5 può impedire il funzionamento corretto delle pagine con estensione aspx gestite durante la richiesta figlio. Se si verificano le condizioni riportate di seguito, la richiesta figlio a un documento .aspx predefinito genererà un errore o un comportamento imprevisto. Una pagina .aspx viene inviata al browser con l'attributo dell'elemento action dell'elemento form impostato su "". Il form viene inviato di nuovo a ASP.NET. Un modulo HTTP gestito legge una parte del corpo dell'entità, ad esempio Request.Form o Request.Params. Ciò causa la lettura del corpo dell'entità della richiesta POST nella memoria gestita. Di conseguenza, il corpo dell'entità non sarà più disponibile per qualsiasi modulo di codice nativo in esecuzione nella modalità integrata di IIS 7 o IIS 7.5. Verrà infine eseguito l'oggetto DefaultDocumentModule di IIS che creerà una richiesta figlio al documento Default.aspx. Tuttavia, poiché il corpo dell'entità è già stato letto da una parte del codice gestito, non esisterà alcun corpo di entità disponibile per l'invio alla richiesta figlio. Quando viene eseguita la pipeline HTTP per la richiesta figlio, il gestore dei file .aspx viene eseguito durante la fase di esecuzione gestore. Poiché non esiste alcun corpo di entità, non esisterà alcuna variabile presente nel form né alcuno stato di visualizzazione. Non esistono pertanto informazioni disponibili per il gestore della pagina .aspx per determinare quale evento (se presente) deve essere generato. Di conseguenza, nessuno dei gestori di eventi postback verrà eseguito per la pagina .aspx interessata.	Per informazioni sulle modalità per ovviare ai problemi che potrebbero insorgere a seguito di questa modifica, vedere la sezione sui gestori evento che potrebbero non essere non generati in un documento predefinito in modalità integrata IIS 7 o IIS 7.5 nel documento relativo alle ultime modifiche di ASP.NET 4 Beta 2 nel sito Web di ASP.NET.
Algoritmo hash	ASP.NET utilizza algoritmi di crittografia e hash per consentire la protezione di dati quali cookie di autenticazione form e stati di visualizzazione. Per impostazione predefinita, ASP.NET 4 utilizza l'algoritmo HMACSHA256 per le operazioni hash su cookie e stati di visualizzazione. Versioni precedenti di ASP.NET utilizzano l'algoritmo HMACSHA1 meno recente.	Se si eseguono applicazioni che combinano ASP.NET 2.0 e ASP.NET 4, laddove dati quali cookie di autenticazione form devono essere utilizzati in diverse versioni di .NET Framework, configurare un'applicazione Web di ASP.NET 4 in modo da utilizzare l'algoritmo HMACSHA1 meno recente aggiungendo l'impostazione seguente nel file Web.config: <machineKey validation="SHA1" />
Hosting di controlli in Internet Explorer	Non è più eseguire l'hosting dei controlli Windows Form in Internet Explorer, poiché ci sono soluzioni migliori sul Web. Quindi, gli assembly IEHost.dll e IEExec.dll sono stati rimossi da .NET Framework.	È possibile utilizzare le seguenti tecnologie per lo sviluppo del controllo personalizzato nelle applicazioni Web: È possibile creare un'applicazione Silverlight e configurarla per essere eseguita al di fuori del browser. Per ulteriori informazioni, vedere Out-of-Browser Support. È possibile compilare un'applicazione browser (XBAP) XAML per sfruttare le funzionalità WPF (richiede .NET Framework sui computer client). Per ulteriori 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 di virgolette singole (') come riportato di seguito. Il metodo HtmlEncode codifica le istanze del carattere di virgolette singole come ' Il metodo UrlEncode codifica le istanze del carattere di virgolette singole come %27	Esaminare il codice per individuare i punti in cui si utilizzano i metodi HtmlEncode e UrlEncode e verificare che il cambiamento di codifica non comporti una modifica tale da influenzare il funzionamento dell'applicazione.
Errori HttpException nelle applicazioni ASP.NET 2.0	Dopo che ASP.NET 4 è stato abilitato su IIS 6, le applicazioni ASP.NET 2.0 che sono in esecuzione su 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 utilizzare invece ASP.NET 2.0. -oppure- Se ASP.NET 4 è necessario per eseguire il sito Web, spostare qualsiasi directory virtuale di ASP.NET 2.0 figlio in un sito Web diverso di cui è stato eseguito il mapping a ASP.NET 2.0. -oppure- Disabilitare gli URL senza estensioni. Per ulteriori informazioni, vedere la sezione sulle applicazioni ASP.NET 2.0 che potrebbero generare errori HttpException che fanno riferimento a eurl.axd nel documento relativo alle ultime modifiche di ASP.NET 4 sul sito Web ASP.NET.
Tipi di appartenenza	Alcuni tipi (ad esempio, System.Web.Security.MembershipProvider) utilizzati nell'appartenenza ad ASP.NET sono stati spostati dall'assembly System.Web.dll a System.Web.ApplicationServices.dll. I tipi sono stati spostati per risolvere le dipendenze di livello architetturale tra i tipi nel client e nelle SKU di .NET Framework estese.	Le librerie di classi aggiornate da versioni precedenti di ASP.NET e che utilizzano i tipi di appartenenza che sono stati spostati potrebbero non riuscire ad eseguire la compilazione se utilizzate in un progetto ASP.NET 4. In tal caso, aggiungere un riferimento al progetto della libreria di classi a System.Web.ApplicationServices.dll.
Modifiche al controllo Menu	Le modifiche al controllo Menu danno come risultato il seguente comportamento: Se System.Web.UI.WebControls.MenuRenderingMode è impostato su List, o se System.Web.UI.WebControls.MenuRenderingMode è impostato su Default e PagesSection.ControlRenderingCompatibilityVersion è impostato su 4.0 o versione successiva, la proprietà MenuItem.PopOutImageUrl non diventa effettiva. Se il percorso che viene impostato nelle proprietà Menu.StaticPopOutImageUrl e Menu.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à MenuItem.PopOutImageUrl per le voci di menu singole, impostare Menu.StaticPopOutImageUrl o Menu.DynamicPopOutImageUrl del controllo System.Web.UI.WebControls.Menu padre. -oppure- Impostare System.Web.UI.WebControls.MenuRenderingMode su Table, oppure impostare System.Web.UI.WebControls.MenuRenderingMode su Default e impostare PagesSection.ControlRenderingCompatibilityVersion su 3.5. Queste impostazioni fanno in modo che il controllo Menu utilizzi il layout basato su tabella HTML utilizzato nelle versioni precedenti di ASP.NET. Se il percorso nella proprietà Menu.StaticPopOutImageUrl o Menu.DynamicPopOutImageUrl contiene una barra rovesciata (\), sostituire un carattere barra (/).
Assembly mobile nel file Web.config	Nelle versioni precedenti di ASP.NET, un riferimento all'assembly System.Web.Mobile.dll era incluso nel file Web.config radice nella sezione assemblies in 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 di ASP.NET sono inclusi in ASP.NET 4, ma sono deprecati.	Se si desidera utilizzare i tipi da questo assembly, aggiungere un riferimento all'assembly nel file Web.config radice o in un file Web.config dell'applicazione.
Memorizzazione nella cache di output	In ASP.NET 1.0, un bug causava la generazione, da parte delle pagine memorizzate nella cache che specificavano Location="ServerAndClient" come un'impostazione della cache di output, di un'intestazione HTTP Vary:* nella risposta. Ciò aveva l'effetto di comunicare ai browser dei client di non memorizzare mai la pagina nella cache in locale. In ASP.NET 1.1, è stato aggiunto il metodo HttpCachePolicy.SetOmitVaryStar che può essere chiamato per eliminare l'intestazione Vary:. Tuttavia, le segnalazioni dei bug suggeriscono che gli sviluppatori non sono a conoscenza del funzionamento di SetOmitVaryStar esistente. In ASP.NET 4, l'intestazione HTTP Vary: non viene generata più in seguito a risposte che specificano la direttiva seguente: <%@ OutputCache Location="ServerAndClient" %> Di conseguenza, il metodo HttpCachePolicy.SetOmitVaryStar non è più necessario per eliminare l'intestazione Vary:*. Nelle applicazioni che specificano "ServerAndClient" per l'attributo Location, le pagine saranno memorizzabili nella cache del browser senza necessità di chiamare HttpCachePolicy.SetOmitVaryStar.	Se le pagine nell'applicazione devono generare l'intestazione Vary:, chiamare il metodo HttpResponse.AppendHeader come illustrato nell'esempio seguente: HttpResponse.AppendHeader("Vary",""); In alternativa, è possibile impostare su "Server" il valore dell'attributo Location di memorizzazione nella cache di output.
Analisi pagina	Il parser della pagina per le pagine Web ASP.NET (file aspx) e i controlli utente (file .ascx) sono più severi in ASP.NET 4 rispetto alle versioni precedenti di ASP.NET e sono contrassegnate più markup come non valide rispetto alle versioni precedenti.	Esaminare i messaggi di errore prodotti quando una pagina è in esecuzione e correggere gli errori risultanti da una markup non valida.
Tipi Passport	Il supporto Passport incorporato in ASP.NET 2.0 è obsoleto e non è supportato a causa delle modifiche a Passport (ora Live ID SDK). Di conseguenza, i tipi correlati a Passport in System.Web.Security sono ora contrassegnati dall'attributo ObsoleteAttribute.	Modificare qualsiasi parte del codice che utilizza tipi Passport nello spazio dei nomi System.Web.Security (ad esempio, System.Web.Security.PassportIdentity) in modo da utilizzare Windows Live ID SDK (la pagina potrebbe essere in inglese).
Informazioni PathInfo nella proprietà FilePath	ASP.NET 4 non include più il valore PathInfo nei valori restituiti da proprietà quali ad esempio HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath e HttpRequest.CurrentExecutionFilePath. Invece, le informazioni su PathInfo sono disponibili in HttpRequest.PathInfo. Si consideri ad esempio il seguente frammento di URL: /testapp/Action.mvc/SomeAction Nelle versioni precedenti di ASP.NET, le proprietà System.Web.HttpRequest hanno i valori seguenti: HttpRequest.FilePath: /testapp/Action.mvc/SomeAction HttpRequest.PathInfo: (vuoto) In ASP.NET 4 invece, le proprietà System.Web.HttpRequest hanno i valori seguenti: HttpRequest.FilePath: /testapp/Action.mvc HttpRequest.PathInfo: SomeAction	Esaminare il codice per individuare i punti in cui è basato su proprietà della classe System.Web.HttpRequest per restituire informazioni sul percorso. Modificare quindi il codice per riflettere le modifiche al modo in cui vengono restituite le informazioni sul percorso.
Convalida delle richieste	Per migliorare il processo di convalida delle richieste, in ASP.NET la convalida delle richieste viene chiamata in anticipo nel ciclo di vita della richiesta. Di conseguenza, la convalida delle richieste viene eseguita per richieste non di file con estensione aspx, quali ad esempio le chiamate del servizio Web e le chiamate di gestori personalizzati. La convalida delle richieste sarà attiva anche quando moduli HTTP personalizzati sono in esecuzione nella pipeline di elaborazione delle richieste. A seguito di questa modifica, le richieste di risorse diverse da file .aspx potrebbero generare errori di convalida della richiesta. Il codice personalizzato in esecuzione nella pipeline delle richieste (ad esempio, moduli HTTP personalizzati) potrebbe inoltre generare errori di convalida della richiesta.	Se necessario, è possibile ripristinare il comportamento precedente, in cui solo le pagine con estensione aspx attivano l'esecuzione della convalida delle richieste, utilizzando l'impostazione seguente nel file Web.config: <httpRuntime requestValidationMode="2.0" /> Nota sulla sicurezza Se si ripristina il comportamento precedente, assicurarsi che tutto il codice nei gestori esistenti, i moduli e gli altri codici personalizzati esegua i controlli per input HTTP potenzialmente non sicuri che potrebbero rappresentare dei rischi di attacco di XSS.
Routing	Se si crea un sito Web del file system in Visual Studio 2010 e il sito Web è in una cartella che contiene un punto (.) nel nome della cartella, il routing dell'URL non funzionerà in maniera affidabile. Un errore HTTP 404 viene restituito da alcuni percorsi virtuali. Questo accade perché Visual Studio 2010 avvia Visual Studio Development Server (Cassini) utilizzando un percorso errato per la directory virtuale radice.	Nella pagina Proprietà del sito Web basato su file, modificare l'attributo Percorso virtuale in "/." -oppure- Creare un progetto dell'applicazione Web invece di un progetto del sito Web. I progetti dell'applicazione Web non hanno questo problema e il routing dell'URL funziona anche se la cartella del progetto ha un punto nel nome. -oppure- Creare un sito Web basato su HTTP di cui è stato eseguito l'hosting in IIS. I siti Web di cui è stato eseguito l'hosting da IIS possono avere punti nel percorso virtuale e nella cartella del file di progetto.
Siti SharePoint	Se si tenta di 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, verrà visualizzato l'errore seguente: Could not find permission set named 'ASP.Net'.	Al momento, nessuna versione di SharePoint è compatibile con ASP.NET. Di conseguenza, non è necessario tentare di eseguire un sito Web ASP.NET 4 come figlio di un sito Web SharePoint.
Standard XHTML 1.1	Per abilitare la conformità a XHTML 1.1 per i nuovi siti Web, i controlli ASP.NET in .NET Framework 4 genereranno un codice HTML conforme a XHTML 1.1. Questo rendering viene abilitato utilizzando la seguente opzione nel file Web.config: <system.Web> <pages controlRenderingCompatibilityVersion="4.0"/> </system.Web> Per impostazione predefinita, questa opzione è impostata su 4.0. L'impostazione 3.5 sarà abilitata per conformità ai progetti Web aggiornati a Visual Studio da Visual Studio 2008.	Nessuna.

Torna all'inizio

Core

Funzionalità generali

Funzionalità	Differenze rispetto alla versione 3.5 SP1	Modifiche consigliate
CardSpace	Windows CardSpace non è incluso più in .NET Framework; viene fornito separatamente.	Scaricare Windows CardSpace da Microsoft Download Center.
File di configurazione	Sono state eseguite correzioni alla modalità di accesso di .NET Framework ai file di configurazione dell'applicazione.	Se il file di configurazione dell'applicazione è denominato nome-applicazione.config, rinominarlo in nome-applicazione.exe.config. Ad esempio, rinominare MyApp.config in MyApp.exe.config.
Compilatore codice C#	Le classi Compiler, CompilerError e ErrorLevel che si trovavano nello spazio dei nomi Microsoft.CSharp non sono più disponibili e il relativo assembly (cscompmgd.dll) non è più incluso in .NET Framework.	Utilizzare la classe CodeDomProvider e altre classi nello spazio dei nomi System.CodeDom.Compiler. Per ulteriori informazioni, vedere Utilizzo di CodeDOM.
Hosting (API non gestita)	Per migliorare le funzionalità di hosting, alcune delle API di attivazione hosting sono state dichiarate come 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 mediante le quali vengono caricati componenti aggiuntivi (o componenti) basati su .NET Framework 2.0 SP1 e componenti aggiuntivi basati su .NET Framework 4 nello stesso processo. I componenti precedenti continuano a utilizzare la versione di .NET Framework precedente, mentre i nuovi componenti utilizzano la nuova versione di .NET Framework.	Utilizzare le configurazioni descritte in Esecuzione side-by-side in-process.
Nuovo modello di sicurezza	I criteri di sicurezza dall'accesso di codice (CAS) sono stati disattivati e sostituiti con un modello semplificato, come descritto in Modifiche della sicurezza in .NET Framework 4.	Possono essere necessarie modifiche se le applicazioni dipendono dai criteri di sicurezza dall'accesso di codice. Per ulteriori informazioni, vedere Migrazione e compatibilità dei criteri di sicurezza dall'accesso di codice.

Torna all'inizio

Data e ora

Spazio dei nomi: System; assembly: mscorlib (in mscorlib.dll)

Funzionalità	Differenze rispetto alla versione 3.5 SP1	Modifiche consigliate
Ora legale	Per garantire la coerenza con l'orologio di sistema, le proprietà relative all'ora (quale TimeZoneInfo.Local e DateTime.Now) adesso utilizzano regole del sistema operativo anziché altri dati di .NET Framework per le operazioni relative all'ora legale.	Nessuna correzione.
Formattazione di stringhe	Per supportare la formattazione dipendente dalle impostazioni cultura, la struttura TimeSpan include nuovi overload dei metodi ToString, Parse e TryParse, oltre ai nuovi metodi ParseExact e TryParseExact.	Nessuna correzione.

Torna all'inizio

Globalizzazione

Per un elenco di nuove impostazioni cultura non associate ad alcun paese e specifiche, vedere Novità relative alla globalizzazione e alla localizzazione.

Spazio dei nomi: System.Globalization; assembly: mscorlib (in mscorlib.dll)

Funzionalità	Differenze rispetto alla versione 3.5 SP1	Modifiche consigliate
Nomi delle impostazioni cultura	Le modifiche dei nomi riportate di seguito interessano le impostazioni cultura tedesche, Divehi e africane. CurrencyEnglishName: il nome della valuta per le impostazioni cultura del tedesco (Svizzera) "de-CH" è stato modificato da "sFr." a "Fr.". LongDatePattern: il modello di data estesa per le impostazioni cultura del divehi (Maldive) (dv-MV) è stato modificato da "dd/MMMM/yyyy" a "dd/MM/yyyy". PMDesignator: l'indicatore PM delle impostazioni cultura dell'afrikaans (Sudafrica) (af-ZA) è stato modificato da "nm" a "PM."	Annotare le modifiche ai nomi delle impostazioni cultura.
Parametro LCID	Per garantire la coerenza con il comportamento previsto nelle impostazioni del server di automazione, CLR non passa più le impostazioni cultura correnti per il parametro LCID alle applicazioni basate su COM non gestite. Invece passa 1033 (en-us) per le impostazioni cultura.	Non sono necessarie modifiche a eccezione di applicazioni native che richiedono una specifica impostazione cultura.
Tipi di impostazioni cultura obsoleti	I tipi di impostazioni cultura FrameworkCultures e WindowsOnlyCultures sono ora considerati obsoleti. Per la compatibilità con versioni precedenti, FrameworkCultures adesso restituisce le impostazioni cultura neutre e specifiche incluse con la versione precedente di .NET Framework, mentre WindowsOnlyCultures adesso restituisce un elenco vuoto.	Utilizzare altri valori dell'enumerazione CultureTypes.
Recupero di impostazioni cultura	A partire da Windows 7, .NET Framework 4 recupera le informazioni sulle impostazioni cultura dal sistema operativo anziché provvedere ad archiviare tali dati. Inoltre, .NET Framework si sincronizza con Windows per l'ordinamento e la distinzione tra maiuscole e minuscole.	Nessuna correzione.
Standard Unicode 5.1	.NET Framework ora supporta tutti i caratteri Unicode 5.1: un'aggiunta di circa 1400 caratteri. I caratteri aggiuntivi includono i nuovi simboli, frecce, segni diacritici, punteggiatura, simboli matematici, ideogrammi e tratti CJK, caratteri numerici aggiuntivi Malayalam e Telugu e vari caratteri birmani, latini, arabi, greci, mongoli e cirillici. I nuovi script riportati di seguito sono supportati con Unicode 5.1: Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Oriya, Tamil, Telugu e caratteri Malayalam e Cham.	Nessuna correzione.

Torna all'inizio

Eccezioni

Spazi dei nomi: System, System.Runtime.ExceptionServices; assembly: mscorlib (in mscorlib.dll)

Funzionalità	Differenze rispetto alla versione 3.5 SP1	Modifiche consigliate
Eccezioni per lo stato di processo danneggiato	CLR non recapita più eccezioni per lo stato di processo danneggiato ai gestori di eccezioni nel codice gestito.	Queste eccezioni indicano che lo stato di un processo è stato danneggiato. Non si consiglia di eseguire l'applicazione in questo stato. Per ulteriori informazioni, vedere la sezione relativa alle HandleProcessCorruptedStateExceptionsAttribute e la voce sulla gestione delle eccezioni sullo stato danneggiato nel blog Tutto su CRL.
Eccezioni del motore di esecuzione	ExecutionEngineException è ora obsoleta, perché un'eccezione intercettabile consentirà a un processo instabile di restare in esecuzione. Questa modifica migliora la prevedibilità e l'affidabilità nel runtime.	Utilizzare un'eccezione InvalidOperationException per notificare la condizione.

Eccezioni per lo stato di processo danneggiato

CLR non recapita più eccezioni per lo stato di processo danneggiato ai gestori di eccezioni nel codice gestito.

Queste eccezioni indicano che lo stato di un processo è stato danneggiato. Non si consiglia di eseguire l'applicazione in questo stato.

Per ulteriori informazioni, vedere la sezione relativa alle HandleProcessCorruptedStateExceptionsAttribute e la voce sulla gestione delle eccezioni sullo stato danneggiato nel blog Tutto su CRL.

Eccezioni del motore di esecuzione

ExecutionEngineException è ora obsoleta, perché un'eccezione intercettabile consentirà a un processo instabile di restare in esecuzione. Questa modifica migliora la prevedibilità e l'affidabilità nel runtime.

Utilizzare un'eccezione InvalidOperationException per notificare la condizione.

Torna all'inizio

Reflection

Spazio dei nomi: System.Reflection; assembly: mscorlib (in mscorlib.dll)

Funzionalità	Differenze rispetto alla versione 3.5 SP1	Modifiche consigliate
Algoritmi hash dell'assembly	La proprietà AssemblyName.HashAlgorithm restituisce ora AssemblyHashAlgorithm.None, perché il runtime non conosce l'algoritmo hash dell'assembly a cui si fa riferimento quando l'assembly non viene caricato. Si riferisce all'utilizzo della proprietà per un assembly a cui viene fatto riferimento quale quello restituito dal metodo Assembly.GetReferencedAssemblies.	Nessuna correzione.
Caricamento di assembly	Per evitare il caricamento ridondante di assembly e salvare spazio degli indirizzi virtuali, CLR ora carica gli assembly solo tramite la funzione Win32 MapViewOfFile. Inoltre non chiama più la funzione LoadLibrary. Questa modifica influisce sulle applicazioni diagnostiche nelle modalità riportate di seguito. Un ProcessModuleCollection non conterrà più moduli da una libreria di classi (file .dll), come si ottiene chiamando Process.GetCurrentProcess().Modules. Le applicazioni Win32 che utilizzano la funzione EnumProcessModules non vedranno elencati tutti i moduli gestiti.	Nessuna correzione.
Dichiarazione del tipo	La proprietà Type.DeclaringType ora restituisce correttamente null quando il tipo non dispone di un tipo dichiarante.	Nessuna correzione.
Delegati	Un delegato ora genera un'eccezione ArgumentNullException anziché un NullReferenceException quando viene passato un valore null al costruttore del delegato.	Assicurarsi che qualsiasi gestione di eccezioni intercetti ArgumentNullException.
Modifica del percorso della Global Assembly Cache	Per gli assembly di .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 contrassegno ASM_CACHE_ROOT_EX. Questo contrassegno ottiene il percorso della cache per gli assembly di .NET Framework 4 che può essere ottenuto dalla funzione GetCachePath.	Nessuna, presupponendo che le applicazioni non utilizzino percorsi espliciti a assembly, cosa che rappresenta una procedura non consigliata.
Strumento Global Assembly Cache.	Il visualizzatore del plug-in della shell non è più supportato da Gacutil.exe (strumento Global Assembly Cache).	Nessuna correzione.

Interoperabilità

Spazio dei nomi: System.Runtime.InteropServices; assembly: mscorlib (in mscorlib.dll)

Funzionalità	Differenze rispetto alla versione 3.5 SP1	Modifiche consigliate
Lunghezza buffer (API non gestita)	Al fine di risparmiare memoria, la funzionalità del parametro pBufferLengthOffset per il metodo ICorProfilerInfo2::GetStringLayout è stata modificata per corrispondere al parametro pStringLengthOffset. 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.
Debug JIT	Per semplificare la registrazione per il debug JIT (just-in-time), il debugger di .NET Framework utilizza ora solo la chiave del Registro di sistema AeDebug che controlla il comportamento del debug JIT per il codice nativo. Questa modifica comporta quanto riportato di seguito. Non è più possibile registrare due debugger diversi per il codice gestito e il codice nativo. Non è più possibile avviare automaticamente il debugger per un processo non interattivo, ma è possibile richiedere all'utente un processo interattivo. Gli utenti non ricevono più una notifica quando non è possibile avviare il debugger o quando non esiste alcun debugger registrato da avviare. I criteri di avvio automatico che dipendono dall'interattività dell'applicazione non sono più supportati.	Regolare le operazioni di debug in base alle necessità.
Platform invoke	Al fine di migliorare le prestazioni in termini di interoperabilità con codice non gestito, le convenzioni di chiamata errate in un platform invoke ora causano il mancato completamento dell'applicazione. Nelle versioni precedenti, il livello del marshalling risolveva questi errori sullo stack.	Eseguendo il debug delle applicazioni in Microsoft Visual Studio 2010, tali errori verranno segnalati in modo da poterli correggere. Se si dispone di binari che non possono essere aggiornati, è possibile includere l'elemento <NetFx40_PInvokeStackResilience> nel file di configurazione dell'applicazione per abilitare la risoluzione degli errori di chiamata sullo stack come nelle versioni precedenti. Ciò tuttavia potrà avere effetto sulle prestazioni dell'applicazione.
Interfacce rimosse (API non gestita)	Per evitare di confondere gli sviluppatori, le interfacce riportate di seguito sono state rimosse, perché non fornivano alcuno scenario utile di runtime e CLR non ne forniva e non ne accettava alcuna implementazione: INativeImageINativeImageDependency INativeImageInstallInfo INativeImageEvaluate INativeImageConverter ICorModule IMetaDataConverter	Nessuna correzione.

Torna all'inizio

Dati

In questa sezione vengono descritti i problemi di migrazione per l'utilizzo di set di dati e client SQL, Entity Framework, LINQ to SQL e server di dati WCF (precedentemente noto come ADO.NET Data Services).