Versionsinformationen beim Remoting
Remoting wurde für die Arbeit mit Assemblys mit starken Namen entwickelt. Wenn beim Remoting starke Namen verwendet werden, gelten die folgenden Grundregeln:
Versionen sind immer in der TypeName-Eigenschaft einer IMethodCallMessage-Schnittstellenimplementierung enthalten.
Versionen sind immer in der ActivationTypeName-Eigenschaft einer IConstructionCallMessage-Schnittstellenimplementierung enthalten.
Versionen sind immer in der in ObjRef-Objekten gespeicherten TypeInfo-Eigenschaft enthalten.
Jede weitere Versionsverwaltung beim 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 bei der Erstellung eines Channels programmgesteuert geändert oder mithilfe der Remotekonfigurationsdatei festgelegt werden.
In diesem Abschnitt wird beschrieben, wie diese Regeln sich auf Objektverweise und die verschiedenen, beim Remoting gängigen Aktivierungsmodelle auswirken.
Serveraktivierte Objekte
Der Server steuert, welche Version eines Typs aktiviert wird, wenn ein Client eine Verbindung mit einem serveraktivierten Objekt (bzw. <wellknown>-Objekt) herstellt. Wenn bei der Konfiguration des Dienstes keine Versionsinformationen bereitgestellt werden, wird bei Aktivierung des Objekts die neueste Version der Assembly verwendet. Wenn z. B. zwei Assemblys vorhanden sind, nämlich MyHello, Version 1.0.0.0, und MyHello, Version 2.0.0.0, wird das bekannte Objekt unter Verwendung der Assembly mit Version 2 aktiviert, wenn keine Versionsinformationen angegeben werden. Beachten Sie hierbei, dass diese Version unabhängig von der Version verwendet wird, auf die bei Erstellung des Clients verwiesen wurde.
Der Dienst kann aber auch für die Verwendung einer bestimmten Version einer Assembly konfiguriert werden. In der folgenden Konfigurationsdatei wird beispielhaft das Angeben einer Version aufgezeigt. Beachten Sie, dass Sie sämtliche Typinformationen angeben müssen, einschließlich der Kulturinformationen und des öffentlichen Schlüssels, wenn sich eine Assembly im globalen Assemblycache befindet. In den folgenden Konfigurationsbeispielen wurden die Informationen zu starken Namen weggelassen, um besonderes Augenmerk auf die Versionsinformationen zu lenken.
<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>
In dieser Datei wird angegeben, dass Version 1.0.0.0 der MyHello-Assembly zum Erstellen von Objekten für die Clients verwendet werden soll. Wenn am Endpunkt mehrere Versionen desselben Objekts angegeben werden, wird bei Aktivierung des Objekts die zuletzt angegebene Version verwendet. Bedenken Sie stets, dass bedeutende Änderungen zwischen verschiedenen Versionen desselben Objekts sich nachteilig auf Clients auswirken können. Wird z. B. von einer Version zur nächsten ein Methodenparameter hinzugefügt oder geändert, lösen mit Version 1 kompilierte Clients bei Verwendung mit Version 2 eine Ausnahme aus. Daher empfiehlt es sich, eine neue Version eines Objekts an einem anderen Endpunkt zu hosten, wenn zwischen den Versionen erhebliche Änderungen vorgenommen wurden.
Clientaktivierte Objekte
Wenn ein Client ein clientaktiviertes Objekt (d. h. ein <activated>-Objekt) aktiviert, wird sofort ein Netzwerkaufruf an den Server gesendet, wo das angeforderte Objekt aktiviert. Dann wird ein Objektverweis an den Client zurückgegeben. Da der Client die Aktivierung des Objekts steuert, wählt er auch die Version des zu aktivierenden Objekts aus. So wird z. B. Version 1 von HelloService auf dem Server aktiviert, wenn der Client mit Version 1 des Objekts erstellt wurde. Wurde der Client hingegen mit Version 2 von HelloService erstellt, wird diese Version auf dem Server aktiviert.
Beachten Sie unbedingt, dass Sie bei Konfiguration des Dienstes keine Versionsnummer für clientaktivierte Typen angeben können. Des Weiteren hat die Bereitstellung von Versionsinformationen für serveraktivierte Typen keinerlei Auswirkungen auf clientaktivierte Objekte, selbst wenn beide Typen in derselben Assembly enthalten sind.
Angenommen, in derselben Assembly sind ein clientaktivierter Typ und ein serveraktivierter Typ enthalten, und Sie erstellen Client1 mit Version 1 und Client2 mit Version 2. Wenn nun keine Versionsinformationen für das serveraktivierte Objekt festgelegt werden, erhält Client1 Version 2 des serveraktivierten Objekts und Version 1 des clientaktivierten Objekts. Client2 erhält sowohl für bekannte als auch für aktivierte Typen Objekte der Version 2.
Wenn Sie den Dienst so konfigurieren, dass für das bekannte Objekt Version 1 der Assembly verwendet wird, erhalten beide Clients Version 1 des bekannten Objekts, während Client1 Version 1 des aktivierten Typs und Client2 Version 2 des aktivierten Typs erhält.
Welche Version für einen Client aktiviert wird, lässt sich nicht konfigurieren. Es wird immer die Version verwendet, mit der der Client erstellt wurde.
Objektverweise
Für Objektverweise gelten dieselben Regeln wie für server- und clientaktivierte Typen. Wenn z. B. ein Proxy für einen clientaktivierten Typ als Parameter von einem Client an einen anderen oder von einem Client an den Server übergeben wird, werden die in den Objektverweis eingebetteten Versionsinformationen mit übergeben. Versucht der Empfänger, eine Methode für den von dem Objektverweis generierten Proxy aufzurufen, hat die in den Objektverweis eingebettete Version Vorrang vor der Version, mit der der Client erstellt wurde. Im Falle serveraktivierter Objekte gibt der Server die zu verwendende Version vor, und alle Clients, die einen Objektverweis als Parameter erhalten, kommunizieren mit der Version, die bei der Konfiguration des Dienstes festgelegt wurde. Wenn keine Versionsverwaltung erfolgt, wird auf dem Server die neueste Version aktiviert.
MBV-Objekte
Wenn zwischen Anwendungsdomänen ein MBV-Objekt (Marshal-by-Value) übergeben wird, bestimmt das verwendete Formatierungsprogramm, ob Versionsinformationen enthalten sind. BinaryFormatter-Objekte schließen die Version stets ein, während SoapFormatter-Objekte Versionsinformationen ignorieren. Diese Option kann für beide Formatierungsprogramme aktiviert bzw. deaktiviert werden. Wenn z. B. der Konfigurationsdatei die folgende Zeile hinzugefügt wird, fügt SoapFormatter bei der Serialisierung eines Objekts Versionsinformationen hinzu.
<formatter ref="soap" includeVersions="true" />
Siehe auch
Konzepte
Konfiguration von Remoteanwendungen
Clientaktivierung
Serveraktivierung