Migrationsprobleme in .NET Framework 4

Artikel
08/10/2011

Aktualisiert: August 2010

In diesem Thema werden Migrationsprobleme zwischen .NET Framework, Version 3.5 Service Pack 1 und .NET Framework, Version 4 beschrieben, einschließlich der Patches, Änderungen bei der Standardkompatibilität und Sicherheit sowie Änderungen auf Grundlage von Kundenfeedback. Für die meisten dieser Änderungen sind keine Programmieränderungen in den Anwendungen erforderlich. In den Fällen, in denen Änderungen erforderlich sind, finden Sie Informationen in der Spalte "Empfohlene Änderungen" der Tabelle.

In diesem Thema werden wichtige Änderungen in den folgenden Bereichen beschrieben:

ASP.NET und Web
Kern
Daten
Windows Communication Foundation (WCF)
Windows Presentation Foundation (WPF)
XML

Eine allgemeine Übersicht zu den in diesem Thema beschriebenen Problemen finden Sie unter Migrationshandbuch zu .NET Framework 4.

Informationen zu Migrationsproblemen nach Beta 2 finden Sie unter Migrationsprobleme bei .NET Framework 4-Anwendungen: Beta 2 zu RTM.

Weitere Informationen zu neuen Features finden Sie unter Neues in .NET Framework 4.

ASP.NET und Web

