Migrationsprobleme in .NET Framework 4

Aktualisiert: August 2010

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

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

  • ASP.NET und Web

  • Kern

  • Daten

  • Windows Communication Foundation (WCF)

  • Windows Presentation Foundation (WPF)

  • XML

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

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

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

ASP.NET und Web

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

Feature

Unterschiede zu 3.5 SP1

Empfohlene Änderungen

Browserdefinitionsdateien

Die Browserdefinitionsdateien wurden aktualisiert und enthalten nun Informationen zu neuen und aktualisierten Browsern und Geräten. Ältere Browser und Geräte, z. B. Netscape Navigator, wurden entfernt, und neuere Browser und Geräte wie Google Chrome und Apple iPhone wurden hinzugefügt.

Wenn die Anwendung benutzerdefinierte Browserdefinitionen enthält, die von einer der entfernten Browserdefinitionen erben, wird ein Fehler angezeigt.

Das HttpBrowserCapabilities-Objekt (das von der Request.Browser-Eigenschaft der Seite verfügbar gemacht wird) wird von den Browserdefinitionsdateien gesteuert. Daher können die Informationen, die durch das Zugreifen auf eine Eigenschaft dieses Objekts in ASP.NET 4 zurückgegeben werden, von den Informationen abweichen, die in einer früheren Version von ASP.NET zurückgegeben wurden.

Wenn die Anwendung die alten Browserdefinitionsdateien benötigt, können Sie sie aus dem folgenden Ordner kopieren:

Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

Kopieren Sie die Dateien in den entsprechenden Ordner \CONFIG\Browsers für ASP.NET 4. Nachdem Sie die Dateien kopiert haben, führen Sie das Befehlszeilentool Aspnet_regbrowsers.exe aus. Weitere Informationen finden Sie auf der Website http://www.asp.net/mobile.

Untergeordnete Anwendungen, die unter gemischten Versionen von ASP.NET ausgeführt werden

ASP.NET 4-Anwendungen, die als untergeordnete Elemente von Anwendungen konfiguriert werden und frühere Versionen von ASP.NET ausführen, können möglicherweise aufgrund von Konfigurations- oder Kompilierungsfehlern nicht gestartet werden. Welcher Fehler jeweils auftritt, hängt davon ab, ob die Anwendung unter IIS 6.0 ausgeführt wird oder unter IIS 7 oder IIS 7.5.

Sie können Änderungen an den Konfigurationsdateien der betroffenen Anwendungen vornehmen, damit das Konfigurationssystem die ASP.NET 4-Anwendung ordnungsgemäß erkennt. Informationen zu den vorzunehmenden Änderungen finden Sie im Abschnitt "Untergeordnete ASP.NET 4-Anwendungen werden unter ASP.NET 2.0- oder ASP.NET 3.5-Anwendungen nicht gestartet" im Dokument Änderungen in ASP.NET 4, die die Lauffähigkeit der Anwendung beeinträchtigen auf der ASP.NET-Website.

ClientID-Änderungen

Mit der neuen Einstellung ClientIDMode in ASP.NET 4 können Sie angeben, wie ASP.NET das id-Attribut für HTML-Elemente generiert. In früheren Versionen von ASP.NET entsprach das Standardverhalten der Einstellung AutoID von ClientIDMode. Die Standardeinstellung ist nun Predictable. Weitere Informationen finden Sie unter Identifikation von ASP.NET-Webserversteuerelementen.

Wenn Sie die Anwendung mithilfe von Visual Studio 2010 von ASP.NET 2.0 oder ASP.NET 3.5 aktualisieren, fügt das Tool der Datei Web.config automatisch eine Einstellung hinzu, die das Verhalten der früheren Versionen von .NET Framework beibehält. Wenn Sie jedoch eine Anwendung aktualisieren, indem Sie den Anwendungspool in IIS ändern, um auf .NET Framework 4 abzuzielen, verwendet ASP.NET standardmäßig den neuen Modus. Fügen Sie der Datei Web.config die folgende Einstellung hinzu, um den neuen Client-ID-Modus zu deaktivieren:

<pages ClientIDMode="AutoID" / >

Codezugriffssicherheit (Code Access Security, CAS)

ASP.NET 2.0-NET-Funktionen, die in ASP.NET 3.5 hinzugefügt wurden, verwenden das .NET Framework 1.1- und .NET Framework 2.0-Codezugriffssicherheitsmodell (CAS). Die Implementierung von CAS in ASP.NET 4 wurde jedoch erheblich überholt. Daher können bei teilweise vertrauenswürdige ASP.NET-Anwendungen, die vertrauenswürdigen Code benötigen, der im globalen Assemblycache ausgeführt wird, Fehler mit verschiedenen Sicherheitsausnahmen auftreten. Bei teilweise vertrauenswürdigen Anwendungen, die umfangreiche Änderungen an der CAS-Richtlinie des Computers benötigen, können ebenfalls Fehler und Sicherheitsausnahmen auftreten.

Sie können teilweise vertrauenswürdige ASP.NET 4-Anwendungen mit dem neuen legacyCasModel-Attribut im trust Konfigurationselement auf das Verhalten von ASP.NET 1.1 und 2.0 zurücksetzen, wie im folgenden Beispiel gezeigt:

<trust level= "Medium"

legacyCasModel="true" />

SicherheitshinweisSicherheitshinweis
Das Zurücksetzen auf das ältere CAS-Modell kann eine verringerte Sicherheit bedeuten.

Weitere Informationen zum neuen ASP.NET 4-Codezugriffssicherheitsmodell finden Sie unter Codezugriffssicherheit für ASP.NET 4-Anwendungen.

Konfigurationsdateien

Die Stammkonfigurationsdateien (die Datei machine.config und die Stamm-Datei Web.config) für .NET Framework und ASP.NET 4 wurden aktualisiert und schließen nun die meisten Standardkonfigurationsinformationen ein, die in den Web.config-Anwendungsdateien in ASP.NET 3.5 vorhanden waren. Aufgrund der Komplexität der verwalteten IIS 7- und IIS 7.5-Konfigurationssysteme kann das Ausführen von ASP.NET 3.5-Anwendungen unter ASP.NET 4 und unter IIS 7 und IIS 7.5 zu ASP.NET-Fehlern oder IIS-Fehlern führen.

Aktualisieren Sie ASP.NET 3.5-Anwendungen mit dem Projektupgradetools in Visual Studio 2010 auf ASP.NET 4. Visual Studio 2010 ändert die Web.config-Datei der ASP.NET 3.5-Anwendung automatisch, sodass sie die entsprechenden Einstellungen für ASP.NET 4 enthält.

Sie können jedoch ASP.NET 3.5-Anwendungen mit .NET Framework 4 ohne Neukompilierung ausführen. In diesem Fall müssen Sie möglicherweise die Web.config-Datei der Anwendung manuell ändern, bevor Sie die Anwendung unter .NET Framework 4 und IIS 7 oder IIS 7.5 ausführen. Die genaue Änderung, die Sie vornehmen müssen, ist abhängig von der Kombination der Software, mit der Sie arbeiten, einschließlich SP (Service Pack)-Versionen. Informationen zu den möglichen Softwarekombinationen, die von dieser Änderung betroffen sind, zum Lösen von Problemen mit bestimmten Kombinationen finden Sie im Abschnitt "Konfigurationsfehler im Zusammenhang mit der neuen ASP.NET 4-Stammkonfiguration" im Dokument Änderungen in ASP.NET 4, die die Lauffähigkeit der Anwendung beeinträchtigen auf der ASP.NET-Website.

Steuerelementrendering

In früheren Versionen von ASP.NET haben einige Steuerelemente Markup ausgegeben, das Sie nicht deaktivieren konnten. Standardmäßig wird dieser Markuptyp in ASP.NET 4 nicht mehr generiert. Die Renderingänderungen wirken sich auf die folgenden Steuerelemente aus:

  • Das Image-Steuerelement und ImageButton-Steuerelement rendern kein border="0"-Attribut mehr.

  • Die BaseValidator-Klasse und die Validierungssteuerelemente, die davon abgeleitet sind, rendern nicht mehr standardmäßig roten Text.

  • Das HtmlForm-Steuerelement rendert kein name-Attribut.

  • Das Table-Steuerelement rendert kein border="0"-Attribut mehr.

Steuerelemente, die nicht für Benutzereingaben konzipiert wurden (z. B. das Label-Steuerelement), rendern nicht mehr das disabled="disabled"-Attribut, wenn ihre Enabled-Eigenschaft auf false festgelegt wird (oder wenn sie diese Einstellung von einem Containersteuerelement erben).

