Freigeben über

ASP.NET 4: Bedeutende Änderungen

  • Artikel

In diesem Dokument werden Änderungen beschrieben, die für die .NET Framework Version 4 vorgenommen wurden, die sich möglicherweise auf Anwendungen auswirken können, die mit früheren Releases erstellt wurden, einschließlich der ASP.NET 4 Beta 1- und Beta 2-Versionen.

Laden Sie dieses Whitepaper herunter

Inhalte

ControlRenderingCompatibilityVersionseinstellung in der Web.config-Datei
ClientIDMode-Änderungen
HtmlEncode und UrlEncode codieren jetzt einzelne Anführungszeichen
ASP.NET Page (.aspx) Parser ist strenger
Browserdefinitionsdateien aktualisiert
System.Web.Mobile.dll aus der Stammwebkonfigurationsdatei entfernt
ASP.NET Anforderungsüberprüfung
Der Standardhashalgorithmus ist jetzt HMACSHA256
Konfigurationsfehler im Zusammenhang mit der neuen ASP.NET 4-Stammkonfiguration
ASP.NET 4 untergeordnete Anwendungen können nicht gestartet werden, wenn unter ASP.NET 2.0- oder ASP.NET 3.5-Anwendungen
ASP.NET 4 Websites können auf Computern, auf denen SharePoint installiert ist, nicht gestartet werden
Die HttpRequest.FilePath-Eigenschaft enthält keine PathInfo-Werte mehr.
ASP.NET 2.0-Anwendungen können HttpException-Fehler generieren, die auf eurl.axd verweisen
Ereignishandler werden in einem Standarddokument im integrierten IIS 7- oder IIS 7.5-Modus möglicherweise nicht ausgelöst.
Änderungen an der Implementierung von ASP.NET Code Access Security (CAS)
MembershipUser und andere Typen im System.Web.Security-Namespace wurden verschoben.
Änderungen an der Ausgabezwischenspeicherung in Vary * HTTP-Header
System.Web.Security Types for Passport sind veraltet
Die MenuItem.PopOutImageUrl-Eigenschaft kann ein Bild in ASP.NET 4 nicht rendern
Menu.StaticPopOutImageUrl und Menu.DynamicPopOutImageUrl können Bilder nicht rendern, wenn Pfade umgekehrte Schrägstriche enthalten
Haftungsausschluss

ControlRenderingCompatibilityVersionseinstellung in der Web.config-Datei

ASP.NET Steuerelemente wurden in der .NET Framework Version 4 geändert, damit Sie genauer angeben können, wie sie Markup rendern. In früheren Versionen der .NET Framework haben einige Steuerelemente Markup ausgegeben, das Sie nicht deaktivieren konnten. Standardmäßig wird ASP.NET 4 dieser Markuptyp nicht mehr generiert.

Wenn Sie Visual Studio 2010 zum Upgrade Ihrer Anwendung von ASP.NET 2.0 oder ASP.NET 3.5 verwenden, fügt das Tool der Datei automatisch eine Einstellung hinzu, die das Web.config Legacyrendering beibehalten. 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 der Datei die Web.config folgende Einstellung hinzu:

<pages controlRenderingCompatibilityVersion="3.5" />

Die wichtigsten Renderingänderungen, die das neue Verhalten mit sich bringt, sind wie folgt:

  • Die Steuerelemente Image und ImageButton rendern kein border="0" Attribut mehr.
  • Die BaseValidator-Klasse und die Validierungssteuerelemente, die daraus abgeleitet werden, rendern standardmäßig keinen roten Text mehr.
  • Das HtmlForm-Steuerelement rendert kein name-Attribut .
  • Das Table-Steuerelement rendert kein border="0" Attribut mehr.
  • Steuerelemente, die nicht für Benutzereingaben konzipiert sind (z. B. das Label-Steuerelement ), rendern das disabled="disabled" Attribut nicht mehr, wenn ihre Enabled-Eigenschaft auf false festgelegt ist (oder wenn sie diese Einstellung von einem Containersteuerelement erben).

ClientIDMode-Änderungen

Mit der 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 entsprach das Standardverhalten der AutoID-Einstellung von ClientIDMode. Die Standardeinstellung ist jedoch jetzt Vorhersagbar.

Wenn Sie Visual Studio 2010 verwenden, um Ihre Anwendung von ASP.NET 2.0 oder ASP.NET 3.5 zu aktualisieren, fügt das Tool der Datei automatisch eine Einstellung hinzu, die Web.config das Verhalten früherer Versionen des .NET Framework behä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 der Datei die Web.config folgende Einstellung hinzu:

<pages clientIDMode="AutoID" />

HtmlEncode und UrlEncode codieren jetzt einzelne Anführungszeichen

In ASP.NET 4 wurden die Methoden HtmlEncode und UrlEncode der HttpUtility - und HttpServerUtility-Klassen 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.

ASP.NET Page (.aspx) Parser ist strenger

Der Seitenparser für ASP.NET Seiten (.aspx Dateien) und Benutzersteuerelemente (.ascx Dateien) ist in ASP.NET 4 strenger und lehnt weitere Instanzen ungültiger Markups ab. Beispielsweise würden die folgenden beiden Codeausschnitte in früheren Releases von ASP.NET erfolgreich analysiert, lösen jetzt aber Parserfehler in ASP.NET 4 aus.

<asp:HiddenField runat="server" ID="SomeControl" Value="sampleValue"  ; />

Beachten Sie das ungültige Semikolon am Ende des HiddenField-Tags .

<asp:LinkButton runat="server" ID="SomeControl" onclick="someControlClicked"
      style="display:inline;  CssClass="searchLink"  />

Beachten Sie das nicht geschlossene Stilattribut , das in das CssClass-Attribut ausgeführt wird.

Browserdefinitionsdateien aktualisiert

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. Wenn der App_Browsers Ordner beispielsweise eine Browserdefinition enthält, die von der IE2-Browserdefinition erbt, erhalten Sie die folgende Konfigurationsfehlermeldung:

  • Das Browser- oder Gatewayelement mit der ID "IE2" wurde nicht gefunden.

Hinweis

Das HttpBrowserCapabilities-Objekt (das durch die Request.Browser-Eigenschaft der Seite verfügbar gemacht wird) wird von den Browserdefinitionsdateien gesteuert. Daher können sich die Durch den Zugriff auf eine Eigenschaft dieses Objekts in ASP.NET 4 zurückgegebenen Informationen von den in einer früheren Version von ASP.NET zurückgegebenen Informationen unterscheiden.

