RegisterProperty - no more forceInit trick

RegisterProperty - no more forceInit trick

Old forum URL: forums.lhotka.net/forums/t/7986.aspx


JoeFallon1 posted on Thursday, November 12, 2009

Rocky,

Could you please describe how you got rid of the forceInit trick and can now guarantee that all managed properties get registered across the inheritance hierarchy?

I have this hierarchy:

1. CSLA.BusinessBase
2. MyBusinessBass
3. SomeBOGen
4. SomeBOBase
5. SomeBO (final type)

I put managed properties in my code gen level SomeBOGen. Then I put 1 more in the developer level SomeBOBase. There are none in the final type SomeBO.

When my web page called the Shared method SomeBO.GetSomeBO which is in the SomeBOGen level, the Shared managed properties were the first things that got registered. Then the DataPortal.Fetch call was executed.

But the Shared properties in the SomeBOBase level were not registered yet.

When ctor.Invoke(); is called then I assume that all constructors in the hierarch are called from the bottom up (5-1 in the list above) even if the class does not have hand written constructor like 5 and 4 do not. They inherit the Protected Sub New from the Gen level.

It is at this point that the Shared managed property in SomeBOBase is registered.

So it looks to me like the construction of the BO is handling the "touching" in each class. But if this is so why was the forceInit trick needed in the first place?

I know I am missing something here so can you please elaborate a bit?

Thanks.

Joe

 

 

ajj3085 replied on Friday, November 13, 2009

I think this happens if you use the overload of RegisterProperty that takes a type as the first argument.  Or in Silverlight the PropertyInfo's need to be public.

RockfordLhotka replied on Friday, November 13, 2009

The thing is that .NET treats static and instance fields differently.

It only initializes static fields on a type (not an object or subclass type, but each individual type) when a static member of that particular type is touched.

Touching an instance member doesn't trigger static initialization - only touching a static member triggers static initialization.

So what I did after it was clear that the forceInit thing was such a pain, was to write a method that runs through your inheritance hierarchy (once per appdomain per subclass type) and uses reflection to find and touch one static field per type.

In .NET this generally works without issue, because I can use private reflection.

In Silverlight there is no private reflection (for this anyway), so your static fields must be public for this to work.

As I said in another thread recently, I've taken to making my PropertyInfo<T> fields public anyway, because I so often want access to them in my DAL and/or UI too.

JoeFallon1 replied on Friday, November 13, 2009

Rocky,

I made them Public for the reasons you state.

Where is this code: "write a method that runs through your inheritance hierarchy (once per appdomain per subclass type) and uses reflection to find and touch one static field per type."

That is what I haven't been able to "find" or "see in action".

Joe

 

RockfordLhotka replied on Friday, November 13, 2009

It is FieldDataManager.ForceStaticFieldInit()

 

Copyright (c) Marimer LLC