I've read various threads on the usage of the UnitOfWork class too keep track of collection modifications in the UI and decided to implement this approach.

I'm having the issue of remoting the UnitOfWork object over to the Server. On the client form I add a new entity:

CddcategoryEntity newEnt = (CddcategoryEntity)entities.AddNew();
newEnt.Cddcategoryguid = 0m;
newEnt.Shasessionguid = 0m;
newEnt.Lastmodifiedtime = DateTime.Today;
newEnt.Categoryid = "REMOTINGTEST";
newEnt.Categorytext = "Remoting Test with LLBLGen";

When the user clicks store, I add the collection for save and call the remote store method which takes in a UnitOfWork class

uow.AddCollectionForSave(entities);
mgr.Store(uow);

At this point on the client, I can see that the uow has the object in the "_collectionsToSave." When I get to the remote store method, however, the UOW has null for the following members: _collectionsToSave, _entitiesToInsert, _entitiesToSave, _entitiesToUpdate, _objectIDsToSave. This leads to a object reference error when I try to do the Commit() on the UOW.

public void Store(UnitOfWork uow)
{
     Transaction trans = new Transaction(IsolationLevel.ReadCommitted, "UOW");
     uow.Commit(trans, true);
}

Is it that these members do not get serialized? Am I doing something wrong? Ive tried to do some research on the topic but the closest I have come is this thread which I could still use some clarification on.

http://llblgen.com/tinyforum/Messages.aspx?ThreadID=6650&HighLight=1

Further information: I am using self-servicing, .NET 2.0, and have tried both tcp and http remoting with binary formatting.

Thanks, Milos

LLBLGen Pro uses ConstructSaveProcessQueues before a UnitOfWork object is serialized into a remoting stream, to be sure all elements to send over the wire are indeed elements which participate in a save action.

To elaborate on that abit more: The UnitOfWork(2) object thus only serializes the entities in the queues to the other side (and the entities to delete of course), it doesn't serialize the other objects. So the parameters you read are null / empty on the other side as that data isn't serialized, only the calculated queues for insert and update + the entities for delete are.

Thanks guys for the elaboration...

After examining the ConstructSaveProcessQueues() method it seems that any entities that are valid for save are either put in the _entitiesToInsert List or in the _entitiesToUpdate List.

So I tested this by calling the ConstructSaveProcessQueues() method on the UOW object manually on the client side after adding a new entity to see what it would do. It put an entity in the _entitiesToInsert collection.

It seems that the Commit method persists anything that is in these Lists but when I call the remote Store method passing this UOW object it now has null for these 2 Lists. I also notice that the [NonSerialized] attribute is above them as will in the UOW class.

Sorry if I am being dense, but it seems that I am missing something here. Thanks for bearing with me.

Milos

These steps are used to weed out entities which aren't used in the save process, e.g. in collections which are added to the unit of work.

At serialization It builds the two queues with the ConstructSaveProcessQueues routine, then builds one list from the two queues and adds that list as the entities to save to the data to remote. It doesn't send the other lists of entities or collections to save, as all entities to save are in the insert/update queues.

At deserialization, it simply stores the build list of entities to save as _entitiesToSave.

So at commit, it then again computes the queues from the entitiesToSave list.

What I find odd is that you get null for _entitiesToSave on the server. I have several unittests which serialize a unitofwork to a memorystream and back to test this and they work OK. What is the runtime library build nr of the runtime library you're using? (see the guidelines thread in this forum for how to obtain that number)

Sorry Otis for not supplying that information earlier...

Im using LLBLGen 2.0 the version is 2.0.0.61023

Im going to take a look at this further and see if maybe I'm doing something wrong that I have missed.

Thanks Milos

I hope this problem wasn't bothering you too much because it was totally my fault. I had started this project a while ago and just recently got back to it.

At the time it was a project that I converted from VS 2003 (.net 1.1) to VS 2005 (.net 2.0) using Visual studio to do this.

Getting back to it now, I realized I never changed the referenced LLBLGen dlls to the .Net 2.0 versions.

I regenerated everything for the 2.0 framework and changed the references and everything works smoothly now.

Thanks all for your insight, Milos

Glad it's all solved!