Parallele Ausführung von .NET Framework

Veröffentlicht: 18. Feb 2003 | Aktualisiert: 23. Jun 2004
Von Dennis Angeline

Auf dieser Seite

Terminologie Terminologie
Weitere Informationen Weitere Informationen
Die richtige Entscheidung bei der Konfiguration von Anwendungen Die richtige Entscheidung bei der Konfiguration von Anwendungen
Konfigurieren von Windows-Clientanwendungen Konfigurieren von Windows-Clientanwendungen
Konfigurieren von nicht verwalteten Anwendungen Konfigurieren von nicht verwalteten Anwendungen
Konfigurieren von Webanwendungen Konfigurieren von Webanwendungen
Zusätzliche Informationen Zusätzliche Informationen

Terminologie

Eine 1.0-Anwendung ist auf Version 1.0 von .NET Framework ausgerichtet. Alle mit Visual Studio .NET 2002 erstellten Anwendungen sind 1.0-Anwendungen.

Eine 1.1-Anwendung ist auf Version 1.1 von .NET Framework ausgerichtet. Alle mit Visual Studio .NET 2003 erstellten Anwendungen sind 1.1-Anwendungen.

Weitere Informationen

Die in .NET Framework integrierte Unterstützung für parallele Ausführung ermöglicht es, mehrere Framework-Versionen auf einem System zu installieren. Bei Version 1.1 von .NET Framework müssen Anwendungs- und Komponentenentwickler berücksichtigen, wie ihr Code auf Systemen arbeitet, auf denen mehrere Framework-Versionen installiert sind.

Die Framework-Version 1.1 ist voll kompatibel mit Version 1.0. Microsoft hat umfassende Schritte unternommen, um sicherzustellen, dass die große Mehrheit der auf Framework 1.0 erstellten Anwendungen auch auf Framework 1.1 funktionieren. Dazu gehört auch eine umfassendere Kompatibilität, die sich nicht nur auf die öffentlichen Typen und APIs beschränkt. Wir führen z.B. eine genaue Überwachung der Änderungen an API-Implementierungen durch, die sich auch auf die Kompatibilität auswirken können. Eine API, die einen Wert zurückgibt, der von seinem Vorgänger nicht zurückgegeben wurde, würde somit nach wie vor als inkompatibel gelten.

Es wurden zwar alle möglichen Anstrengungen unternommen, um die Kompatibilität zu erhalten, doch ist es für das Entwicklungsteam in gewissen Fällen erforderlich, die Kompatibilität aufzuheben. Dies wird nur in den schwersten Fällen und nach einer gründlichen Analyse der Auswirkungen der Änderung getan. Inkompatibilitätsänderungen stellen in der Regel nur eine letzte Möglichkeit zur Behebung von sicherheitsbezogenen Problemen oder ernsthaften Fehlern in der vorhandenen Funktionalität dar. Inkompatibilitätsänderungen werden nicht vorgenommen, um die Konsistenz oder das Erscheinungsbild einer API zu ändern oder Probleme zu lösen, die mit anderen angemessenen Mitteln behoben werden können. Wenn die Kompatibilität beeinträchtigt wird, stellt Microsoft eine öffentliche Dokumentation der Änderungen und potenzielle Workarounds bereit. Die vollständige Liste der Inkompatibilitätsänderungen für die Framework-Version 1.1 finden Sie unter http://www.gotdotnet.com/team/changeinfo/Backwards1.0to1.1/default.aspx (in Englisch).

Trotz des hohen Maßes an Kompatibilität zwischen Framework 1.0 und 1.1 werden die meisten Anwendungen, die Framework 1.0 verwenden, bei der Installation von Framework 1.1 nicht automatisch aktualisiert. In der Tat hat die Installation der neueren Versionen von .NET Framework auf die meisten vorhandenen Anwendungstypen keinerlei Auswirkungen. Framework 1.1 kann auf einem System installiert oder deinstalliert werden, ohne dass Anwendungen, die Framework 1.0 verwenden, dadurch beeinträchtigt werden. Gleichermaßen werden auch Anwendungen, die mit der Framework-Version 1.1 erstellt wurden, nicht beeinflusst, wenn die ältere Version von Framework installiert wird.

Anmerkung:
Das Deinstallieren einer älteren Version von Framework kann sich auf vorhandene Anwendungen auswirken, die von dieser Version abhängen und mit der neuen Version nicht vollständig kompatibel sind.

