Slowly Inching to Csla4.0. Question about the final step

Slowly Inching to Csla4.0. Question about the final step

Old forum URL:

Jav posted on Monday, July 19, 2010

From VS2008, SL3.0, .Net3.5 and Csla3.8.4, I have arrived at VS2010, SL4.0, .Net4.0 and Csla3.8.4

So far so good.  The App runs fine in my development server.  I have downloaded Csla4.0 and "installed" it.

I know about the issue of changing PropertyInto stuff from Private to Public, which I am starting on rigt now.  My Validation Rules have not been set up yet, nor authorization rules - I wanted to get to 4.0 before starting on those.

Is there any other preparatory change I need to make before "crossing over"?


RockfordLhotka replied on Monday, July 19, 2010

I think the big things when moving from 3.8 to 4 include:

  1. Understanding the new CSLA assemblies (Csla,dll, Csla.Web.dll, Csla.Xaml.dll, etc)
  2. If doing Silverlight 4, making the PropertyInfo<T> fields public
  3. Changing business rules to the new model
  4. Changing authorization rules to the new model
  5. Updating any use of LINQ to CSLA for the new implementation
  6. Switch from non-generic data portal to generic data portal (if necessary)

Then there are the things you can choose to exploit:

  1. New MVVM support in Silverlight/WPF
  2. New ASP.NET MVC support
  3. Support for SL 4 data binding UI features
  4. Simplified criteria passing
  5. Simplified data portal configuration
  6. and more...



Jav replied on Monday, July 19, 2010

Thank you.  That would be very helpful.

One interesting observation (for all I know it may be expected)

While still working with Csla 3.8.4, I changed all PropertyInfo declarations from private to public. To Create my Root object, I need to send 4 parameters, which I do with an old style Criteria class, which is implemented as shown below.  The observation was that when the PropertyInfo items within the Criteria class were changed from private to public, it generated a runtime error as shown below.

Here is my Root object factory method:
       public static void NewEncounter(Int32 personKey, Int32 param2, Int32 param3, Int32 param4,                                                                                      EventHandler<DataPortalResult<Encounter>> callback)
            var dp = new DataPortal<Encounter>();
            dp.CreateCompleted += callback;
            dp.BeginCreate(new Encounter.Criteria(personKey, param2, param3, param4));

Here is the Criteria Class:
        class Criteria : Csla.CriteriaBase
            public static PropertyInfo<Int32> PersonKeyProperty = RegisterProperty<Int32>(typeof(Criteria), new PropertyInfo<Int32> ("PersonKey","PersonKey"));
            public Int32 PersonKey
                get { return ReadProperty(PersonKeyProperty); }
                set { LoadProperty(PersonKeyProperty, value); }

            ...........  Other Properties ..........................

            public Criteria(Int32 personKey, Int32 argument2, Int32 argument3, Int32 argument4)
                this.PersonKey = personKey;
 ..................   other criteria arguments ..................

Data error
Csla.Reflection.CallMethodException: NewEncounter method call failed ---> Csla.PropertyLoadException: Property load or set failed for property PersonKey (Attempt by method 'Csla.Core.FieldManager.FieldDataManager.ForceStaticFieldInit(System.Type)' to access field 'VisitLibrary.Encounter+Criteria.PersonKeyProperty' failed.)
at Csla.Core.ManagedObjectBase.LoadProperty[P](PropertyInfo`1 propertyInfo, P newValue)
at VisitLibrary.Encounter.Criteria.set_PersonKey(Int32 value)
at VisitLibrary.Encounter.Criteria..ctor(Int32 personKey, Int32 param2, Int32 param3, Int32 param4)
at VisitLibrary.Encounter.NewEncounter(Int32 personKey, Int32 param2, Int32 param3, Int32 param4, EventHandler`1 callback)
 --- End of inner exception stack trace ---
at Csla.Reflection.MethodCaller.CallFactoryMethod(Type objectType, String method, Object[] parameters)at Csla.Silverlight.ViewModelBase`1.BeginRefresh(String factoryMethod, Object[] factoryParameters)


RockfordLhotka replied on Monday, July 19, 2010

Your RegisterProperty() call isn't using the lambda syntax, and your first parameter (the typeof() parameter) is incorrect.

Jav replied on Tuesday, July 20, 2010


That was the first and only multi-argument Criteria class I wrote almost 8 months, don't even know where I got that code.  Amazingly it's been working all these months.

In VS2010, I am using:
        private class Criteria : Csla.BusinessBase<Criteria>

In VS2008 I have already tried:
        private class Criteria : Csla.BusinessBase<Criteria>, ICriteria
and it appears to work fine

I have now also learnt that in Csla4, ICriteria is neither available nor necessary.


b1tburn3r replied on Tuesday, February 25, 2014

I need a second pair of eyes on this...

I am using RegisterProperty with the Lambda syntax (see my example below), I also have the PropertyInfo set as a public static instance, however; I am getting the exact same error he is describing in his original question.  The exception is thrown in my code by CSLA when I call LoadProperty with the value to set (I am just setting it inside my constructor as shown below).  FWIW - this is on a SilverLight application happening on the client side.

I must be missing something somewhere because I am using the built in Csla.Security.UsernameCriteria class in my own custom identity implementation and LoadProperty works fine in there...

private class CustomerCriteria : CriteriaBase<CustomerCriteria>
         public static PropertyInfo<Guid> CustomerIdProperty = RegisterProperty<Guid>(p => p.CustomerId);

         internal CustomerCriteria(Guid custId)
                CustomerId = custId;

         public Guid CustomerId
               get { return ReadProperty(CustomerIdProperty);
               private set { LoadProperty(CustomerIdProperty, value); }


b1tburn3r replied on Tuesday, February 25, 2014

Spent some time poking around the CSLA codebase to see if I could figure out what I was doing wrong in my code...

Interesting - the problem seems to be that I cannot have a private nested criteria class in my business object, and I need a public parameterless constructor on the Silverlight side as well - once I made the criteria class public and added the constructor was able to call LoadProperty without issue.

It would seem that I am going to have to unlearn some habits I got used to doing in the earlier versions of Csla...

RockfordLhotka replied on Tuesday, February 25, 2014

The Silverlight runtime imposes some limitations on what can be done, and CSLA had to be altered to accommodate them.

The "Using CSLA 4" ebook series, and the Silverlight video series touch on most of the difference points.

The upside to adapting though, is that WinRT imposes similar limitations (I think of it as basically being Silverlight 6 :) ), so if you get used to programming for Silverlight you should be all set for WinRT.

Copyright (c) Marimer LLC