BeginEdit Throws Exception When Using MobileFormatter in .NET Framework

[b-higginbotham]

Describe the bug
When setting the "CslaSerializationFormatter" to "MobileFormatter" on a .NET Framework client, any call to the BeginEdit method of UndoableBase throws an exception.

Version and Platform
CSLA version: 4.9.0
OS: Windows 10
Platform: WPF

Code that Fails
FieldDataManager.cs Line 525: formatter.Serialize(buffer, state);
MobileFormatter.cs Line 137: if (!(obj is IMobileObject mobile))

Additional context
Method calls that trigger this behavior:
ViewModelBase.cs Line 148: undo.BeginEdit();
BusinessBase.cs Line 891: CopyState(this.EditLevel + 1);
UndoableBase.cs Line 468: ((Core.IUndoableObject)value).CopyState(this.EditLevel + 1, BindingEdit);

Some additional considerations:
The implementations of IUndoableBase that I have examined treat only properties/fields that implement IUndoableBase as child objects. The MobileFormatter implementation treats any object that implements IMobileObject as a child object when passing it to the CslaWriter.
When trying to troubleshoot this issue with a local copy of the code, I ran into an issue where the CslaBinaryWriter would fall through to CslaBinaryWriter.cs Line 216: throw new NotSupportedException(Resources.BinaryWriterObjectSerializationException);

Most of the business objects in my project use a struct to provide additional context for GUIDs. This struct implements IMobileObject to allow the business objects to be serializable using the MobileFormatter. When I ran into the discrepancy in how a child object is defined, I decided it would be best to leave this one to the experts.

[rockfordlhotka]

A struct can't actually implement IMobileObject, because a struct doesn't have methods. There's no support for serializing value types (like a struct) in MobileFormatter (other than the standard primitive value types like int, double, etc.).

If you are going to use MobileFormatter you must live within its limitations.

[b-higginbotham]

Rocky,

Did you even read the entire post or did you just skip to the part you didn't like?

The comment about the struct was listed as an additional consideration, not the source of the problem. The problem is that FieldDataManager tries to serialize an array of IFieldData when serialized using .NET Framework. The type IFieldData[] does not implement IMobileObject and thus throws an exception when using the MobileFormatter. This is a bug.

For what it's worth though, I had zero issues implementing the IMobileObject interface on this struct and serializing and deserializing it using the MobileFormatter. I'm not sure why you jumped on this to dismiss the entire issue.

[GillesBer]

Hi @Hadronicus ,

I had zero issues implementing the IMobileObject interface on this struct

Did deserialization work?
I would expect it to behave unexpectedly, ie such as https://blogs.msdn.microsoft.com/abhinaba/2005/10/05/c-structs-and-interface/

[b-higginbotham]

@GillesBer

Deserialization works fine. I created a repo with a simple demonstration that can be found here.

[rockfordlhotka]

I'm pretty sure the issue in your sample code is because MobileFormatter can't serialize a custom enum. Your GetState/SetState code needs to convert/parse the value as a string.

So you are right - the struct is a red herring - it is the enum that's the issue.

Update: Nope, enums work too.

I'm trying to base some unit tests on your sample repro - thus far unsuccessful. I'll check it into a branch so you can collaborate and help me figure out what I'm doing that isn't triggering your issue.

See the commit (c68235e) to review the new unit test code I've added trying to replicate your issue.

[b-higginbotham]

I've added two ways to reproduce the original issue. One is a bare bones project that I hosted here.

I was also able to reproduce it using the ProjectTracker sample, but it required a little manipulation because the App.config file still has a reference to MobileProxy which was removed.

ProjectTracker Reproduction Steps

1. Add reference to ProjectTracker.DalMock to ProjectTracker.Ui.WPF. Note: I just wanted to set the project to use the local Data Portal for a quick setup, I was having trouble getting the proxy to communicate with the app server host project.
2. Replace the contents of the App.config file in the .\Samples\ProjectTracker\ProjectTracker.Ui.WPF directory with the following code:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <appSettings>
  <add key="DalManagerType" value="ProjectTracker.DalMock.DalManager,ProjectTracker.DalMock" />
  <add key="CslaSerializationFormatter" value="MobileFormatter"/>
 </appSettings>
 <startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/></startup>
