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"?
Jav
I think the big things when moving from 3.8 to 4 include:
Then there are the things you can choose to exploit:
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:
[Serializable()]
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)
Jav
Your RegisterProperty() call isn't using the lambda syntax, and your first parameter (the typeof() parameter) is incorrect.
Aah!
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.
Jav
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...
[Serializable]
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); }
}
}
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...
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