Refreshing the .NET Application to Read Modified Configuration Files Values

In .NET applications, we encounter two types of configuration files. One is "Web.config" which is used for configuring the settings for a Web application and the other is "App.config" used for Windows application settings.

Any changes made to the Web.config file causes a web application to restart the Application Domain. This behavior occurs by design. Unlike web applications, modifying the Application Configuration files for Windows Applications does not restart the application. The reason being that when the Windows Application runs, a new Application Domain is created for the application and it caches all the settings of the configuration file in temporary memory, and all the references to the settings will be referred to the temporary memory cache and not to the actual file.

Let us see in practice how the configuration settings are used by a Windows application and how to modify the settings at runtime without closing the application.

Create a Windows Forms application using Visual Studio 2005/2008/2010/2012 as below:

Figure: Creating a new project

Figure: Selecting Windows Forms

Now add a button control on the Windows Forms form and name it "Show Logging Flag" as below:

Figure: Adding and modifying the text of a Button Control

Check if the application configuration file is available in the project. If the application was created in Visual Studio 2012 then the application configuration file is available by default. Otherwise, add a new application configuration file.

Open the application configuration file and add the <appSettings> section as below:

<appSettings>
<add key="LoggingFlag" value="ON"/>
</appSettings>

Now add a reference to System.Configuration in your project.

Figure: Adding System.Configuration

Now add the code in the Form1.cs file to read the value from the configuration file and show it in a MessageBox as below:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.Configuration;
namespace TestAppSettingRefresh
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
MessageBox.Show(ConfigurationManager.AppSettings["LoggingFlag"].ToString());
}
}
}

Now run the application and check if the value is displayed in the MessageBox.

Figure: Showing the value read from the configuration file. Now click "OK" and do not close the application.

Go to the bin folder and open the debug folder as below:

Figure: Bin\Debug folder

If you observe the files in the folder you will find two configuration files. One is the with the naming convention ApplicationName.exe.config and the other one is ApplicationName.vhost.exe.config.

The file vhost is the hosting process and it supports the debugging and design-time expression evaluation. There is an article on this. Please go through the link here for more details. So when an application is loaded the settings are loaded into the vhost.exe.config file and application reads the values from this file and caches the settings. So if you modify any values in the ApplicationName.exe.config file when the application is running (when you press CTRL+F5) you will not see the same settings updated in the ApplicationName.vhost.exe.config unless the application is restarted.

Now let us open the file "TestAppSettingRefresh.exe.config" and modify the value to "OFF" and save the file.

Figure: Modifying the value to OFF

Now click on the button again. The value is not changed in the MessageBox and it still shows the value as "ON".

Figure: Showing value in a MessageBox

As a benefit of the doubt, let us go and change the vhost.exe.config file. By the way, check if changing the value in the exe.config file before had changed the value in vhost.exe.config file or not. Open the vhost.exe.config file now.

The value is still "ON". So, this tells us that unless the application is restarted the value will not change the value in the vhost.exe.config file.

<appSettings>
<add key="LoggingFlag" value="ON"/>
</appSettings>

Now change the value to "OFF" and click the button again to see if the value is changed now.

Figure: Changing the value to OFF

You will find that still the value is shown as "ON". So, this proves that changing the values at runtime will not refresh the application settings and the application will still have the old values. In other words, the values are cached.

Now what we are going to do is to test if the vhost.exe.config file value changes if we build the application again by reading the values from the exe.config file. Let us see that first. So, change back the value to ON in vhost.exe.config file so that we can test it now. Close and run the application again. Now the application should show the value as "OFF" when the button is clicked and also should the values in the vhost.exe.config file changes w.r.t exe.config file.

The value is shown as "OFF" and even the vhost.exe.config value is refreshed with "OFF" now:

Figure: Showing value is OFF

<appSettings>
<add key="LoggingFlag" value="OFF"/>
</appSettings>

Figure: Settings in the vhost.exe.config file

So now let us see how we can make the application to refresh itself so that it reads the modified values from the configuration file.

To do that the ConfigurationManager has a method called RefreshSection(string sectionName). This method refreshes the section specified in the method so that the application can read the changed values.

Now your code should look like the following:

Figure: Refresh Section has now been added

Now run the application again and change the value to "False" in the TestAppSettingRefresh.exe.config file first and check if the value is changed. It still shows the old value. Now open the file TestAppSettingRefresh.vhost.exe.config file and change the value to "False" and now click the button again. This time it shows "False", the modified value.

This indicates that the application compiled in debug mode reads the values from the vhost.exe.config and the mechanism to refresh the application settings value when the configuration file is modified is by calling ConfigurationManager's RefreshSection method.

Note: vhost files are there to provide support for debugging when you are running your application from Visual Studio by pressing the F5 button. If you directly go to the Bin\Debug or Bin\Release folders and click on the .exe file and then modify the configuration file, the value is refreshed as here the application is running as an exe and not from the Visual Studio.

Now go to the Bin\Debug folder and check it. Click on the file TestAppSettingRefresh.exe and now go and change the value in the TestAppSettingRefresh.exe.config file and you will see that the value is refreshed. From a practical point, we deploy the application by packaging the application using Set up projects and the Setup projects always take the .exe file and .exe.config files for packaging and there will be no vhost files.

So, in this article, we have learned how to make the Windows application read the modified values from the configuration file not from the Cache. The practical usage of this scenario is when you deploy a Windows Service into Production and programmatically modifying the configuration file value and when you want your Windows Service to pick the new values. If you do not use the RefreshSection method of the ConfigurationManager, you have to restart your Windows Service to pick up the modified values.

Hope you liked this article. In the next article, we will discuss how to modify the configuration values programmatically so that our application picks up the modified values.

8 Comments

Join the conversation! Your thoughts help the community grow.

Adam Kucharski9y ago
Hah! Thanks a LOT! Your article clarified something probably very obvious to some yet I didn't get it until now, thanks again:>
Jaideep Singh10y ago
How to do the same post release
Yaduveer Saini11y ago
Great work
Abhishek Bhat12y ago
Good article...basic but still clarified lot of my misconceptions.
Akkiraju Ivaturi14y ago
Thanks guys!!!
Varesh Tuli14y ago
very knowledgeable thanks for this article..
Deepak Middha14y ago
Very nice explanation......... Thanx for posting
Richa Garg14y ago
Very well explain sir.......thanks for posting.