Possible netMF4.3 Bug With Initializing of Static Objects. Can someone else confirm my test code?

I’m using a typesafe enum pattern with my code and may have come across a netMF bug. I have some static objects that are initialized too late and shouldn’t be. Can someone else try this code to confirm?

using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;


namespace MyBug
{
    public class Program
    {
        static MyDeviceSetting Settings;

        public static void Main()
        {
            while(true)
            {
                Debug.Print(MyDeviceSetting.BLAH.Name);
                Debug.Print(MyDeviceSetting.TempUnits.Name);
            }


        }

    }

    public class MyDeviceSetting //parent
    {
        public readonly string Name;
        public MyUnit SettingUnit;
        public readonly MyUnit.UnitPurpose UnitPurpose;

        #region MY STATIC SETTINGS
        //UNIT SETTINGS
        public static MyDeviceSetting TempUnits = new MyDeviceSetting("TempUnits", MyUnit.mm);//MyUnit.mm is NULL it should not be
        public static MyDeviceSetting BLAH = new MyDeviceSetting("BLAH", MyUnit.inch);//MyUnit.Inch is NULL it should not be.
        #endregion



        /// <summary>
        /// This is the MAIN PRIVATE Constructor
        /// </summary>
        /// <param name="?"></param>
        private MyDeviceSetting(string name, MyUnit defaultUnit)
        {
            Name = name;
            SettingUnit = defaultUnit;//NULL <- passed in as null because it won't initialize
            UnitPurpose = SettingUnit.Purpose; //fails because SettingUnit is NULL


        }


    }


    public sealed class MyUnit
    {
        private static int Count = 0;

        //these are used to store and identify the unit in memory
        public readonly int UnitID;
        public readonly int TestID;

        public enum UnitPurpose
        {
            DISTANCE,
            SPEED,
            TEMPERATURE,
            TIME,
            CLOCK,
            NO_UNITS
        }

        public readonly string DisplayName;
        public readonly string Abbreviation;
        public readonly string Name;
        public readonly UnitPurpose Purpose;

        #region My Units
        public static readonly MyUnit mm = new MyUnit("Milimeters", "mm", "mm", UnitPurpose.DISTANCE, 1);
        public static readonly MyUnit inch = new MyUnit("inch", "inch", "in", UnitPurpose.DISTANCE, 2);



        #endregion

        private MyUnit(string name,
                       string displayName,
                       string abbreviation,
                       UnitPurpose unitPurpose,
                       int unitID)
        {
            Name = name;
            DisplayName = displayName;
            Abbreviation = abbreviation;
            Purpose = unitPurpose;
            UnitID = unitID;
            TestID = Count;
            Count++;

        }
    }
}

@ Gismofx - I dont understand your problem, please tell us what you expect, and what happens…

Have you tested it on the emulator?

@ Gus I’ve never tried the emulator…I’m not sure how to start that.

@ njbuch MyDeviceSetting Class/objects rely on the static members of MyUnit class. The static members of MyUnit class need to be initialized before static members of MyDeviceSetting class are initialized. So, In my example, a NULL reference is passed into the constructor causing an error. .NET should know the dependencies and initialize MyUnit on demand before…It turns out, this is some type of limitation in netMF.

That being said, I did uncover some type of hack workaround. They seem to initialize by alphabetical order of class name, to renaming MyUnit to MyAUnit caused the static members to initialize first.

Also, please check out this thread I made here:

[url]Microsoft Learn: Build skills that open doors in your career

@ Gismofx - By relying on the discovered ordering trick, you are relying on an unspec’d behavior that is very likely to change in the future. Your program will probably break again in future versions of the netmf core. It would be better to be more explicit about forcing initialization in the correct order as suggested in some of the stackoverflow thread. Unless you never plan to touch this code again (and even then), use init calls or dummy refs instead of compiler tricks.

Im new to .net mf but very experienced with .net. The op raises an important question - is there a comprehensive list of what isnt supported ? Initialization of static items is done by the CLR not the framework , so this is TinyCLR issue, is there a list of limitations?

OMG… Today I get this bug in my program.

This is a known problem, that fixed in Verison 5.0 of .Net specifications (c# 4.0) - see the section 10.5.5.1.
Why in NetMF not changed this behavior, I don’t know.

1 Like