Migrationsprobleme in .NET Framework 4

In diesem Thema werden Migrationsprobleme zwischen .NET Framework Version 3.5 Servicepack 1 und .NET Framework 4 beschrieben. Dabei werden auch Probleme aufgrund von Programmfehlerbehebungen, Änderungen für die Einhaltung von Standards und Sicherheit sowie Änderungen auf Grundlage von Kundenfeedback besprochen. 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“ in der Tabelle.

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

Einen allgemeineren Überblick über die Probleme in diesem Thema finden Sie im Migrationshandbuch zu .NET Framework 4.7, 4.6 und 4.5.

Informationen zu Migrationsproblemen nach Beta 2 finden Sie unter Migration Issues for .NET Framework 4 Applications: Beta 2 to RTM (Migrationsprobleme in .NET Framework 4-Anwendungen: Beta 2 zu RTM).

Informationen zu neuen Funktionen finden Sie unter Neuigkeiten in .NET Framework.

ASP.NET und Web

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

Funktion 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\Browser

Kopieren Sie die Dateien in den entsprechenden Ordner \CONFIG\Browser 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 http://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 2010 von ASP.NET 2.0 oder ASP.NET 3.5 upgraden, 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 eine Anwendung jedoch upgraden, indem Sie den Anwendungspool in IIS so ändern, dass er sich an .NET Framework 4 richtet, 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 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.

ASP.NET 3.5-Anwendungen lassen sich aber auch ohne Neukompilierung mit .NET Framework 4 ausführen. Dazu müssen Sie die „Web.config“-Datei 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 Ihre Anwendung mit Visual Studio 2010 von ASP.NET 2.0 oder ASP.NET 3.5 upgraden, fügt das Tool der Datei „Web.config“ automatisch eine Einstellung hinzu, die das Legacyrendering beibehält. Wenn Sie eine Anwendung jedoch upgraden, indem Sie den Anwendungspool in IIS so ändern, dass er sich an .NET Framework 4 richtet, 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 den Code, der Passport-Typen im System.Web.Security-Namespace verwendet (z.B. PassportIdentity), um das SDK zu nutzen.
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 (Cassini) 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, die von Visual Studio auf Visual Studio 2008 upgegradet wurden, 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 steht nicht mehr in .NET Framework enthalten, sondern wird getrennt bereitgestellt. Sie können CardSpace im Microsoft Download Center herunterladen.
Konfigurationsdateien An der Art und Weise, wie .NET Framework auf Anwendungskonfigurationsdateien zugreift, wurden ebenfalls Korrekturen 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 ihre 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 gleichen 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“)

Funktion 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“)

Funktion 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 Name der Währung der Kultur „Deutsch (Schweiz)“ (de-CH) wurde von „sFr.“ in „Fr.“ geändert.
* LongDatePattern: Das lange Datumsmuster für die 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)“ 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 wird .NET Framework zum Sortieren und die Groß-/Kleinschreibung von Daten mit Windows synchronisiert. Keine
Unicode 5.1-Standards .NET Framework unterstützt jetzt alle Unicode 5.1-Zeichen, d.h. ungefähr 1400 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 Schriften 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

Namespace: System, System.Runtime.ExceptionServices; Assembly: mscorlib (in „mscorlib.dll“)

Funktion 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 Blogeintrag Handling Corrupted State Exceptions (Behandeln beschädigter Statusausnahmen) im englischsprachigen Blog zur CLR.
Ausnahmen des Ausführungsmoduls 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“)

Funktion 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“)

Funktion 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 2010 werden Sie 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“)

Funktion 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; Assembly: System.Data.Entity (in „System.Data.Entity.dll“)

Funktion 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“)

Funktion Unterschiede zu 3.5 SP1
Ereignisse Ein System.Data.Linq.EntitySet<TEntity>-Auflistung löst jetzt das Ereignis ListChanged für die Vorgänge „Hinzufügen“ und „Entfernen“ aus, wenn EntitySet<TEntity> entladen und wenn die Auflistung 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“)

Funktion 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 DataService<T>.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.

Funktion 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; Assembly: PresentationFramework (in „PresentationFramework.dll“)

Funktion 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.

Beachten Sie, dass Anwendungen, die an vertrauenswürdigen Standorten oder in der Intranetzone ausgeführt werden, nicht beeinträchtigt sind.
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.
* Fordern Sie Ihre Kunden auf, die Anwendung in Internet Explorer auszuführen.
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 AllowsTransparency true und WindowState sich selbst, also WindowState entspricht, wird InvalidOperationException ausgelöst. Wenn Sie WindowStyle ändern müssen und AllowsTransparency true 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 kein .NET Framework 3.5 SP1 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“)

Funktion 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“)

Funktion 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 2010 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“)

Funktion 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 KeyDown-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 ein Element an die Methode FocusManager.GetFocusedElement ü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“)

Funktion 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“)

Funktion 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“)

Funktion 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 erstellt keine doppelten 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“)

Funktion 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“)

Funktion 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

Verweis

Neue Typen und Member in .NET Framework 4

Konzepte

Migrationshandbuch zu .NET Framework 4.7, 4.6 und 4.5
Neuigkeiten in .NET Framework
Kompatibilität von .NET Framework-Versionen
Migrieren von Office-Projektmappen in .NET Framework 4

Weitere Ressourcen

Veraltete Elemente in .NET Framework
Migration Issues for .NET Framework 4 Applications: Beta 2 to RTM (Migrationsprobleme in .NET Framework 4-Anwendungen: Beta 2 zu RTM)