FrameworkBootstrapper() static constructor

Jul 19, 2011 at 10:25 PM

Hi,
I usually start Caliburn.Micro logging in a static constructor in my AppBootstrapper(), following advice from http://buksbaum.us/2011/07/04/introducing-caliburn-micro-logging/, so that logging starts early in the initialisation, especially if CM gets started in App.xaml.

However you have a static constructor in FrameworkBootstrapper(), which is masked if I have one in AppBootstrapper()
(unless you know of a way to overcome this)

I can work round this with a logging starter in xaml, but would like your thoughts

thanks

John

Coordinator
Jul 20, 2011 at 4:41 AM

What makes you think that the static constructor in a derived class masks the static constructor in the base class? All static constructors get called all the way up the hierarchy. The thing is they are non-deterministic and you can't call them explicitly with base() or this(). Also, what's pretty annoying is you can't debug them in Visual Studio. VS doesn't step into static constructors. Supposedly usability studies showed that developers were confused because of the non-deterministic characteristics of the static constructors.

Jul 20, 2011 at 8:10 AM

Hi,
I'm debugging design-time using another copy of VS2010 attached as a debugger. Break points are being responded to in a robust way, and whereas I am aways wary of debugger actions, I've no reason to suspect the break points were being missed. Place a break point in each static constructor and only the Appbootstrapper() one gets acted apon. Remove the Appbootstrapper static constructor, and Framework one gets acted apon.
OK, I'll place some code in them to check further
J

Coordinator
Jul 20, 2011 at 8:32 AM

This is exactly the problem with the non-deterministic nature of static constructors. You can't control when they get called and they can get called before the debugger takes hold. Sounds like if you attach another VS instance as a debugger it does attempt to step into the static constructors, but very unpredictable as you can see. Also, I've only tried it out with Silverlight. I wouldn't be surprised if the debugger behaves different with WPF.

 

 

Coordinator
Jul 20, 2011 at 9:06 AM

Here's a simple unit test to demonstrate that the base ctor is indeed called.

using Microsoft.VisualStudio.TestTools.UnitTesting;
 
namespace StaticCtorTest
{
    public class BaseClass
    {
        public static int BaseValue;
 
        static BaseClass()
        {
            BaseValue = 10;
        }
    }
 
    public class DerivedClass : BaseClass
    {
        public static int DerivedValue;
 
        static DerivedClass()
        {
            DerivedValue = 20;
        }
    }
 
    [TestClass]
    public class CtorTest
    {
        [TestMethod]
        public void ShouldCallBaseStaticCtor()
        {
            Assert.IsTrue(DerivedClass.BaseValue == 10, "Base static ctor should have initialize BaseValue");
            Assert.IsTrue(DerivedClass.DerivedValue == 20,
                          "DerivedClass static ctor should have initialized DerivedValue");
        }
    }
}