Freigeben über

ASP.NET 4 unterbrochene Änderungen

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

Dieses Whitepaper herunterladen

Inhalt

ControlRenderingCompatibilityVersion-Einstellung in der Web.config Datei
ClientIDMode-Änderungen
HtmlEncode und UrlEncode codieren jetzt einfache 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 Standardhashingalgorithmus ist jetzt HMACSHA256
Konfigurationsfehler im Zusammenhang mit der neuen ASP.NET 4-Stammkonfiguration
4 untergeordnete Anwendungen können nicht gestartet werden, wenn unter ASP.NET 2.0 oder ASP.NET 3.5 Anwendungen
4 Websites können nicht auf Computern gestartet werden, auf denen SharePoint installiert ist
Die HttpRequest.FilePath-Eigenschaft enthält keine PathInfo-Werte mehr.
ASP.NET 2.0-Anwendungen generieren möglicherweise HttpException-Fehler, die auf eurl.axd verweisen
Ereignishandler werden möglicherweise nicht in einem Standarddokument im integrierten IIS 7- oder IIS 7.5-Modus ausgelöst
Änderungen an der Implementierung von ASP.NET Code Access Security (CAS)
MembershipUser und andere Typen im System.Web.Security-Namespace wurden verschoben.
Ausgabezwischenspeicherungsänderungen für unterschiedliche * HTTP-Header
System.Web.Security-Typen für Passport sind veraltet
Die MenuItem.PopOutImageUrl-Eigenschaft kann ein Bild in ASP.NET 4 nicht rendern.
Menu.StaticPopOutImageUrl und Menu.DynamicPopOutImageUrl Fehler beim Rendern von Bildern, wenn Pfade umgekehrte Schrägstriche enthalten
Haftungsausschluss

ControlRenderingCompatibilityVersion-Einstellung in der Web.config Datei

ASP.NET Steuerelemente wurden in .NET Framework, Version 4, geändert, damit Sie genauer angeben können, wie sie Markup rendern. In früheren Versionen von .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 verwenden, um die Anwendung von ASP.NET 2.0 oder ASP.NET 3.5 zu aktualisieren, fügt das Tool automatisch eine Einstellung zu der Web.config Datei hinzu, die das Legacyrendering bewahrt. Wenn Sie jedoch ein Upgrade einer Anwendung durchführen, indem Sie den Anwendungspool in IIS so ändern, dass es auf .NET Framework 4 ausgerichtet ist, verwendet ASP.NET standardmäßig den neuen Renderingmodus. Um den neuen Renderingmodus zu deaktivieren, fügen Sie die folgende Einstellung in der Web.config Datei hinzu:

<pages controlRenderingCompatibilityVersion="3.5" />

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

  • Die Image - und ImageButton-Steuerelemente rendern kein border="0" Attribut mehr.
  • Die BaseValidator-Klasse und -Überprüfungssteuerelemente, die von ihr abgeleitet werden, rendern standardmäßig keinen roten Text mehr.
  • Das HtmlForm-Steuerelement rendert kein Namensattribute .
  • Das Table-Steuerelement rendert kein border="0" Attribut mehr.
  • Steuerelemente, die nicht für die Benutzereingabe vorgesehen sind (z. B. das Bezeichnungssteuerelement ), 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 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 entspricht das Standardverhalten der AutoID-Einstellung von ClientIDMode. Die Standardeinstellung ist jedoch jetzt vorhersehbar.

Wenn Sie Visual Studio 2010 zum Upgrade Ihrer Anwendung von ASP.NET 2.0 oder ASP.NET 3.5 verwenden, fügt das Tool automatisch eine Einstellung zu der Web.config Datei hinzu, die das Verhalten früherer Versionen von .NET Framework bewahrt. Wenn Sie jedoch ein Upgrade einer Anwendung durchführen, indem Sie den Anwendungspool in IIS so ändern, dass es auf .NET Framework 4 ausgerichtet ist, verwendet ASP.NET standardmäßig den neuen Modus. Um den neuen Client-ID-Modus zu deaktivieren, fügen Sie die folgende Einstellung in der Web.config Datei hinzu:

