Probleme bei Metadaten

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.

Die .NET-Remoteinfrastruktur benötigt die richtigen Metadaten, um ein Objekt in einer Anwendungsdomäne mit einem Objekt in einer anderen Anwendungsdomäne zu verbinden. In allen Fällen muss die Clientanwendungsdomäne über die Metadaten des Remoteobjekts verfügen, das verwendet werden soll. Folgende wichtige Punkte müssen beachtet werden:

• Bei vom Server aktivierten Objekten muss der Assemblyname, der den Typ enthält, auf dem Client und dem Server identisch sein. Der Typname muss ebenfalls identisch sein. Dies liegt daran, dass die Typidentität über die Kombination aus dem Typ- und dem Assemblynamen, einschließlich der Assemblyversion und der Informationen zu starken Namen, bestimmt wird.

• Bei vom Client aktivierten Objekten muss der Assemblyname, der den Typ enthält, auf dem Client und dem Server identisch sein. Der Typname muss ebenfalls identisch sein. Außerdem muss der Client über eine tatsächliche Implementierung des Remotetyps verfügen, und alle Member müssen genau dieselbe Signatur wie die entsprechenden Member der Serverimplementierung haben.

Hinweis:

Die Clientimplementierung muss nicht die Serverimplementierung sein. Wenn der Client keinen Zugriff auf die Serverimplementierung haben soll, können Sie eine Ersatzbibliothek erstellen, die die oben genannten Anforderungen erfüllt, aber Stub-out-Members enthält, die eine NotSupportedException-Ausnahme auslösen. Das Soapsuds-Tool (Soapsuds.exe) macht dies für Clients mithilfe der SOAP-Serialisierung. Dies ist für alle veröffentlichten Marshal-by-Reference-Typen mit jedem Channel möglich.

Siehe auch

Konzepte

Verwenden von Soapsuds.exe beim Remoting