Sie können die alten Browserdefinitionsdateien rückgängig machen, indem Sie die Browserdefinitionsdateien aus dem folgenden Ordner kopieren:

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

Kopieren Sie die Dateien für ASP.NET 4 in den entsprechenden \CONFIG\Browsers Ordner. Führen Sie nach dem Kopieren der Dateien das Befehlszeilentool Aspnet_regbrowsers.exe aus.

System.Web.Mobile.dll aus der Stammwebkonfigurationsdatei entfernt

In früheren Versionen von ASP.NET wurde in der Stammdatei Web.config im Abschnitt Assemblys unter ein Verweis auf die System.Web.Mobile.dll-Assembly enthalten. Um die Leistung zu verbessern, wurde der Verweis auf diese Assembly entfernt.

Die System.Web.Mobile.dll Assembly ist in ASP.NET 4 enthalten, ist aber veraltet. Wenn Sie Typen aus der System.Web.Mobile.dll Assembly verwenden möchten, fügen Sie entweder der Stammdatei Web.config oder einer Anwendungsdatei Web.config einen Verweis auf diese Assembly hinzu. Wenn Sie beispielsweise eines der (veralteten) ASP.NET mobilen Steuerelemente verwenden möchten, müssen Sie der Web.config Datei einen Verweis auf die System.Web.Mobile.dll-Assembly hinzufügen.

ASP.NET Anforderungsüberprüfung

Die Anforderungsüberprüfungsfunktion in ASP.NET bietet einen bestimmten Standardschutz vor XSS-Angriffen (Cross-Site Scripting). In früheren Versionen von ASP.NET war die Anforderungsüberprüfung standardmäßig aktiviert. Es wurde jedoch nur auf ASP.NET Seiten (.aspx Dateien und deren Klassendateien) angewendet, und nur, wenn diese Seiten ausgeführt wurden.

In ASP.NET 4 ist die Anforderungsüberprüfung standardmäßig für alle Anforderungen aktiviert, da sie vor der BeginRequest-Phase einer HTTP-Anforderung aktiviert ist. Daher gilt die Anforderungsüberprüfung für Anforderungen für alle ASP.NET Ressourcen, nicht nur für ASPX-Seitenanforderungen. Dies umfasst Anforderungen wie Webdienstaufrufe und benutzerdefinierte HTTP-Handler. Die Anforderungsüberprüfung ist auch aktiv, wenn benutzerdefinierte HTTP-Module den Inhalt einer HTTP-Anforderung lesen.

Daher können nun Anforderungsüberprüfungsfehler für Anforderungen auftreten, die zuvor keine Fehler ausgelöst haben. Um das Verhalten der ASP.NET 2.0-Anforderungsüberprüfungsfunktion zu rückgängig machen, fügen Sie der Datei die Web.config folgende Einstellung hinzu:

<httpRuntime requestValidationMode="2.0" />

Es wird jedoch empfohlen, alle Anforderungsüberprüfungsfehler zu analysieren, um zu ermitteln, ob vorhandene Handler, Module oder andere benutzerdefinierte Codezugriffe möglicherweise unsichere HTTP-Eingaben aufweisen, bei denen es sich um XSS-Angriffsvektoren handeln könnte.

Der Standardhashalgorithmus ist jetzt HMACSHA256

ASP.NET verwendet sowohl Verschlüsselung als auch Hashalgorithmen, um Daten wie Formularauthentifizierungscookies und den Ansichtsstatus zu sichern. Standardmäßig verwendet ASP.NET 4 jetzt den HMACSHA256-Algorithmus für Hashvorgänge für Cookies und den Ansichtszustand. Frühere Versionen von ASP.NET den älteren HMACSHA1-Algorithmus verwendet.

Ihre Anwendungen sind möglicherweise betroffen, wenn Sie gemischte ASP.NET 2.0/ASP.NET 4-Umgebungen ausführen, in denen Daten wie Formularauthentifizierungscookies across.NET Framework-Versionen funktionieren müssen. Um eine ASP.NET 4-Webanwendung für die Verwendung des älteren HMACSHA1-Algorithmus zu konfigurieren, fügen Sie der Datei die Web.config folgende Einstellung hinzu:

<machineKey validation="SHA1" />

Die Stammkonfigurationsdateien (die machine.config Datei und die StammdateiWeb.config) für die .NET Framework 4 (und damit ASP.NET 4) wurden aktualisiert, sodass sie die meisten Informationen zur Konfiguration des Boilerplates enthalten, die in ASP.NET 3.5 in den Anwendungsdateien Web.config gefunden wurden. Aufgrund der Komplexität der verwalteten IIS 7- und IIS 7.5-Konfigurationssysteme kann das Ausführen ASP.NET 3.5-Anwendungen unter ASP.NET 4 und unter IIS 7 und IIS 7.5 entweder zu ASP.NET- oder IIS-Konfigurationsfehlern führen.

Es wird empfohlen, ASP.NET 3.5-Anwendungen mithilfe der Projektupgradetools in Visual Studio 2010 auf ASP.NET 4 zu aktualisieren, sofern dies sinnvoll ist. Visual Studio 2010 ändert die Datei der ASP.NET 3.5-Anwendung Web.config automatisch so, dass sie die entsprechenden Einstellungen für ASP.NET 4 enthält.

Es wird jedoch unterstützt, ASP.NET 3.5-Anwendungen mithilfe der .NET Framework 4 ohne erneute Kompilierung auszuführen. In diesem Fall müssen Sie möglicherweise die Datei der Anwendung Web.config manuell ändern, bevor Sie die Anwendung unter dem .NET Framework 4 und unter IIS 7 oder IIS 7.5 ausführen.

In den nächsten beiden Abschnitten werden Änderungen beschrieben, die Sie möglicherweise für verschiedene Kombinationen von Software vornehmen müssen.

Windows Vista SP1 oder Windows Server 2008 SP1, wobei weder Hotfix KB958854 noch SP2 installiert sind. In dieser Konfiguration führt das IIS 7-Konfigurationssystem die verwaltete Konfiguration einer Anwendung fälschlicherweise zusammen, indem die Datei auf Anwendungsebene Web.config mit den ASP.NET 2.0-Dateien machine.config verglichen wird. Aus diesem Grund müssen Dateien auf Anwendungsebene Web.config aus dem .NET Framework 3.5 oder höher über eine System.web.extensions-Konfigurationsabschnittsdefinition (das -Element) verfügen, um keinen IIS 7-Validierungsfehler zu verursachen.

