web.config详解,app_code和bin文件夹

在开发中经常会遇到这样的情况,在部署程序时为了保密起见并不将源代码随项目一同发布,而我们开发时的环境与部署环境可能不一致(比如数据库不一样),如果在代码中保存这些配置这些信息部署时需要到用户那里更改代码再重新编译,这种部署方式非常麻烦。 在.net 中提供了一种便捷的保存项目配置信息的办法,那就是利用配置文件,配置文件的文件后缀一般是.config,在asp.net中配置文件名一般默认是 web.config。每个web.config文件都是基于XML的文本文件,并且可以保存到Web应用程序中的任何目录中。在发布Web应用程序时 web.config文件并不编译进dll文件中。如果将来客户端发生了变化,仅仅需要用记事本打开web.config文件编辑相关设置就可以重新正常 使用,非常方便。 本篇要讲述的知识如下: 配置文件的查找优先级

配置文件节点说明 配置文件的操作

配置文件的查找优先级 在.net提供了一个针对当前机器的配置文件,这个文件是 machine.config,它位于%windir%/Microsoft.NET/Framework/v2.0.50727/CONFIG/文件下 (%windir%是系统分区下的系统目录,在命令行模式下输入%windir%然后回车就能查看当前机器的系统目录,在Windows2003及 WindowsXP中%windir%是系统分区下的windows目录,在Windows2000中%windir%是系统分区下的WinNT目录,在 笔者机器上这个系统目录是C:/WINDOWS)。这个文件里面定义了针对当前机器的WinForm程序和asp.net应用程序的配置。下面是 machine.config文件的内容: web.config详解,app_code和bin文件夹_第1张图片  在这个文件夹下还有一个web.config文件,这个文件包含了asp.net网站的常用配置。下面是这个web.config文件的内容: web.config详解,app_code和bin文件夹_第2张图片  asp.net网站IIS启动的时候会加载配置文件中的配置信息,然后缓存这些信息,这样就不必每次去读取配置信息。在运行过程中asp.net应用程序会监视配置文件的变化情况,一旦编辑了这些配置信息,就会重新读取这些配置信息并缓存。 当我们要读取某个节点或者节点组信息时,是按照如下方式搜索的: (1)如果在当前页面所在目录下存在web.config文件,查看是否存在所要查找的结点名称,如果存在返回结果并停止查找。 (2)如果当前页面所在目录下不存在web.config文件或者web.config文件中不存在该结点名,则查找它的上级目录,直到网站的根目录。 (3)如果网站根目录下不存在web.config文件或者web.config文件中不存在该节点名则在%windir%/Microsoft.NET/Framework/v2.0.50727/CONFIG/web.config文件中查找。 (4) 如果在%windir%/Microsoft.NET/Framework/v2.0.50727/CONFIG/web.config文件中不存在相应 结点,则在%windir%/Microsoft.NET/Framework/v2.0.50727/CONFIG/machine.config文件 中查找。 (5)如果仍然没有找到则返回null。 所以如果我们对某个网站或者某个文件夹有特定要求的配置,可以在相应的文件夹下创建一个 web.config文件,覆盖掉上级文件夹中的web.config文件中的同名配置即可。这些配置信息的寻找只查找一次,以后便被缓存起来供后来的调 用。在asp.net应用程序运行过程中,如果web.config文件发生更改就会导致相应的应用程序重新启动,这时存储在服务器内存中的用户会话信息 就会丢失(如存储在内存中的Session)。一些软件(如杀毒软件)每次完成对web.config的访问时就会修改web.config的访问时间属 性,也会导致asp.net应用程序的重启。

 

