Migreringsproblem med .NET Framework 4

Artikel
03/02/2024

I den här artikeln beskrivs migreringsproblem mellan .NET Framework version 3.5 Service Pack 1 och .NET Framework version 4, inklusive korrigeringar, ändringar av standarders efterlevnad och säkerhet samt ändringar baserat på kundfeedback. De flesta av dessa ändringar kräver inga programmeringsändringar i dina program. För de som kan innebära ändringar, se kolumnen Rekommenderade ändringar i tabellen. Anmärkningsvärda ändringar är uppdelade efter område, till exempel ASP.NET och Windows Presentation Foundation (WPF).

En översikt över problemen i den här artikeln finns i Migreringsguide till .NET Framework 4.

Information om nya funktioner finns i Nyheter i .NET Framework 4.

ASP.NET och webb

Namnområden: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls

Sammansättning: System.Web (i System.Web.dll)

Funktion	Skillnader från 3,5 SP1	Rekommenderade ändringar
Webbläsardefinitionsfiler	Webbläsardefinitionsfilerna har uppdaterats så att de innehåller information om nya och uppdaterade webbläsare och enheter. Äldre webbläsare och enheter som Netscape Navigator har tagits bort och nyare webbläsare och enheter som Google Chrome och Apple i Telefon har lagts till. Om ditt program innehåller anpassade webbläsardefinitioner som ärver från någon av webbläsardefinitionerna som har tagits bort visas ett fel. Objektet HttpBrowserCapabilities (som exponeras av sidans egenskap) drivs av webbläsardefinitionsfilerna `Request.Browse` . Därför kan informationen som returneras genom åtkomst till en egenskap för det här objektet i ASP.NET 4 skilja sig från den information som returnerades i en tidigare version av ASP.NET.	Om programmet förlitar sig på de gamla webbläsardefinitionsfilerna kan du kopiera dem från följande mapp: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Kopiera filerna till motsvarande \CONFIG\Browsers-mapp för ASP.NET 4. När du har kopierat filerna kör du kommandoradsverktyget Aspnet_regbrowsers.exe . Mer information finns på https://www.asp.net/mobile webbplatsen.
Underordnade program som körs under blandade versioner av ASP.NET	ASP.NET 4 program som är konfigurerade som underordnade program som kör tidigare versioner av ASP.NET kan misslyckas med att starta på grund av konfigurations- eller kompileringsfel. Det specifika fel som uppstår beror på om programmet körs under IIS 6.0 eller under IIS 7 eller IIS 7.5.	Du kan göra ändringar i konfigurationsfilerna för de berörda programmen så att konfigurationssystemet känner igen ASP.NET 4-programmet korrekt. Information om de ändringar du måste göra finns i avsnittet "ASP.NET 4 underordnade program kan inte starta när under ASP.NET 2.0 eller ASP.NET 3.5-program" i dokumentet ASP.NET 4 icke-bakåtkompatibla ändringar på ASP.NET webbplats.
ClientID-ändringar	Med den nya `clientIDMode` inställningen i ASP.NET 4 kan du ange hur ASP.NET genererar `id` attributet för HTML-element. I tidigare versioner av ASP.NET var standardbeteendet detsamma som `AutoID` inställningen `clientIDMode`för . Standardinställningen är nu `Predictable`. Mer information finns i ASP.NET webserverkontrollidentifiering.	Om du använder Visual Studio för att uppgradera programmet från ASP.NET 2.0 eller ASP.NET 3.5 lägger verktyget automatiskt till en inställning i filen Web.config som bevarar beteendet för tidigare versioner av .NET Framework. Men om du uppgraderar ett program genom att ändra programpoolen i IIS till att rikta in sig på .NET Framework 4 använder ASP.NET det nya läget som standard. Om du vill inaktivera det nya klient-ID-läget lägger du till följande inställning i filen Web.config: `<pages clientIDMode="AutoID" />`
Kodåtkomstsäkerhet (CAS)	ASP.NET 2.0 NET-funktioner som lades till i ASP.NET 3.5 använder du CAS-modellen (.NET Framework 1.1 och .NET Framework 2.0 code access security). Genomförandet av CAS i ASP.NET 4 har dock setts över avsevärt. Därför kan partiellt förtroende ASP.NET program som förlitar sig på betrodd kod som körs i den globala sammansättningscachen misslyckas med olika säkerhetsundanstag. Program med partiellt förtroende som förlitar sig på omfattande ändringar av datorns CAS-princip kan också misslyckas och utlösa säkerhetsundantag.	Du kan återställa partiellt förtroende ASP.NET 4 program till beteendet för ASP.NET 1.1 och 2.0 med hjälp av det nya `legacyCasModel` attributet i `trust` konfigurationselementet, som du ser i följande exempel: `<trust level= "Medium" legacyCasModel="true" />` Viktigt: Om du återgår till den äldre CAS-modellen kan säkerheten minska. Mer information om den nya säkerhetsmodellen ASP.NET 4 kod finns i Kodåtkomstsäkerhet i ASP.NET 4 program.
Konfigurationsfiler	Rotkonfigurationsfilerna (filen machine.config och web.config-rotfilen) för .NET Framework och ASP.NET 4 har uppdaterats för att inkludera de flesta av konfigurationsinformationen för boilerplate som hittades i application Web.config-filerna i ASP.NET 3.5. På grund av komplexiteten i de hanterade IIS 7- och IIS 7.5-konfigurationssystemen kan körning av ASP.NET 3.5-program under ASP.NET 4 och under IIS 7 och IIS 7.5 resultera i antingen ASP.NET fel eller IIS-fel.	Uppgradera ASP.NET 3.5-program till ASP.NET 4 med hjälp av projektuppgraderingsverktygen i Visual Studio. Visual Studio 2010 ändrar automatiskt ASP.NET 3.5-programmets Web.config-fil så att den innehåller lämpliga inställningar för ASP.NET 4. Du kan dock köra ASP.NET 3.5-program med hjälp av .NET Framework 4 utan omkompilering. I så fall kan du behöva ändra programmets Web.config-fil manuellt innan du kör programmet under .NET Framework 4 och under IIS 7 eller IIS 7.5. Den specifika ändring du måste göra beror på vilken kombination av programvara du arbetar med, inklusive Service Pack-versioner (SP). Information om möjliga programvarukombinationer som påverkas av den här ändringen och hur du löser problem med specifika kombinationer finns i avsnittet "Konfigurationsfel relaterade till ny ASP.NET 4 rotkonfiguration" i dokumentet ASP.NET 4 icke-bakåtkompatibla ändringar på ASP.NET webbplats.
Kontrollåtergivning	I tidigare versioner av ASP.NET har vissa kontroller genererat markering som du inte kunde inaktivera. Som standard genereras inte längre den här typen av markering i ASP.NET 4. Återgivningsändringarna påverkar följande kontroller: * Kontrollerna `Image` och `ImageButton` renderar inte längre ett `border="0"` attribut. * De `BaseValidator` klass- och valideringskontroller som härleds från den återger inte längre röd text som standard. * Kontrollen `HtmlForm` renderar inte ett `name` attribut. * Kontrollen `Table` renderar inte längre ett `border="0"` attribut. Kontroller som inte är utformade för användarindata (till exempel `Label` kontrollen) återger `disabled="disabled"` inte längre attributet om deras `Enabled` egenskap är inställd på `false` (eller om de ärver den här inställningen från en containerkontroll).	Om du använder Visual Studio för att uppgradera programmet från ASP.NET 2.0 eller ASP.NET 3.5 lägger verktyget automatiskt till en inställning i filen Web.config som bevarar äldre rendering. Men om du uppgraderar ett program genom att ändra programpoolen i IIS till mål för .NET Framework 4 använder ASP.NET det nya återgivningsläget som standard. Om du vill inaktivera det nya återgivningsläget lägger du till följande inställning i filen Web.config: `<pages controlRenderingCompatibilityVersion="3.5" />`
Händelsehanterare i standarddokument	ASP.NET 4 återges HTML-elementets `formaction` attributvärde som en tom sträng när en begäran görs till en tilläggslös URL som har ett standarddokument mappat till det. I tidigare versioner av ASP.NET skulle en begäran till `http://contoso.com` resultera i en begäran om att Default.aspx. I det dokumentet återges den inledande `form` taggen som i följande exempel: `<form action="Default.aspx" />` I ASP.NET 4 resulterar en begäran om att `http://contoso.com` även resultera i en begäran om att Default.aspx, men ASP.NET återger nu HTML-öppningstaggen `form` som i följande exempel: `<form action="" />` `action` När attributet är en tom sträng skapar IIS-objektet `DefaultDocumentModule` en underordnad begäran till Default.aspx. Under de flesta förhållanden är den här underordnade begäran transparent för programkod och den Default.aspx sidan körs normalt. En potentiell interaktion mellan hanterad kod och IIS 7- eller IIS 7.5-integrerat läge kan dock leda till att hanterade .aspx sidor slutar fungera korrekt under den underordnade begäran. Om följande villkor inträffar resulterar den underordnade begäran till ett standarddokument .aspx ett fel eller ett oväntat beteende: * En .aspx sida skickas till webbläsaren med elementets `formaction` attribut inställt på "". * Formuläret skickas tillbaka till ASP.NET. * En hanterad HTTP-modul läser en del av entitetstexten, till exempel `Request.Form` eller `Request.Params`. Detta gör att entitetstexten i POST-begäran läss in i hanterat minne. Därför är entitetstexten inte längre tillgänglig för interna kodmoduler som körs i IIS 7- eller IIS 7.5-integrerat läge. * IIS-objektet `DefaultDocumentModule` körs så småningom och skapar en underordnad begäran till Default.aspx dokumentet. Men eftersom entitetstexten redan har lästs av en del av den hanterade koden finns det ingen entitetstext tillgänglig att skicka till den underordnade begäran. * När HTTP-pipelinen körs för den underordnade begäran körs hanteraren för .aspx filer under hanterarens körningsfas. Eftersom det inte finns någon entitetstext finns det inga formulärvariabler och inget visningstillstånd. Det finns därför ingen tillgänglig information för .aspx sidhanterare för att avgöra vilken händelse (om någon) som ska aktiveras. Därför körs ingen av postback-händelsehanterarna för den berörda .aspx sidkörningen.	Information om hur du kan kringgå problem som kan uppstå till följd av den här ändringen finns i "Händelsehanterare kanske inte genereras i ett standarddokument i IIS 7 eller IIS 7.5 Integrerat läge" i dokumentet ASP.NET 4 Icke-bakåtkompatibla ändringar på ASP.NET webbplats.
Hash-algoritm	ASP.NET använder både krypterings- och hashalgoritmer för att skydda data som formulärautentiseringscookies och visningstillstånd. Som standard använder ASP.NET 4 algoritmen HMACSHA256 för hash-åtgärder på cookies och visningstillstånd. Tidigare versioner av ASP.NET använde den äldre HMACSHA1 algoritmen.	Om du kör program som blandar ASP.NET 2.0 och ASP.NET 4, där data som formulärautentiseringscookies måste fungera mellan .NET Framework-versioner, konfigurerar du ett ASP.NET 4-webbprogram för att använda den äldre HMACSHA1 algoritmen genom att lägga till följande inställning i filen Web.config: `<machineKey validation="SHA1" />`
Värdkontroller i Internet Explorer	Du kan inte längre vara värd för Windows Forms-kontroller i Internet Explorer, eftersom det finns bättre lösningar för att hantera kontroller på webben. Därför har IEHost.dll och IEExec.exe sammansättningar tagits bort från .NET Framework.	Du kan använda följande tekniker för anpassad kontrollutveckling i webbprogram: * Du kan skapa ett Silverlight-program och konfigurera det så att det körs utanför webbläsaren. Mer information finns i Out-of-Browser Support. * Du kan skapa ett XAML-webbläsarprogram (XBAP) för att dra nytta av WPF-funktioner (kräver .NET Framework på klientdatorer). Mer information finns i Översikt över WPF XAML-webbläsarprogram.
HtmlEncode- och UrlEncode-metoder	Metoderna `HtmlEncode` och `UrlEncode` för HttpUtility klasserna och HttpServerUtility har uppdaterats för att koda det enkla citattecknet (') enligt följande: * Metoden `HtmlEncode` kodar instanser av det enkla citattecknet som `'` * Metoden `UrlEncode` kodar instanser av det enkla citattecknet som `%27`	Granska koden för platser där du använder `HtmlEncode` metoderna och `UrlEncode` och se till att ändringen i kodningen inte resulterar i en ändring som skulle påverka ditt program.
HttpException-fel i ASP.NET 2.0-program	När ASP.NET 4 har aktiverats i IIS 6 kan ASP.NET 2.0-program som körs på IIS 6 (antingen i Windows Server 2003 eller Windows Server 2003 R2) generera fel som följande: `System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.`	* Om ASP.NET 4 inte krävs för att köra webbplatsen, mappa om webbplatsen så att den använder ASP.NET 2.0 i stället. -eller- * Om ASP.NET 4 krävs för att köra webbplatsen flyttar du eventuella underordnade ASP.NET 2,0 virtuella kataloger till en annan webbplats som är mappad till ASP.NET 2.0. -eller- * Inaktivera tilläggslösa URL:er. Mer information finns i "ASP.NET 2.0-program kan generera HttpException-fel som refererar till eurl.axd" i dokumentet ASP.NET 4 icke-bakåtkompatibla ändringar på webbplatsen ASP.NET.
Medlemskapstyper	Vissa typer (till exempel MembershipProvider) som används i ASP.NET medlemskap har flyttats från System.Web.dll till System.Web.ApplicationServices.dll sammansättning. Typerna flyttades för att lösa beroenden för arkitekturskikt mellan typer i klienten och i utökade .NET Framework-SKU:er.	Klassbibliotek som har uppgraderats från tidigare versioner av ASP.NET och som använder medlemskapstyper som har flyttats kan inte kompileras när de används i ett ASP.NET 4-projekt. I så fall lägger du till en referens i klassbiblioteksprojektet i System.Web.ApplicationServices.dll.
Ändringar i menykontroll	Ändringar i Menu kontrollen resulterar i följande beteende: * Om MenuRenderingMode är inställt på `List`, eller om MenuRenderingMode är inställt på `Default` och ControlRenderingCompatibilityVersion är inställt på `4.0` eller senare, har egenskapen PopOutImageUrl ingen effekt. * Om sökvägen som anges i StaticPopOutImageUrl egenskaperna och DynamicPopOutImageUrl innehåller ett omvänt snedstreck (\) återges inte bilderna. (I tidigare versioner av ASP.NET kan sökvägen innehålla ett omvänt snedstreck.)	* I stället för att PopOutImageUrl ange egenskapen för enskilda menyalternativ anger du StaticPopOutImageUrl eller DynamicPopOutImageUrl för den överordnade Menu kontrollen. -eller- Ange MenuRenderingMode till `Table`, eller ange MenuRenderingMode till `Default` och inställt ControlRenderingCompatibilityVersion på `3.5`. De här inställningarna gör Menu att kontrollen använder den HTML-tabellbaserade layout som den använde i tidigare versioner av ASP.NET. * Om sökvägen i StaticPopOutImageUrl egenskapen eller DynamicPopOutImageUrl innehåller ett omvänt snedstreck (\) ersätter du ett snedstreck (/).
Mobil sammansättning i web.config-fil	I tidigare versioner av ASP.NET inkluderades en referens till System.Web.Mobile.dll-sammansättningen i rotfilen Web.config i `assemblies` avsnittet under/`system.webcompilation` . För att förbättra prestandan har referensen till den här sammansättningen tagits bort. Obs! System.Web.Mobile.dll-sammansättningen och de ASP.NET mobila kontrollerna ingår i ASP.NET 4, men de är inaktuella.	Om du vill använda typer från den här sammansättningen lägger du till en referens till sammansättningen i antingen rotfilen Web.config eller i en web.config-fil för ett program.
Cachelagring av utdata	I ASP.NET 1.0 orsakade en bugg cachelagrade sidor som angavs `Location="ServerAndClient"` som en cacheinställning för utdata€" för att generera ett `Vary:` HTTP-huvud i svaret. Detta hade effekten att be klientwebbläsare att aldrig cachelagrar sidan lokalt. I ASP.NET 1.1 SetOmitVaryStar lades metoden till, vilket kan anropas för att utelämna `Vary:` rubriken. Buggrapporter tyder dock på att utvecklare inte känner till det befintliga `SetOmitVaryStar` beteendet. I ASP.NET 4 `Vary:` genereras http-huvudet inte längre från svar som anger följande direktiv: `<%@ OutputCache Location="ServerAndClient" %>` Det innebär att SetOmitVaryStar metoden inte längre behövs för att utelämna `Vary:` huvudet. I program som anger "ServerAndClient" för `Location` attributet kan sidorna cachelagras i webbläsaren utan att du behöver anropa SetOmitVaryStar.	Om sidor i programmet måste generera `Vary:`anropar du AppendHeader metoden enligt följande exempel: `System.Web.HttpResponse.AppendHeader("Vary","");` Du kan också ändra värdet för cachelagringsattributet `Location` för utdata till "Server".
Sidparsning	Sidparsern för ASP.NET webbsidor (.aspx filer) och användarkontroller (.ascx-filer) är striktare i ASP.NET 4 än i tidigare versioner av ASP.NET och flaggar mer markering som ogiltig än i tidigare versioner.	Granska felmeddelanden som skapas när en sida körs och åtgärda fel som beror på ogiltig markering.
Passport-typer	Passport-supporten som är inbyggd i ASP.NET 2.0 är föråldrad och stöds inte på grund av ändringar i Passport (nu Live ID SDK). Därför markeras de typer som är relaterade till Passport i System.Web.Security nu med attributet `ObsoleteAttribute` .	Ändra all kod som använder Passport-typer i System.Web.Security namnområdet (till exempel PassportIdentity) för att använda Windows Live ID SDK.
PathInfo-information i egenskapen FilePath	ASP.NET 4 innehåller `PathInfo` inte längre värdet i returvärdena från egenskaper som FilePath, AppRelativeCurrentExecutionFilePathoch CurrentExecutionFilePath. `PathInfo` I stället är informationen tillgänglig i PathInfo. Tänk dig till exempel följande URL-fragment: `/testapp/Action.mvc/SomeAction` I tidigare versioner av ASP.NET HttpRequest har egenskaperna följande värden: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (tom) I ASP.NET 4 HttpRequest har egenskaperna i stället följande värden: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Granska koden för platser där du förlitar dig på egenskaperna för HttpRequest klassen för att returnera sökvägsinformation. Ändra koden så att den återspeglar ändringarna i hur sökvägsinformation returneras.
Validering av begäran	För att förbättra valideringen av begäran anropas valideringen av ASP.NET begäran tidigare under begärandelivscykeln. Därför körs validering av begäranden för begäranden som inte gäller .aspx filer, till exempel för webbtjänstanrop och för anpassade hanterare. Valideringen av begäran är också aktiv när anpassade HTTP-moduler körs i pipelinen för bearbetning av begäranden. Som ett resultat av den här ändringen kan begäranden om andra resurser än .aspx filer utlösa valideringsfel för begäranden. Anpassad kod som körs i pipelinen för begäran (till exempel anpassade HTTP-moduler) kan också utlösa valideringsfel för begäran.	Om det behövs kan du återgå till det gamla beteendet att bara ha .aspx sidor som utlöser validering av begäran med hjälp av följande inställning i webbkonfigurationsfilen: `<httpRuntime requestValidationMode="2.0" />` Varning! Om du återgår till det gamla beteendet kontrollerar du att all kod i befintliga hanterare, moduler och annan anpassad kod utför kontroller för potentiellt osäkra HTTP-indata som kan vara XSS-attackvektorer.
Routning	Om du skapar en filsystemwebbplats i Visual Studio 2010 och webbplatsen finns i en mapp som innehåller en punkt (.) i mappnamnet fungerar inte URL-routning på ett tillförlitligt sätt. Ett HTTP 404-fel returneras från vissa virtuella sökvägar. Detta beror på att Visual Studio 2010 startar Visual Studio Development Server med en felaktig sökväg för den virtuella rotkatalogen.	* På sidan Egenskaper för den filbaserade webbplatsen ändrar du attributet Virtuell sökväg till "/". -eller- * Skapa ett webbprogramprojekt i stället för ett webbplatsprojekt. Webbprogramprojekt har inte det här problemet och URL-routning fungerar även om projektmappen har en punkt i namnet. -eller- * Skapa en HTTP-baserad webbplats som finns i IIS. IIS-värdbaserade webbplatser kan ha punkter i den virtuella sökvägen samt i projektfilmappen.
SharePoint-webbplatser	Om du försöker köra en ASP.NET 4-webbplats som distribueras som underordnad en SharePoint-webbplats som innehåller en anpassad partiell förtroendenivå med namnet `WSS_Minimal`visas följande fel: `Could not find permission set named 'ASP.Net'.`	För närvarande är inga versioner av SharePoint kompatibla med ASP.NET. Därför bör du inte försöka köra en ASP.NET 4-webbplats som underordnad en SharePoint-webbplats.
XHTML 1.1-standarder	Om du vill aktivera XHTML 1.1-efterlevnad för nya webbplatser genererar ASP.NET-kontrollerna i .NET Framework 4 XHTML 1.1-kompatibel HTML. Den här återgivningen aktiveras med hjälp av följande alternativ i filen Web.config i elementet `<system.Web>` : `<pages controlRenderingCompatibilityVersion="4.0"/>` Det här alternativet anges som standard till 4.0. Webbprojekt som uppgraderas från Visual Studio 2008 har inställningen 3.5 aktiverad för kompatibilitet.	Inga.

Kärna

Allmänna funktioner

Funktion	Skillnader från 3,5 SP1	Rekommenderade ändringar
Cardspace	Windows CardSpace ingår inte längre i .NET Framework. den tillhandahålls separat.	Ladda ned Windows CardSpace från Microsoft Download Center.
Konfigurationsfiler	Korrigeringar har gjorts i hur .NET Framework kommer åt programkonfigurationsfiler.	Om programkonfigurationsfilen heter application-name.config byter du namn på den till application-name.exe.config. Byt till exempel namn på MyApp.config till MyApp.exe.config.
C#-kodkompilerare	Klasserna `Compiler`, `CompilerError`och `ErrorLevel` som fanns i Microsoft.CSharp namnområdet är inte längre tillgängliga och deras sammansättning (cscompmgd.dll) ingår inte längre i .NET Framework.	CodeDomProvider Använd klassen och andra klasser i System.CodeDom.Compiler namnområdet. Mer information finns i Använda CodeDOM.
Värd ( ohanterat API)	För att förbättra värdfunktionerna har vissa värdaktiverings-API:er blivit inaktuella. Med körningsfunktionerna sida vid sida kan ett program läsa in och starta flera versioner av .NET Framework i samma process. Du kan till exempel köra program som läser in tillägg (eller komponenter) som baseras på .NET Framework 2.0 SP1 och tillägg som baseras på .NET Framework 4 i samma process. Äldre komponenter fortsätter att använda den äldre .NET Framework-versionen och nya komponenter använder den nya .NET Framework-versionen.	Använd de konfigurationer som beskrivs i Körning sida vid sida i processen.
Ny säkerhetsmodell	Principen för kodåtkomstsäkerhet (CAS) har inaktiverats och ersatts med en förenklad modell, enligt beskrivningen i Säkerhetsändringar i .NET Framework 4.	Ändringar kan krävas om du är beroende av CAS i dina program. Mer information finns i Kompatibilitet och migrering för kodåtkomstsäkerhetsprinciper.

Datum och tid

Namnområde: System

Sammansättning: mscorlib (i mscorlib.dll)

Funktion	Skillnader från 3,5 SP1	Rekommenderade ändringar
Sommartid	För att vara konsekvent med systemklockan använder tidsegenskaper (till exempel Local och Now) nu operativsystemregler i stället för andra .NET Framework-data för sommartidsåtgärder.	Inga.
Formateringssträngar	För att stödja kulturkänslig formatering TimeSpan innehåller strukturen nya överlagringar av `ToString`metoderna , `Parse`och `TryParse` utöver nya `ParseExact` metoder och `TryParseExact` metoder.	Inga.

Globalisering

En lista över nya neutrala och specifika kulturer finns i Nyheter i globalisering och lokalisering.

Namnområde: System.Globalization

Sammansättning: mscorlib (i mscorlib.dll)

Funktion	Skillnader från 3,5 SP1	Rekommenderade ändringar
Kulturnamn	Följande namnändringar påverkar de tyska, divehi- och afrikanska kulturerna: * CurrencyEnglishName: Valutanamnet för den tyska kulturen (Schweiz) (de-CH) har ändrats från "sFr" till "Fr". * LongDatePattern: Det långa datummönstret för Divehi-kulturen (Maldiverna) (dv-MV) har ändrats från "dd/MMMM/åååå" till "dd/MM/åååå". * PMDesignator: P.M. designator av Afrikaans (Sydafrika) (af-ZA) kultur har ändrats från "nm" till "PM".	Observera ändringar av kulturnamn.
LCID-parameter	För att vara konsekvent med förväntat beteende i inställningarna för automationsserver skickar CLR inte längre den aktuella kulturen för parametern `LCID` till ohanterade COM-baserade program. I stället passerar det 1033 (en-us) för kulturen.	Inga ändringar krävs förutom för inbyggda program som kräver en angiven kultur.
Föråldrade kulturtyper	Kulturtyperna CultureTypes och CultureTypes är nu föråldrade. För bakåtkompatibilitet CultureTypes returnerar nu neutrala och specifika kulturer som ingick i det tidigare .NET Framework och CultureTypes returnerar nu en tom lista.	Använd andra värden för CultureTypes uppräkningen.
Hämta kultur	Från och med Windows 7 hämtar .NET Framework 4 kulturinformation från operativsystemet i stället för att lagra själva data. Dessutom synkroniseras .NET Framework med Windows för sortering och höljedata.	Inga.
Unicode 5.1-standarder	.NET Framework stöder nu alla Unicode 5.1-tecken – ett tillägg på cirka 1 400 tecken. De ytterligare tecknen inkluderar nya symboler, pilar, diakritiska tecken, skiljetecken, matematiska symboler, CJK-linjer och ideografier, ytterligare numeriska tecken i Malayalam och Telugu och olika tecken i Myanmar, latin, arabiska, grekiska, mongoliska och kyrilliska tecken. Följande nya skript stöds med Unicode 5.1: Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu och Malayalam samt Cham.	Inga.

Undantag

Namnområden: System, System.Runtime.ExceptionServices

Sammansättning: mscorlib (i mscorlib.dll)

Funktion	Skillnader från 3,5 SP1	Rekommenderade ändringar
Undantag för skadat processtillstånd	CLR levererar inte längre undantag för skadat processtillstånd till undantagshanterare i hanterad kod.	Dessa undantag indikerar att tillståndet för en process har skadats. Vi rekommenderar inte att du kör programmet i det här tillståndet. Mer information finns i HandleProcessCorruptedStateExceptionsAttribute och posten Hantera skadade tillståndsfel i MSDN-tidningen.
Undantag för körningsmotor	ExecutionEngineException är nu föråldrad eftersom ett undantag som kan fångas tillåter att en instabil process fortsätter att köras. Den här ändringen förbättrar förutsägbarheten och tillförlitligheten i körningen.	Använd en InvalidOperationException för att signalera villkoret.

Reflektion

Namnområde: System.Reflection

Sammansättning: mscorlib (i mscorlib.dll)

Funktion	Skillnader från 3,5 SP1	Rekommenderade ändringar
Sammansättningshashalgoritmer	Egenskapen HashAlgorithm returnerar AssemblyHashAlgorithmnu , eftersom körningen inte känner till hash-algoritmen för den refererade sammansättningen när sammansättningen inte läses in. (Detta avser användning av egenskapen på en refererad sammansättning, till exempel den som returneras av GetReferencedAssemblies metoden.)	Inga.
Monteringsinläsning	För att förhindra redundant inläsning av sammansättningar och för att spara virtuellt adressutrymme läser CLR nu in sammansättningar med endast funktionen Win32 `MapViewOfFile` . Den anropar `LoadLibrary` inte längre funktionen. Den här ändringen påverkar diagnostikprogram på följande sätt: * A ProcessModuleCollection innehåller inte längre några moduler från ett klassbibliotek (.dll fil), som hämtas från ett anrop till `Process.GetCurrentProcess().Modules`. * Win32-program som använder `EnumProcessModules` funktionen ser inte alla hanterade moduler i listan.	Inga.
Deklareringstyp	Egenskapen DeclaringType returnerar nu null korrekt när typen inte har någon deklareringstyp.	Inga.
Delegater	Ett ombud genererar nu ett ArgumentNullException i stället för ett NullReferenceException när ett null-värde skickas till ombudets konstruktor.	Se till att all undantagshantering fångar .ArgumentNullException
Platsändring för global sammansättningscache	För .NET Framework 4-sammansättningar har den globala sammansättningscachen flyttats från Windows-katalogen (%WINDIR%) till Microsoft.Net underkatalog (%WINDIR%\Microsoft.Net). Sammansättningar från tidigare versioner finns kvar i den äldre katalogen. Den ohanterade ASM_CACHE_FLAGS uppräkning innehåller den nya `ASM_CACHE_ROOT_EX` flaggan. Den här flaggan hämtar cacheplatsen för .NET Framework 4-sammansättningar, som kan hämtas av funktionen GetCachePath .	Ingen, förutsatt att program inte använder explicita sökvägar till sammansättningar, vilket inte är en rekommenderad metod.
Verktyg för global sammansättningscache	Gacutil.exe (Global Assembly Cache Tool) stöder inte längre visningsprogrammet för plugin-gränssnittet.	Inga.

Samverkan

Namnområde: System.Runtime.InteropServices

Sammansättning: mscorlib (i mscorlib.dll)

Funktion	Skillnader från 3,5 SP1	Rekommenderade ändringar
Buffertlängd (ohanterat API)	För att spara minne har funktionerna för parametern `pBufferLengthOffset` för metoden ICorProfilerInfo2::GetStringLayout ändrats för att matcha parametern `pStringLengthOffset` . Båda parametrarna pekar nu på förskjutningsplatsen för strängens längd. Buffertlängden har tagits bort från representationen av strängklassen.	Ta bort eventuella beroenden av buffertlängden.
JIT-felsökning	För att förenkla registreringen för jit-felsökning (just-in-time) använder .NET Framework-felsökaren nu endast AeDebug-registernyckeln, som styr JIT-felsökningsbeteendet för intern kod. Den här ändringen resulterar i följande: * Du kan inte längre registrera två olika felsökningsprogram för hanterad och intern kod. * Du kan inte längre starta felsökningsprogrammet automatiskt för en icke-interaktiv process, men du kan be användaren om en interaktiv process. * Du meddelas inte längre när felsökningsprogrammet inte startar eller när det inte finns något registrerat felsökningsprogram som ska startas. * Principer för automatisk start som är beroende av programmets interaktivitet stöds inte längre.	Justera felsökningsåtgärder efter behov.
Plattformsanrop	För att förbättra prestanda i samverkan med ohanterad kod gör felaktiga anropskonventioner i en plattform nu att programmet misslyckas. I tidigare versioner löste marshallinglagret dessa fel uppåt i stacken.	När du felsöker dina program i Microsoft Visual Studio får du en avisering om dessa fel så att du kan korrigera dem. Om du har binärfiler som inte kan uppdateras kan du ta med <NetFx40_PInvokeStackResilience-elementet> i programmets konfigurationsfil så att anropsfel kan lösas upp i stacken som i tidigare versioner. Detta kan dock påverka programmets prestanda.
Borttagna gränssnitt (ohanterat API)	För att undvika utvecklarförvirring togs följande gränssnitt bort eftersom de inte gav några användbara körningsscenarier och CLR inte angav eller accepterade några implementeringar: * INativeImageINativeImageDependency * INativeImageInstallInfo * INativeImageEvaluate * INativeImageConverter * ICorModule * IMetaDataConverter	Inga.

Data

I det här avsnittet beskrivs migreringsproblem för användning av datauppsättningar och SQL-klienter, Entity Framework, LINQ till SQL och WCF-dataservrar (kallades tidigare ADO.NET Data Services).