That "3HyOSdeZ" is because you need a concrete type, not an interface. WCF accepts interfaces, but it turns them into implementations by making a dyanmic proxy (ie runtime generated class for your type. So for example the following is possible
Services.Get<IService>().Call(x => x.helloWorld());
What that would do because your UI wouldn't know about any IService implementation is that it creates a dynamic proxy for IService and puts WCF routing into the impelementation of IService. Each method will do the same behavior, ie serialize and route across a network to some protocoll like soap.
Your runtime heirachy looks like this:
IService <---------- IServices9df87sdf987
What IService might look like is:
interface IService{
void HelloWorld();
}
What your IServices9df87sdf987 might look like:
public IServices9df87sdf987 : IService{
public void HelloWorld(){
return SerializeAndRouteCallToWCF();
}
}
The method I created there called: SerializeAndRouteCallToWCF() is purely abitary to demonstrate what the implementation generated by a proxy object pattern could look like at runtime. Understanding this concept in WCF is quite the gotcha, it adds behavior to your application, where if you understand it, its not such a mystery, but when you don't know. it generates random rubbush and can cause strange behavior. An example of this was where I was once struggling to understand what was happening to my proxy objects when I passed them through a WCF boundary. (WCF was unwrapping them).
Hope this shines a new light on the situation.
On Sat, Dec 17, 2011 at 9:21 AM, RScanlon
<[hidden email]> wrote:
I too am having a very similar issue.
The only real difference is that we use actual Dictionaries instead of
IDictionary.
I believe the issue stems from having a custom or complex type as either the
key or value in your dictionary.
I have tested it sending a string for the key and an int for the value and
it works fine.
I have also used fiddler to examine the difference in the SOAP between the
XML that mono sends and the xml that .NET or Silverlight sends. What I have
found is that .NET and Silverlight appends what appears to be a seemingly
random set of characters onto the end of the type name. But in truth it must
not be random because through different projects and compiles the string
remains consistent. I have also noticed that it changes depending on what
namespace your custom class is in. So it must be some form of digest of a
namespace. Without this, the WCF server is unable to deserialize the
dictionary properly.
Below is an example of the dictionary in XML created by mono and then the
XML created by .NET.
This is in a namespace called Joe and is a dictionary keyed by string with a
value of type SimpleTest.
Mono:
<d4p1:NewDict
xmlns:d5p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
<d5p1:KeyValueOfstringSimpleTest>
<d5p1:Key>TestKey1</d5p1:Key>
<d5p1:Value>
<int1
xmlns="http://schemas.datacontract.org/2004/07/Origin.BLL.Joe">1</int1>
<string1
xmlns="http://schemas.datacontract.org/2004/07/Origin.BLL.Joe">Test1</string1
</d5p1:Value>
</d5p1:KeyValueOfstringSimpleTest>
</d4p1:NewDict>
.NET
<d4p1:NewDict
xmlns:d5p1="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
<d5p1:KeyValueOfstringSimpleTest3HyOSdeZ>
<d5p1:Key>TestKey1</d5p1:Key>
<d5p1:Value
xmlns:d7p1="http://schemas.datacontract.org/2004/07/Origin.BLL.Joe">
<d7p1:int1>1</d7p1:int1>
<d7p1:string1>Test1</d7p1:string1>
</d5p1:Value>
</d5p1:KeyValueOfstringSimpleTest3HyOSdeZ>
</d4p1:NewDict>
Notice how .NET appends "3HyOSdeZ" on the end of SimpleTest.
Where you able to come up with a solution to your issue?
--
View this message in context: http://mono-for-android.1047100.n5.nabble.com/Can-not-send-IDictionary-to-WCF-tp4908854p5081325.html
Sent from the Mono for Android mailing list archive at Nabble.com.
_______________________________________________
Monodroid mailing list
[hidden email]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
_______________________________________________
Monodroid mailing list
[hidden email]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
Locked
