Versionsinformationen in Remoting
Dieses Thema bezieht sich auf eine veraltete Technologie, die zum Zwecke der Abwärtskompatibilität mit vorhandenen Anwendungen beibehalten wird und nicht für die neue Entwicklung empfohlen wird. Verteilte Anwendungen sollten jetzt mit Windows Communication Foundation (WCF) entwickelt werden.
Remoting wurde für die Arbeit mit Assemblys mit starkem Namen entworfen. Wenn starke Namen in Verbindung mit Remoting verwendet werden, gelten die folgenden Basisregeln:
Versionen werden immer mit der TypeName-Eigenschaft einer IMethodCallMessage-Schnittstellenimplementierung eingeschlossen.
Versionen werden immer mit der ActivationTypeName-Eigenschaft einer IConstructionCallMessage-Schnittstellenimplementierung eingeschlossen.
Versionen werden immer mit der in ObjRef-Objekten gespeicherten TypeInfo-Eigenschaft eingeschlossen.
Die restliche Versionsverwaltung in Remoting wird durch die includeVersions-Eigenschaft des verwendeten Formatierungsprogramms bestimmt. Standardmäßig generiert das BinaryFormatter-Objekt Versionsinformationen, das SoapFormatter-Objekt jedoch nicht. Diese Eigenschaft kann beim Erstellen eines Channels programmgesteuert geändert oder über die Remotekonfigurationsdatei festgelegt werden.
In diesem Abschnitt wird beschrieben, wie sich diese Regeln auf die Objektverweise und die verschiedenen Aktivierungsmodelle auswirken, die beim Remoting häufig verwendet werden.
Vom Server aktivierte Objekte
Der Server steuert, welche Version eines Typs aktiviert wird, wenn ein Client eine Verbindung mit einem vom Server aktivierten Objekt (oder <wellknown>-Objekt) herstellt. Wenn bei der Konfiguration des Dienstes keine Versionsinformationen bereitgestellt werden, wird beim Aktivieren des Objekts die neueste Version verwendet. Wenn Sie z. B. über zwei Assemblys, MyHello, Version 1.0.0.0, und MyHello, Version 2.0.0.0, verfügen, wird das bekannte Objekt mit Version 2.0 der Assembly aktiviert, falls keine Versionsinformationen bereitgestellt werden. Beachten Sie unbedingt, dass diese Version unabhängig von der Version verwendet wird, auf die bei der Clienterstellung verwiesen wurde.
Der Dienst kann so konfiguriert werden, dass er eine bestimmte Version einer Assembly verwendet. Die folgende Konfigurationsdatei veranschaulicht z. B. die Angabe einer Version. Wenn sich eine Assembly im globalen Assemblycache befindet, müssen alle Typinformationen, einschließlich Kulturinformationen und öffentlicher Schlüssel, angegeben werden. In den folgenden Konfigurationsbeispielen werden die Informationen zu starken Namen weggelassen, damit Sie sich auf die Versionsverwaltung konzentrieren können.
<configuration>
<system.runtime.remoting>
<application name="RemotingHello">
<lifetime
leaseTime="20ms"
sponsorshipTimeOut="20ms"
renewOnCallTime="20ms"
/>
<service>
<wellknown
mode="SingleCall"
type="Hello.HelloService,MyHello,Version=1.0.0.0,<strong name omitted>"
objectUri="HelloService.soap"
/>
<activated
type="Hello.AddService, MyHello"
/>
</service>
<channels>
<channel
port="8000"
ref="tcp"
>
</channel>
</channels>
</application>
</system.runtime.remoting>
</configuration>
Diese Datei gibt an, dass Version 1.0.0.0 der MyHello-Assembly verwendet werden soll, um Objekte für ihre Clients zu erstellen. Wenn am Endpunkt mehrere Versionen eines Objekts angegeben sind, wird beim Aktivieren des Objekts die zuletzt angegeben Version verwendet. Beachten Sie unbedingt, dass wichtige Änderungen zwischen den Versionen eines Objekts negative Auswirkungen auf Clients haben können. Wenn ein Methodenparameter zwischen Versionen hinzugefügt oder geändert wird, lösen Clients, die mit der Version 1.0 kompiliert wurden, eine Ausnahme aus, wenn sie mit Version 2.0 verwendet werden. Daher wird empfohlen, dass eine neue Version eines Objekts an einem anderen Endpunkt gehostet wird, wenn zwischen Versionen signifikante Änderungen vorgenommen wurden.
Vom Client aktivierte Objekte
Wenn ein Client ein vom Client aktiviertes Objekt (d. h. ein <activated>-Objekt) aktiviert, wird ein Netzwerkaufruf an den Server gesendet. Dort wird das angeforderte Objekt aktiviert, und ein Objektverweis auf das Objekt wird an den Client zurückgegeben. Weil der Client die Aktivierung des Objekts anweist, wählt er auch die Version des zu aktivierenden Objekts. So wird z. B. HelloService, Version 1.0, auf dem Server aktiviert, wenn der Client für Version 1.0 des Objekts erstellt wurde, und HelloService, Version 2.0, wird auf dem Server aktiviert, wenn der Client für Version 2.0 erstellt wurde.
Beachten Sie unbedingt, dass Sie die Versionsnummer für von Clients aktivierte Typen nicht angeben können, wenn Sie den Dienst konfigurieren. Außerdem haben Versionsinformationen, die für vom Servern aktivierte Typen bereitgestellt wurden, keine Auswirkungen auf vom Client aktivierte Objekte, selbst wenn sich beide Typen in derselben Assembly befinden.
Ein clientaktivierter Typ und ein serveraktivierter Typ befinden sich z. B. in der gleichen Assembly, und Sie erstellen client1 mit Version 1.0 und client2 mit Version 2.0. Wenn keine Versionsinformationen für das serveraktivierte Objekt angegeben werden, empfängt client1 Version 2.0 des serveraktivierten Objekts und Version 1.0 des clientaktivierten Objekts. Client2 empfängt sowohl für bekannte als auch für aktivierte Typen Objekte der Version 2.0.
Wenn Sie den Dienst so konfigurieren, dass Version 1.0 der Assembly für das bekannte Objekt verwendet wird, empfangen beide Clients Version 1.0 des bekannten Objekts, während client1 Version 1.0 des aktivierten Typs und client2 Version 2.0 des aktivierten Typs empfängt.
Die für einen Client aktivierte Version kann nicht konfiguriert werden. Es wird immer die Version verwendet, für die der Client erstellt wurde.
Objektverweise
Die Regeln, die für vom Server aktivierte und vom Client aktivierte Typen gelten, gelten auch für Objektverweise. Wenn beispielsweise ein Proxy für einen vom Client aktivierten Typ als Parameter von einem Client an einen anderen Client oder von einem Client an den Server übergeben wird, werden die in den Objektverweis eingebetteten Versionsinformationen mit übergeben. Wenn der Empfänger versucht, eine Methode für den aus dem Objektverweis generierten Proxy aufzurufen, hat die in den Objektverweis eingebettete Version Vorrang vor der Version, für die der Client erstellt wurde. Bei vom Server aktivierten Objekten gibt der Server die verwendete Version vor. Alle Clients, die einen Objektverweis als Parameter empfangen, kommunizieren mit der Version, die bei der Konfiguration des Servers angegeben wurde. Wenn keine Versionsinformationen vorhanden sind, wird die neueste Version auf dem Server aktiviert.
Als Wert gemarshallte Objekte
Wenn ein als Wert gemarshalltes Objekt (Marshal-By-Value-Objekt, MBV-Objekt) zwischen Anwendungsdomänen übergeben wird, bestimmt das verwendete Formatierungsprogramm, ob Versionsinformationen eingeschlossen werden. BinaryFormatter-Objekte schließen die Version immer ein, während SoapFormatter-Objekte Versionsinformationen ignorieren. Diese Option kann für beide Formatierungsprogramme aktiviert oder deaktiviert werden. Wenn der Konfigurationsdatei zum Beispiel die folgende Zeile hinzugefügt wird, fügt SoapFormatter beim Serialisieren eines Objekts Versionsinformationen hinzu.
<formatter ref="soap" includeVersions="true" />
Siehe auch
Konzepte
Konfiguration von Remoteanwendungen
Clientaktivierung
Serveraktivierung