コンフィギュレーション設定を読み込むにはコンフィギュレーション設定を使用します
以下、いくつかの状況に分けて見る.Netでは、デフォルトではそのプロファイルが機能します.ケース1:
標準的なWin独立アプリケーション、または標準的なWEB独立アプリケーションなら、言うまでもなく、みんな知っています.コンフィギュレーションファイル定義コンフィギュレーション情報は、次のコードを使用して、コンフィギュレーション情報を簡単に読み取ります.using System.Configuration;string ww = ConfigurationSettings.AppSettings["SQLConnString"];//または他のコンフィギュレーション設定クラスの方法で構成情報を取得します.
ケース2:
Winプログラムによって呼び出されるDLLコンポーネントである場合、そのWinプログラムを呼び出すプロファイル(app.config)に構成情報が配置され、呼び出しコードは依然としてケース1の簡単な2行の呼び出しコードである.
ケース3:
WEBプログラムによって呼び出されるDLLコンポーネントである場合、そのWEBプログラムを呼び出すプロファイル(web.config)に構成情報が配置され、呼び出しコードは依然としてケース1の簡単な2行の呼び出しコードである.
ケース4:
独立したWinのサービスを作成している場合は、状況1と全く同じように、構成情報ファイルをWinサービスプロジェクトに配置します.Winサービスではケース1の上のコードで直接呼び出せばよい.
ケース5:
1つのコンポーネントであれば,Winサービスに呼び出され,ケース2,3と全く同じように,構成情報ファイルをWinサービス項目に格納する.コンポーネントでは,ケース1の上のコードで直接呼び出せばよい.
ケース6:
独立したCom+エンタープライズアプリケーションを作成している場合.また、このCom+アプリケーションのアクティブ化モードは「ライブラリアプリケーション」であり、コンポーネントは作成者プロセスでアクティブ化されます.ケース2,3,5と同様に,このときのCom+は1つのコンポーネントと考えられる.このCom+を呼び出すプロジェクトにプロファイルを配置します.このCOM+では、ケース1上のコードで直接呼び出せばよい.
以上のいくつかの状況を分析する:機能するプロファイルは実は現在のアプリケーションドメインのプロファイルである.Netコンポーネントの役割ドメインは,そのWinプログラムやWEBプログラム,Winサービスなどを呼び出す.コンポーネントの構成情報も、これらのプライマリ・プログラムの構成ファイルで構成されるべきです.コードの中でAppDomainを使うことができます.CurrentDomain.SetupInformation.コンフィギュレーションファイルというコードは、現在機能しているプロファイルを取得します.
ケース7:
独立したCom+エンタープライズアプリケーションを作成している場合.また、このCom+アプリケーションアクティブ化モードは「サーバアプリケーション」であり、コンポーネントは専用サーバプロセスでアクティブ化されます.つまりこのような構成[assembly:ApplicationActivation(ActivationOption.Server)]では、お手数ですが、AppDomain.CurrentDomain.SetupInformation.コンフィギュレーションファイルは、現在有効なプロファイルがC:/WINDOWS/system 32/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アプリケーションにアプリケーションRoot Directory(Activation Tabの下)即ち「アプリケーションルートディレクトリ」を指定する
例えばF:/MyDevelop/TEmp/COMPLUSTest/COMConfigTest/bin/Debugディレクトリ
2、このディレクトリの下にアプリケーションを作成します.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();情况8
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);
服务器进程中被激活的COM+程序中调用组件。组件的做法。
如果你看了前面几种方式，这种方式就知道如何应对了。
配置文件的方式看情况7
调用代码，跟情况1的代码完全一样。
， ， 。