2023年11月28日发(作者：)
配置详细说明
（⼀）.是以XML⽂件规范存储,配置⽂件分为以下格式
1.配置节处理程序声明
特点：位于配置⽂件的顶部，包含在
2.特定应⽤程序配置
特点: 位于
3.配置节设置
特点: 位于<>节中，控制运⾏时的⾏为.
4.配置节组
特点: ⽤
（⼆）.配置节的每⼀节
1.
根元素，其它节都是在它的内部.
2.
此节⽤于定义应⽤程序设置项。对⼀些不确定设置，还可以让⽤户根据⾃⼰实际情况⾃⼰设置
⽤法:
I.
定义了⼀个连接字符串常量，并且在实际应⽤时可以修改连接字符串，不⽤修改程式代码.
II.
定义了⼀个错误重定向页⾯.
III.
写法为：
3.
格式:
I.
default language: 定义后台代码语⾔,可以选择C#和两种语⾔.
II.
debug : 为true时，启动aspx调试；为false不启动aspx调试，因⽽可以提⾼应⽤程序运⾏时的性能。⼀般程序员在开发时设置为
true,交给客户时设置为false.
4.
格式:
/> I. mode : 具有On,Off,RemoteOnly 3种状态。On表⽰始终显⽰⾃定义的信息; Off表⽰始终显⽰详细的错误信息; RemoteOnly表 ⽰只对不在本地Web服务器上运⾏的⽤户显⽰⾃定义信息. II. defaultRedirect: ⽤于出现错误时重定向的URL地址. 是可选的 III. III. statusCode: 指明错误状态码，表明⼀种特定的出错状态. IV. redirect:错误重定向的URL. 5. 格式: I. requestEncoding: 它⽤来检查每⼀个发来请求的编码. II. responseEncoding: ⽤于检查发回的响应内容编码. III. fileEncoding: ⽤于检查aspx,asax等⽂件解析的默认编码. 6. 格式: I. mode: 分为off,Inproc,StateServer,SqlServer⼏种状态 II. stateConnectionString :指定应⽤程序存储远程会话状态的服务器名，默认为本机 III. sqlConnectionString: 当⽤会话状态数据库时，在这⾥设置连接字符串 IV. Cookieless: 设置为true时，表⽰不使⽤cookie会话状态来标识客户； 否则，相反. V. TimeOut: ⽤来定义会话状态存储的时间，超过期限，将⾃动终⽌会话. 7. 格式: I. Windows: 使⽤IIS验证⽅式 II. Forms: 使⽤基于窗体的验证⽅式 III. Passport: 采⽤Passport cookie验证模式 IV. None: 不采⽤任何验证⽅式 ⾥⾯内嵌Forms节点的属性涵义: I. Name: 指定完成⾝份验证的Http cookie的名称. II. LoginUrl: 如果未通过验证或超时后重定向的页⾯URL，⼀般为登录页⾯，让⽤户重新登录 III. Protection: 指定 cookie数据的保护⽅式. 可设置为: All None Encryption Validation四种保护⽅式 a. All表⽰加密数据，并进⾏有效性验证两种⽅式 b. None表⽰不保护Cookie. c. Encryption表⽰对Cookie内容进⾏加密 d. validation表⽰对Cookie内容进⾏有效性验证 IV. TimeOut: 指定Cookie的失效时间. 超时后要重新登录. （2）配置段句柄说明 的配置⽂件架构并未指定任何⽂件格式或者是⽀持的配置属性。相反的，它提出了“配置段句柄申明”的概念来⽀持任意的⽤ 户定义配置段。 格式： （３）配置段 具体定义配置的内容，供应⽤使⽤。 以下例⼦定义了⼀个“httpmodules”配置段，设置了系统http相关的处理模块 4.2. 4 定义的标准配置段 （１）httpmodule 段： 定义了应⽤的http请求的处理模块以及诸如安全、⽇志之类的应⽤⽅式 （２）httphandlers 段： 负责映射URLs到IhttpHandler类 （３）sessionstat 段： 负责配置http模块的会话状态 （４）globalization 段：配置应⽤的公⽤设置 （５）compilation 段： 配置的编译环境 （６）trace 段：配置的跟踪服务 （７）security 段： 的安全配置 （８）iisprocessmodel 段： 在IIS上配置的处理模式 （９）browercaps 段： 配置浏览器的兼容部件 4.2. 5 ⼀个配置读出的例⼦ （１）配置⽂件 （２）读出其内容 中"test"配置段中key的内容为: （３）运⾏结果 4.2. 6 配置实例
<>//⼤多应⽤程序设置位于此元素下
Table 3-1.可⽤于的顶层配置元素
元素Element含义Purpose
1, 配置的四个层次
(1)机器::位于$FRAMEWORKCONFIG($FRAMEWORK⼀般是c:meworkv1.0.3705)，
是.net必须备的默认配置⽂件。
⽤来修改.net默认配置。
(2)站点:web站点根⽬录下的，影响全站配置
(3)程序:应⽤程序虚⽬录根下的，影响全虚⽬录配置
(3)⼦⽬录:虚⽬录的⼦⽬录下的，影响该⼦⽬录及其⼦⽬录下配置
Figure 3-1. Hierarchy of Configuration Files
2，通过location元素简化配置:
Listing 3-2 Using the location Element
<>
3，元素的配置规定:
authentication, sessionState, trust, 和 httpModules(即使在⽼版本.net允许在⼦⽬录中配置，也是不⽣效的)元素属于应⽤程序级别的元素，
不能配置于⼦⽬录下的 。processModel属于机器级别元素，只能⽤于。
4，元素的更改⽣效时间:
⼀般更改后，会⾃动重新加载程序，并放弃原进程的会话状态和程序状态。如果是processModel更改，只有终⽌⼯作者进程(可
⼿⼯IIS复位，可撤销aspnet_进程，也可因进程意外反弹⾃⾝)然后重新启动，才能应⽤新配置，同时放弃所有运⾏于该机器上的.net
程序状态，缓存数据和会话状态。
5,IIS与配置
如果使⽤了IIS，则IIS的安全配置等优秀于.net配置。如此可以只使⽤IIS默认配置，⽽在中具体配置。
⼆，常量配置appSettings
使⽤appSettings元素的add⼦元素的key和value属性(键值不分⼤⼩写)来存储常量设置。
Listing 3-3 Specifying Application-Specific Configuration Data
value="server=localhost;uid=sa;pwd=;database=pubs" /> 程序启动后，配置就载⼊内存，有访问权限(.net使⽤HttpForbiddenHandler来控制对., .vb, .asax, .resx⽂件的访问权限，默认下外 部程序不可访问配置⽂件)的程序就可以使⽤tings ["DSN"]的⽅式直接引⽤配置的值。 Listing 3-4 Retrieving appSettings Configuration Data <%@ Page Language='C#' %> <%@ Import Namespace='uration' %> 三，进程配置processModel 只能在中使⽤processModel，其改动只在aspnet_进程重启后⽣效，并由unmanaged (⾮托管?)的 aspnet_(ISAPI扩展dll)读取，⽽⾮象其他配置⼀样由managed mechanism(托管机制?)读取。 Table 3-2. Attributes of the processModel Element AttributeValuesDefaultDescription Enabletrue | falsetrue指定是驻留在外部⼯作者进程中(true)，还是直接在 中(false) Whether is hosted in an external worker process (true) or directly in (false) 进程的总⽣命期——超时后进程反弹Total life of a process—timeoutInfinite | HH:MM:SSInfinite process bounced after timeout 进程的总空闲期——当到达超时时间时进程反弹Total idle lifeidleTimeoutInfinite | HH:MM:SSInfinite of a process—process bounced when reached 在撤消进程之前，给予进程关闭的时间Time given to processshutdownTimeoutInfinite | HH:MM:SS0:00:05 to shut down before being killed 进程反弹之前，要服务的总需求量Total number of requestsrequestLimitInfinite | numberInfinite to serve before bouncing process 进程反弹之前．所允许的在队列中等待的请求数量requestQueueLimitInfinite | number5000 Number of queued requests allowed before bouncing process 进程重启时．在队列中等待的请求量Number of requestsrestartQueueLimitInfinite | number10 kept in queue while process is restarting 进程反弹之前．允许进程使⽤的物理内存百分数PercentagememoryLimitNumber60 of physical memory process is allowed to use before bouncing process 指定进程是否与特定CPU建⽴密切关系(对于多CPU机webGardentrue | falsefalse 器)Whether process should be affinitized with a particular CPU (for multi-CPU machines) 控制⼯作者进程所⽤的CPU数cpuMaskBitmask0xffffffff (webGarden必须为true)Controls number of CPUs available for worker processes (webGarden must be true) 运⾏⼯作者进程所需的Windows⾝份userNameSYSTEM | MACHINEMACHINE (MACHINE使⽤低特权的ASPNET账号)Windows identity to| username run the worker process in (MACHINE uses low-privileged ASPNET account) PasswordAutoGenerateAutoGenerateusername的密码Password for username logLevelAll | None | ErrorsErrors登记在事件⽇志中的事件类型Event types logged to event clientConnectedCheckHH:MM:SS0:00:05执⾏客户连接的检查前．请求保留在队列中的时间Time a | password log request is left in the queue before a client-connected check is performed DCOM的安全性⾝份验证的级别Level of authentication forcomAuthenticationLevelDefault | None | ConnectConnect DCOM security| Call | Pkt | PktIntegrity | COM的安全性⾝份验证的级别Authentication level for COMDefault | Anonymous |ImpersonatecomImpersonationLevel securityIdentify | Impersonate | 由于responseRestart-DeadlockInterval⽽重启⼯作者进程所responseRestartDeadlockIntervalInfinite | HH:MM:SS00:09:00 maxWorkerThreadsNumber线程池中每个CPU的最多⼯作者线程量 maxIoThreadsNumber25线程池中每个CPU的最多I./O线程量Maximum number of I/O serverErrorMessageFileFile name""“Server Unavailable"消息的⾃定义Customization for "Server Maximum number of I/O threads per CPU in the thread pool threads per CPU in the thread pool Unavailable" message 虽然如上有众多条件能使进程反弹，但默认下只有两个反弹条件：⼀是程序占⽤了60%以上的物理内存(该条件由memoryLimit属性来指 定)，⼆是有5000多个请求在队列中等待。常⽤的反弹条件还有明确的超时时间 (timeout),空闲超时时间(累计空闲时间idleTimeout),⼯作者进 程的服务数量上限(requestLimit)。 可以通过设置webGarden和 cpuMask来设置多cpu的使⽤⽅式 Listing 3-5 Specifying Multiple Worker Processes on a Multi-CPU machine timeout="Infinite" idleTimeout="Infinite" shutdownTimeout="0:00:05" requestLimit="Infinite" requestQueueLimit="5000" restartQueueLimit="10" memoryLimit="60" webGarden="true"//启⽤该配置后，每个cpu运⾏⼀个⼯作者进程，进程间不能共享会话状态，数据缓存，程序状态 cpuMask="0x00000007"//相当于⼆进制0...0111屏蔽，则只使⽤cpu0,cpu1,cpu2，屏蔽其他cpu userName="machine" password="AutoGenerate" logLevel="Errors" clientConnectedCheck="0:00:05" comAuthenticationLevel="Connect" comImpersonationLevel="Impersonate" responseRestartDeadlockInterval="00:09:00" responseDeadlockInterval="00:03:00" maxWorkerThreads="25" maxIoThreads="25" /> 还可以设置maxIoThreads和maxWorkerThreads来控制CPU。(前者⼀定是I/O(如流或管道)实现端⼝，后者则是传统⾮限制流程。由于 ⽬前IIS采⽤异步写已命名管道的⽅法来处理请求(IIS6直接集成了，所以不必通过已命名管道⽽是在⼯作者线程中直接处理请求)，所 以.net主要也在I/O中处理请求。)默认的线程设置是25/CPU，⼀般已经够⽤。当需要设置超过25直到100线程时,需要谨慎检查是否有异常。 1, 读取进程信息 使⽤ProcessModelInfo(两个获得当前或刚终⽌⼯作者进程休息的⽅法，都调⽤ProcessInfo类)和ProcessInfo(保存⼯作者进程的信息)两个静 态类来读取进程信息 Listing 3-6 ProcessModelInfo and ProcessInfo Classes public class ProcessModelInfo { public static ProcessInfo GetCurrentProcessInfo(); public static ProcessInfo[] GetHistory(int num); } public class ProcessInfo { public TimeSpan Age {get;}//年龄 public int PeakMemoryUsed {get;}//已使⽤最⼤内存数 public int ProcessID {get;}//进程ID public int RequestCount {get;}//已服务的请求数 public ProcessShutdownReason ShutdownReason {get;}//关闭原因 public DateTime StartTime {get;}//开始时间 public ProcessStatus Status {get;}//状态 } Figure 3-3. Sample ProcessModelInfo Output 2 , IIS6.0进程模型的改变(相对IIS5的隔离⽅式) 在IIS6.0中，ProcessModel在IIS元数据库中被对等设置代替，现在以XML形式放在⽂件中，所以忽略了 中的ProcessModel元素。⽽且进程不再是ASPNET_，⽽是⼀个或多个中，因为已经不限制⼀个cpu只能⼀个⼯作者进 程。我们可以配置应⽤程序池(包含共享相同⼯作者进程的虚⽬录集)，通过⽐ProcessModel更多更灵活的设置来控制进程(循环次数/天，分 离虚拟内存极限，实际内存极限，cpu使⽤监视，cpu过载的回收，应⽤程序池禁⽤的错误数量极限，启动和关闭时间限制)。 另外，使⽤的内核模式来侦听处理Http请求，⽽不再是。这样就不在进程中⽽是在系统服务内核中处理Http要求，于 是即使⽤户模式进程出现缺陷甚⾄崩溃，都不会影响服务内核。 四，附属设置 1，assemblies元素 在中使⽤@Assembly，可以全局引⽤GAC部署的应⽤程序。 Listing 3-7 Adding an Application-wide Reference to a GAC-Deployed Assembly <> 2，pages元素 在中使⽤@page指令，可以统⼀改变应⽤程序的page默认设置。 Listing 3-8 Using the pages Element <> 五，读取配置信息 除了通过tings["xxx"]来访问保存在AppSettings中的值外，通常⽤ fig()⽅ 法，请求从缓存中读取，如未缓存就请求直接从配置⽂件读⼊内存， ConfigurationRecord类使⽤XmlTextReader类可以直接读取最低层配 置的物理xml⽂件。 Listing 3-9 Reading Configuration Settings object settings = fig("appSettings"); NameValueCollection nvc = settings as NameValueCollection; if (nvc != null) { string val = (string)nvc["xxx"]; } 除了这样的配置的元数据，还有配置的处理程序(解析配置使其获得⾼扩展性，并在正式读取配置时建⽴类，同时传送对象的实例 建⽴，开始传送相关配置)。如下图：中，compilation元素由 CompilationConfigurationHandler类来解析，该类于 configSections元素下指定，同时也属于 sectionGroup元素(进⼀步确定分析范围是 )。另外⼀个元素appSettings由 NameValueFileSectionHandler负责解析，该元素位于配置⽂件的顶层。 Figure 3-4. Configuration Section Handlers in 每个configSections中的元素都必须实现IConfigurationSectionHandler接⼝，该接⼝有⼀个简单的⽅法 Create。当配置处理程序的标签被读 ⼊时，ConfigurationRecord类(顶层配置⽂件解析器)调⽤Create⽅法。同时，处理程序获得上层配置信息(如果有上层配置的话)和当前 HttpConfigurationContext对象(通过输⼊参数)，以及对 XmlNode的引⽤(最重要信息，由配置处理程序负责解析)。通常处理程序(函数)会遍 历XmlNode的每个⼦节点和属性，返回⼀个对象，包含所有状态信息。在缓存上述状态信息后，应⽤程序就可通过 fig()全局引⽤该状态信息。 Listing 3-10 IConfigurationSectionHandler Interface public interface IConfigurationSectionHandler { object Create(object parent, object input, XmlNode node); } 配置部份的处理程序各⾃都会在内存中建⽴⼀个state retainer(状态保持器)，如CompilerConfiguration类(compilation元素信息)， PagesConfiguration类(pages元素信息 )等。这些配置实例类(都是内部类，不可直接访问，⽤它们来设置其创建类中的默认值和其它 值)都保存在⼀个全局的哈希表中，可以⽤ fig()来访问该哈希表。 Figure 3-5. In-memory Configuration Settings Layout 六，创建⾃定义的配置处理程序 除了保存在appSettings元素中之外，还可以⾃定义配置元素。如下: Listing 3-11 Sample Custom Configuration Element Courier New ⾸先，我们要建⽴⽤于保存配置状态信息的保存机制。 ⼀种较简单的⽅法是定义⼀个类(如AcmeSettings类)，⽤其中的公有数据成员来保存对应的配置元素。 Listing 3-12 Sample Custom Configuration Settings State Class // File: namespace { public class AcmeSettings { public string Font; public string BackgroundColor; public bool UnderlineLinks; public int HorizontalWidth; public int VerticalWidth; } } 然后，我们要建⽴⼀个实现IConfigurationSectionHandler接⼝的类，⽤于解析配置⽂件中⾃定义部份，并将其状态信息保存到acmeSettings break; case ("backgroundColor"): oundColor = ext; break; case ("underlineLinks"): ineLinks = (ext); break; case ("horizontalWidth"): ntalWidth = (ext); break; case ("verticalWidth"): alWidth = (ext); break; } } return aset; } } } 最后要通知，我们要⽤该类解析配置⽂件中的acme元素。为此，我们在配置⽂件的configSections中添加⼀个section元素，⽤于读取并解析 配置⽂件。(系统范围的⽂件，站点范围和应⽤程序范围的⽂件都能添加Section元素) Listing 3-14 Installing a Custom Configuration Section Handler type="nfigHandler, AcmeConfigHandler" /> 现在，应⽤程序中的所有⽹页或者代码块，都能使⽤fig()⽅法访问该配置信息，传递我们创建的部份组 (section group)和部份名称(section name)，并将结果转变为我们创建的AcmeSettings类。如下: Listing 3-15 Accessing Custom Configuration Information // File: protected void Page_Load(object src, EventArgs e) { AcmeSettings set; set = fig("acmeGroup/acme") as AcmeSettings; // use set here (like , oundColor, // etc.) } 还有⼀种⽅法，使⽤NameValueFileSectionHandler，就不需要⾃即编写实现 IConfigurationSectionHandler接⼝的类了，⽽是重⽤与 appSettings元素⼀样的类。当然也不能⽤add元素(带有键 /值对)添加新的配置元素，但也能容易地添加新的配置部份。 Listing 3-17 Accessing Custom Configuration Information with NameValueCollection // File: protected void Page_Load(object src, EventArgs e) { NameValueCollection set; set = fig("myGroup") as NameValueCollection; // use set here (like set["Font"], // set["BackgroundColor"], etc.) } 七，⼩结： 使⽤名字的XML⽂件取代IIS的元数据库进⾏配置，是最顶层的机器配置，⽽可以放在站点根 ⽬录，虚⽬录根部，⼦⽬录等不同层次位置，相应地对其下层发⽣效⽤。 另外还可⽤新的配置元素，appSettings⽤于保存数据的通⽤的名/值对，以供应⽤程序调⽤。processModel可以精确控制⼯作者进程。另外 还可通过写⼀个实现IConfigurationSectionHandler接⼝的类或者使⽤系统提供的 NameValueFileSectionHandler类，实现⾃定义配置。
发布评论