Das parallele Ausführen gibt Anwendungsentwicklern und Systemadministratoren die Möglichkeit, vorhandene Anwendungen ggf. für die Verwendung der neueren Version von Framework zu konfigurieren. Unserer Ansicht nach kann die Entscheidung, welche Framework-Version für die jeweilige Anwendung verwendet werden sollte, nur von Anwendungsentwicklern oder Systemadministratoren getroffen werden. Mit anderen Worten: Echte Kompatibilität kann nur im Kontext einer bestimmten Anwendung überprüft werden.

Daher können Anwendungen mit der neuen Version von Framework getestet und für die Verwendung der neuen Version konfiguriert werden, wenn der Anwendungsentwickler oder Systemadministrator dies aufgrund des Testergebnisses als angemessen erachtet. Aufgrund des hohen Maßes an Kompatibilität zwischen den beiden Versionen gehen wir davon aus, dass die große Mehrheit der 1.0-Anwendungen mit Framework 1.0 oder 1.1 gleichermaßen gut arbeiten. In dem seltenen Fall, dass die Anwendung auf Framework 1.1 nicht funktioniert, kann sie so konfiguriert werden, dass sie nur Framework 1.0 unterstützt. Anwendungsentwickler sollten ihre Anwendungen daher mit Framework 1.1 testen und ggf. für 1.0, 1.1 oder beide Versionen konfigurieren.

Wir gehen zwar davon aus, dass 1.0-Anwendungen in Framework 1.1 ausgeführt werden können, das Ausführen von 1.1-Anwendungen in Framework 1.0 ist jedoch wesentlich schwieriger. Damit dies funktioniert, muss der Entwickler einige Überlegungen im Voraus anstellen, um die Verwendung neuer Funktionalitäten zu vermeiden, die in Framework 1.0 nicht verfügbar sind. Anwendungen mit Features, die nur in Framework 1.1 vorhanden sind, funktionieren in Framework 1.0 einfach nicht. Eine Liste dieser Features finden Sie unter http://www.gotdotnet.com/team/changeinfo/Forwards1.0to1.1/default.aspx (in Englisch).

Die richtige Entscheidung bei der Konfiguration von Anwendungen

Die Methode, die zum Konfigurieren einer Anwendung erforderlich ist, hängt vom Typ der zu erstellenden Anwendung ab. Herkömmliche Windows™-Clientanwendungen (Windows Forms, Konsolenanwendungen und Windows-Dienste) werden mit einer Anwendungskonfigurationsdatei konfiguriert. Webanwendungen (ASP.NET und XML Web Services) werden über den Internet Information Services-Administrator (IIS-Administrator) konfiguriert.

Konfigurieren von Windows-Clientanwendungen

Ein Anwendungsentwickler oder Administrator kann 1.0-Windows-Clientanwendungen durch Bereitstellung einer Anwendungskonfigurationsdatei testen oder permanent an Framework 1.1 umleiten. Die Anwendungskonfigurationsdatei kann die Common Language Runtime (CLR) anweisen, eine bestimmte Version von .NET Framework in den Anwendungsprozess zu laden. Die Framework-Version, die zur Laufzeit geladen wird, kann sich von der Version unterscheiden, mit der die Anwendung eigentlich kompiliert wurde.

Die Anwendungskonfigurationsdatei ist eine XML-Datei, die sich in demselben Verzeichnis wie die ausführbare Datei (EXE) für die Anwendung befindet. Der Name der Konfigurationsdatei muss dem der EXE-Datei entsprechen, wobei allerdings die Endung .config angehängt wird. Die Konfigurationsdatei der Anwendung MyApp.exe würde z.B. MyApp.exe.config heißen. Beachten Sie, dass die Konfigurationsdatei Einstellungen enthalten kann, die sich nicht nur auf die Framework-Version, auf der sie ausgeführt werden sollte, auswirken können, sondern auch auf andere Aspekte des Anwendungsverhaltens.

Die Framework-Version wird vom Inhalt des Startabschnitts in der Konfigurationsdatei beeinflusst. Insbesondere das supportedRuntime-Element wirkt sich auf die Auswahl der Framework-Version aus. Der Startabschnitt kann ein oder mehrere supportedRuntime-Elemente enthalten. Jedes Element gibt eine Framework-Version an, die die Anwendung unterstützt. Die supportedRuntime-Elemente werden nach Präferenzen sortiert. Mit anderen Worten: Die am meisten bevorzugte Version von Framework wird an erster Stelle aufgelistet. Bei einer Anwendung, die sowohl Framework 1.0 als auch Framework 1.1 unterstützt, die Verwendung von Framework 1.1 jedoch vorzieht, würde z.B. Folgendes im Startabschnitt der Anwendungskonfigurationsdatei stehen:

<configuration> 
… 
<startup> 
   <supportedRuntime version="v1.1.4322" /> 
   <supportedRuntime version="v1.0.3705" />    
</startup> 
… 
</configuration>

Die im supportedRuntime-Element angegebene Versionsnummer muss mit dem Unterverzeichnis übereinstimmen, in dem Framework installiert ist. Wenn die 1.0-Version von Framework z.B. im Verzeichnis C:\Windows\Microsoft.Net\Framework\v1.0.3705 installiert wird, muss die in der Konfigurationsdatei angegebene Versionsnummer "v1.0.3705" lauten. In gleicher Weise wird Framework 1.1 im Verzeichnis C:\Windows\Microsoft.Net\Framework\v1.1.4322 installiert. In der unterstützten Laufzeitversionsnummer dürfen keine Platzhalter verwendet werden. Daher kann eine Anwendung nicht für die Unterstützung einer Version von Framework konfiguriert werden, die noch nicht veröffentlicht wurde.

Anmerkung:
Für neuere Versionen von Framework, die für Beta-Tests veröffentlicht werden, werden Versionsnummern zur Verfügung gestellt.

Die CLR bestimmt, welche Version von Framework geladen werden soll, wobei sie zum einen die Versionen zugrunde legt, die in der CONFIG-Datei der Anwendung aufgelistet sind und zum anderen die Versionen, die auf dem System verfügbar sind, unter dem die Anwendung ausgeführt wird. Konfigurierte Anwendungen können nur unter den in der supportedRuntime-Liste enthaltenen Framework-Versionen ausgeführt werden. Die Konfiguration kann vor und nach der Weitergabe der Anwendung jederzeit geändert werden. Gehen Sie beim Ändern der Konfigurationsdatei mit Bedacht vor, da sich die in der Datei enthaltene Einstellung auf andere Aspekte des Anwendungsverhaltens auswirken kann.

Nicht konfigurierte Windows-Clientanwendungen

Anwendungen, die keine Konfigurationsdatei enthalten oder deren Konfigurationsdatei kein supportedRuntime-Element aufweist (nicht konfigurierte Anwendungen), können mit der Version von Framework ausgeführt werden, die zum Erstellen der Anwendung verwendet wurde, sofern diese Version auf dem lokalen System installiert ist. (Die Framework-Version, mit der die Anwendung erstellt wurde, ist im Header der EXE-Datei der Anwendung enthalten.) Wenn diese Framework-Version nicht verfügbar ist, verwendet die CLR stattdessen eine neuere Version von Framework. Mit anderen Worten: Eine nicht konfigurierte Anwendung, die mit Framework 1.0 erstellt wurde, kann mit 1.0 auf einem System ausgeführt werden, auf dem sowohl 1.0 als auch 1.1 installiert sind. Dieselbe Anwendung kann mit Framework 1.1 auf einem System ausgeführt werden, auf dem lediglich Framework 1.1 installiert ist. Anwendungen sollten unbedingt für die Unterstützung aller als kompatibel geltenden Versionen von Framework konfiguriert werden, um Szenarios zu ermöglichen, in denen nur eine bestimmte Version auf dem Zielcomputer verfügbar ist. Beachten Sie, dass eine Anwendung auch durch Neuverteilung der erforderlichen Version von .NET Framework für solche Situationen vorsorgen kann, wie unter Redistributing the .NET Framework (in Englisch) erläutert wird.

Keine geeignete Version verfügbar

Wenn keine geeignete Framework-Version zum Ausführen einer Anwendung gefunden wird, zeigt die CLR ein Dialogfeld an. In diesem Dialogfeld sind die von der Anwendung unterstützten Framework-Versionen aufgelistet und fordern den Benutzer auf, eine dieser Versionen zu installieren. Sie können dieses Dialogfeld unterdrücken, indem Sie den Schlüssel NoGuiFromShim in der Registrierung setzen:

HKLM\\Software\\Microsoft\\.NETFramework\\NoGuiFromShim = 1

Konfigurieren von nicht verwalteten Anwendungen

Viele nicht verwaltete Windows-Clientanwendungen (Windows-Clientanwendungen, die nicht mit .NET Framework, sondern mit einem anderen Programmiermodell erstellt wurden) verwenden die Dienste von verwalteten Komponenten (Komponenten, die mit .NET Framework erstellt wurden) über COM Interop. Das Hosten einer verwalteten Komponente auf einer Webseite, die mit Internet Explorer angezeigt wird, ist ein perfektes Beispiel für eine nicht verwaltete Anwendung (Internet Explorer), die die Dienste einer verwalteten Komponente in Anspruch nimmt. Ein weiteres Beispiel sind verwaltete Windows-Clientanwendungen, die über berührungslose Weitergabe mit Internet Explorer an den Desktop weitergegeben werden.