<pages clientIDMode="AutoID" />

HtmlEncode und UrlEncode codieren jetzt einfache Anführungszeichen

In ASP.NET 4 wurden die Methoden HtmlEncode und UrlEncode der Klassen HttpUtility und HttpServerUtility 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 einfachen 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 von ungültigem Markup ab. Die folgenden beiden Codeausschnitte würden beispielsweise erfolgreich in früheren Versionen von ASP.NET analysiert, lösen jetzt jedoch 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 unverkloste Style-Attribut , das im CssClass-Attribut ausgeführt wird.

Browserdefinitionsdateien aktualisiert

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

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

Hinweis

Das HttpBrowserCapabilities-Objekt (das von der Request.Browser-Eigenschaft der Seite verfügbar gemacht wird) wird von den Browserdefinitionsdateien 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 werden.

Sie können auf die alten Browserdefinitionsdateien zurücksetzen, indem Sie die Browserdefinitionsdateien aus dem folgenden Ordner kopieren:

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

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

System.Web.Mobile.dll aus der Stammwebkonfigurationsdatei entfernt

In früheren Versionen von ASP.NET wurde ein Verweis auf die System.Web.Mobile.dll-Assembly in die Stammdatei Web.config im Abschnitt "Assemblys " eingefügt. 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 jedoch veraltet. Wenn Sie Typen aus der System.Web.Mobile.dll-Assembly verwenden möchten, fügen Sie dieser Assembly entweder einen Verweis auf die Stammdatei Web.config oder eine Anwendungsdatei Web.config hinzu. Wenn Sie beispielsweise eines der (veralteten) ASP.NET mobilen Steuerelemente verwenden möchten, müssen Sie der Datei einen Verweis auf die Web.config System.Web.Mobile.dll-Assembly hinzufügen.

ASP.NET Anforderungsüberprüfung

Das Anforderungsüberprüfungsfeature in ASP.NET bietet einen bestimmten Standardschutz vor Angriffen auf websiteübergreifendes Skripting (Cross Site Scripting, XSS). In früheren Versionen von ASP.NET wurde die Anforderungsüberprüfung standardmäßig aktiviert. Sie wurde jedoch nur auf ASP.NET Seiten (.aspx Dateien und deren Klassendateien) angewendet, und nur dann, 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. Dazu gehören 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 Anforderungsüberprüfungsfehler jetzt für Anforderungen auftreten, die zuvor keine Fehler ausgelöst haben. Um das Verhalten des ASP.NET 2.0-Anforderungsüberprüfungsfeatures wiederhergestellt zu können, fügen Sie die folgende Einstellung in der Web.config Datei hinzu:

<httpRuntime requestValidationMode="2.0" />

Es wird jedoch empfohlen, alle Anforderungsüberprüfungsfehler zu analysieren, um festzustellen, ob vorhandene Handler, Module oder andere benutzerdefinierte Code auf potenziell unsichere HTTP-Eingaben zugreifen, die XSS-Angriffsvektoren sein könnten.

Der Standardhashingalgorithmus ist jetzt HMACSHA256

ASP.NET verwendet Verschlüsselungs- und Hashingalgorithmen, um Daten wie Formularauthentifizierungscookies und Ansichtszustand zu sichern. Standardmäßig verwendet ASP.NET 4 jetzt den HMACSHA256 Algorithmus für Hashvorgänge in Cookies und Ansichtszustand. In früheren Versionen von ASP.NET wurde der ältere 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 die folgende Einstellung in der Web.config Datei hinzu:

<machineKey validation="SHA1" />