Manuell geänderte Dateieinträge auf Anwendungsebene Web.config , die nicht genau mit den ursprünglichen Konfigurationsabschnittsdefinitionen übereinstimmen, die mit Visual Studio 2008 eingeführt wurden, verursachen jedoch ASP.NET Konfigurationsfehler. (Die Standardkonfigurationseinträge, die von Visual Studio 2008 generiert werden, funktionieren ordnungsgemäß.) Ein häufiges Problem besteht darin, dass manuell geänderte Web.config Dateien die Konfigurationsattribute allowDefinition und requirePermission auslassen, die in verschiedenen Konfigurationsabschnittsdefinitionen gefunden werden. Dies führt zu einem Konflikt zwischen dem abgekürzten Konfigurationsabschnitt in Dateien auf Anwendungsebene Web.config und der vollständigen Definition in der datei ASP.NET 4 machine.config . Daher löst das ASP.NET 4-Konfigurationssystem zur Laufzeit einen Konfigurationsfehler aus.

Windows Vista SP2, Windows Server 2008 SP2, Windows 7, Windows Server 2008 R2 sowie Windows Vista SP1 und Windows Server 2008 SP1, in denen Hotfix KB958854 installiert ist.

In diesem Szenario gibt das systemeigene Konfigurationssystem IIS 7 und IIS 7.5 einen Konfigurationsfehler zurück, da es einen Textvergleich für das Typattribute ausführt, das für einen Handler für einen verwalteten Konfigurationsabschnitt definiert ist. Da alle Web.config Dateien, die von Visual Studio 2008 und Visual Studio 2008 SP1 generiert werden, "3.5" in der Typzeichenfolge für die System.web.extensions-Konfigurationsabschnittshandler (und die zugehörigen) Konfigurationsabschnittshandler enthalten, und da die ASP.NET 4-Datei machine.config im Type-Attribut für die gleichen Konfigurationsabschnittshandler "4.0" enthält, schlagen Anwendungen, die in Visual Studio 2008 oder Visual Studio 2008 SP1 generiert werden, in IIS 7 und IIS 7.5 immer fehl.

Beheben dieser Probleme

Die Problemumgehung für das erste Szenario besteht darin, die Datei auf Anwendungsebene Web.config zu aktualisieren, indem sie den Konfigurationstext des Bausteines aus einer Web.config Datei einschließt, die automatisch von Visual Studio 2008 generiert wurde.

Eine alternative Problemumgehung für das erste Szenario besteht darin, Service Pack 2 für Vista oder Windows Server 2008 auf Ihrem Computer zu installieren, um das falsche Konfigurationszusammenführungsverhalten des IIS-Konfigurationssystems zu beheben. Nachdem Sie jedoch eine dieser Aktionen ausgeführt haben, tritt für Ihre Anwendung wahrscheinlich aufgrund des für das zweite Szenario beschriebenen Problems ein Konfigurationsfehler auf.

Die Problemumgehung für das zweite Szenario besteht darin, alle System.web.extensions-Konfigurationsabschnittsdefinitionen und Konfigurationsabschnittsgruppendefinitionen aus der Datei auf Anwendungsebene Web.config zu löschen oder auszukommentieren. Diese Definitionen befinden sich in der Regel am Anfang der Datei auf Anwendungsebene Web.config und können durch das configSections-Element und seine untergeordneten Elemente identifiziert werden.

Für beide Szenarien wird empfohlen, auch den Abschnitt system.codedom manuell zu löschen, obwohl dies nicht erforderlich ist.

ASP.NET 4 untergeordnete Anwendungen können nicht gestartet werden, wenn anwendungen unter ASP.NET 2.0 oder ASP.NET 3.5

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. Das folgende Beispiel zeigt eine Verzeichnisstruktur für eine betroffene Anwendung.

/parentwebapp (für die Verwendung von ASP.NET 2.0 oder ASP.NET 3.5 konfiguriert)
/childwebapp (für die Verwendung von ASP.NET 4 konfiguriert)

Die Anwendung im childwebapp Ordner kann unter IIS 7 oder IIS 7.5 nicht gestartet werden und meldet einen Konfigurationsfehler. Der Fehlertext enthält eine Meldung ähnlich der folgenden:

  • The requested page cannot be accessed because the related configuration data for the page is invalid.

  • The configuration section 'configSections' cannot be read because it is missing a section declaration.

Unter IIS 6 kann die Anwendung im childwebapp Ordner ebenfalls nicht gestartet werden, aber es wird ein anderer Fehler gemeldet. Im Fehlertext kann beispielsweise Folgendes angegeben werden:

  • The value for the 'compilerVersion' attribute in the provider options must be 'v4.0' or later if you are compiling for version 4.0 or later of the .NET Framework. To compile this Web application for version 3.5 or earlier of the .NET Framework, remove the 'targetFramework' attribute from the element of the Web.config file

Diese Szenarien treten auf, weil die Konfigurationsinformationen aus der übergeordneten Anwendung im parentwebapp Ordner Teil der Hierarchie der Konfigurationsinformationen sind, die die endgültigen zusammengeführten Konfigurationseinstellungen bestimmt, die von der untergeordneten Webanwendung im childwebapp Ordner verwendet werden. Je nachdem, ob die ASP.NET 4-Webanwendung unter IIS 7 (oder IIS 7.5) oder IIS 6 ausgeführt wird, gibt entweder das IIS-Konfigurationssystem oder das kompilierungssystem ASP.NET 4 einen Fehler zurück.

Die Schritte, die Sie ausführen müssen, um dieses Problem zu beheben und die untergeordnete ASP.NET 4-Anwendung zum Funktionieren zu bringen, hängen davon ab, ob die anwendung ASP.NET 4 unter IIS 6 oder IIS 7 (oder IIS 7.5) ausgeführt wird.

Schritt 1 (nur IIS 7 oder IIS 7.5)

Dieser Schritt ist nur auf Betriebssystemen erforderlich, auf denen IIS 7 oder IIS 7.5 ausgeführt wird, einschließlich Windows Vista, Windows Server 2008, Windows 7 und Windows Server 2008 R2.

