We are using CSLA 4.1. Our business objects are generated from the T4 templates. We are getting an EditLevel Mismatch in CopyState when we return an updated EditableBusinessBase class as criteria for an async Static Command. The class is originally part of the criteria object passed to the command. The return of the command includes an updated base class. When I look at the object model in the watch window, the Edit levels are different for the base class versus its child classes (EditableChildLists). I changed the template to add the "DisableIEditableObject=true" on the child classes (EditableChildBase) contructors . However, this is not available to be set for the BusinessListBase classes. I also attempted to clone the object before it was passed to the command and after the command received it, but still have the issue when the Async callback attempts to set the Business base class in the ui to the one from the command. So what can I set to cause the collections to Disable the IEditableObject or could this be caused by the way the ChildList objects are being initialized when the root base is created?
Command Call in Silverlight Client:
CriteriaObject criteria = new CriteriaObject();
criteria.Property1 = value;
criteria.Property2 = value;
criteria.BusinessObject = this.Model.Clone;
BusinessObject.CommandMethod(Criteria, (o, e) =>
if (e.Error == null)
this.Model = e.Object.BusinessObject; //Error occurs here.
Business Object Method to Call Command:
public static void CommandMethod(CriteriaObject criteria, EventHandler<DataPortalResult<Command>> callback)
Collection Object Load:
internal static MyCollection Get(IEnumerable<EZOrder.Data.MyChildItem> data)
if (data == null)
Additionally, when the Editable Root class is set to a property on the criteria object, it still has the valid Edit Level 2. However, once it is deserialized on the server, only the Editable Root class has an edit level of 0. Its children are Edit Level 2. It seems like it is inheriting the edit level from Criteria, but not passing it along to the grandchildren. Stingy Parents...
We ended up solving this by using the ManageObjectLifetime =false in the ViewModel classes since we don't use the N-Level Undo features in our app.
Copyright (c) Marimer LLC