</configuration>

3. Build and launch ProjectTracker.Ui.WPF.
4. Log in as Username: manager Password: manager.
5. Click on Project List.
6. Click the Edit button for the first entry in the list.

Resulting Call Stack

Edit: I forgot to include the actual exception.

System.InvalidOperationException: 'Type IFieldData[] must implement IMobileObject'
   at Csla.Serialization.Mobile.MobileFormatter.SerializeObject(Object obj) in E:\src\rdl\csla\Source\Csla.Shared\Serialization\Mobile\MobileFormatter.cs:line 138
   at Csla.Serialization.Mobile.MobileFormatter.SerializeAsDTO(Object graph) in E:\src\rdl\csla\Source\Csla.Shared\Serialization\Mobile\MobileFormatter.cs:line 63
   at Csla.Serialization.Mobile.MobileFormatter.Serialize(Stream serializationStream, Object graph) in E:\src\rdl\csla\Source\Csla.Shared\Serialization\Mobile\MobileFormatter.cs:line 48
   at Csla.Core.FieldManager.FieldDataManager.Csla.Core.IUndoableObject.CopyState(Int32 parentEditLevel, Boolean parentBindingEdit) in E:\src\rdl\csla\Source\Csla.Shared\Core\FieldManager\FieldDataManager.cs:line 525
   at Csla.Core.UndoableBase.CopyState(Int32 parentEditLevel) in E:\src\rdl\csla\Source\Csla.Shared\Core\UndoableBase.cs:line 468
   at Csla.Core.UndoableBase.Csla.Core.IUndoableObject.CopyState(Int32 parentEditLevel, Boolean parentBindingEdit) in E:\src\rdl\csla\Source\Csla.Shared\Core\UndoableBase.cs:line 400
   at Csla.BusinessListBase`2.CopyState(Int32 parentEditLevel) in E:\src\rdl\csla\Source\Csla.Shared\BusinessListBase.cs:line 515
   at Csla.BusinessListBase`2.Csla.Core.IUndoableObject.CopyState(Int32 parentEditLevel, Boolean parentBindingEdit) in E:\src\rdl\csla\Source\Csla.Shared\BusinessListBase.cs:line 480
   at Csla.Core.FieldManager.FieldDataManager.Csla.Core.IUndoableObject.CopyState(Int32 parentEditLevel, Boolean parentBindingEdit) in E:\src\rdl\csla\Source\Csla.Shared\Core\FieldManager\FieldDataManager.cs:line 509
   at Csla.Core.UndoableBase.CopyState(Int32 parentEditLevel) in E:\src\rdl\csla\Source\Csla.Shared\Core\UndoableBase.cs:line 468
   at Csla.Core.BusinessBase.BeginEdit() in E:\src\rdl\csla\Source\Csla.Shared\Core\BusinessBase.cs:line 891
   at Csla.Xaml.ViewModelBase`1.<>c.<.cctor>b__111_0(DependencyObject o, DependencyPropertyChangedEventArgs e) in E:\src\rdl\csla\Source\Csla.Xaml.Shared\ViewModelBase.cs:line 143
   at System.Windows.DependencyObject.OnPropertyChanged(DependencyPropertyChangedEventArgs e)
   at System.Windows.DependencyObject.NotifyPropertyChange(DependencyPropertyChangedEventArgs args)
   at System.Windows.DependencyObject.UpdateEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType)
   at System.Windows.DependencyObject.SetValueCommon(DependencyProperty dp, Object value, PropertyMetadata metadata, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType, Boolean isInternal)
   at System.Windows.DependencyObject.SetValue(DependencyProperty dp, Object value)
   at Csla.Xaml.ViewModelBase`1.set_Model(T value) in E:\src\rdl\csla\Source\Csla.Xaml.Shared\ViewModelBase.cs:line 162
   at WpfUI.ViewModels.ProjectGetter.ProjectEdit..ctor(ProjectGetter parent, ProjectEdit project) in D:\csla-master\Samples\ProjectTracker\ProjectTracker.Ui.WPF\ViewModels\ProjectEdit.cs:line 62
   at WpfUI.ViewModels.ProjectGetter.get_ProjectEditViewModel() in D:\csla-master\Samples\ProjectTracker\ProjectTracker.Ui.WPF\ViewModels\ProjectEdit.cs:line 39