配置文件节点说明 web.config文件是一个XML文件,它的根结点 是<configuration>,在<configuration>节点下的常见子节点 有:<configSections>、<appSettings>、<connectionStrings> 和<system.web>。其中<appSettings>节点主要用于配置一些网站的应用配置信息, 而<connectionStrings>节点主要用于配置网站的数据库连接字符串信息。 <system.web>节点主要是网站运行时的一些配置,它的常见节点有如下: <appSettings>节点 <appSettings>节点主要用来存储asp.net应用程序的一些配置信息,比如上传文件的保存路径等,以下是一个例子:

  1. <appSettings>
  2.     <!--允许上传的图片格式类型-->
  3.     <add key="ImageType" value=".jpg;.bmp;.gif;.png;.jpeg"/>
  4.     <!--允许上传的文件类型-->
  5.     <add key="FileType" value=".jpg;.bmp;.gif;.png;.jpeg;.pdf;.zip;.rar;.xls;.doc"/>
  6. </appSettings>

对于<appSettings>节点中的值可以按照key来进行访问,以下就是一个读取key值为“FileType”节点值的例子:

  1. string fileType=ConfigurationManager.AppSettings["FileType "];

<connectionStrings>节点 <connectionStrings> 节点主要用于配置数据库连接的,我们可以<connectionStrings>节点中增加任意个节点来保存数据库连接字符串,将来在代码中 通过代码的方式动态获取节点的值来实例化数据库连接对象,这样一旦部署的时候数据库连接信息发生变化我们仅需要更改此处的配置即可,而不必因为数据库连接 信息的变化而需要改动程序代码和重新部署。 以下就是一个<connectionStrings>节点配置的例子:

  1. <connectionStrings>
  2.     <!--SQL Server数据库配置-->
  3.     <add name="AspNetStudyConnectionString1" connectionString="Data Source=(local);Initial Catalog=AspNetStudy;User ID=sa;Password=sa"/>
  4. </connectionStrings>

在代码中我们可以这么实例化数据库连接对象:

  1. //读取web.config节点配置
  2. string connectionString = ConfigurationManager.ConnectionStrings["AspNetStudyConnectionString1"].ConnectionString;
  3. //实例化SqlConnection对象
  4. SqlConnection connection = new SqlConnection(connectionString);

这样做的好处是一旦开发时所用的数据库和部署时的数据库不一致,仅仅需要用记事本之类的文本编辑工具编辑connectionString属性的值就行了。

 

<compilation>节点 <compilation>节点配置 ASP.NET 使用的所有编译设置。默认的debug属性为“true”,即允许调试,在这种情况下会影响网站的性能,所以在程序编译完成交付使用之后应将其设为“false”。

 

<authentication>节点 设置asp.net身份验证模式,有四种身份验证模式,它们的值分别如下: Mode 说明 Windows 使用Windows身份验证,适用于域用户或者局域网用户。 Forms 使用表单验证,依靠网站开发人员进行身份验证。 Passport 使用微软提供的身份验证服务进行身份验证。 None 不进行任何身份验证。

 

<authentication>节点 <authentication>节点控制用户对网站、目录或者单独页的访问,必须配合<authentication>节点一起使用。

 

<customErrors>节点 <customErrors>节点用于定义 一些自定义错误信息的信息。此节点有Mode和defaultRedirect两个属性,其中defaultRedirect属性是一个可选属性,表示应 用程序发生错误时重定向到的默认URL,如果没有指定该属性则显示一般性错误。Mode属性是一个必选属性,它有三个可能值,它们所代表的意义分别如下: Mode 说明 On 表示在本地和远程用户都会看到自定义错误信息。 Off 禁用自定义错误信息,本地和远程用户都会看到详细的错误信息。 RemoteOnly 表示本地用户将看到详细错误信息,而远程用户将会看到自定义错误信息。 这 里有必要说明一下本地用户和远程用户的概念。当我们访问asp.net应用程时所使用的机器和发布asp.net应用程序所使用的机器为同一台机器时成为 本地用户,反之则称之为远程用户。在开发调试阶段为了便于查找错误Mode属性建议设置为Off,而在部署阶段应将Mode属性设置为On或者 RemoteOnly,以避免这些详细的错误信息暴露了程序代码细节从而引来黑客的入侵。 下面我们添加一个页面CustomErrorsDemo.aspx,在它的Page_Load事件里抛出一个异常,代码如下:

 

  1. using System;
  2. using System.Data;
  3. using System.Configuration;
  4. using System.Collections;
  5. using System.Web;
  6. using System.Web.Security;
  7. using System.Web.UI;
  8. using System.Web.UI.WebControls;
  9. using System.Web.UI.WebControls.WebParts;
  10. using System.Web.UI.HtmlControls;
  11. public partial class CustomErrorsDemo : System.Web.UI.Page
  12. {
  13.     protected void Page_Load(object sender, EventArgs e)
  14.     {
  15.         throw new Exception("故意抛出的异常。");
  16.     }
  17. }

