Migrationsprobleme in .NET Framework 4

In diesem Artikel werden Migrationsprobleme zwischen .NET Framework Version 3.5 Service Pack 1 und .NET Framework 4 beschrieben. Dabei werden auch Probleme aufgrund von Programmfehlerbehebungen, Änderungen zur Einhaltung von Standards und zur Gewährleistung der Sicherheit sowie Änderungen auf Grundlage von Kundenfeedback besprochen. Für die meisten dieser Änderungen sind keine Programmieränderungen in den Anwendungen erforderlich. Falls Änderungen erforderlich sind, finden Sie entsprechende Informationen in der Tabellenspalte Empfohlene Änderungen. Relevante Änderungen werden nach Bereich untergliedert, z.B. für ASP.NET und Windows Presentation Foundation (WPF).

Einen allgemeineren Überblick über die in diesem Artikel behandelten Probleme finden Sie im Leitfaden zur Migration zu .NET Framework 4.

Informationen zu neuen Features finden Sie unter Neuerungen 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 jetzt Informationen zu neuen und aktualisierten Browsern und Geräten. Ältere Browser und Geräte wie Netscape Navigator wurden entfernt und neuere Browser und Geräte wie Google Chrome und Apple iPhone hinzugefügt. Wenn Ihre Anwendung benutzerdefinierte Browserdefinitionen enthält, die von einer der entfernten Browserdefinitionen erben, wird ein Fehler angezeigt. Das HttpBrowserCapabilities-Objekt (von der Request.Browse-Eigenschaft der Seite verfügbar gemacht) wird durch die Browserdefinitionsdateien gesteuert. Aus diesem Grund können die Informationen, die durch den Zugriff 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 Ihre Anwendung auf den alten Browserdefinitionsdateien basiert, können Sie diese 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. Führen Sie nach dem Kopieren der Dateien das Befehlszeilentool Aspnet_regbrowsers.exe aus. Weitere Informationen finden Sie auf der Website https://www.asp.net/mobile.
Untergeordnete Anwendungen werden unter Mischversionen von ASP.NET ausgeführt	ASP.NET 4-Anwendungen, die als untergeordnete Anwendungen konfiguriert wurden, die frühere Versionen von ASP.NET ausführen, können möglicherweise aufgrund von Konfigurations- oder Kompilierungsfehlern nicht starten. Der genauen Fehler, der auftritt, hängt davon ab, ob die Anwendung unter IIS 6.0 oder unter IIS 7 oder IIS 7.5 ausgeführt wird.	An den Konfigurationsdateien der betroffenen Anwendungen lassen sich Änderungen vornehmen, damit das Konfigurationssystem die ASP.NET 4-Anwendung ordnungsgemäß erkennt. Informationen zu den Änderungen, die Sie vornehmen müssen, finden Sie auf der ASP.NET-Website im Dokument ASP.NET 4 Breaking Changes (Grundlegende Änderungen in ASP.NET 4 ) im Abschnitt „ASP.NET 4 Child Applications Fail to Start When Under ASP.NET 2.0 or ASP.NET 3.5 Applications“ (Untergeordnete ASP.NET 4-Anwendungen können unter ASP.NET 2.0 oder ASP.NET 3.5-Anwendungen nicht gestartet werden).
Änderungen an der ClientID	Mit der neuen clientIDMode-Einstellung in ASP.NET 4 haben Sie die Möglichkeit anzugeben, wie ASP.NET das id-Attribut für HTML-Elemente generiert. In früheren Versionen von ASP.NET entsprach das Standardverhalten der AutoID-Einstellung von clientIDMode. Die Standardeinstellung ist jetzt Predictable. Weitere Informationen finden Sie unter Steuerelementidentifikation in Web Forms.	Wenn Sie Ihre Anwendung mit Visual Studio 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 früherer Versionen von .NET Framework beibehält. Wenn Sie für eine Anwendung jedoch ein Upgrade durchführen, indem Sie .NET Framework 4 als Ziel für den Anwendungspool in IIS festlegen, verwendet ASP.NET standardmäßig den neuen Modus. Um den neuen Client-ID-Modus zu deaktivieren, fügen Sie die folgende Einstellung in der Datei „Web.config“ hinzu: <pages clientIDMode="AutoID" />
Codezugriffssicherheit (Code Access Security, CAS)	ASP.NET 2.0-Funktionen, die in ASP.NET 3.5 hinzugefügt wurden, verwenden das Codezugriffssicherheitsmodell (CAS) von .NET Framework 1.1 und .NET Framework 2.0. Die Implementierung von CAS wurde in ASP.NET 4 aber erheblich überholt. Daher können teilweise vertrauenswürdige ASP.NET-Anwendungen, die vertrauenswürdigen Code verwenden, der im globalen Assemblycache ausgeführt wird, mit verschiedenen Sicherheitsausnahmen Fehler auslösen. Teilweise vertrauenswürdige Anwendungen, die umfangreiche Änderungen an den CAS-Richtlinien des Computers verwenden, lösen möglicherweise auch Fehler und Sicherheitsausnahmen aus.	Sie können das Verhalten von teilweise vertrauenswürdigen ASP.NET 4-Anwendungen auf das von ASP.NET 1.1 und 2.0 zurücksetzen. Nutzen Sie dazu das neue legacyCasModel-Attribut im trust-Konfigurationselement, wie im folgenden Beispiel gezeigt: <trust level= "Medium" legacyCasModel="true" /> Wichtig: Eine Zurücksetzung auf ein älteres CAS-Modell bringt möglicherweise Sicherheitseinschränkungen mit sich. Weitere Informationen zu dem neuen ASP.NET 4-Modell für Codezugriffssicherheit finden Sie unter Codezugriffssicherheit für ASP.NET 4-Anwendungen.
Konfigurationsdateien	Die Stammkonfigurationsdateien für .NET Framework und ASP.NET 4 (die Datei „machine.config“ und die Stammdatei „Web.config“) wurden aktualisiert und enthalten jetzt die meisten Standardkonfigurationsinformationen aus den Web.config-Dateien in ASP.NET 3.5. Wegen der Komplexität von verwalteten IIS 7 und IIS 7.5-Konfigurationssystemen kann die Ausführung von ASP.NET 3.5-Anwendungen unter ASP.NET 4 sowie unter IIS 7 und IIS 7.5 entweder ASP.NET-Fehler oder IIS-Fehler hervorrufen.	Aktualisieren Sie ASP.NET 3.5-Anwendungen mithilfe der Upgrade-Tools für Projekte in Visual Studio 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. ASP.NET 3.5-Anwendungen lassen sich aber auch ohne Neukompilierung mit .NET Framework 4 ausführen. Dazu müssen Sie die Datei „Web.config“ der Anwendung möglicherweise manuell ändern, bevor die Anwendung unter .NET Framework 4 und IIS 7 oder IIS 7.5 ausgeführt wird. Die Änderung, die Sie vornehmen müssen, hängt von der Softwarekombination (einschließlich der Service Pack-Versionen (SP)) ab, mit der Sie arbeiten. Informationen zu den möglichen Softwarekombinationen, die dieser Änderung betroffen sind, finden Sie auf der ASP.NET-Website im Dokument ASP.NET 4 Breaking Changes im Abschnitt „Configuration Errors Related to New ASP.NET 4 Root Configuration“ (Konfigurationsfehler im Zusammenhang mit der neuen ASP.NET 4-Stammkonfiguration).
Rendern von Steuerelementen	In früheren Versionen von ASP.NET haben einige Steuerelemente Markup ausgegeben, das nicht deaktiviert werden konnte. Diese Art von Markup wird in ASP.NET 4 standardmäßig nicht mehr generiert. Die Renderingänderungen wirken sich auf die folgenden Steuerelemente aus: * Die Steuerelemente Image und ImageButton rendern das Attribut border="0" nicht mehr. * Die BaseValidator-Klasse und die Validierungssteuerelemente, die sich davon ableiten, rendern standardmäßig keinen rot formatierten Text mehr. * Das Steuerelement HtmlForm rendert kein name-Attribut. * Das Steuerelement Table rendert nicht mehr das Attribut border="0". Steuerelemente, die nicht für Benutzereingaben entworfen wurden (z.B. das Steuerelement Label), rendern nicht mehr das Attribut disabled="disabled", wenn ihre Enabled-Eigenschaftensatz auf false festgelegt ist (oder wenn sie diese Einstellung von einem Containersteuerelement erben).	Wenn Sie ein Upgrade Ihrer Anwendung mit Visual Studio von ASP.NET 2.0 oder ASP.NET 3.5 vornehmen, fügt das Tool der Datei „Web.config“ automatisch eine Einstellung hinzu, die das Legacyrendering beibehält. Wenn Sie für eine Anwendung jedoch ein Upgrade durchführen, indem Sie .NET Framework 4 als Ziel für den Anwendungspool in IIS festlegen, verwendet ASP.NET standardmäßig den neuen Renderingmodus. Um den neuen Renderingmodus zu deaktivieren, fügen Sie die folgende Einstellung in der Datei „Web.config“ hinzu: <pages controlRenderingCompatibilityVersion="3.5" />
Ereignishandler in Standarddokumenten	ASP.NET 4 rendert den action-Attributwert des HTML-Formularelements (form-Element) als eine leere Zeichenfolge, wenn eine Anforderung an eine URL ohne Erweiterung erfolgt, der ein Standarddokument zugeordnet wurde. In früheren Versionen von ASP.NET folgte aus einer Anforderung an http://contoso.com eine Anforderung an „Default.aspx“. In diesem Dokument wurde das öffnende form-Tag wie im folgenden Beispiel gerendert: <form action="Default.aspx" /> In ASP.NET 4 folgt aus einer Anforderung an http://contoso.com auch eine Anforderung an „Default.aspx“, allerdings rendert ASP.NET jetzt auch das öffnende HTML-form-Tag, wie im folgenden Beispiel gezeigt: <form action="" /> Wenn das action-Attribut eine leere Zeichenfolge ist, erstellt das IIS-DefaultDocumentModule-Objekt eine untergeordnete Anforderung an „Default.aspx“. In den meisten Situationen ist diese untergeordnete Anforderung für Anwendungscode transparent, und die Seite „Default.aspx“ wird normal ausgeführt. Allerdings kann eine mögliche Interaktion zwischen verwaltetem Code und IIS 7 oder IIS 7.5 im integrierten Modus dazu führen, dass verwaltete ASPX-Seiten während der untergeordnete Anforderung nicht mehr ordnungsgemäß ausgeführt werden. Unter den folgenden Umständen ruft die untergeordnete Anforderung an ein standardmäßiges ASPX-Dokument einen Fehler oder unerwartetes Verhalten hervor: * Eine ASPX-Seite wird an den Browser gesendet, wobei der action-Attributsatz des form-Elements auf "" festgelegt ist. * Das Formular wird an ASP.NET zurückgesendet. * Ein verwaltetes HTTP-Modul liest einen Teil des Einheitstextkörpers, z.B. Request.Form oder Request.Params. Aus diesem Grund wird der Einheitstextkörper der POST-Anforderung im verwalteten Arbeitsspeicher gelesen. Der Einheitstextkörper ist daher nicht mehr für native Codemodule verfügbar, die in IIS 7 oder IIS 7.5 im integrierten Modus ausgeführt werden. * Das IIS-DefaultDocumentModule-Objekt wird schließlich ausgeführt und erstellt eine untergeordnete Anforderung an das Dokument „Default.aspx“. Da der Einheitstextkörper bereits von verwaltetem Code gelesen wurde, kann kein Einheitstextkörper an die untergeordnete Anforderung gesendet werden. * 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 Einheitstextkörper verfügbar ist, gibt es auch keine Formularvariablen und keinen Ansichtszustand. Aus diesem Grund hat der ASPX-Seitenhandler keine Informationen dazu, welches Ereignis (sofern vorhanden) ausgelöst werden soll. Daher werden keine Postback-Ereignishandler für die betroffene ASPX-Seite ausgeführt.	Informationen zur Umgehung von Problemen, die aufgrund der Änderung auftreten können, finden Sie auf der ASP.NET-Website im Dokument ASP.NET 4 Breaking Changes unter „Event Handlers Might Not Be Not Raised in a Default Document in IIS 7 or IIS 7.5 Integrated Mode“ (Ereignishandler wird in einem Standarddokument im integrierten Modus in IIS 7 oder IIS 7.5 möglicherweise nicht ausgelöst).
Hashalgorithmus	ASP.NET verwendet sowohl Verschlüsselung als auch Hashalgorithmen, um Daten wie Formularauthentifizierungscookies und den Ansichtsstatus zu sichern. Bei Hashvorgängen für Cookies und den Ansichtszustand verwendet ASP.NET 4 standardmäßig den Algorithmus HMACSHA256. Frühere Versionen von ASP.NET haben die älteren Algorithmus HMACSHA1 verwendet.	Für Anwendungen, die ASP.NET 2.0 und ASP.NET 4 kombinieren und in denen Daten wie Formularauthentifizierungscookies in verschiedenen .NET Framework-Versionen unterstützt werden müssen, können Sie eine ASP.NET 4 Web-Anwendung mit dem älteren HMACSHA1-Algorithmus konfigurieren, indem Sie die folgende Einstellung in der Datei „Web.config“ hinzufügen: <machineKey validation="SHA1" />
Hosten von Steuerelementen in Internet Explorer	Windows Forms-Steuerelemente können nicht mehr in Internet Explorer gehostet werden, weil es bessere Lösungen für das Hosten von Steuerelementen im Web gibt. Daher wurden die Assemblys „IEHost.dll“ und „IEExec.exe“ aus .NET Framework entfernt.	Mithilfe der folgenden Technologien lassen sich Steuerelement in Webanwendungen benutzerdefiniert entwickeln: * Sie können eine Silverlight-Anwendung erstellen und sie so konfigurieren, dass sie außerhalb des Browsers ausgeführt wird. Weitere Informationen finden Sie unter Out-of-Browser Support (Out-of-Browser-Unterstützung). * Sie haben die Möglichkeit, eine XAML-Browseranwendung (XBAP) zu erstellen, um WPF-Funktionen zu nutzen (erfordert .NET Framework auf Clientcomputern). Weitere Informationen finden Sie unter Übersicht über WPF-XAML-Browseranwendungen.
Die Methoden „HtmlEncode“ und „UrlEncode“	Die Methoden HtmlEncode und UrlEncode der Klassen HttpUtility und HttpServerUtility wurden aktualisiert und codieren das einfache Anführungszeichen (') jetzt wie folgt: * Die Methode HtmlEncode codiert Instanzen von einfachen Anführungszeichen mit &#39;. * Die Methode UrlEncode codiert Instanzen von einfachen Anführungszeichen mit %27.	Überprüfen Sie Ihren Code auf die Methoden HtmlEncode und UrlEncode, und achten Sie darauf, dass die Änderung der Codierung keine Auswirkungen auf Ihre Anwendung hat.
HttpException-Fehler in ASP.NET 2.0-Anwendungen	Nachdem ASP.NET 4 für IIS 6 aktiviert wurde, generieren ASP.NET 2.0-Anwendungen, die auf IIS 6 (entweder unter Windows Server 2003 oder Windows Server 2003 R2) ausgeführt werden, möglicherweise Fehler wie den folgenden: System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.	* Wenn ASP.NET 4 nicht erforderlich ist, um die Website auszuführen, ordnen Sie die Website ASP.NET 2.0 neu zu. - oder - * Wenn ASP.NET 4 für die Ausführung 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 Erweiterung. Weitere Informationen finden Sie auf der ASP.NET-Website im Dokument ASP.NET 4 Breaking Changes unter „ASP.NET 2.0 Applications Might Generate HttpException Errors That Reference eurl.axd“ (ASP.NET 2.0-Anwendungen generieren möglicherweise HttpException-Fehler, die auf eurl.axd verweisen).
Mitgliedschaftstypen	Einige Typen (z.B. MembershipProvider) der ASP.NET-Mitgliedschaft wurden aus der Assembly „System.Web.dll“ in „System.Web.ApplicationServices.dll“ verschoben. So sollten architektonische Schichtabhängigkeiten zwischen Typen im Client und erweiterten .NET Framework-SKUs gelöst werden.	Klassenbibliotheken, die von früheren Versionen von ASP.NET upgegradet wurden und Mitgliedschaftstypen verwenden, die verschoben wurden, können in einem ASP.NET 4-Projekt möglicherweise nicht kompiliert werden. Wenn dies der Fall ist, fügen Sie im Klassenbibliotheksprojekt „System.Web.ApplicationServices.dll“ einen Verweis hinzu.
Änderungen an Menüsteuerelementen	Änderungen am Steuerelement Menu rufen das folgende Verhalten hervor: * Wenn MenuRenderingMode auf List festgelegt ist, oder wenn MenuRenderingMode auf Default und ControlRenderingCompatibilityVersion auf 4.0 oder höher festgelegt ist, hat die Eigenschaft PopOutImageUrl keine Auswirkungen. * Wenn der Pfad, der in den Eigenschaften StaticPopOutImageUrl und DynamicPopOutImageUrl festgelegt wird, einen umgekehrten Schrägstrich (\) enthält, werden die Bilder nicht gerendert. (In früheren Versionen von ASP.NET durfte der Pfad einen umgekehrten Schrägstrich enthalten.)	* Anstatt die Eigenschaft PopOutImageUrl für einzelne Menüelemente festzulegen, sollten Sie StaticPopOutImageUrl oder DynamicPopOutImageUrl des übergeordneten Menu-Steuerelements festlegen. - oder - Legen Sie MenuRenderingMode auf Table fest, oder legen Sie MenuRenderingMode auf Default und ControlRenderingCompatibilityVersion auf 3.5 fest. Aufgrund dieser Einstellungen verwendet das Menu-Steuerelement das tabellenbasierte HTML-Layout, das in früheren Versionen von ASP.NET verwendet wurde. * Wenn der Pfad in den Eigenschaften StaticPopOutImageUrl oder DynamicPopOutImageUrl einen umgekehrten Schrägstrich (\) enthält, ersetzen Sie ihn durch einen Schrägstrich (/).
Mobile Assembly in der Datei „Web.config“	In früheren Versionen von ASP.NET war unter system.web/compilation im Abschnitt assemblies in der Stammdatei „Web.config“ ein Verweis auf die Assembly „System.Web.Mobile.dll“ enthalten. Um die Leistung zu verbessern, wurde der Verweis auf diese Assembly entfernt. Hinweis: Die Assembly „System.Web.Mobile.dll“ und mobile ASP.NET-Steuerelemente sind in ASP.NET 4 enthalten, aber veraltet.	Wenn Sie die Typen aus dieser Assembly verwenden möchten, fügen Sie in der „Web.config“-Stammdatei oder in einer „Web.config“-Anwendungsdatei einen Verweis auf die Assembly hinzu.
Ausgabezwischenspeicherung	In ASP.NET 1.0 haben zwischengespeicherte Seiten, die Location="ServerAndClient" als Einstellung für die Ausgabezwischenspeicherung angegeben haben, aufgrund eines Fehlers einen Vary:*-HTTP-Header in der Antwort ausgegeben. So wurde Clientbrowsern mitgeteilt, dass Seiten nie lokal zwischengespeichert werden sollen. In ASP.NET Version 1.1 wurde die Methode SetOmitVaryStar hinzugefügt, um aufgerufen werden kann, um den Vary:*-Header zu unterdrücken. Allerdings legen Problemberichte nahe, dass Entwickler keine Kenntnis von dem SetOmitVaryStar-Verhalten haben. In ASP.NET 4 wird der Vary:*-HTTP-Header nicht mehr in Antworten ausgegeben, die folgende Anweisung angeben: <%@ OutputCache Location="ServerAndClient" %> Daher wird die Methode SetOmitVaryStar nicht mehr benötigt, um den Vary:*-Header zu unterdrücken. In Anwendungen, die für das Location-Attribut „ServerAndClient“ angeben, können Seiten im Browser zwischengespeichert werden, ohne dass SetOmitVaryStar aufgerufen werden muss.	Wenn Seiten in der Anwendung Vary:* ausgeben müssen, rufen Sie die Methode AppendHeader wie im folgenden Beispiel dargestellt auf: System.Web.HttpResponse.AppendHeader("Vary","*"); Alternativ können Sie den Wert des Location-Attribut der Ausgabezwischenspeicherung in „Server“ ändern.
Seitenanalyse	Der Seitenparser für ASP.NET-Webseiten (ASPX-Dateien) und -Benutzersteuerelemente (ASCX-Dateien) ist in ASP.NET 4 strenger und kennzeichnet mehr Markup als in früheren Versionen als ungültig als in früheren Versionen.	Nehmen wir z.B. die Fehlermeldungen, die bei der Ausführung einer Seite erstellt werden, und Fehler, die von ungültigem Markup hervorgerufen werden.
Passport-Typen	Die in ASP.NET 2.0 integrierte Unterstützung für Passport ist veraltet und aufgrund von Änderungen in Passport (jetzt Live ID SDK) wird die Unterstützung nicht weitergeführt. Daher werden die Typen im Zusammenhang mit Passport in System.Web.Security jetzt mit dem ObsoleteAttribute-Attribut markiert.	Ändern Sie jeglichen Code, der Passport-Typen im System.Web.Security-Namespace verwendet (beispielsweise PassportIdentity), um das Windows Live ID SDK zu verwenden.
PathInfo-Informationen in der FilePath-Eigenschaft	In ASP.NET 4 ist der PathInfo-Wert nicht mehr in den Rückgabewerten von Eigenschaften wie FilePath, AppRelativeCurrentExecutionFilePath und CurrentExecutionFilePath enthalten. Die PathInfo-Informationen sind stattdessen in PathInfo verfügbar. Nehmen wir z.B. das folgenden URL-Fragment: /testapp/Action.mvc/SomeAction In früheren Versionen von ASP.NET hatten HttpRequest-Eigenschaften die folgenden Werte: * FilePath: /testapp/Action.mvc/SomeAction * PathInfo: (leer) In ASP.NET 4 haben HttpRequest-Eigenschaften stattdessen die folgenden Werte: * FilePath: /testapp/Action.mvc * PathInfo: SomeAction	Prüfen Sie den Code darauf, ob Eigenschaften der HttpRequest-Klasse verwendet werden, um Pfadinformationen zurückgeben. Ändern Sie ggf. im Code die Art und Weise, wie Pfadinformationen zurückgegeben werden.
Anforderungsvalidierung	Um die Anforderungsvalidierung zu verbessern, wird die ASP.NET-Anforderungsvalidierung früher im Lebenszyklus aufgerufen. Daher wird die Anforderungsvalidierung für Anforderungen ausgeführt, die nicht an ASPX-Dateien gerichtet sind, z.B. für Aufrufe des Webdiensts und benutzerdefinierte Handler. Die Anforderungsvalidierung wird auch aktiv, wenn benutzerdefinierte HTTP-Module in der Pipeline zur Anforderungsverarbeitung ausgeführt werden. Aufgrund der Änderung lösen Anforderungen von anderen Ressourcen als ASPX-Dateien unter Umständen Anforderungsvalidierungsfehler aus. Benutzerdefinierter Code, der in der Anforderungspipeline ausgeführt wird (z.B. benutzerdefinierte HTTP-Module), kann auch Anforderungsvalidierungsfehler auslösen.	Bei Bedarf können Sie das alte Verhalten wiederherstellen, bei dem nur ASPX-Seiten die Anforderungsvalidierung mithilfe der folgenden Einstellung in der Webkonfigurationsdatei auslösen: <httpRuntime requestValidationMode="2.0" /> Warnung: Wenn Sie das alte Verhalten wiederherstellen, vergewissern Sie sich, dass der gesamte Code im vorhandenen Handler, in Modulen und in anderem benutzerdefinierten Code auf potenziell unsichere HTTP-Eingaben prüft, die XSS-Angriffsvektor sein können.
Routing	Wenn Sie eine Dateisystemwebsite in Visual Studio 2010 erstellen und die Website sich in einen Ordner mit einem Punkt (.) im Ordnernamen befindet, funktioniert das URL-Routing nicht zuverlässig. Einige virtuelle Pfade geben einen HTTP 404-Fehler zurück. Dies tritt auf, weil Visual Studio 2010 den Visual Studio Development Server mit einem falschen Pfad für das virtuelle Stammverzeichnis startet.	* Ändern Sie auf der Seite Eigenschaften für die dateibasierte Website das Attribut Virtueller Pfad auf „/“. - oder - * Erstellen Sie ein Webanwendungsprojekt statt eines Websiteprojekts. In Webanwendungsprojekten tritt dieses Problem nicht auf, und das URL-Routing funktioniert, selbst wenn der Name des Projektordners einen Punkt enthält. - oder - * Erstellen Sie eine in IIS gehostete, HTTP-basierte-Website. Die virtuellen Pfade und Projektdateiordner können bei in IIS-gehosteten Websites auch Punkte enthalten.
SharePoint-Websites	Wenn Sie versuchen, eine ASP.NET 4-Website auszuführen, die als untergeordnetes Element einer SharePoint-Website bereitgestellt wird, die eine benutzerdefinierte, partielle Vertrauensebene namens WSS_Minimal enthält, wird die folgende Fehlermeldung angezeigt: Could not find permission set named 'ASP.Net'.	Derzeit sind keine Versionen von SharePoint mit ASP.NET kompatibel. Daher sollten Sie nicht versuchen, eine ASP.NET 4-Website als untergeordnetes Element einer SharePoint-Website auszuführen.
XHTML 1.1-Standards	Damit neue Websites mit XHTML 1.1 kompatibel sind, generieren die ASP.NET-Steuerelemente in .NET Framework 4 XHTML 1.1-kompatibles HTML. Dieses Rendering wird mit der folgenden Option in der Datei „Web.config“ innerhalb der <system.Web>-Elements aktiviert: <pages controlRenderingCompatibilityVersion="4.0"/> Diese Option ist standardmäßig auf 4.0 festgelegt. In Webprojekten, für die ein Upgrade von Visual Studio 2008 ausgeführt wurde, ist die 3.5-Einstellung aus Kompatibilitätsgründen aktiviert.	Keine

Kernspeicher

Allgemeine Funktionen

Funktion	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
CardSpace	Windows CardSpace ist nicht mehr in .NET Framework enthalten, sondern wird getrennt bereitgestellt.	Sie können CardSpace im Microsoft Download Center herunterladen.
Konfigurationsdateien	Es wurden Korrekturen am Zugriff von .NET Framework auf Anwendungskonfigurationsdateien vorgenommen.	Wenn Ihre Anwendungskonfigurationsdatei application-name.config heißt, benennen Sie sie in application-name.exe.config um. Benennen Sie MyApp.config z.B. in MyApp.exe.config um.
C#-Codecompiler	Die Klassen Compiler, CompilerError und ErrorLevel aus dem Microsoft.CSharp-Namespace sind nicht mehr verfügbar, und die zugehörige Assembly (cscompmgd.dll) ist nicht mehr in .NET Framework enthalten.	Verwenden Sie stattdessen die CodeDomProvider-Klasse und andere Klassen im System.CodeDom.Compiler-Namespace. Weitere Informationen finden Sie unter Verwenden von CodeDOM.
Hosting (nicht verwaltete API)	Um die Hostingfunktionen zu verbessern, wurden einige der Hosting-Aktivierungs-APIs als veraltet gekennzeichnet. Funktionen zur parallelen In-Process-Ausführung ermöglichen es Anwendungen, mehrere Versionen von .NET Framework im selben Prozess zu laden und zu starten. Sie haben z. B. die Möglichkeit, Anwendungen auszuführen, die auf .NET Framework 2.0 SP1 und auf .NET Framework 4 basierende Add-Ins (oder Komponenten) im selben Prozess laden. Ältere Komponenten verwenden weiterhin die ältere Version von .NET Framework, während neue Komponenten die neue Version verwenden.	Verwenden Sie die unter Parallele In-Process-Ausführung beschriebene Konfigurationen.
Neues Sicherheitsmodell	Die Codezugriffssicherheitsrichtlinie wurde deaktiviert und durch ein vereinfachtes Modell ersetzt, wie in Änderungen der Sicherheit in .NET Framework 4 beschrieben.	Wenn Sie in Ihren Anwendungen von CAS abhängen, sind Änderungen unter Umständen erforderlich. Weitere Informationen finden Sie unter Kompatibilität und Migration von Richtlinien für die Codezugriffssicherheit.

Datum und Uhrzeit

Namespace: System

Assembly: mscorlib (in „mscorlib.dll“)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Sommerzeit	Um Abweichungen von der Systemuhr zu vermeiden, verwenden Zeiteigenschaften (wie Local und Now) nun Betriebssystemregeln anstelle von anderen .NET Framework-Daten für Vorgänge hinsichtlich Sommerzeit.	Keine
Formatierungszeichenfolge	Um die kulturabhängige Formatierung zu unterstützen, enthält die TimeSpan-Struktur neue Überladungen der Methoden ToString, Parse und TryParse sowie ParseExact und TryParseExact.	Keine

Globalisierung

Eine Liste der neuen neutralen und spezifischen Kulturen finden Sie unter Neues bei der Globalisierung und Lokalisierung.

Namespace: System.Globalization

Assembly: mscorlib (in „mscorlib.dll“)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Namen von Kulturen	Die folgenden Namensänderungen wirken sich auf die deutsch- und Divehi-sprachigen sowie auf die afrikanischen 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 für die ethnische Gruppe „Divehi“ (Malediven) (dv-MV) wurde von „dd/MMMM/yyyy“ in „dd/MM/yyyy“ geändert. * PMDesignator: Der PM-Kennzeichner der Kultur „Afrikaans (Südafrika)“ wurde von „nm“ in „PM“ geändert.	Beachten Sie die Namensänderungen für Kulturen.
LICD-Parameter	Damit das erwartete Verhalten in den Einstellungen des Automatisierungsserver auftritt, übergibt die CLR die aktuelle Kultur für den LCID-Parameter nicht mehr an nicht verwaltete COM-basierte Anwendungen. Stattdessen wird 1033 (en-US) für die Kultur übergeben.	Mit Ausnahme der nativen Anwendungen, die eine angegebene Kultur erfordern,sind keine Änderungen erforderlich.
Veraltete Kulturtypen	Die Kulturtypen CultureTypes und CultureTypes sind jetzt veraltet. Aus Gründen der Abwärtskompatibilität gibt CultureTypes jetzt neutrale und spezifische Kulturen zurück, die in früheren .NET Framework-Versionen enthalten waren, und CultureTypes gibt jetzt eine leere Liste zurück.	Verwenden Sie andere Werte der CultureTypes-Enumeration.
Abrufen einer Kultur	Ab Windows 7 ruft .NET Framework 4 Kulturinformationen vom Betriebssystem ab, anstatt die Daten selbst zu speichern. Darüber hinaus synchronisiert .NET Framework die Sortierung und Groß-/Kleinschreibung von Daten mit Windows.	Keine
Unicode 5.1-Standards	.NET Framework unterstützt jetzt alle Unicode 5.1-Zeichen, d. h. ungefähr 1.400 zusätzliche Zeichen. Diese Zeichen umfassen neue Symbole, Pfeile, diakritische Zeichen, Satzzeichen, mathematische Symbolen, CJK-Querstriche und -Ideogramme, zusätzliche numerische Zeichen aus dem Malaiischen und Telugu sowie verschiedene myanmarische, lateinische, arabische, griechische, mongolische und kyrillische Zeichen. Die folgenden neuen Skripts werden mit Unicode 5.1 unterstützt: Sudanesisch, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Odia, Tamil, Telugu, Cham und malaiische Zeichen.	Keine

Ausnahmen

Namespaces: System, System.Runtime.ExceptionServices

Assembly: mscorlib (in „mscorlib.dll“)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Ausnahmen für beschädigte Prozessstatus	Die CLR übergibt keine Ausnahmen mehr für beschädigte Prozessstatus an Ausnahmehandler in verwaltetem Code.	Diese Ausnahmen deuten darauf hin, dass der Status eines Prozesses beschädigt wurde. Eine Ausführung Ihrer Anwendung in diesem Zustand ist nicht empfehlenswert. Weitere Informationen finden Sie unter HandleProcessCorruptedStateExceptionsAttribute und im Eintrag Handling Corrupted State Exceptions (Behandeln beschädigter Statusausnahmen) im MSDN-Magazin.
Ausnahmen der Ausführungs-Engine	ExecutionEngineException ist jetzt veraltet, da der Prozess aufgrund einer abfangbaren Ausnahme weiterhin ausgeführt wird. Diese Änderung verbessert die Vorhersagbarkeit und Zuverlässigkeit in der Laufzeit.	Verwenden Sie InvalidOperationException, um die Bedingung zu signalisieren.

Spiegelung

Namespace: System.Reflection

Assembly: mscorlib (in „mscorlib.dll“)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Assembly-Hashalgorithmen	Die Eigenschaft HashAlgorithm gibt jetzt AssemblyHashAlgorithm 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 für eine Assembly, auf die verwiesen wird, z.B. die von der GetReferencedAssemblies-Methode zurückgegebene.)	Keine
Laden von Assemblys	Um das redundante Laden von Assemblys zu vermeiden und den virtuellen Adressraum zu speichern, lädt die CLR nun Assemblys nur mit der Win32-MapViewOfFile-Funktion. Die LoadLibrary-Funktion wird nicht mehr zusätzlich aufgerufen. Diese Änderung betrifft Diagnoseanwendungen auf die folgende Art und Weise: * ProcessModuleCollection enthält keine Module aus einer Klassenbibliothek (DLL-Datei) mehr, wie aus 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 Eigenschaft DeclaringType gibt jetzt ordnungsgemäß NULL zurück, wenn der Typ keinen deklarierenden Typ hat.	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 Assemblycaches	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 bleiben 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 mit der Funktion GetCachePath ab.	Keine, vorausgesetzt dass Anwendungen keine expliziten Pfade zu Assemblys verwenden (nicht empfohlen)
Globaler Assemblycache (Tool)	Gacutil.exe (Global Assembly Cache-Tool) unterstützt den Shell-Plug-In-Viewer nicht mehr.	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 des pBufferLengthOffset-Parameters für die ICorProfilerInfo2::GetStringLayout-Methode geändert und entspricht jetzt 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 alle Abhängigkeiten von der Pufferlänge.
JIT-Debuggen	Um die Registrierung für das Just-in-Time-Debuggen (JIT) zu vereinfachen, verwendet der .NET Framework-Debugger jetzt nur den AeDebug-Registrierungsschlüssel, der das JIT-Debuggingverhalten für nativen Code steuert. Diese Änderung hat folgende Auswirkungen: * Sie können keine zwei verschiedenen Debugger mehr für verwalteten und nativen Code registrieren. * Sie können den Debugger nicht mehr automatisch bei einem nicht interaktiven Prozess starten. Sie können Benutzer aber zu einem interaktiven Prozess auffordern. * Sie werden nicht mehr benachrichtigt, wenn der Debugger nicht gestartet werden kann oder wenn es ist keinen registrierten Debugger gibt, der gestartet werden soll. * Automatisch gestartete Richtlinien, die von der Interaktivität von der Anwendung abhängig sind, werden nicht mehr unterstützt.	Passen Sie Debuggingvorgänge nach Bedarf an.
Plattformaufruf	Um die Leistung der Interoperabilität mit nicht verwaltetem Code zu verbessern, rufen falsche Aufrufkonventionen bei einem Plattformaufruf jetzt einen Fehler in der Anwendung hervor. In früheren Versionen behoben hat die Marshalling-Ebene diese Fehler im Stapel gelöst.	Beim Debuggen Ihrer Anwendungen in Microsoft Visual Studio werden Sie auf diese Fehler aufmerksam gemacht, damit Sie sie korrigieren können. Bei nicht aktualisierbaren Binärdateien kann das <NetFx40_PInvokeStackResilience>-Element in der Anwendungskonfigurationsdatei einschließen, damit aufrufende Fehler im Stapel wie in früheren Versionen gelöst werden können. Allerdings kann dies auf die Leistung Ihrer Anwendung auswirken.
Entfernte Schnittstellen (nicht verwaltete API)	Um Verwirrung bei den Entwicklern zu vermeiden, wurden die folgenden Schnittstellen entfernt, da sie keine nützlichen Szenarios bereitstellen und die CLR keine Implementierung bereitgestellt oder übernommen hat: * INativeImageINativeImageDependency * INativeImageInstallInfo * INativeImageEvaluate * INativeImageConverter * ICorModule * IMetaDataConverter	Keine