Namespaces: System.Web, System.Web.Mobile, System.Web.Security, System.Web.UI.WebControls; Assembly: System.Web (in System.Web.dll)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Browserdefinitionsdateien	Die Browserdefinitionsdateien wurden aktualisiert und enthalten nun Informationen zu neuen und aktualisierten Browsern und Geräten. Ältere Browser und Geräte, z. B. Netscape Navigator, wurden entfernt, und neuere Browser und Geräte wie Google Chrome und Apple iPhone wurden hinzugefügt. Wenn die Anwendung benutzerdefinierte Browserdefinitionen enthält, die von einer der entfernten Browserdefinitionen erben, wird ein Fehler angezeigt. Das HttpBrowserCapabilities-Objekt (das von der Request.Browser-Eigenschaft der Seite verfügbar gemacht wird) wird von den Browserdefinitionsdateien gesteuert. Daher können die Informationen, die durch das Zugreifen auf eine Eigenschaft dieses Objekts in ASP.NET 4 zurückgegeben werden, von den Informationen abweichen, die in einer früheren Version von ASP.NET zurückgegeben wurden.	Wenn die Anwendung die alten Browserdefinitionsdateien benötigt, können Sie sie aus dem folgenden Ordner kopieren: Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers Kopieren Sie die Dateien in den entsprechenden Ordner \CONFIG\Browsers für ASP.NET 4. Nachdem Sie die Dateien kopiert haben, führen Sie das Befehlszeilentool Aspnet_regbrowsers.exe aus. Weitere Informationen finden Sie auf der Website https://www.asp.net/mobile.
Untergeordnete Anwendungen, die unter gemischten Versionen von ASP.NET ausgeführt werden	ASP.NET 4-Anwendungen, die als untergeordnete Elemente von Anwendungen konfiguriert werden und frühere Versionen von ASP.NET ausführen, können möglicherweise aufgrund von Konfigurations- oder Kompilierungsfehlern nicht gestartet werden. Welcher Fehler jeweils auftritt, hängt davon ab, ob die Anwendung unter IIS 6.0 ausgeführt wird oder unter IIS 7 oder IIS 7.5.	Sie können Änderungen an den Konfigurationsdateien der betroffenen Anwendungen vornehmen, damit das Konfigurationssystem die ASP.NET 4-Anwendung ordnungsgemäß erkennt. Informationen zu den vorzunehmenden Änderungen finden Sie im Abschnitt "Untergeordnete ASP.NET 4-Anwendungen werden unter ASP.NET 2.0- oder ASP.NET 3.5-Anwendungen nicht gestartet" im Dokument Änderungen in ASP.NET 4, die die Lauffähigkeit der Anwendung beeinträchtigen auf der ASP.NET-Website.
ClientID-Änderungen	Mit der neuen Einstellung ClientIDMode in ASP.NET 4 können Sie angeben, wie ASP.NET das id-Attribut für HTML-Elemente generiert. In früheren Versionen von ASP.NET entsprach das Standardverhalten der Einstellung AutoID von ClientIDMode. Die Standardeinstellung ist nun Predictable. Weitere Informationen finden Sie unter Identifikation von ASP.NET-Webserversteuerelementen.	Wenn Sie die Anwendung mithilfe von Visual Studio 2010 von ASP.NET 2.0 oder ASP.NET 3.5 aktualisieren, fügt das Tool der Datei Web.config automatisch eine Einstellung hinzu, die das Verhalten der früheren Versionen von .NET Framework beibehält. Wenn Sie jedoch eine Anwendung aktualisieren, indem Sie den Anwendungspool in IIS ändern, um auf .NET Framework 4 abzuzielen, verwendet ASP.NET standardmäßig den neuen Modus. Fügen Sie der Datei Web.config die folgende Einstellung hinzu, um den neuen Client-ID-Modus zu deaktivieren: <pages ClientIDMode="AutoID" / >
Codezugriffssicherheit (Code Access Security, CAS)	ASP.NET 2.0-NET-Funktionen, die in ASP.NET 3.5 hinzugefügt wurden, verwenden das .NET Framework 1.1- und .NET Framework 2.0-Codezugriffssicherheitsmodell (CAS). Die Implementierung von CAS in ASP.NET 4 wurde jedoch erheblich überholt. Daher können bei teilweise vertrauenswürdige ASP.NET-Anwendungen, die vertrauenswürdigen Code benötigen, der im globalen Assemblycache ausgeführt wird, Fehler mit verschiedenen Sicherheitsausnahmen auftreten. Bei teilweise vertrauenswürdigen Anwendungen, die umfangreiche Änderungen an der CAS-Richtlinie des Computers benötigen, können ebenfalls Fehler und Sicherheitsausnahmen auftreten.	Sie können teilweise vertrauenswürdige ASP.NET 4-Anwendungen mit dem neuen legacyCasModel-Attribut im trust Konfigurationselement auf das Verhalten von ASP.NET 1.1 und 2.0 zurücksetzen, wie im folgenden Beispiel gezeigt: <trust level= "Medium" legacyCasModel="true" /> Sicherheitshinweis Das Zurücksetzen auf das ältere CAS-Modell kann eine verringerte Sicherheit bedeuten. Weitere Informationen zum neuen ASP.NET 4-Codezugriffssicherheitsmodell finden Sie unter Codezugriffssicherheit für ASP.NET 4-Anwendungen.
Konfigurationsdateien	Die Stammkonfigurationsdateien (die Datei machine.config und die Stamm-Datei Web.config) für .NET Framework und ASP.NET 4 wurden aktualisiert und schließen nun die meisten Standardkonfigurationsinformationen ein, die in den Web.config-Anwendungsdateien in ASP.NET 3.5 vorhanden waren. Aufgrund der Komplexität der verwalteten IIS 7- und IIS 7.5-Konfigurationssysteme kann das Ausführen von ASP.NET 3.5-Anwendungen unter ASP.NET 4 und unter IIS 7 und IIS 7.5 zu ASP.NET-Fehlern oder IIS-Fehlern führen.	Aktualisieren Sie ASP.NET 3.5-Anwendungen mit dem Projektupgradetools in Visual Studio 2010 auf ASP.NET 4. Visual Studio 2010 ändert die Web.config-Datei der ASP.NET 3.5-Anwendung automatisch, sodass sie die entsprechenden Einstellungen für ASP.NET 4 enthält. Sie können jedoch ASP.NET 3.5-Anwendungen mit .NET Framework 4 ohne Neukompilierung ausführen. In diesem Fall müssen Sie möglicherweise die Web.config-Datei der Anwendung manuell ändern, bevor Sie die Anwendung unter .NET Framework 4 und IIS 7 oder IIS 7.5 ausführen. Die genaue Änderung, die Sie vornehmen müssen, ist abhängig von der Kombination der Software, mit der Sie arbeiten, einschließlich SP (Service Pack)-Versionen. Informationen zu den möglichen Softwarekombinationen, die von dieser Änderung betroffen sind, zum Lösen von Problemen mit bestimmten Kombinationen finden Sie im Abschnitt "Konfigurationsfehler im Zusammenhang mit der neuen ASP.NET 4-Stammkonfiguration" im Dokument Änderungen in ASP.NET 4, die die Lauffähigkeit der Anwendung beeinträchtigen auf der ASP.NET-Website.
Steuerelementrendering	In früheren Versionen von ASP.NET haben einige Steuerelemente Markup ausgegeben, das Sie nicht deaktivieren konnten. Standardmäßig wird dieser Markuptyp in ASP.NET 4 nicht mehr generiert. Die Renderingänderungen wirken sich auf die folgenden Steuerelemente aus: Das Image-Steuerelement und ImageButton-Steuerelement rendern kein border="0"-Attribut mehr. Die BaseValidator-Klasse und die Validierungssteuerelemente, die davon abgeleitet sind, rendern nicht mehr standardmäßig roten Text. Das HtmlForm-Steuerelement rendert kein name-Attribut. Das Table-Steuerelement rendert kein border="0"-Attribut mehr. Steuerelemente, die nicht für Benutzereingaben konzipiert wurden (z. B. das Label-Steuerelement), rendern nicht mehr das disabled="disabled"-Attribut, wenn ihre Enabled-Eigenschaft auf false festgelegt wird (oder wenn sie diese Einstellung von einem Containersteuerelement erben).	Wenn Sie die Anwendung von ASP.NET 2.0 oder ASP.NET 3.5 mithilfe von Visual Studio 2010 aktualisieren, fügt das Tool der Datei Web.config automatisch eine Einstellung hinzu, die das Legacyrendering beibehält. Wenn Sie jedoch eine Anwendung aktualisieren, indem Sie den Anwendungspool in IIS ändern, um auf .NET Framework 4 abzuzielen, verwendet ASP.NET standardmäßig den neuen Renderingmodus. Fügen Sie der Datei Web.config die folgende Einstellung hinzu, um den neuen Renderingmodus zu deaktivieren: <pages controlRenderingCompatibilityVersion="3.5" />
Ereignishandler in Standarddokumenten	ASP.NET 4 rendert den action-Attributwert des form-HTML-Elements als leere Zeichenfolge, wenn eine Anforderung an eine URL ohne Erweiterung erfolgt, dem ein Standarddokument zugeordnet ist. In früheren Versionen von ASP.NET würde eine Anforderung an https://contoso.com zu einer Anforderung an Default.aspx führen. In diesem Dokument würde das öffnende form-Tag wie im folgenden Beispiel gerendert werden: <form action="Default.aspx" /> In ASP.NET 4 führt eine Anforderung an https://contoso.com auch zu einer Anforderung an Default.aspx, aber ASP.NET rendert jetzt das öffnende form-HTML-Tag wie im folgenden Beispiel: <form action="" /> Wenn das action-Attribut eine leere Zeichenfolge ist, erstellt das DefaultDocumentModule-Objekt in IIS eine untergeordnete Anforderung an Default.aspx. Unter den meisten Bedingungen ist diese untergeordnete Anforderung für Anwendungscode transparent, und die Seite Default.aspx wird normal ausgeführt. Eine mögliche Interaktion zwischen verwaltetem Code und dem integrierten Modus von IIS 7 oder IIS 7.5 kann jedoch bewirken, dass verwaltete ASPX-Seiten während der untergeordneten Anforderung nicht mehr ordnungsgemäß funktionieren. Wenn die folgenden Bedingungen auftreten, führt die untergeordnete Anforderung an ein ASPX-Standarddokument zu einem Fehler oder unerwartetem Verhalten: Eine ASPX-Seite wird an den Browser gesendet, und das action-Attribut des form-Elements ist auf "" festgelegt. Das Formular wird an ASP.NET zurückgesendet. Ein verwaltetes HTTP-Modul liest einen Teil des Entitätstexts, z. B. Request.Form oder Request.Params. Dies führt dazu, dass der Entitätstext der POST-Anforderung in den verwalteten Arbeitsspeicher gelesen wird. Daher ist der Entitätstext nicht mehr für systemeigene Codemodule verfügbar, die im integrierten Modus von IIS 7 oder IIS 7.5 ausgeführt werden. Das DefaultDocumentModule-Objekt in IIS wird schließlich ausgeführt und erstellt eine untergeordnete Anforderung an das Dokument Default.aspx. Da jedoch der Entitätstext bereits von einem verwaltete Codeabschnitt gelesen wurde, ist kein Entitätstext verfügbar, der an die untergeordnete Anforderung gesendet werden kann. Wenn die HTTP-Pipeline für die untergeordnete Anforderung ausgeführt wird, wird der Handler für ASPX-Dateien während der Handlerausführungsphase ausgeführt. Da kein Entitätstext vorhanden ist, gibt es keine Formularvariablen und keinen Ansichtszustand. Daher sind keine Informationen verfügbar, mit denen der ASPX-Seiten-Handler bestimmen kann, welches Ereignis ggf. ausgelöst werden soll. Aus diesem Grund wird keiner der Postbackereignishandler für die betroffene ASPX-Seite ausgeführt.	Informationen zu Möglichkeiten, Probleme zu umgehen, die aufgrund dieser Änderung auftreten können, finden Sie unter "Ereignishandler werden möglicherweise nicht in einem Standarddokument im integrierten Modus von IIS 7 oder IIS 7.5 ausgelöst" im Dokument Änderungen in ASP.NET 4, die die Lauffähigkeit der Anwendung beeinträchtigen auf der ASP.NET-Website.
Hashalgorithmus	ASP.NET verwendet Verschlüsselung sowie Hashalgorithmen zum Sichern von Daten, z. B. Formularauthentifizierungscookies und Ansichtszustand. Standardmäßig verwendet ASP.NET 4 den HMACSHA256-Algorithmus für Hashvorgänge bei Cookies und Ansichtszustand. In früheren Versionen von ASP.NET wurde der ältere HMACSHA1-Algorithmus verwendet.	Wenn Sie Anwendungen ausführen, die ASP.NET 2.0 und ASP.NET 4 kombinieren und in denen Daten wie Formularauthentifizierungscookies über mehrere .NET Framework-Versionen funktionieren müssen, konfigurieren Sie durch Hinzufügen der folgenden Einstellung in der Datei Web.config eine ASP.NET 4-Webanwendung für die Verwendung des älteren HMACSHA1-Algorithmus: <machineKey validation="SHA1" />
Hosten von Steuerelementen in Internet Explorer	Sie können in Internet Explorer keine Windows Forms-Steuerelemente mehr hosten, da es bessere Lösungen zum Hosten von Steuerelementen im Web gibt. Die IEHost.dll-Assembly und die IEExec.exe-Assembly wurden deshalb aus .NET Framework entfernt.	Sie können die folgenden Technologien zum Entwickeln von benutzerdefinierten Steuerelementen in Webanwendungen verwenden: Sie können eine Silverlight-Anwendung erstellen und so konfigurieren, dass sie außerhalb des Browsers ausgeführt wird. Weitere Informationen finden Sie unter Out-of-Browser Support. Sie können eine XAML-Browseranwendung (XBAP) erstellen, um die WPF-Funktionen zu nutzen (dazu ist .NET Framework auf Clientcomputern erforderlich). Weitere Informationen finden Sie unter Übersicht über WPF-XAML-Browseranwendungen.
HtmlEncode-Methode und UrlEncode-Methode	Die HtmlEncode-Methode und UrlEncode-Methode der HttpUtility-Klasse und HttpServerUtility-Klasse wurden aktualisiert und codieren das einfache Anführungszeichen (') wie folgt: Die HtmlEncode-Methode codiert Instanzen des einfachen Anführungszeichens als '. Die UrlEncode-Methode codiert Instanzen des einfachen Anführungszeichens als %27.	Suchen Sie im Code die Stellen, an denen die HtmlEncode-Methode und UrlEncode-Methode verwendet werden, und stellen Sie sicher, dass die Änderung der Codierung nicht zu einer Änderung führt, die Auswirkungen auf die Anwendung hat.
HttpExceptions-Fehler in ASP.NET 2.0-Anwendungen	Nachdem ASP.NET 4 für IIS 6 aktiviert wurde, können unter IIS 6 ausgeführte ASP.NET 2.0-Anwendungen (unter Windows Server 2003 oder Windows Server 2003 R2) beispielsweise folgende Fehler generieren: System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.	Wenn ASP.NET 4 zum Ausführen der Website nicht erforderlich ist, ordnen Sie die Site neu zu, sodass stattdessen ASP.NET 2.0 verwendet wird. – oder – Wenn ASP.NET 4 zum Ausführen der Website erforderlich ist, verschieben Sie alle untergeordneten virtuellen ASP.NET 2.0-Verzeichnisse auf eine andere Website, die ASP.NET 2.0 zugeordnet ist. – oder – Deaktivieren Sie URLs ohne Dateierweiterung. Weitere Informationen finden Sie unter "ASP.NET 2.0-Anwendungen können HttpException-Fehler generieren, die auf eurl.axd verweisen" im Dokument Änderungen in ASP.NET 4, die die Lauffähigkeit der Anwendung beeinträchtigen auf der ASP.NET-Website.
Mitgliedschaftstypen	Einige Typen (z. B. System.Web.Security.MembershipProvider), die in der ASP.NET-Mitgliedschaft verwendet werden, wurden aus System.Web.dll in die System.Web.ApplicationServices.dll-Assembly verschoben. Die Typen wurden verschoben, um Abhängigkeiten verschiedener Architekturebenen zwischen Typen im Client und in erweiterten .NET Framework-SKUs aufzulösen.	Klassenbibliotheken, die aus früheren Versionen von ASP.NET aktualisiert wurden und Mitgliedschaftstypen verwenden, die verschoben wurden, werden bei Verwendung in einem ASP.NET 4-Projekt möglicherweise nicht kompiliert. In diesem Fall fügen Sie System.Web.ApplicationServices.dll im Klassenbibliotheksprojekt einen Verweis hinzu.
Änderungen am Menu-Steuerelement	Änderungen am Menu-Steuerelement führen zu folgendem Verhalten: Wenn System.Web.UI.WebControls.MenuRenderingMode auf List oder System.Web.UI.WebControls.MenuRenderingMode auf Default festgelegt wird und PagesSection.ControlRenderingCompatibilityVersion auf 4.0 oder höher festgelegt wird, hat die MenuItem.PopOutImageUrl-Eigenschaft keine Auswirkung. Wenn der Pfad, der in der Menu.StaticPopOutImageUrl-Eigenschaft und der Menu.DynamicPopOutImageUrl-Eigenschaft festgelegt wird, einen umgekehrten Schrägstrich (\) enthalten ist, werden die Bilder nicht gerendert. (In früheren Versionen von ASP.NET konnte der Pfad einen umgekehrten Schrägstrich enthalten.)	Legen Sie Menu.StaticPopOutImageUrl oder Menu.DynamicPopOutImageUrl des übergeordneten System.Web.UI.WebControls.Menu-Steuerelements fest, anstatt die MenuItem.PopOutImageUrl-Eigenschaft für einzelne Menüelemente festzulegen. – oder – Legen Sie System.Web.UI.WebControls.MenuRenderingMode auf Table oder System.Web.UI.WebControls.MenuRenderingMode auf Default fest, und legen Sie PagesSection.ControlRenderingCompatibilityVersion auf 3.5 fest. Diese Einstellungen führen dazu, dass das Menu-Steuerelement das auf HTML-Tabellen basierte Layout wie in früheren Versionen von ASP.NET verwendet. Wenn der Pfad in der Menu.StaticPopOutImageUrl-Eigenschaft oder Menu.DynamicPopOutImageUrl-Eigenschaft einen umgekehrten Schrägstrich (\) enthält, ersetzen Sie es durch einen Schrägstrich (/).
Mobile Assembly in der Web.config-Datei	In früheren Versionen von ASP.NET war ein Verweis auf die System.Web.Mobile.dll-Assembly in der Web.config-Stammdatei im assemblies-Abschnitt unter system.web/compilation enthalten. Der Verweis auf diese Assembly wurde entfernt, um die Leistung zu verbessern. Hinweis Die System.Web.Mobile.dll-Assembly und die ASP.NET Mobile-Steuerelemente sind in ASP.NET 4 enthalten, aber sie sind veraltet.	Wenn Sie Typen aus dieser Assembly verwenden möchten, fügen Sie einen Verweis auf die Assembly entweder in der Web.config-Stammdatei oder einer Web.config-Anwendungsdatei hinzu.
Ausgabecache	In ASP.NET 1.0 hat ein Fehler dazu geführt, dass zwischengespeicherte Seiten, die Location="ServerAndClient" als Ausgabecacheeinstellung angegeben haben, einen Vary:* HTTP-Header in der Antwort ausgegeben haben. Dies hatte zur Folge, dass Clientbrowser angewiesen wurden, die Seite nie lokal zwischenzuspeichern. In ASP.NET 1.1 wurde die HttpCachePolicy.SetOmitVaryStar-Methode hinzugefügt, die aufgerufen werden konnte, um den Vary:-Header zu unterdrücken. Problemberichte zeigen jedoch, dass Entwickler das vorhandene SetOmitVaryStar-Verhalten nicht kennen. In ASP.NET 4 wird der Vary: HTTP-Header nicht mehr von Antworten ausgegeben, die die folgende Direktive angeben: <%@ OutputCache Location="ServerAndClient" %> Daher wird die HttpCachePolicy.SetOmitVaryStar-Methode nicht mehr benötigt, um den Vary:*-Header zu unterdrücken. In Anwendungen, die "ServerAndClient" für das Location-Attribut angeben, können Seiten im Browser zwischengespeichert werden, ohne dass Sie HttpCachePolicy.SetOmitVaryStar aufrufen müssen.	Wenn Seiten in der Anwendung Vary:* ausgeben müssen, rufen Sie die HttpResponse.AppendHeader-Methode auf, wie im folgenden Beispiel dargestellt: HttpResponse.AppendHeader("Vary","*"); Alternativ können Sie den Wert des Location-Ausgabecachingattributs in "Server" ändern.
Seitenanalyse	Der Seitenparser für ASP.NET-Webseiten (ASPX-Dateien) und Benutzersteuerelement (ASCX-Dateien) ist in ASP.NET 4 strenger als in früheren Versionen von ASP.NET. Mehr Markup wird als ungültig gekennzeichnet als in früheren Versionen.	Untersuchen Sie Fehlermeldungen, die beim Ausführen einer Seite erzeugt werden, und beheben Sie Fehler, die sich aus ungültigem Markup ergeben.
Passport-Typen	Die in ASP.NET 2.0 integrierte Passport-Unterstützung ist veraltet und wird aufgrund von Änderungen in Passport (jetzt Live ID-SDK) nicht unterstützt. Daher werden die Typen in Zusammenhang mit Passport in System.Web.Security jetzt mit dem ObsoleteAttribute-Attribut markiert.	Ändern Sie allen vorliegenden Code, der Passport-Typen im System.Web.Security-Namespace verwendet (z. B. System.Web.Security.PassportIdentity) so, dass Windows Live ID SDK verwendet wird.
PathInfo-Informationen in der FilePath-Eigenschaft	ASP.NET 4 umfasst nicht mehr den PathInfo-Wert in den Rückgabewerten von Eigenschaften wie HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath und HttpRequest.CurrentExecutionFilePath. Stattdessen sind die PathInfo-Informationen in HttpRequest.PathInfo verfügbar. Betrachten Sie z. B. das folgende URL-Fragment: /testapp/Action.mvc/SomeAction In früheren Versionen von ASP.NET verfügen System.Web.HttpRequest-Eigenschaften über die folgenden Werte: HttpRequest.FilePath: /testapp/Action.mvc/SomeAction HttpRequest.PathInfo: (leer) In ASP.NET 4 verfügen System.Web.HttpRequest-Eigenschaften stattdessen über die folgenden Werte: HttpRequest.FilePath: /testapp/Action.mvc HttpRequest.PathInfo: SomeAction	Suchen Sie im Code die Stellen, an denen Sie Eigenschaften der System.Web.HttpRequest-Klasse benötigen, um Pfadinformationen zurückzugeben. Ändern Sie den Code entsprechend den Änderungen bei der Rückgabe der Pfadinformationen.
Anforderungsvalidierung	Zur Optimierung der Anforderungsvalidierung wird die ASP.NET-Anforderungsvalidierung früher im Anforderungslebenszyklus aufgerufen. Daher wird die Anforderungsvalidierung für Anforderungen ausgeführt, bei denen es sich nicht um ASPX-Dateien handelt, z. B. für Webdienstaufrufe und für benutzerdefinierte Handler. Die Anforderungsvalidierung ist auch aktiv, wenn benutzerdefinierte HTTP-Module in der Anforderungsverarbeitungspipeline ausgeführt werden. Aufgrund dieser Änderung können Anforderungen für andere Ressourcen als ASPX-Dateien Anforderungsvalidierungsfehler auslösen. Benutzerdefinierter Code, der in der Anforderungspipeline ausgeführt wird (z. B. benutzerdefinierte HTTP-Module), kann ebenfalls Anforderungsvalidierungsfehler auslösen.	Falls notwendig, können Sie das alte Verhalten wiederherstellen, dass nur ASPX-Seiten die Anforderungsvalidierung auslösen, indem Sie die folgende Einstellung in der Webkonfigurationsdatei verwenden: <httpRuntime requestValidationMode="2.0" /> Sicherheitshinweis Wenn Sie das alte Verhalten wiederherstellen, stellen Sie sicher, dass der gesamte Code in vorhandenen Handlern, Modulen und in anderem benutzerdefiniertem Code Überprüfungen auf potenziell unsichere HTTP-Eingaben ausführt, bei denen es sich um XSS-Angriffsmöglichkeiten handeln könnte.
Routing	Wenn Sie in Visual Studio 2010 eine Dateisystemwebsite erstellen, und die Website befindet sich in einem Ordner, der im Ordnernamen einen Punkt (.) enthält, funktioniert das URL-Routing nicht zuverlässig. Ein HTTP-Fehler mit dem Fehlercode 404 wird von einigen virtuellen Pfaden zurückgegeben. Dies liegt daran, dass Visual Studio Development Server (Cassini) von Visual Studio 2010 mit einem falschen Pfad für das virtuelle Stammverzeichnis gestartet wird.	Ändern Sie auf der Seite Eigenschaften für die dateibasierte Website das Virtueller Pfad-Attribut in "/". – oder – Erstellen Sie ein Webanwendungsprojekt anstatt eines Websiteprojekts. Webanwendungsprojekte weisen dieses Problem nicht auf, und das URL-Routing funktioniert, auch wenn der Name des Projektordners einen Punkt enthält. – oder – Erstellen Sie eine HTTP-basierte Website, die in IIS gehostet wird. Von IIS gehostete Websites können Punkte im virtuellen Pfad und im Projektdateiordner enthalten.
SharePoint-Websites	Wenn Sie versuchen, eine ASP.NET 4-Website auszuführen, die als untergeordnetes Element einer SharePoint-Website bereitgestellt wird und eine benutzerdefinierte teilweise vertrauenswürdige Ebene mit dem Namen WSS_Minimal enthält, wird der folgende Fehler angezeigt: Could not find permission set named 'ASP.Net'.	Derzeit sind keine Versionen von SharePoint mit ASP.NET kompatibel. Folglich sollten Sie nicht versuchen, eine ASP.NET 4-Website als untergeordnetes Element einer SharePoint-Website auszuführen.
XHTML 1.1-Standards	Um die Kompatibilität von XHTML-1.1 für neue Websites zu ermöglichen, generieren ASP.NET-Steuerelemente in .NET Framework 4 XHTML 1.1-kompatibles HTML. Dieses Rendering wird mit folgenden Option in der Web.config-Datei aktiviert: <system.Web> <pages controlRenderingCompatibilityVersion="4.0"/> </system.Web> Standardmäßig ist diese Option auf 4.0 festgelegt. Für Webprojekte, die von Visual Studio 2008 auf Visual Studio aktualisiert werden, ist die 3.5-Einstellung zur Kompatibilität aktiviert.	Keine.

Zurück nach oben

Kern

Allgemeine Features

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
CardSpace	Windows CardSpace ist nicht mehr in .NET Framework enthalten; es wird getrennt zur Verfügung gestellt.	Laden Sie Windows CardSpace im Microsoft Download Center herunter.
Konfigurationsdateien	Korrekturen wurden an der Art und Weise vorgenommen, in der von .NET Framework auf Anwendungskonfigurationsdateien zugegriffen wird.	Wenn die Anwendungskonfigurationsdatei den Namen "Anwendungsname.config" trägt, benennen Sie sie in "Anwendungsname.exe.config" um. Nennen Sie beispielsweise MyApp.config in MyApp.exe.config um.
C#-Codecompiler	Die Klassen Compiler, CompilerError und ErrorLevel, die sich im Microsoft.CSharp-Namespace befanden, sind nicht mehr verfügbar, und ihre Assembly (cscompmgd.dll) ist nicht mehr in .NET Framework enthalten.	Verwenden Sie die CodeDomProvider-Klasse und andere Klassen im System.CodeDom.Compiler-Namespace. Weitere Informationen finden Sie unter Verwenden von CodeDOM .
Hosting (nicht verwaltete API)	Zur Verbesserung der Hostingfunktionen sind einige Hostingaktivierungs-APIs nun veraltet. Durch prozessinterne parallele Ausführungsfunktionen kann eine Anwendung mehrere Versionen von .NET Framework im gleichen Prozess laden und starten. Sie können z. B. Anwendungen ausführen, die auf .NET Framework 2.0 SP1 basierende Add-Ins (oder Komponenten) und auf .NET Framework 4 basierende Add-Ins im gleichen Prozess laden. In älteren Komponenten wird weiterhin die ältere .NET Framework-Version verwendet, und neue Komponenten verwenden die neue .NET Framework-Version.	Verwenden Sie die in Prozessinterne parallele Ausführung beschriebenen Konfigurationen.
Neues Sicherheitsmodell	Die Codezugriffssicherheitsrichtlinie (CAS) wurde deaktiviert und durch ein vereinfachtes Modell ersetzt, wie in Änderungen der Sicherheit in .NET Framework 4 beschrieben.	Änderungen sind möglicherweise erforderlich, wenn Sie in den Anwendungen CAS benötigen. Weitere Informationen finden Sie unter Kompatibilität und Migration von Richtlinien für die Codezugriffssicherheit.

Zurück nach oben

Datum und Uhrzeit

Namespace: System; Assembly: mscorlib (in mscorlib.dll)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Sommerzeit	Um mit der Systemuhr konsistent zu sein, verwenden Zeiteigenschaften (z. B. TimeZoneInfo.Local und DateTime.Now) jetzt Betriebssystemregeln statt anderer .NET Framework-Daten für Vorgänge im Zusammenhang mit der Sommerzeit.	Keine.
Formatzeichenfolgen	Um die kulturabhängige Formatierung zu unterstützen, schließt die TimeSpan-Struktur neue Überladungen der Methoden ToString, Parse und TryParse sowie neue Methoden für ParseExact und TryParseExact ein.	Keine.

Zurück nach oben

Globalisierung

Eine Liste neuer neutraler und bestimmter Kulturen finden Sie unter Neues bei Globalisierung und Lokalisierung.

Namespace: System.Globalization; Assembly: mscorlib (in mscorlib.dll)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Kulturnamen	Die folgenden Namensänderungen wirken sich auf die Kulturen für Deutsch, Divehi und afrikanische Kulturen aus: CurrencyEnglishName: Der Währungsname für die Kultur "Deutsch (Schweiz)" (de-CH) wurde von "sFr." in "Fr." geändert. LongDatePattern: Das lange Datumsmuster der Kultur "Divehi (Malediven)" (dv-MV) wurde von "dd/MMMM/yyyy" in "dd/MM/yyyy" geändert. PMDesignator: der PM-Kennzeichner der Kultur "Afrikaans (Südafrika)" (af-ZA) wurde von "nm" in "PM" geändert.	Beachten Sie die Änderungen der Kulturnamen.
LCID-Parameter	Um mit erwartetem Verhalten in Automatisierungsservereinstellungen konsistent zu sein, übergibt CLR nicht mehr die aktuelle Kultur für den LCID-Parameter an nicht verwaltete COM-basierte Anwendungen. Stattdessen wird 1033 (en-us) als Kultur übergeben.	Es sind keine Änderungen erforderlich, außer bei systemeigenen Anwendungen, die eine angegebene Kultur erfordern.
Veraltete Kulturtypen	Der FrameworkCultures-Kulturtyp und der WindowsOnlyCultures-Kulturtyp sind nun veraltet. Für die Abwärtskompatibilität gibt FrameworkCultures jetzt neutrale und bestimmte Kulturen zurück, die in der vorherigen Version von .NET Framework enthalten waren, und WindowsOnlyCultures gibt jetzt eine leere Liste zurück.	Verwenden Sie andere Werte der CultureTypes-Enumeration.
Abrufen der Kultur	Ab Windows 7 ruft .NET Framework 4 Kulturinformationen aus dem Betriebssystem ab, statt die Daten selbst zu speichern. Außerdem wird .NET Framework mit Windows für Sortierungs- und Groß-/Kleinschreibungsdaten synchronisiert.	Keine.
Unicode 5.1-Standards	.NET Framework unterstützt jetzt alle Unicode 5.1-Zeichen, dies bedeutet ca. 1.400 Zeichen mehr. Zu den zusätzlichen Zeichen gehören neue Symbole, Pfeile, diakritische Zeichen, Interpunktion, mathematische Symbole, CJK-Zeichen und Ideogramme, zusätzliche numerische Malayalam- und Telugu-Zeichen und verschiedene Zeichen für Myanmar, Latein, Arabisch, griechisch, Mongolisch und Kyrillisch. Die folgenden neuen Skripts werden mit Unicode 5.1 unterstützt: Sundanesisch, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Oriya, Tamil, Telugu/ und Malayalam-Zeichen und Cham.	Keine.

Zurück nach oben

Ausnahmen

Namespaces: System, System.Runtime.ExceptionServices; Assembly: mscorlib (in mscorlib.dll)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Ausnahmen für beschädigten Prozesszustand	CLR sendet keine Ausnahmen für beschädigte Prozesszustände mehr an Ausnahmehandler in verwaltetem Code.	Diese Ausnahmen geben an, dass der Zustand eines Prozesses beschädigt ist. Es empfiehlt sich nicht, die Anwendung in diesem Zustand ausführen. Weitere Informationen finden Sie unter HandleProcessCorruptedStateExceptionsAttribute und im Beitrag Verarbeitung von Ausnahmen bei Beschädigungen im Blog "Tiefe Einblicke in CLR".
Ausnahmen des Ausführungsmoduls	ExecutionEngineException ist jetzt veraltet, da eine abfangbare Ausnahme zulässt, dass ein Prozess weiterhin ausgeführt wird. Diese Änderung verbessert Voraussagbarkeit und Zuverlässigkeit in der Laufzeit.	Verwenden Sie eine InvalidOperationException, um die Bedingung zu signalisieren.

Ausnahmen für beschädigten Prozesszustand

CLR sendet keine Ausnahmen für beschädigte Prozesszustände mehr an Ausnahmehandler in verwaltetem Code.

Diese Ausnahmen geben an, dass der Zustand eines Prozesses beschädigt ist. Es empfiehlt sich nicht, die Anwendung in diesem Zustand ausführen.

Weitere Informationen finden Sie unter HandleProcessCorruptedStateExceptionsAttribute und im Beitrag Verarbeitung von Ausnahmen bei Beschädigungen im Blog "Tiefe Einblicke in CLR".

Ausnahmen des Ausführungsmoduls

ExecutionEngineException ist jetzt veraltet, da eine abfangbare Ausnahme zulässt, dass ein Prozess weiterhin ausgeführt wird. Diese Änderung verbessert Voraussagbarkeit und Zuverlässigkeit in der Laufzeit.

Verwenden Sie eine InvalidOperationException, um die Bedingung zu signalisieren.

Zurück nach oben

Reflektion

Namespace: System.Reflection; Assembly: mscorlib (in mscorlib.dll)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Assemblyhashalgorithmen	Die AssemblyName.HashAlgorithm-Eigenschaft gibt jetzt AssemblyHashAlgorithm.None zurück, da die Laufzeit den Hashalgorithmus der Assembly, auf die verwiesen wird, nicht kennt, wenn die Assembly nicht geladen wurde. (Dies bezieht sich auf die Verwendung der Eigenschaft bei einer Assembly, auf die verwiesen wird, z. B. die von der Assembly.GetReferencedAssemblies-Methode zurückgegebene Assembly.)	Keine.
Laden von Assemblys	Um redundantes Laden von Assemblys zu verhindern und virtuellen Adressenspeicherplatz zu sparen, lädt CLR Assemblys nun nur mithilfe der MapViewOfFile-Win32-Funktion. Die LoadLibrary-Funktion wird nicht mehr ebenfalls aufgerufen. Diese Änderung hat folgende Auswirkungen auf Diagnoseanwendungen: Eine ProcessModuleCollection enthält nicht mehr Module aus einer Klassenbibliothek (DLL-Datei), wie durch einem Aufruf von Process.GetCurrentProcess().Modules abgerufen. Für Win32-Anwendungen, die die EnumProcessModules-Funktion verwenden, werden nicht alle verwalteten Module aufgeführt.	Keine.
Deklarierender Typ	Die Type.DeclaringType-Eigenschaft gibt jetzt ordnungsgemäß NULL zurück, wenn der Typ nicht über einen deklarierenden Typ verfügt.	Keine.
Delegaten	Ein Delegat löst jetzt eine ArgumentNullException statt einer NullReferenceException aus, wenn ein NULL-Wert an den Konstruktor des Delegaten übergeben wird.	Stellen Sie sicher, dass jede Ausnahmebehandlung ArgumentNullException abfängt.
Änderung des Speicherorts des globalen Assemblycache	Für .NET Framework 4-Assemblys wurde der globale Assemblycache aus dem Windows-Verzeichnis (% WINDIR%) in das Unterverzeichnis Microsoft.Net (%WINDIR%\Microsoft.Net) verschoben. Assemblys aus früheren Versionen verbleiben im älteren Verzeichnis. Die nicht verwaltete ASM_CACHE_FLAGS-Enumeration enthält das neue ASM_CACHE_ROOT_EX-Flag. Dieses Flag ruft den Cachespeicherort für .NET Framework 4-Assemblys ab, die von der GetCachePath-Funktion abgerufen werden können.	Keines, ausgehend davon, dass Anwendungen keine expliziten Pfade zu Assemblys verwenden. Hierbei handelt es sich um keine empfohlene Vorgehensweise.
Global Assembly Cache-Tool	Der Shell-Plug-In-Viewer wird von Gacutil.exe (Global Assembly Cache-Tool) nicht mehr unterstützt.	Keine.

Interoperabilität

Namespace: System.Runtime.InteropServices; Assembly: mscorlib (in mscorlib.dll)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Pufferlänge (nicht verwaltete API)	Um Arbeitsspeicher zu sparen, wurde die Funktionalität für den pBufferLengthOffset-Parameter für die ICorProfilerInfo2::GetStringLayout-Methode geändert und entspricht nun dem pStringLengthOffset-Parameter. Beide Parameter zeigen jetzt auf die Offsetposition der Länge der Zeichenfolge. Die Pufferlänge wurde aus der Darstellung der Zeichenfolgenklasse entfernt.	Entfernen Sie jede Abhängigkeit von der Pufferlänge.
JIT-Debuggen	Zur Vereinfachung der Registrierung zum Just-In-Time-Debugging (JIT) verwendet der .NET Framework-Debugger jetzt nur den Registrierungsschlüssel AeDebug, der das JIT-Debugging-Verhalten für systemeigenen Code steuert. Diese Änderung hat folgende Auswirkungen: Sie können nicht mehr zwei verschiedene Debugger für verwalteten und systemeigenen Code registrieren. Sie können den Debugger für einen nicht interaktiven Prozess nicht mehr automatisch starten, aber Sie können den Benutzer für einen interaktiven Prozess auffordern. Sie werden nicht mehr benachrichtigt, wenn der Debugger nicht startet oder wenn kein registrierter Debugger vorhanden ist, der gestartet werden soll. Richtlinien für den automatischen Start, die von der Interaktivität der Anwendung abhängen, werden nicht mehr unterstützt.	Stellen Sie Debugvorgänge nach Bedarf ein.
Plattformaufruf	Um die Leistung bei der Interoperabilität mit nicht verwaltetem Code zu verbessern, führen falsche Aufrufkonventionen in einem Plattformaufruf jetzt zu einem Fehler der Anwendung. In früheren Versionen wurden diese Fehler durch die Marshallingebene im Stapel aufwärts behoben.	Wenn Sie Ihre Anwendungen in Microsoft Visual Studio 2010 debuggen, werden Sie auf diese Fehler hingewiesen, damit Sie sie korrigieren können. Bei Binärdateien, die nicht aktualisiert werden können, können Sie das <NetFx40_PInvokeStackResilience>-Element in der Konfigurationsdatei der Anwendung einschließen, um das Aufrufen von Fehlern zu ermöglichen, die wie in früheren Versionen weiter oben im Stapel aufgelöst werden sollen. Dies kann jedoch die Leistung der Anwendung beeinträchtigen.
Entfernte Schnittstellen (nicht verwaltete API)	Um Verwirrung bei den Entwicklern zu vermeiden, wurden die folgenden Schnittstellen entfernt, da sie keine nützlichen Laufzeitszenarien bereitgestellt haben und die CLR keine Implementierungen bereitgestellt oder akzeptiert hat: INativeImageINativeImageDependency INativeImageInstallInfo INativeImageEvaluate INativeImageConverter ICorModule IMetaDataConverter	Keine.

Zurück nach oben

Daten

In diesem Abschnitt werden Migrationsproblemen bei der Verwendung von Datasets und SQL-Clients, dem Entity Framework, LINQ to SQL und WCF Data Servers (früher bekannt als ADO.NET Data Services) beschrieben.