我们先配置<customErrors>如下:

  1. <customErrors mode="RemoteOnly">
  2.      <error statusCode="403" redirect="NoAccess.htm" />
  3.      <error statusCode="404" redirect="FileNotFound.htm" />
  4. </customErrors>

这时本地运行CustomErrorsDemo.aspx的效果如下: web.config详解,app_code和bin文件夹_第3张图片  远程访问时看到的效果: web.config详解,app_code和bin文件夹_第4张图片  如果我们将customErrors的Mode属性设置为“On”本地运行和远程访问都会看到如下效果: web.config详解,app_code和bin文件夹_第5张图片  如果将customErrors的Mode属性设置为“Off”本地运行和远程访问都会看到如下效果: web.config详解,app_code和bin文件夹_第6张图片 

<error>子节点 在<customErrors>节点下还包含 有<error>子节点,这个节点主要是根据服务器的HTTP错误状态代码而重定向到我们自定义的错误页面,注意要 使<error>子节点下的配置生效,必须将<customErrors>节点节点的Mode属性设置为“On”。下面是一个例 子:

  1. <customErrors mode="On" defaultRedirect="GenericErrorPage.htm">
  2.      <error statusCode="403" redirect="403.htm" />
  3.      <error statusCode="404" redirect="404.htm" />
  4. </customErrors>

在上面的配置中如果用户访问的页面不存在就会跳转到404.htm页面,如果用户没有权限访问请求的页面则会跳转到403.htm页面,403.htm和404.htm页面都是我们自己添加的页面,我们可以在页面中给出友好的错误提示。

 

<httpHandlers>节点 <httpHandlers>节点用于根据用户请求的URL和HTTP谓词将用户的请求交给相应的处理程序。可以在配置级别的任何层次配置此节点,也就是说可以针对某个特定目录下指定的特殊文件进行特殊处理。

下面是与machine.config文件同一目录下的web.config文件中的<httpHandlers>节点配置:

 

  1. <httpHandlers>
  2.             <add path="*.rules" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  3.             <add path="*.xoml" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>
  4.             <add path="trace.axd" verb="*" type="System.Web.Handlers.TraceHandler" validate="true"/>
  5.             <add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="true"/>
  6.             <add path="*.axd" verb="*" type="System.Web.HttpNotFoundHandler" validate="true"/>
  7.             <add path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory" validate="true"/>
  8.             <add path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" validate="true"/>
  9.             <add path="*.asmx" verb="*" type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" validate="false"/>
  10.             <add path="*.rem" verb="*" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>
  11.             <add path="*.soap" verb="*" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>
  12.             <add path="*.asax" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  13.             <add path="*.ascx" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  14.             <add path="*.master" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  15.             <add path="*.skin" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  16.             <add path="*.browser" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  17.             <add path="*.sitemap" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  18.             <add path="*.dll.config" verb="GET,HEAD" type="System.Web.StaticFileHandler" validate="true"/>
  19.             <add path="*.exe.config" verb="GET,HEAD" type="System.Web.StaticFileHandler" validate="true"/>
  20.             <add path="*.config" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  21.             <add path="*.cs" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  22.             <add path="*.csproj" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  23.             <add path="*.vb" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  24.             <add path="*.vbproj" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  25.             <add path="*.webinfo" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  26.             <add path="*.licx" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  27.             <add path="*.resx" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  28.             <add path="*.resources" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  29.             <add path="*.mdb" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  30.             <add path="*.vjsproj" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  31.             <add path="*.java" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  32.             <add path="*.jsl" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  33.             <add path="*.ldb" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  34.             <add path="*.ad" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  35.             <add path="*.dd" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  36.             <add path="*.ldd" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  37.             <add path="*.sd" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  38.             <add path="*.cd" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  39.             <add path="*.adprototype" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  40.             <add path="*.lddprototype" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  41.             <add path="*.sdm" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  42.             <add path="*.sdmDocument" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  43.             <add path="*.mdf" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  44.             <add path="*.ldf" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  45.             <add path="*.exclude" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  46.             <add path="*.refresh" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
  47.             <add path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>
  48.             <add path="*" verb="GET,HEAD,POST" type="System.Web.DefaultHttpHandler" validate="true"/>
  49.             <add path="*" verb="*" type="System.Web.HttpMethodNotAllowedHandler" validate="true"/>
  50.         </httpHandlers>