Verschieben Sie die definition configSections in der Web.config Datei der übergeordneten Anwendung (die Anwendung, die ASP.NET 2.0 oder ASP.NET 3.5 ausgeführt wird) in die Stammdatei Web.config für the.NET Framework 2.0. Das systemeigene Iis 7- und IIS 7.5-Konfigurationssystem überprüft das configSections-Element , wenn es die Hierarchie der Konfigurationsdateien zusammenführt. Wenn Sie die definition configSections aus der Datei der übergeordneten Webanwendung Web.config in die Stammdatei Web.config verschieben, wird das Element aus dem Konfigurationszusammenführungsprozess für die untergeordnete ASP.NET 4-Anwendung ausgeblendet.

Unter einem 32-Bit-Betriebssystem oder für 32-Bit-Anwendungspools befindet sich die Stammdatei Web.config für ASP.NET 2.0 und ASP.NET 3.5 normalerweise im folgenden Ordner:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG

Unter einem 64-Bit-Betriebssystem oder für 64-Bit-Anwendungspools befindet sich die Stammdatei Web.config für ASP.NET 2.0 und ASP.NET 3.5 normalerweise im folgenden Ordner:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG

Wenn Sie sowohl 32-Bit- als auch 64-Bit-Webanwendungen auf einem 64-Bit-Computer ausführen, müssen Sie das configSections-Element sowohl für die 32-Bit- als auch für die 64-Bit-Systeme in stammdateien Web.config verschieben.

Wenn Sie das configSections-Element in die Stammdatei Web.config einfügen, fügen Sie den Abschnitt unmittelbar nach dem Konfigurationselement ein. Das folgende Beispiel zeigt, wie der obere Teil der Stammdatei Web.config aussehen sollte, wenn Sie das Verschieben der Elemente abgeschlossen haben.

Hinweis

Im folgenden Beispiel wurden Zeilen zur Besseren Lesbarkeit umschlossen.

<?xml version="1.0" encoding="utf-8"?>
<!-- The root web configuration file -->
<configuration>
  <configSections>
    <sectionGroup name="system.web.extensions"
        type="System.Web.Configuration.SystemWebExtensionsSectionGroup, 
      System.Web.Extensions, Version=3.5.0.0, Culture=neutral,  
      PublicKeyToken=31BF3856AD364E35">

      <sectionGroup name="scripting"
        type="System.Web.Configuration.ScriptingSectionGroup, 
        System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
        PublicKeyToken=31BF3856AD364E35">

        <section name="scriptResourceHandler"
          type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
          allowDefinition="MachineToApplication" />

        <sectionGroup name="webServices"
          type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35">

          <section name="jsonSerialization"
            type="System.Web.Configuration.ScriptingJsonSerializationSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="Everywhere" />

          <section name="profileService"
            type="System.Web.Configuration.ScriptingProfileServiceSection, 
            System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
            PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />
          <section name="authenticationService"
            type="System.Web.Configuration.ScriptingAuthenticationServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

          <section name="roleService"
            type="System.Web.Configuration.ScriptingRoleServiceSection, 
          System.Web.Extensions, Version=3.5.0.0, Culture=neutral, 
          PublicKeyToken=31BF3856AD364E35" requirePermission="false"
            allowDefinition="MachineToApplication" />

        </sectionGroup>
      </sectionGroup>
    </sectionGroup>
  </configSections>

Schritt 2 (alle Versionen von IIS)

Dieser Schritt ist erforderlich, unabhängig davon, ob die ASP.NET 4 untergeordnete Webanwendung unter IIS 6 oder IIS 7 (oder IIS 7.5) ausgeführt wird.

Fügen Sie in der Web.config Datei der übergeordneten Webanwendung, die ASP.NET 2 oder ASP.NET 3.5 ausgeführt wird, ein Speicherorttag hinzu, das explizit (sowohl für iis als auch für ASP.NET-Konfigurationssysteme) angibt, dass die Konfigurationseinträge nur für die übergeordnete Webanwendung gelten. Das folgende Beispiel zeigt die Syntax des hinzuzufügenden location-Elements :

<location path="" inheritInChildApplications="false" >
  <!-- Additional settings -->
</location>

Das folgende Beispiel zeigt, wie das Location-Tag verwendet wird, um alle Konfigurationsabschnitte zu umschließen, beginnend mit dem Abschnitt appSettings und endend mit dem Abschnitt system.webServer .

<location path="" inheritInChildApplications="false" >
  <appSettings />
  <connectionStrings />
  <system.web>
    <!-- Removed for brevity -->
  </system.web>
  <system.codedom>
    <!-- Removed for brevity -->
  </system.codedom>
  <system.webServer>
    <!-- Removed for brevity -->
</system.webServer>
</location>

Wenn Sie die Schritte 1 und 2 abgeschlossen haben, werden untergeordnete ASP.NET 4 Webanwendungen ohne Fehler gestartet.

ASP.NET 4 Websites können auf Computern, auf denen SharePoint installiert ist, nicht gestartet werden

Webserver, auf denen SharePoint ausgeführt wird, verfügen über eine Web.config Datei, die im Stammverzeichnis einer SharePoint-Website bereitgestellt wird (z. B. c:\inetpub\wwwroot\web.config für Standardwebsite). In dieser Web.config Datei legt SharePoint eine benutzerdefinierte teilweise vertrauenswürdige Ebene namens WSS_Minimal fest.

Wenn Sie versuchen, eine ASP.NET 4-Website auszuführen, die als untergeordnetes Element dieses Typs von SharePoint-Website bereitgestellt wird, wird der folgende Fehler angezeigt:

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

Dieser Fehler tritt auf, weil die ASP.NET 4-Codezugriffssicherheitsinfrastruktur (Code Access Security, CAS) nach einem Berechtigungssatz namens ASP.NET sucht. Die teilweise vertrauenswürdige Konfigurationsdatei, auf die von WSS_Minimal verwiesen wird, enthält jedoch keine Berechtigungssätze mit diesem Namen.

Derzeit ist keine Version von SharePoint verfügbar, die mit ASP.NET kompatibel ist. Daher sollten Sie nicht versuchen, eine ASP.NET 4-Website als untergeordnete Website unterhalb von SharePoint-Websites auszuführen.

Die HttpRequest.FilePath-Eigenschaft enthält keine PathInfo-Werte mehr.

Frühere Versionen von ASP.NET einen PathInfo-Wert in dem Wert enthalten, der von verschiedenen dateipfadbezogenen Eigenschaften zurückgegeben wurde, einschließlich HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath und HttpRequest.CurrentExecutionFilePath. ASP.NET 4 enthält den PathInfo-Wert nicht mehr in den Rückgabewerten dieser Eigenschaften. Stattdessen sind die PathInfo-Informationen in HttpRequest.PathInfo verfügbar. Nehmen wir z.B. das folgenden URL-Fragment:

/testapp/Action.mvc/SomeAction

In früheren Versionen von ASP.NET haben HttpRequest-Eigenschaften die folgenden Werte:

HttpRequest.FilePath: /testapp/Action.mvc/SomeAction

HttpRequest.PathInfo: (leer)

In ASP.NET 4 weisen HttpRequest-Eigenschaften stattdessen die folgenden Werte auf:

HttpRequest.FilePath: /testapp/Action.mvc

HttpRequest.PathInfo: SomeAction

ASP.NET 2.0-Anwendungen generieren möglicherweise HttpException-Fehler, die auf eurl.axd verweisen

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.

Dieser Fehler tritt auf, weil ASP.NET erkennt, dass eine Website für die Verwendung ASP.NET 4 konfiguriert ist, eine native Komponente von ASP.NET 4 eine erweiterungslose URL zur weiteren Verarbeitung an den verwalteten Teil der ASP.NET übergibt. Wenn jedoch virtuelle Verzeichnisse, die sich unterhalb einer ASP.NET 4-Website befinden, für die Verwendung ASP.NET 2.0 konfiguriert sind, führt die Verarbeitung der erweiterungslosen URL auf diese Weise zu einer geänderten URL, die die Zeichenfolge "eurl.axd" enthält. Diese geänderte URL wird dann an die anwendung ASP.NET 2.0 gesendet. ASP.NET 2.0 kann das Format "eurl.axd" nicht erkennen. Daher versucht ASP.NET 2.0, eine Datei namens eurl.axd zu finden und auszuführen. Da keine solche Datei vorhanden ist, schlägt die Anforderung mit einer HttpException-Ausnahme fehl.

Sie können dieses Problem umgehen, indem Sie eine der folgenden Optionen verwenden.

Option 1:

Wenn ASP.NET 4 nicht erforderlich ist, um die Website auszuführen, ordnen Sie die Website neu zu, um stattdessen ASP.NET 2.0 zu verwenden.

Option 2:

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.

Option 3

Wenn es nicht sinnvoll ist, die Website ASP.NET 2.0 neu zuzuordnen oder den Speicherort eines virtuellen Verzeichnisses zu ändern, deaktivieren Sie die Verarbeitung von erweiterungslosen URLs in ASP.NET 4 explizit. Gehen Sie dazu wie folgt vor:

  1. Öffnen Sie in der Windows-Registrierung den folgenden Knoten:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0

  1. Erstellen Sie einen neuen DWORD-Wert namens EnableExtensionlessUrls.
  2. Legen Sie EnableExtensionlessUrls auf 0 fest. Dadurch wird das Url-Verhalten ohne Erweiterung deaktiviert.
  3. Speichern Sie den Registrierungswert, und schließen Sie den Registrierungs-Editor.
  4. Führen Sie das Befehlszeilentool iisreset aus, wodurch IIS den neuen Registrierungswert liest.

Hinweis

Wenn EnableExtensionlessUrls auf 1 festgelegt wird, wird das Verhalten von erweiterungslosen URLs aktiviert. Dies ist die Standardeinstellung, wenn kein Wert angegeben wird.

Ereignishandler werden möglicherweise nicht in einem Standarddokument im integrierten IIS 7- oder IIS 7.5-Modus ausgelöst

ASP.NET 4 enthält Änderungen, die ändern, wie das Aktionsattribute des HTML-Formularelements gerendert wird, wenn eine erweiterungslose URL in ein Standarddokument aufgelöst wird. Ein Beispiel für eine erweiterungslose URL, die in ein Standarddokument aufgelöst wird, wäre http://contoso.com/, was zu einer Anforderung an http://contoso.com/Default.aspxführt.

ASP.NET 4 rendert nun den Aktionsattributewert des HTML-Formularelements als leere Zeichenfolge, wenn eine Anforderung an eine erweiterungslose URL gestellt wird, der ein Standarddokument zugeordnet ist. In früheren Versionen von ASP.NET würde beispielsweise eine Anforderung an http://contoso.com zu einer Anforderung an Default.aspxführen. In diesem Dokument wird das öffnende Formulartag wie im folgenden Beispiel gerendert:

<form action="Default.aspx" />

In ASP.NET 4 führt eine Anforderung an auch zu http://contoso.com einer Anforderung an Default.aspx. Allerdings rendert ASP.NET jetzt das HTML-Öffnen-Formulartag wie im folgenden Beispiel:

<form action="" />

Dieser Unterschied in der Art und Weise, wie das Aktionsattribute gerendert wird, kann zu geringfügigen Änderungen in der Verarbeitung eines Formularbeitrags durch IIS und ASP.NET führen. Wenn das Aktionsattribute eine leere Zeichenfolge ist, erstellt das IIS DefaultDocumentModule-Objekt eine untergeordnete Anforderung an Default.aspx. Unter den meisten Bedingungen ist diese untergeordnete Anforderung für Den Anwendungscode transparent, und die Default.aspx Seite 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 Default.aspx Dokument zu einem Fehler oder zu unerwartetem Verhalten:

  1. Eine ASPX-Seite wird an den Browser gesendet, wobei das Aktionsattribute des Formularelements auf "" festgelegt ist.
  2. Das Formular wird an ASP.NET zurückgesendet.
  3. Ein verwaltetes HTTP-Modul liest einen Teil des Entitätstexts. Ein Modul liest 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.
  4. Das IIS DefaultDocumentModule-Objekt 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.
  5. 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.
  6. Da kein Entitätstext vorhanden ist, gibt es keine Formularvariablen und keinen Ansichtszustand, und 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.

