DataContract Diagram Encoding Problem

Topics: General Discussion Forum, Service Factory Modeling Edition Forum
Apr 16, 2008 at 6:15 PM
I have two developers working on same Model.
Implementation Technology is set to WCF.
Developer 1 creates a Data Contract Collection called "SalesPositions" and saves it. Saves to diagram file as:
<dataContractCollection Id="57fbc344-3576-4a7d-8c3d-702e6f35bbcb" objectExtenderContainer="&lt;?xml version=&quot;1.0&quot;?&gt;&#xD;&#xA;&lt;ObjectExtenderContainer xmlns:xsi=&quot;; xmlns:xsd=&quot;;&gt;&#xD;&#xA;  &lt;ObjectExtenders xsi:type=&quot;WCFDataContractCollection&quot; /&gt;&#xD;&#xA;&lt;/ObjectExtenderContainer&gt;" name="SalesPositions" namespace="">
        <dataContractBaseCanBeContainedOnContracts Id="1a6d323a-baaa-4446-9151-a5df6a5cba03">
          <dataContractMoniker Id="076c61e3-2e0a-4348-9d11-9ca2375d9911" />
NOTICE the value for objectExtenderContainer which looks like XML encoding.

Now the model goes to Developer 2 who opens the Data Contract Model and moves a line or block and then tries to save the Data Contract Diagram. Gets the following error:
Cannot save 'C:\SecSvc\SecurityManagementServices\CommonTypes.datacontract': Type 'System.Xml.XmlNode' in Assembly 'System.Xml, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not marked as serializable.

If Developer 2 deletes the Data Contract Collection "SalesPositions" and then re-adds it back he is then able to save the diagram.
HOWEVER, Saves to diagram file as:
    <dataContractCollection Id="7e06a561-bd6e-445a-b9e2-4e44119d27a7" objectExtenderContainer="AAEAAAD/////AQAAAAAAAAAMAgAAAGZNaWNyb3NvZnQuUHJhY3RpY2VzLk1vZGVsaW5nLkNvbW1vbiwgVmVyc2lvbj0zLjEuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTMxYmYzODU2YWQzNjRlMzUFAQAAAFBNaWNyb3NvZnQuUHJhY3RpY2VzLk1vZGVsaW5nLkV4dGVuc2lvblByb3ZpZGVyLkV4dGVuc2lvbi5PYmplY3RFeHRlbmRlckNvbnRhaW5lcgEAAAAPb2JqZWN0RXh0ZW5kZXJzAxxTeXN0ZW0uQ29sbGVjdGlvbnMuQXJyYXlMaXN0AgAAAAkDAAAABAMAAAAcU3lzdGVtLkNvbGxlY3Rpb25zLkFycmF5TGlzdAMAAAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uBQAACAgJBAAAAAEAAAABAAAAEAQAAAAEAAAACQUAAAANAwwGAAAAgAFNaWNyb3NvZnQuUHJhY3RpY2VzLlNlcnZpY2VGYWN0b3J5LkV4dGVuZGVycy5EYXRhQ29udHJhY3QuV2NmLCBWZXJzaW9uPTMuMS4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49MzFiZjM4NTZhZDM2NGUzNQUFAAAAV01pY3Jvc29mdC5QcmFjdGljZXMuU2VydmljZUZhY3RvcnkuRXh0ZW5kZXJzLkRhdGFDb250cmFjdC5XY2YuV0NGRGF0YUNvbnRyYWN0Q29sbGVjdGlvbgEAAAAOY29sbGVjdGlvblR5cGUDC1N5c3RlbS5UeXBlBgAAAAoL" name="SalesPositions" namespace="">
        <dataContractBaseCanBeContainedOnContracts Id="d7ec61d1-b31e-4c0d-b921-bb10e6657944">
          <dataContractMoniker Id="076c61e3-2e0a-4348-9d11-9ca2375d9911" />

NOTICE the value for objectExtenderContainer which looks like Base 64 encoding.

This is happening whenever there are Data Contract Collections. Each developer has to delete ALL the Data Contract Collections in the diagram and add them back inorder to get the diagram to save. Also this is only an issue after you have chosen a Implementation Technology of WCF. If you have not chosen an Implementation Technology yet then the diagram files do not appear to encode the Data Contract Collections and therefore not a problem with the developers exchanging the Model.

Can someone please tell me how to get all the developers to save the Data Contract Collections in the diagram file using the same encoding for objectExtenderContainer attribute.

Also which encoding is correct XML or Base 64????

Apr 16, 2008 at 6:18 PM
Sorry values for ObjectExtenderContainer got cut off in previous post:

<dataContractCollection Id="57fbc344-3576-4a7d-8c3d-702e6f35bbcb" objectExtenderContainer="<?xml version="1.0"?>&#xD;&#xA;<ObjectExtenderContainer xmlns:xsi="" xmlns:xsd="">&#xD;&#xA; <ObjectExtenders xsi:type="WCFDataContractCollection" />&#xD;&#xA;</ObjectExtenderContainer>" name="SalesPositions" namespace="">

<dataContractCollection Id="7e06a561-bd6e-445a-b9e2-4e44119d27a7" objectExtenderContainer="AAEAAAD/////AQAAAAAAAAAMAgAAAGZNaWNyb3NvZnQuUHJhY3RpY2VzLk1vZGVsaW5nLkNvbW1vbiwgVmVyc2lvbj0zLjEuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPTMxYmYzODU2YWQzNjRlMzUFAQAAAFBNaWNyb3NvZnQuUHJhY3RpY2VzLk1vZGVsaW5nLkV4dGVuc2lvblByb3ZpZGVyLkV4dGVuc2lvbi5PYmplY3RFeHRlbmRlckNvbnRhaW5lcgEAAAAPb2JqZWN0RXh0ZW5kZXJzAxxTeXN0ZW0uQ29sbGVjdGlvbnMuQXJyYXlMaXN0AgAAAAkDAAAABAMAAAAcU3lzdGVtLkNvbGxlY3Rpb25zLkFycmF5TGlzdAMAAAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uBQAACAgJBAAAAAEAAAABAAAAEAQAAAAEAAAACQUAAAANAwwGAAAAgAFNaWNyb3NvZnQuUHJhY3RpY2VzLlNlcnZpY2VGYWN0b3J5LkV4dGVuZGVycy5EYXRhQ29udHJhY3QuV2NmLCBWZXJzaW9uPTMuMS4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49MzFiZjM4NTZhZDM2NGUzNQUFAAAAV01pY3Jvc29mdC5QcmFjdGljZXMuU2VydmljZUZhY3RvcnkuRXh0ZW5kZXJzLkRhdGFDb250cmFjdC5XY2YuV0NGRGF0YUNvbnRyYWN0Q29sbGVjdGlvbgEAAAAOY29sbGVjdGlvblR5cGUDC1N5c3RlbS5UeXBlBgAAAAoL" name="SalesPositions" namespace="">

Apr 16, 2008 at 8:13 PM
In the first scenario (Dev1) you are getting Xml Serialization for the obj extender. This is done when this extender (in this case the collection and its members) are XmlSerializable, otherwise it will fallback to the binary formatter as you can see on the second secanrio (Dev2).
Now for some reason, the second scenario is detecting a non serializable type and therefore reverting to binary. (My guess may be some type in your collection that may be using an XmlNode according to the error description).
Nevertheless, the only drawback of the different serialization is that binary is opaque for info inside the extender and Xml may give you a chance to inspect its content and manually change it. However manually editing a model file is not a typical scenario so it should not be a big issue but I might be wrong if you actually depend on that.
So both encoding are correct but that will depend on which of them may be used, giving first try to XML.
Apr 16, 2008 at 8:42 PM
Not sure I understand. The two developers are Zipping up the entire solution and sending it back and forth.
All they are doing is opening an existing DataContract Model and Adding a DataContract Collection and saving.
The Data Contract "Position" which is associated with the Data Contract Collection is the same for both developers. Only the Data Contract Collection
is being deleted and recreated and associated with the existing Data Contract "Position"

Where is the choice of Xml Serialization being made vs binary?
Is this some property or attribute of the Modeling environment? Developers are not changing any Properties.
Is this a user setting in Visual Studio 2008 that exists outside of the solution they are sending back and forth?

Doesn't this have to be something different in the two developers environment given they are using the exact same Solution
and only playing with the creation of the Data Contract Collection Shape in the diagram.

How does the developer specifically choose XML Serialization or Binary to effcet the value of ObjectExtenderContainer for the Data Contract Collection?

Apr 16, 2008 at 10:43 PM
You can't choose the serialization strategy. That is being done in the DSL libraries of WSSF. Whenever you got a type that does not supports XML serializer, then it will automatically fallback to binary.
Apr 16, 2008 at 11:24 PM
OK, but why on one computer does it choose to save diagram Data Contract Collection as XML
and on the second computer it saves it as binary. It is the exact same files copied from one machine to the other.

This goes for all Data Contract Collections.
On computer one it saves using XML and on Computer two it saves as binary.

It is the exact same Visual Studio Solution copied on both machines.
It is the exact same Type, it is the same file.