从上面的配置中可以看出,针对*.mdf、*.ldf文件的Get或者Post请求都会交给 System.Web.HttpForbiddenHandler来处理,处理的结果就是用户不能查看或者下载相关的文件。如果我们某个文件夹下的文件或 者某个类型的文件不允许用户下载,可以在</httpHandlers>节点中增加相应的子节点。 下面我们以一个例子来说明<httpHandlers>节点的用法,在我们的asp.net应用程序中建立一个IPData目录,在IPData目录中创建一个IPData.txt文件,然后在Web.config中添加以下配置:

 

  1. <httpHandlers>
  2.       <add path="IPData/*.txt" verb="*" type="System.Web.HttpForbiddenHandler"/>
  3. </httpHandlers>

上面的代码的作用是禁止访问IPData目录下的任何txt文件。 然后新建一个页面,在页面中添加一个超级链接,链接到该目录下IPData.txt文件,代码如下:

 

  1. <%@ Page Language="C#" AutoEventWireup="true" CodeFile="HttpHandlersDemo.aspx.cs" Inherits="HttpHandlersDemo" %>
  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  3. <html xmlns="http://www.w3.org/1999/xhtml" >
  4. <head runat="server">
  5.     <title>httpHandlers节点的例子</title>
  6. </head>
  7. <body>
  8.     <form id="form1" runat="server">
  9.     <div>
  10.     <a href="IPData/IPData.txt" title="打开IPData/IPData.txt">打开IPData/IPData.txt</a>
  11.     </div>
  12.     </form>
  13. </body>
  14. </html>

运行这个页面的效果如下: web.config详解,app_code和bin文件夹_第7张图片  当前web.config文件的<customErrors>节点配置如下: <customErrors mode="On" defaultRedirect="GenericErrorPage.htm">      <error statusCode="403" redirect="403.htm" />      <error statusCode="404" redirect="404.htm" /> </customErrors> 如果存在403.htm和404.htm页面,点击超级链接之后会出现如下效果: web.config详解,app_code和bin文件夹_第8张图片  我们从上图中可以看到当<customErrors>节点的Mode属性为“On”时,因为被禁止访问IPData文件夹下的所有txt文件,所以会跳转到自定义的没有权限提示页面,即403.htm。

 

<httpRuntime>节点 <httpRuntime>节点用于对 ASP.NET HTTP 运行库设置。该节可以在计算机、站点、应用程序和子目录级别声明。 例如下面的配置控制用户最大能上传的文件为40M(40*1024K),最大超时时间为60秒,最大并发请求为100个。

  1. <httpRuntime maxRequestLength="40960" executionTimeout="60" appRequestQueueLimit="100"/>