Daten

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

Dataset und SQL Client

Die folgende Tabelle beschreibt die verbesserten Funktionen, die zuvor Einschränkungen oder andere Probleme hatten.

Namespaces: System.Data, System.Data.Objects.DataClasses, System.Data.SqlClient

Assemblys: System.Data (in „System.Data.dll“), System.Data.Entity (in „System.Data.Entity.dll“)

Feature	Unterschiede zu 3.5 SP1
POCO-Szenarios	Die IRelatedEnd-Schnittstelle verfügt über neue Methoden, um die Benutzerfreundlichkeit in Plain Old CLR Object-Szenarios (POCO) zu verbessern. Diese neuen Methoden akzeptiert ein Object statt einer IEntityWithRelationships-Entität als Parameter.
Bearbeiten von Zeilen	Die IndexOf-Methode, wie von der DataView-Klasse implementiert, gibt den Wert einer bearbeiteten Zeile jetzt richtig zurück, statt -1 zurückzugeben.
Ereignisse	Das PropertyChanged-Ereignis wird jetzt ausgelöst, wenn sich eine Zeile in einem geänderten Zustand befindet und die RejectChanges-Methode aufgerufen wird. Diese Änderung erleichtert es, Benutzeroberflächen-Steuerelemente zu erstellen, die den Inhalt eines DataSet-Objekts verfügbar machen.
Ausnahmen	Die Prepare-Methode löst jetzt statt einer NullReferenceException eine InvalidOperationException aus, wenn eine Verbindung nicht festgelegt oder offen ist.
Zuordnen von Ansichten	Zuordnungsfehler in der Abfrageansicht werden jetzt zur Entwurfszeit abgefangen, statt zur Laufzeit eine NullReferenceException auszulösen. Die Zuordnungsvalidierung fängt den Fehler jetzt ab, bei dem zwei Zurodnungssätze in konzeptionelle Schemadefinitionssprache (CSDL) der gleichen Spalte zugeordnet sind.
Transaktionen	Wenn eine Anwendung versucht, eine Anweisung für eine Verbindung auszuführen, nachdem eine Transaktion abgeschlossen wurde (einschließlich Abbruch oder Rollback zurück), wird jetzt eine InvalidOperationException ausgelöst. In Vorgängerversionen wurde keine Ausnahme ausgelöst, und Sie konnten zusätzliche Befehle ausführen, auch wenn eine Transaktion abgebrochen wurde.

