Microsoft .NET Framework 4-Infodatei

Die aktuellste Version der Infodatei finden Sie hier.

1. Systemanforderungen

1.1 Unterstützte Architekturen

1.2 Unterstützte Betriebssysteme

1.3 Hardwareanforderungen

1.4 Sonstige Systemanforderungen

2. Bekannte Probleme

2.1 Installation

2.1.1 Vollständiges Framework (Installation)

2.1.1.1 Typ "System.ServiceModel.Activation.HttpModule" kann bei installiertem .NET Framework 4 nach Änderung von .NET Framework 3.5 nicht geladen werden

Dieses Problem kann durch die folgenden Szenarios verursacht werden:

Im Folgenden finden Sie den vollständigen Text des Fehlers:

Der Typ "System.ServiceModel.Activation.HttpModule" in der Assembly "System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" konnte nicht geladen werden.

Beschreibung: Unbehandelte Ausnahme beim Ausführen der aktuellen Webanforderung. Überprüfen Sie die Stapelüberwachung, um weitere Informationen über diesen Fehler anzuzeigen und festzustellen, wo der Fehler im Code verursacht wurde.

So beheben Sie dieses Problem

2.1.1.2 Nach dem Deinstallieren von .NET Framework 4 Beta 2 bleiben unter Windows Vista, Windows Server 2008 und Windows 7 in der Datei "applicationHost.config" nicht verwendete "isapiCgiRestriction"-Einträge erhalten

Auf Computern, auf denen IIS 7 oder IIS 7.5 aktiviert und .NET Framework 4 installiert ist, bleiben nach dem Deinstallieren der Version Beta 2 in der Datei applicationHost.config nicht verwendete "isapiCgiRestriction"-Einträge erhalten. Dies ist der Fall unter Windows Vista, Windows Server 2008 und Windows 7. Die nicht verwendeten Einträge wirken sich nicht auf die Webserverfunktion aus. Höhere Versionen von .NET Framework 4 können sicher auf demselben Computer installiert werden, da bei späteren Installationen die "isapiCgiRestriction"-Einträge aktualisiert werden.

So beheben Sie dieses Problem

Löschen Sie die nicht verwendeten "isapiCgiRestriction"-Einträge in der Datei applicationHost.config. Dieser Schritt ist jedoch nicht erforderlich, da sich die nach dem Deinstallieren verbleibenden Einträge nicht auf die Funktionalität des Produkts oder die Möglichkeit, höhere Versionen zu installieren, auswirken.

2.1.1.3 .NET Framework 1.0 kann nicht nach .NET Framework 4 installiert werden

.NET Framework 1.0 kann nicht nach .NET Framework 4 installiert werden.  .NET Framework 1.0 muss vor .NET Framework 4 installiert werden.

So beheben Sie dieses Problem

  1. Öffnen Sie in der Systemsteuerung Programme und Funktionen.
  2. Deinstallieren Sie .NET Framework 4 Extended.
  3. Deinstallieren Sie .NET Framework 4 Client Profile.
  4. Deinstallieren Sie .NET Framework 1.0.
  5. Deinstallieren Sie .NET Framework 4.

2.1.1.4 Beim Setup von .NET Framework 4 tritt ein Fehler auf

Beim Setup von .NET Framework 4 tritt ein Fehler auf.

So beheben Sie dieses Problem