Apr 17, 2008 at 12:20 PM
In that case, perhaps the difference is in the enviroment (VS,SDK, Fwk in one machine may differ).
Apr 17, 2008 at 1:49 PM
Yes that is what I believe to be the problem.
Can you suggest what particular environment setting might be causing this on the computer that is
saving all Data Contract Collections as Binary instead of XML.

Also what is Fwk?

Thanks again for your help,
Apr 18, 2008 at 1:08 PM
Edited Apr 18, 2008 at 1:12 PM
Not sure, but the only clue is the errror message you are getting regarding the XmlNode as not serialized.
Do you know if in both devs are executing exactly the same sequence of steps in terms of opening model files, update and save. That way we may also compare if some library is being loaded and make the difference between both environments.

Fwk: Framework
May 23, 2008 at 11:09 PM

In our scenario, we are work in a solution under Visual Team System.
A developer create a new Data Contract Model, he crate a Data Contract (Person) and Data Contract Collection (PersonList), new Data Contract Collection has Data Contract property to Person and Collection Type property to List<T>, then he check in the new model.
A second developer get latest version and modify the data contract model that first developer made, add a new Primitive Data Type to System.String or any data type. Second developer check in the data contract model.
Whe the first developer want to get latest version and modify the new data contract he can´t save any modification, the same error apear: Cannot save 'Admon.datacontract': Type 'System.Xml.XmlNode' in Assembly 'System.Xml, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089' is not marked as serializable.

The only workaround was remove Data Contract Collection (PersonList) and create data contract collection again.
This behavior is slow when some body modify a exist data contract model, and he must recreate data contract collection.


Efrén Cruz

May 26, 2008 at 2:04 PM
Hi Efren,

Regarding the slow behavior you describe, I was wondering if you are using the lates version (Refresh) that has a fix in this area.

May 29, 2008 at 8:13 PM

Hi again Efren, I believe your problem could be related to the development environment of the FIRST developer you mentioned. To verify this, you should confirm that the objectExtenderContainer
of the DataContractColletion generated in the first step is being encoded in Base 64. You can check this by going through the following steps:

  1. Ask the developer you referred as the FIRST one to create the Data Contract model you described. Have him save the model created.
  2. Right click on the file with the .dataContract extension (NOT the diagram) and choose "Open With..."
  3. On the Open With dialog box that pops up, choose XML Editor and click OK.
  4. Verify that the objectExtenderContainer attribute on the dataContractCollection XML element has a value that looks like Base 64 encoding.  (eg: objectExtenderContainer="AAEAAAD/////AQAAAAAAAAAMAgAAAGZNaWN.....")

If this is the case, it means that there is a difference between the environments of the two developers and you should make sure that the environment of the first developer looks like the one of
the SECOND developer. By enviornment I mean the System Requirements for the WSSF Modeling Edition Source Code version:

  • Windows XP Professional, Windows Server 2003, or Windows Vista operating system
  • Microsoft Visual Studio 2008 (Visual Studio Professional Edition or Visual Studio Team Suite)
  • Visual Studio 2008 SDK Version 1.0 (includes the Domain-Specific Language (DSL) Toolkit)
  • Microsoft .NET Framework 3.5
  • Guidance Automation Extensions - February 2008 Release for Visual Studio 2005 and Visual Studio 2008
  • Guidance Automation Toolkit - February 2008 Release for Visual Studio 2008


Feb 10, 2009 at 4:39 PM
Was the cause of this ever determined?

I did manage to get it working once with everything saved in Base64, but have no idea how I did it.
The weird thing is that I have a working data contract model (objectExtenderContainer is Base64) that loads and saves fine, but if I add something new to the diagram, objectExtenderContainer saves as Xml.
So now I have a diagram with Base64 AND Xml, but the Xml fails to load, causing "Order" and "Collection Type" values to be lost.

I guess if it is ok to have either or both Xml/Base64 then the problem lies with the load routine.
This also happens for some data in the other diagrams.

Feb 11, 2009 at 6:13 PM
The exact cause was not determined but the most likely assumption was some kind of mistmatch between different versions of the XML serialization types in versions of the .NET Framework.
What is really weird is that the same type serialized as XML may not be deserialized back from XML.
Regarding the load rutine, it will simple try to use the binary serializer if the first character of the serialized string is an Hex char. Otherwise will switch to the XML serializer. In this case the XML serializer is complaining.
Feb 14, 2009 at 11:20 PM
My issue seems to be related to the Avanade dlls from installing "EntLib Extensions to WSSF (VS 2008) - Binary (Jun 2008)".
After removing it all my values save and load normally.

Dec 22, 2009 at 9:49 AM

I had the same issue and for me too removing the Avanade dlls solved the issue.