Wenn Sie die Anwendung von ASP.NET 2.0 oder ASP.NET 3.5 mithilfe von Visual Studio 2010 aktualisieren, fügt das Tool der Datei Web.config automatisch eine Einstellung hinzu, die das Legacyrendering beibehält. Wenn Sie jedoch eine Anwendung aktualisieren, indem Sie den Anwendungspool in IIS ändern, um auf .NET Framework 4 abzuzielen, verwendet ASP.NET standardmäßig den neuen Renderingmodus. Fügen Sie der Datei Web.config die folgende Einstellung hinzu, um den neuen Renderingmodus zu deaktivieren:

<pages controlRenderingCompatibilityVersion="3.5" />

Ereignishandler in Standarddokumenten

ASP.NET 4 rendert den action-Attributwert des form-HTML-Elements als leere Zeichenfolge, wenn eine Anforderung an eine URL ohne Erweiterung erfolgt, dem ein Standarddokument zugeordnet ist. In früheren Versionen von ASP.NET würde eine Anforderung an http://contoso.com zu einer Anforderung an Default.aspx führen. In diesem Dokument würde das öffnende form-Tag wie im folgenden Beispiel gerendert werden:

<form action="Default.aspx" />

In ASP.NET 4 führt eine Anforderung an http://contoso.com auch zu einer Anforderung an Default.aspx, aber ASP.NET rendert jetzt das öffnende form-HTML-Tag wie im folgenden Beispiel:

<form action="" />

Wenn das action-Attribut eine leere Zeichenfolge ist, erstellt das DefaultDocumentModule-Objekt in IIS eine untergeordnete Anforderung an Default.aspx. Unter den meisten Bedingungen ist diese untergeordnete Anforderung für Anwendungscode transparent, und die Seite Default.aspx wird normal ausgeführt. Eine mögliche Interaktion zwischen verwaltetem Code und dem integrierten Modus von IIS 7 oder IIS 7.5 kann jedoch bewirken, dass verwaltete ASPX-Seiten während der untergeordneten Anforderung nicht mehr ordnungsgemäß funktionieren. Wenn die folgenden Bedingungen auftreten, führt die untergeordnete Anforderung an ein ASPX-Standarddokument zu einem Fehler oder unerwartetem Verhalten:

  • Eine ASPX-Seite wird an den Browser gesendet, und das action-Attribut des form-Elements ist auf "" festgelegt.

  • Das Formular wird an ASP.NET zurückgesendet.

  • Ein verwaltetes HTTP-Modul liest einen Teil des Entitätstexts, z. B. Request.Form oder Request.Params. Dies führt dazu, dass der Entitätstext der POST-Anforderung in den verwalteten Arbeitsspeicher gelesen wird. Daher ist der Entitätstext nicht mehr für systemeigene Codemodule verfügbar, die im integrierten Modus von IIS 7 oder IIS 7.5 ausgeführt werden.

  • Das DefaultDocumentModule-Objekt in IIS wird schließlich ausgeführt und erstellt eine untergeordnete Anforderung an das Dokument Default.aspx. Da jedoch der Entitätstext bereits von einem verwaltete Codeabschnitt gelesen wurde, ist kein Entitätstext verfügbar, der an die untergeordnete Anforderung gesendet werden kann.

  • Wenn die HTTP-Pipeline für die untergeordnete Anforderung ausgeführt wird, wird der Handler für ASPX-Dateien während der Handlerausführungsphase ausgeführt.

Da kein Entitätstext vorhanden ist, gibt es keine Formularvariablen und keinen Ansichtszustand. Daher sind keine Informationen verfügbar, mit denen der ASPX-Seiten-Handler bestimmen kann, welches Ereignis ggf. ausgelöst werden soll. Aus diesem Grund wird keiner der Postbackereignishandler für die betroffene ASPX-Seite ausgeführt.

Informationen zu Möglichkeiten, Probleme zu umgehen, die aufgrund dieser Änderung auftreten können, finden Sie unter "Ereignishandler werden möglicherweise nicht in einem Standarddokument im integrierten Modus von IIS 7 oder IIS 7.5 ausgelöst" im Dokument Änderungen in ASP.NET 4, die die Lauffähigkeit der Anwendung beeinträchtigen auf der ASP.NET-Website.

Hashalgorithmus

ASP.NET verwendet Verschlüsselung sowie Hashalgorithmen zum Sichern von Daten, z. B. Formularauthentifizierungscookies und Ansichtszustand. Standardmäßig verwendet ASP.NET 4 den HMACSHA256-Algorithmus für Hashvorgänge bei Cookies und Ansichtszustand. In früheren Versionen von ASP.NET wurde der ältere HMACSHA1-Algorithmus verwendet.

Wenn Sie Anwendungen ausführen, die ASP.NET 2.0 und ASP.NET 4 kombinieren und in denen Daten wie Formularauthentifizierungscookies über mehrere .NET Framework-Versionen funktionieren müssen, konfigurieren Sie durch Hinzufügen der folgenden Einstellung in der Datei Web.config eine ASP.NET 4-Webanwendung für die Verwendung des älteren HMACSHA1-Algorithmus:

<machineKey validation="SHA1" />

Hosten von Steuerelementen in Internet Explorer

Sie können in Internet Explorer keine Windows Forms-Steuerelemente mehr hosten, da es bessere Lösungen zum Hosten von Steuerelementen im Web gibt. Die IEHost.dll-Assembly und die IEExec.exe-Assembly wurden deshalb aus .NET Framework entfernt.

Sie können die folgenden Technologien zum Entwickeln von benutzerdefinierten Steuerelementen in Webanwendungen verwenden:

  • Sie können eine Silverlight-Anwendung erstellen und so konfigurieren, dass sie außerhalb des Browsers ausgeführt wird. Weitere Informationen finden Sie unter Out-of-Browser Support.

  • Sie können eine XAML-Browseranwendung (XBAP) erstellen, um die WPF-Funktionen zu nutzen (dazu ist .NET Framework auf Clientcomputern erforderlich). Weitere Informationen finden Sie unter Übersicht über WPF-XAML-Browseranwendungen.

HtmlEncode-Methode und UrlEncode-Methode

