Migratieproblemen met .NET Framework 4

Artikel
03/30/2023

In dit artikel worden migratieproblemen beschreven tussen .NET Framework versie 3.5 Service Pack 1 en .NET Framework versie 4, waaronder fixes, wijzigingen voor naleving en beveiliging van standaarden en wijzigingen op basis van feedback van klanten. Voor de meeste van deze wijzigingen zijn geen programmeerwijzigingen in uw toepassingen vereist. Zie de kolom Aanbevolen wijzigingen van de tabel voor degenen die mogelijk wijzigingen omvatten. Belangrijke wijzigingen worden onderverdeeld per gebied, bijvoorbeeld ASP.NET en Windows Presentation Foundation (WPF).

Zie migratiehandleiding voor .NET Framework 4 voor een overzicht op een hoger niveau van de problemen in dit artikel.

Zie Wat is er nieuw in .NET Framework 4 voor meer informatie over nieuwe functies.

ASP.NET en web

Naamruimten: System.Web, System.Web.Mobile, System.Web.Security System.Web.UI.WebControls

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

Functie	Verschillen van 3.5 SP1	Aanbevolen wijzigingen
Browserdefinitiebestanden	De browserdefinitiebestanden zijn bijgewerkt met informatie over nieuwe en bijgewerkte browsers en apparaten. Oudere browsers en apparaten zoals Netscape Navigator zijn verwijderd en nieuwere browsers en apparaten zoals Google Chrome en Apple i Telefoon zijn toegevoegd. Als uw toepassing aangepaste browserdefinities bevat die overnemen van een van de browserdefinities die zijn verwijderd, ziet u een fout. Het HttpBrowserCapabilities object (dat wordt weergegeven door de eigenschap van `Request.Browse` de pagina) wordt aangestuurd door de definitiebestanden van de browser. Daarom is de informatie die wordt geretourneerd door toegang te krijgen tot een eigenschap van dit object in ASP.NET 4 mogelijk anders dan de informatie die is geretourneerd in een eerdere versie van ASP.NET.	Als uw toepassing afhankelijk is van de oude browserdefinitiebestanden, kunt u deze kopiëren vanuit de volgende map: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Kopieer de bestanden naar de bijbehorende map \CONFIG\Browsers voor ASP.NET 4. Nadat u de bestanden hebt gekopieerd, voert u het Aspnet_regbrowsers.exe opdrachtregelprogramma uit. Zie de https://www.asp.net/mobile website voor meer informatie.
Onderliggende toepassingen die worden uitgevoerd onder gemengde versies van ASP.NET	ASP.NET 4 toepassingen die zijn geconfigureerd als onderliggende toepassingen waarop eerdere versies van ASP.NET worden uitgevoerd, kunnen niet worden gestart vanwege configuratie- of compilatiefouten. De specifieke fout die optreedt, is afhankelijk van of de toepassing wordt uitgevoerd onder IIS 6.0 of onder IIS 7 of IIS 7.5.	U kunt wijzigingen aanbrengen in de configuratiebestanden van de betrokken toepassingen, zodat het configuratiesysteem de ASP.NET 4-toepassing correct herkent. Zie de sectie 'ASP.NET 4 onderliggende toepassingen kunnen niet worden gestart wanneer onder ASP.NET 2.0 of ASP.NET 3.5-toepassingen' in het ASP.NET document onder ASP.NET 2.0 of ASP.NET 4 belangrijke wijzigingen op de website van ASP.NET wordt weergegeven.
Wijzigingen in client-id	Met de nieuwe `clientIDMode` instelling in ASP.NET 4 kunt u opgeven hoe ASP.NET het `id` kenmerk voor HTML-elementen genereert. In eerdere versies van ASP.NET was het standaardgedrag gelijk aan de `AutoID` instelling van `clientIDMode`. De standaardinstelling is nu `Predictable`. Zie ASP.NET Webserverbesturingsidentificatie voor meer informatie.	Als u Visual Studio gebruikt om uw toepassing te upgraden vanaf ASP.NET 2.0 of ASP.NET 3.5, wordt er automatisch een instelling toegevoegd aan het Web.config-bestand dat het gedrag van eerdere versies van .NET Framework behoudt. Als u echter een toepassing bijwerkt door de groep van toepassingen in IIS te wijzigen in .NET Framework 4, ASP.NET de nieuwe modus standaard gebruikt. Als u de nieuwe client-id-modus wilt uitschakelen, voegt u de volgende instelling toe aan het web.config-bestand: `<pages clientIDMode="AutoID" />`
Beveiliging van codetoegang (CAS)	ASP.NET 2.0 NET-functies die zijn toegevoegd in ASP.NET 3.5, gebruiken het CAS-model (.NET Framework 1.1 en .NET Framework 2.0 Code Access Security). De uitvoering van CAS in ASP.NET 4 is echter aanzienlijk herzien. Als gevolg hiervan kunnen gedeeltelijke vertrouwensrelaties ASP.NET toepassingen die afhankelijk zijn van vertrouwde code die wordt uitgevoerd in de globale assemblycache, mislukken met verschillende beveiligingsuitzondering. Gedeeltelijke vertrouwenstoepassingen die afhankelijk zijn van uitgebreide wijzigingen in het CAS-beleid van de machine kunnen ook mislukken en beveiligingsonderzonderingen genereren.	U kunt gedeeltelijke vertrouwensrelatie ASP.NET 4 toepassingen herstellen naar het gedrag van ASP.NET 1.1 en 2.0 met behulp van het nieuwe `legacyCasModel` kenmerk in het `trust` configuratie-element, zoals wordt weergegeven in het volgende voorbeeld: `<trust level= "Medium" legacyCasModel="true" />` Belangrijk: Terugkeren naar het oudere CAS-model kan een verminderde beveiliging vertegenwoordigen. Zie codetoegangsbeveiliging in ASP.NET 4 toepassingen voor meer informatie over het nieuwe ASP.NET 4-codetoegangsbeveiligingsmodel.
Configuratiebestanden	De hoofdconfiguratiebestanden (het bestand machine.config en het hoofdbestand Web.config) voor .NET Framework en ASP.NET 4 zijn bijgewerkt met de meeste standaardconfiguratiegegevens die zijn gevonden in de web.config-bestanden van de toepassing in ASP.NET 3.5. Vanwege de complexiteit van de beheerde IIS 7- en IIS 7.5-configuratiesystemen kan het uitvoeren van ASP.NET 3.5-toepassingen onder ASP.NET 4 en iis 7 en IIS 7.5 leiden tot ASP.NET fouten of IIS-fouten.	Werk ASP.NET 3.5-toepassingen bij naar ASP.NET 4 met behulp van de hulpprogramma's voor projectupgrades in Visual Studio. Visual Studio 2010 wijzigt automatisch het web.config-bestand van de ASP.NET 3.5-toepassing met de juiste instellingen voor ASP.NET 4. U kunt echter ASP.NET 3.5-toepassingen uitvoeren met .NET Framework 4 zonder hercompilatie. In dat geval moet u het web.config-bestand van de toepassing mogelijk handmatig wijzigen voordat u de toepassing uitvoert onder .NET Framework 4 en onder IIS 7 of IIS 7.5. De specifieke wijziging die u moet aanbrengen, is afhankelijk van de combinatie van software waarmee u werkt, inclusief Service Pack (SP)-releases. Zie de sectie Configuratiefouten met betrekking tot nieuwe ASP.NET 4 hoofdconfiguratie in het document ASP.NET 4 Belangrijke wijzigingen op de ASP.NET website voor informatie over de mogelijke softwarecombinaties die worden beïnvloed door deze wijziging en hoe u problemen met specifieke combinaties kunt oplossen.
Rendering van besturingselementen	In eerdere versies van ASP.NET hebben sommige besturingselementen markeringen gegenereerd die u niet kunt uitschakelen. Dit type markeringen wordt standaard niet meer gegenereerd in ASP.NET 4. De renderingwijzigingen zijn van invloed op de volgende besturingselementen: * De `Image` en `ImageButton` besturingselementen geven geen `border="0"` kenmerk meer weer. * De `BaseValidator` klasse- en validatiebesturingselementen die eraan zijn afgeleid, geven standaard geen rode tekst meer weer. * Het `HtmlForm` besturingselement geeft geen kenmerk weer `name` . * Het `Table` besturingselement geeft geen `border="0"` kenmerk meer weer. Besturingselementen die niet zijn ontworpen voor gebruikersinvoer (bijvoorbeeld het `Label` besturingselement) geven het `disabled="disabled"` kenmerk niet meer weer als de `Enabled` eigenschap is ingesteld `false` op (of als ze deze instelling overnemen van een containerbesturingselement).	Als u Visual Studio gebruikt om uw toepassing bij te werken vanaf ASP.NET 2.0 of ASP.NET 3.5, wordt er automatisch een instelling toegevoegd aan het Web.config-bestand dat verouderde rendering behoudt. Als u echter een toepassing bijwerkt door de groep van toepassingen in IIS te wijzigen in .NET Framework 4, gebruikt ASP.NET standaard de nieuwe renderingmodus. Als u de nieuwe renderingmodus wilt uitschakelen, voegt u de volgende instelling toe aan het web.config-bestand: `<pages controlRenderingCompatibilityVersion="3.5" />`
Gebeurtenis-handlers in standaarddocumenten	ASP.NET 4 geeft de kenmerkwaarde van `action` het HTML-element `form` weer als een lege tekenreeks wanneer een aanvraag wordt ingediend bij een extensieloze URL waaraan een standaarddocument is toegewezen. In eerdere releases van ASP.NET zou een aanvraag die `http://contoso.com` moet resulteren in een aanvraag voor Default.aspx. In dat document wordt de openingstag `form` weergegeven zoals in het volgende voorbeeld: `<form action="Default.aspx" />` In ASP.NET 4 resulteert een aanvraag ook `http://contoso.com` in een aanvraag voor Default.aspx, maar ASP.NET nu de HTML-openingstag `form` weer zoals in het volgende voorbeeld: `<form action="" />` Wanneer het `action` kenmerk een lege tekenreeks is, maakt het IIS-object `DefaultDocumentModule` een onderliggende aanvraag voor Default.aspx. Onder de meeste omstandigheden is deze onderliggende aanvraag transparant voor toepassingscode en wordt de Default.aspx pagina normaal uitgevoerd. Een mogelijke interactie tussen beheerde code en IIS 7 of IIS 7.5 Geïntegreerde modus kan er echter toe leiden dat beheerde .aspx pagina's niet meer goed werken tijdens de onderliggende aanvraag. Als de volgende voorwaarden optreden, leidt de onderliggende aanvraag naar een standaarddocument .aspx document tot een fout of onverwacht gedrag: * Er wordt een .aspx pagina naar de browser verzonden met het kenmerk van `action` het `form` element ingesteld op ''. * Het formulier wordt teruggezet naar ASP.NET. * Een beheerde HTTP-module leest een deel van de hoofdtekst van de entiteit, zoals `Request.Form` of `Request.Params`. Hierdoor wordt de hoofdtekst van de POST-aanvraag in het beheerde geheugen gelezen. Hierdoor is de hoofdtekst van de entiteit niet meer beschikbaar voor systeemeigen codemodules die worden uitgevoerd in de geïntegreerde IIS 7- of IIS 7.5-modus. * Het IIS-object `DefaultDocumentModule` wordt uiteindelijk uitgevoerd en maakt een onderliggende aanvraag voor het Default.aspx document. Omdat de hoofdtekst van de entiteit echter al is gelezen door een stukje beheerde code, is er geen entiteitstekst beschikbaar om naar de onderliggende aanvraag te verzenden. * Wanneer de HTTP-pijplijn wordt uitgevoerd voor de onderliggende aanvraag, wordt de handler voor .aspx bestanden uitgevoerd tijdens de handler-execute-fase. Omdat er geen entiteitstekst is, zijn er geen formuliervariabelen en geen weergavestatus. Er is dus geen informatie beschikbaar voor de .aspx pagina-handler om te bepalen welke gebeurtenis (indien aanwezig) moet worden gegenereerd. Als gevolg hiervan worden geen van de postback-gebeurtenis-handlers voor de betrokken .aspx pagina uitgevoerd.	Zie 'Gebeurtenishandlers worden mogelijk niet gegenereerd in een standaarddocument in IIS 7 of IIS 7.5 Geïntegreerde modus' in het document ASP.NET 4 Belangrijke wijzigingen op de ASP.NET website voor informatie over manieren om problemen te omzeilen die kunnen optreden als gevolg van deze wijziging.
Hash-algoritme	ASP.NET maakt gebruik van zowel versleutelings- als hash-algoritmen om gegevens zoals formulierverificatiecookies te beveiligen en de status weer te geven. Standaard gebruikt ASP.NET 4 het HMACSHA256 algoritme voor hashbewerkingen op cookies en de status weergeven. Eerdere versies van ASP.NET het oudere HMACSHA1 algoritme gebruikt.	Als u toepassingen uitvoert die ASP.NET 2.0 en ASP.NET 4 combineren, waarbij gegevens zoals formulierverificatiecookies moeten werken in .NET Framework-versies, configureert u een ASP.NET 4-webtoepassing om het oudere HMACSHA1 algoritme te gebruiken door de volgende instelling toe te voegen in het web.config-bestand: `<machineKey validation="SHA1" />`
Besturingselementen hosten in Internet Explorer	U kunt geen Besturingselementen van Windows Forms meer hosten in Internet Explorer, omdat er betere oplossingen zijn voor het hosten van besturingselementen op internet. Daarom zijn de IEHost.dll en IEExec.exe assembly's verwijderd uit .NET Framework.	U kunt de volgende technologieën gebruiken voor het ontwikkelen van aangepaste besturingselementen in webtoepassingen: * U kunt een Silverlight-toepassing maken en configureren voor uitvoering buiten de browser. Zie Ondersteuning voor niet-browser voor meer informatie. * U kunt een XAML-browsertoepassing (XBAP) bouwen om te profiteren van WPF-mogelijkheden (vereist .NET Framework op clientcomputers). Zie overzicht van WPF XAML-browsertoepassingen voor meer informatie.
HtmlEncode- en UrlEncode-methoden	De `HtmlEncode` en `UrlEncode` methoden van de HttpUtility en HttpServerUtility klassen zijn bijgewerkt om het enkele aanhalingsteken (') als volgt te coderen: * De `HtmlEncode` methode codeert exemplaren van het enkele aanhalingsteken als `'` * De `UrlEncode` methode codeert exemplaren van het enkele aanhalingsteken als `%27`	Controleer uw code op plaatsen waar u de `HtmlEncode` en `UrlEncode` methoden gebruikt en zorg ervoor dat de wijziging in codering niet resulteert in een wijziging die van invloed is op uw toepassing.
HttpException-fouten in ASP.NET 2.0-toepassingen	Nadat ASP.NET 4 is ingeschakeld op IIS 6, kunnen ASP.NET 2.0-toepassingen die worden uitgevoerd op IIS 6 (in Windows Server 2003 of Windows Server 2003 R2) fouten genereren, zoals: `System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.`	* Als ASP.NET 4 niet is vereist om de website uit te voeren, moet u de site opnieuw toewijzen om in plaats daarvan ASP.NET 2.0 te gebruiken. – of – * Als ASP.NET 4 is vereist om de website uit te voeren, verplaatst u onderliggende ASP.NET 2.0 virtuele mappen naar een andere website die is toegewezen aan ASP.NET 2.0. – of – * Schakel extensieloze URL's uit. Zie 'ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd' (HttpException-fouten genereren die verwijzen naar eurl.axd) in het document ASP.NET 4 Belangrijke wijzigingen op de website van ASP.NET.
Lidmaatschapstypen	Sommige typen (bijvoorbeeld MembershipProvider) die worden gebruikt in ASP.NET lidmaatschap, zijn verplaatst van System.Web.dll naar de System.Web.ApplicationServices.dll assembly. De typen zijn verplaatst om afhankelijkheden van architectuurlagen tussen typen in de client en in uitgebreide .NET Framework-SKU's op te lossen.	Klassebibliotheken die zijn bijgewerkt vanuit eerdere versies van ASP.NET en die gebruikmaken van lidmaatschapstypen die zijn verplaatst, kunnen niet worden gecompileerd wanneer ze worden gebruikt in een ASP.NET 4-project. Zo ja, voeg dan een verwijzing toe aan het klassebibliotheekproject aan System.Web.ApplicationServices.dll.
Wijzigingen in menubesturing	Wijzigingen in het Menu besturingselementresultaat in het volgende gedrag: * Als MenuRenderingMode deze optie is ingesteld op `List`, of MenuRenderingMode als deze is ingesteld `Default4.0` op of ControlRenderingCompatibilityVersion hoger, heeft de PopOutImageUrl eigenschap geen effect. * Als het pad dat is ingesteld in de StaticPopOutImageUrl en DynamicPopOutImageUrl eigenschappen een backslash (\) bevat, worden de afbeeldingen niet weergegeven. (In eerdere versies van ASP.NET kan het pad een backslash bevatten.)	* In plaats van de PopOutImageUrl eigenschap voor afzonderlijke menu-items in te stellen, stelt u het StaticPopOutImageUrl of DynamicPopOutImageUrl het bovenliggende Menu besturingselement in. – of – Instellen op `Table`, of instellen MenuRenderingMode MenuRenderingMode op `Default` en instellen op `3.5`ControlRenderingCompatibilityVersion . Deze instellingen zorgen ervoor dat het Menu besturingselement de indeling op basis van html-tabellen gebruikt die in eerdere versies van ASP.NET wordt gebruikt. * Als het pad in de StaticPopOutImageUrl of DynamicPopOutImageUrl eigenschap een backslash (\) bevat, vervangt u een slash (/).
Mobiele assembly in web.config-bestand	In eerdere versies van ASP.NET is een verwijzing naar de System.Web.Mobile.dll assembly opgenomen in het hoofdbestand Web.config in de `assemblies` sectie onder/`system.webcompilation` . Ter verbetering van de prestaties is de verwijzing naar deze assembly verwijderd. Opmerking: de System.Web.Mobile.dll assembly en de ASP.NET mobiele besturingselementen zijn opgenomen in ASP.NET 4, maar ze zijn afgeschaft.	Als u typen uit deze assembly wilt gebruiken, voegt u een verwijzing naar de assembly toe in het hoofdbestand Web.config of in een web.config-bestand van de toepassing.
Uitvoercache	In ASP.NET 1.0 heeft een fout in de cache pagina's veroorzaakt die zijn opgegeven `Location="ServerAndClient"` als een instelling voor uitvoercache om een `Vary:` HTTP-header in het antwoord te verzenden. Dit heeft tot gevolg dat clientbrowsers de pagina nooit lokaal in de cache moeten opslaan. In ASP.NET 1.1 is de SetOmitVaryStar methode toegevoegd, die kan worden aangeroepen om de `Vary:` header te onderdrukken. Foutrapporten stellen echter voor dat ontwikkelaars zich niet bewust zijn van het bestaande `SetOmitVaryStar` gedrag. In ASP.NET 4 wordt de `Vary:` HTTP-header niet meer verzonden uit antwoorden die de volgende instructie opgeven: `<%@ OutputCache Location="ServerAndClient" %>` Als gevolg hiervan is de SetOmitVaryStar methode niet meer nodig om de `Vary:` header te onderdrukken. In toepassingen die 'ServerAndClient' voor het `Location` kenmerk opgeven, kunnen pagina's in de browser worden opgeslagen zonder dat u dit hoeft aan te roepen SetOmitVaryStar.	Als pagina's in de toepassing moeten worden verzonden `Vary:`, roept u de AppendHeader methode aan, zoals wordt weergegeven in het volgende voorbeeld: `System.Web.HttpResponse.AppendHeader("Vary","");` U kunt ook de waarde van het kenmerk uitvoercaching `Location` wijzigen in 'Server'.
Paginaparsering	De paginaparser voor ASP.NET webpagina's (.aspx bestanden) en gebruikersbesturingselementen (.ascx-bestanden) is strenger in ASP.NET 4 dan in eerdere versies van ASP.NET en markeert meer markeringen als ongeldig dan in eerdere versies.	Bekijk foutberichten die worden geproduceerd wanneer een pagina wordt uitgevoerd en los fouten op die het gevolg zijn van ongeldige markeringen.
Paspoorttypen	De Passport-ondersteuning die is ingebouwd in ASP.NET 2.0 is verouderd en wordt niet ondersteund vanwege wijzigingen in Passport (nu Live ID SDK). Als gevolg hiervan worden de typen die zijn gerelateerd aan Passport nu System.Web.Security gemarkeerd met het `ObsoleteAttribute` kenmerk.	Wijzig alle code die gebruikmaakt van Passport-typen in de System.Web.Security naamruimte (bijvoorbeeld PassportIdentity) om de Windows Live ID SDK te gebruiken.
PathInfo-informatie in de eigenschap FilePath	ASP.NET 4 bevat niet langer de `PathInfo` waarde in de retourwaarden van eigenschappen zoals FilePath, AppRelativeCurrentExecutionFilePathen CurrentExecutionFilePath. In plaats daarvan is de `PathInfo` informatie beschikbaar in PathInfo. Stel bijvoorbeeld het volgende URL-fragment voor: `/testapp/Action.mvc/SomeAction` In eerdere versies van ASP.NET HttpRequest hebben eigenschappen de volgende waarden: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (leeg) In ASP.NET 4 HttpRequest hebben eigenschappen in plaats daarvan de volgende waarden: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Bekijk uw code voor plaatsen waar u afhankelijk bent van eigenschappen van de HttpRequest klasse om padgegevens te retourneren. Wijzig de code zodat deze overeenkomt met de wijzigingen in de wijze waarop padgegevens worden geretourneerd.
Aanvraagvalidatie	Ter verbetering van de aanvraagvalidatie wordt de ASP.NET aanvraagvalidatie eerder in de levenscyclus van de aanvraag aangeroepen. Als gevolg hiervan wordt aanvraagvalidatie uitgevoerd voor aanvragen die niet voor .aspx bestanden zijn, zoals voor webservice-aanroepen en voor aangepaste handlers. Aanvraagvalidatie is ook actief wanneer aangepaste HTTP-modules worden uitgevoerd in de pijplijn voor aanvraagverwerking. Als gevolg van deze wijziging kunnen aanvragen voor andere resources dan .aspx bestanden validatiefouten genereren. Aangepaste code die wordt uitgevoerd in de aanvraagpijplijn (bijvoorbeeld aangepaste HTTP-modules) kan ook validatiefouten voor aanvragen veroorzaken.	Indien nodig kunt u terugkeren naar het oude gedrag van alleen .aspx pagina's die aanvraagvalidatie activeren met behulp van de volgende instelling in het webconfiguratiebestand: `<httpRuntime requestValidationMode="2.0" />` Waarschuwing: als u teruggaat naar het oude gedrag, moet u ervoor zorgen dat alle code in bestaande handlers, modules en andere aangepaste code controles uitvoert op mogelijk onveilige HTTP-invoer die XSS-aanvalsvectoren kunnen zijn.
Routering	Als u een bestandssysteemwebsite maakt in Visual Studio 2010 en de website zich in een map bevindt die een punt (.) in de mapnaam bevat, werkt URL-routering niet betrouwbaar. Er wordt een HTTP 404-fout geretourneerd vanuit een aantal virtuele paden. Dit komt doordat Visual Studio 2010 de Visual Studio Development Server start met behulp van een onjuist pad voor de virtuele hoofdmap.	* Wijzig op de pagina Eigenschappen voor de website op basis van bestanden het kenmerk Virtueel pad in '/'. – of – * Maak een webtoepassingsproject in plaats van een websiteproject. Webtoepassingsprojecten hebben dit probleem niet en URL-routering werkt zelfs als de projectmap een punt in de naam heeft. – of – * Maak een HTTP-website die wordt gehost in IIS. IiS-gehoste websites kunnen punten in het virtuele pad en in de projectbestandsmap hebben.
SharePoint-sites	Als u probeert een ASP.NET 4-website uit te voeren die is geïmplementeerd als een onderliggend element van een SharePoint-website met een aangepast gedeeltelijk vertrouwensniveau met de naam `WSS_Minimal`, wordt de volgende fout weergegeven: `Could not find permission set named 'ASP.Net'.`	Momenteel zijn er geen versies van SharePoint compatibel met ASP.NET. Als gevolg hiervan moet u geen ASP.NET 4-website uitvoeren als onderliggend element van een SharePoint-website.
XHTML 1.1-standaarden	Als u XHTML 1.1-naleving wilt inschakelen voor nieuwe websites, worden met de ASP.NET-besturingselementen in .NET Framework 4 XHTML 1.1-compatibele HTML gegenereerd. Deze rendering is ingeschakeld met behulp van de volgende optie in het Web.config-bestand in het `<system.Web>` element: `<pages controlRenderingCompatibilityVersion="4.0"/>` Deze optie is standaard ingesteld op 4.0. Webprojecten die zijn bijgewerkt vanuit Visual Studio 2008, hebben de instelling 3.5 ingeschakeld voor compatibiliteit.	Geen.

Basis

Algemene functies

Functie	Verschillen van 3.5 SP1	Aanbevolen wijzigingen
Cardspace	Windows CardSpace is niet meer opgenomen in .NET Framework; het wordt afzonderlijk verstrekt.	Download Windows CardSpace via het Microsoft Downloadcentrum.
Configuratiebestanden	Er zijn correcties aangebracht in de wijze waarop .NET Framework toegang krijgt tot toepassingsconfiguratiebestanden.	Als uw toepassingsconfiguratiebestand de naam application-name.config heeft, wijzigt u de naam ervan in application-name.exe.config. Wijzig bijvoorbeeld de naam van MyApp.config in MyApp.exe.config.
C#-codecompilator	De `Compiler`, `CompilerError`en `ErrorLevel` klassen in de Microsoft.CSharp naamruimte zijn niet meer beschikbaar en hun assembly (cscompmgd.dll) is niet meer opgenomen in .NET Framework.	Gebruik de CodeDomProvider klasse en andere klassen in de System.CodeDom.Compiler naamruimte. Zie Het codeDOM gebruiken voor meer informatie.
Hosting (niet-beheerde API)	Om de hostingmogelijkheden te verbeteren, zijn sommige api's voor hostingactivering afgeschaft. Met in-proces naast elkaar uitgevoerde functies kan een toepassing meerdere versies van .NET Framework in hetzelfde proces laden en starten. U kunt bijvoorbeeld toepassingen uitvoeren die invoegtoepassingen (of onderdelen) laden die zijn gebaseerd op .NET Framework 2.0 SP1 en invoegtoepassingen die zijn gebaseerd op .NET Framework 4 in hetzelfde proces. Oudere onderdelen blijven de oudere .NET Framework-versie gebruiken en nieuwe onderdelen gebruiken de nieuwe .NET Framework-versie.	Gebruik de configuraties die worden beschreven in de uitvoering naast elkaar.
Nieuw beveiligingsmodel	Het CAS-beleid (Code Access Security) is uitgeschakeld en vervangen door een vereenvoudigd model, zoals beschreven in Beveiligingswijzigingen in .NET Framework 4.	Mogelijk zijn er wijzigingen vereist als u afhankelijk bent van CAS in uw toepassingen. Zie Compatibiliteit en migratie van beveiligingsbeleid voor codetoegang voor meer informatie.

Datum en tijd

Naamruimte: System

Assembly: mscorlib (in mscorlib.dll)

Functie	Verschillen van 3.5 SP1	Aanbevolen wijzigingen
Zomertijd	Om consistent te zijn met de systeemklok, gebruiken tijdeigenschappen (zoals Local en Now) nu besturingssysteemregels in plaats van andere .NET Framework-gegevens voor zomertijdbewerkingen.	Geen.
Tekenreeksen opmaken	Ter ondersteuning van cultuurgevoelige opmaak bevat de TimeSpan structuur nieuwe overbelastingen van de `ToString`, `Parse`en `TryParse` methoden naast nieuwe `ParseExact` en `TryParseExact` methoden.	Geen.

Globalisatie

Zie What's New in Globalization and Localization and Localization(What's New in Globalization and Localization) voor een lijst met nieuwe neutrale en specifieke culturen.

Naamruimte: System.Globalization

Assembly: mscorlib (in mscorlib.dll)

Functie	Verschillen van 3.5 SP1	Aanbevolen wijzigingen
Cultuurnamen	De volgende naamwijzigingen zijn van invloed op de Duitse, Divehi- en Afrikaanse culturen: * CurrencyEnglishName: De valutanaam voor de Duitse cultuur (Zwitserland) (de-CH) is veranderd van "sFr." in "Fr.". * LongDatePattern: Het lange datumpatroon voor de Divehi -cultuur (Dv-MV) is veranderd van "dd/MMMM/jjjj" in "dd/MM/jjjj". * PMDesignator: De P.M. designator van de Afrikaanse (Zuid-Afrika) cultuur (af-ZA) is veranderd van "nm" in "PM".	Let op wijzigingen in de cultuurnaam.
LCID-parameter	Om consistent te zijn met verwacht gedrag in automatiseringsserverinstellingen, geeft de CLR de huidige cultuur voor de `LCID` parameter niet langer door aan onbeheerde COM-toepassingen. In plaats daarvan passeert het 1033 (en-us) voor de cultuur.	Er zijn geen wijzigingen nodig, behalve voor systeemeigen toepassingen waarvoor een opgegeven cultuur is vereist.
Verouderde cultuurtypen	De CultureTypes en CultureTypes cultuurtypen zijn nu verouderd. Voor compatibiliteit met CultureTypes eerdere versies retourneert nu neutrale en specifieke culturen die zijn opgenomen in het vorige .NET Framework en CultureTypes wordt nu een lege lijst geretourneerd.	Gebruik andere waarden van de CultureTypes opsomming.
Cultuur ophalen	Vanaf Windows 7 haalt .NET Framework 4 cultuurgegevens op uit het besturingssysteem in plaats van de gegevens zelf op te slaan. Daarnaast synchroniseert .NET Framework met Windows voor het sorteren en hoofdlettergebruik van gegevens.	Geen.
Unicode 5.1-standaarden	.NET Framework ondersteunt nu alle Unicode 5.1-tekens, een toevoeging van ongeveer 1400 tekens. De extra tekens zijn onder andere nieuwe symbolen, pijlen, diakritische tekens, interpunctie, wiskundige symbolen, CJK-pennenstreken en ideografieën, extra numerieke tekens van Malayalam en Telugu, en verschillende tekens uit Myanmar, Latijns, Arabisch, Grieks, Mongools en Cyrillisch. De volgende nieuwe scripts worden ondersteund met Unicode 5.1: Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu, en Malayalam tekens en Cham.	Geen.

Uitzonderingen

Naamruimten: System, System.Runtime.ExceptionServices

Assembly: mscorlib (in mscorlib.dll)

Functie	Verschillen van 3.5 SP1	Aanbevolen wijzigingen
Uitzonderingen voor beschadigde processtatus	De CLR levert geen uitzonderingen meer voor beschadigde processtatussen aan uitzonderingshandlers in beheerde code.	Deze uitzonderingen geven aan dat de status van een proces is beschadigd. Het wordt afgeraden om uw toepassing in deze status uit te voeren. Zie de HandleProcessCorruptedStateExceptionsAttribute vermelding Handling Corrupted State Exceptions in het MSDN magazine voor meer informatie.
Uitzonderingen voor uitvoeringsengine	ExecutionEngineException is nu verouderd, omdat een ondervangbare uitzondering een instabiele proces kan blijven uitvoeren. Deze wijziging verbetert de voorspelbaarheid en betrouwbaarheid in de runtime.	Gebruik een InvalidOperationException om de voorwaarde aan te geven.

Reflectie

Naamruimte: System.Reflection

Assembly: mscorlib (in mscorlib.dll)

Functie	Verschillen van 3.5 SP1	Aanbevolen wijzigingen
Assembly-hashalgoritmen	De HashAlgorithm eigenschap retourneert AssemblyHashAlgorithmnu, omdat de runtime het hash-algoritme van de assembly waarnaar wordt verwezen niet weet wanneer de assembly niet wordt geladen. (Dit verwijst naar het gebruik van de eigenschap op een assembly waarnaar wordt verwezen, zoals die geretourneerd door de GetReferencedAssemblies methode.)	Geen.
Assembly laden	Om redundant laden van assembly's te voorkomen en virtuele adresruimte te besparen, laadt de CLR nu assembly's met behulp van alleen de Win32-functie `MapViewOfFile` . De functie wordt niet meer aangeroepen `LoadLibrary` . Deze wijziging is van invloed op diagnostische toepassingen op de volgende manieren: * A ProcessModuleCollection bevat geen modules meer uit een klassebibliotheek (.dll bestand), zoals verkregen door een aanroep naar `Process.GetCurrentProcess().Modules`. * Win32-toepassingen die gebruikmaken van de `EnumProcessModules` functie, zien niet alle beheerde modules worden vermeld.	Geen.
Type declareren	De DeclaringType eigenschap retourneert nu juist null als het type geen declarerend type heeft.	Geen.
Afgevaardigden	Een gemachtigde genereert nu een ArgumentNullException in plaats van een NullReferenceException wanneer een null-waarde wordt doorgegeven aan de constructor van de gemachtigde.	Zorg ervoor dat elke uitzonderingsafhandeling van vangsten ArgumentNullException.
Locatie van globale assemblycache wijzigen	Voor .NET Framework 4-assembly's is de globale assemblycache verplaatst van de Windows-map (%WINDIR%) naar de Microsoft.Net submap (%WINDIR%\Microsoft.Net). Assembly's uit eerdere versies blijven in de oudere map staan. De niet-beheerde ASM_CACHE_FLAGS opsomming bevat de nieuwe `ASM_CACHE_ROOT_EX` vlag. Met deze vlag wordt de cachelocatie voor .NET Framework 4-assembly's opgehaald, die kunnen worden verkregen door de functie GetCachePath .	Geen, ervan uitgaande dat toepassingen geen expliciete paden gebruiken voor assembly's, wat geen aanbevolen procedure is.
Global Assembly Cache Tool	Het Gacutil.exe (Global Assembly Cache Tool) biedt geen ondersteuning meer voor de shell-invoegtoepassingsviewer.	Geen.

Interoperabiliteit

Naamruimte: System.Runtime.InteropServices

Assembly: mscorlib (in mscorlib.dll)

Functie	Verschillen van 3.5 SP1	Aanbevolen wijzigingen
Bufferlengte (niet-beheerde API)	Om geheugen op te slaan, is de functionaliteit voor de `pBufferLengthOffset` parameter voor de methode ICorProfilerInfo2::GetStringLayout gewijzigd zodat deze overeenkomt met de `pStringLengthOffset` parameter. Beide parameters verwijzen nu naar de offsetlocatie van de lengte van de tekenreeks. De bufferlengte is verwijderd uit de weergave van de tekenreeksklasse.	Verwijder eventuele afhankelijkheid van de bufferlengte.
JIT-foutopsporing	Ter vereenvoudiging van de registratie voor Just-In-Time-foutopsporing (JIT) gebruikt het .NET Framework-foutopsporingsprogramma nu alleen de registersleutel AeDebug, waarmee het JIT-foutopsporingsgedrag voor systeemeigen code wordt bepaald. Deze wijziging resulteert in het volgende: * U kunt geen twee verschillende foutopsporingsprogramma's meer registreren voor beheerde en systeemeigen code. * U kunt het foutopsporingsprogramma niet meer automatisch starten voor een niet-interactief proces, maar u kunt de gebruiker vragen om een interactief proces. * U ontvangt geen melding meer wanneer het foutopsporingsprogramma niet kan worden gestart of wanneer er geen geregistreerd foutopsporingsprogramma is gestart. * Beleid voor automatisch starten dat afhankelijk is van de interactiviteit van de toepassing, wordt niet meer ondersteund.	Pas de foutopsporingsbewerkingen naar behoefte aan.
Platform aanroepen	Als u de prestaties in de interoperabiliteit met niet-beheerde code wilt verbeteren, worden onjuiste aanroepconventies in een platform nu veroorzaakt dat de toepassing mislukt. In eerdere versies loste de marshalllaag deze fouten op de stapel op.	Fouten opsporen in uw toepassingen in Microsoft Visual Studio waarschuwt u voor deze fouten, zodat u ze kunt corrigeren. Als u binaire bestanden hebt die niet kunnen worden bijgewerkt, kunt u het element NetFx40_PInvokeStackResilience> opnemen in het <configuratiebestand van uw toepassing om aanroepende fouten op te lossen zoals in eerdere versies. Dit kan echter van invloed zijn op de prestaties van uw toepassing.
Verwijderde interfaces (niet-beheerde API)	Om verwarring bij ontwikkelaars te voorkomen, zijn de volgende interfaces verwijderd, omdat ze geen nuttige runtimescenario's bieden en de CLR geen implementaties heeft verstrekt of accepteert: * INativeImageINativeImageDependency * INativeImageInstallInfo * INativeImageEvaluate * INativeImage Converter * ICorModule * IMetaData Converter	Geen.

Gegevens

In deze sectie worden migratieproblemen beschreven voor het gebruik van gegevenssets en SQL-clients, entity framework, LINQ naar SQL en WCF-gegevensservers (voorheen bekend als ADO.NET Data Services).