Entity Framework

Die folgende Tabelle beschreibt die verbesserten Funktionen, die zuvor Einschränkungen oder andere Probleme hatten.

Namespaces: System.Data, System.Data.Objects, System.Data.Objects.DataClasses

Assemblys: System.Data.Entity (in „System.Data.Entity.dll“)

Feature	Unterschiede zu 3.5 SP1
Entitätsobjekte	Es gibt nun Parität zwischen der Detach-Methode und der Status des Entitätsobjekts, wenn der SaveChanges-Methode aufgerufen wird. Diese verbesserte Konsistenz verhindert, dass unerwartete Ausnahmen ausgelöst werden.
Entity SQL	Die Regeln für die Auflösung von Bezeichnern in Entity SQL wurden verbessert. Die Logik des Entity SQL-Parsers wurde für das Auflösen von mehrteiligen Bezeichnern verbessert.
Strukturelle Anmerkungen	Das Entity Framework erkennt jetzt strukturelle Anmerkungen.
Abfragen	Die folgenden Verbesserungen wurden in Abfragen vorgenommen: * Eine GroupBy-Abfrage, die einen NULL-Schlüssel statt einer leeren Auflistung verwendet, wird keine Zeilen zurückgeben, unabhängig davon, ob in der Abfrage zusätzliche SELECT-Anweisungen vorhanden sind. * Generierte SQL in LINQ- und Entity SQL-Abfragen behandeln Zeichenfolgenparameter jetzt standardmäßig als Nicht-Unicode-Werte.

