Hello,

We are currently using LLBLGen entities throughout our code base for our middle tier. One of the requirements we have is to serialize some entities to xml and store them into a database. An out of band process then picks up these serialized entities, deserializes them, and then performs some type of action on them.

We have run into the problem after we have made modifications to our code base (i.e. added new entities), re-generated the middle tier, and deployed those to our app servers (including the out of band process that processes the serialized entities). Because we have stored some serialized entities, when the out of band process with the new re-generated entities starts to process the previously serialized entities, we are getting a failure on the deserialization process.

After digging a little deeper, we found out that the deserialization fails because the LLBLGen "EntityType" value on the serialized entities in the database is different than the newly generated entities (i.e. likely as a result of adding new entities). But it appears only some of the objects have the EntityType as part of the xml and some don't

Now the questions: 1) Why does the EntityType appear on some serialized objects, but not others. 2) Is there a way to prevent serialization/deserialization from taking into account the EntityType so that we do not have to constantly update our stored serialized entities every time we make a change to LLBLGen? 3) Are there any work arounds?

1) This puzzles me - I'd expect them all to be the same. Which serialisation format are you using ? And are you sure the same one is used for each entity ?

2) You could override the serialise and deserialise methods, and serialise the entities yourself any way you like.

3) Have a method on the out of band process that knows how to upgrade from the older format to the newer ?

Matt

Thanks for replying so quick.

1) We are using the typical XML Serialization, so there is nothing too interesting here.

3) This is certainly an option, however, it means that everytime there is a change, we would have to modify this code, which is not too flexible/extensible. The out of band process is intended to be relatively generic. We are trying to avoid having to make updates everytime something changes.

The problem seems to be that when we do the XML Serlialization, the LLBLGen entity has an "EntityType = <some value>" property/attribute, and the value is unpredictable as it depends on what LLBLGen generates and how many additional entities we add. It appears that the EntityType is used on subtypes/derived classes so that the entity knows who its parent is. I tried changing the entity type value to the value of the parent class, and then deserialized, and it worked just fine. Problem with this is that we have tons of these xml serialized entities in the database, and would have to go through and update them all everytime there is a change ... not ideal

Is there anything out of the box that we can use? Perhaps some attributes we can decorate a class with?

Which LLBLGen runtime library version (build no.) are you using?

We are using LLBLGen Pro v3.0

For inherited entities this property is emitted so there is no doubt about the type. But you have a problem because the EntityType enum in your old code base (where these xmls were generated) is different from your actual code.

You can perform a little regex trick to read this entities back. This is no ideal but you wont need to modify every xml:

[TestMethod]
public void SerializeEntityVerbose()
{
    // fetch a SalesPerson (inherits from Employee)
    var salesPerson = new SalesPersonEntity();
    using (var adapter = new DataAccessAdapter())
    {
        adapter.FetchEntity(salesPerson);
    }

    // serialize it
    StreamWriter writer = new StreamWriter("salesPerson.XML");
    string salesPersonXml = String.Empty;
    salesPerson.WriteXml(out salesPersonXml);
    writer.Write(salesPersonXml);
    writer.Close();

    // now read it back
    StreamReader reader = new StreamReader("salesPerson.XML");
    string xmlFromFile = reader.ReadToEnd();
    reader.Close();

    // clean the EntityType property, if exists
    xmlFromFile = CleanMyOldEntityXML(xmlFromFile);
            
    // get the entity back
    var salesPersonFromXml = new SalesPersonEntity();
    salesPersonFromXml.ReadXml(xmlFromFile);

    // test: is this still a SalesPerson?
    Assert.IsTrue(salesPersonFromXml is SalesPersonEntity);
}

public string CleanMyOldEntityXML(string oldEntityXml)
{
    // if exists, remove the EntityType property
    Regex rgx = new Regex("EntityType=\"\\d+\"");
    return rgx.Replace(oldEntityXml, "");
}

Thanks for the quick response.

I just tried this out, and it got me further, but another error. Becuase the type is a subtype, there are additional properties on the subtype. When I exclude the EntityType value, it complains that the other properties are simply not part of the object.

Thoughts on this?

How are you deserializing it? It's seems logical to obtain the error, however in my case do it from an instance of the concrete type and everything worked.

For example, I deserialize as a SalesPerson (not an Employee). If I deserialize the xml as a EmployeeEntity, that will give errors because there are properties that don't match. Does that makes sense to you?