Die nicht verwalteten Hostanwendungen können alle für die Verwendung einer bestimmten Framework-Version für ihre verwalteten Komponenten konfiguriert werden. Wenn die Komponenten von einer nicht verwalteten Anwendung geladen werden, wird die verwaltete Komponente standardmäßig zusammen mit der neuesten verfügbaren Version von Framework in den Anwendungsprozess geladen. Dieses Verhalten unterscheidet sich erheblich von dem Verhalten der zuvor beschriebenen verwalteten Windows-Clientanwendungen. Im Gegensatz zu einer voll verwalteten Anwendung fehlen nicht verwalteten EXE-Dateien die Headerinformationen, die die Framework-Version beschreiben, mit der der betreffende Code erstellt wurde. Dadurch bleibt der CLR keine andere Wahl, als die neueste verfügbare Version von Framework zu laden.

Wenn eine Komponente jedoch eine ganz bestimmte Version von Framework benötigt, kann für die nicht verwaltete EXE-Datei (z.B. Internet Explorer), die die Komponente hostet, eine Konfigurationsdatei wie die zuvor beschriebene bereitgestellt werden. Beachten Sie, dass die Konfigurationsdatei für die EXE-Datei vorhanden sein muss, die die Komponente hostet, nicht für die verwaltete Komponente selbst. Letztendlich bedeutet dies, dass alle verwalteten Komponenten, die von einer bestimmten nicht verwalteten Anwendung aufgerufen werden, auf derselben Framework-Version ausgeführt werden können - entweder auf der neuesten verfügbaren Version oder aber der Version, die in der CONFIG-Datei der Anwendung angegeben ist. Diese Konfigurationsdateien können mit Hilfe des zuvor gezeigten XML-Beispiels von Grund auf erstellt werden. Die CONFIG-Datei sollte in derselben Weise benannt werden: [Name der EXE-Datei der nicht verw. Anw.] .exe.config (z.B. iexplore.exe.config).

Konfigurieren von Webanwendungen

Webserver können für die Verwendung verschiedener Versionen von .NET Framework für einzelne, mit .NET Framework erstellte Websites konfiguriert werden (das heißt die ASP.NET-Bibliotheken). Sämtlicher Code, der innerhalb einer bestimmten Site ausgeführt wird, verwendet die Version, die für die Site oder den Server (falls für die Site keine Version angegeben ist) angegeben ist.

Anstatt die Framework-Version anhand von Konfigurationsdateien auszuwählen, wird die Konfiguration für die einzelnen Sites innerhalb der IIS-Verwaltungskonsole durch Auswahl der jeweiligen Versionen des ASP.NET ISAPI-Filters festgelegt. Der ASP.NET-Filter wird im Dialogfeld für Websiteeigenschaften auf der Registerkarte ISAPI-Filter gesetzt. Der Filter kann für jede Site individuell gesetzt werden. Sie können ihn auch für den gesamten Webserver setzen, indem Sie den Filter für die Stammwebsite ändern. Der ASP.NET-Filter ist in der Datei aspnet_filter.dll implementiert. Der 1.0-Filter befindet sich im Verzeichnis %windir%\Microsoft.Net\Frameworks\v1.0.3705. Der 1.1-Filter befindet sich im Verzeichnis %windir%\Microsoft.Net\Frameworks\v1.1.4322.

Die Installation der Framework-Version 1.1 fügt der Filterliste auf der Stammwebsite des Webservers den 1.1-ASP.NET-Filter automatisch hinzu. Das Aktualisieren des Filters auf Stammebene führt dazu, dass alle nicht separat konfigurierten Sites mit der Version 1.1 von Framework starten. Jede Site, für die Framework 1.0 auch weiterhin erforderlich ist, muss separat für die Verwendung des 1.0-ISAPI-Filters konfiguriert werden. Die Konfiguration des ISAPI-Filters kann nur auf Websiteebene vorgenommen werden. Einzelne VRoots können nicht für die Verwendung eines anderen ISAPI-Filters konfiguriert werden.

Zusätzliche Informationen

Weitere Beispiele für die Parallelkonfiguration finden Sie unter http://www.gotdotnet.com/team/changeinfo/default.aspx (in Englisch).


Anzeigen: