class AppSettings // no need to be static - but it can of course { public static string ConnString = new SomeLongRunningProcess().GetConnString(); }http://msdn.microsoft.com/en-us/magazine/cc163857.aspx
static class AppSettings > { > public static string ConnString; public static string ConnString2; > > static AppSettings() > { > ConnString = new SomeLongRunningProcess().GetConnString(); ConnString2 = new SomeLongOtherRunningProcess().GetConnString(); > } > }I would prefer
static class AppSettings > { > public static string ConnString = new SomeLongRunningProcess().GetConnString(); public static string ConnString2 = new SomeLongOtherRunningProcess().GetConnString(); > }If there's a dependency between static fields, then it may be best to use a static constructor - just to make it clear
static class AppSettings > { > public static string ConnString; > > static AppSettings() > { > ConnString = new SomeLongRunningProcess().GetConnString(); > } > }the long running bit is guaranteed not to be called unless the ConnString value is actually required elsewhere in code. If it were a non-static class the static constructor would fire un-neccessarily the first time an instance of the class was created....