Sie können dieses Verhalten auf folgende Weise umgehen:

  • Identifizieren Sie das HTTP-Modul, das während Standarddokumentanforderungen auf den Entitätstext der Anforderung zugreift, und ermitteln Sie, ob es für die Ausführung nur für verwaltete Anforderungen konfiguriert werden kann. Im integrierten Modus für IIS 7 und IIS 7.5 können HTTP-Module so markiert werden, dass sie nur für verwaltete Anforderungen ausgeführt werden, indem dem Eintrag system.webServer/modules des Moduls das folgende Attribut hinzugefügt wird:

  • precondition="managedHandler"

  • Diese Einstellung deaktiviert das Modul für Anforderungen, die IIS 7 und IIS 7.5 als nicht verwaltete Anforderungen ermitteln. Bei Standarddokumentanforderungen ist die erste Anforderung eine erweiterungslose URL. Daher führt IIS keine verwalteten Module aus, die während der anfänglichen Anforderungsverarbeitung mit einer Vorbedingung des verwalteten Handlers gekennzeichnet sind. Daher werden verwaltete Module nicht versehentlich den Entitätstext lesen, sodass der Entitätstext weiterhin verfügbar ist und an die untergeordnete Anforderung und an das Standarddokument übergeben wird.

  • Wenn die problematischen HTTP-Module für alle Anforderungen ausgeführt werden müssen (für statische Dateien, für erweiterungslose URLs, die in das DefaultDocumentModule-Objekt aufgelöst werden, für verwaltete Anforderungen usw.), ändern Sie die betroffenen ASPX-Seiten, indem Sie die Action-Eigenschaft des System.Web.UI.HtmlControls.HtmlForm-Steuerelements der Seite explizit auf eine nicht leere Zeichenfolge festlegen. Wenn das Standarddokument beispielsweise lautetDefault.aspx, ändern Sie den Code der Seite, um die Action-Eigenschaft des HtmlForm-Steuerelements explizit auf "Default.aspx" festzulegen.

Änderungen an der Implementierung von ASP.NET Code Access Security (CAS)

ASP.NET 2.0 und als Erweiterung der ASP.NET Features, die in Version 3.5 hinzugefügt wurden, verwenden Sie das .NET Framework 1.1- und 2.0-Codezugriffssicherheitsmodell (CAS). Die Implementierung von CAS wurde in ASP.NET 4 aber erheblich überholt. Daher können teilweise vertrauenswürdige ASP.NET Anwendungen, die auf vertrauenswürdigem Code basieren, der im globalen Assemblycache (GAC) ausgeführt wird, mit verschiedenen Sicherheitsausnahmen fehlschlagen. Teilweise vertrauenswürdige Anwendungen, die auf umfangreichen Änderungen an der CAS-Richtlinie für Computer angewiesen sind, können auch mit Sicherheitsausnahmen fehlschlagen.

Sie können teilweise vertrauenswürdige ASP.NET 4-Anwendungen auf das Verhalten von ASP.NET 1.1 und 2.0 mithilfe des neuen legacyCasModel-Attributs im Vertrauenskonfigurationselement rückgängig machen, wie im folgenden Beispiel gezeigt:

<trust level= "Medium" legacyCasModel="true" />

Wenn Sie das ältere CAS-Modell rückgängig machen, werden die folgenden alten CAS-Verhaltensweisen aktiviert:

  • Die CAS-Richtlinie für Computer wird berücksichtigt.
  • Mehrere unterschiedliche Berechtigungssätze in einer einzelnen Anwendungsdomäne sind zulässig.
  • Explizite Berechtigungsassertionen sind für Assemblys im GAC nicht erforderlich, die aufgerufen werden, wenn sich nur ASP.NET oder andere .NET Framework Code auf dem Stapel befindet.

Ein Szenario kann im .NET Framework 4 nicht wiederhergestellt werden: Teilweise vertrauenswürdige Anwendungen ohne Web können bestimmte APIs in System.Web.dll und System.Web.Extensions.dll nicht mehr aufrufen. In früheren Versionen der .NET Framework war es möglich, dass Nicht-Web-Anwendungen, die teilweise vertrauenswürdig sind, explizit AspNetHostingPermission-Berechtigungen erteilt wurden. Diese Anwendungen können dann System.Web.HttpUtility, Typen in den System.Web.ClientServices.* -Namespaces und Typen im Zusammenhang mit Mitgliedschaft, Rollen und Profilen verwenden. Das Aufrufen dieser Typen von Nicht-Web-Teilweise vertrauenswürdigen Anwendungen wird im .NET Framework 4 nicht mehr unterstützt.

Hinweis

Die HtmlEncode- und HtmlDecode-Funktionalität der System.Web.HttpUtility-Klasse wurde in die neue .NET Framework 4 System.Net.WebUtility-Klasse verschoben. Wenn dies die einzige ASP.NET Funktionalität war, die verwendet wurde, ändern Sie den Code der Anwendung, um stattdessen die neue WebUtility-Klasse zu verwenden.

Es folgt eine allgemeine Zusammenfassung der Änderungen an der Cas-Standardimplementierung in ASP.NET 4:

  • ASP.NET Anwendungsdomänen sind jetzt homogene Anwendungsdomänen. In einer Anwendungsdomäne sind nur teilweise vertrauenswürdige und voll vertrauenswürdige Zuteilungsgruppen verfügbar.
  • ASP.NET teilweise vertrauenswürdige Zuteilungssätze sind unabhängig von jeder CAS-Richtlinie auf Unternehmensebene, auf Computern oder auf Benutzerebene.
  • ASP.NET Assemblys, die in 3.5 und 3.5 SP1 ausgeliefert wurden, wurden in die Verwendung des Transparenzmodells .NET Framework 4 konvertiert.
  • Die Verwendung des ASP.NET AspNetHostingPermission-Attributs wurde erheblich reduziert. Die meisten Instanzen dieses Attributs wurden aus den öffentlichen ASP.NET-APIs entfernt.
  • Dynamisch kompilierte Assemblys, die von ASP.NET Buildanbietern erstellt werden, wurden aktualisiert, um Assemblys explizit als transparent zu kennzeichnen.
  • Alle ASP.NET Assemblys sind jetzt so gekennzeichnet, dass das APTCA-Attribut nur in Webhostingumgebungen berücksichtigt wird. Teilweise vertrauenswürdige Nicht-Webhostingumgebungen wie ClickOnce können ASP.NET Assemblys nicht aufrufen.

Weitere Informationen zum neuen ASP.NET 4-Codezugriffssicherheitsmodell finden Sie unter Verwenden der Codezugriffssicherheit in ASP.NET-Anwendungen auf der MSDN-Website.