<pages>节点 <pages>节点用于表示对特定页设置,主要有三个属性,分别如下: 属性名 说明 buffer 是否启用了 HTTP 响应缓冲。 enableViewStateMac 是否应该对页的视图状态运行计算机身份验证检查 (MAC),以放置用户篡改,默认为false,如果设置为true将会引起性能的降低。 validateRequest 是 否验证用户输入中有跨站点脚本攻击和SQL注入式漏洞攻击,默认为true,如果出现匹配情况就会发 HttpRequestValidationException 异常。对于包含有在线文本编辑器页面一般自行验证用户输入而将此属性设为false。 下面就是一个配置节点的例子:

  1. <pages buffer="true" enableViewStateMac="true" validateRequest="false"/>

<sessionState>节点 <sessionState>节点用于配置当前asp.net应用程序的会话状态配置。以下就是一个常见配置:

  1. <sessionState cookieless="false" mode="InProc" timeout="30" />

上面的节点配置是设置在asp.net应用程序中启用Cookie,并且指定会话状态模式为在进程中保存会话状态,同时还指定了会话超时为30分钟。 <sessionState>节点的Mode属性可以是以下几种值之一: 属性值 说明 Custom 使用自定义数据来存储会话状态数据。 InProc 默认值。由asp.net辅助进程来存储会话状态数据。 Off 禁用会话状态。 SQLServer 使用进程外SQL Server数据库保存会话状态数据。 StateServer 使用进程外 ASP.NET 状态服务存储状态信息。 一般默认情况下使用InProc模式来存储会话状态数据,这种模式的好处是存取速度快,缺点是比较占用内存,所以不宜在这种模式下存储大型的用户会话数据。

<globalization>节点: 用于配置应用程序的全球化设置。此节点有几个比较重要的属性,分别如下: 属性名 说明 fileEncoding 可选属性。设置.aspx、.asmx 和 .asax 文件的存储编码。 requestEncoding 可选属性。设置客户端请求的编码,默认为UTF-8. responseEncoding 可选属性。设置服务器端响应的编码,默认为UTF-8. 以下就是asp.net应用程序中的默认配置:

  1. <globalization fileEncoding="utf-8" requestEncoding="utf-8" responseEncoding="utf-8"/>

配置文件的读写操作 虽然web.config文件是一个XML文件,但是由于权限的原因它在部署中不能像操作普通XML文件那样进行修改,在.net中提供了一个类用于对web.config进行修改。 下面是针对web.config修改通用类的代码:

 

  1. using System;
  2. using System.Configuration;
  3. using System.Web;
  4. using System.Web.Configuration;
  5. /// <summary>
  6. /// ConfigurationOperator 的摘要说明
  7. /// </summary>
  8. public class ConfigurationOperator:IDisposable
  9. {
  10.     private Configuration config;
  11.  public ConfigurationOperator():this(HttpContext.Current.Request.ApplicationPath)
  12.  {
  13.         
  14.  }
  15.     public ConfigurationOperator(string path)
  16.     {
  17.         config = WebConfigurationManager.OpenWebConfiguration(path);
  18.     }
  19.     /// <summary> 
  20.     /// 设置应用程序配置节点,如果已经存在此节点,则会修改该节点的值,否则添加此节点
  21.     /// </summary> 
  22.     /// <param name="key">节点名称</param> 
  23.     /// <param name="value">节点值</param> 
  24.     public void SetAppSetting(string key, string value)
  25.     {
  26.         AppSettingsSection appSetting = (AppSettingsSection)config.GetSection("appSettings");
  27.         if (appSetting.Settings[key] == null)//如果不存在此节点,则添加 
  28.         {
  29.             appSetting.Settings.Add(key, value);
  30.         }
  31.         else//如果存在此节点,则修改 
  32.         {
  33.             appSetting.Settings[key].Value = value;
  34.         }
  35.     }
  36.     /// <summary> 
  37.     /// 设置数据库连接字符串节点,如果不存在此节点,则会添加此节点及对应的值,存在则修改 
  38.     /// </summary> 
  39.     /// <param name="key">节点名称</param> 
  40.     /// <param name="value">节点值</param> 
  41.     public void SetConnectionString(string key, string connectionString)
  42.     {
  43.         ConnectionStringsSection connectionSetting = (ConnectionStringsSection)config.GetSection("connectionStrings");
  44.         if (connectionSetting.ConnectionStrings[key] == null)//如果不存在此节点,则添加 
  45.         {
  46.             ConnectionStringSettings connectionStringSettings = new ConnectionStringSettings(key, connectionString);
  47.             connectionSetting.ConnectionStrings.Add(connectionStringSettings);
  48.         }
  49.         else//如果存在此节点,则修改 
  50.         {
  51.             connectionSetting.ConnectionStrings[key].ConnectionString = connectionString;
  52.         }
  53.     }
  54.     /// <summary> 
  55.     /// 保存所作的修改 
  56.     /// </summary> 
  57.     public void Save()
  58.     {
  59.         config.Save();
  60.         config = null;
  61.     }
  62.     public void Dispose()
  63.     {
  64.         if (config != null)
  65.         {
  66.             config.Save();
  67.         }
  68.     }
  69. }

