Bereitstellen einer Common Language Runtime-Anwendung mit Internet Explorer

Artikel
09/02/2008

Aktualisiert: November 2007

Webbasierte Anwendungen können Microsoft Internet Explorer 5.5 oder höhere Versionen zum Herunterladen und Ausführen von Assemblys verwenden. Eine webbasierte Anwendung kann die beiden standardmäßigen PE (Portable Executable)-Dateitypen (.exe bzw. .dll) herunterladen. In einem HTML-Dokument kann angegeben sein, welche Assemblys heruntergeladen werden sollen und wie die Speicherorte dieser Assemblys sowie der Speicherort der Konfigurationsdatei lauten, in der zusätzliche Informationen zur Verfügung stehen.

Wenn eine Anwendung mit Internet Explorer bereitgestellt wird, hat dies den Vorteil, dass Assemblys nur bei ihrer Verwendung heruntergeladen werden. Wenn sich die Anwendung aus mehreren Assemblys zusammensetzt, werden diese nur heruntergeladen, wenn auf sie verwiesen wird. Dieser automatische Prozess gewährleistet den schnelleren anfänglichen Download einer Anwendung, da nicht die gesamte Anwendung gedownloaded wird und der Client lediglich den von ihm verwendeten Code empfängt.

Hinweis:
Über das Internet bereitgestellter Code verfügt i. d. R. über die Standardberechtigungen für das Internet, die in den Sicherheitsrichtlinien festgelegt wurden. Über diese Berechtigungen kann lediglich eine begrenzte Anzahl an Funktionen durch Code ausgeführt werden. Weitere Informationen über die Standardsicherheitsrichtlinien für das Internet finden Sie unter Sicherheitsrichtlinie.

Einstellungen für webbasierte Anwendungen

Durch Common Language Runtime wird standardmäßig eine Anwendungsdomäne für jede Site erstellt, auf die mit Internet Explorer zugegriffen wird. Anwendungsdomänen isolieren separate Anwendungen, die innerhalb eines Prozesses ausgeführt werden. Das Verfahren zur Erstellung von Anwendungsdomänen hat Auswirkungen auf die Berechtigungen der Assemblys, die in der Domäne ausgeführt werden. Jeder Anwendungsdomäne sind URL-Beweise und eine Anwendungsbasis zugeordnet, sowie optional eine Konfigurationsdatei.

URL-Beweise

URL-Beweise werden Anwendungen zugeordnet, die mit Microsoft Internet Explorer 5.5 oder höher bereitgestellt wurden. Mithilfe dieser URL-Beweise trifft der Laufzeithost Entscheidungen auf Grundlage der Sicherheitsrichtlinien. Obwohl die URL-Beweise sowohl den Assemblys zugeordnet sind, aus denen die Anwendung besteht, als auch der Anwendungsdomäne, die von der Anwendung erstellt wird, unterscheidet sich das Format der Beweise jeweils. Bei einer Assembly besteht der URL-Beweis aus dem vollständigen URL-Pfad zur Hauptassemblydatei. Bei einer Assembly, die Teil einer Anwendung ist, könnte der URL-Beweis z. B. http://www.code.microsoft.com/myApp/myAssembly.dll lauten. Der URL-Beweis für die Anwendungsdomäne entspricht demjenigen für die Site. Der URL-Beweis für die Anwendungsdomäne im vorherigen Beispiel wäre http://www.code.microsoft.com/.

Hinweis:
Der Speicherort für die Konfigurationsdatei der Anwendung wirkt sich nicht auf den URL-Beweis für die Anwendungsdomäne aus.

Konfigurationsdateien

Mithilfe von Internet Explorer bereitgestellte Webanwendungen können die in einer Anwendungskonfigurationsdatei gespeicherten Informationen verwenden. Die Konfigurationsdatei der Anwendung muss sich auf dem Webserver in demselben Verzeichnis wie die ausführbare Datei der Anwendung befinden. Die Anwendungskonfigurationsdatei muss die für Anwendungskonfigurationsdateien geltenden Namenskonventionen einhalten. Der Name der Datei muss mit dem der ausführbaren Datei übereinstimmen, an die die Erweiterung .config angehängt wurde. Die Anwendungskonfigurationsdatei für die Anwendung myApplication.exe wäre daher myApplication.exe.config.