MembershipUser und andere Typen im System.Web.Security-Namespace wurden verschoben.

Einige Typen, die in ASP.NET Mitgliedschaft verwendet werden, wurden in System.Web.dll die neue System.Web.ApplicationServices.dll-Assembly verschoben. So sollten architektonische Schichtabhängigkeiten zwischen Typen im Client und erweiterten .NET Framework-SKUs gelöst werden.

Websiteprojekte haben keine Probleme aufgrund des Verschiebens dieser Typen, da System.Web.ApplicationServices.dll der Liste der Assemblys hinzugefügt wurde, auf die verwiesen wird, die standardmäßig vom ASP.NET Kompilierungssystem verwendet wird. Wenn Sie ein Websiteprojekt, das mit einer früheren Version von ASP.NET erstellt wurde, auf ASP.NET 4 aktualisieren, indem Sie es in Visual Studio 2010 öffnen, wird das Projekt fehlerfrei kompiliert.

Wenn Sie ein Webanwendungsprojekt, das in einer früheren Version von ASP.NET erstellt wurde, auf ASP.NET 4 aktualisieren, indem Sie es in Visual Studio 2010 öffnen, fügt der Upgradeprozess einen Verweis auf System.Web.ApplicationServices.dll zum Projekt hinzu. Daher werden aktualisierte Webanwendungsprojekte auch fehlerfrei kompiliert.

Kompilierte (Binärdateien), die mit früheren Versionen von ASP.NET erstellt wurden, werden auch auf ASP.NET 4 fehlerfrei ausgeführt, obwohl die Mitgliedschaftstypen in eine andere Assembly verschoben wurden. Typweiterleitungsinformationen wurden der ASP.NET 4-Version von System.Web.dll hinzugefügt, die Laufzeitverweise für diese Typen automatisch an den neuen Speicherort für die Typen weiterleitet.

Klassenbibliotheken, die bestimmte Mitgliedschaftstypen verwenden und die von früheren Versionen von ASP.NET aktualisiert wurden, können jedoch nicht kompiliert werden, wenn sie in einem ASP.NET 4-Projekt verwendet werden. Beispielsweise kann ein Klassenbibliotheksprojekt einen Fehler wie den folgenden nicht kompilieren und melden:

  • The type 'System.Web.Security.MembershipUser' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

  • The type name 'MembershipUser' could not be found. This type has been forwarded to assembly 'System.Web.ApplicationServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Consider adding a reference to that assembly.

Sie können dieses Problem umgehen, indem Sie System.Web.ApplicationServices.dll einen Verweis in Ihrem Klassenbibliotheksprojekt hinzufügen.

Die folgende Liste zeigt die System.Web.Security-Typen , die von System.Web.dll System.Web.ApplicationServices.dll verschoben wurden:

  • System.Web.Security.MembershipCreateStatus
  • System.Web.Security.Membership.CreateUserException
  • System.Web.Security.MembershipPasswordException
  • System.Web.Security.MembershipPasswordFormat
  • System.Web.Security.MembershipProvider
  • System.Web.Security.MembershipProviderCollection
  • System.Web.Security.MembershipUser
  • System.Web.Security.MembershipUserCollection
  • System.Web.Security.MembershipValidatePasswordEventHandler
  • System.Web.Security.ValidatePasswordEventArgs
  • System.Web.Security.RoleProvider
  • System.Web.Configuration.MembershipPasswordCompatibilityMode

Änderungen an der Ausgabezwischenspeicherung in Vary * HTTP-Header

In ASP.NET 1.0 hat ein Fehler dazu geführt, dass zwischengespeicherte Seiten, die als Ausgabecacheeinstellung angegeben wurden Location="ServerAndClient" , einen Vary:* HTTP-Header in der Antwort ausgeben. So wurde Clientbrowsern mitgeteilt, dass Seiten nie lokal zwischengespeichert werden sollen.

In ASP.NET Version 1.1 wurde die System.Web.HttpCachePolicy.SetOmitVaryStar-Methode hinzugefügt, die Sie aufrufen können, um den Vary:* Header zu unterdrücken. Diese Methode wurde ausgewählt, da das Ändern des ausgegebenen HTTP-Headers zu diesem Zeitpunkt als potenziell fehlerhafte Änderung angesehen wurde. Entwickler wurden jedoch durch das Verhalten in ASP.NET verwirrt, und Fehlerberichte deuten darauf hin, dass Entwickler das vorhandene SetOmitVaryStar-Verhalten nicht kennen.

In ASP.NET 4 wurde die Entscheidung getroffen, das Stammproblem zu beheben. Der Vary:* HTTP-Header wird nicht mehr von Antworten ausgegeben, die die folgende Anweisung angeben:

<%@OutputCache Location="ServerAndClient" %>

Daher wird SetOmitVaryStar nicht mehr benötigt, um den Vary:* Header zu unterdrücken.

In Anwendungen, die in der @ OutputCache-Direktive auf einer Seite angebenLocation="ServerAndClient", wird nun das Verhalten angezeigt, das durch den Namen des Werts des Location-Attributs impliziert wird. Das heißt, Seiten können im Browser zwischengespeichert werden, ohne dass Sie die SetOmitVaryStar-Methode aufrufen müssen.

Wenn Seiten in Ihrer Anwendung ausgegeben Vary:*werden müssen, rufen Sie wie im folgenden Beispiel die AppendHeader-Methode auf:

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

Alternativ können Sie den Wert des Attributs "Speicherort für die Ausgabespeicherung" in "Server" ändern.

System.Web.Security Types for Passport sind veraltet

Die in ASP.NET 2.0 integrierte Passport-Unterstützung ist aufgrund von Änderungen in Passport (jetzt LiveID) seit einigen Jahren veraltet und wird nicht unterstützt. Daher sind die fünf Passport-Typen in System.Web.Security jetzt mit dem ObsoleteAttribute-Attribut gekennzeichnet.

Die MenuItem.PopOutImageUrl-Eigenschaft kann ein Bild in ASP.NET 4 nicht rendern