把上面的代码存放到App_Code文件夹下,我们在项目中就可以直接使用了。 我们通过一个例子演示如果使用这个通用类对web.config进行设置。新建一个aspx页面,下面是前台代码:

 

  1. <%@ Page Language="C#" AutoEventWireup="true" CodeFile="ConfigModifyDemo.aspx.cs" Inherits="ConfigModifyDemo" %>
  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  3. <html xmlns="http://www.w3.org/1999/xhtml" >
  4. <head runat="server">
  5.     <title>在部署后修改web.config的例子</title>
  6. </head>
  7. <body>
  8.     <form id="form1" runat="server">
  9.     <div>
  10.     <table border="0" cellpadding="0" cellspacing="0">
  11.     <tr><td>类型</td><td>名称</td><td></td></tr>
  12.     <tr><td>
  13.         程序配置</td><td>
  14.             <asp:TextBox ID="txtKey" runat="server"></asp:TextBox>
  15.             <asp:RequiredFieldValidator ID="RequiredFieldValidator2" runat="server" ControlToValidate="txtKey"
  16.                 ErrorMessage="*" Display="Dynamic"></asp:RequiredFieldValidator></td><td>
  17.         <asp:TextBox ID="txtAppSetting" runat="server"></asp:TextBox></td></tr>
  18.     <tr><td>
  19.         数据库连接</td><td>
  20.             <asp:TextBox ID="txtConnectionName" runat="server"></asp:TextBox>
  21.             <asp:RequiredFieldValidator ID="RequiredFieldValidator1" runat="server" ErrorMessage="*" ControlToValidate="txtConnectionName" Display="Dynamic"></asp:RequiredFieldValidator></td><td style="height: 24px">
  22.         <asp:TextBox ID="txtConnectionString" runat="server"></asp:TextBox></td></tr>
  23.     <tr><td>
  24.         <asp:Button ID="btnModify" runat="server" OnClick="btnModify_Click" Text="修改" /></td><td></td><td></td></tr>
  25.     </table>
  26.     </div>
  27.     </form>
  28. </body>
  29. </html>

 

编写后台代码有时可能需要增加对配置文件读写操作类所在dll的引用,如下:

 

web.config详解,app_code和bin文件夹_第9张图片下面是后台代码:

 

  1. using System;
  2. using System.Data;
  3. using System.Configuration;
  4. using System.Collections;
  5. using System.Web;
  6. using System.Web.Security;
  7. using System.Web.UI;
  8. using System.Web.UI.WebControls;
  9. using System.Web.UI.WebControls.WebParts;
  10. using System.Web.UI.HtmlControls;
  11. using System.Web.Configuration;//注意添加这个命名空间
  12. public partial class ConfigModifyDemo : System.Web.UI.Page
  13. {
  14.     protected void Page_Load(object sender, EventArgs e)
  15.     {
  16.     }
  17.     protected void btnModify_Click(object sender, EventArgs e)
  18.     {
  19.         string appSetting = txtAppSetting.Text;//appSetting子节点值
  20.         string connectionString = txtConnectionString.Text;//连接字符串
  21.         string key = txtKey.Text;//appSetting子节点Key
  22.         string connectionName = txtConnectionName.Text;//连接Name
  23.         ConfigurationOperator op = new ConfigurationOperator();
  24.         op.SetAppSetting(key, appSetting);
  25.         op.SetConnectionString(connectionName, connectionString);
  26.         op.Save();
  27.     }
  28.     
  29. }

