AKA ‘avoiding the dreaded “Can not register property YourProperty after containing type (YourBaseType) has been instantiated” error message’
Somewhere between CSLA 3.0 en 3.6 a new way of registering properties has become into being:
// old skool CSLA
private string _oldProp = string.Empty;
public string OldProp
{
get
{return _oldProp;}
set
{ if (value == null) value = string.Empty;
if (!_oldProp.Equals(value))
{
_oldProp = value;
PropertyHasChanged("OldProp");
}
}
}
//new skool CSLA
private static PropertyInfo NewPropProperty =
RegisterProperty(c => c.NewProp);
public string NewProp
{
get { return GetProperty(NewPropProperty); }
set { SetProperty(NewPropProperty, value); }
}
In CSLA 4.0 the last style is mandatory, so I started upgrading some objects (while currently using CSLA 3.8.3) in anticipation. So I upgraded my base object
using Csla;
namespace CslaInheritance
{
public abstract class MyBaseClass : BusinessBase<MyBaseClass>
{
protected static PropertyInfo<string> MyProp1Property =
RegisterProperty<string>(c => c.MyProp1);
public string MyProp1
{
get { return GetProperty(MyProp1Property); }
set { SetProperty(MyProp1Property, value); }
}
protected static PropertyInfo<string> MyProp2Property =
RegisterProperty<string>(c => c.MyProp2);
public string MyProp2
{
get { return GetProperty(MyProp2Property); }
set { SetProperty(MyProp2Property, value); }
}
}
}
and then my child object
using Csla;
namespace CslaInheritance
{
public abstract class MyConcreteClass1 : MyBaseClass
{
protected static PropertyInfo<string> ConcreteProp1Property =
RegisterProperty<string>(c => c.ConcreteProp1);
public string ConcreteProp1
{
get { return GetProperty(ConcreteProp1Property); }
set { SetProperty(ConcreteProp1Property, value); }
}
protected static PropertyInfo<string> ConcreteProp2Property =
RegisterProperty<string>(c => c.ConcreteProp2);
public string ConcreteProp2
{
get { return GetProperty(ConcreteProp2Property); }
set { SetProperty(ConcreteProp2Property, value); }
}
}
}
And then I noticed something odd: according to the compiler, ConcreteProp1 and ConcreteProp2 were not defined. Even worse is the situation when you choose to upgrade your properties not using lambda expressions, but PropertyInfo objects, like this:
protected static PropertyInfo<string> ConcreteProp3Property =
new PropertyInfo<string>("ConcreteProp3Property");
public string ConcreteProp3
{
get { return GetProperty(ConcreteProp3Property); }
set { SetProperty(ConcreteProp3Property, value); }
}
because this will compile - and run. Until you create a second child class MyConcreteClass2, instantiate it, then instantiate a MyConcreteClass1 – and then you will get a cryptical runtime error message saying “Can not register property ConcreteProp1Property after containing type MyBaseClass has been instantiated”.
Fortunately the CSLA framework comes with sources, and after some rooting around I found the culprit, if you can call it that, in Csla.BusinessBase:
protected static PropertyInfo<P>
RegisterProperty<P>(Expression<Func<T, object>> propertyLambdaExpression)
{
PropertyInfo reflectedPropertyInfo =
Reflect<T>.GetProperty(propertyLambdaExpression);
return RegisterProperty(Csla.Core.FieldManager.PropertyInfoFactory.Factory.Create<P>(
typeof(T), reflectedPropertyInfo.Name));
}
Although MyConcreteClass1 inherits from MyBaseClass, MyBaseClass inherits in turn from templated class BusinessBase<MyBaseClass>. Therefore, in RegisterProperty called from MyConcreteClass1 T is still MyBaseClass. It does not matter that I actually called it from a child class. So what happens is that all the statics are defined in the base class MyBaseClass. If you are using the lambda variant to register, the compiler saves your *ss, but if you use the PropertyInfo method something weird happens. Remember, statics in a class are initialized as soon as you touch any one of statics. So what happens is: you instantiate your concrete child class, immediately the statics of both the concrete and the base class are initialized, and all the properties are registered in the base class. If you try to instantiate a second concrete child class, Csla finds that your base class properties are already initialized, and the dreaded “Can not register property ConcreteProp1Property after containing type MyBaseClass has been instantiated” error message appears.
Now you can of course change the way you implement classes. I might make MyBaseClass generic as well, then T changes along. But when upgrading an existing API out of a situation in which direct inheritance used to be perfectly legal, it’s a different story.
There are actually two ways out of this. The first one is: use PropertyInfo, but explicitly name the object type to which the property belongs
protected static PropertyInfo<string> ConcreteProp3Property =
RegisterProperty(typeof(MyConcreteClass1),
new PropertyInfo<string>("ConcreteProp3Property"));
public string ConcreteProp3
{
get { return GetProperty(ConcreteProp3Property); }
set { SetProperty(ConcreteProp3Property, value); }
}
This works, but I like the solution below better, because that uses lambda expressions again and so your friend the compiler ;-) can help you catch typo’s. The only way I see to realize that is to add a static method at the bottom of your class
private static PropertyInfo<T> RegisterPropertyLocal<T>(
Expression<Func<MyConcreteClass1, object>> propertyLambdaExpression)
{
var reflectedPropertyInfo =
Reflect<MyConcreteClass1>.GetProperty(propertyLambdaExpression);
return RegisterProperty(typeof(MyConcreteClass1),
Csla.Core.FieldManager.PropertyInfoFactory.Factory.Create<T>(
typeof(MyConcreteClass1),
reflectedPropertyInfo.Name);
}
and then register your properties like this from now on:
protected static PropertyInfo<string> ConcreteProp1Property =
RegisterPropertyLocal<string>(c => c.ConcreteProp1);
public string ConcreteProp1
{
get { return GetProperty(ConcreteProp1Property); }
set { SetProperty(ConcreteProp1Property, value); }
}
The drawback of this solution is, of course, that you have to define a static RegisterPropertyLocal in every inherited class you define. But at least you will be saved from typos and weird runtime errors.
Now you are ready to upgrade, but I would recommend recording some macros to do the actual syntax change, unless you are very fond of very dull repetitive typing jobs ;-)
