下面分几种情况来看.net中，默认是那个配置文件起作用。
情况1：
如果是一个标准的Win独立应用，或者一个标准的WEB独立应用，就不用说了，大家都知道。
配置文件定义配置信息
用下面代码，简单读取配置信息。
using System.Configuration;
string ww = ConfigurationSettings.AppSettings["SQLConnString"];
// 或者其他 ConfigurationSettings 类的方法获得配置信息
情况2：
如果是一个需要被Win程序调用的DLL组件，
配置信息放在调用它的Win程序的配置文件(app.config)中，
调用代码仍然是情况1简单的那两行调用代码。
情况3：
如果是一个需要被WEB程序调用的DLL组件，
配置信息放在调用它的WEB程序的配置文件（web.config）中，
调用代码仍然是情况1简单的那两行调用代码。
情况4：如果你编写的是一个独立的Win的服务，
跟情况1完全一样，
把配置信息文件放到Win服务项目中。
Win服务中再用情况1上面的代码直接调用即可。
情况5：如果是一个组件，被Win服务所调用，
跟情况2、3完全一样，
把配置信息文件放到Win服务项目中。
组件中，再用情况1上面的代码直接调用即可。
情况6：
如果你编写的是一个独立的Com+企业应用。并且这个Com+应用激活模式是“库应用程序”，组件将在创建者进程中被激活。
跟情况 2、3、5 类似，这时候的Com+就可以认为是一个组件。
把配置信息文件放到调用这个Com+的项目中。
这个COM+中，用情况1上面的代码直接调用即可。
分析以上几种情况：
起作用的配置文件其实是当前应用程序域的配置文件，.net 组件的作用域是调用它的Win程序或者WEB程序或者Win服务等等。组件的配置信息也应该是在这些主程序的配置文件中配置。
你可以在代码中通过AppDomain.CurrentDomain.SetupInformation.ConfigurationFile
这个代码，获得当前起作用的配置文件。
情况7：
如果你编写的是一个独立的Com+企业应用。并且这个Com+应用激活模式是“服务器应用程序”，组件将在专用服务器进程中被激活。
即这样的配置 [assembly: ApplicationActivation(ActivationOption.Server) ]
这时候，麻烦来了，
我们用 AppDomain.CurrentDomain.SetupInformation.ConfigurationFile 获得的是当前有效配置文件是
C:\WINDOWS\system32\dllhost.exe.config
这个文件默认并不存在，我们自己手工创建这个文件，并把配置信息写到这个文件中。
Debug 程序，我们仍看会看到“未将对象引用设置到对象的实例。”这样的异常产生。
以上我们得出的结论并不适用这个情况。
解决方法：
参看：
http://dotnet.org.za/armand/archive/2004/05/30/1917.aspx
http://blogs.msdn.com/florinlazar/archive/2003/12/04/41369.aspx
在未打过补丁的WINXP或者2003中确实有这个问题，在打过补丁的WINXP或者2003中，需要一些额外的操作，才可以使用ConfigurationSettings
请依次如下步骤：
1、给COM+ Server Application指定一个Application Root Directory（在Activation
Tab下）即： “应用程序根目录”
比如是 F:\MyDevelop\Temp\COMPLUSTest\COMConfigTest\bin\Debug 目录
2、然后在这个目录下创建一个 application.manifest 文件，内容如下：
<?xml
version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
</assembly>
3、然后再创建一个 application.config 文件
这个文件里面就是你要配置的具体内容，跟其他配置文件没有差别。
这时候你在执行这个COM+程序，
COM+内执行
AppDomain.CurrentDomain.SetupInformation.ConfigurationFile
返回的就是
F:\MyDevelop\Temp\COMPLUSTest\COMConfigTest\bin\Debug\Application.Config
获得配置信息也没有问题了。
注意这个必须是打过补丁的。
继续分析原因：
以下只是我的怀疑：
微软的Com+并不是一个彻头彻尾的.net应用，里面有大量的非托管代码。
问题就产生在这里，非托管代码中，并没有应用程序域与应用程序域的配置文件的概念。
于是乎，第七种情况就产生了。
如果没打过补丁的，解决方法，就是把配置文件的路径作为一个参数传递进Com+。
打过补丁的就是上面说的方法。
另外，如果你的程序是完全意义上的.net程序（也就是不是上述第7中情况）
你是可以修改一个应用程序的默认配置文件的。
具体请看参MSDN中关于
AppDomainSetup.ConfigurationFile 属性 和 IAppDomainSetup.ConfigurationFile
属性 的描述和演示代码。
配置文件描述应用程序域的搜索规则和配置数据。创建应用程序域的宿主负责提供此数据，因为有意义的值因情况不同而异。
例如，ASP.NET 应用程序的配置数据针对每个应用程序、站点和计算机进行存储，而可执行文件的配置数据针对每个应用程序、用户和计算机进行存储。只有宿主知道针对特定情况的配置数据的细节。
当 AppDomain 完成它的第一次绑定后，此属性不得更改。
参见：
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemappdomainsetupclassconfigurationfiletopic.asp
手工配置应用程序配置文件的范例可以参看下面一篇文章中提到的代码：
Executing ASMX files without a web server
http://radio.weblogs.com/0105476/stories/2002/10/24/executingAsmxFilesWithoutAWebServer.html
http://www.gotdotnet.com/team/clr/AppdomainFAQ.aspx
或者看下面的代码：
AppDomainSetup info = new
AppDomainSetup();
info.ApplicationBase = "file:///" + System.Environment.CurrentDirectory;
info.ConfigurationFile = "C:\\Program Files\\MyApp\\MyApp.exe.config";
AppDomain dom = AppDomain.CreateDomain("RemoteDomain",
null, info);
dom.ExecuteAssembly("HelloWorld1.exe");
AppDomain.Unload(dom);
情况8
服务器进程中被激活的COM+程序中调用组件。组件的做法。
如果你看了前面几种方式，这种方式就知道如何应对了。
配置文件的方式看情况7
调用代码，跟情况1的代码完全一样。 |
|