LINQ to SQL

Die folgende Tabelle beschreibt die verbesserten Funktionen, die zuvor Einschränkungen oder andere Probleme hatten.

Namespace: System.Data.Linq

Assembly: System.Data.Linq (in „System.Data.Linq.dll“)

Feature	Unterschiede zu 3.5 SP1
Ereignisse	Eine EntitySet<TEntity>-Sammlung löst jetzt das Ereignis ListChanged für die Vorgänge „Hinzufügen“ und „Entfernen“ aus, wenn EntitySet<TEntity> entladen und die Sammlung geladen wird.
Abfragen	Skip(0) wird in LINQ to SQL-Abfragen nicht mehr ignoriert. Abfragen, die diese Methode verwenden, können sich daher anders verhalten. In einigen Fällen ist eine OrderBy-Klausel mit Skip(0) erforderlich, und die Abfrage löst jetzt eine NotSupportedException-Ausnahme aus, wenn die OrderBy-Klausel nicht enthalten war.

WCF Data Services

Die folgende Tabelle beschreibt die verbesserten Funktionen, die zuvor Einschränkungen oder andere Probleme hatten.

Namespaces: System.Data.Services, System.Data.Services.Client, System.Data.Services.Common, System.Data.Services.Providers

Assemblys: System.Data.Services (in „System.Data.Services.dll“), System.Data.Services.Client (in „System.Data.Services.Client.dll“)

