Using LLBLGen 4.0, Self Servicing, runtime version 4.0.13.0417

Code that worked fine in 3.5 to serialize and deserialize EntityFields is now failing in 4.0:

var field = new SD.LLBLGen.Pro.ORMSupportClasses.EntityField("XXX", "A", typeof(int));
MemoryStream ms = new MemoryStream();
var s = new System.Runtime.Serialization.NetDataContractSerializer();
s.Serialize(ms, field);
ms.Seek(0, SeekOrigin.Begin);
(new StreamReader(ms)).ReadToEnd().Dump();
ms.Seek(0, SeekOrigin.Begin);
var field2 = (SD.LLBLGen.Pro.ORMSupportClasses.EntityField)s.Deserialize(ms);  // Exception here
field2.Dump();

The Deserialize call fails with the following exception:

IXmlSerializable Type 'SD.LLBLGen.Pro.ORMSupportClasses.EntityField' must have default constructor.

My guess at the problem is that in 4.0, EntityFieldCore now implements IXmlSerializable, but EntityField does not implement a default construtor (EntityField2 does)

In what context are you serializing selfservicing fields outside an entity? Could you elaborate a bit about this scenario? I think it worked in v3 because the xml serializer simply did a reflection run over the object (the XML must have had all the properties, correct?)

Frans,

I'd be happy to provide some context. In our ASP.NET application, we have pages that allow the user to configure complicated searches via a UI. Our code then turns their search parameters into a PredicateExpression that we use to perform the search. In addition, we save the PredicateExpression, RelationCollection, SortExpressions, etc. into the ASP.NET Session so that we can repeat the same fetch later. The PredicateExpression might contain a FieldCompareValuePredicate, and the FieldCompareValuePredicate contains an EntityField.

If we configure the ASP.NET Session to use a provider that happens to use binary serialization, then this works fine. However, if we configure the Session to use a caching provider that happens to use XML based serialization, then we see the exception when the EntityField is deserialized.

We've recently been experimenting with both LLBLGen 4.0 and with different Session providers, which is why we're seeing this issue now.

-Wesley

The problem is that in an EntityField, there's a persistenceinfo object, which isn't xml serializable. So while the entityfield's own data is xmlserializable, the persistenceinfo needs to be serialized as well. This is currently not implemented, as the selfservicing fields themselves aren't meant to be serializable over xml. That it worked before using Xml serializer is thus 'luck'.

Anyway, we've to think about what to do with this, as we don't want people to run into a showstopper when migrating code to v4.

Implemented in build 05022013:

[Test]
public void XmlSerializeCompareValuePredicateTest()
{
    var predicate = CustomerFields.Country == "Germany";
    var ms = new MemoryStream();
    var s = new System.Runtime.Serialization.NetDataContractSerializer();
    s.Serialize(ms, predicate);
    ms.Seek(0, SeekOrigin.Begin);
    var deserializedPredicate = s.Deserialize(ms) as IPredicate;
    ms.Close();

    var customers = new CustomerCollection();
    customers.GetMulti(deserializedPredicate);
    Assert.AreEqual(11, customers.Count);
}

So this now works.

edit: release build is found here: http://www.llblgen.com/tinyforum/GotoMessage.aspx?MessageID=123429&ThreadID=21906

it might be we release the final build tomorrow instead of today, so in the meantime, if you need the feature to work today, you can grab the runtime from that post.