Die HtmlEncode-Methode und UrlEncode-Methode der HttpUtility-Klasse und HttpServerUtility-Klasse wurden aktualisiert und codieren das einfache Anführungszeichen (') wie folgt:

  • Die HtmlEncode-Methode codiert Instanzen des einfachen Anführungszeichens als &#39;.

  • Die UrlEncode-Methode codiert Instanzen des einfachen Anführungszeichens als %27.

Suchen Sie im Code die Stellen, an denen die HtmlEncode-Methode und UrlEncode-Methode verwendet werden, und stellen Sie sicher, dass die Änderung der Codierung nicht zu einer Änderung führt, die Auswirkungen auf die Anwendung hat.

HttpExceptions-Fehler in ASP.NET 2.0-Anwendungen

Nachdem ASP.NET 4 für IIS 6 aktiviert wurde, können unter IIS 6 ausgeführte ASP.NET 2.0-Anwendungen (unter Windows Server 2003 oder Windows Server 2003 R2) beispielsweise folgende Fehler generieren:

System.Web.HttpException: Path '/[yourApplicationRoot]/eurl.axd/[Value]' was not found.

  • Wenn ASP.NET 4 zum Ausführen der Website nicht erforderlich ist, ordnen Sie die Site neu zu, sodass stattdessen ASP.NET 2.0 verwendet wird.

    – oder –

  • Wenn ASP.NET 4 zum Ausführen der Website erforderlich ist, verschieben Sie alle untergeordneten virtuellen ASP.NET 2.0-Verzeichnisse auf eine andere Website, die ASP.NET 2.0 zugeordnet ist.

    – oder –

  • Deaktivieren Sie URLs ohne Dateierweiterung. Weitere Informationen finden Sie unter "ASP.NET 2.0-Anwendungen können HttpException-Fehler generieren, die auf eurl.axd verweisen" im Dokument Änderungen in ASP.NET 4, die die Lauffähigkeit der Anwendung beeinträchtigen auf der ASP.NET-Website.

Mitgliedschaftstypen

Einige Typen (z. B. System.Web.Security.MembershipProvider), die in der ASP.NET-Mitgliedschaft verwendet werden, wurden aus System.Web.dll in die System.Web.ApplicationServices.dll-Assembly verschoben. Die Typen wurden verschoben, um Abhängigkeiten verschiedener Architekturebenen zwischen Typen im Client und in erweiterten .NET Framework-SKUs aufzulösen.

Klassenbibliotheken, die aus früheren Versionen von ASP.NET aktualisiert wurden und Mitgliedschaftstypen verwenden, die verschoben wurden, werden bei Verwendung in einem ASP.NET 4-Projekt möglicherweise nicht kompiliert. In diesem Fall fügen Sie System.Web.ApplicationServices.dll im Klassenbibliotheksprojekt einen Verweis hinzu.

Änderungen am Menu-Steuerelement

Änderungen am Menu-Steuerelement führen zu folgendem Verhalten:

Mobile Assembly in der Web.config-Datei

In früheren Versionen von ASP.NET war ein Verweis auf die System.Web.Mobile.dll-Assembly in der Web.config-Stammdatei im assemblies-Abschnitt unter system.web/compilation enthalten. Der Verweis auf diese Assembly wurde entfernt, um die Leistung zu verbessern.

HinweisHinweis
Die System.Web.Mobile.dll-Assembly und die ASP.NET Mobile-Steuerelemente sind in ASP.NET 4 enthalten, aber sie sind veraltet.

Wenn Sie Typen aus dieser Assembly verwenden möchten, fügen Sie einen Verweis auf die Assembly entweder in der Web.config-Stammdatei oder einer Web.config-Anwendungsdatei hinzu.

Ausgabecache

In ASP.NET 1.0 hat ein Fehler dazu geführt, dass zwischengespeicherte Seiten, die Location="ServerAndClient" als Ausgabecacheeinstellung angegeben haben, einen Vary:* HTTP-Header in der Antwort ausgegeben haben. Dies hatte zur Folge, dass Clientbrowser angewiesen wurden, die Seite nie lokal zwischenzuspeichern. In ASP.NET 1.1 wurde die HttpCachePolicy.SetOmitVaryStar-Methode hinzugefügt, die aufgerufen werden konnte, um den Vary:*-Header zu unterdrücken. Problemberichte zeigen jedoch, dass Entwickler das vorhandene SetOmitVaryStar-Verhalten nicht kennen.

In ASP.NET 4 wird der Vary:* HTTP-Header nicht mehr von Antworten ausgegeben, die die folgende Direktive angeben:

<%@ OutputCache Location="ServerAndClient" %>

Daher wird die HttpCachePolicy.SetOmitVaryStar-Methode nicht mehr benötigt, um den Vary:*-Header zu unterdrücken. In Anwendungen, die "ServerAndClient" für das Location-Attribut angeben, können Seiten im Browser zwischengespeichert werden, ohne dass Sie HttpCachePolicy.SetOmitVaryStar aufrufen müssen.

Wenn Seiten in der Anwendung Vary:* ausgeben müssen, rufen Sie die HttpResponse.AppendHeader-Methode auf, wie im folgenden Beispiel dargestellt:

HttpResponse.AppendHeader("Vary","*");

Alternativ können Sie den Wert des Location-Ausgabecachingattributs in "Server" ändern.

Seitenanalyse

Der Seitenparser für ASP.NET-Webseiten (ASPX-Dateien) und Benutzersteuerelement (ASCX-Dateien) ist in ASP.NET 4 strenger als in früheren Versionen von ASP.NET. Mehr Markup wird als ungültig gekennzeichnet als in früheren Versionen.

Untersuchen Sie Fehlermeldungen, die beim Ausführen einer Seite erzeugt werden, und beheben Sie Fehler, die sich aus ungültigem Markup ergeben.

Passport-Typen

Die in ASP.NET 2.0 integrierte Passport-Unterstützung ist veraltet und wird aufgrund von Änderungen in Passport (jetzt Live ID-SDK) nicht unterstützt. Daher werden die Typen in Zusammenhang mit Passport in System.Web.Security jetzt mit dem ObsoleteAttribute-Attribut markiert.

Ändern Sie allen vorliegenden Code, der Passport-Typen im System.Web.Security-Namespace verwendet (z. B. System.Web.Security.PassportIdentity) so, dass Windows Live ID SDK verwendet wird.

PathInfo-Informationen in der FilePath-Eigenschaft

ASP.NET 4 umfasst nicht mehr den PathInfo-Wert in den Rückgabewerten von Eigenschaften wie HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath und HttpRequest.CurrentExecutionFilePath. Stattdessen sind die PathInfo-Informationen in HttpRequest.PathInfo verfügbar. Betrachten Sie z. B. das folgende URL-Fragment:

/testapp/Action.mvc/SomeAction

In früheren Versionen von ASP.NET verfügen System.Web.HttpRequest-Eigenschaften über die folgenden Werte:

In ASP.NET 4 verfügen System.Web.HttpRequest-Eigenschaften stattdessen über die folgenden Werte:

Suchen Sie im Code die Stellen, an denen Sie Eigenschaften der System.Web.HttpRequest-Klasse benötigen, um Pfadinformationen zurückzugeben. Ändern Sie den Code entsprechend den Änderungen bei der Rückgabe der Pfadinformationen.

Anforderungsvalidierung

Zur Optimierung der Anforderungsvalidierung wird die ASP.NET-Anforderungsvalidierung früher im Anforderungslebenszyklus aufgerufen. Daher wird die Anforderungsvalidierung für Anforderungen ausgeführt, bei denen es sich nicht um ASPX-Dateien handelt, z. B. für Webdienstaufrufe und für benutzerdefinierte Handler. Die Anforderungsvalidierung ist auch aktiv, wenn benutzerdefinierte HTTP-Module in der Anforderungsverarbeitungspipeline ausgeführt werden.

Aufgrund dieser Änderung können Anforderungen für andere Ressourcen als ASPX-Dateien Anforderungsvalidierungsfehler auslösen. Benutzerdefinierter Code, der in der Anforderungspipeline ausgeführt wird (z. B. benutzerdefinierte HTTP-Module), kann ebenfalls Anforderungsvalidierungsfehler auslösen.

Falls notwendig, können Sie das alte Verhalten wiederherstellen, dass nur ASPX-Seiten die Anforderungsvalidierung auslösen, indem Sie die folgende Einstellung in der Webkonfigurationsdatei verwenden:

<httpRuntime requestValidationMode="2.0" />

SicherheitshinweisSicherheitshinweis
Wenn Sie das alte Verhalten wiederherstellen, stellen Sie sicher, dass der gesamte Code in vorhandenen Handlern, Modulen und in anderem benutzerdefiniertem Code Überprüfungen auf potenziell unsichere HTTP-Eingaben ausführt, bei denen es sich um XSS-Angriffsmöglichkeiten handeln könnte.

Routing

Wenn Sie in Visual Studio 2010 eine Dateisystemwebsite erstellen, und die Website befindet sich in einem Ordner, der im Ordnernamen einen Punkt (.) enthält, funktioniert das URL-Routing nicht zuverlässig. Ein HTTP-Fehler mit dem Fehlercode 404 wird von einigen virtuellen Pfaden zurückgegeben. Dies liegt daran, dass Visual Studio Development Server (Cassini) von Visual Studio 2010 mit einem falschen Pfad für das virtuelle Stammverzeichnis gestartet wird.

  • Ändern Sie auf der Seite Eigenschaften für die dateibasierte Website das Virtueller Pfad-Attribut in "/".

    – oder –

  • Erstellen Sie ein Webanwendungsprojekt anstatt eines Websiteprojekts. Webanwendungsprojekte weisen dieses Problem nicht auf, und das URL-Routing funktioniert, auch wenn der Name des Projektordners einen Punkt enthält.

    – oder –

  • Erstellen Sie eine HTTP-basierte Website, die in IIS gehostet wird. Von IIS gehostete Websites können Punkte im virtuellen Pfad und im Projektdateiordner enthalten.

SharePoint-Websites

Wenn Sie versuchen, eine ASP.NET 4-Website auszuführen, die als untergeordnetes Element einer SharePoint-Website bereitgestellt wird und eine benutzerdefinierte teilweise vertrauenswürdige Ebene mit dem Namen WSS_Minimal enthält, wird der folgende Fehler angezeigt:

Could not find permission set named 'ASP.Net'.

Derzeit sind keine Versionen von SharePoint mit ASP.NET kompatibel. Folglich sollten Sie nicht versuchen, eine ASP.NET 4-Website als untergeordnetes Element einer SharePoint-Website auszuführen.

XHTML 1.1-Standards

Um die Kompatibilität von XHTML-1.1 für neue Websites zu ermöglichen, generieren ASP.NET-Steuerelemente in .NET Framework 4 XHTML 1.1-kompatibles HTML. Dieses Rendering wird mit folgenden Option in der Web.config-Datei aktiviert:

<system.Web>

<pages controlRenderingCompatibilityVersion="4.0"/>

</system.Web>

Standardmäßig ist diese Option auf 4.0 festgelegt. Für Webprojekte, die von Visual Studio 2008 auf Visual Studio aktualisiert werden, ist die 3.5-Einstellung zur Kompatibilität aktiviert.

Keine.

Zurück nach oben

Kern

Allgemeine Features

Feature

Unterschiede zu 3.5 SP1

Empfohlene Änderungen

CardSpace

Windows CardSpace ist nicht mehr in .NET Framework enthalten; es wird getrennt zur Verfügung gestellt.

Laden Sie Windows CardSpace im Microsoft Download Center herunter.

Konfigurationsdateien

Korrekturen wurden an der Art und Weise vorgenommen, in der von .NET Framework auf Anwendungskonfigurationsdateien zugegriffen wird.

Wenn die Anwendungskonfigurationsdatei den Namen "Anwendungsname.config" trägt, benennen Sie sie in "Anwendungsname.exe.config" um. Nennen Sie beispielsweise MyApp.config in MyApp.exe.config um.

C#-Codecompiler

Die Klassen Compiler, CompilerError und ErrorLevel, die sich im Microsoft.CSharp-Namespace befanden, sind nicht mehr verfügbar, und ihre Assembly (cscompmgd.dll) ist nicht mehr in .NET Framework enthalten.

Verwenden Sie die CodeDomProvider-Klasse und andere Klassen im System.CodeDom.Compiler-Namespace. Weitere Informationen finden Sie unter Verwenden von CodeDOM .

Hosting

(nicht verwaltete API)

Zur Verbesserung der Hostingfunktionen sind einige Hostingaktivierungs-APIs nun veraltet. Durch prozessinterne parallele Ausführungsfunktionen kann eine Anwendung mehrere Versionen von .NET Framework im gleichen Prozess laden und starten. Sie können z. B. Anwendungen ausführen, die auf .NET Framework 2.0 SP1 basierende Add-Ins (oder Komponenten) und auf .NET Framework 4 basierende Add-Ins im gleichen Prozess laden. In älteren Komponenten wird weiterhin die ältere .NET Framework-Version verwendet, und neue Komponenten verwenden die neue .NET Framework-Version.

Verwenden Sie die in Prozessinterne parallele Ausführung beschriebenen Konfigurationen.

Neues Sicherheitsmodell

Die Codezugriffssicherheitsrichtlinie (CAS) wurde deaktiviert und durch ein vereinfachtes Modell ersetzt, wie in Änderungen der Sicherheit in .NET Framework 4 beschrieben.

Änderungen sind möglicherweise erforderlich, wenn Sie in den Anwendungen CAS benötigen. Weitere Informationen finden Sie unter Kompatibilität und Migration von Richtlinien für die Codezugriffssicherheit.

Zurück nach oben

Datum und Uhrzeit

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

Feature

Unterschiede zu 3.5 SP1

Empfohlene Änderungen

Sommerzeit

Um mit der Systemuhr konsistent zu sein, verwenden Zeiteigenschaften (z. B. TimeZoneInfo.Local und DateTime.Now) jetzt Betriebssystemregeln statt anderer .NET Framework-Daten für Vorgänge im Zusammenhang mit der Sommerzeit.

Keine.

Formatzeichenfolgen

Um die kulturabhängige Formatierung zu unterstützen, schließt die TimeSpan-Struktur neue Überladungen der Methoden ToString, Parse und TryParse sowie neue Methoden für ParseExact und TryParseExact ein.

Keine.

Zurück nach oben

Globalisierung

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

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

Feature

Unterschiede zu 3.5 SP1

Empfohlene Änderungen

Kulturnamen

Die folgenden Namensänderungen wirken sich auf die Kulturen für Deutsch, Divehi und afrikanische Kulturen aus:

  • CurrencyEnglishName: Der Währungsname für die Kultur "Deutsch (Schweiz)" (de-CH) wurde von "sFr." in "Fr." geändert.

  • LongDatePattern: Das lange Datumsmuster der Kultur "Divehi (Malediven)" (dv-MV) wurde von "dd/MMMM/yyyy" in "dd/MM/yyyy" geändert.

  • PMDesignator: der PM-Kennzeichner der Kultur "Afrikaans (Südafrika)" (af-ZA) wurde von "nm" in "PM" geändert.

Beachten Sie die Änderungen der Kulturnamen.

LCID-Parameter

Um mit erwartetem Verhalten in Automatisierungsservereinstellungen konsistent zu sein, übergibt CLR nicht mehr die aktuelle Kultur für den LCID-Parameter an nicht verwaltete COM-basierte Anwendungen. Stattdessen wird 1033 (en-us) als Kultur übergeben.

Es sind keine Änderungen erforderlich, außer bei systemeigenen Anwendungen, die eine angegebene Kultur erfordern.

Veraltete Kulturtypen

Der FrameworkCultures-Kulturtyp und der WindowsOnlyCultures-Kulturtyp sind nun veraltet.

Für die Abwärtskompatibilität gibt FrameworkCultures jetzt neutrale und bestimmte Kulturen zurück, die in der vorherigen Version von .NET Framework enthalten waren, und WindowsOnlyCultures gibt jetzt eine leere Liste zurück.

Verwenden Sie andere Werte der CultureTypes-Enumeration.

Abrufen der Kultur

Ab Windows 7 ruft .NET Framework 4 Kulturinformationen aus dem Betriebssystem ab, statt die Daten selbst zu speichern. Außerdem wird .NET Framework mit Windows für Sortierungs- und Groß-/Kleinschreibungsdaten synchronisiert.

Keine.

Unicode 5.1-Standards

.NET Framework unterstützt jetzt alle Unicode 5.1-Zeichen, dies bedeutet ca. 1.400 Zeichen mehr. Zu den zusätzlichen Zeichen gehören neue Symbole, Pfeile, diakritische Zeichen, Interpunktion, mathematische Symbole, CJK-Zeichen und Ideogramme, zusätzliche numerische Malayalam- und Telugu-Zeichen und verschiedene Zeichen für Myanmar, Latein, Arabisch, griechisch, Mongolisch und Kyrillisch. Die folgenden neuen Skripts werden mit Unicode 5.1 unterstützt: Sundanesisch, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Oriya, Tamil, Telugu/ und Malayalam-Zeichen und Cham.

Keine.

Zurück nach oben

Ausnahmen

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

Feature

Unterschiede zu 3.5 SP1

Empfohlene Änderungen

Ausnahmen für beschädigten Prozesszustand

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

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

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

Ausnahmen des Ausführungsmoduls

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

Verwenden Sie eine InvalidOperationException, um die Bedingung zu signalisieren.

Zurück nach oben

Reflektion

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

Feature

Unterschiede zu 3.5 SP1

Empfohlene Änderungen

Assemblyhashalgorithmen

Die AssemblyName.HashAlgorithm-Eigenschaft gibt jetzt AssemblyHashAlgorithm.None zurück, da die Laufzeit den Hashalgorithmus der Assembly, auf die verwiesen wird, nicht kennt, wenn die Assembly nicht geladen wurde. (Dies bezieht sich auf die Verwendung der Eigenschaft bei einer Assembly, auf die verwiesen wird, z. B. die von der Assembly.GetReferencedAssemblies-Methode zurückgegebene Assembly.)

Keine.

Laden von Assemblys

Um redundantes Laden von Assemblys zu verhindern und virtuellen Adressenspeicherplatz zu sparen, lädt CLR Assemblys nun nur mithilfe der MapViewOfFile-Win32-Funktion. Die LoadLibrary-Funktion wird nicht mehr ebenfalls aufgerufen.

Diese Änderung hat folgende Auswirkungen auf Diagnoseanwendungen:

  • Eine ProcessModuleCollection enthält nicht mehr Module aus einer Klassenbibliothek (DLL-Datei), wie durch einem Aufruf von Process.GetCurrentProcess().Modules abgerufen.

  • Für Win32-Anwendungen, die die EnumProcessModules-Funktion verwenden, werden nicht alle verwalteten Module aufgeführt.

Keine.

Deklarierender Typ

Die Type.DeclaringType-Eigenschaft gibt jetzt ordnungsgemäß NULL zurück, wenn der Typ nicht über einen deklarierenden Typ verfügt.

Keine.

Delegaten

Ein Delegat löst jetzt eine ArgumentNullException statt einer NullReferenceException aus, wenn ein NULL-Wert an den Konstruktor des Delegaten übergeben wird.

Stellen Sie sicher, dass jede Ausnahmebehandlung ArgumentNullException abfängt.

Änderung des Speicherorts des globalen Assemblycache

Für .NET Framework 4-Assemblys wurde der globale Assemblycache aus dem Windows-Verzeichnis (% WINDIR%) in das Unterverzeichnis Microsoft.Net (%WINDIR%\Microsoft.Net) verschoben. Assemblys aus früheren Versionen verbleiben im älteren Verzeichnis.

Die nicht verwaltete ASM_CACHE_FLAGS-Enumeration enthält das neue ASM_CACHE_ROOT_EX-Flag. Dieses Flag ruft den Cachespeicherort für .NET Framework 4-Assemblys ab, die von der GetCachePath-Funktion abgerufen werden können.

Keines, ausgehend davon, dass Anwendungen keine expliziten Pfade zu Assemblys verwenden. Hierbei handelt es sich um keine empfohlene Vorgehensweise.

Global Assembly Cache-Tool

Der Shell-Plug-In-Viewer wird von Gacutil.exe (Global Assembly Cache-Tool) nicht mehr unterstützt.

Keine.

Interoperabilität

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

Feature

Unterschiede zu 3.5 SP1

Empfohlene Änderungen

Pufferlänge

(nicht verwaltete API)

Um Arbeitsspeicher zu sparen, wurde die Funktionalität für den pBufferLengthOffset-Parameter für die ICorProfilerInfo2::GetStringLayout-Methode geändert und entspricht nun dem pStringLengthOffset-Parameter. Beide Parameter zeigen jetzt auf die Offsetposition der Länge der Zeichenfolge. Die Pufferlänge wurde aus der Darstellung der Zeichenfolgenklasse entfernt.

Entfernen Sie jede Abhängigkeit von der Pufferlänge.

JIT-Debuggen

Zur Vereinfachung der Registrierung zum Just-In-Time-Debugging (JIT) verwendet der .NET Framework-Debugger jetzt nur den Registrierungsschlüssel AeDebug, der das JIT-Debugging-Verhalten für systemeigenen Code steuert. Diese Änderung hat folgende Auswirkungen:

  • Sie können nicht mehr zwei verschiedene Debugger für verwalteten und systemeigenen Code registrieren.

  • Sie können den Debugger für einen nicht interaktiven Prozess nicht mehr automatisch starten, aber Sie können den Benutzer für einen interaktiven Prozess auffordern.

  • Sie werden nicht mehr benachrichtigt, wenn der Debugger nicht startet oder wenn kein registrierter Debugger vorhanden ist, der gestartet werden soll.

  • Richtlinien für den automatischen Start, die von der Interaktivität der Anwendung abhängen, werden nicht mehr unterstützt.

Stellen Sie Debugvorgänge nach Bedarf ein.

Plattformaufruf

Um die Leistung bei der Interoperabilität mit nicht verwaltetem Code zu verbessern, führen falsche Aufrufkonventionen in einem Plattformaufruf jetzt zu einem Fehler der Anwendung. In früheren Versionen wurden diese Fehler durch die Marshallingebene im Stapel aufwärts behoben.

Wenn Sie Ihre Anwendungen in Microsoft Visual Studio 2010 debuggen, werden Sie auf diese Fehler hingewiesen, damit Sie sie korrigieren können.

Bei Binärdateien, die nicht aktualisiert werden können, können Sie das <NetFx40_PInvokeStackResilience>-Element in der Konfigurationsdatei der Anwendung einschließen, um das Aufrufen von Fehlern zu ermöglichen, die wie in früheren Versionen weiter oben im Stapel aufgelöst werden sollen. Dies kann jedoch die Leistung der Anwendung beeinträchtigen.

Entfernte Schnittstellen

(nicht verwaltete API)

Um Verwirrung bei den Entwicklern zu vermeiden, wurden die folgenden Schnittstellen entfernt, da sie keine nützlichen Laufzeitszenarien bereitgestellt haben und die CLR keine Implementierungen bereitgestellt oder akzeptiert hat:

  • INativeImageINativeImageDependency

  • INativeImageInstallInfo

  • INativeImageEvaluate

  • INativeImageConverter

  • ICorModule

  • IMetaDataConverter

Keine.

Zurück nach oben

Daten

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

DataSet und SQL Client

In der folgenden Tabelle werden Verbesserungen an Funktionen beschrieben, die zuvor Einschränkungen oder andere Probleme aufwiesen.

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-Szenarien

Die System.Data.Objects.DataClasses.IRelatedEnd-Schnittstelle verfügt über neue Methoden, um ihre Benutzerfreundlichkeit in POCO (Plain Old CLR Object)-Szenarien zu verbessern. Diese neuen Methoden nehmen ein Object statt einer IEntityWithRelationships-Entität als Parameter an.

Bearbeiten von Zeilen

Die IndexOf-Methode, wie von der DataView-Klasse implementiert, gibt jetzt ordnungsgemäß den Wert einer Zeile, die bearbeitet wird, zurück und nicht -1.

Ereignisse

Das DataRowView.PropertyChanged-Ereignis wird jetzt ausgelöst, wenn eine Zeile sich in einem geänderten Zustand befindet und die RejectChanges-Methode aufgerufen wird. Durch diese Änderung können leichter UI-Steuerelemente erstellt werden, die den Inhalt eines DataSet-Objekts verfügbar machen.

Ausnahmen

Die Prepare-Methode löst nun eine InvalidOperationException aus anstelle einer NullReferenceException, wenn eine Verbindung nicht festgelegt oder geöffnet wird.

Zuordnen von Ansichten

Abfrageansichtszuordnungsfehler werden nun zur Entwurfszeit abgefangen, statt zur Laufzeit eine NullReferenceException auszulösen.

Die Zuordnungsvalidierung fängt jetzt den Fehler ab, bei dem zwei Zuordnungssätze im konzeptionellen Schema (CSDL) der gleichen Spalte zugeordnet werden.

Transaktionen

Wenn eine Anwendung versucht, eine Anweisung für eine Verbindung auszuführen, nachdem eine Transaktion abgeschlossen wurde (einschließlich Abbruch oder Rollback), wird jetzt eine InvalidOperationException ausgelöst. In früheren Versionen wurde keine Ausnahme ausgelöst, und Sie konnten zusätzliche Befehle ausführen, auch wenn eine Transaktion abgebrochen wurde.

Zurück nach oben

Entity Framework

In der folgenden Tabelle werden Verbesserungen an Funktionen beschrieben, die zuvor Einschränkungen oder andere Probleme aufwiesen.

Namespaces: System.Data, System.Data.Objects, System.Data.Objects.DataClasses; Assembly: System.Data.Entity (in System.Data.Entity.dll)

Feature

Unterschiede zu 3.5 SP1

Entitätsobjekte

Es gibt jetzt Parität zwischen der ObjectContext.Detach-Methode und dem Zustand des Entitätsobjekts, wenn die ObjectContext.SaveChanges-Methode aufgerufen wird. Diese verbesserte Konsistenz verhindert, dass unerwartete Ausnahmen ausgelöst werden.

Entitäts-SQL

Die Regeln für die Bezeichnerauflösungen in Entity SQL wurden verbessert.

Der Entity SQL-Parser verfügt über verbesserte Logik zum Auflösen von mehrteiligen Bezeichnern.

Strukturelle Anmerkungen

Das Entity Framework erkennt jetzt strukturelle Anmerkungen.

Abfragen

Die folgenden Verbesserungen wurden für Abfragen vorgenommen:

  • Eine GroupBy-Abfrage, die einen NULL-Schlüssel für eine leere Auflistung verwendet, gibt keine Zeilen zurück, unabhängig davon, ob die Abfrage weitere select-Anweisungen enthält.

  • Generiertes SQL in LINQ- und Entitäts-SQL-Abfragen behandeln jetzt Zeichenfolgenparameter standardmäßig als Nicht-Unicode-Werte.

Zurück nach oben

LINQ to SQL

In der folgenden Tabelle werden Verbesserungen an Funktionen beschrieben, die zuvor Einschränkungen oder andere Probleme aufwiesen.

Namespace: System.Data.Linq; Assembly: System.Data.Linq (in System.Data.Linq.dll)

Feature

Unterschiede zu 3.5 SP1

Ereignisse

Eine System.Data.Linq.EntitySet<TEntity>-Auflistung löst jetzt das ListChanged-Ereignis für Vorgänge zum Hinzufügen und Entfernen aus, wenn das EntitySet<TEntity> entladen wird. Außerdem wird das Ereignis ausgelöst, wenn die Auflistung geladen wird.

Abfragen

Skip(0) wird nicht mehr in LINQ to SQL-Abfragen ignoriert. Folglich verhalten sich Abfragen möglicherweise anders, die über diese Methode verfügen. In einigen Fällen ist z. B. eine OrderBy-Klausel mit Skip(0) erforderlich, und die Abfrage löst jetzt eine NotSupportedException-Ausnahme aus, wenn die OrderBy-Klausel nicht eingeschlossen war.

Zurück nach oben

WCF Data Services

In der folgenden Tabelle werden Verbesserungen an Funktionen beschrieben, die zuvor Einschränkungen oder andere Probleme aufwiesen.

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 Inhalt im Batchmodus

WCF-Datendienste unterstützen jetzt binären Inhalt im Batchmodus in Anforderungen und Antworten.

Änderungsinterceptors

Änderungsinterceptors werden jetzt für eine Löschanforderung ausgeführt.

Ein Änderungsinterceptor ist eine Methode, die jedes Mal ausgeführt wird, wenn eine Anforderung zum Ändern einer Entität im Entitätssatz vom Server empfangen wird. Sie wird ausgeführt, bevor die eingehende Anforderung ausgeführt wird. Der Änderungsinterceptor bietet Zugriff auf die Entität, die geändert wird, und den Vorgang, der dafür ausgeführt wird.

Ausnahmen

Die folgenden Bedingungen lösen jetzt nützlichere Ausnahmen statt einer NullReferenceException aus:

In den Anwendungen sollten Sie die Ausnahmebehandlung so ändern, dass die neuen Ausnahmen abgefangen werden.

Headers

Die folgenden Verbesserungen wurden an Headern vorgenommen:

  • WCF-Datendienste lehnen jetzt ordnungsgemäß einen eTag-Header ab, der über einen nicht angegebenen Wert verfügt.

  • WCF-Datendienste geben jetzt einen Fehler zurück und führen die Anforderung für eine Löschanforderung an einen Link nicht aus, wenn ein if-*-Header in der Anforderung vorhanden ist.

  • WCF-Datendienste geben jetzt einen Fehler in dem vom Client im Accept-Header angeforderten Format (Atom, JSON) an den Client zurück.

JSON-Reader

Der JSON (JavaScript Objekt Notation)-Reader gibt jetzt ordnungsgemäß einen Fehler zurück, wenn das Escapezeichen einzelner umgekehrter Schrägstrich ("\") gelesen wird, wenn an einen WCF-Datendienst gesendete JSON-Nutzlasten verarbeitet werden.

Zusammenführungen

Die folgenden Verbesserungen wurden an der MergeOption-Enumeration vorgenommen:

  • Mit der AppendOnly-Zusammenführungsoption wird die Entität auf dem Client nicht mehr als Ergebnis einer nachfolgenden Antwort von einem Datendienst geändert.

  • Die PreserveChanges-Option ist jetzt zwischen dynamischem SQL und Aktualisierungen auf Grundlage von gespeicherten Prozeduren konsistent.

Anforderungen

Die DataService<T>.OnStartProcessingRequest-Methode wird jetzt aufgerufen, bevor eine Anforderung an Datendienste verarbeitet wird. So kann die Anforderung ordnungsgemäß für ServiceOperation-Dienste ausgeführt werden.

Streams

WCF-Datendienste schließen nicht mehr den zugrunde liegenden Stream für Lese- und Schreibvorgänge.

URIs

Das Versehen von URIs mit Escapezeichen durch den WCF-Datendiensteclient wurde korrigiert.

Windows Communication Foundation (WCF)

In der folgenden Tabelle werden Verbesserungen an Funktionen beschrieben, die zuvor Einschränkungen oder andere Probleme aufwiesen.

Feature

Unterschiede zu 3.5 SP1

Konfigurationsdateien

Um die Vererbung von Verhalten durch die Konfigurationsdateihierarchie zu aktivieren, unterstützt WCF jetzt die Zusammenführung über Konfigurationsdateien hinweg.

Das Konfigurationsvererbungsmodell wird jetzt erweitert, damit Benutzer Verhalten definieren können, das auf alle auf dem Computer ausgeführten Dienste angewendet wird.

Sie stoßen möglicherweise auf Verhaltensänderungen, wenn Verhalten mit dem gleichen Namen auf unterschiedlichen Ebenen der Hierarchie vorhanden sind.

Diensthosting

Sie können das <serviceHostingEnvironment>-Konfigurationselement nicht mehr auf Serviceebene angeben, indem Sie der Elementdefinition das Attribut allowDefinition="MachineToApplication" hinzufügen.

Das Angeben des <serviceHostingEnvironment>-Elements auf Serviceebene ist technisch falsch und verursacht inkonsistentes Verhalten.

Zurück nach oben

Windows Presentation Foundation (WPF)

Anwendungen

Namespaces: System.Windows, System.Windows.Controls; Assembly: 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 InnerException-Eigenschaft auf wichtige Ausnahmen fest, z. B. NullReferenceException, OutOfMemoryException, StackOverflowException und SecurityException, anstatt die ursprüngliche Ausnahme zu erfassen.

Keine.

Verknüpfte Ressourcen

Zur Vereinfachung der Verknüpfung verwenden Ressourcendateien (z. B. Bilder), die sich an einer anderen Stelle befinden als in der Ordnerstruktur des Projekts, beim Erstellen der Anwendung den vollständigen Pfad der Ressourcendatei anstelle des Dateinamens der Ressource als Ressourcen-ID. Die Anwendung ist in der Lage, die Dateien zur Laufzeit zu suchen.

Keine.

Teilweise vertrauenswürdige Anwendungen

Aus Sicherheitsgründen lösen Windows-basierte Anwendungen, die mit teilweiser Vertrauenswürdigkeit ausgeführt werden und ein WebBrowser-Steuerelement oder ein Frame-Steuerelement mit HTML enthalten, eine SecurityException aus, wenn das Steuerelement erstellt wird.

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 Anwendung wird mit teilweiser Vertrauenswürdigkeit in der Internetzone von nicht vertrauenswürdigen Sites ausgeführt.

  • Die Anwendung enthält ein WebBrowser-Steuerelement oder ein Frame-Steuerelement, das HTML enthält

Beachten Sie, dass Anwendungen, die von vertrauenswürdigen Sites oder der Intranetzone ausgeführt werden, nicht davon betroffen sind.

In Ihren Browseranwendungen können Sie diese Änderung durch einen der folgenden Schritte vereinfachen:

  • Führen Sie die Browseranwendung in voller Vertrauenswürdigkeit aus.

  • Bitten Sie Kunden, die Site der Anwendung der Zone vertrauenswürdiger Sites hinzuzufügen.

  • Bitten Sie Kunden, die Anwendung in Internet Explorer auszuführen.

Ressourcenwörterbücher

Um Ressourcenwörterbücher auf Designebene zu verbessern und Änderungen zu verhindern, werden Freezable-Ressourcen, die in einem Ressourcenwörterbuch definiert und in einem Wörterbuch auf Designebene zusammengeführt werden, jetzt immer als fixiert und unveränderlich markiert. Dies ist das erwartete Verhalten für Freezable-Ressourcen.

Anwendungen, die eine Ressource ändern, die in einem auf Designebene zusammengeführten Wörterbuch definiert ist, sollten die Ressource klonen und die geklonte Kopie ändern. Alternativ kann die Ressource als x:Shared="false" gekennzeichnet werden, sodass das ResourceDictionary jedes Mal eine neue Kopie erstellt, wenn die Ressource abgefragt wird.

Windows 7

Damit WPF-Anwendungen unter Windows 7 besser funktionieren, wurden die folgenden Verbesserungen zum Korrigieren des Verhaltens eines Fensters vorgenommen:

  • Dock- und Gestenzustände funktionieren nun wie erwartet auf Grundlage von Benutzerinteraktionen.

  • Die Taskleistenbefehle Überlappend, Fenster gestapelt anzeigen, und Fenster nebeneinander anzeigen weisen jetzt das richtige Verhalten auf und aktualisieren die entsprechenden Eigenschaften.

  • Die Eigenschaften Top, Left, Width und Height für ein maximiertes oder minimiertes Fenster enthalten jetzt die richtige Wiederherstellungsposition des Fensters anstelle anderer Werte, abhängig vom Bildschirm.

Keine.

Windows-Stil und Transparenz

Eine InvalidOperationException wird ausgelöst, wenn Sie versuchen, WindowStyle auf einen anderen Wert als None festzulegen, wenn AllowsTransparency den Wert true und WindowState den Wert Minimized hat.

Wenn Sie den WindowStyle ändern müssen, wenn AllowsTransparency den Wert true aufweist, können Sie die Win32-SetWindowLongPtr-Funktion aufrufen.

XPS-Viewer

WPF beinhaltet nicht das Microsoft XML Paper Specification Essentials Pack (XPSEP). XPSEP ist in Windows 7 und Windows Vista enthalten.

Auf einem Computer unter Windows XP ohne installiertes .NET Framework 3.5 SP1 wird zum Drucken mit einer anderen WPF-API als der in PrintDialog WINSPOOL verwendet. Einige Druckerfunktionen werden nicht gemeldet, und einige Druckereinstellungen werden während des Drucks nicht angewendet.

Falls erforderlich, installieren Sie das Microsoft XML Paper Specification Essentials Pack.

Zurück nach oben

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 CommonDialog.ShowDialog-Methode in dem Thread aufgerufen, der das Microsoft.Win32.FileDialog-Steuerelement erstellt hat.

Stellen Sie sicher, ein FileDialog-Steuerelement zu erstellen und die ShowDialog-Methode auf dem gleichen Thread aufzurufen.

Unverankerte Fenster

Um die Fokuswiederherstellungslogik zu korrigieren, mit der ein unverankertes Fenster falsch reaktiviert wird (sodass es wie ein modales Dialogfeld angezeigt wird), wird die Fokuswiederherstellung jetzt verhindert, 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, wird es in der CollectionView an der gleichen relativen Stelle angezeigt, wenn die CollectionView nicht sortiert wird. Dadurch ist die Konsistenz zwischen der Position des Elements in der Auflistung und in der zugeordneten CollectionView gewährleistet.

Verwenden Sie die ItemContainerGenerator.ContainerFromItem-Methode oder CollectionView.IndexOf-Methode, um die Position eines Elements in einer CollectionView zu suchen, anstatt sich auf eine feste Position eines Elements zu stützen.

Layouts

Um unnötige erneute Layouts auszuschließen, führt das Ändern von Page.ShowsNavigationUI nicht mehr zu einem ungültigen Layout oder verursacht einen anderen Layoutdurchlauf.

Wenn Sie erwarten, dass das Ändern von ShowsNavigationUI zu einem anderen Layoutdurchlauf führt, rufen Sie nach dem Festlegen der Eigenschaft UIElement.InvalidateVisual auf.

Menüs

Um ClearType-Text in Menüpopups zu aktivieren, wurden Änderungen an der ControlTemplate-Klasse und dem MenuItem-Steuerelement sowie anderen Steuerelementen vorgenommen.

Anwendungen sollten sich nicht auf die visuelle Struktur von Steuerelementvorlagen stützen. Nur benannte Teile einer ControlTemplate sind Bestandteil des öffentlichen Vertrags. Wenn eine Anwendung ein bestimmtes Objekt in einer ControlTemplate suchen muss, durchsuchen Sie die visuelle Struktur nach einem bestimmten Typ anstatt sich auf eine feste Position eines Objekts in der Struktur zu stützen.

Navigieren

Wenn ein Frame direkt zu einem Speicherort navigiert, ist die IsNavigationInitiator-Eigenschaft true nach der ursprünglichen Navigation. Diese Änderung verhindert, dass zusätzliche Ereignisse während Startszenarien ausgelöst werden.

Keine.

Popups

Der CustomPopupPlacementCallback-Delegat kann nun während einer Layoutübergabe mehrmals statt nur ein Mal aufgerufen werden.

Wenn der CustomPopupPlacementCallback-Delegat die Position von einem Popup anhand der vorherigen Position berechnet, berechnen Sie die Position nur neu, wenn sich die Werte der Parameter popupSize, targetSize oder offset ändern.

Eigenschaftswerte

Die DependencyObject.SetCurrentValue-Methode bietet nun die Möglichkeit, eine Eigenschaft auf einen gültigen Wert festzulegen, wobei alle Bindungen, Stile oder Trigger beachtet werden, die sich auf die Eigenschaft auswirken.

Steuerelementautoren sollten SetCurrentValue immer dann verwenden, wenn sich der Eigenschaftswert als Nebenwirkung einer anderen Aktion ändert, einschließlich der Bearbeitung durch den Benutzer.

Textfelder

Aus Sicherheitsgründen schlagen die Methoden TextBoxBase.Copy und TextBoxBase.Cut ohne Fehlermeldung fehl, wenn sie mit partieller Vertrauensstellung aufgerufen werden.

Außerdem wird die programmgesteuerte Ausführung der ApplicationCommands.Copy-Eigenschaft oder ApplicationCommands.Cut-Eigenschaft in einem Steuerelement, das von TextBoxBase erbt, bei partieller Vertrauensstellung blockiert. Vom Benutzer initiierte Befehle zum Kopieren und Ausschneiden, wie z. B. das Klicken auf eine Schaltfläche, deren ButtonBase.Command-Eigenschaft an einen dieser Befehle gebunden ist, funktionieren jedoch. Standardkopieren und -ausschneiden über Tastenkombinationen und das Kontextmenü funktionieren immer noch wie zuvor in der partiellen Vertrauensstellung.

Binden Sie den ApplicationCommands.Copy-Befehl oder ApplicationCommands.Cut-Befehl an eine benutzerinitiierte Aktion, z. B. das Klicken auf eine Schaltfläche.

Zurück nach oben

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 Leistungssteigerung sind die BitmapEffect-Klasse und die Klassen, die von der BitmapEffect-Klasse erben, zwar noch vorhanden, aber deaktiviert. Der Effekt wird mit der hardwarebeschleunigten Pipeline gerendert, wenn die folgenden Bedingungen erfüllt sind:

  • Die Anwendung verwendet einen DropShadowBitmapEffect oder einen BlurBitmapEffect, dessen Radiuseigenschaft auf einen Wert unter 100 DIU festgelegt ist.

  • Die Videokarte auf dem Computer, auf dem die Anwendung ausgeführt wird, unterstützt Pixel Shader 2.0.

Wenn diese Bedingungen nicht erfüllt sind, hat ein BitmapEffect-Objekt keine Auswirkungen.

Außerdem erstellt Visual Studio 2010 eine Compilerwarnung, wenn es auf das BitmapEffect-Objekt oder eine Unterklasse stößt.

Die PushEffect-Methode ist als veraltet gekennzeichnet.

Stellen Sie die Verwendung des Vorgänger-BitmapEffect und abgeleiteter Klassen ein, und verwenden Sie stattdessen die neuen Klassen, die von Effect: BlurEffect, DropShadowEffect und ShaderEffect abgeleitet werden.

Sie können auch eigene Effekte erstellen, indem Sie von der ShaderEffect-Klasse erben.

Bitmapframes

Die geklonten BitmapFrame-Objekte empfangen nun die Ereignisse DownloadProgress, DownloadCompleted und DownloadFailed. Dadurch werden Bilder aktiviert, die aus dem Internet heruntergeladen und über einen Style auf das Image-Steuerelement angewendet werden, damit sie einwandfrei funktionieren.

Sie stellen nur eine Änderung im Verhalten fest, wenn die folgenden Aussagen zutreffen:

Überprüfen Sie den Absender im Ereignishandler, und handeln Sie nur, wenn der Absender der ursprüngliche BitmapFrame ist.

Decodieren von Bildern

Um zu verhindern, dass eine IOException nicht behandelt wird, wenn Bilder möglicherweise nicht decodiert werden, löst die BitmapSource-Klasse das DecodeFailed-Ereignis aus, wenn kein Bild decodiert wird.

Entfernen Sie alle Ausnahmebehandlungen für IOException, und verwenden Sie das DecodeFailed-Ereignis für die Überprüfung auf Decodierungsfehler.

Zurück nach oben

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 zum Binden von ansichtsmodellbasierten Befehlsinstanzen an ansichtsbasierte Eingabegesten bereitzustellen, erbt die InputBinding-Klasse jetzt von Freezable und nicht von DependencyObject. Die folgenden Eigenschaften sind jetzt Abhängigkeitseigenschaften:

Diese Änderung hat folgende Auswirkungen:

  • Ein InputBinding-Objekt wird jetzt gesperrt, wenn es registriert wird, anstatt veränderbar zu bleiben.

  • Aufgrund der Einschränkungen der DependencyObject-Klasse können Sie nicht aus mehreren Threads auf InputBinding-Objekte auf Instanzebene zugreifen.

  • Aufgrund der Einschränkungen der Freezable-Klasse können Sie keine Eingabebindungen auf Klassenebene nach ihrer Registrierung binden.

  • Sie können keine Eingabebindungen für Befehlsinstanzen angeben, die in einem Ansichtsmodell erstellt werden.

Erstellen Sie separate Instanzen einer InputBinding-Klasse für separate Threads, wenn Bindungen änderbar sein sollen, oder fixieren Sie sie andernfalls. Verändern Sie keine statische InputBinding auf Klassenebene nach ihrer Registrierung.

Browseranwendungen

WPF-Browseranwendungen (.XBAP) verarbeiten Tastenereignisse jetzt auf die gleiche Weise wie eigenständig WPF-Anwendungen, sodass Objekte weitergeleitete Tastenereignisse in der richtigen Reihenfolge empfangen.

Keine.

Unbelegte Tastenkombinationen

WPF verbirgt unbelegte Tasten, die kein sichtbares Zeichen erzeugen, gibt aber stattdessen an, dass die Taste mit der nächsten Buchstabentaste kombiniert werden soll, um ein Zeichen zu erzeugen. Die Tasteneingabeereignisse wie das KeyDown-Ereignis melden, wenn eine Taste unbelegt ist, indem die Key-Eigenschaft auf den DeadCharProcessed-Wert festgelegt wird. Dies ist normalerweise erwartetes Verhalten, da Anwendungen in der Regel nicht beabsichtigen, auf Tastatureingaben zu reagieren, die ein kombiniertes Zeichen erstellen.

Anwendungen, die erwarten, Tasten zu lesen, die Teil von kombinierten Zeichen waren, können jetzt die verborgene Taste mit der DeadCharProcessedKey-Eigenschaft abrufen.

Fokus-Manager

Wenn der FocusManager.GetFocusedElement-Methode ein Element übergeben wird, für das die angefügte IsFocusScope-Eigenschaft auf true festgelegt ist, gibt die Methode ein Element zurück, das das letzte tastaturfokussierte Element in diesem Fokusbereich ist, wenn das zurückgegebene Element zum gleichen PresentationSource-Objekt gehört wie das Element, das an die Methode übergeben wird.

Keine.

Zurück nach oben

Benutzeroberflächenautomatisierung

Namespace: 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 Klassen TreeViewAutomationPeer und TreeViewItemAutomationPeer erben von ItemsControlAutomationPeer anstelle von FrameworkElementAutomationPeer.

Wenn Sie von den TreeViewItemAutomationPeer-Klassen erben und die GetChildrenCore-Methode überschreiben, ziehen Sie in Erwägung, ein Objekt zurückzugeben, das von der neuen TreeViewDataItemAutomationPeer-Klasse erbt.

Container außerhalb des Bildschirmbereichs

Um einen falschen Rückgabewert zu korrigieren, gibt die UIElementAutomationPeer.IsOffscreenCore-Methode jetzt ordnungsgemäß false für Elementcontainer zurück, die durch einen Bildlauf außerhalb der Ansicht liegen. Ob das Element von anderen Fenstern verdeckt ist oder auf einem bestimmten Bildschirm angezeigt wird, hat keine Auswirkungen auf den Wert der Methode.

Keine.

Menüs und untergeordnete Objekte

Um die Benutzeroberflächenautomatisierung von Menüs zu aktivieren, die andere untergeordnete Elemente als MenuItem-Objekte enthalten, gibt die GetChildrenCore-Methode jetzt das AutomationPeer-Objekt eines untergeordneten UIElement-Objekts zurück und kein MenuItemAutomationPeer-Objekt.

Keine.

Neue Schnittstellen und Assembly

Um neue Funktionen für die Benutzeroberflächenautomatisierung zu aktivieren, wurden die folgenden Schnittstellen hinzugefügt:

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. Daher melden Steuerelemente wie GridSplitter, die von der Thumb-Klasse erben, einen Namen an die Benutzeroberflächenautomatisierung.

Keine.

Virtualisierte Elemente

Zur Verbesserung der Leistung gibt die UIElementAutomationPeer.GetChildrenCore-Methode anstelle aller untergeordneten Objekte nur die untergeordneten Objekte zurück, die sich tatsächlich in der visuellen Struktur befinden, und zwar unabhängig davon, ob sie virtualisiert sind.

Verwenden Sie ItemContainerPattern, um alle Elemente eines ItemsControlAutomationPeer zu durchlaufen.

Zurück nach oben

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 MarkupExtension-Methode anstatt in bestimmten Fällen das MarkupExtension.ProvideValue-Objekt zurückzugeben, wenn eine Markuperweiterung verwendet wird, um eine Eigenschaft festzulegen oder ein Element in einer Auflistung zu erstellen. Eine Markuperweiterung könnte sich in einigen Fällen selbst zurückgeben.

Wenn die Anwendung auf eine Ressource zugreift, die in früheren Versionen ein MarkupExtension-Objekt zurückgegeben hat, verweisen Sie auf das Objekt, das von ProvideValue zurückgegeben wird, nicht auf das MarkupExtension-Objekt.

Analysieren von Attributen

Attribute in XAML können jetzt nur über einen Punkt verfügen. Folgende Beispiele sind gültig:

<Button Background="Red"/> (keine Punkte)

<Button Button.Background = "Red"/> (ein Punkt)

Das folgende Beispiel ist nicht mehr gültig:

<Button Control.Button.Background = "Red"/> (mehr als ein Punkt)

Korrigieren Sie XAML-Attribute mit mehr als einem Punkt.

Zurück nach oben

XML

In den Zeilen der folgenden Tabelle werden Verbesserungen an Funktionen beschrieben, die zuvor Einschränkungen oder andere Probleme aufwiesen.

Schema 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ädigungen zu verhindern, werden Chamäleonschemas jetzt ordnungsgemäß geklont, wenn sie in mehreren Schemas eingeschlossen werden.

Chamäleonschemas sind Schemas, die nicht über einen Zielnamespace verfügen. Wenn sie in einem anderen XSD eingeschlossen werden, nehmen sie den Zielnamespace des importierenden Schemas an. Sie werden häufig verwendet, um allgemeine Typen in ein Schema einzuschließen.

ID-Funktionen

Die XSLT-ID-Funktion gibt jetzt den richtigen Wert statt NULL zurück, wenn ein XmlReader-Objekt an einen XLST übergeben wird.

Wenn der Benutzer ein XmlReader-Objekt mit der CreateReader-Methode aus einer LINQ to XML-Klasse erstellt hat und dieses XmlReader-Objekt an ein XSLT übergeben wurde, gaben alle Instanzen der id-Funktion im XSLT zuvor NULL zurück. Dies ist kein zulässiger Rückgabewert für die id-Funktion.

Namespaceattribut

Um Datenbeschädigungen zu verhindern, gibt ein XPathNavigator-Objekt jetzt ordnungsgemäß den lokalen Namen des x:xmlns-Attributs zurück.

Namespacedeklarationen

Ein XmlReader-Objekt in einer Teilstruktur erstellt nicht mehr doppelte Namespacedeklarationen innerhalb eines XML-Elements.

Schemavalidierung

Um eine falsche Schemavalidierung zu verhindern, ermöglicht die XmlSchemaSet-Klasse das richtige und konsistente Kompilieren von XSD-Schemas. Diese Schemas können andere Schemas einschließen. A.xsd kann z. B. B.xsd einschließen, das C.xsd einschließen kann. Das Kompilieren führt in diesen Fällen dazu, dass dieses Diagramm von Abhängigkeiten durchlaufen wird.

Skriptfunktionen

Die function-available-Funktion gibt nicht mehr fälschlicherweise false zurück, wenn die Funktion eigentlich verfügbar ist.

URIs

Die XElement.Load-Methode gibt jetzt den richtigen BaseURI in LINQ-Abfragen zurück.

Zurück nach oben

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

Namespaceresolver

Die XmlReader.ReadContentAs-Methode ignoriert nicht mehr den an sie übergebenen IXmlNamespaceResolver-Resolver.

In früheren Versionen wurde der angegebene Namespaceresolver ignoriert und stattdessen der XmlReader verwendet.

Leerraum

Um Datenverlust beim Erstellen eines Readers zu verhindern, verwirft die XmlReader.Create-Methode signifikanten Leerraum nicht mehr.

Die XML-Validierung erkennt den Modus für gemischten Inhalt, bei dem Text mit XML-Markup gemischt werden kann. Im gemischten Modus ist der gesamte Leerraum signifikant und sollte gemeldet werden.

Zurück nach oben

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ädigungen zu verhindern, werden Entitätsverweise in XML-Attributen nicht mehr zweimal durch Entitätenzeichen ersetzt.

Wenn der Benutzer versucht hat, eine Entität mit der WriteEntityRef-Methode in ein xmlns-Attribut, ein xml:lang-Attribut oder xml:space-Attribut zu schreiben, wurde die Entität in der Ausgabe zweimal durch Entitätenzeichen ersetzt, und die Daten wurden so beschädigt.

Behandlung von neuen Zeilen

Um Datenbeschädigungen zu verhindern, berücksichtigen XmlWriter-Objekte die None-Option.

Zurück nach oben

Siehe auch

Konzepte

Neues in .NET Framework 4

Weitere Ressourcen

Migrationshandbuch zu .NET Framework 4

Kompatibilität von .NET Framework-Versionen

Veraltete Elemente in .NET Framework

Neue Typen und Member in .NET Framework 4

Migrationsprobleme bei .NET Framework 4-Anwendungen: Beta 2 zu RTM

Migrieren von Office-Lösungen zu .NET Framework 4

Änderungsprotokoll

Datum

Versionsgeschichte

Grund

August 2010

Weitere Aspekte zum Hosten von Steuerelementen im Webbrowser, zu Compilerklassen und CodeDOM und zum Viewer des globalen Assemblycaches.

Informationsergänzung.