Review post below.
http://forums.lhotka.net/forums/thread/24774.aspx
It may assist you. Its using NVL objects not new class, but does use different code in DataPortal_Fetch
Regards
I don't know. I don't think we specifically tested using enum values through the MobileFormatter. I've entered a bug so this question/issue doesn't get lost.
I guess I should ask a clarifying question though.
Are you saying
I could see 1, as that's what we didn't test (I don't think).
If the problem is 2, then that's almost certainly a bug in your code, because I know NVL objects serialize just fine - I use them all the time.
If the problem is 3, then we need to talk about how you created the custom object. The MobileFormatter has very strict requirements around what objects it will and won't serialize, and if you want to pass any custom object through the data portal you have to create the object exactly right. CSLA has base classes you should inherit from, but the easiest solution, by far, is to use one of the normal business object base classes with managed backing fields - otherwise you'll have to do some extra work.
Thanks for the detailed explanation, that helps a lot.
Hopefully we can figure out a solution. The process of serializing values to/from Silverlight and .NET is complex because they are two different platforms, so there are no common types between them. Even what we see as the "same type" is actually not the same type at all...
Hi,
I'm just wondering what the final outcome of this was?
I see the 'bug' is closed as resolved, however when I try and use enums in a Silverlight/.Net mixed environment, I still receive the serialize error.
Is there an attribute i need to set on the enum to make this work???
Stuart
It sure looks like the fix was applied in April 2009:
Based on the code, I can't see how a special attribute or anything would be required - the serializer is just locating anything of type enum and is converting it to the underlying type.
Hi Rocky,
Thanks for the awesomely quick reply!
I've looked through all your CSLA light samples, and I can't see anywhere at all that you have ever used an enum as property type.
I've already converted all my PropertyInfo to now use <int>, but I'll make up a quick project later today to get the exact error that occurs. (It was a few hours ago, and my memory doesn't span that far back ;-).)
Will post here later today.
Stuart
There's a unit test for this: BusinessObjectWithEnum() in the Silverlight serialization tests.
Just wanted to mention that I am using the latest and I seem to be having an issue with enums as well. Using the very latest CSLA.
Type '<mytype>' with data contract name '<enumtype>:http://schemas.datacontract.org/2004/07/<ns>' is not expected. Add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.
I'm just going to use an integer for the property as I know that works, but just thought I'd mention this too.
We will have to re-open that bug then. This is odd though, since there is a unit test covering the scenario and it passes on both SL and .NET. The one thing the test doesn't cover is actually sending the value through the data portal, but technically that shouldn't matter if clone works on both sides. Obviously it does matter though 
Yes, that's the error I receive too, in the Silverlight client, when I attempt a save on the CslaDataProvider.
I am using Csla 3.8.2. (I haven't had time to replicate into a separate project.)
Stuart
This is a confirmed bug btw, and Sergey is working on a fix.
It actually has to do with n-level undo, because the serialization used there isn't the same as the serialization used by the data portal...
If the problem is 3, then we need to talk about how you created the custom object. The MobileFormatter has very strict requirements around what objects it will and won't serialize, and if you want to pass any custom object through the data portal you have to create the object exactly right. CSLA has base classes you should inherit from, but the easiest solution, by far, is to use one of the normal business object base classes with managed backing fields - otherwise you'll have to do some extra work.
Hi Rocky,
This caught my eye as I am trying to send a custom criteria object through the data portal. I'm using CSLA Light 3.8.2. My custom criteria object inherits from Csla.CriteriaBase. I've tagged the class as Serializable using the Csla.Serialization.SerializableAttribute. I declare my criteria class with a single generic type T. The custom criteria class has 2 properties... Name (string) and Value (object). BeginFetch is called with this criteria, from my ELRB based list class. The criteria property values look good going in to the call, but in the DataPortal_Fetch on the server side, both property values are null. What else do I need to do to ensure proper serialization of a custom criteria object?
Thanks,
Matt
You need to either use managed properties or you need to override OnGetState() and OnSetState() to put your private field values into the serialization stream.
You need to either use managed properties or you need to override OnGetState() and OnSetState() to put your private field values into the serialization stream.
Ah yes, rookie mistake... forgot to configure my properties as managed. I did that and it works now. Thanks!
Matt
fwiw, in CSLA 4 this will get easier because CriteriaBase is generic, so the same RegisterProperty() syntax used in a business object will work in a criteria object (and a command object and an identity object).
I'm glad to hear that. I've lately found myself using readonlybase type objects for criteria objects.
Look forward to hearing all about it at Code Camp on Apr 10th.
Look forward to hearing all about it at Code Camp on Apr 10th.
I am hoping that I can show the new business rules subsystem. That's what I'm working toward anyway 
Copyright (c) Marimer LLC