ASP.NET-Anwendungen legen Informationen für die Konfiguration fest und verwenden dazu eine Web.config-Datei. Wie in ASP.NET und in einem ausführbaren Host können auch in Webanwendungen Konfigurationsinformationen zur Verfügung stehen. Wenn eine von Internet Explorer gehostete Anwendung über eine Konfigurationsdatei verfügt, wird der Speicherort der Konfigurationsdatei in einem <link>-Tag mit folgender Syntax angegeben:

<LINK REL="CONFIGURATION" HREF="[configuration file name]"></LINK>

In diesem Beispiel ist [configuration file name] der Name der Konfigurationsdatei, z. B.:

<LINK REL="CONFIGURATION" HREF="two.dll.config"></LINK>

In einfachen Webanwendungsszenarien, in denen in der Webseite kein auf die Konfigurationsdatei verweisender <link>-Tag angegeben ist, wird durch die Common Language Runtime für jede Site eine Anwendungsdomäne erstellt. Wenn sich das HTML-Dokument beispielsweise auf http://www.code.microsoft.com/myApp/mypage.htm befindet, wird die Anwendungsdomäne für die gesamte Site http://www.code.microsoft.com erstellt. Beachten Sie, dass sich so zwar bequem Webdokumente erstellen lassen, dabei aber alle Webseiten, die Assemblys mit verwaltetem Code in dieser Website verwenden, über eine gemeinsame Anwendungsdomäne verfügen, da keine Konfigurationsdatei festgelegt wurde.

Wenn die Anwendung Informationen aus einer Anwendungskonfigurationsdatei liest, müssen Sie die folgenden Schritte ausführen:

Legen Sie die Konfigurationsdatei an demselben Speicherort ab wie die ausführbare Datei.
Gewähren Sie den anonymen Zugriff auf die Website sowie die Ausführung von Skripts im Verzeichnis mit der Konfigurationsdatei.

In einem komplexeren Szenario müssen möglicherweise zwei oder mehr unterschiedliche Anwendungen in einer Website isoliert voneinander ausführbar sein. Um die Isolierung zu gewährleisten, muss beim Verfassen der Webseite eine Konfigurationsdatei im HTML-Dokument angegeben werden. Alle Seiten, die auf dieselbe Konfigurationsdatei zeigen, werden in derselben Anwendungsdomäne erstellt. Auf diese Weise ist es möglich, eine Anwendungsdomäne für jede Konfigurationsdatei zu erstellen.

Hinweis:
Die Common Language Runtime unterstützt nicht das Zeichen '#' in URLs, die auf eine Konfigurationsdatei verweisen, wenn das <link>-Tag einen relativen Pfad enthält.

Anwendungsbasis

ApplicationBase ist eine Eigenschaft der Anwendungsdomäne, die das Verzeichnis festlegt, das als Stammverzeichnis angegeben wird, wenn die Common Language Runtime nach Assemblys sucht. Die ApplicationBase-Eigenschaft wird standardmäßig als Stammverzeichnis der Site (z. B. wwwroot) betrachtet. Wenn eine Anwendungskonfigurationsdatei vorhanden ist, wird die ApplicationBase zum Speicherort der Konfigurationsdatei. Die Konfigurationsdatei kann spezifische Konfigurationsinformationen für den Code enthalten, der in der Anwendungsdomäne ausgeführt wird. Wenn auf einem Computer mehrere Sites definiert sind, ruft die ApplicationBase standardmäßig die auf Anschluss 80 festgelegte "Standard"-Site auf.

Herunterladen von verwalteten ausführbaren Dateien

Während es sich bei den meisten mithilfe des <object>-Tags heruntergeladenen Anwendungen um Steuerelemente für Benutzeroberflächen handelt, die auf der Webseite angezeigt werden, unterstützt die Common Language Runtime auch zwei weitere Möglichkeiten zum Herunterladen von verwalteten ausführbaren Dateien:

Ein Benutzer gibt den URL einer verwalteten .exe-Datei in den Browser ein. Ein Beispiel:
```
http://www.server.microsoft.com/MyWebSite/MyApp.exe.
```
Eine HTML-Seite enthält einen Link zu einer verwalteten ausführbaren Datei, beispielsweise:
```
HREF="MyApp.exe".
```

In beiden Szenarien wird von der Common Language Runtime eine neue Anwendungsdomäne erstellt, in der die ausführbare Datei ausgeführt werden soll. In nachfolgenden Anforderungen nach Assemblys wird die Anwendungsbasis auf den Speicherort der ausführbaren Datei festgelegt.

Zum Beispiel verweist der folgende Code auf myClass:

<object id="myCtl" 
  classid="http://www.mycode.Microsoft.com/mycode.dll#myClass"> 
</object>

Abhängige, statisch miteinander verknüpfte Assemblys müssen sich im selben Verzeichnis wie die aufrufende Assembly befinden, wenn diese mit einem <object>-Tag angegeben wird. Wenn beispielsweise die Assembly myAssembly.dll mit einem <object>-Tag angegeben ist und einen statischen Verweis auf myOtherAssembly.dll verwendet, muss sich myOtherAssembly.dll in demselben Verzeichnis wie myAssembly.dll befinden.

Hinweis:
Ausführbare Dateien mit verwaltetem Code, die von Internet Explorer mit einer HREF-Verknüpfung bereitgestellt wurden, sollten nicht mit Befehlszeilenargumenten gestartet werden. Argumente werden nicht erfolgreich an die ausführbare Datei übergeben.

Fehlerberichte

Der Prozess des Herunterladens von Code verwendet die folgenden beiden Registrierungseinstellungen, um Fehlerberichte von verwalteten, ausführbaren Codedateien, die mithilfe von Internet Explorer bereitgestellt werden, zu steuern.

HKLM\Software\Microsoft\.NETFramework\ExposeExceptionsInCOM
HKCU\Software\Microsoft\.NETFramework\ExposeExceptionsInCOM

Beide Einstellungen verwenden die folgenden Werte, um anzugeben, wie Fehler gemeldet werden.

Wert	Beschreibung
1	Fehlerinformationen werden an den Standardausgabestream gesendet.
2	Fehlerinformationen werden dem Benutzer angezeigt.
3	Fehlerinformationen werden sowohl an den Standardausgabestream gesendet als auch dem Benutzer angezeigt.

Beim Debuggen von verwaltetem Code, der mit Internet Explorer bereitgestellt wird, können Sie die Werte dieser Einstellungen dazu verwenden, detaillierte Informationen über fehlgeschlagenes Herunterladen von Code zu erhalten. Dies erlaubt Ihnen z. B., die Stapelüberwachungsinformationen anzuzeigen, wenn Ausnahmen ausgelöst werden, und Sie sind nicht allein auf die Fehlerberichte angewiesen, die Internet Explorer bereitstellt; denn diese sind lediglich für Endbenutzer gedacht und nicht für Entwickler.

Von Internet Explorer gehostete Steuerelemente

Internet Explorer kann als Host von Steuerelementen verwendet werden, die mit .NET Framework erstellt wurden. Steuerelemente müssen in einer Bibliothek mit einer .dll-Erweiterung enthalten sein. Um ein Windows Form-Steuerelement sowohl eigenständig als auch mit Internet Explorer als Host zu verwenden, muss die Bibliothek für die ordnungsgemäße Ausführung in beiden Fällen eine .dll-Erweiterung aufweisen.

Wichtiger Hinweis:
Sämtliche von Internet Explorer gehosteten verwalteten Steuerelemente verwenden die aktuelle Version der auf dem Computer installierten Common Language Runtime. Dies bedeutet, dass das Steuerelement in einigen Instanzen möglicherweise nicht unter der Version ausgeführt werden kann, in der es erstellt wurde und dass es u. U. nicht unter der ursprünglich beabsichtigen Sicherheitsrichtlinie angewendet wird. Vor dem Ausführen eines verwalteten Steuerelements unter einer neuen Version der Common Language Runtime muss die Sicherheitsrichtlinie für die neue Laufzeitversion aktualisiert werden. Dies gilt für alle Sicherheitszonen, jedoch nicht für verwaltete ausführbare Dateien, die heruntergeladen wurden.