Entsprechende Informationen finden Sie im Handbuch zur Problembehandlung für das .NET Framework 4 Setup (http://go.microsoft.com/fwlink/?LinkId=186690).

2.1.1.5 Der Windows Presentation Foundation (WPF) 4-Schriftartcachedienst wird bei der Deinstallation von .NET Framework 4 (vollständiges Framework) nicht vollständig entfernt

Der Windows Presentation Foundation (WPF) 4-Schriftartcachedienst wird bei der Deinstallation von .NET Framework 4 (vollständiges Framework) nicht vollständig entfernt.

Hinweis: Dieses Problem betrifft sowohl die vollständige Version als auch die Client Profile-Version von .NET Framework.

So beheben Sie dieses Problem

  1. Öffnen Sie ein Befehlsfenster im Administratormodus.
  2. Geben Sie den folgenden Befehl ein: sc delete WPFFontCache_v0400

Jetzt sollte [SC] DeleteService SUCCESS angezeigt werden.

Nach dem Aktualisieren der Dienstekonsole sollte der Schriftartcache nicht angezeigt werden.  Falls das Problem durch die Aktualisierung nicht behoben wird, starten Sie den Computer neu.

2.1.2 Client Profile (Installation)

2.1.2.1 .NET Framework 1.0 kann nicht nach .NET Framework 4 Client Profile installiert werden

.NET Framework 1.0 kann nicht nach .NET Framework 4 Client Profile installiert werden.  .NET Framework 1.0 muss vor .NET Framework 4 Client Profile installiert werden.

So beheben Sie dieses Problem

  1. Öffnen Sie in der Systemsteuerung Programme und Funktionen.
  2. Deinstallieren Sie .NET Framework 4 Client Profile.
  3. Deinstallieren Sie .NET Framework 1.0.
  4. Installieren Sie .NET Framework 4 Client Profile.

2.1.2.2 Der Windows Presentation Foundation (WPF) 4-Schriftartcachedienst wird bei der Deinstallation von .NET Framework 4 (Client Profile) nicht vollständig entfernt

Bei der Deinstallation von .NET Framework 4 wird der WPF-Schriftartcachedienst möglicherweise nicht vollständig entfernt. 

Obwohl der WPF-Schriftartcachedienst nach der Deinstallation nicht mehr verwendet werden kann, wird der Diensteintrag Windows Presentation Foundation Font Cache 4.0.0.0 weiterhin in der Dienstekonsole angezeigt.

Unter Windows Vista und Windows Server 2008 wird im Feld Beschreibung die folgende Meldung angezeigt: <Fehler beim Lesen der Beschreibung. Fehlercode: 2 >.  Unter Windows XP und Windows Server 2003 wird im Feld Beschreibung weiterhin die richtige Zeichenfolge angezeigt.

Dieses Problem kann durch eine Neuinstallation von .NET Framework behoben werden. Weitere Auswirkungen sind nicht bekannt.

Hinweis: Dieses Problem betrifft sowohl die Client Profile-Version als auch die vollständige Version von .NET Framework.

So beheben Sie dieses Problem

  1. Öffnen Sie ein Befehlsfenster im Administratormodus.
  2. Geben Sie den folgenden Befehl ein: sc delete WPFFontCache_v0400

Jetzt sollte [SC] DeleteService SUCCESS angezeigt werden.

Nach dem Aktualisieren der Dienstekonsole sollte der Schriftartcache nicht angezeigt werden.  Falls das Problem durch die Aktualisierung nicht behoben wird, starten Sie den Computer neu.

2.1.2.3 Beim Setup von .NET Framework 4 Client Profile tritt ein Fehler auf

Beim Setup von .NET Framework 4 Client Profile tritt ein Fehler auf.

So beheben Sie dieses Problem

Entsprechende Informationen finden Sie im Handbuch zur Problembehandlung für das .NET Framework 4 Setup (http://go.microsoft.com/fwlink/?LinkId=186690).

2.2 Deinstallation

2.2.1 Vollständiges Framework (Deinstallation)

2.2.1.1 Nach dem Deinstallieren von .NET Framework 4 Beta 2 bleiben unter Windows Vista, Windows Server 2008 und Windows 7 in der Datei "applicationHost.config" nicht verwendete "isapiCgiRestriction"-Einträge erhalten

Auf Computern, auf denen IIS 7 oder IIS 7.5 aktiviert und .NET Framework 4 installiert ist, bleiben nach dem Deinstallieren der Version Beta 2 in der Datei applicationHost.config nicht verwendete "isapiCgiRestriction"-Einträge erhalten. Dies ist der Fall unter Windows Vista, Windows Server 2008 und Windows 7. Die nicht verwendeten Einträge wirken sich nicht auf die Webserverfunktion aus. Höhere Versionen von .NET Framework 4 können sicher auf demselben Computer installiert werden, da bei späteren Installationen die "isapiCgiRestriction"-Einträge aktualisiert werden.

So beheben Sie dieses Problem

Löschen Sie die nicht verwendeten "isapiCgiRestriction"-Einträge in der Datei applicationHost.config. Dieser Schritt ist jedoch nicht erforderlich, da sich die nach dem Deinstallieren verbleibenden Einträge nicht auf die Funktionalität des Produkts oder die Möglichkeit, höhere Versionen zu installieren, auswirken.

2.2.1.2 Der WPF 4.0-Schriftartcachedienst wird bei der Deinstallation von NET4 (vollständiges Framework) nicht vollständig entfernt

Löschen Sie zum Umgehen des Problems den verwaisten Schriftartcachedienst vollständig:

  1. Öffnen Sie ein Befehlsfenster im Administratormodus.
  2. Geben Sie den folgenden Befehl ein: sc delete WPFFontCache_v0400

Auf dem Bildschirm sollte Folgendes angezeigt werden:  [SC] DeleteService SUCCESS

Wenn Sie die Dienstekonsole aktualisieren, sollte der Schriftartcache jetzt nicht angezeigt werden.  Möglicherweise ist ein Neustart erforderlich, wenn das Problem durch die Aktualisierung der Dienstekonsole nicht behoben wurde.

(Hinweis: Dieses Problem betrifft das vollständige Framework und ist eine Kopie der Client Profile-Probleme unter 877240 in der Infodatei.)

So beheben Sie dieses Problem

Löschen Sie zum Umgehen des Problems den verwaisten Schriftartcachedienst vollständig:

  1. Öffnen Sie ein Befehlsfenster im Administratormodus.
  2. Geben Sie den folgenden Befehl ein: sc delete WPFFontCache_v0400

Auf dem Bildschirm sollte Folgendes angezeigt werden: [SC] DeleteService SUCCESS

Wenn Sie die Dienstekonsole aktualisieren, sollte der Schriftartcache jetzt nicht angezeigt werden.  Möglicherweise ist ein Neustart erforderlich, wenn das Problem durch die Aktualisierung der Dienstekonsole nicht behoben wurde.

2.2.2 Client Profile (Deinstallation)

2.2.2.1 Der WPF 4.0-Schriftartcachedienst wird bei der Deinstallation von NET4 (Client Profile) nicht vollständig entfernt

Bei der Deinstallation von .NET 4.0 unter Vista/XP/W2K3/W2K8 wird der WPF-Schriftartcachedienst nicht ordnungsgemäß deinstalliert. 

Obwohl der WPF-Schriftartcachedienst nach der Deinstallation nicht mehr verwendet werden kann, wird der Diensteintrag Windows Presentation Foundation Font Cache 4.0.0.0 weiterhin in der Dienstekonsole angezeigt.

Unter Vista und W2K8 wird im Feld Beschreibung die folgende Meldung angezeigt: <Fehler beim Lesen der Beschreibung. Fehlercode: 2 >.  Unter XP/W2K3 wird im Feld Beschreibung weiterhin die richtige Zeichenfolge angezeigt.

Dieses Problem können Sie durch eine Framework-Neuinstallation beheben. Weitere Auswirkungen sind nicht bekannt.

Hinweis: Dieses Problem betrifft sowohl Net4 Client Profile als auch die vollständige Version von NET4.

So beheben Sie dieses Problem

Löschen Sie zum Umgehen des Problems den verwaisten Schriftartcachedienst vollständig:

  1. Öffnen Sie ein Befehlsfenster im Administratormodus.
  2. Geben Sie den folgenden Befehl ein: sc delete WPFFontCache_v0400

Auf dem Bildschirm sollte Folgendes angezeigt werden: [SC] DeleteService SUCCESS

Wenn Sie die Dienstekonsole aktualisieren, sollte der Schriftartcache jetzt nicht angezeigt werden.  Möglicherweise ist ein Neustart erforderlich, wenn das Problem durch die Aktualisierung der Dienstekonsole nicht behoben wurde.

(Hinweis: Dieses Problem betrifft Client Profile und ist eine Kopie der Probleme für das vollständige Framework unter 888322 in der Infodatei. 

2.3 Probleme mit dem Produkt

2.3.1Allgemeine Probleme

2.3.1.1 Fehler bei der ClickOnce-Veröffentlichung aufgrund falscher Position der Redistributable Language Packs

Möglicherweise wird ein Buildfehler angezeigt, wenn Sie die Visual Studio 2010-Version für Chinesisch (vereinfacht) oder Chinesisch (traditionell) zur Veröffentlichung einer Anwendung verwenden, im Dialogfeld Erforderliche Komponenten die Option Erforderliche Komponenten von demselben Speicherort wie Anwendung herunterladen aktivieren und eine der folgenden Komponenten als erforderliche Komponente auswählen:

  1. Microsoft .NET Framework 4 (x86 und x64)
  2. Microsoft .NET Framework 4 Client Profile (x86 und x64)
  3. Microsoft Visual F#-Runtime für .NET 2.0
  4. Microsoft Visual F#-Runtime für .NET 4.0

Für Microsoft .NET Framework 4 Client Profile (x86 und x64) kann der folgende Buildfehler angezeigt werden:

"MSB3152: Der Installationspfad für die erforderlichen Komponenten wurde nicht auf "Webseite für Bereitstellung der Komponenten" festgelegt, und die Datei "DotNetFX40Client\dotNetFx40LP_Client_x86_x64cs.exe" in Element "Microsoft .NET Framework 4 Client Profile (x86 und x64)" konnte auf dem Datenträger nicht gefunden werden. Weitere Informationen finden Sie in der Hilfe."

So umgehen Sie dieses Problem

    Führen Sie folgende Schritte aus, um das Problem für Chinesisch (vereinfacht) zu umgehen:

  1. Öffnen Sie den Ordner %ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client. Bei x64-Betriebssystemen beginnt der Pfad mit %ProgramFiles(x86)%.
  2. Kopieren Sie den Ordner zh-Hans in einen neuen Ordner mit der Bezeichnung zh-chs.
  3. Navigieren Sie zum Ordner zh-chs.
  4. Öffnen Sie die Datei Package.xml im Administratormodus.
  5. Ändern Sie den Wert von >Culture< wie folgt in zh-chs:
  6. <String Name="Culture">zh-chs</String>

    Führen Sie folgende Schritte aus, um das Problem für Chinesisch (traditionell) zu umgehen:

  1. Öffnen Sie den Ordner %ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client. Bei x64-Betriebssystemen beginnt der Pfad mit %ProgramFiles(x86)%.
  2. Kopieren Sie den Ordner zh-Hant in einen neuen Ordner mit der Bezeichnung zh-cht.
  3. Navigieren Sie zum Ordner zh-cht.
  4. Öffnen Sie die Datei Package.xml im Administratormodus.
  5. Ändern Sie den Wert von >Culture< wie folgt in zh-cht:
  6. <String Name="Culture">zh-cht</String>

2.3.1.2 Von der ClickOnce-Anwendung werden die falschen Redistributable Language Packs installiert

Möglicherweise können die Language Packs für Chinesisch (vereinfacht) und Chinesisch (traditionell) nicht installiert werden, wenn Sie die Visual Studio 2010-Version für Chinesisch (vereinfacht) oder Chinesisch (traditionell) zur Veröffentlichung einer Anwendung verwenden, im Dialogfeld Erforderliche Komponenten die Option Erforderliche Komponenten von der Website des Komponentenherstellers herunterladen aktivieren und eine der folgenden Komponenten als erforderliche Komponente auswählen:

  1. Microsoft .NET Framework 4 (x86 und x64)
  2. Microsoft .NET Framework 4 Client Profile (x86 und x64)
  3. Microsoft Visual F#-Runtime für .NET 2.0
  4. Microsoft Visual F#-Runtime für .NET 4.0

So umgehen Sie dieses Problem

    Führen Sie folgende Schritte aus, um das Problem für Chinesisch (vereinfacht) zu umgehen:

  1. Öffnen Sie den Ordner %ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client. Bei x64-Betriebssystemen beginnt der Pfad mit %ProgramFiles(x86)%.
  2. Kopieren Sie den Ordner zh-Hans in einen neuen Ordner mit der Bezeichnung zh-chs.
  3. Navigieren Sie zum Ordner zh-chs.
  4. Öffnen Sie die Datei Package.xml im Administratormodus.
  5. Ändern Sie den Wert von >Culture< wie folgt in zh-chs:
  6. <String Name="Culture">zh-chs</String>

    Führen Sie folgende Schritte aus, um das Problem für Chinesisch (traditionell) zu umgehen:

  1. Öffnen Sie den Ordner %ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\DotNetFX40Client. Bei x64-Betriebssystemen beginnt der Pfad mit %ProgramFiles(x86)%.
  2. Kopieren Sie den Ordner zh-Hant in einen neuen Ordner mit der Bezeichnung zh-cht.
  3. Navigieren Sie zum Ordner zh-cht.
  4. Öffnen Sie die Datei Package.xml im Administratormodus.
  5. Ändern Sie den Wert von >Culture< wie folgt in zh-cht:
  6. <String Name="Culture">zh-cht</String>

2.3.2 ASP.NET

2.3.2.1 Nach der Installation von .NET Framework 4 unter Windows 7 können für einzelne Anwendungspools unter IIS 7.5 keine ASP.NET-Konfigurationsdateien mehr konfiguriert werden

Wenn Sie .NET Framework 4 auf einem Client- oder Servercomputer unter Windows 7 installiert haben, auf dem IIS 7.5 aktiviert ist, kann die Option zum Konfigurieren von ASP.NET-Konfigurationsdateien für verschiedene Anwendungspools nicht mehr verwendet werden. Der Grund dafür besteht darin, dass beim Installieren von .NET Framework 4 eine geringfügige Änderung am Standardverhalten der CLR-Initialisierung (Common Language Runtime) vorgenommen wird. Wenn .NET Framework 4 installiert ist, ruft IIS 7.5 unter Windows 7 eine systemeigene ASP.NET 4-DLL auf, um die CLR-Initialisierung auszuführen, und diese Initialisierungslogik verhindert die Verwendung anderer Konfigurationsdateien.

So beheben Sie dieses Problem

Da die CLR-Initialisierungslogik für .NET Framework 4 und IIS 7.5 im Prinzip gleich ist (abgesehen von der genannten Nebenwirkung für Konfigurationsdateien), können Sie IIS 7.5 so umkonfigurieren, dass die CLR-Initialisierung nicht mehr an ASP.NET 4 delegiert wird. Dazu stehen Ihnen zwei Möglichkeiten zur Verfügung.

Option 1
----------
Legen Sie in der Datei applicationHost.config von IIS 7.5 den Standardwert des managedRuntimeLoader-Attributs, wie im folgenden Beispiel veranschaulicht, auf eine leere Zeichenfolge fest:

<applicationPools>
  <applicationPoolDefaults managedRuntimeLoader="" />
</applicationPools>

Option 2
----------
Legen Sie in der Datei IIS_Schema.xml von IIS 7.5 im managedRuntimeLoader-Attribut defaultValue auf eine leere Zeichenfolge fest. Das Attribut kann ursprünglich beispielsweise dem folgenden Beispiel ähneln: 

<attribute name="managedRuntimeLoader" type="string" defaultValue="webengine4.dll" />

Ändern Sie es in das folgende Markup:

<attribute name="managedRuntimeLoader" type="string" defaultValue="" />

2.3.2.2 Beim Aufheben der Registrierung und erneuten Registrieren von ASP.NET 4 unter Windows XP und Windows Server 2003 wird in der IIS-MMC auf der ASP.NET-Eigenschaftenregisterkarte für die ASP.NET-Version ein leerer Wert geschrieben

Wenn Sie unter Windows XP und Windows Server 2003 (alle Versionen) die Registrierung von ASP.NET 4 bei IIS aufheben und dann ASP.NET 4 erneut registrieren, wird in der IIS-MMC auf der ASP.NET-Registerkarte für die ASP.NET-Versionsliste ein leerer Wert angezeigt. Dieses Problem wird bei Ausführung der folgenden Schrittfolge ausgelöst:

  1. Verwenden der ASP.NET 4-Version von aspnet_regiis, Ausführen von "aspnet_regiis -u"
  2. Verwenden der ASP.NET 4-Version von aspnet_regiis, Ausführen von "aspnet_regiis -i -enable"

So beheben Sie dieses Problem

Wählen Sie in der IIS-MMC in der ASP.NET-Versionsliste manuell die gewünschte Version von ASP.NET aus, und klicken Sie dann auf die Schaltfläche Übernehmen.

2.3.2.3 Bei ASP.NET-Kompilierungsaufgaben unter Windows Vista, Windows Server 2008 und Windows 7 tritt möglicherweise ein Fehler auf, da der IIS-Arbeitsprozess über keine Schreibberechtigung für das temporäre Windows-Verzeichnis verfügt

Bei einigen ASP.NET-Kompilierungsaufgaben unter Windows Vista, Windows Server 2008 und Windows 7 tritt möglicherweise ein Fehler auf, da der IIS-Arbeitsprozess über keine Schreibberechtigung für das temporäre Windows-Verzeichnis (%WINDOWS%\Temp) verfügt. Wenn Sie versuchen, bestimmte, von WSDL-Dateien abhängige Elemente zu kompilieren, z. B. Webdienstverweise, werden möglicherweise Fehler angezeigt, z. B. "Parserfehlermeldung: Temporäre Klasse kann nicht generiert werden".
 
Dieser Fehler tritt auf, wenn auf dem Computer IIS aktiviert und .NET Framework 4 installiert ist, aber ASP.NET und die .NET-Erweiterbarkeitsfunktionen nicht aktiviert wurden.

So beheben Sie dieses Problem

Option 1
----------
Erteilen Sie dem Konto des IIS-Arbeitsprozesses explizit Schreibberechtigungen für das temporäre Windows-Verzeichnis (%WINDOWS%\Temp). Dazu können Sie u. a. einer Gruppe Schreibzugriff gewähren, die das Konto des Arbeitsprozesses umfasst, z. B. der Gruppe IIS_IUSRS.
 
Option 2
---------
Aktivieren Sie ASP.NET und die .NET-Erweiterbarkeitsfunktionen. Öffnen Sie in der Windows-Systemsteuerung die Seite Programme", und klicken Sie unter Programme und Funktionen auf Windows-Features aktivieren oder deaktivieren. Öffnen Sie im Dialogfeld Windows-Features den Knoten Internetinformationsdienste, dann WWW-Dienste und dann Anwendungsentwicklungsfeatures. Aktivieren Sie die folgenden Funktionen:

     .NET-Erweiterbarkeit
     ASP.NET

2.3.2.4 Beim Laden vorkompilierter, im GAC bereitgestellter Webassemblys tritt ein Fehler auf und wird die SecurityException-Ausnahme ausgelöst, wenn die Website mit teilweiser Vertrauenswürdigkeit ausgeführt wird

Sie können ASP.NET-Websites mit dem Befehlszeilentool aspnet_compiler.exe vorkompilieren. Wenn Sie die resultierenden Assemblys mit einem Schlüssel signieren, können Sie Assemblys im GAC statt im Ordner Bin der Website bereitstellen.

Wenn in ASP.NET 4 eine mit teilweiser Vertrauenswürdigkeit ausgeführte Website versucht, die Assemblys aus dem GAC zu laden, wird eine System.Security.SecurityException-Ausnahme ausgelöst. Dies ist standardmäßig der Fall, wenn ASP.NET 4 eine neuere CAS-Implementierung (Code Access Security, Codezugriffssicherheit) als frühere Versionen von ASP.NET verwendet. In der neuen CAS-Implementierung müssen vorkompilierte und signierte, im GAC bereitgestellte Assemblys explizit mit dem SecurityTransparent-Attribut markiert werden.

So beheben Sie dieses Problem

Option 1
--------
Markieren Sie die Assembly vor dem Kompilieren mit dem SecurityTransparent-Attribut, wie im folgenden Beispiel gezeigt:

[assembly:System.Security.SecurityTransparentAttribute]

Option 2
--------
Fügen Sie der Web.config-Datei für die Website die Einstellung compilerOptions hinzu, wie im Artikel "Gewusst wie: Erstellen von Assemblys mit Versionsangaben für vorkompilierte Websites" (http://msdn.microsoft.com/de-de/library/ms228042.aspx, maschinell übersetzt) beschrieben. Fügen Sie dabei der Datei AssemblyInfo.vb oder AssemblyInfo.cs, auf die die Einstellung compilerOptions verweist, die folgende Zeile hinzu:

[assembly:System.Security.SecurityTransparentAttribute]

Option 3
--------
Erstellen Sie eine Dummy-Klassenbibliothek, die das folgende Attribut enthält:

[assembly:System.Security.SecurityTransparentAttribute]

Kompilieren Sie die Klassenbibliothek zu einer Assembly, und führen Sie dann das Befehlszeilentool aspnet_merge.exe für die vorkompilierte Websiteausgabe aus, indem Sie, wie im folgenden Beispiel gezeigt, die Option copyattrs verwenden:

aspnet_merge c:\MyApplicationRootDirectory -copyattrs assemblyfile.dll

Verwenden Sie als DLL-Namen den Namen der mit dem SecurityTransparent-Attribut markierten Dummy-Klassenbibliothek.

Option 4
--------
Kehren Sie vorübergehend in den älteren CAS-Modus zurück, indem Sie in der Web.config-Datei für die Website das legacyCasModel-Attribut des trust-Elements, wie im folgenden Beispiel gezeigt, auf true festlegen:

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

Es wird empfohlen, nach dieser Änderung den vorkompilierten Assemblys das SecurityTransparent-Attribut mit einer der anderen Optionen hinzuzufügen. Anschließend können Sie das legacyCasModel-Attribut entfernen und die Website im neuen CAS-Modus ausführen.

2.3.2.5 ASP.NET- und WCF-Anwendungen können möglicherweise nicht im integrierten Modus von IIS 7 gestartet werden

Wenn der Web.config-Anwendungsdatei einer ASP.NET- oder WCF-Anwendung (Windows Communication Foundation) neue Konfigurationsabschnitte hinzugefügt werden, kann eine im integrierten Modus von IIS 7 ausgeführte Anwendung nicht gestartet werden.

Wird der Anwendungsdatei Web.config einer WCF-Anwendung z. B. ein neuer Konfigurationsabschnitt <standardEndpoints> hinzugefügt, kann die Anwendung nicht im integrierten Modus von IIS 7 gestartet werden. Stattdessen gibt IIS 7 einen Konfigurationsvalidierungsfehler aus, da der neue Konfigurationsabschnitt nicht vom IIS 7-Konfigurationssystem erkannt wird.

So beheben Sie dieses Problem

Laden Sie einen öffentlich verfügbaren Hotfix für dieses Problem herunter, und installieren Sie diesen. Der Hotfix ist unter http://support.microsoft.com/kb/958854 verfügbar. Sie können auch Windows Vista SP 2 installieren, das den Hotfix bereits enthält.  Unter Windows 7 und Windows Server 2008 R2 tritt dieses Problem nicht auf, da diese Betriebssysteme den erforderlichen Hotfix bereits enthalten.

2.3.2.6 Unter Windows Vista, Windows Server 2008, Windows 7 und Windows Server 2008 R2 kann eine erneute Registrierung von ASP.NET 4 erforderlich sein

ASP.NET 4 muss erneut registriert werden, wenn IIS 7/7.5 oder die IIS 7/7.5-Funktion .NET-Erweiterbarkeit aktiviert werden, *nachdem* .NET Framework 4 bereits auf dem Computer installiert wurde. ASP.NET 4 muss auch erneut registriert werden, wenn die Funktion .NET-Erweiterbarkeit nach der Installation von .NET Framework 4 auf dem Computer entfernt wird.

In beiden Fällen ist eine erneute Registrierung erforderlich, da der Installations- und Deinstallationsprozess des Betriebssystems für IIS 7 und IIS 7.5 sowie die Funktion .NET-Erweiterbarkeit nicht für das Szenario konzipiert wurde, in dem bereits eine neuere Version von .NET Framework auf dem Computer vorhanden ist.

So beheben Sie dieses Problem

Führen Sie den folgenden Befehl aus, um ASP.NET 4 erneut zu registrieren:

          aspnet_regiis -iru -enable 

Vergewissern Sie sich, dass Sie die Version von aspnet_regiis.exe verwenden, die im Installationsverzeichnis von .NET Framework 4 installiert ist.

2.3.2.7 Die MMC-Registerkarte (Microsoft Management Console) für ASP.NET wird bei der Verwaltung eines Remotewebservers möglicherweise nicht angezeigt

Die ASP.NET-Registerkarte wird beim Verwalten eines Remotewebservers möglicherweise nicht angezeigt, wenn Sie die Verwaltungskonsole (MMC) auf einem lokalen Computer ausführen. Dies ist der Fall, wenn Sie das IIS 6-Verwaltungstool zur Remoteverwaltung eines Webservers verwenden, auf dem ASP.NET installiert ist, und auf dem lokalen Computer Windows Server 2008 x64, Windows 7 oder Windows Server 2008 R2 (x86 oder x64) ausgeführt wird.

So beheben Sie dieses Problem

Dies kann nicht umgangen werden.

2.3.2.8 Durch die Ausführung der ASP.NET 2.0-Version von "aspnet_regiis -ua" werden andere Versionen von ASP.NET (einschließlich ASP.NET 4) nicht deinstalliert

Die Ausführung der ASP.NET 2.0-Version des Befehls aspnet_regiis -ua unter Windows Vista, Windows Server 2008, Windows 7 oder Windows Server 2008 R2 führt zu folgendem Fehler: 

          Die Anforderung wird nicht unterstützt.

Dieser Fehler tritt auf, weil die ASP.NET 2.0-Version des Befehls aspnet_regiis nicht erkennen kann, dass eine neuere ASP.NET-Version auf dem Computer vorhanden ist.

So beheben Sie dieses Problem

Führen Sie die ASP.NET 4-Version des Befehls aspnet_regiis -ua aus, um die Registrierung aller ASP.NET-Versionen auf dem Computer aufzuheben.

2.3.2.9 Durch die Ausführung von "aspnet_regiis -i" unter Windows Server 2003 wird die Aktualisierung virtueller Verzeichnisse auf ASP.NET 4 nicht rekursiv erzwungen

Für ASP.NET 2.0 aktualisiert der Befehl aspnet_regiis -i rekursiv alle virtuellen Verzeichnisse unter Windows Server 2003 zur Verwendung von ASP.NET 2.0. Für ASP.NET 4 aktualisiert der Befehl aspnet_regiis -i unter Windows Server 2003 nur das Stammverzeichnis von IIS 6 auf ASP.NET 4. Falls virtuelle Verzeichnisse unterhalb der Stammebene explizit zur Ausführung einer bestimmten ASP.NET-Version konfiguriert wurden, behalten diese virtuellen Verzeichnisse die explizit festgelegte ASP.NET-Version bei, anstatt die ASP.NET 4-Einstellung der Stammverzeichnisse zu erben.

So beheben Sie dieses Problem

Führen Sie die ASP.NET 4-Version eines der folgenden Befehle aus:

          aspnet_regiis -s

          aspnet_regiis -r

Durch diese Befehle wird eine rekursive Aktualisierung aller virtuellen Verzeichnisse auf ASP.NET 4 erzwungen.

2.3.2.10 Durch das Aufheben der Registrierung von ASP.NET 2.0 werden ASP.NET 4-Leistungsindikatoren beschädigt

Das Aufheben der Registrierung von ASP.NET 2.0 führt unter jedem Betriebssystem, auf dem ASP.NET 4 bereits registriert ist, zur Beschädigung einiger Leistungsindikatorregistrierungen für ASP.NET 4. Dieser Fehler tritt auf, weil der ASP.NET 2.0-Prozess zum Aufheben der Registrierung nicht erkennen kann, dass eine neuere ASP.NET-Version auf dem Computer installiert ist. Daher können bei Verwendung bestimmter ASP.NET 4-Leistungsindikatoren z. B. folgende Fehler im Anwendungsereignisprotokoll angezeigt werden: 

          "Die Open-Prozedur "%pef_counter_name%" in der DLL "%WINDOWS%\Microsoft.NET\Framework\v4.0.NNNNN\aspnet_perf.dll" für den "ASP.NET"-Dienst wurde nicht gefunden."

          "Das Zusammenstellen der Leistungsindikatorendaten vom Dienst "ASP.NET" wurde deaktiviert, da mindestens ein Fehler von der Leistungsindikatorenbibliothek für diesen Dienst verursacht wurde."

So beheben Sie dieses Problem

Führen Sie die ASP.NET 4-Version des Befehls aspnet_regiis -iru aus.  Dadurch werden die ASP.NET 4-Leistungsindikatoren erneut registriert.

2.3.2.11 SQL Server Express-Benutzerinstanzen funktionieren nicht mit Webanwendungsprojekten unter IIS 6 oder IIS 7 oder mit Anwendungen unter IIS 7.5

Von SQL Server Express-Benutzerinstanzen abhängige ASP.NET 4-Webprojekte und -Webanwendungen funktionieren in den folgenden Szenarien standardmäßig nicht:

  1. Ein Webanwendungsprojekt (WAP) wird als virtuelles Verzeichnis in einer IIS-Version gehostet.  Das Problem ist in diesem Fall darauf zurückzuführen, dass SQL Server Express-Benutzerinstanzen bestimmte Dateiberechtigungen für den Ordner Dokumente des Benutzers erfordern und das standardmäßige IIS-Dienstkonto (NETWORK SERVICE) nicht über diese Berechtigungen verfügt.
  2. Eine Website wird in IIS 7.5 unter Windows 7 oder Windows Server 2008 R2 gehostet. Das Problem ist in diesem Fall darauf zurückzuführen, dass die Standard-Sicherheitsanmeldeinformationen für IIS 7.5-Anwendungspools nicht auf NETWORK SERVICE basieren.

So beheben Sie dieses Problem

Details zur Behebung dieser Probleme finden Sie im folgenden Artikel (möglicherweise in englischer Sprache):  

          http://go.microsoft.com/fwlink/?LinkID=160102

2.3.2.12 ASP.NET 4 oder IIS 7 löst Konfigurationsfehler aus, wenn "Web.config"-Dateien auf Anwendungsebene verwandte Abschnitte enthalten

In ASP.NET 4 wurde die standardmäßige Datei Web.config beträchtlich verkleinert. Aus diesem Grund lösen IIS 7 (unter Windows Vista und Windows Server 2008) und IIS 7.5 (unter Windows Server 2008 R2) Konfigurationsfehler aus. Die genauen Fehler hängen von den im Betriebssystem installierten Updates und den in Web.config-Dateien auf Anwendungsebene enthaltenen Konfigurationsinformationen ab.

Windows Vista SP1 oder Windows Server 2008 SP1, wenn weder der Hotfix KB958854 noch SP2 installiert ist. In dieser Konfiguration führt das IIS 7-Konfigurationssystem die verwaltete Konfiguration einer Anwendung fehlerhaft zusammen, indem die Datei Web.config auf Anwendungsebene mit den machine.config-Dateien von ASP.NET 2.0 verglichen wird. Daher müssen die Web.config-Dateien auf Anwendungsebene von .NET Framework 3.5 oder .NET Framework 4 einen Konfigurationsabschnitt <system.web.extensions> enthalten, damit kein IIS 7-Validierungsfehler auftritt.  Manuell geänderte Einträge in der Datei Web.config auf Anwendungsebene, die nicht genau mit den in Visual Studio 2008 eingeführten ursprünglichen Codebausteindefinitionen übereinstimmen, verursachen Konfigurationsfehler. (Die von Visual Studio 2008 generierten Standardkonfigurationseinträge funktionieren.) Ein allgemeines Problem besteht darin, dass die in verschiedenen Konfigurationsabschnittdefinitionen enthaltenen allowDefinition- und requirePermission-Konfigurationsattribute in manuell geänderten Web.config-Dateien nicht vorhanden sind. Daher entsteht ein Konflikt zwischen dem gekürzten Konfigurationsabschnitt in Web.config-Dateien auf Anwendungsebene und der vollständigen Definition in der Datei machine.config von ASP.NET 4. 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, wenn der Hotfix KB958854 installiert ist. In diesem Szenario gibt das systemeigene Konfigurationssystem von IIS 7 und IIS 7.5 einen Konfigurationsfehler zurück, da es einen Textvergleich für das definierte Type-Attribut eines verwalteten Konfigurationsabschnitthandlers ausführt. Da alle von Visual Studio 2008 und Visual Studio 2008 SP1 generierten Web.config-Dateien in der Type-Zeichenfolge für die <system.web.extensions>-Konfigurationsabschnitte (und verwandte Abschnitte) "3.5" enthalten und die Datei machine.config von ASP.NET 4 im Type-Attribut für die gleichen Konfigurationsabschnitte "4.0" enthält, schlägt die Konfigurationsvalidierung der in Visual Studio 2008 oder Visual Studio 2008 SP1 generierten Anwendungen in IIS 7 und IIS 7.5 immer fehl.

So beheben Sie dieses Problem

Aktualisieren Sie für das erste Szenario die Web.config-Datei auf Anwendungsebene, indem Sie den Konfigurationstextbaustein aus einer automatisch von Visual Studio 2008 generierten Web.config-Datei einschließen.

Löschen Sie für das zweite Szenario alle <system.web.extensions>-Konfigurationsabschnittdefinitionen und Konfigurationsabschnitt-Gruppendefinitionen aus der Web.config-Datei auf Anwendungsebene, oder kommentieren Sie sie aus.

2.3.2.13 An die System.Web.Hosting.IProcessHostPreloadClient.Preload-Methode werden keine Parameterdaten übergeben

Die System.Web.Hosting.IProcessHostPreloadClient.Preload-Methode akzeptiert ein Zeichenfolgenarray als Eingabeparameter. Es ist jedoch nicht möglich, diese Daten festzulegen, und es werden niemals Informationen in diesem Parameter übergeben.

So beheben Sie dieses Problem

In früheren Vorschauversionen der Autostart-Funktion von IIS 7.5 bestand die Möglichkeit, Zeichenfolgenwerte für die Übergabe an die IProcessHostPerloadClient.Preload-Methode von ASP.NET 4 zu konfigurieren. Diese Funktion wurde jedoch vor der endgültigen Version von Windows 7 und Windows Server 2008 R2 entfernt.

2.3.2.14 Die IIS 7/IIS 7.5-Funktion ".NET-Erweiterbarkeit" unter Windows Vista, Windows Server 2008, Windows 7 und Windows Server 2008 R2 ist nicht in ASP.NET 4 integriert

Die IIS 7- und IIS 7.5-Funktion .NET-Erweiterbarkeit ist eine Konfigurationsoption, die im Dialogfeld Windows-Funktionen zum Installieren oder Deinstallieren von IIS 7- bzw. IIS 7.5-Funktionen zur Verfügung steht. Die Funktion befindet sich im folgenden Knoten:

Internetinformationsdienste > WWW-Dienste > Anwendungsentwicklungsfeatures > .NET-Erweiterbarkeit 

Unter Windows Vista, Windows Server 2008, Windows 7 und Windows Server 2008 R2 betrifft die Funktion .NET-Erweiterbarkeit nur die ASP.NET 2.0-Integration in IIS 7 oder IIS 7.5. Sie hat keinen Einfluss auf die Registrierung oder Aufhebung der Registrierung von ASP.NET 4 bei IIS 7 bzw. IIS 7.5.

So beheben Sie dieses Problem

Verwenden Sie zum Verwalten der ASP.NET 4-Integration in IIS 7 oder IIS 7.5 die ASP.NET 4-Version des Befehls aspnet_regiis.exe.

2.3.2.15 ASP.NET 2.0-Anwendungen, die unter IIS 6 ausgeführt werden, können zu Fehlern führen, z. B. "System.Web.HttpException: Der Pfad '/[IhrAnwendungsstamm]/eurl.axd/[Wert]' wurde nicht gefunden"

ASP.NET 2.0-Anwendungen, die unter IIS 6 ausgeführt werden (unter Windows Server 2003 oder Windows Server 2003 R2) führen möglicherweise zu Fehlern wie dem folgenden:

System.Web.HttpException: Der Pfad '/[IhrAnwendungsstamm]/eurl.axd/[Wert]' wurde nicht gefunden.

Dieser Fehler tritt nur auf, wenn ASP.NET 4 für IIS 6 aktiviert wurde. Dieser Fehler tritt auf, wenn von ASP.NET erkannt wird, dass eine Website für die Verwendung von ASP.NET 4 konfiguriert ist, eine systemeigene Komponente von ASP.NET 4 erweiterungslose URLs zur weiteren Verarbeitung an den verwalteten Teil von ASP.NET übergibt.

Wenn jedoch virtuelle Verzeichnisse unterhalb einer ASP.NET 4-Website für die Verwendung von ASP.NET 2.0 konfiguriert sind, wird bei einer solchen Verarbeitung der erweiterungslosen URL eine geänderte URL erzeugt, die "eurl.axd" enthält und dann an die ASP.NET 2.0-Anwendung gesendet wird. ASP.NET 2.0 erkennt das Format "eurl.axd" nicht.  Daher versucht ASP.NET 2.0, eine Datei mit dem Namen eurl.axd zu finden und diese auszuführen.  Da keine solche Datei vorhanden ist, tritt bei der Anforderung ein Fehler mit einer HttpException-Ausnahme auf.

So beheben Sie dieses Problem

Option 1
--------
Wenn ASP.NET 4 zum Ausführen der Website nicht erforderlich ist, ordnen Sie die Website stattdessen erneut der Verwendung von ASP.NET 2.0 zu.

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

Option 3
---------
Wenn die Website nicht problemlos ASP.NET 2.0 zugeordnet oder der Speicherort eines virtuellen Verzeichnisses nicht problemlos geändert werden kann, deaktivieren Sie die Verarbeitung erweiterungsloser URLs explizit in ASP.NET 4. 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.<build#>   

 Hinweis: <build#> gibt die Buildnummer der Releaseversion von .NET Framework 4 an.

2. Erstellen Sie den DWORD-Wert EnableExtensionlessUrls.

3. Legen Sie EnableExtensionlessUrls auf 0 fest. Damit deaktivieren Sie das Verhalten für erweiterungslose URLs.

4. Speichern Sie den Registrierungswert, und schließen Sie den Registrierungs-Editor.

5. Führen Sie das Befehlszeilentool "iisreset" aus. Dies führt dazu, dass IIS den neuen Registrierungswert liest.

 Hinweise: Wenn Sie EnableExtensionlessUrls auf 1 festlegen, wir das Verhalten für erweiterungslose URLs aktiviert. Wenn kein Wert angegeben ist, ist dies die Standardeinstellung.

2.3.2.16 Mit Vorabversionen von ASP.NET 4 erstellte Websites, für die Entity Framework verwendet wird, können aufgrund fehlender Assemblyverweise nicht mehr verwendet werden

Verweise auf Namespaces und Assemblys, die für Webprojekte erforderlich sind, für die Entity Framework verwendet wird, wurden aus der RTM-Version der Web.config-Datei des Stammverzeichnisses entfernt. Daher treten bei mit Vorabversionen von ASP.NET 4 erstellten Dynamic Data-Websites, für die EntityDataSource verwendet wird, sowie Webanwendungen, für die Entity Framework verwendet wird, Fehler auf, und Kompilierungsfehler werden gemeldet.

So beheben Sie dieses Problem

Die fehlende Assembly und die fehlenden Namespaceverweise können Sie in die Web.config-Datei der Anwendung einfügen. Das folgende Beispiel zeigt die Assembly und die Namespaceelemente, die manuell in der Web.config-Datei auf Anwendungsebene eingefügt werden müssen.

<system.web>

<compilation>
        <assemblies>
            <add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
            <add assembly="System.Web.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
            <add assembly="System.Data.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
            <add assembly="System.Data.Entity.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />             
        </assemblies>
    </compilation>

    <pages>
        <namespaces>
            <add namespace="System.Data.Entity.Design" />
            <add namespace="System.Data.Linq" />
        </namespaces>
    </pages>

</system.web>

2.3.2.17 Bei Vorabversionen von ASP.NET 4, die im integrierten Modus von IIS 7 oder IIS 7.5 ausgeführt werden, wird möglicherweise ein unbehandelter NullReferenceException-Fehler gemeldet, der von der RoleManagerModule-Klasse ausgelöst wurde

Unter Windows Vista, Windows Server 2008, Windows 7 und Windows Server 2008 R2 lösen ASP.NET 4-Anwendungen bei bestimmten Installationsreihenfolgen für .NET Framework, Version 2.0, und Version 4 in der RoleManagerModule-Klasse einen unbehandelten NullReferenceException-Fehler aus. Dies ist der Fall, wenn ASP.NET 4 die einzige Version von ASP.NET ist, die bei IIS 7 oder IIS 7.5 registriert wurde, und ASP.NET 2.0 nie bei IIS registriert wurde oder die Registrierung von ASP.NET 2.0 bei IIS 7 oder IIS 7.5 aufgehoben wurde.

In beiden Szenarios führt die eigenständige Registrierung von ASP.NET 4 zu einer falschen Reihenfolge in der Konfigurationsdatei für zwei HTTP-Module, die in Anwendungen im integrierten Modus verwendet werden.

So beheben Sie dieses Problem

Zwar wurde dieses Problem in der Releaseversion von ASP.NET 4 behoben, doch ist in den Vorabversionen von ASP.NET 4 möglicherweise eine falsche Reihenfolge der Module angegeben. Wenn die unbehandelte Ausnahme auf einem Computer weiterhin auftritt, auf dem die Vorabversion von ASP.NET 4 auf die RTM-Version aktualisiert wurde, führen Sie die folgenden Schritte aus:

1.  Öffnen Sie die Datei applicationHost.config im folgenden Ordner:

%windir%\System32\inetsrv\config

2. Suchen Sie das folgende Element:

<location path="" overrideMode="Allow">

In diesem Element ist die Liste der HTTP-Module für den integrierten Modus enthalten. Die Informationen befinden sich im <modules>-Element.

3. Suchen Sie das Element, das mit folgender Zeichenfolge beginnt:

<add name="RoleManager"  ...

4. Verschieben Sie das Element unter das Element, das mit der folgenden Zeichenfolge beginnt:

<add name="DefaultAuthentication"...

5. Speichern Sie die Datei.

Wenn Sie den Vorgang abgeschlossen haben, sollte ein Teil der <modules>-Definition dem folgenden Beispiel ähneln:

<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" preCondition="managedHandler" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" preCondition="managedHandler" />

2.3.2.18 MVC 2- und ASP.NET 4-Web Forms-Anwendungen unter IIS 7 und IIS 7.5, für die URL-Routing verwendet wird, geben beim Verarbeiten erweiterungsloser URLs möglicherweise HTTP-Fehler vom Typ 404 zurück

MVC 2 und ASP.NET 4-Web Forms-Anwendungen, für die erweiterungslose URLs verwendet werden, geben möglicherweise HTTP-Fehler vom Typ 404 zurück, wenn sie unter Windows Vista, Windows Server 2008, Windows 7 oder Windows Server 2008 R2 ausgeführt werden. Diese Situation kann auftreten, wenn während der Installation von IIS über das Dialogfeld Windows-Features nur die .NET Framework-Erweiterbarkeitsoption aktiviert ist. In minimalen Installationen von IIS sind bestimmte HTTP-Module nicht enthalten. Aufgrund der Art, in der HTTP-Übergänge zwischen Pipelines und Ereignissen von ASP.NET und IIS behandelt werden, verhindert das Fehlen der HTTP-Module, dass das ASP.NET-URL-Routingmodul zum richtigen Zeitpunkt ausgeführt wird. Anforderungen für erweiterungslose URLs werden daher vom URL-Routingmodul nicht verarbeitet, und ein Fehler vom Typ 404 tritt auf.

So beheben Sie dieses Problem

Führen Sie in der Windows-Systemsteuerung unter Programme und Features
im Dialogfeld Windows-Features aktivieren oder deaktivieren die folgenden Schritte aus:

1. Navigieren Sie zum folgenden Knoten:

Internetinformationsdienste --> WWW-Dienste --> Allgemeine HTTP-Features

2. Stellen Sie sicher, dass die Option HTTP-Fehlerumleitung aktiviert ist.

- oder -

1. Navigieren Sie zum folgenden Knoten:

Internetinformationsdienste --> WWW-Dienste --> Leistungsfeatures

2. Stellen Sie sicher, dass die Option Komprimierung statischer Inhalte aktiviert ist.

Wenn eine der genannten Optionen aktiviert wurde, klicken Sie auf OK, um die Änderungen zu speichern.

Durch erneutes Aktivieren des Moduls HTTP-Fehlerumleitung oder Komprimierung statischer Inhalte stellen Sie sicher, dass HTTP-Pipelineereignisse von ASP.NET und IIS fehlerfrei synchronisiert werden. Dies ermöglicht es dem URL-Routingmodul, erweiterungslose URLs zu verarbeiten.

2.3.2.19 "System.Web.Mobile.dll" wurde aus der "Web.config"-Datei des Stammverzeichnisses entfernt

In früheren Versionen von ASP.NET enthielt die Web.config-Datei des Stammverzeichnisses im <assemblies>-Abschnitt unter <system.web><compilation> einen Verweis auf die Assembly System.Web.Mobile.dll. Zur Verbesserung der Leistung wurde der Verweis auf diese Assembly entfernt.

So beheben Sie dieses Problem

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

2.3.2.20 An Browserdefinitionsdateien und Browserfunktionen wurden Änderungen vorgenommen

Die Browserdefinitionsdateien wurden aktualisiert und enthalten nun Informationen zu den 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 wurden hinzugefügt.

So beheben Sie dieses Problem

Mit ASP.NET 4 können Sie die alten Browserdefinitionsdateien verwenden. Diese sowie die Dokumentation für deren Installation sind in der Release der ASP.NET-Browserdefinitionsdateien unter http://go.microsoft.com/fwlink/?LinkID=186493.

2.3.2.21 ScriptManager.EnableCdn und lokalisierte Microsoft AJAX-Dateien

Die lokalisierten Versionen der Microsoft AJAX JavaScript-Dateien, z. B. MicrosoftAjax.debug.ja.js, werden dem Microsoft AJAX-CDN (Content Delivery Network, Netzwerk für die Inhaltsübermittlung) erst hinzugefügt, wenn die lokalisierten Versionen von .NET Framework 4 veröffentlicht wurden. Aktivieren Sie daher die ScriptManager.EnableCdn-Eigenschaft nicht, wenn Sie eine lokalisierte Version von .NET Framework und des CDN verwenden.

So beheben Sie dieses Problem

Warten Sie mit der Verwendung des Microsoft AJAX-CDN, bis die lokalisierten Versionen von .NET Framework 4 veröffentlicht wurden. Stellen Sie bis dahin sicher, dass für die ScriptManager-Steuerelemente in Ihrer Anwendung nicht EnableCdn="true" festgelegt ist.

2.3.2.22 Generische ASP.NET-Leistungsindikatoren melden nur Daten von ASP.NET 4-Anwendungen

Nach der Installation von ASP.NET 4 melden die generischen ASP.NET-Leistungsindikatoren nur Daten von ASP.NET 4-Anwendungen.  Wenn die generischen Leistungsindikatoren für ASP.NET 1.1-, ASP.NET 2.0- und ASP.NET 3.5-Anwendungen verwendet werden, geben sie keine Daten zurück.  Für Leistungsdaten für Anwendungen, von denen frühere Versionen von ASP.NET ausgeführt werden, müssen die versionsabhängigen ASP.NET-Leistungskategorien verwendet werden.

Die generischen ASP.NET-Leistungsindikatoren umfassen die folgenden Leistungsindikatorenkategorien:  ASP.NET und ASP.NET Applications.

Die Namen der versionsabhängigen ASP.NET-Leistungskategorien ähneln den folgenden: "ASP.NET v2.0.50727" und "ASP.NET Apps v2.0.50727".

So beheben Sie dieses Problem

Dieses Verhalten ist im System vorgesehen.  Die neueste auf einem Computer installierte Version von ASP.NET "besitzt" die Kategorien des generischen Leistungsindikators.  Daher wird empfohlen, beim Erfassen von Leistungsdaten von verschiedenen ASP.NET-Anwendungen, von denen unterschiedliche ASP.NET-Versionen ausgeführt werden, die versionsabhängigen Leistungsindikatorkategorien zu verwenden.

2.3.3 WinForms

Es sind keine Probleme bekannt.

2.3.4 Parallele Programmierung

Es sind keine Probleme bekannt.

2.3.5 Managed Extensibility Framework

Es sind keine Probleme bekannt.

2.3.6 Entity Framework

Es sind keine Probleme bekannt.

2.3.7 LINQ to SQL

Es sind keine Probleme bekannt.

2.3.8. Windows Communication Foundation (WCF)

2.3.8.1 Beim Starten eines Diensts oder Zurücksetzen von IIS nach dem Upgrade des Clientprofils tritt der Fehler "Die angegebene Datei kann nicht gefunden werden" auf

Wenn Sie .NET Framework 4 von Beta 2 auf die RTM-Version aktualisiert haben, tritt beim Starten eines Diensts oder erneuten Starten von IIS möglicherweise der folgende Fehler auf:

"Die angegebene Datei kann nicht gefunden werden."

So beheben Sie dieses Problem

Reparieren Sie .NET Framework Client Profile in der Anwendung Programme der Systemsteuerung.

2.3.9 Windows Presentation Foundation (WPF)

2.3.9.1 Windows Presentation Foundation (WPF) wird auf ia64-Systemen nicht unterstützt

WPF-Assemblies werden auf ia64-Computern nicht installiert und unterstützt.

So beheben Sie dieses Problem

Dies kann nicht umgangen werden. WPF kann nicht auf ia64-Systemen verwendet werden.

2.3.10 Windows Workflow Foundation (WF)

2.3.10.1 Der sizeof-Operator wird von der Workflowvalidierung nicht unterstützt

Wenn ein Workflow validiert wird, der den sizeof-Operator enthält, wird eine Ausnahme ausgelöst.

So beheben Sie dieses Problem

Verwenden Sie den sizeof-Operator nicht in Workflows.

2.3.11 Client Profile (Produkt)

2.3.11.1 .NET Framework 4 Client Profile wird auf ia64-Systemen nicht unterstützt

.NET Framework 4 Client Profile wird auf ia64-Systemen nicht unterstützt.

So beheben Sie dieses Problem

Wenn Sie .NET Framework 4 auf einem ia64-System deinstallieren, müssen Sie sowohl die vollständige Version als auch die Client Profile-Version deinstallieren.

3. Weitere Links

              * Jeroen Frijters

 

© 2010 Microsoft Corporation. Alle Rechte vorbehalten.

Nutzungsbedingungen  | Marken  | Datenschutzbestimmungen