.NET Remoting und Funktionsüberladung

Question

Hi,

ein Remoting-Objekt verfügt über überladene Funktionen, z.B.

ArrayList Get();

ArrayList Get(int i);

ArrayList Get(int i, string a);

Beim Aufruf von einer dieser Methoden aus einem anderen Prozess wird eine Exception geworfen mit der Fehlerbeschreibung:

"Das Objekt mit dem Typ "System.Type[]" kann nicht in den Typ "System.Int32" konvertiert werden."

Bei Funktionen, für welche es keine Überladungen gibt, tritt das Problem nicht auf.

Handelt es sich hierbei um ein generelles .NET Remoting Problem oder gibt es bei der Verwendung von Funktionsüberladung bei Remoting-Objekten noch etwas besonderes zu beachten?

Viele Grüße

Christian

Answer 1

Hallo Christian

bei dieser Art Exception tippe ich auf ein 'Ungleichgewicht' (Versionsunterschiede) der Metadata,
also zB des gemeinsamen Assembly oder Proxy das du zwischen Server und Client-Projekt teilst.

Andernfalls bitte vollständige Details zur Exception, inkl Stack.

Answer 2

Christian, Nachtrag:

dieselbe Problematik beträfe im Prinzip auch die Objekt-Typen, welche im ArrayList abgefüllt werden.
 => Teste mal kurz wenn Server nur 'leere' ArrayList zurückgibt.

Answer 3

Hallo Christian,

kann mit mehreren auch ganz simplen Dingen zusammen hängen ... ist noch etwas wenig Code, um das zu beurteilen.
Ein paar Möglichkeiten:

[objekt with typ can not be converted Remoting - Google-Suche]

In der ArrayList sind ansonsten auch immer bestimmte Typen.
Diese müssen aber letztlich bei der Übertragung "in der Leitung" serialisiert werden und man kann dies nicht immer mit allen Typen machen.


[Serialization/Deserialization between two apps.]
http://www.netframeworkdev.com/net-remoting-runtime-serialization/serializationdeserialization-between-two-apps-43904.shtml

Achte ggf. insbesondere auch auf das XmlInclude und Serializable Attribut.

BTW: ab .NET 4.0 würde ich auf jeden Fall eher zu WCF als .NET Remoting raten (bei 3.0 noch nicht unbedingt).

---

ciao Frank

Answer 4

Hallo Christian,

Mir sieht das sehr nach einem einfachen, serverseitigen System.InvalidCastException-Fehler aus. Wahrscheinlich soll die ArrayList serverseitig anhand der Parameter (int i, string a) gefiltert werden. Beim Filtern wird vermutlich eine cast/Konvertierung gemacht und da man von System.Type nicht zu Int32 konvertieren kann, wird eine Ausnahme geworfen.

Zeig uns doch mal bitte den Code von Get(int i).

BTW: Ab .NET 3.0 nimmt man für Neuentwicklungen, die prozessübergreifendes Remoting benötigen, gewöhnlich WCF. Remoting fristet nur noch ein Nischendasein beim Remoten zwischen verschiedenen AppDomains desselben Prozesses.

Gruß
Marcel

Answer 5

Hi Thomas,

vielen Dank für Deine Hilfe!

Ich habe die Info an den Kollegen gegeben, der sich gerade mit dem Problem befasst.

Viele Grüße

Christian

Answer 6

Hi Frank,

vielen Dank für Deine Hilfe!

Ich habe auch Deine Infos an den Kollegen gegeben. Wir prüfen es.

Viele Grüße

Christian

Answer 7

Hi Marcel,

vielen Dank für Deine Hilfe!

Wahrscheinlich soll die ArrayList serverseitig anhand der Parameter (int i, string a) gefiltert werden. Beim Filtern wird vermutlich eine cast/Konvertierung gemacht und da man von System.Type nicht zu Int32 konvertieren kann, wird eine Ausnahme geworfen.

Das Problem tritt nur auf, wenn der Remote-Aufruf über Rechnergrenzen geschieht. Das Problem tritt nicht auf, wenn der Aufruf auf einem Rechner, d.h. innerhalb eines Prozesses ausgeführt wird.

Viele Grüße

Christian

Answer 8

Das Problem tritt nur auf, wenn der Remote-Aufruf über Rechnergrenzen geschieht. Das Problem tritt nicht auf, wenn der Aufruf auf einem Rechner, d.h. innerhalb eines Prozesses ausgeführt wird.

Christian,
zur Sicherheit   (aber sehe ich kaum als Ursache):