下面是运行界面: web.config详解,app_code和bin文件夹_第10张图片  我们在上面的表单中填入如下信息: web.config详解,app_code和bin文件夹_第11张图片  假设此时web.config文件相关节点的内容如下:

  1. <appSettings>
  2.   </appSettings>
  3.   <connectionStrings>
  4.     <add name="Conn" connectionString="Data Source=(local);Initial Catalog=AspNetStudy;Persist Security Info=True;User ID=sa;Password=sa" />
  5.   </connectionStrings>

我们点击“修改”按钮之后的文件内容如下:

  1. <appSettings>
  2.     <add key="country" value="china" />
  3.   </appSettings>
  4.   <connectionStrings>
  5.     <add name="Conn" connectionString="Data Source=(local);Initial Catalog=Study;User ID=sa;Password=sa"
  6.       providerName="System.Data.SqlClient" />
  7.   </connectionStrings>

从执行结果可以看出我们的程序确实能做到修改和添加web.config中的节点的功能。需要注意的是,在利用了某些版本控制软件之后(如 Microsoft Visual SourceSafe),版本控制软件可能会将web.config设置为只读属性,就会出现不能设置的情况,我们需要手动将web.config的只读 属性去掉才能设置web.config文件。在实际部署项目的时候就不会存在这个问题。

总结:web.config是asp.net应用程序中一个很重要的配置文件,通过web.config文件可以方便我们进行开发和部署 asp.net应用程序。此外还能对程序进行一些灵活的控制。在本篇中详细讲述了各节点的作用。因为在部署asp.net应用程序后因为权限原因不能按照 XML方式进行修改web.config文件,所以在本篇中还提供了一个针对<appSettings>节点 和<connectionStrings>节点设置的通用类,读者朋友可以根据实际项目需要对这个通用类进行完善和补充。

 

asp.netapp_codebin文件夹介绍

  如果您的 Web 应用程序包括要在多个页之间共享的代码,您可以将代码保存在 Web 应用程序根目录下的两个特殊文件夹(Bin 文件夹和 App_Code 文件夹)中的某个文件夹中。

 

Bin 文件夹

      可以在 Bin 文件夹中存储编译的程序集,并且 Web 应用程序任意处的其他代码(如页代码)会自动引用该文件夹。典型的示例是您为自定义类编译好的代码。您可以将编译后的程序集复制到 Web 应用程序的 Bin 文件夹中,这样所有页都可以使用这个类。

 

Bin 文件夹中的程序集无需注册。只要 .dll 文件存在于 Bin 文件夹中,ASP.NET 就可以识别它。如果您更改了 .dll 文件,并将它的新版本写入到了 Bin 文件夹中,则 ASP.NET 会检测到更新,并对随后的新页请求使用新版本的 .dll 文件。

 

Bin 文件夹的安全性

      将编译后的程序集放入 Bin 文件夹中会带来安全风险。如果是您自己编写和编译的代码,那么您了解代码的功能。但是,您必须像对待任何可执行代码一样来对待 Bin 文件夹中已编译的代码。在完成代码测试并确信已了解代码功能之前,要对已编译的代码保持谨慎的态度。

 

请注意以下安全方面的知识,这些知识与是否将已编译的代码放入 Bin 文件夹有关:

 

Bin 文件夹中程序集的作用范围为当前应用程序。因此,它们无法访问当前 Web 应用程序之外的资源或调用当前 Web 应用程序之外的代码。

 

      运行时,程序集的访问级别由本地计算机上指定的信任级别确定。有关更多信息,请参见 ASP.NET 信任级别和策略文件。

 