Feature	Unterschiede zu 3.5 SP1
Binärer Batchinhalt	WCF Data Services unterstützt jetzt binären Batchinhalt in Anforderungen und-Antworten.
Change-Interceptors	Change-Interceptors werden nun für eine DELETE-Anforderung ausgeführt. Ein Change-Interceptor ist eine Methode, die immer ausgeführt wird, wenn der Server die Anforderung empfängt, eine Entität in der Entitätenmenge zu ändern. Er wird ausgeführt, bevor die eingehende Anforderung ausgeführt wird. Der Change-Interceptor ermöglicht den Zugriff auf die Entität, die geändert wird, und den Vorgang, der ausgeführt wird.
Ausnahmen	Die folgenden Bedingungen lösen nun nützlichere Ausnahmen statt einer NullReferenceException aus: * Eine TimeoutException, wenn beim Aufruf eines Datendiensts ein Timeout eintritt. * Eine DataServiceRequestException, wenn eine ungültige Anforderung an einen Datendienst erfolgt. Sie sollten in Ihren Anwendungen die Behandlung von Ausnahmen ändern, um die neue Ausnahmen abzufangen.
Header	Die folgenden Verbesserungen wurden in Headern vorgenommen: * WCF Data Services lehnt einen eTag-Header, der einen nicht angegebenen Wert enthält, nun ordnungsgemäß ab. * WCF Data Services gibt nun einen Fehler zurück und führt die Anforderung für eine DELETE-Anforderung zu einem Link nicht aus, wenn die Anforderung einen if-* Header enthält. * WCF Data Services gibt nun an den Client einen Fehler im Format (Atom, JSON) zurück, das der Client im Accept-Header angegeben hat.
JSON-Reader	Der JavaScript Object Notation-Reader (JSON) gibt jetzt beim Lesen ordnungsgemäß einen Fehler zurück, wenn beim Verarbeiten von JSON-Nutzlasten, die an einen WCF Data Service gesendet wurden, ein einzelnes Escapezeichen, d. h. der umgekehrter Schrägstrich („\“) gelesen wird.
Merges	Die folgenden Verbesserungen wurden an der MergeOption-Enumeration vorgenommen: * Die Mergeoption MergeOption ändert als Ergebnis einer nachfolgenden Antwort von einem Datendienst nicht mehr die Entität auf dem Client. * Die Option MergeOption stimmt jetzt in dynamischen SQL-Anweisungen und in auf gespeicherten Prozeduren basierenden Updates überein.
Anforderungen	Die Methode OnStartProcessingRequest wird jetzt aufgerufen, bevor eine Anforderung an Datendienste verarbeitet wird. Dadurch funktioniert die Anforderung ordnungsgemäß für ServiceOperation-Dienste.
Streams	WCF Data Services schließt nicht mehr den zugrunde liegenden Stream für Lese- und Schreibvorgänge.
URIs	Escapevorgänge des WCF Data Services-Clients für URIs wurde korrigiert.

