This project is read-only.

Blog Engine .NET Loading of configuration settings

Topics: ASP.NET 2.0, Business Logic Layer
Jul 18, 2010 at 8:30 AM


I am debugging Blog Engine .NET to see how everything fits together. I am specifically trying to understand the singleton that they are using. I am debugging right from the beginning. I am trying to find the entry point where the configuration settings are read from the XML file.

Basically what is happening is it reads a whole lot of configuration values from a XML file. The name of the singleton class is BlogSetting.cs, and there is an instance method called Instance. I searched the whole solution where this object is used, and set breakpoints on ALL of them. So when ever I get to BlogSettings.Instance()... then it seems that it was already set, all the value properties. I'm not understanding this.

Has any one had the same issue, can anyone explain this to me?

Also, any idea why a singleton was used for this?


Jul 18, 2010 at 12:28 PM

The very first time BlogSettings.Instance is accessed, you can see in BlogSettings.cs that the "Instance" getter check to see if blogSettingsSingleton is null, and if so, it assigns a new BlogSettings() instance to blogSettingsSingleton.

if (blogSettingsSingleton == null)
	blogSettingsSingleton = new BlogSettings();
When "new BlogSettings()" occurs, the private constructor runs (a few lines above)

private BlogSettings()

The Load() function looks like this:

private void Load()
It loads the data from the data store (XML or DB) and assigns the settings to the various properties of the BlogSettings class.  These values are getting assigned to the blogSettingsSingleton instance.

A Singleton is used to enforce the fact that there is only one set of settings for the blog, and to prevent another instance of BlogSettings from being created which isn't needed.

Jul 18, 2010 at 12:36 PM


I understand that.  I set breakpoints everywhere in the solution where the word BlogSettings occurs.  But my breakpoints are not being hit.  It seems to load the values but not going into blog settings.  There is a breakpoint on Load(); in the BlogSettings constructor.  This is probably not possible.  So I commented out the Utils.LoadExtensions(); in the global.ascx to see if I can see how it sets the values from a different call.


Jul 18, 2010 at 12:37 PM

Do breakpoints anywhere else in the project get hit?  Maybe you're in Release mode, and not Debug mode?  Just guessing...

Jul 18, 2010 at 12:46 PM

Yes they do get hit, because I have one in the global.asax, this seems to be the first entry point into the application.  Sometimes it goes into blogSettingsSingleton = new BlogSettings();, other times it seems to have been created already.

I am in debug mode.

Jul 18, 2010 at 1:05 PM

This is what I am doing.  I have set breakpoints all over where the word BlogSettings have appeared.  I have set another breakpoint in the global.asax's Application_Start method.  There is a single call Utils.LoadExtensions();  I set another breakpoint here.  I tun the web app.  When this breakpoint is hit then I go to the Immediate Window and type in something like BlogSettings.Instance.SmtpServerPort just to see the values so far.  I hover over the word BlogSettings and expand it.  Then I hover over the Instance property, and expand it.  And then all the properties seem to have been set already.  Why is this.  My breakpoint at blogSettingsSingleton = new BlogSettings(); has even been hit yet.

Any ideas why this is happening?  Do I need to clear cache or something?

Jul 18, 2010 at 5:06 PM

What I also noticed was that the values that were being set comes from some where else.  I set it in the web.config to use my database.  There is a property called AdministratorRole, and it is set to Administrators.  I went and changed this setting in the database to something else, and in the settings.xml I changed it.  But still it is being set as Administrators.  Where does it get these values from?  Am I missing something here??

I am using Visual Studio 2010 and I am running on Windows Vista Business.

I hope someone can help.

Jul 18, 2010 at 11:50 PM

Not sure if it will help, but you can try doing a Rebuild Solution under the Build menu.  Sometimes this can help if there's some type of older build data either cached or in the Temporary ASP.NET Files folder.

The AdministratorRole property is controlled by the "BlogEngine.AdminRole" appSetting in the web.config file.  The AdministratorRole property is a read-only property in BlogSettings.cs.

public string AdministratorRole
	get { return ConfigurationManager.AppSettings["BlogEngine.AdminRole"] ?? "administrators"; }
This property appears in the Settings.xml file (and in the DB settings table too) just because when blog settings are saved to the data store, the BE code dynamically stores all the properties of the BlogSettings class -- even if they are read-only.  So even though the AdministratorRole is stored to the data store, the value is not actually read-back in when BlogSettings gets populated with data (because it's a read-only property).

Jul 20, 2010 at 12:19 PM

Nope I'm not winning here.  Whenever it goes to do the following check then the blogSettingsSingleton variable has already been instantiated (I can't seem where???), I've even changed some of the values in the settings.xml and in the setting table, but they are not read into the BlogSettings's properties:

if (blogSettingsSingleton == null)
 blogSettingsSingleton = new BlogSettings();
return blogSettingsSingleton;

I'm starting to get annoyed now because I'm not winning here :(  When is the blogSettingsSingleton variable set the first time?  From what method?  I have breakpoints all over, and not one of them are hit.  I also want to know do the instance variables get set if I am only at the first call into the website in the global.asax:

void Application_Start(object sender, EventArgs e)

This is the first entry into the website??

Is there none of the blog engine's developers that can help me here?

Jul 20, 2010 at 1:04 PM

If you make manual changes to the Settings.xml file or the DB table, BE won't use (or see) those changes until the next time the blog is re-started.  BE reads in the settings when the BE application first starts, and keeps those settings cached in memory.  So if you make a manual change to one of those files, you should restart the blog for the changes to take effect.  You can restart the blog by making any change to the web.config file (add a space, etc).