In ASP.NET 3.5 können Sie mit der MenuItem.PopOutImageUrl-Eigenschaft die URL für ein Bild angeben, das in einem Menüelement angezeigt wird, um anzugeben, dass das Menüelement über ein dynamisches Untermenü verfügt. Im folgenden Beispiel wird gezeigt, wie Sie diese Eigenschaft im Markup in ASP.NET 3.5 angeben.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank"  
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        PopOutImageUrl="~/Images/Popout.gif"   
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          PopOutImageUrl="~/Images/Popout.gif"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Infolge einer Entwurfsänderung in ASP.NET 4 wird keine Ausgabe für die PopOutImageUrl gerendert, wenn die Eigenschaft für die MenuItem-Klasse festgelegt ist. Stattdessen müssen Sie eine Bild-URL direkt im Menu-Steuerelement angeben, indem Sie entweder die StaticPopOutImageUrl-Eigenschaft oder die DynamicPopOutImageUrl-Eigenschaft verwenden. Wenn Sie mit einem statischen Menü arbeiten, gibt die Menu.StaticPopOutImageUrl-Eigenschaft die URL für ein angezeigtes Bild an, um anzugeben, dass das statische Menüelement über ein Untermenü verfügt, wie im folgenden Beispiel gezeigt:

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Wenn Sie mit einem dynamischen Menü arbeiten, verwenden Sie die Menu.DynamicPopOutImageUrl-Eigenschaft , um die URL für ein Bild anzugeben, das angibt, dass ein dynamisches Menüelement über ein Untermenü verfügt. Das folgende Beispiel ähnelt dem vorherigen, zeigt aber, wie die DynamicPopOutImageUrl-Eigenschaft für ein dynamisches Menü festgelegt wird.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical" 
    target="_blank" 
    DynamicPopOutImageTextFormatString="More..."
    DynamicPopOutImageUrl="Images/Popout.gif" 
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Wenn die Menu.DynamicPopOutImageUrl-Eigenschaft nicht festgelegt ist und die Menu.DynamicEnableDefaultPopOutImage-Eigenschaft auf false festgelegt ist, wird kein Bild angezeigt. Wenn die StaticPopOutImageUrl-Eigenschaft nicht festgelegt und die StaticEnableDefaultPopOutImage-Eigenschaft auf false festgelegt ist, wird kein Bild angezeigt.

Wenn Sie die Pfade für diese Eigenschaften festlegen, verwenden Sie einen Schrägstrich (/) anstelle eines umgekehrten Schrägstrichs (). Weitere Informationen finden Sie unter Menu.StaticPopOutImageUrl und Menu.DynamicPopOutImageUrl können Bilder nicht rendern, wenn Pfade umgekehrte Schrägstriche an anderer Stelle in diesem Dokument enthalten.

In ASP.NET 4 werden die Bilder, die Sie mit den Eigenschaften Menu.StaticPopOutImageUrl und Menu.DynamicPopOutImageUrl angeben, nicht gerendert, wenn der Pfad umgekehrte Schrägstriche () enthält. Dies ist eine Änderung gegenüber früheren Versionen von ASP.NET.

Das folgende Beispiel für Menu-Steuerelementmarkup zeigt die StaticPopOutImageUrl-Eigenschaft , die mithilfe eines Pfads festgelegt ist, der einen umgekehrten Schrägstrich enthält. In ASP.NET 4 wird das in der -Eigenschaft angegebene Bild nicht gerendert.

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images\Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Um dieses Problem zu beheben, ändern Sie Pfadwerte, die in den Eigenschaften StaticPopOutImageUrl und DynamicPopOutImageUrl angegeben sind, um Schrägstriche (/) zu verwenden. Das folgende Beispiel zeigt diese Änderung:

<asp:menu id="NavigationMenu"
    staticdisplaylevels="1"
    staticsubmenuindent="10" 
    orientation="Vertical 
    target="_blank" 
    StaticPopOutImageTextFormatString="More..."
    StaticPopOutImageUrl="Images/Popout.gif"   
    runat="server">
  <items>
    <asp:menuitem navigateurl="default2.aspx" 
        text="Home" 
        tooltip="Home">
      <asp:menuitem navigateurl="default3.aspx"
          text="Movies"
          tooltip="Movies"> 
      </asp:menuitem>
    </asp:menuitem>
  </items>
</asp:menu>

Beachten Sie, dass Anwendungen, die von früheren Versionen von ASP.NET zu ASP.NET 4 migriert wurden, möglicherweise ebenfalls betroffen sind, da die MenuItem.PopOutImageUrl-Eigenschaft geändert wurde. Weitere Informationen finden Sie unter Die MenuItem.PopOutImageUrl-Eigenschaft kann ein Bild in ASP.NET 4 an anderer Stelle in diesem Dokument nicht rendern.

Haftungsausschluss

Dies ist ein vorläufiges Dokument, das vor der kommerziellen Veröffentlichung der beschriebenen Software ggf. erheblich geändert wird.

Die in diesem Dokument enthaltenen Informationen stellen die Sicht der Microsoft Corporation der hier diskutierten Themen zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf wechselnde Marktbedingungen reagieren muss, sollten sie nicht als Verpflichtung seitens Microsoft interpretiert werden, und Microsoft kann die Genauigkeit der dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren.

Dieses Whitepaper dient ausschließlich Informationszwecken. MICROSOFT ÜBERNIMMT KEINE AUSDRÜCKLICHE, STILLSCHWEIGENDE ODER AUS GESETZ ERWACHSENDE GARANTIE IN BEZUG AUF DIE INFORMATIONEN IN DIESEM DOKUMENT.

Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf kein Teil dieses Dokuments ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht.

Es ist möglich, dass Microsoft Rechte an Patenten bzw. an angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Die Bereitstellung dieses Dokuments gewährt Ihnen jedoch keinerlei Lizenzrechte an diesen Patenten, Marken, Urheberrechten oder anderem geistigen Eigentum, es sei denn, dies wurde ausdrücklich durch einen schriftlichen Lizenzvertrag mit der Microsoft Corporation vereinbart.

Sofern nicht anders angegeben, sind die hier dargestellten Beispielunternehmen, Organisationen, Produkte, Domänennamen, E-Mail-Adressen, Logos, Personen, Orte und Ereignisse fiktiv, und keine Verbindung mit einem echten Unternehmen, organization, Produkt, Domänenname, E-Mail-Adresse, Logo, Person, Ort oder Ereignis ist beabsichtigt oder sollte abgeleitet werden.

© 2010 Microsoft Corporation. Alle Rechte vorbehalten.

Microsoft und Windows sind eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.

Die in diesem Dokument erwähnten Namen von Unternehmen und Produkten können Marken der jeweiligen Eigentümer sein.