2010-12-11 13 views
4

私はASP.Netで開発しているアプリケーションの1つです。このアプリケーションでは、多くのAppSettingsを使用しています。最初の開発では、ConfigurationManager.AppSettings [""]を使用しました。開発が進むにつれて、各AppSettingsの静的プロパティを定義するユーティリティクラスを作成しました。その後、問題が発生し始めた。これで、アプリケーションがテストサーバーにデプロイされ、AppSettingsの設定が変更されると、IISを再起動しない限り効果はありません。ここで私はAppSettingsの静的プロパティを作成するために使用している次のコードスニペットです。私は考えることができた理由のAppSettingを変更してもアプリケーションに影響がありません

public static class AppSettingsUtil 
{ 
     public static string Log4Net 
     { 
      get 
      { 
       return ConfigurationManager.AppSettings["Log4Net"]; 
      } 
     } 
} 

一つは、それはそれはそれはのAppSettingsから値を取得することはできません以降その一生に一度ので、次の時間を初期化することができるように、静的プロパティがあるということです。

答えて

10

私はこれが古いスレッドだが、何かを追加することを知っている。

あなたが使用している場合:

<appSettings file="AppSettings.config" /> 

web.configファイルに変更が行われたり、再起動が実行されるまで続いて外部ファイルへの変更は使用できません。

しかし、あなたがすることに変更した場合:

<appSettings configSource="AppSettings.config" /> 

これらの設定に加えた変更は、すぐに再起動またはweb.configファイルを変更せずに、あなたのコード内で使用可能です。

私はこれが再現性のあるテストの場合であることを確認しました。

+0

ニース。これは多くの助けになります。 –

+2

注意すべき点が1つあります。 configSourceを使用している場合、web.configのappSettings部分には何も入力できません。あなたの外部ファイルでのみ。 file =アプローチを使用する場合は、両方の場所にエントリを含めることができますが、外部ファイルを読み込むにはIISを再起動する(またはweb.configを変更する)必要があります。 –

+1

"ファイル"対 "configSource"ビットを説明してくれてありがとう!私はそれが見つかるまで私の頭を叩いていた! –

0

このコンテキストでの静的メソッドは、AOPフレームワークの1つを使用せずに、configからの値をキャッシュすることはありません。サイトがコンパイルされておらず、フレームワークディレクトリに移動している可能性が高いシナリオです。個人的なメモでは、私はそのファイルConfig.csを呼び出すことを好む。

3

IISの再起動後に、更新された設定が利用可能であるため、設定ファイルを展開していることは明らかです。これは、あなたが異なる設定の別々の環境用のファイル(例えば、DEV、テスト、PRODを維持する場合は特に、きれいなweb.configを維持するために良いです

<appSettings file="my-app-settings.config" /> 

:あなたのAppSettingsのために外部ファイルを使用しているようですね

)。ただし、この方法の欠点は、ASP.NETが外部ファイルへの変更を自動的に検出しないため、設定が自動的にリフレッシュされないことです。

MSDNの場合、.NET Framework 2.0では別のファイルに変更されても、その後のアプリケーションの再起動は発生しません。このシナリオでは、外部ファイルを使用しないようにソリューションを設計しているようです。

+0

100%正しくない、以下の私の答えを参照してください。 "file"属性を使用しないで、代わりに "configSource"属性を使用してください。 –

関連する問題