[rockfordlhotka]

I'm trying to get a failing unit test, that's the current goal. Did you look at the diff I linked to? It has basically the same code as your example, but doesn’t fail for some reason. Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Hadronicus <notifications@github.com> Sent: Monday, March 11, 2019 4:10:42 PM To: MarimerLLC/csla Cc: Rockford Lhotka; State change Subject: Re: [MarimerLLC/csla] MobileFormatter Unusable in .NET Framework (#1080) I've added two ways to reproduce the original issue. One is a bare bones project that I hosted here<https://github.com/Hadronicus/CslaMobileFormatterBug>. I was also able to reproduce it using the ProjectTracker sample, but it required a little manipulation because the App.config file still has a reference to MobileProxy which was removed. ProjectTracker Reproduction Steps 1. Add reference to ProjectTracker.DalMock to ProjectTracker.Ui.WPF. Note: I just wanted to set the project to use the local Data Portal for a quick setup, I was having trouble getting the proxy to communicate with the app server host project. 2. Replace the contents of the App.config file in the .\Samples\ProjectTracker\ProjectTracker.Ui.WPF directory with the following code: <?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="DalManagerType" value="ProjectTracker.DalMock.DalManager,ProjectTracker.DalMock" /> <add key="CslaSerializationFormatter" value="MobileFormatter"/> </appSettings> <startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/></startup> </configuration> 1. Build and launch ProjectTracker.Ui.WPF. 2. Log in as Username: manager Password: manager. 3. Click on Project List. 4. Click the Edit button for the first entry in the list. Resulting Call Stack at Csla.Serialization.Mobile.MobileFormatter.SerializeObject(Object obj) in E:\src\rdl\csla\Source\Csla.Shared\Serialization\Mobile\MobileFormatter.cs:line 138 at Csla.Serialization.Mobile.MobileFormatter.SerializeAsDTO(Object graph) in E:\src\rdl\csla\Source\Csla.Shared\Serialization\Mobile\MobileFormatter.cs:line 63 at Csla.Serialization.Mobile.MobileFormatter.Serialize(Stream serializationStream, Object graph) in E:\src\rdl\csla\Source\Csla.Shared\Serialization\Mobile\MobileFormatter.cs:line 48 at Csla.Core.FieldManager.FieldDataManager.Csla.Core.IUndoableObject.CopyState(Int32 parentEditLevel, Boolean parentBindingEdit) in E:\src\rdl\csla\Source\Csla.Shared\Core\FieldManager\FieldDataManager.cs:line 525 at Csla.Core.UndoableBase.CopyState(Int32 parentEditLevel) in E:\src\rdl\csla\Source\Csla.Shared\Core\UndoableBase.cs:line 468 at Csla.Core.UndoableBase.Csla.Core.IUndoableObject.CopyState(Int32 parentEditLevel, Boolean parentBindingEdit) in E:\src\rdl\csla\Source\Csla.Shared\Core\UndoableBase.cs:line 400 at Csla.BusinessListBase`2.CopyState(Int32 parentEditLevel) in E:\src\rdl\csla\Source\Csla.Shared\BusinessListBase.cs:line 515 at Csla.BusinessListBase`2.Csla.Core.IUndoableObject.CopyState(Int32 parentEditLevel, Boolean parentBindingEdit) in E:\src\rdl\csla\Source\Csla.Shared\BusinessListBase.cs:line 480 at Csla.Core.FieldManager.FieldDataManager.Csla.Core.IUndoableObject.CopyState(Int32 parentEditLevel, Boolean parentBindingEdit) in E:\src\rdl\csla\Source\Csla.Shared\Core\FieldManager\FieldDataManager.cs:line 509 at Csla.Core.UndoableBase.CopyState(Int32 parentEditLevel) in E:\src\rdl\csla\Source\Csla.Shared\Core\UndoableBase.cs:line 468 at Csla.Core.BusinessBase.BeginEdit() in E:\src\rdl\csla\Source\Csla.Shared\Core\BusinessBase.cs:line 891 at Csla.Xaml.ViewModelBase`1.<>c.<.cctor>b__111_0(DependencyObject o, DependencyPropertyChangedEventArgs e) in E:\src\rdl\csla\Source\Csla.Xaml.Shared\ViewModelBase.cs:line 143 at System.Windows.DependencyObject.OnPropertyChanged(DependencyPropertyChangedEventArgs e) at System.Windows.DependencyObject.NotifyPropertyChange(DependencyPropertyChangedEventArgs args) at System.Windows.DependencyObject.UpdateEffectiveValue(EntryIndex entryIndex, DependencyProperty dp, PropertyMetadata metadata, EffectiveValueEntry oldEntry, EffectiveValueEntry& newEntry, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType) at System.Windows.DependencyObject.SetValueCommon(DependencyProperty dp, Object value, PropertyMetadata metadata, Boolean coerceWithDeferredReference, Boolean coerceWithCurrentValue, OperationType operationType, Boolean isInternal) at System.Windows.DependencyObject.SetValue(DependencyProperty dp, Object value) at Csla.Xaml.ViewModelBase`1.set_Model(T value) in E:\src\rdl\csla\Source\Csla.Xaml.Shared\ViewModelBase.cs:line 162 at WpfUI.ViewModels.ProjectGetter.ProjectEdit..ctor(ProjectGetter parent, ProjectEdit project) in D:\csla-master\Samples\ProjectTracker\ProjectTracker.Ui.WPF\ViewModels\ProjectEdit.cs:line 62 at WpfUI.ViewModels.ProjectGetter.get_ProjectEditViewModel() in D:\csla-master\Samples\ProjectTracker\ProjectTracker.Ui.WPF\ViewModels\ProjectEdit.cs:line 39 — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub<#1080 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ACOZzn8kLrd0BLYMiAlWocuWiBxjeHyrks5vVsZSgaJpZM4bnseC>.

[b-higginbotham]

I think I chose the title poorly and it’s causing some confusion. The unit tests that you created are based on the sample I made to demonstrate that the MobileFormatter can successfully serializer and deserialize a custom struct I’m response to @GillesBer’s question.

The problem that I am seeing is similar to the issue described in #897, but for different reasons under different conditions. The code in the the two reproduction steps that I listed in my previous post would be a better starting point for a unit test to target this issue.

[b-higginbotham]

Rocky,

I am new to Git and GitHub, so I'm sorry if I didn't get this part 100% correct, but I forked the CSLA repository and created a branch with a unit test that fails for the exact issue that I'm experiencing. Take a look at it here 950f5d5.

[b-higginbotham]

I have looked into multiple ways of trying to solve this issue, and I ultimately came up with one that is actually quite simple, but I want to explain the thought process here to provide context to why I chose the solution that I did.

Considerations

1. CSLA for the full .NET Framework currently has no issues with serializing objects that are not compatible with the MobileFormatter. I believe it is critical to make sure this behavior remains intact.
2. I wanted to minimize any changes to the size and shape of the serialized payload of CSLA business objects. Any significant changes to the shape of the payload could cause potential compatibility issues. Any significant changes to the size of the payload could potentially cause performance issues.
3. I wanted to ensure that the BeginEdit, UndoChanges, and ApplyChanges methods would work with types that implement IMobileObject but not IUndoableObject. An example of this would be the custom struct described in the discussion above. This may be a detail that is only important to my specific project, but, at least in my case, it is definitely important.

Assumptions

• The serialized data for n-level undo never crosses a data portal boundary.
  • This is a critical assumption for the solution that I implemented because this solution cannot guarantee this if the state stack data crosses a data portal boundary because there's no guarantee that the process on the other side of the data portal can deserialize it.
  • After thorough examination of the CSLA source code, I believe this to be a safe assumption, and in certain cases, it is an explicit guarantee based on the implementation of IMobileObject in some of the affected classes.

Unsuccessful Approaches

1. Copy the code from the .NET standard implementation of IUndoableObject.CopyState on the FieldDataManager class. However, this was not viable because it would fail the first consideration.
2. Modify the FieldDataManager to serialize IFieldData objects using a MobileList or MobileDictionary rather than IFieldData[]. Doing this directly is not viable because IFieldData does not enforce the implementation of IMobileObject. The alternative would have been to serialize the raw data values from IFieldData. However, this approach, and every other option that I looked into ultimately came down to the same problem.
   • The type parameter for MobileList or MobileDictionary would need to be something that is generic enough to support all value types that may be passed into it. The only two candidates are IMobileObject, which fails the first consideration or System.Object.
   • System.Object immediately fails the third consideration because any type that implements IMobileObject will fail when be passed to the CslaBinaryWriter.
   • System.Object ultimately fails the second consideration as well because it would require additional type information to be serialized with the data in order to ensure proper handling during deserialization. This likely would have required rewriting large portions of code in FieldDataManager, UndoableBase, as well as the MobileFormatter itself and possibly the CslaBinaryWriter and CslaBinaryReader. None of that sounds particularly appealing because that would introduce a huge amount of volatility and likely some breaking changes.

Occam's Razor
After getting deep into the weeds researching these unsuccessful approaches, I eventually realized that the simplest solution to the problem is to have the FielDataManager and UndoableBase do exactly what they've been doing successfully for years in the full .NET Framework.

I created a new method on the SerializationFormatterFactory called GetNativeFormatter. The purpose of this method is to provide a formatter that can be used for serialization and deserialization in a format that is native to the environment in which a given process is running. In other words, Android, iOS, net-core, etc. processes will all use the MobileFormatter and .NET Framework processes will use the NetDataContractSerializerWrapper.

This is why the Data Portal boundary assumption is critical. As long as we are not trying to do a BeginEdit in one process and then an UndoChanges in another process on the other side of a data portal, this solution will remain completely transparent to any calling code. In my description of this assumption, I mentioned that in at least one place in the CSLA code, there is an explicit guarantee that this assumption would be correct. That occurs in the OnSetState implementation in UndoableBase. Because, this method explicitly clears the state stack during deserialization, it is guaranteed that the state cannot be undone on the other side of a Data Portal boundary when using the MobileFormatter.

We do not quite have the same level of guarantee when using other implementations of ISerializationFormatter. This does leave us with one potential breaking change if all of the following conditions are true:

• A project is using a custom implementation of ISerializationFormatter for data portal calls and
• the project is using a data portal proxy and
• the data portal client and server processes are using different versions of .NET (i.e. core vs framework) and
• the project is calling BeginEdit on one side of the Data Portal and UndoChanges on the other side.

A bonus bug
While testing the fix for the serialization problem, I came across an additional issue with the logic in the DoSave method of the ViewModelBase. When saving a business object with a child collection that inherits from BusinessListBase, the DoSave method would throw an exception for an edit level mismatch between the parent object and the child list. The root cause of this issue is the explicit guarantee for the data portal assumption that I described above. When deserializing and object that inherits from UndoableBase using the MobileFormatter, the state stack is explicitly cleared. When checking the edit level for UndoableBase, it simply returns the current count from the state stack. This will always be 0 after deserialization. However, BusinessListBase stores an explicit value for its edit level and this value is explicitly preserved through serialization and deserialization. I added an additional unit test to the ViewModelTests to demonstrate this behavior.

To resolve this issue, I modified BusinessListBase to no longer serialize this value and to explicitly default it to 0 in the implementation of OnSetState to match the behavior of UndoableBase.

[rockfordlhotka]

This is a great amount of work, research, and detail, thank you!

A question/concern I have is that it sounds like this leaves the existing bug/issue intact on Android and other platforms - presumably your unit test code would still fail there because all other platforms would still use MobileFormatter as their native serializer?

[b-higginbotham]

The source of the bug was code that was specific to the .NET Framework platform. With the exception to the removal of the edit level from the data serialized in BusinessListBase, the rest of the changes I made would not even be compiled when targeting other platforms. Anything that uses the MobileFormatter by default already has a working implementation and didn't need any attention as far as I could tell.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.