Die Stammkonfigurationsdateien (die machine.config Datei und die Stammdatei Web.config ) für .NET Framework 4 (und daher ASP.NET 4) wurden aktualisiert, um die meisten Konfigurationsinformationen zu 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 von ASP.NET 3.5-Anwendungen unter ASP.NET 4 und unter IIS 7 und IIS 7.5 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. 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 ist jedoch ein unterstütztes Szenario, ASP.NET 3.5-Anwendungen mit .NET Framework 4 ohne erneute Kompilierung auszuführen. In diesem Fall müssen Sie die Anwendungsdatei Web.config möglicherweise manuell ändern, bevor Sie die Anwendung unter .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 falsch 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 .NET Framework 3.5 oder höher über eine System.web.extensions-Konfigurationsabschnittsdefinition (das Element) verfügen, um keinen IIS 7-Überprüfungsfehler 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 allowDefinition - und requirePermission-Konfigurationsattribute verlassen, 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 ASP.NET 4-Datei 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 und auch Windows Vista SP1 und Windows Server 2008 SP1, wo Hotfix-KB958854 installiert sind.

In diesem Szenario gibt das systemeigene IIS 7 und IIS 7.5-Konfigurationssystem einen Konfigurationsfehler zurück, da er einen Textvergleich für das Typattribute durchführt, das für einen verwalteten Konfigurationsabschnittshandler definiert ist. Da alle Web.config Von Visual Studio 2008 und Visual Studio 2008 SP1 generierten Dateien "3.5" in der Typzeichenfolge für die Konfigurationsabschnittshandler " system.web.extensions " (und zugehörige) aufweisen, und da die ASP.NET 4-Datei machine.config "4.0" im Typ-Attribut für dieselben Konfigurationsabschnittshandler aufweist, treten Anwendungen, die in Visual Studio 2008 oder Visual Studio 2008 SP1 generiert werden, immer die Konfigurationsüberprüfung in IIS 7 und IIS 7.5 fehl.

Beheben dieser Probleme

Die Problemumgehung für das erste Szenario besteht darin, die Datei auf Anwendungsebene Web.config zu aktualisieren, indem der Textbausteine der Konfigurationstext aus einer Web.config Datei eingeschlossen wird, 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 aufgrund des für das zweite Szenario beschriebenen Problems wahrscheinlich ein Konfigurationsfehler auf.

Die Problemumgehung für das zweite Szenario besteht darin, alle Konfigurationsabschnittsdefinitionen für system.web.extensions 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 die 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 unter ASP.NET 2.0 oder ASP.NET 3.5 Anwendungen

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

In IIS 6 kann die Anwendung im childwebapp Ordner ebenfalls nicht gestartet werden, meldet jedoch einen anderen Fehler. Der Fehlertext kann beispielsweise Folgendes angeben:

  • 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, da die Konfigurationsinformationen aus der übergeordneten Anwendung im parentwebapp Ordner Teil der Hierarchie von Konfigurationsinformationen sind, die die endgültigen zusammengeführten Konfigurationseinstellungen bestimmen, 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 ASP.NET 4 Kompilierungssystem einen Fehler zurück.

Die Schritte, die Sie ausführen müssen, um dieses Problem zu beheben und die untergeordnete ASP.NET 4-Anwendung zu funktionieren, hängt davon ab, ob die ASP.NET 4-Anwendung 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, die IIS 7 oder IIS 7.5 ausführen, einschließlich Windows Vista, Windows Server 2008, Windows 7 und Windows Server 2008 R2.

Verschieben Sie die configSections-Definition 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. Durch das Verschieben der configSections-Definition aus der Datei der übergeordneten Webanwendung Web.config in die Stammdatei Web.config wird das Element effektiv aus dem Konfigurationszusammenführungsprozess ausgeblendet, der für die untergeordnete ASP.NET 4-Anwendung auftritt.

Auf 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

Auf 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 soll, 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, ob die untergeordnete ASP.NET 4-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 Speicherortelements :

<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 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 nicht auf Computern gestartet werden, auf denen SharePoint installiert ist