如果您使用了诸如 Visual Studio 这样的设计器,那么 Bin 文件夹中的代码运行所在的上下文与运行时不同。例如,代码可能以完全信任状态运行。

 

App_Code 文件夹

      可以在 App_Code 文件夹中存储源代码,在运行时将会自动对这些代码进行编译。Web 应用程序中的其他任何代码都可以访问产生的程序集。因此,App_Code 文件夹的工作方式与 Bin 文件夹很类似,不同之处是您可以在其中存储源代码而非已编译的代码。App_Code 文件夹及其在 ASP.NET Web 应用程序中的特殊地位使您可以创建自定义类和其他仅源代码文件,并在 Web 应用程序中使用它们而不必单独对它们进行编译。

 

      App_Code 文件夹可以包含以传统类文件(即带有 .vb、.cs 等扩展名的文件)的形式编写的源代码文件。但是,它也可以包含并非明确显示出由某一特定编程语言编写的文件。例如 .wsdl(Web 服务发现语言)文件和 XML 架构 (.xsd) 文件。ASP.NET 可以将这些文件编译成程序集。

 

      根据您的需要,App_Code 文件夹可以包含任意数量的文件和子文件夹。您可以采用任何您认为方便的方式组织源代码,ASP.NET 仍会将所有代码编译成单个程序集,并且 Web 应用程序任意处的其他代码都可以访问该程序集。  

   

推断 App_Code 文件夹的编程语言

       App_Code 文件夹并未显式标记为包含以任何一种编程语言编写的文件。相反,ASP.NET 是根据 App_Code 文件夹所包含的文件来推断应为 App_Code 文件夹调用哪一种编译器。如果 App_Code 文件夹包含 .vb 文件,则 ASP.NET 使用 Visual Basic 编译器;如果包含 .cs 文件,则 ASP.NET 使用 C# 编译器,以此类推。

 

如果 App_Code 文件夹只包含并未明确表明编程语言的文件(如 .wsdl 文件),则 ASP.NET 将使用 Web 应用程序的默认编译器,默认编译器在 Web 应用程序或计算机配置文件的 compilation 元素中确定。  

   

在 App_Code 文件夹中使用多种编程语言

        因为 App_Code 文件夹中的源代码要编译成单个程序集,所以 App_Code 文件夹中的所有文件必须使用相同的编程语言编写。例如,App_Code 文件夹不能同时包含采用 Visual Basic 和 C# 编写的源代码。

 

但是,您可以对 Web 应用程序进行配置,使其将 App_Code 文件夹的子文件夹作为独立的可编译单元处理。这样,每一个文件夹就可以包含以不同编程语言编写的源代码。通过在 Web.config 文件的 codeSubDirectories 元素中创建一个 compilation 元素,然后添加一个对子文件夹的引用,即可指定该配置。下面的示例阐释如何对名为 VBCode 和 CSCode 的子文件夹进行配置,使其编译成不同的程序集:

 

复制到剪贴板<compilation debug="false">

<codeSubDirectories>

<add directoryName="VBCode" />

<add directoryName="CSCode" />

</codeSubDirectories>

</compilation>

      请注意,对 VBCode 和 CSCode 子文件夹的引用并未包括任何有关子文件夹中所包含的编程语言的信息。就像对待 App_Code 文件夹本身一样,ASP.NET 会根据子文件夹中的文件来推断要使用的编译器。  

   

App_Code 文件夹的安全性

       App_Code 文件夹中的代码存在的安全问题基本上与 Bin 文件夹中的代码存在的安全问题相同 - 代码都会在运行时编译成程序集。比 Bin 文件夹要好一些的是,您可以阅读 App_Code 文件夹中文件的源代码。但是,如果您不能完全理解代码,仍然会存在安全风险。因此,对待 App_Code 文件夹中的源代码的态度必须像对待基于同样的源代码生成的已编译代码一样谨慎。

你可能感兴趣的:(config)