Develop your own blog. NET version step by step (11. Read and modify the Web. config file),. netweb. config
Read Web. config
The reading of Web. config is very special. Usually, we usually use the configuration under the deleteworker node. For example:
The corresponding code is:
= ConfigurationManager.AppSettings[“OAuth_QQ_ClientId”]; = ConfigurationManager.AppSettings[“OAuth_QQ_CallbackUrl”];= ConfigurationManager.AppSettings[“OAuth_QQ_ClientScrert”];= ConfigurationManager.AppSettings[“OAuth_Sina_ClientId”];= ConfigurationManager.AppSettings[“OAuth_Sina_ClientScrert”];= ConfigurationManager.AppSettings[“OAuth_Sina_CallbackUrl”];........
Yes. It is very simple, convenient, and clear. It can always feel a little less "Object-Oriented. It doesn't matter. What if there are dozens of hundreds? Can we consider the classification definition as follows:
<! -- Custom configuration --> <customCon> <! -- Mail configuration --> <mail mailPwd = "" mailHost = "" mailFrom = "/> <! -- Log on to QQ --> <oAuthQQ OAuth_QQ_ClientId = "" OAuth_QQ_ClientScrert = "" OAuth_QQ_CallbackUrl = "haojima.net/hi_login.html"/> <! -- Sina login --> <oAuthSina OAuth_Sina_ClientId = "" OAuth_Sina_ClientScrert = "" OAuth_Sina_CallbackUrl = "haojima.net/hi_login.html"/> </customCon>
However, you will find that the customCon editor does not recognize it because it is defined by myself. How can this problem be solved? (Declare custom tags)
Is the classification clearer? But the problem arises again. How can we read the values in the custom tag?
First: (Note: You must inherit the ConfigurationSection)
/// <Summary> /// custom configuration /// </summary> public class CustomCon: configurationSection {// <summary> // mailbox settings /// </summary> [ConfigurationProperty ("mail", IsRequired = true)] public MailElement Mail {get {return (MailElement) this ["mail"] ;}} /// <summary> // log on to qq /// </summary> [ConfigurationProperty ("oAuthQQ", IsRequired = true)] public OAuthQQElement OAuthQQ {get {return (OAuthQQElement) this ["oAuthQQ"] ;}/// <summary> /// Sina logon /// </summary> [ConfigurationProperty ("oAuthSina", IsRequired = true)] public OAuthSinaElement OAuthSina {get {return (OAuthSinaElement) this ["oAuthSina"] ;}}
Then, MailElement, OAuthQQElement, and OAuthSinaElement are defined as follows:
# Region MailElement (Mailbox) public class MailElement: ConfigurationElement {// <summary> // sender password /// </summary> [ConfigurationProperty ("mailPwd ", isRequired = true)] public string Pwd {get {return this ["mailPwd"]. toString () ;}set {this ["mailPwd"] = value ;}} /// <summary> /// SMTP email server /// </summary> [ConfigurationProperty ("mailHost", IsRequired = true)] public string Host {get {return this ["mailHost"]. toString () ;}set {this ["mailHost"] = value ;}} /// <summary> /// sender's email /// </summary> [ConfigurationProperty ("mailFrom", IsRequired = true)] public string From {get {return this ["mailFrom"]. toString () ;}set {this ["mailFrom"] = value ;}}# endregion # region OAuthQQElement (QQ) public class OAuthQQElement: ConfigurationElement {[ConfigurationProperty ("OAuth_QQ_ClientId ", isRequired = true)] public string ClientId {get {return this ["OAuth_QQ_ClientId"]. toString () ;}set {this ["OAuth_QQ_ClientId"] = value ;}} [ConfigurationProperty ("OAuth_QQ_ClientScrert", IsRequired = true)] public string ClientScrert {get {return this ["OAuth_QQ_ClientScrert"]. toString () ;}set {this ["OAuth_QQ_ClientScrert"] = value ;}} [ConfigurationProperty ("OAuth_QQ_CallbackUrl", IsRequired = true)] public string CallbackUrl {get {return this ["OAuth_QQ_CallbackUrl"]. toString () ;}set {this ["OAuth_QQ_CallbackUrl"] = value ;}}# endregion # region OAuthSinaElement (SINA) public class OAuthSinaElement: ConfigurationElement {[ConfigurationProperty ("OAuth_Sina_ClientId ", isRequired = true)] public string ClientId {get {return this ["OAuth_Sina_ClientId"]. toString () ;}set {this ["OAuth_Sina_ClientId"] = value ;}} [ConfigurationProperty ("OAuth_Sina_ClientScrert", IsRequired = true)] public string ClientScrert {get {return this ["OAuth_Sina_ClientScrert"]. toString () ;}set {this ["OAuth_Sina_ClientScrert"] = value ;}} [ConfigurationProperty ("OAuth_Sina_CallbackUrl", IsRequired = true)] public string CallbackUrl {get {return this ["OAuth_Sina_CallbackUrl"]. toString () ;}set {this ["OAuth_Sina_CallbackUrl"] = value ;}}# endregionView Code
So far, we have established a one-to-one association with config at the code level. The values are as follows:
CustomCon custom = (CustomCon) ConfigurationManager. getSection ("customCon"); var url = custom. OAuthQQ. callbackUrl; // obtain the value var id = custom. OAuthQQ. clientId; // obtain the value //,,,,,
Isn't it so cool? It feels more "object" than the original deletemetadata. In addition, when you configure too many configurations, the classification is clearer!
Write Web. config
The write requirements for Web. config are usually very small, and most of them are only read. So why do I want to write data here? Many people asked me "where is the database of this blog system ?", "Coder first generates a database based on the code" is explained every time. After that, the number of times is too high. Consider whether you can make a boot page and prompt you to set up the database and mailbox when you use it for the first time (this lowers the threshold for building your own blog system for people without programming basics ).
When you start the program for the first time, check the database connection. If you do not start the program, go to the boot page and set it. (You do not need to edit the Web. config file in this process)
Now, let's continue to see how data is written to the Web. config file.
In fact, it is very simple. Just change the above Code:
You can edit the code by reading the Code through WebConfigurationManager. OpenWebConfiguration. However, do not forget to update config. Save (); To Web. config.
Only custom node data can be modified here. The most important thing is to update the database connection. Please refer to the following operations for database connection:
/// <Summary> /// modify the database connection /// </summary> /// <param name = "key"> </param> /// <param name = "connectionString"> </param> // <param name = "providerName"> </param> public static void SetConnectionString (string key, string connectionString, string providerName = "System. data. sqlClient ") {ConnectionStringsSection connectionSetting = (ConnectionStringsSection) config. getSection ("connectionStrings"); if (connectionSetting. connectionStrings [key] = null) // if this node does not exist, add {ConnectionStringSettings connectionStringSettings = new ConnectionStringSettings (key, connectionString, providerName); connectionSetting. connectionStrings. add (connectionStringSettings);} else // if this node exists, modify {connectionSetting. connectionStrings [key]. connectionString = connectionString; connectionSetting. connectionStrings [key]. providerName = providerName;} config. save ();}
In fact, it is similar to the code above. (Just changed our custom class to the ConnectionStringsSection. net default connection object)
Well, all of the above are nonsense.
The main idea is to give full play to everyone. Thank you for reading this article. I hope it will be helpful to you!
Article head: http://www.cnblogs.com/zhaopei/p/5677053.html