Csla 7.0.3 command class fails to serialize

[ecaldentey]

I'm migrating to Csla 7.0.3 and I already have all my classes working, Root, Child, EditList, ReadOnlyList, etc. All classes work perfectly by injecting interfaces into the DataAccess layer, using Criteria objects for selection filters, etc. My classes are constructed with properties, a factory class, a Criteria class, and DataPortal methods. Everything works perfectly as expected except for Command objects that I can't get to pass the serialization stage.

According to the definition of the ExecuteAsync method, it supports being passed either the command or an array of objects:
Task ExecuteAsync(T command);
Task ExecuteAsync(params object[] criteria);

But when I try to invoke the ExecuteAsync method, it fails when attempting to serialize.

As a test, I copied the ProjectExistsCommand example from the ProjectTracker project and tested it in 7.0.3, but it also fails in serialization.

To pinpoint exactly where the error occurs, I added the source project of Csla 7.0.3 to my project and followed the flow. Here I attach screenshots of what happens, and the problem occurs in the private void Write(object target, BinaryWriter writer) method of the CslaBinaryWriter class where the TypeCode of the target parameter is Object and is not supported.

Am I doing something wrong when creating command objects? Do they have a different way of handling than the rest of the Csla class types, and do I need to do something different?

Any help is appreciated.

[ecaldentey]

I changed the following code as indicated in thread #2923, and I included a DataPortal Create method and RunLocal, using the strategy of initially creating the command object and then passing it as a parameter to the ExecuteAsync method. This way, the command works.

I changed the code, and it now looks as follows, but obviously it's not as clear as one would expect:

[rockfordlhotka]

ProjectTracker is sadly out of date - on the backlog to update.

CSLA now always uses MobileFormatter for serialization, which means that all business and criteria types must be serializable by MobileFormatter. That means using managed backing fields for properties and only referencing types that are serializable (by MobileFormatter).

[ecaldentey]

Hello Rocky,

Where do I configure the WASM client and Blazor server to use the MobileFormatter serializer? Although I don't think the issue lies there because I've managed to enable classes inheriting from the Csla CommandBase class in my application currently. However, to make them work, I used the strategy of creating a command and then passing it as a parameter in the ExecuteAsync method. But when I pass parameters directly or through a Criteria object, the command fails, unless the MobileFormatter serialization allows ExecuteAsync to work with parameters.

Regards,

Esteban

[rockfordlhotka]

You don't need to configure the serializer - it is always MobileFormatter (starting with CSLA 5 I think?).

There are now two ways to execute a "command".

The original way, which is to

1. Create a command class that is a subclass of CommandBase
2. Set properties on that object
3. Execute the command
4. Evaluate properties on the resulting object

The new way, which is to

1. Call execute on the data portal, passing in criteria parameters
2. On the server, the data portal creates an instance of the desired type
3. On the server, the data portal calls the execute method, passing in the criteria parameters
4. The resulting object is returned to the client

This new way is literally a fetch operation, but with a different name. The class you create for this doesn't need to derive from CommandBase. It could be a subclass of ReadOnlyBase, CommandBase, or even just Csla.Core.MobileObject. The requirement is that it have a method to handle the execute operation on the server, than that it be serializable.