Windows Communication Foundation (WCF)

Die folgende Tabelle beschreibt die verbesserten Funktionen, die zuvor Einschränkungen oder andere Probleme hatten.

Feature	Unterschiede zu 3.5 SP1
Konfigurationsdateien	Um die Vererbung von Verhalten über die Hierarchie der Konfigurationsdatei zu aktivieren, unterstützt WCF jetzt das konfigurationsdateiübergreifende Zusammenführen. Das Vererbungsmodell für die Konfiguration wurde erweitert, sodass Benutzer Verhalten definieren können, die auf alle Dienste auf dem Computer angewendet werden. Es kann zu Verhaltensänderungen kommen, wenn es auf unterschiedlichen Hierarchieebenen Verhalten mit demselben Namen gibt.
Diensthosting	Sie können das Konfigurationselement <serviceHostingEnvironment> nicht mehr auf Dienstebene angeben, indem Sie der Elementdefinition das Attribut allowDefinition="MachineToApplication" hinzufügen. Das Element <serviceHostingEnvironment> auf Dienstebene anzugeben, ist technisch falsch und führt zu inkonsistentem Verhalten.

Windows Presentation Foundation (WPF)

Anwendungen

Namespaces: System.Windows, System.Windows.Controls

Assemblys: PresentationFramework (in „PresentationFramework.dll“)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Ausnahmebehandlung	Damit Fehler früher erkannt werden können, löst WPF eine TargetInvocationException aus und legt die Eigenschaft InnerException auf kritische Ausnahmen wie NullReferenceException, OutOfMemoryException, StackOverflowException und SecurityException fest, anstatt die ursprüngliche Ausnahme abzufangen.	Keine
Verknüpfte Ressourcen	Um das Verknüpfen zu vereinfachen, verwenden Ressourcendateien (z.B. Images), die sich an einem anderen Speicherort als der Ordnerstruktur des Projekts befinden, bei der Erstellung der Anwendung den vollständigen Pfad der Ressourcendatei anstelle des Dateinamens als Ressourcen-ID. So kann die Anwendung die Dateien zur Laufzeit finden.	Keine
Teilweise vertrauenswürdige Anwendungen	Aus Sicherheitsgründen lösen Windows-basierte, teilweise vertrauenswürdige Anwendungen, die die Steuerelemente WebBrowser oder Frame mit HTML enthalten, bei der Erstellung des Steuerelements eine SecurityException aus. Browseranwendungen lösen eine Ausnahme aus und zeigen eine Meldung an, wenn alle der folgenden Bedingungen erfüllt sind: Die Anwendung wird in Firefox ausgeführt. * Die teilweise vertrauenswürdige Anwendung wird in der Internetzone von nicht vertrauenswürdigen Standorten ausgeführt. * Die Anwendung enthält die Steuerelemente WebBrowser oder Frame, die HTML enthalten. Anwendungen, die an vertrauenswürdigen Standorten oder in der Intranetzone ausgeführt werden, sind nicht betroffen.	Sie können die Auswirkungen dieser Änderung in Ihren Browseranwendungen wie folgt abschwächen: * Führen Sie die Browseranwendung als voll vertrauenswürdig aus. * Fordern Sie Ihre Kunden auf, den Standort der Anwendung der Zone der vertrauenswürdigen Standorte hinzuzufügen.
Ressourcenverzeichnisse	Um Ressourcenverzeichnis auf der Designebene zu verbessern und zu verhindern, dass sie geändert werden, werden sperrbare Ressourcen, die in einem Ressourcenverzeichnis definiert und in ein Verzeichnis auf der Designebene zusammengeführt wurden, jetzt immer als gesperrt markiert und sind damit unveränderlich. Dies ist das erwartete Verhalten von sperrbaren Ressourcen.	Anwendungen, die eine in einem zusammengeführten Verzeichnis auf der Designebene definierte Ressource ändern, sollten die Ressource klonen und die geklonte Kopie ändern. Alternativ haben Sie die Möglichkeit, die Ressource als x:Shared="false" zu kennzeichnen, damit ResourceDictionary bei jeder Abfrage der Ressource eine neue Kopie erstellt.
Windows 7	Damit WPF-Anwendungen besser unter Windows 7 funktionieren, wurden die folgenden Verbesserungen vorgenommen, um das Verhalten eines Fensters zu korrigieren: * Zustände beim Andocken und bei Gesten funktionieren jetzt wie entsprechend der Benutzerinteraktionen erwartet. * Die Taskleistenbefehle Überlappend, Fenster gestapelt anzeigen und Show windows side-by-side (Fenster nebeneinander anzeigen) haben jetzt haben das richtige Verhalten und aktualisieren die richtigen Eigenschaften. * Die Eigenschaften Top, Left, Width und Height für maximierte oder minimierte Fenster enthalten jetzt, je nach Monitor, den richtigen Wiederherstellungsort des Fensters statt anderer Werte.	Keine
Fensteranordnung und -transparenz	Wenn Sie versuchen, WindowStyle auf einen anderen Wert als WindowStyle festzulegen, wenn AllowsTransparencytrue und WindowState sich selbst, also WindowState entspricht, wird InvalidOperationException ausgelöst.	Wenn Sie WindowStyle ändern müssen und AllowsTransparencytrue entspricht, können Sie die Win32-SetWindowLongPtr-Funktion aufrufen.
XPS-Viewer	WPF enthält das Microsoft XML Paper Specification Essentials Pack (XPSEP) nicht. XPSEP nur ist im Lieferumfang von Windows 7 und Windows Vista enthalten. Auf einem Computer unter Windows XP, auf dem .NET Framework 3.5 SP1 nicht installiert ist, wird für das Drucken über eine andere WPF-API als der in PrintDialog WINSPOOL verwendet. Einige Funktionen des Druckers werden nicht gemeldet, und einige Druckereinstellungen werden nicht während des Druckens angewendet.	Installieren Sie bei Bedarf das Microsoft XML Paper Specification Essentials Pack.

Steuerelemente

Namespaces: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input

