This problem occurs when you write Windows Services in the previous stage. When writing to get a configuration value of the configuration file, I usually write a static method like the following to get it:
1:/// <Summary>
2:/// Obtain the number of records processed each time
3:/// </Summary>
4:/// <Returns> </returns>
5:Private Static IntGetrecordcount ()
6:{
7:IntRecordcount = 10000;
8:Try
9:{
10:Recordcount = math. Abs (Int. Parse (configurationmanager. receivettings ["Recordcount"]);
11:If(Recordcount = 0)
12:{
13:Recordcount = 10000;
14:}
15:}
16:Catch
17:{
18:Recordcount = 10000;
19:}
20:ReturnRecordcount;
21:}
Recordcount indicates the number of records read from the database each time. This parameter was changed several times during the test after the service was installed. At first, the default value was 10000, and then it was changed to 500,100, 50, and 10 respectively. However, after the change, I had to restart the service to make the configuration file take effect. After several such ups and downs, I feel that the experience is too bad. I searched online and found this article: Do you have to restart a Windows service if you change the app. config? In the original question, a buddy gave an answer through configurationmanager.RefreshsectionTo refresh a configuration node, we do not need to restart the service when getting the configuration value:
/// <Summary> /// Obtain the number of records processed each time /// </Summary> /// <Returns> </returns> Private Static Int Getrecordcount (){ Int Recordcount = 10000; Try {Configurationmanager. refreshsection ( "Appsettings" ); // Refresh the naming section and read it from the disk the next time you retrieve it. Recordcount = math. Abs ( Int . Parse (configurationmanager. receivettings [ "Recordcount" ]); If (Recordcount = 0) {recordcount = 10000 ;}} Catch {Recordcount = 10000 ;} Return Recordcount ;}
This is true after testing.
You may ask why you can add the configurationmanager. refreshsection (named node?
Check msdn to explain the following:"Refresh the naming Section so that it will be re-read from the disk the next time it is retrieved". The Function Description in vs is as follows:
// // summary: // refresh the naming Section so that it will be reread from the disk the next time it is retrieved. // // parameters: // sectionname: // The configuration section name or configuration path and section name of the section to be refreshed. Public static void refreshsection ( string sectionname );
It turns out that after the configuration file is changed, the applicationProgramThe order in which the configuration is read is not from a physical file, but from its cache (configurationmanager. the refreshsection method invalidates the cache of the specified configuration section without affecting other sections. You must force refresh the configuration file to read the changed configuration section information.
There is no doubt that, compared with the normal method of reading the configuration file node, this method of reading the configuration should have a slight impact on the performance. As for the loss, will it cause a performance bottleneck, you know.
finally, we can see from the msdn example that this method is very effective for dynamic write/read configuration files. However, this method may not be suitable for Web applications, because you know that modifying web. config is equivalent to restarting web applications.