11

.NET では、.settings ファイルを使用してアプリケーション設定を管理できます。次のようなことができるように、本番、開発、およびテストの設定を個別に保存したいと思います。

EnvironmentSettings environmentSettings;

// get the current environment (Production, Development or Test)
ApplicationEnvironment Environment = (ApplicationEnvironment)
    Enum.Parse(typeof(ApplicationEnvironment), Settings.Default.ApplicationEnvironment);

switch (Environment)
{
    case ApplicationEnvironment.Production:
        environmentSettings = Settings.Production;
        break;
    ...
}

string reportOutputLocation = environmentSettings.ReportOutputLocation;

基本的に、2 つの個別の設定クラスが必要です。選択した環境と環境固有ではないプロパティを格納する一般的な設定クラスと、EnvironmentSettings という 2 番目のクラスの 3 つの静的インスタンスです。使用されるインスタンスは、一般的な設定クラスで指定された環境に依存する必要があります。

静的コンストラクターなどでこれらすべての設定の値を手動で設定する以外に、これを行う方法はありますか? そうしなければならない場合は、「DevOutputLocation」、「LiveOutputLocation」などのプロパティを持つ大きな設定クラスを 1 つだけ用意します。

プロジェクトに複数の .settings ファイルを含めることができますが、それは互いに派生しない個別のクラスを作成するだけです。したがって、DevelopmentSettings.settings、ProductionSettings.settings、および TestSettings.settings ファイルを作成して、それらに同じプロパティを与えることができますが、共通のクラスから派生していないため、使用するクラスを決定するために、どこにでも大量の switch ステートメントが必要になります。 .

4

6 に答える 6

3

1 つの考えとしては、一連の静的な値の間で切り替えることは、物事を行う上でかなり骨の折れる方法のように聞こえるということです。シングルトンパターンを調べることをお勧めします。このパターンは、クラスへのすべての参照間で共有される単一のクラス インスタンスを提供しますが、最初に読み込まれるときに、通常の初期化ビットを実行して環境をチェックし、それに応じて値を設定できます。

同様に、スイッチを使用してさまざまなクラスに作用するのではなく、1 つのインターフェイスを設計し、各クラスにそのインターフェイスを実装させることを検討していませんか?

于 2010-02-11T23:04:28.783 に答える
2

私は .config ファイルにこのアプローチを使用しています。これも役立つと確信しています。Scott Hanselman のブログ投稿とこの質問を見てください。イデオロギーは地獄のように単純ですが、かなりうまく機能します。必要なのは次のとおりです。

  1. 異なる構成用に複数のファイルを作成する
  2. my.dev.settings、my.live.settings など、規則に従って名前を付けます。
  3. ビルド後のイベントを作成する (リンクを参照)
  4. 楽しむ=）

設定を含むクラスのインスタンス化コードは常にデフォルト設定 (ビルドごとに必要な設定に置き換えられます) を参照するため、このアプローチは最小限の労力で済みます。

于 2010-02-12T09:13:44.983 に答える
1

どの環境で実行しているかを判断するためのチェックには、多少のオーバーヘッドが伴います。Web 環境について話している場合、これはパフォーマンスが大幅に低下する可能性があります。3 つの個別の構成ファイルを作成し、環境に基づいて適切な設定ファイルの命名とロールアウトを処理する継続的な統合および展開システムをセットアップすることをお勧めします。あなたの場合、Production.config、Development.config、および Test.config の 3 つのファイルがあります。次に、統合サーバーは、環境に基づいて web.config または app.config のこのファイルのコピーを作成します。

構成の変更が行われるたびに 3 つの個別のファイルを維持することに関連する追加のメンテナンスに関しては、ファイルを自動フォーマットに保ち、WinMerge などを使用して違いを簡単に確認し、適切な同期を維持します。これらのタイプのファイルは通常、多くの変更を必要とせず、必要な場合は通常、マイナーな追加です。

于 2010-02-12T20:17:16.100 に答える
1

私は現在、pdavisが言及したソリューションと同様のことを行っています。ただし、複数の構成ファイルを簡素化するために、T4 テンプレートを使用して環境固有の構成ファイルを作成します。このようにして、デフォルトの web.config ファイルの生成を処理する 1 つの web.tt ファイルが存在します。各環境には、web.tt から継承し、環境固有のオーバーライドを含む独自のテンプレート ファイル (qa.tt、production.tt など) があります。Web 構成への変更 - 新しいアプリ設定、構成設定などは、テンプレートを再生成することにより、すべての地域固有の構成ファイルに自動的に反映されます。差分ツールを使用してファイルの同期を維持することを心配する必要はありません。

于 2010-02-13T04:33:48.140 に答える
0

ただのアイデアですが、うまくいくかもしれません...

  • 同じキーを含むN+2個の設定ファイル（N個の異なるビルド; 2個のマスター）が必要です。

  • マスターの1つを除くすべての「カスタムツール」プロパティをクリアします（したがって、マスターが生成するのは1つだけです）。

  • 各リリースのビルド前スクリプトを変更して、適切な設定ファイルの内容をビルドマスターファイルにコピーします。

  • ビルド後のスクリプトを変更して、セカンダリマスターファイルの内容を元のマスターファイルにコピーし直します。

注：ビルド前およびビルド後のスクリプトでソース管理プロバイダーと連携できる場合は、セカンダリマスターは必要ありません。ビルド前でチェックアウトし、ビルド後でチェックアウトを元に戻すことができます。 。ただし、ロックされたファイルではビルドが失敗する必要があるため、これにより継続的インテグレーション環境で問題が発生する可能性があります。

私もこれをしたことがありません。VSでこのようなことをもっと前もって行う方法があればいいのにと思うこともありますが。

于 2010-02-11T20:52:03.063 に答える
0

上記の実装を具体的に使用せずに、.NET 環境ベースの構成ファイルに関する追加情報をいくつか示します。

V3.0 以降、Enterprise Library には次の機能があります 。

Visual Studio 2010 にもこの機能があります。構成変換と呼ばれる

于 2010-02-12T19:02:59.810 に答える