Quantcast

Can not send IDictionary to WCF

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Can not send IDictionary to WCF

Nirban Dutta

Hi,

 

We have a Filter class with a DataMember of IDictionary type.

 

public class Filter

    {

        [DataMember]

        public IDictionary<CriterionType, string> CriterionList { get; set;}

        [DataMember]

        public IDictionary<string, string> UserFieldList { get; set; }

        ......

    }

 

 

When we call the WCF from android, we get 0 items in the dictionary,  is it not serializable? should we use KeyValuePair?

 

 

Regards,

 

 

Nirban Dutta

 

Software Engineer

PROJECTCENTRE_LOGO_

 

P 1300 653 420 | M +61 432 675 543

Deloitte_TF50Winner

F +61 (0) 2 9420 8277

3 / 11 Orion Road, Lane Cove, NSW, Australia 2066

CADX PTY LTD DISCLAIMER: The information contained in this email message is CONFIDENTIAL INFORMATION, and may also be LEGALLY PRIVILEGED, intended only for the individual or entity named above. If you are not the intended recipient, you are hereby notified that any use, review, dissemination, distribution or copying of this document is strictly prohibited. If you have received this document in error, please immediately notify us by email and destroy the original message. CADX disclaims all liability and responsibility for any direct or indirect loss or damage that may be suffered by any recipient of this message

 


_______________________________________________
Monodroid mailing list
[hidden email]

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can not send IDictionary to WCF

RScanlon
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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Can not send IDictionary to WCF

Richard Wilburn
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
Loading...