Bug 11881 - CollectionDataContractAttribute Name is ignored for Dictionary types in DataContractSerializer
Summary: CollectionDataContractAttribute Name is ignored for Dictionary types in DataC...
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries ()
Version: 4.6.x
Hardware: PC Windows
: Lowest normal
Target Milestone: ---
Assignee: Marek Habersack
Depends on:
Reported: 2013-04-22 06:28 UTC by Andras Zoltan
Modified: 2017-07-06 16:05 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Shows the incorrect string generated by the DataContractSerializer (177.83 KB, image/png)
2013-04-22 06:28 UTC, Andras Zoltan

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Andras Zoltan 2013-04-22 06:28:11 UTC
Created attachment 3839 [details]
Shows the incorrect string generated by the DataContractSerializer

A dictionary type that is decorated with the CollectionDataContractAttribute serializes *almost* correctly, except that the Name property appears to be ignored.  This came to light in my project because I have one type on our web services that inherits from Dictionary<TKey, TValue> and which explicitly sets both the item, key and value names, but also the root name of the type itself.

Here's an example class: 

[CollectionDataContract(Name = "MyDictionary", 
	Namespace = "http://foo.bar/schema", 
	ItemName = "pair", 
	KeyName = "mykey", 
	ValueName = "myvalue")]
public class MyDictionary : Dictionary<string, string>


And here's a NUnitLite test  (with supporting method):

public string Serialize(object o)
	DataContractSerializer ser = new DataContractSerializer(o.GetType());
	using (var ms = new MemoryStream())
		ser.WriteObject(ms, o);
		return Encoding.Default.GetString(ms.ToArray());

public void ShouldSerializeDictionaryCorrectly()
	MyDictionary dict = new MyDictionary();
	dict["message1"] = "hello";
	dict["message2"] = "world";
	var s = Serialize(dict);
	Assert.That(s, Is.StringStarting("<MyDictionary"));

This test fails - and as you can see from the test output (screenshot attached), the object is incorrectly getting generated with the root element name of 'ArrayOfpair' instead of 'MyDictionary'.  Incidentally, you can also see that the ItemName, KeyName and ValueName properties do appear to have taken hold.

This bug does not appear to apply to types inheriting from List<T>, however: a similar test for the following type:

[CollectionDataContract(Name = "MyList", Namespace = "http://foo.bar/schema")]
public class MyList : List<string>


Passes fine.

This is a bit of a blocking issue for me now.  I can't change how the server serializes the type I'm trying to work with, and since I can't actually instruct the serializer to recognise the correct element name, there presently isn't any simple way for me to get this to work!
Comment 1 Andras Zoltan 2013-04-22 07:04:05 UTC
I have also pushed a QA on to StackOverflow for this: http://stackoverflow.com/questions/16145424/mfa-name-property-on-collectiondatacontractattribute-on-dictionary-type-is-i

Since that is a place where people might go with this issue.
Comment 2 Andras Zoltan 2014-04-28 09:32:56 UTC
Has this bug been fixed?  Causes interesting issues if you're trying to build a PCL as the only workaround I have involves a conditional #if __ANDROID__ block around the standard type definition, with a completely rewritten version of the type to get it to work in Xamarin Android.
Comment 3 Cody Beyer (MSFT) 2017-07-06 16:05:39 UTC
Thank you for taking the time to submit this report. After reviewing the description of this bug, we believe it no longer affects the current version of Xamarin.Android. If you are still experiencing the issue after updating your packages, please reopen this report with an attached reproduction.