Webserver, auf denen SharePoint ausgeführt wird, verfügen über eine Web.config Datei, die im Stammverzeichnis einer SharePoint-Website bereitgestellt wird (z. B. für Die c:\inetpub\wwwroot\web.config 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 dieser Art von SharePoint-Website bereitgestellt wird, wird der folgende Fehler angezeigt:

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

Dieser Fehler tritt auf, da die ASP.NET 4-Codezugriffssicherheitsinfrastruktur (CAS) nach einem Berechtigungssatz mit dem Namen 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 unter SharePoint-Websites auszuführen.

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

Frühere Versionen von ASP.NET enthielten einen PathInfo-Wert in den Wert, der aus verschiedenen dateipfadbezogenen Eigenschaften zurückgegeben wird, einschließlich HttpRequest.FilePath, HttpRequest.AppRelativeCurrentExecutionFilePath und HttpRequest.CurrentExecutionFilePath. ASP.NET 4 enthält nicht mehr den PathInfo-Wert in den Rückgabewerten dieser Eigenschaften. Stattdessen sind die PathInfo-Informationen in HttpRequest.PathInfo verfügbar. Stellen Sie sich beispielsweise das folgende URL-Fragment vor:

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

Dieser Fehler tritt auf, da ASP.NET erkennt, dass eine Website für die Verwendung ASP.NET 4 konfiguriert ist, eine systemeigene Komponente von ASP.NET 4 eine erweiterungslose URL an den verwalteten Teil der ASP.NET zur weiteren Verarbeitung übergibt. Wenn virtuelle Verzeichnisse, die sich unter einer ASP.NET 4-Website befinden, jedoch 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 ASP.NET 2.0-Anwendung 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 stattdessen ASP.NET 2.0 zu.

Option 2

Wenn ASP.NET 4 erforderlich ist, um die Website auszuführen, verschieben Sie alle untergeordneten ASP.NET 2.0 virtuellen Verzeichnisse in 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 Verhalten der erweiterungslosen URL 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

Das Festlegen von EnableExtensionlessUrls auf 1 ermöglicht das Verhalten der erweiterungslosen URL. 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ürde http://contoso.com/dazu führen, dass eine Anforderung an http://contoso.com/Default.aspx.

ASP.NET 4 rendert nun den Aktions-Attributwert des HTML-Formularelements 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 z. B. eine Anforderung an http://contoso.com eine Anforderung an Default.aspx. In diesem Dokument würde das öffnende Formulartag wie im folgenden Beispiel gerendert:

<form action="Default.aspx" />

In ASP.NET 4 führt eine Anforderung, http://contoso.com auch eine Anforderung an .Default.aspx ASP.NET rendert nun jedoch das HTML-Öffnende Formulartag wie im folgenden Beispiel:

<form action="" />

Dieser Unterschied beim Rendern des Aktionsattributes kann zu subtilen Änderungen bei der Verarbeitung eines Formularbeitrags durch IIS und ASP.NET führen. Wenn das Aktions-Attribut 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 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 Aktions-Attribut des Formularelements auf "" festgelegt ist.
  2. Das Formular wird zurück zu ASP.NET gepostet.
  3. Ein verwaltetes HTTP-Modul liest einen Teil des Entitätstexts vor. Ein Modul liest z. B. "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.
  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 Ausführungsphase des Handlers ausgeführt.
  6. Da kein Entitätstext 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.

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 bestimmen Sie, ob es so konfiguriert werden kann, dass es nur für verwaltete Anforderungen ausgeführt werden kann. Im integrierten Modus für IIS 7 und IIS 7.5 können HTTP-Module so gekennzeichnet werden, dass sie nur für verwaltete Anforderungen ausgeführt werden, indem sie dem Eintrag "system.webServer/modules " des Moduls das folgende Attribut hinzufügen:

  • precondition="managedHandler"

  • Diese Einstellung deaktiviert das Modul für Anforderungen, die IIS 7 und IIS 7.5 als nicht verwaltete Anforderungen bestimmen. Bei Standarddokumentanforderungen besteht die erste Anforderung an 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 den Entitätstext nicht versehentlich lesen und somit ist der Entitätstext weiterhin verfügbar und wird an die untergeordnete Anforderung und an das Standarddokument übergeben.

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

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

ASP.NET 2.0 und durch Erweiterung der in 3.5 hinzugefügten ASP.NET Features verwenden Sie das .NET Framework 1.1- und 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 auf vertrauenswürdigem Code basieren, der im globalen Assemblycache (GAC) ausgeführt wird, mit verschiedenen Sicherheits exceptions fehlschlagen. Teilweise vertrauenswürdige Anwendungen, die auf umfangreichen Änderungen an der Cas-Richtlinie des Computers basieren, können auch mit Sicherheits exceptions 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 zurücksetzen, wie im folgenden Beispiel gezeigt:

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

Wenn Sie zum älteren CAS-Modell zurückkehren, sind die folgenden alten CAS-Verhalten aktiviert:

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

Ein Szenario kann in .NET Framework 4 nicht wiederhergestellt werden: Nicht-Web partielle vertrauenswürdige Anwendungen können bestimmte APIs in System.Web.dll und System.Web.Extensions.dllnicht mehr aufrufen. In früheren Versionen von .NET Framework war es möglich, dass nicht webpartbasierte Anwendungen explizit AspNetHostingPermission-Berechtigungen erteilt werden konnten. 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 aus nicht webpartbasierten Vertrauensanwendungen wird in .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 stattdessen den Code der Anwendung, um die neue WebUtility-Klasse zu verwenden.

Es folgt eine allgemeine Zusammenfassung der Änderungen an der standardmäßigen CAS-Implementierung in ASP.NET 4:

  • ASP.NET Anwendungsdomänen sind jetzt homogene Anwendungsdomänen. Nur teilbasierte und voll vertrauenswürdige Zuschüsse sind in einer Anwendungsdomäne verfügbar.
  • ASP.NET teilbasierten Vertrauenswürdigkeitssätzen unabhängig von jeder CAS-Richtlinie auf Unternehmensebene, Computerebene oder cas-Richtlinie auf Benutzerebene sind.
  • ASP.NET Assemblys, die in 3.5 und 3.5 SP1 ausgeliefert wurden, wurden in die Verwendung des .NET Framework 4-Transparenzmodells 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 werden jetzt so gekennzeichnet, dass das APTCA-Attribut nur in Webhostingumgebungen berücksichtigt wird. Teilweise vertrauenswürdige Nicht-Webhosting-Umgebungen wie ClickOnce können keine ASP.NET Assemblys 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 von System.Web.dll der neuen 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.

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

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

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

Klassenbibliotheken, die bestimmte Mitgliedschaftstypen verwenden und 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. Ein Klassenbibliotheksprojekt kann z. B. nicht kompiliert werden und einen Fehler melden, z. B. folgendes:

  • 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 ihrem Klassenbibliotheksprojekt einen Verweis zu System.Web.ApplicationServices.dllhinzufügen.

In der folgenden Liste sind die System.Web.Security-Typen aufgeführt, die von System.Web.dll System.Web.ApplicationServices.dllverschoben 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

Ausgabezwischenspeicherungsänderungen für unterschiedliche * HTTP-Header

In ASP.NET 1.0 verursachte ein Fehler zwischengespeicherte Seiten, die als Ausgabecacheeinstellung angegeben Location="ServerAndClient" wurden, einen Vary:* HTTP-Header in der Antwort auszugeben. Dies hatte zur Folge, dass Client-Browser die Seite nie lokal zwischenspeichern.

In ASP.NET 1.1 wurde die System.Web.HttpCachePolicy.SetOmitVaryStar-Methode hinzugefügt, die Sie aufrufen konnten, um den Vary:* Header zu unterdrücken. Diese Methode wurde ausgewählt, da das Ändern des ausgegebenen HTTP-Headers zu dem Zeitpunkt als potenziell bahnbrechende Ä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 Direktive angeben:

<%@OutputCache Location="ServerAndClient" %>

Daher wird SetOmitVaryStar nicht mehr benötigt, um die Vary:* Kopfzeile 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 – d. h. Seiten werden im Browser zwischengespeichert, ohne dass Sie die SetOmitVaryStar-Methode aufrufen müssen.

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

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

Alternativ können Sie den Wert des Ausgabezwischenspeicherungsspeicherort-Attributs in "Server" ändern.

System.Web.Security-Typen für 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 Typen im Zusammenhang mit Passport 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. Das folgende Beispiel zeigt, 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>

Aufgrund 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 Menüsteuerelement mithilfe der StaticPopOutImageUrl-Eigenschaft oder der DynamicPopOutImageUrl-Eigenschaft angeben. Wenn Sie mit einem statischen Menü arbeiten, gibt die Menu.StaticPopOutImageUrl-Eigenschaft die URL für ein Bild an, das angezeigt wird, 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 Eigenschaft Menu.DynamicPopOutImageUrl , 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 jedoch, 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 ist und die StaticEnableDefaultPopOutImage-Eigenschaft auf "false" festgelegt ist, wird kein Bild angezeigt.

Wenn Sie die Pfade für diese Eigenschaften festlegen, verwenden Sie anstelle eines umgekehrten Schrägstrichs (/) einen Schrägstrich (/). Weitere Informationen finden Sie unter Menu.StaticPopOutImageUrl und Menu.DynamicPopOutImageUrl Fail to Render Images When Paths Contain Backslashes elsewhere in this document.

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

Das folgende Beispiel des Menüsteuerelementmarkups zeigt den StaticPopOutImageUrl-Eigenschaftssatz mithilfe eines Pfads, 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, ebenfalls betroffen sind, da die MenuItem.PopOutImageUrl-Eigenschaft geändert wurde. Weitere Informationen finden Sie unter The MenuItem.PopOutImageUrl Property Fails to Render an Image in ASP.NET 4 elsewhere in this document.

Haftungsausschluss

Dies ist ein vorläufiges Dokument und kann erheblich vor der endgültigen kommerziellen Veröffentlichung der hier beschriebenen Software geändert werden.

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 sich ändernde Marktbedingungen reagieren muss, sollte dies nicht als Verpflichtung von Microsoft interpretiert werden, und Microsoft kann nicht für die Richtigkeit der nach dem Datum der Veröffentlichung vorgelegten Informationen garantieren.

Dieses Weißbuch dient nur zu Informationszwecken. MICROSOFT ÜBERNIMMT BEZÜGLICH DER INFORMATIONEN IN DIESEM DOKUMENT KEINE GEWÄHRLEISTUNGEN, SEI SIE AUSDRÜCKLICH, KONKLUDENT ODER GESETZLICH GEREGELT.

Die Einhaltung aller anwendbaren Urheberrechtsgesetze liegt in der Verantwortung des Nutzers. Ohne Einschränkung der Rechte des Urheberrechts kann kein Teil dieses Dokuments in einem Abrufsystem vervielfältigt, in einem Abrufsystem gespeichert oder in irgendeiner Form oder auf irgendeine Weise übertragen werden (elektronische, mechanische, Fotokopie, Aufzeichnung oder anderweitig), oder zu irgendeinem Zweck, ohne die ausdrückliche schriftliche Erlaubnis der Microsoft Corporation.

Microsoft verfügt möglicherweise über Patente, Patentanmeldungen, Marken, Urheberrechte oder andere Rechte des geistigen Eigentums, die Gegenstand dieses Dokuments abdecken. Sofern nicht ausdrücklich in einem schriftlichen Lizenzvertrag von Microsoft vorgesehen, erhalten Sie durch die Bereitstellung dieses Dokuments keine Lizenz für diese Patente, Marken, Urheberrechte oder andere geistiges Eigentum.

Sofern nicht anders angegeben, sind die Hierin dargestellten Beispielunternehmen, Organisationen, Produkte, Domänennamen, E-Mail-Adressen, Logos, Personen, Orte und Ereignisse fikttiv, und keine Zuordnung zu einem echten Unternehmen, Unternehmen, Produkt, Domänennamen, E-Mail-Adresse, Logo, Person, Ort oder Ereignis ist vorgesehen oder sollte abgeleitet werden.

© 2010 Microsoft Corporation. Alle Rechte vorbehalten.

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

Die Namen der tatsächlichen Unternehmen und Produkte, die hier erwähnt werden, können die Marken ihrer jeweiligen Eigentümer sein.

  • Last updated on