System.TypeInitializationException using Static PropertyInfo in Csla 3.8

System.TypeInitializationException using Static PropertyInfo in Csla 3.8

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


Patrick.Roeper posted on Friday, January 29, 2010

I am having some trouble with an object model that resembles this. Basically, if I new up an instance of "B" on the client, and inspect the Id property, I get a System.TypeInitializationException; the same happens if I use the immediate window to check the value. However, if I check the value through code (e.g. Debug.WriteLine(b.Id)) I do not get the exception.

I suspected this has something to do with the static property initialization that has been mentioned. I have read through the book and tried the forceInit trick on pg 249-250 but that didn't help. I have made all property info objects public (Rocky mentioned newer versions of the framework will do the forceInit for you) but this did not help.

The only thing that seems to work is to make all PropertyInfo objects on "A" non-static, and then I'm good. I'm pretty sure this comes with a performance penalty, so this isn't the route I want to take.

Suggestions?


RockfordLhotka replied on Friday, January 29, 2010

You might try putting a breakpoint in Csla.Core.FieldManager.FieldDataManager.ForceStaticFieldInit() to see if that is actually being run.

It sounds like you are using the new keyword to create your test object. That's normally a bad idea, and objects should be created using the data portal so they get properly initialized. I don't know if that's the problem, but it could be.

Patrick.Roeper replied on Friday, January 29, 2010

Creating the object via...

            var dp = new DataPortal<B>(DataPortal.ProxyModes.LocalOnly);
            dp.CreateCompleted += dp_CreateCompleted;
            dp.BeginCreate();

.. still produces the same result.

Also, FieldManager.ForceStaticFieldInit is not being invoked. Other ideas?

Regarding creation through the dataportal, assume that I always wanted to create an object locally and use initial values provided in the business object itself. Why would I want to incur the reflection costs of piping this through the dataportal? Upon a (quick) trace through the source, it looks like I just need to remember to call ValidationRules.CheckRules().

RockfordLhotka replied on Friday, January 29, 2010

I just re-read your initial post.

The problem could easily be due to the way the IDE works. The IDE may not trigger normal runtime behaviors - in fact I know it doesn't do so in many cases - because those runtime behaviors could be very widespread.

Hovering your mouse over a static field could (would) cause the initialization of all static members, and execution of the cctor. It is quite likely that this is one of those scenarios where the VS team decided it could be determental to the overall experience to have the IDE lock for an indeterminate amount of time while that code runs.

They don't know, for example, if your cctor is going to run off to the database, or execute some mock data generation algorithm - things that could take seconds or minutes. Just think how fun it would be if the IDE locked just because your mouse happened to float over the wrong field :)

Copyright (c) Marimer LLC