Sämtliche von Internet Explorer gehosteten verwalteten Steuerelemente verwenden die aktuelle Version der auf dem Computer installierten Common Language Runtime. Dies bedeutet, dass das Steuerelement in einigen Instanzen möglicherweise nicht unter der Version ausgeführt werden kann, in der es erstellt wurde und dass es u. U. nicht unter der ursprünglich beabsichtigen Sicherheitsrichtlinie angewendet wird. Vor dem Ausführen eines verwalteten Steuerelements unter einer neuen Version der Common Language Runtime muss die Sicherheitsrichtlinie für die neue Laufzeitversion aktualisiert werden. Dies gilt für alle Sicherheitszonen, jedoch nicht für verwaltete ausführbare Dateien, die heruntergeladen wurden.

Hinweis:
Beim Laden eines verwalteten Steuerelements beträgt die maximale Länge des Werts für das classid-Attribut des <object>-Elements 256 Zeichen (MAX_PATH). Überschreitet die Länge diesen Maximalwert, wird das Steuerelement nicht geladen, und es wird keine Fehlermeldung generiert. Beispielsweise stellt der folgende classid-Attributwert eine akzeptable Länge dar: <object id="myCtl" classid="http://www.example.com/mycode.dll#myClass">

Beim Laden eines verwalteten Steuerelements beträgt die maximale Länge des Werts für das classid-Attribut des <object>-Elements 256 Zeichen (MAX_PATH). Überschreitet die Länge diesen Maximalwert, wird das Steuerelement nicht geladen, und es wird keine Fehlermeldung generiert. Beispielsweise stellt der folgende classid-Attributwert eine akzeptable Länge dar:

Hinweis:
Aus Sicherheitsgründen werden verwaltete Steuerelemente, die das <object>-Tag und das Dateizugriffsprotokoll auf einer HTML-Seite verwenden, nicht unterstützt. Das folgende <object>-Tag wird beispielsweise nicht unterstützt: <OBJECT classid="file:///c:/control.dll#control">

Aus Sicherheitsgründen werden verwaltete Steuerelemente, die das <object>-Tag und das Dateizugriffsprotokoll auf einer HTML-Seite verwenden, nicht unterstützt. Das folgende <object>-Tag wird beispielsweise nicht unterstützt:

Suchen nach abhängigen Assemblys

Das von der Common Language Runtime zum Suchen nach abhängigen Assemblys für webbasierte Anwendungen verwendete Verfahren ist demjenigen ähnlich, das im Kontext nicht webbasierter Anwendungen verwendet wird. Die Common Language Runtime sucht nach privaten, abhängigen Assemblys und verwendet dazu einen Pfad, der auf die ApplicationBase bezogen ist. Dabei kommt eine Kombination aus der ApplicationBase, dem <private_binpath>-Tag in einer Konfigurationsdatei und den Regeln zur Suche nach privaten Assemblys zur Anwendung. Außerdem wird der URL, an dem sich die aufrufende Assembly befindet, nach abhängigen Assemblys überprüft.

Signieren von verwaltetem Code mit einer Microsoft Authenticode-Signatur

Mit dem File Signing-Tool (Signcode.exe) können Sie eine Datei mit einer digitalen Authenticode-Signatur versehen. Beachten Sie beim Signieren einer Datei mit einem starken Namen und einer digitalen Authenticode-Signatur, dass Sie den starken Namen zuerst zuweisen müssen. Wenn Sie die Authenticode-Signatur zuerst zuweisen, wird der starke Name beschädigt. Weitere Informationen über das Signieren von Dateien finden Sie unter Überlegungen zur Assembly-Sicherheit. Informationen über Dateisignierung mit Visual Studio 2005 finden Sie in "Bereitstellung und Authenticode-Signatur" in der Visual Studio 2005-Dokumentation. Weitere Informationen zur Authenticode-Signaturtechnologie finden Sie unter "Introduction to Code Signing" in der Platform SDK-Dokumentation (nur auf Englisch verfügbar).