welche Remoting Channel und Formatter werden denn eingesetzt?

Answer 9

Hallo Christian,
Hallo Thomas

Christian schrieb:

Das Problem tritt nur auf, wenn der Remote-Aufruf über Rechnergrenzen geschieht. Das Problem tritt nicht auf, wenn der Aufruf auf einem Rechner, d.h. innerhalb eines Prozesses ausgeführt wird.

Ohne Code und/oder StackTrace, stochern wir im Dunkeln.

Es könnte:

- ein Serialisierungs-/Deserialisierungsproblem sein, es könnte auch
- einfach nur die falsche Version/Codebasis der [Server].dll sein an die clientseitig gebunden wird, oder
- die falsche Assembly für die verwendete Interface (wenn auf Interface gecastet wird)
- usw.

Mir fehlen halt relevante Anhaltspunkte.

Gruß
Marcel

Answer 10

Ohne Code und/oder StackTrace, stochern wir im Dunkeln.

Marcel - klar,
wobei eines kann man wohl schon jetzt feststellen:
ein "generelles .NET Remoting Problem" gibt es mit so überladenen Funktionen nicht, entsprechender Code läuft hier von Anfang an fehlerfrei.

Answer 11

Hi Thomas,

es wird der Soap Formatter verwendet. Beim Remoting Channel kommt eine eigene Implementierung von IServerChannelSinkProvider zum Einsatz.

Viele Grüße

Christian

Answer 12

Hallo Marcel,

Hallo Thomas,

mit dem Beispiel-Code tue ich mir ein bischen schwer. Es geht um die Implementierung unseres eigenen Frameworks. Es wurde inzwischen "gelöst", indem die Funktionen umbenannt wurden. Nicht sehr schön.

Viele Grüße

Christian

Answer 13

Hallo Christian,

mit dem Beispiel-Code tue ich mir ein bischen schwer. Es geht um die Implementierung unseres eigenen Frameworks. Es wurde inzwischen "gelöst", indem die Funktionen umbenannt wurden. Nicht sehr schön.

Dass Du denn Code nicht veröffentlichen willst, kann ich gut verstehen. Aber ein StackTrace wäre doch angebracht, zumal zukünftige Besucher - die eventuell ein ähnliches Problem haben - mehr von dieser Diskussion haben könnten.

Gruß
Marcel

Answer 14

Hi Marcel,

anbei der StackTrace:

Das Objekt mit dem Typ "System.Type[]" kann nicht in den Typ "System.Int32" konvertiert werden.
Server stack trace:

    bei System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo culture, BindingFlags invokeAttr)
    bei System.Reflection.RtFieldInfo.InternalSetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, CultureInfo culture, Boolean doVisibilityCheck, Boolean doCheckConsistency)
    bei System.Reflection.RrFieldInfo.InternalSetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, CultureInfo culture, Boolean doVisibilityCheck)
    bei System.Runtime.Serialization.FormatterServices.SerializationSetValue(MemberInfo fi, Object target, Object value)
    bei System.Runtime.Serialization.FormatterServices.PopulateObjectMembers(Object obj, MemberInfo[] members, Object[] data)
    bei System.Runtime.Serialization.Soap.ReadObjectInfo.PopulateObjectMembers()
    bei System.Runtime.Serialization.Soap.ObjectReader.ParseObjectEnd(ParseRecord pr)
    bei System.Runtime.Serialization.Soap.ObjectReader.ParseMemberEnd(ParseRecord pr)
    bei System.Runtime.Serialization.Soap.ObjectReader.Parse(ParseRecord pr)
    bei System.Runtime.Serialization.Soap.SoapHandler.EndElement(String prefix, String name, String urn)
    bei System.Runtime.Serialization.Soap.SoapParser.ParseXml()
    bei System.Runtime.Serialization.Soap.SoapParser.Run()
    bei System.Runtime.Serialization.Soap.ObjectReader.Deserialize(HeaderHandler handler, ISerParser serParser)
    bei System.Runtime.Serialization.Soap.SoapFormatter.Deserialize(Stream serializationStream, HeaderHandler handler)
    bei System.Runtime.Remoting.Channels.CoreChannel.DeserializeSoapResponseMessage(Stream inputStream, IMessage requestMsg, Header[] h, Boolean bStringBinding)
    bei System.Runtime.Remoting.Channels.SoapClientFormatterSink.DeserializeMessage(IMethodCallMessage mcm, ITransportHeaders headers, Stream stream)
    bei System.Runtime.Remoting.Channels.SoapClientFormatterSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]:
    bei System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
    bei System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

Gruß

Christian