Assemblys: PresentationFramework (in „PresentationFramework.dll“), PresentationCore (in „PresentationCore.dll“), WindowsBase (in „WindowsBase.dll“)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Dialogfelder	Zur Verbesserung der Zuverlässigkeit wird die Methode ShowDialog im gleichen Thread aufgerufen, der erstellt das FileDialog-Steuerelement erstellt hat.	Achten Sie darauf, ein FileDialog-Steuerelement zu erstellen, und rufen Sie die Methode ShowDialog im gleichen Thread auf.
Unverankerte Fenster	Um die Logik für die Fokuswiederherstellung zu beheben, die fälschlicherweise kontinuierlich ein unverankertes Fenster reaktiviert (und es wie ein modales Dialogfeld anzeigt), wird sie jetzt an der Wiederherstellung gehindert, wenn der Kandidat kein untergeordnetes Element des Fensters ist.	Keine
Elemente in Auflistungen	Wenn ein Element verschoben oder einer zugrunde liegenden Auflistung hinzugefügt wird, erscheint es in CollectionView am gleichen relativen Speicherort, wenn CollectionView nicht sortiert ist. So wird die Konsistenz zwischen der Position des Elements in der Auflistung und der zugeordneten CollectionView gewahrt.	Verwenden Sie bei der Suche nach dem Speicherort eines Elements in einer CollectionView statt einer festen Position die Methoden ContainerFromItem oder IndexOf.
Layouts	Um unnötiges erneutes Anordnen zu vermeiden, setzt das Ändern von ShowsNavigationUI nicht mehr das Layout außer Kraft und ruft keinen weiteren Layoutdurchlauf hervor.	Wenn Sie davon ausgehen, dass Änderungen an ShowsNavigationUI zu einem weiteren Layoutdurchlauf führen, rufen Sie nach dem Festlegen der Eigenschaft InvalidateVisual auf.
Menüs	Um ClearType-Text in Menü-Popupelementen zu aktivieren, wurden Änderungen an der ControlTemplate-Klasse, dem MenuItem-Steuerelement und anderen Steuerelementen vorgenommen.	Anwendungen sollten nicht die visuelle Struktur von Steuerelementvorlagen verwenden. Nur benannte Teile einer ControlTemplate sind Teil des öffentlichen Vertrags. Wenn eine Anwendung ein bestimmtes Objekt in einer ControlTemplate suchen muss, suchen Sie in der visuellen Struktur nach einem bestimmten Typ statt nach einer festen Position eines Objekts in der Struktur.
Navigation	Wenn ein Frame direkt zu einem Speicherort navigiert, entspricht die Eigenschaft IsNavigationInitiator nach der ursprünglichen Navigation true. Diese Änderung verhindert, dass während Startszenarios zusätzliche Ereignisse ausgelöst werden.	Keine
Popupelemente	Der Delegat CustomPopupPlacementCallback kann jetzt während einem Layoutdurchlauf mehrfach aufgerufen werden, statt nur einmal.	Wenn Ihr CustomPopupPlacementCallback-Delegat die Position von einem Popup auf Grundlage seiner vorherigen Position berechnet, berechnen Sie die Position nur neu, wenn sich die Werte der Parameter popupSize, targetSize oder offset ändern.
Eigenschaftswerte	Mit der Methode SetCurrentValue lässt sich nun eine Eigenschaft auf einen effektiven Wert festlegen, obwohl auch weiterhin alle Bindungen, Stile oder Trigger berücksichtigt werden, die sich auf die Eigenschaft auswirken.	Autoren von Steuerelementen sollten immer dann SetCurrentValue verwenden, wenn sich der Eigenschaftswert infolge einer anderen Aktion wie der Bearbeitung durch Benutzer ändert.
Textfelder	Aus Sicherheitsgründen schlagen die Methoden Copy und Cut ohne Meldung fehl, wenn sie bei partieller Vertrauenswürdigkeit aufgerufen werden. Darüber hinaus wird die programmgesteuerte Ausführung der Eigenschaften Copy oder Cut für ein Steuerelement, das von TextBoxBase erbt, bei partieller Vertrauenswürdigkeit blockiert. Die von Benutzern initiierten Befehle „Kopieren“ und „Ausschneiden“ wie das Klicken auf eine Schaltfläche, deren Command-Eigenschaft an einen dieser Befehle gebunden ist, funktionieren. Die Ausführung standardmäßiger Kopier- und Ausschneidebefehle über Tastenkombinationen und das Kontextmenü funktioniert weiterhin bei partieller Vertrauenswürdigkeit wie zuvor.	Binden Sie die Befehle Copy oder Cut an eine von Benutzern initiierte Aktion, z.B. an das Klicken auf eine Schaltfläche.

Grafik

Namespaces: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input, System.Windows.Media.Effects

Assemblys: PresentationFramework (in „PresentationFramework.dll“), PresentationCore (in „PresentationCore.dll“), WindowsBase (in „WindowsBase.dll“)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Bitmapeffekte	Zur Verbesserung der Leistung wurden die BitmapEffect-Klasse und die Klassen, die von der BitmapEffect-Klasse erben, deaktiviert, obwohl sie weiterhin vorhanden sind. Der Effekt wird mit der hardwarebeschleunigten Renderingpipeline gerendert, wenn Folgendes zutrifft: * Die Anwendung verwendet einen DropShadowBitmapEffect oder einen BlurBitmapEffect, dessen Radius-Eigenschaft auf weniger als 100 DIU festgelegt ist. * Die Grafikkarte dieses Computers, auf dem die Anwendung ausgeführt wird, unterstützt Pixelshader 2.0. Wenn diese Bedingungen nicht erfüllt werden, hat das BitmapEffect-Objekt keine Auswirkungen. Außerdem erzeugt Visual Studio eine Compilerwarnung, wenn das BitmapEffect-Objekt oder eine Unterklasse erkannt wird. Die PushEffect-Methode ist als veraltet markiert.	Stellen Sie die Verwendung der Vorgängerversion BitmapEffect und der abgeleitete Klassen ein, und verwenden Sie stattdessen die neuen, von Effect abgeleiteten Klassen: BlurEffect, DropShadowEffect, und ShaderEffect. Sie können durch Erben von der ShaderEffect-Klasse auch eigene Effekte erstellen.
Bitmapframes	Geklonte BitmapFrame-Objekte empfangen jetzt die Ereignisse DownloadProgress, DownloadCompleted und DownloadFailed. Dadurch funktionieren Images, die aus dem Web heruntergeladen und auf das Image-Steuerelement angewendet werden, über einen Style ordnungsgemäß. Änderung am Verhalten kommen nur vor, wenn alle der folgenden Aussagen zutreffen: * Sie abonnieren das Ereignis DownloadProgress, DownloadCompleted oder DownloadFailed. * Die Quelle des BitmapFrame stammt aus dem Web. * Das BitmapFrame wird geklont, während der Download immer noch ausgeführt wird.	Überprüfen Sie den Absender im Ereignishandler, und ergreifen Sie nur Maßnahmen, wenn der Absender der ursprüngliche BitmapFrame ist.
Decodieren von Images	Um sicherzustellen, dass eine IOException verarbeitet wird, wenn Images nicht decodiert werden können, löst die BitmapSource-Klasse bei einer fehlgeschlagenen Decodierung das Ereignis DecodeFailed aus.	Entfernen Sie jede Ausnahmebehandlung für IOException, und verwenden Sie das DecodeFailed-Ereignis für die Suche nach Decodierungsfehlern.

Eingabe

Namespaces: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input

Assemblys: PresentationFramework (in „PresentationFramework.dll“), PresentationCore (in „PresentationCore.dll“), WindowsBase (in „WindowsBase.dll“)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Binden von Befehlsinstanzen	Um einen Mechanismus für das Binden von auf dem Ansichtsmodell basierten Befehlsinstanzen an ansichtsbasierte Eingabegesten bereitzustellen, erbt die InputBinding-Klasse jetzt von Freezable statt von DependencyObject. Die folgenden Eigenschaften sind jetzt Abhängigkeitseigenschaften: * Command * CommandParameter * CommandTarget Diese Änderung hat folgende Auswirkungen: * Ein InputBinding-Objekt wird jetzt gesperrt, wenn es registriert wird, statt veränderbar zu bleiben. * Sie können aufgrund der Einschränkungen für die DependencyObject-Klasse nicht von mehreren Threads aus auf InputBinding-Objekte auf Instanzebene zugreifen. * Sie können aufgrund der Einschränkungen der Freezable-Klasse keine Eingabebindungen auf Klassenebene nach deren Registrierung mutieren. * Sie können keine Eingabebindungen auf Befehlsinstanzen angeben, die in einem Ansichtsmodell erstellt werden.	Erstellen Sie separate Instanzen einer InputBinding-Klasse in separaten Threads, wenn Bindungen mutierbar bleiben sollen. Sperren Sie die sie andernfalls. Mutieren Sie kein statisches InputBinding auf Klassenebene, nachdem es registriert wurde.
Browseranwendungen	WPF-Webbrowseranwendungen (.XBAP) verarbeiten jetzt Tastenereignisse wie eigenständige WPF-Anwendungen, sodass Objekte geroutete Tastenereignisse in der richtigen Reihenfolge empfangen.	Keine
Tottastenkombinationen	WPF verbirgt Tottasten, die kein sichtbares Zeichen erzeugen, und weist stattdessen darauf hin, dass die Taste in Kombination mit der nächsten Buchstabentaste ein Zeichen erzeugt. Tasteneingabeereignisse wie das KeyDownEvent-Ereignis melden, wenn eine Taste eine Tottaste ist, indem die Key-Eigenschaft auf den Key-Wert festgelegt wird. Dieses Verhalten wird erwartet, da Anwendungen in der Regel nicht auf Tastatureingaben zu reagieren, die kombinierte Zeichen erzeugen.	Anwendungen, die erwarten, Tasten zu lesen, die Teil von kombinierten Zeichen waren, können verborgene Tasten jetzt mit der DeadCharProcessedKey-Eigenschaft abrufen.
FocusManager	Wenn die Methode FocusManager.GetFocusedElement(DependencyObject) an ein Element übergeben wird, dessen angefügte IsFocusScope-Eigenschaft auf true festgelegt wurde, gibt die Methode ein Element zurück, das das letzte von der Tastatur fokussierte Element innerhalb des Fokusbereichs darstellt, und nur, wenn das zurückgegebene Element zu dem gleichen PresentationSource-Objekt gehört wie das Element, das an die Methode übergeben wird.	Keine

Benutzeroberflächenautomatisierung

Namespaces: System.Windows, System.Windows.Automation.Peers, System.Windows.Automation.Provider, System.Windows.Controls, System.Windows.Data, System.Windows.Input

