Archived
This forum has been archived. Please start a new discussion on GitHub.
Expected type and received type error message indicate same type.
The attached image shows an exception from the server indicating that the expected and received types don't match.
The names are identical and I've double checked the server and client code; they both reference the exact same generated Ice class.
This implementation is an update to an original one that was working; the update included some method signature changes and introduction of additional type definitions in the .ice files.
I believe the error occurs in an Ice module before ever reaching the generated code. As such, it's not possible to debug through and examine the data being passed.
I would be interested in any ideas or ways in which I can verify what the type mismatch issue is or perhaps ideas on what to check for in the type definitions that may be in error.
The names are identical and I've double checked the server and client code; they both reference the exact same generated Ice class.
This implementation is an update to an original one that was working; the update included some method signature changes and introduction of additional type definitions in the .ice files.
I believe the error occurs in an Ice module before ever reaching the generated code. As such, it's not possible to debug through and examine the data being passed.
I would be interested in any ideas or ways in which I can verify what the type mismatch issue is or perhaps ideas on what to check for in the type definitions that may be in error.
0
Comments
-
Things tried to narrow scope issue.
Tried the following:- Replace complex type with primitive in .ice file that defines the server interface. Update implementation using the generated Ice code. Result: call via proxy successful.
- Rename complex type in case of naming collision with other types in implementation. Result: call fails with same 'mismatch' message.
- Remove ALL generated code and corresponding binaries (.dll) in case an old version was being accessed. Result: call fails with same 'mismatch' message.
- Remove all types defined in .ice file and update with a single 'class' with a single 'string' property. Update implementation using the generated Ice code. Result: call fails with same 'mismatch' message.
Basically, fails if any non-primitive types defined in the server interface methods in the .ice file.0 - Replace complex type with primitive in .ice file that defines the server interface. Update implementation using the generated Ice code. Result: call via proxy successful.
-
Hi Rick,
You didn't specify which Ice version or language(s) you're using, but I'm guessing it's Ice 3.5.1 for .NET?
This situation typically occurs when the same class is loaded via multiple assemblies. To be more specific, your generated server-side code has a reference to the Contracts.TargetStatus type that originated from one assembly. However, while unmarshaling the TargetStatus object, the Ice run time attempts to dynamically locate the type associated with this object and apparently finds it in a different assembly. Finally, the generated server-side code tries to verify that the unmarshaled object is actually an instance of the type it expects, and this test fails because .NET considers them to be different.
Are you installing an object factory for the type Contracts.TargetStatus? This would only be necessary if the type is abstract (declares operations), but it could also be a factor in this issue.
The quickest way to resolve this would be for you to provide a simple project that we could use to reproduce the problem. Let us know if you're still having trouble.
Regards,
Mark0 -
Hi Mark:
You assume correctly: Ice 3.5.1 and .NET (C#).
We are dynamically loading at runtime (via reflection) the Ice server and client implementations. I will try referencing and loading directly (without use of reflection) and see if that helps. Your suggestions were helpful in triggering thoughts regarding how the implementation is being loaded.
Rick0 -
Resolution.
Hi Mark:
Your suggestions (specifically with respect to the duplicate assembly load) led me to try the server and agent components without the dynamic load implementation and it resolved the object type mismatch issue.
Guess I'll have to either try to determine how have both statically and dynamically loaded classes the same Ice generated binary or come up with a generic static load that gives me the flexibility of a dynamic load.
Thnx for your help.
Rick0
