Question

My App was running fine when I started it from inside Visual Studio with the debugger attached (F5). But when I started the App without attaching the debugger (Ctrl-F5 or starting the .exe file) i did always get a StackOverflowException which was luckily logged in the Windows event logs.

The problematic code was the following:

namespace Caliburn.Micro.Contrib
{
    public static class FrameworkExtensions
    {
        public static class ViewLocator
        {
            static readonly Func<string,object, IEnumerable<string>> _baseTransformName = Micro.ViewLocator.TransformName;

            public static void EnableContextFallback()
            {
                Caliburn.Micro.ViewLocator.TransformName = FallbackNameTransform;
            }    

            static IEnumerable<string> FallbackNameTransform(string typeName, object context)
            {
                var names = _baseTransformName(typeName, context);
                if (context != null)
                {
                    names = names.Union(_baseTransformName(typeName, null));
                }

                return names;
            }
        }
    }
}

I called the FrameworkExtensions.EnableContextFallack() method during the App startup and the StackOverflowException occured during the first invocation of Caliburn.Micro.ViewLocator.TransformName. This means that the _baseTransformName variable is initialized after EnableContextFallback() was called when no debugger is attached and before EnableContextFallback() is called when a debugger is attached.

Is was able to fix the bug by adding a static constructor and assign the variable in the constructor

namespace Caliburn.Micro.Contrib
{
    public static class FrameworkExtensions
    {
        public static class ViewLocator
        {
            static readonly Func<string, object, IEnumerable<string>> _baseTransformName;

            static ViewLocator()
            {
                 _baseTransformName = Micro.ViewLocator.TransformName;
            }

            public static void EnableContextFallback()
            {
                Caliburn.Micro.ViewLocator.TransformName = FallbackNameTransform;
            }    

            static IEnumerable<string> FallbackNameTransform(string typeName, object context)
            {
                var names = _baseTransformName(typeName, context);
                if (context != null)
                {
                    names = names.Union(_baseTransformName(typeName, null));
                }

                return names;
            }
        }
    }
}

This ensures that the variable _baseTransformName is always set before the first invocation of EnableContextFallback().

So the question is: Why is there a different initialization behavior for static variables when a debugger is attached and is there a way to “disable” the different behavior?

cheers

Answer 1

So the question is: Why is there a different initialization behavior for static variables when a debugger is attached and is there a way to “disable” the different behavior?

Very little is guaranteed about the behaviour of static variable initializers when there’s no static constructor. Indeed, you can even create instances of classes without the static variable initializers being invoked! When you’re using a debugger, the CLR does all kinds of things differently (particularly around JITting).

Using a static constructor is probably the best way of giving you more predictable initialization behaviour.

See my blog post about type initialization changes in .NET 4 for more information.