Assemblys: PresentationFramework (in „PresentationFramework.dll“), PresentationCore (in „PresentationCore.dll“), UIAutomationProvider (in „UIAutomationProvider.dll“), WindowsBase (in „WindowsBase.dll“)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Klassenhierarchie von Ansichten	Die Klasse TreeViewAutomationPeer und TreeViewItemAutomationPeer erben von ItemsControlAutomationPeer statt von FrameworkElementAutomationPeer.	Wenn von der TreeViewItemAutomationPeer-Klasse geerbt und die GetChildrenCore-Methode überschrieben wird, empfiehlt es sich, ein Objekt zurückzugeben, das von der neuen TreeViewDataItemAutomationPeer-Klasse erbt.
Container außerhalb des Bildschirms	Um einen falschen Rückgabewert zu korrigieren, gibt die IsOffscreenCore-Methode jetzt ordnungsgemäß false für Elementcontainer zurück, die außerhalb der Ansicht gescrollt werden. Darüber hinaus ist der Wert der Methode nicht durch Okklusion anderer Fenster oder davon betroffen, ob das Element auf einen bestimmten Monitor angezeigt wird.	Keine
Menüs und untergeordnete Objekte	Um die UI-Automatisierung von Menüs zu ermöglichen, die andere untergeordnete Elemente als MenuItem-Objekte enthalten, gibt die GetChildrenCore-Methode jetzt das AutomationPeer-Objekt eines untergeordneten UIElement-Objekts statt eines MenuItemAutomationPeer-Objekts zurück.	Keine
Neue Schnittstellen und Assembly	Um neue Funktionen für die UI-Automatisierung einzubinden, wurden die folgenden Schnittstellen hinzugefügt: * IItemContainerProvider * ISynchronizedInputProvider * IVirtualizedItemProvider	Jedes Projekt, das WPF-Automatisierungspeers erstellt, muss einen expliziten Verweis auf „UIAutomationProvider.dll“ hinzufügen.
Ziehpunkte	Die GetClassNameCore-Methode gibt einen Wert anstelle von NULL zurück. Aus diesem Grund melden Steuerelemente wie GridSplitter, die von der Thumb-Klasse erben, einen Namen an die UI-Automatisierung.	Keine
Virtualisierte Elemente	Zur Verbesserung der Leistung gibt die GetChildrenCore-Methode nur die untergeordneten Objekte zurück, die tatsächlich in der visuellen Struktur enthalten sind, statt aller untergeordneten Objekte unabhängig vom Virtualisierungsort.	Verwenden Sie ItemContainerPattern, um eine Iteration für alle Elemente von ItemsControlAutomationPeer durchzuführen.

XAML

Namespaces: System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Input, System.Windows.Markup

Assemblys: PresentationFramework (in „PresentationFramework.dll“), PresentationCore (in „PresentationCore.dll“), WindowsBase (in „WindowsBase.dll“)

Feature	Unterschiede zu 3.5 SP1	Empfohlene Änderungen
Markuperweiterung	WPF verwendet jetzt ordnungsgemäß immer den Wert der ProvideValue-Methode, statt in bestimmten Fällen das MarkupExtension-Objekt zurückzugeben, wenn mit einer Markuperweiterung Eigenschaften festgelegt oder ein Element in einer Auflistung erstellt wird. Eine Markuperweiterung kann sich in einigen Fällen selbst zurückgeben.	Wenn Ihre Anwendung auf eine Ressource zugreift, die in einer früheren Version ein MarkupExtension-Objekt zurückgegeben hat, verweisen Sie nicht auf das MarkupExtension-Objekt, sondern auf das von ProvideValue zurückgegebene Objekt.
Analyseattribute	Attribute dürfen in XAML jetzt nur einen Punkt haben. Alle folgenden Attribute sind z.B. gültig: <Button Background="Red"/> (keine Punkte) <Button Button.Background = "Red"/> (ein Punkt) Das folgende Attribut ist nicht mehr gültig: <Button Control.Button.Background = "Red"/> (mehr als ein Punkt)	Richtige XAML-Attribute mit mehr als einem Punkt

XML

Die folgende Tabelle beschreibt die verbesserten Funktionen, die zuvor Einschränkungen oder andere Probleme hatten.

Schemas und Transformationen

Namespaces: System.Xml.Linq, System.Xml.Schema, System.Xml.XPath

Assemblys: System.xml (in „System.Xml.dll“), System.Xml.Linq (in „System.Xml.Linq.dll“)

Feature	Unterschiede zu 3.5 SP1
Chamäleonschemas	Um Datenbeschädigung zu verhindern, werden Chamäleonschemas jetzt ordnungsgemäß geklont, wenn sie in mehreren Schemas enthalten sind. Chamäleonschemas sind Schemas ohne Zielnamespace, und wenn sie in einem anderen XSD-Schema eingeschlossen werden, übernehmen sie den Zielnamespace des importierenden Schemas. Sie werden häufig dazu verwendet, um allgemeine Typen in einem Schema einzuschließen.
ID-Funktionen	Die XSLT-id-Funktion gibt nun den richtigen Wert statt NULL zurück, wenn ein XmlReader-Objekt an eine XSL-Transformation übergeben wird. Wenn der Benutzer aus einer LINQ to XML-Klasse mit der CreateReader-Methode ein XmlReader-Objekt erstellt hat, und dieses XmlReader-Objekt an eine XSL-Transformation übergeben wurde, haben alle Instanzen der id-Funktion in XSLT zuvor NULL zurückgegeben. Dies ist kein zulässiger Rückgabewert für die id-Funktion.
Namespaceattribut	Um Datenbeschädigung zu verhindern, gibt ein XPathNavigator-Objekt nun den lokalen Namen des x:xmlns-Attribut richtig zurück.
Namespacedeklarationen	Ein XmlReader-Objekt in einer Teilstruktur führt nicht länger zur Erstellung doppelter Namespacedeklarationen innerhalb eines XML-Elements.
Schemavalidierung	Um eine fehlerhafte Schemavalidierung zu verhindern, lässt die XmlSchemaSet-Klasse nun zu, dass XSD-Schemas richtig und konsistent kompiliert werden. Diese Schemas können andere Schemas enthalten. A.xsd kann z.B. B.xsd enthalten, das wiederum C.xsd enthalten kann. Das Kompilieren dieser Schemas führt dazu, dass der Graph mit den Abhängigkeiten durchsucht wird.
Skriptfunktionen	Die function-available-Funktion gibt nicht mehr fälschlicherweise false zurück, wenn die Funktion tatsächlich verfügbar ist.
URIs	Die Load-Methode gibt nun den richtigen BaseURI in LINQ-Abfragen zurück.

Validierung

Namespaces: System.Xml.Linq, System.Xml.Schema, System.Xml.XPath

Assemblys: System.xml (in „System.Xml.dll“), System.Xml.Linq (in „System.Xml.Linq.dll“)

Feature	Unterschiede zu 3.5 SP1
Namespace-Resolver	Die ReadContentAs-Methode ignoriert nicht mehr den empfangenenIXmlNamespaceResolver-Resolver. In früheren Versionen wurde der angegebene Namespace-Resolver ignoriert, und stattdessen wurde XmlReader verwendet.
Leerraum	Um beim Erstellen eines Readers Datenverluste zu vermeiden, verwirft die Create-Methode keinen signifikanten Leerraum mehr. Die XML-Validierung erkennt den Modus mit gemischtem Inhalt, in dem Text mit XML-Markup gemischt werden kann. Im gemischten Modus sind jeder Leerraum wichtig und muss gemeldet werden.

Schreiben

Namespaces: System.Xml.Linq, System.Xml.Schema, System.Xml.XPath

Assemblys: System.xml (in „System.Xml.dll“), System.Xml.Linq (in „System.Xml.Linq.dll“)

Feature	Unterschiede zu 3.5 SP1
Entitätsverweise	Um Datenbeschädigung zu verhindern, werden Entitätsverweise in XML-Attribute nicht mehr zweimal in Entitäten geändert. Wenn der Benutzer versucht hat, eine Entität in ein xmlns-Attribut oder mit der WriteEntityRef-Methode in ein xml:lang- oder xml:space-Attribut zu schreiben, wird die Entität zweimal in der Ausgabe in Entitäten geändert. Dabei werden die Daten beschädigt.
Neue Zeilenbehandlung	Um Datenbeschädigung zu verhindern, berücksichtigen XmlWriter-Objekte nun die Option NewLineHandling.

Siehe auch

• Neue Typen und Member in .NET Framework 4
• Leitfaden zur Migration zu .NET Framework 4
• Neuerungen in .NET Framework 4
• Versionskompatibilität in .NET Framework
• Migrieren von Office-Projektmappen zu .NET Framework 4
• Veraltete Elemente in der .NET Framework-Klassenbibliothek