Migrationsprobleme in .NET Framework 4

2025-06-20

In diesem Artikel werden Migrationsprobleme zwischen .NET Framework, Version 3.5 Service Pack 1 und .NET Framework, Version 4, beschrieben, einschließlich Korrekturen, Änderungen für Die Einhaltung von Standards und Sicherheit sowie Änderungen basierend auf Kundenfeedback. Die meisten dieser Änderungen erfordern keine Programmieränderungen in Ihren Anwendungen. Informationen zu Änderungen finden Sie in der Spalte " Empfohlene Änderungen " der Tabelle. Wichtige Änderungen werden nach Bereich aufgeschlüsselt, z. B. ASP.NET und Windows Presentation Foundation (WPF).

Eine allgemeine Übersicht über die Probleme in diesem Artikel finden Sie im Migrationshandbuch zu .NET Framework 4.

Informationen zu neuen Features finden Sie unter What's New 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“)

Merkmal	Unterschiede von 3.5 SP1	Empfohlene Änderungen
Browserdefinitionsdateien	Die Browserdefinitionsdateien wurden aktualisiert, um Informationen zu neuen und aktualisierten Browsern und Geräten einzuschließen. Ältere Browser und Geräte wie Netscape Navigator wurden entfernt, und neuere Browser und Geräte wie Google Chrome und Apple iPhone wurden hinzugefügt. Wenn Ihre Anwendung benutzerdefinierte Browserdefinitionen enthält, die von einer der entfernten Browserdefinitionen erben, wird ein Fehler angezeigt. Das HttpBrowserCapabilities Objekt (das durch die Eigenschaft der Seite verfügbar gemacht wird) wird durch die Browserdefinitionsdateien `Request.Browse` gesteuert. Daher unterscheiden sich die Informationen, die durch den Zugriff auf eine Eigenschaft dieses Objekts in ASP.NET 4 zurückgegeben werden, möglicherweise von den Informationen, die in einer früheren Version von ASP.NET zurückgegeben wurden.	Wenn Ihre Anwendung auf die alten Browserdefinitionsdateien angewiesen ist, 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 Aspnet_regbrowsers.exe Befehlszeilentool aus. Weitere Informationen finden Sie auf der https://www.asp.net/mobile Website.
Untergeordnete Anwendungen, die unter gemischten Versionen von ASP.NET ausgeführt werden	ASP.NET 4-Anwendungen, die als untergeordnete Anwendungen konfiguriert sind, die frühere Versionen von ASP.NET ausführen, können möglicherweise aufgrund von Kompilierungs- oder Konfigurationsfehlern nicht starten. Der spezifische 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.	Sie können Änderungen an den Konfigurationsdateien der betroffenen Anwendungen vornehmen, damit das Konfigurationssystem die ASP.NET 4-Anwendung richtig 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).
ClientID-Änderungen	Mit der neuen `clientIDMode` Einstellung 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 entspricht das Standardverhalten der `AutoID` Einstellung von `clientIDMode`. Die Standardeinstellung ist jetzt `Predictable`. Weitere Informationen finden Sie unter ASP.NET Web Server Control Identification.	Wenn Sie Visual Studio zum Upgrade Ihrer Anwendung von ASP.NET 2.0 oder ASP.NET 3.5 verwenden, fügt das Tool automatisch eine Einstellung zur Web.config Datei hinzu, die das Verhalten früherer Versionen von .NET Framework behält. Wenn Sie jedoch ein Upgrade einer Anwendung durchführen, indem Sie den Anwendungspool in IIS auf .NET Framework 4 ändern, verwendet ASP.NET standardmäßig den neuen Modus. Um den neuen Client-ID-Modus zu deaktivieren, fügen Sie der datei Web.config die folgende Einstellung hinzu: `<pages clientIDMode="AutoID" />`
Codezugriffssicherheit (Code Access Security, CAS)	ASP.NET 2.0 NET-Features, die in ASP.NET 3.5 hinzugefügt wurden, verwenden das .NET Framework 1.1- und .NET Framework 2.0-Codezugriffssicherheitsmodell (CAS). Die Umsetzung der CAS in ASP.NET 4 wurde jedoch erheblich überarbeitet. 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 teilweise vertrauenswürdige ASP.NET 4 Anwendungen auf das Verhalten von ASP.NET 1.1 und 2.0 zurücksetzen, indem Sie das neue `legacyCasModel` Attribut im `trust` Konfigurationselement verwenden, wie im folgenden Beispiel gezeigt: `<trust level= "Medium" legacyCasModel="true" />` Wichtig: Das Zurücksetzen auf das ältere CAS-Modell kann eine reduzierte Sicherheit darstellen. Weitere Informationen zum neuen ASP.NET 4 Codezugriffssicherheitsmodell finden Sie unter Code Access Security in ASP.NET 4 Applications.
Konfigurationsdateien	Die Stammkonfigurationsdateien (die machine.config-Datei und die Web.config-Stammdatei) für .NET Framework und ASP.NET 4 wurden aktualisiert, um die meisten Konfigurationsinformationen zu enthalten, die in der Anwendung Web.config Dateien in ASP.NET 3.5 gefunden wurden. 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 mithilfe der Projektupgradetools in Visual Studio auf ASP.NET 4. Visual Studio 2010 ändert die Web.config-Datei der ASP.NET 3.5-Anwendung automatisch so, dass 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 erneute Kompilierung ausführen. In diesem Fall müssen Sie die Web.config Datei der Anwendung möglicherweise manuell ändern, bevor Sie die Anwendung unter .NET Framework 4 und unter IIS 7 oder IIS 7.5 ausführen. Die spezifische Änderung, die Sie vornehmen müssen, hängt von der Kombination von Software ab, mit der Sie arbeiten, einschließlich Service Pack (SP)-Versionen. Informationen zu den möglichen Softwarekombinationen, die von dieser Änderung betroffen sind und wie Sie Probleme mit bestimmten Kombinationen beheben können, finden Sie im Dokument "Konfigurationsfehler im Zusammenhang mit der neuen ASP.NET 4-Stammkonfiguration" im Dokument ASP.NET 4 Breaking Changes on the ASP.NET Website.
Steuerung des Renderings	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: * Die Steuerelemente `Image` und `ImageButton` rendern kein `border="0"`-Attribut mehr. * Die `BaseValidator`-Klasse und die Validierungssteuerelemente, die sich davon ableiten, rendern standardmäßig keinen rot formatierten Text mehr. * Das `HtmlForm` Steuerelement zeigt kein `name`-Attribut. * Das `Table` Steuerelement rendert kein `border="0"` Attribut mehr. Steuerelemente, die nicht für die Benutzereingabe vorgesehen sind (z. B. das `Label` Steuerelement), rendern das `disabled="disabled"` Attribut nicht mehr, wenn ihre `Enabled` Eigenschaft auf festgelegt `false` ist (oder wenn sie diese Einstellung von einem Containersteuerelement erben).	Wenn Sie Visual Studio verwenden, um die Anwendung von ASP.NET 2.0 oder ASP.NET 3.5 zu aktualisieren, fügt das Tool automatisch eine Einstellung zur Web.config Datei hinzu, die das ältere Rendering bewahrt. Wenn Sie jedoch ein Upgrade einer Anwendung durchführen, indem Sie den Anwendungspool in IIS auf .NET Framework 4 ändern, verwendet ASP.NET standardmäßig den neuen Renderingmodus. Um den neuen Renderingmodus zu deaktivieren, fügen Sie der datei Web.config die folgende Einstellung hinzu: `<pages controlRenderingCompatibilityVersion="3.5" />`
Ereignishandler in Standarddokumenten	ASP.NET 4 rendert den Attributwert des `form` HTML-Elements `action` als leere Zeichenfolge, wenn eine Anforderung an eine erweiterungslose URL gestellt wird, die einem Standarddokument zugeordnet ist. In früheren Versionen von ASP.NET würde eine Anforderung an `http://contoso.com` zu Default.aspx führen. In diesem Dokument wurde das öffnende `form`-Tag wie im folgenden Beispiel gerendert: `<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 HTML-Starttag `form`, wie im folgenden Beispiel: `<form action="" />` Wenn das `action` Attribut eine leere Zeichenfolge ist, erstellt das IIS-Objekt `DefaultDocumentModule` eine untergeordnete Anforderung zum 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. Wenn die folgenden Bedingungen auftreten, führt die untergeordnete Anforderung an ein Standarddokument im Format .aspx zu einem Fehler oder zu unerwartetem Verhalten: * Eine .aspx Seite wird an den Browser gesendet, wobei das `form` Attribut des `action` Elements auf "" festgelegt ist. * Das Formular wird zurück zu ASP.NET gepostet. * Ein verwaltetes HTTP-Modul liest einen Teil des Entitätstexts, wie `Request.Form` oder `Request.Params`. Dies führt dazu, dass der Entitätstext der POST-Anforderung in einen verwalteten Speicher eingelesen wird. Daher ist der Entitätstext nicht mehr für systemeigene Codemodule verfügbar, die im integrierten IIS 7- oder IIS 7.5-Modus ausgeführt werden. * Das IIS-Objekt `DefaultDocumentModule` wird schließlich ausgeführt und erstellt eine untergeordnete Anforderung an das Default.aspx Dokument. 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 Entitätskörper vorhanden ist, gibt es keine Formularvariablen und keinen Ansichtszustand. Daher sind keine Informationen für den .aspx Seitenhandler verfügbar, um zu bestimmen, welches Ereignis (falls 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).
Hashingalgorithmus	ASP.NET verwendet Verschlüsselungs- und Hashingalgorithmen, um Daten wie Formularauthentifizierungscookies und Ansichtszustand zu sichern. Standardmäßig verwendet ASP.NET 4 den HMACSHA256 Algorithmus für Hashvorgänge für 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, wobei Daten wie Formularauthentifizierungscookies in .NET Framework-Versionen funktionieren müssen, konfigurieren Sie eine ASP.NET 4-Webanwendung, um den älteren HMACSHA1 Algorithmus zu verwenden, indem Sie die folgende Einstellung in der datei Web.config hinzufügen: `<machineKey validation="SHA1" />`
Hosten von Steuerelementen in Internet Explorer	Sie können Windows Forms-Steuerelemente nicht mehr im Internet Explorer hosten, da 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.	Sie können die folgenden Technologien für die entwicklung 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 WPF-Funktionen zu nutzen (erfordert .NET Framework auf Clientcomputern). Weitere Informationen finden Sie in der Übersicht über WPF-XAML-Browseranwendungen.
HtmlEncode- und UrlEncode-Methoden	Die `HtmlEncode` und `UrlEncode` Methoden der Klassen HttpUtility und HttpServerUtility wurden aktualisiert, um das einfache Anführungszeichen (') wie folgt zu codieren: * Die `HtmlEncode` Methode codiert Instanzen des einzelnen Anführungszeichens als `'` * Die `UrlEncode` Methode codiert Instanzen des einzelnen Anführungszeichens als `%27`	Überprüfen Sie Ihren Code auf Stellen, an denen Sie die `HtmlEncode` Methoden `UrlEncode` verwenden, und stellen Sie sicher, dass die Änderung der Codierung nicht zu einer Änderung führt, die sich auf Ihre Anwendung auswirken würde.
HttpException-Fehler in ASP.NET 2.0-Anwendungen	Nachdem ASP.NET 4 auf IIS 6 aktiviert wurde, können ASP.NET 2.0-Anwendungen, die auf IIS 6 ausgeführt werden (entweder unter Windows Server 2003 oder Windows Server 2003 R2) Fehler wie die folgenden generieren: `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 erforderlich ist, um die Website auszuführen, verschieben Sie alle untergeordneten ASP.NET 2.0 virtuellen Verzeichnisse auf eine andere Website, die ASP.NET 2.0 zugeordnet ist. -oder- * Deaktivieren Sie erweiterungslose URLs. Weitere Informationen finden Sie im Dokument ASP.NET 4 Breaking Changes auf der ASP.NET-Website unter "ASP.NET 2.0-Anwendungen können HttpException-Fehler erzeugen, die auf eurl.axd verweisen".
Mitgliedschaftstypen	Einige Typen (z. B. MembershipProvider), die in der ASP.NET-Mitgliedschaft verwendet werden, wurden von der System.Web.dll- in die System.Web.ApplicationServices.dll-Assembly verschoben. Die Typen wurden verschoben, um Architekturschichtabhängigkeiten zwischen Typen im Client und in erweiterten .NET Framework-SKUs aufzulösen.	Klassenbibliotheken, die von früheren Versionen von ASP.NET aktualisiert wurden und mitgliedschaftstypen verwenden, die verschoben wurden, können möglicherweise nicht kompiliert werden, wenn sie in einem ASP.NET 4-Projekt verwendet werden. Wenn ja, fügen Sie im Klassenbibliotheksprojekt einen Verweis auf System.Web.ApplicationServices.dllhinzu.
Menüsteuerelementänderungen	Änderungen am Menu Steuerelement führen zu folgendem Verhalten: * Wenn MenuRenderingMode auf `List` gesetzt ist, oder wenn MenuRenderingMode auf `Default` gesetzt ist und ControlRenderingCompatibilityVersion auf `4.0` oder später gesetzt ist, hat die PopOutImageUrl-Eigenschaft keine Auswirkung. * Wenn der Pfad, der in den Eigenschaften StaticPopOutImageUrl und DynamicPopOutImageUrl festgelegt ist, einen umgekehrten Schrägstrich (\) enthält, werden die Bilder nicht gerendert. (In früheren Versionen von ASP.NET konnte der Pfad einen Backslash enthalten.)	* Legen Sie anstelle der PopOutImageUrl-Eigenschaft für einzelne Menüelemente die StaticPopOutImageUrl- oder DynamicPopOutImageUrl-Eigenschaft des übergeordneten Menu-Steuerelements fest. -oder- Setzen Sie MenuRenderingMode auf `Table`, oder setzen Sie MenuRenderingMode auf `Default` und ControlRenderingCompatibilityVersion auf `3.5`. Diese Einstellungen führen dazu, dass das Menu Steuerelement das tabellenbasierte HTML-Layout verwendet, das es in früheren Versionen von ASP.NET verwendet. * 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 wurde ein Verweis auf die System.Web.Mobile.dll-Assembly in der Stammdatei Web.config im `assemblies` Abschnitt unter `system.web`/`compilation` enthalten. Um die Leistung zu verbessern, wurde der Verweis auf diese Assembly entfernt. Hinweis: Die System.Web.Mobile.dll-Assembly und die ASP.NET mobilen Steuerelemente sind in ASP.NET 4 enthalten, sind jedoch veraltet.	Wenn Sie Typen aus dieser Assembly verwenden möchten, fügen Sie in der Stammdatei Web.config Datei oder in einer Anwendung Web.config Datei einen Verweis auf die Assembly hinzu.
Ausgabezwischenspeicherung	In ASP.NET 1.0 führte ein Fehler dazu, dass zwischengespeicherte Seiten, die `Location="ServerAndClient"` als Ausgabecacheeinstellung angegeben hatten, einen `Vary:` HTTP-Header in der Antwort erzeugten. Dies hatte zur Folge, dass Client-Browser die Seite nie lokal zwischenspeichern. In ASP.NET 1.1 wurde die SetOmitVaryStar Methode hinzugefügt, die aufgerufen werden konnte, um die `Vary:` Kopfzeile zu unterdrücken. Fehlerberichte deuten jedoch darauf hin, 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 ist die SetOmitVaryStar Methode nicht mehr erforderlich, um die `Vary:` Kopfzeile zu unterdrücken. In Anwendungen, die "ServerAndClient" für das `Location` Attribut angeben, können Seiten im Browser zwischengespeichert werden, ohne dass Sie aufrufen SetOmitVaryStarmüssen.	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 Ausgabezwischenspeicherungsattributs `Location` in "Server" ändern.
Seitenanalyse	Der Seitenparser für ASP.NET Webseiten (.aspx Dateien) und Benutzersteuerelemente (ASCX-Dateien) ist in ASP.NET 4 strenger als in früheren Versionen von ASP.NET und kennzeichnet mehr Markup als ungültig als in früheren Versionen.	Überprüfen Sie Fehlermeldungen, die beim Ausführen einer Seite erzeugt werden, und beheben Sie Fehler, die aus ungültigem Markup resultieren.
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 im Zusammenhang mit Passport in System.Web.Security jetzt mit dem `ObsoleteAttribute` Attribut gekennzeichnet.	Ändern Sie jeglichen Code, der Passport-Typen im System.Web.Security-Namespace verwendet (z. B. PassportIdentity), um das Windows Live ID SDK zu nutzen.
PathInfo-Informationen in der FilePath-Eigenschaft	ASP.NET 4 enthält nicht mehr den `PathInfo` Wert in den Rückgabewerten von Eigenschaften wie FilePath, und AppRelativeCurrentExecutionFilePath CurrentExecutionFilePath. Stattdessen ist die `PathInfo` Information in PathInfo verfügbar. Stellen Sie sich beispielsweise das folgende URL-Fragment vor: `/testapp/Action.mvc/SomeAction` In früheren Versionen von ASP.NET HttpRequest weisen Eigenschaften die folgenden Werte auf: * FilePath: `/testapp/Action.mvc/SomeAction` * PathInfo: (leer) In ASP.NET 4 HttpRequest weisen Eigenschaften stattdessen die folgenden Werte auf: * FilePath: `/testapp/Action.mvc` * PathInfo: `SomeAction`	Überprüfen Sie den Code auf Stellen, an denen Sie auf Eigenschaften der HttpRequest-Klasse angewiesen sind, um Pfadinformationen zurückzugeben. Ändern Sie den Code, um die neue Art der Rückgabe von Pfadinformationen widerzuspiegeln.
Anforderungsüberprüfung	Um die Anforderungsüberprüfung zu verbessern, wird die ASP.NET Anforderungsüberprüfung weiter oben im Anforderungslebenszyklus aufgerufen. Daher wird die Anforderungsüberprüfung für Anforderungen ausgeführt, die nicht für .aspx Dateien gelten, z. B. für Webdienstaufrufe und für benutzerdefinierte Handler. Die Anforderungsüberprüfung 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 anforderungsüberprüfungsfehler auslösen. Benutzerdefinierter Code, der in der Anforderungspipeline ausgeführt wird (z. B. benutzerdefinierte HTTP-Module), löst möglicherweise auch Anforderungsüberprüfungsfehler aus.	Bei Bedarf können Sie das alte Verhalten wiederherstellen, dass nur .aspx Seiten die Anforderungsüberprüfung auslösen, indem Sie die folgende Einstellung in der Webkonfigurationsdatei verwenden: `<httpRuntime requestValidationMode="2.0" />` Warnung: Wenn Sie auf das alte Verhalten zurücksetzen, stellen Sie sicher, dass der gesamte Code in vorhandenen Handlern, Modulen und anderen benutzerdefinierten Code Überprüfungen auf potenziell unsichere HTTP-Eingaben durchführt, die XSS-Angriffsvektoren sein könnten.
Routing	Wenn Sie eine Dateisystemwebsite in Visual Studio 2010 erstellen und sich die Website in einem Ordner befindet, der einen Punkt (.) im Ordnernamen enthält, funktioniert das URL-Routing nicht zuverlässig. Ein HTTP 404-Fehler wird von einigen virtuellen Pfaden zurückgegeben. Dies tritt auf, da Visual Studio 2010 den Visual Studio Development Server unter Verwendung eines falschen Pfads für das virtuelle Stammverzeichnis startet.	* Ändern Sie auf der Seite Eigenschaften für die dateibasierte Website das Attribut Virtueller Pfad in "/". -oder- * Erstellen Sie ein Webanwendungsprojekt anstelle eines Websiteprojekts. Webanwendungsprojekte haben dieses Problem nicht, und das URL-Routing funktioniert auch dann, wenn der Projektordner einen Punkt im Namen hat. -oder- * Erstellen Sie eine HTTP-basierte Website, die in IIS gehostet wird. Von IIS gehostete Websites können Punkte im virtuellen Pfad sowie im Projektdateiordner 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 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. Daher sollten Sie nicht versuchen, eine ASP.NET 4-Website als untergeordnetes Element einer SharePoint-Website auszuführen.
XHTML 1.1-Standards	Um die XHTML 1.1-Compliance für neue Websites zu aktivieren, generieren die ASP.NET-Steuerelemente in .NET Framework 4 XHTML 1.1-kompatible HTML. Dieses Rendering wird mithilfe der folgenden Option in der Web.config Datei innerhalb des `<system.Web>` Elements aktiviert: `<pages controlRenderingCompatibilityVersion="4.0"/>` Diese Option ist standardmäßig auf 4.0 festgelegt. Webprojekte, die von Visual Studio 2008 aktualisiert werden, haben die Einstellung 3.5 für Kompatibilität aktiviert.	Keiner.

Kern