web-dev-qa-db-ja.com

複数の環境で複数のweb.configファイルをどのように処理しますか？

私が現在これを処理する方法は、次のような複数の構成ファイルを用意することです。

web.config
web.Prod.config
web.QA.config
web.Dev.config

プロジェクトがさまざまな環境にデプロイされたら、対応するファイルの名前を正しい設定に変更するだけです。

誰かがこれをよりよく処理する方法についての提案がありますか？

編集：各構成で変更されるもののいくつかは次のとおりです。

  • WCFクライアントエンドポイントのURLとセキュリティ
  • カスタムデータベース構成
  • セッション接続文字列
  • log4net設定
c#asp.netweb-applications
27
Nick

スコット・グーはこれについて 記事 を一度持っていました。彼が提示した解決策は、ビルド前のイベントを使用して、選択したビルド構成に応じて正しい構成を所定の場所にコピーすることでした。

私はまた、SOに同様の 質問 がすでにあることに気づきました。

18
PHeiberg

変換はこれに本当に役立つようです。特定のセクションを別のルールに置き換えることができます。

http://msdn.Microsoft.com/en-us/library/dd465318（v = vs.100）.aspx

6
user1824408

これまでの方法は、AppSettingsセクションをオーバーライドすることです。

<appSettings file="../AppSettingsOverride.config">
    <add key="key" value="override" />    
    ...
</appSettings>

これはappSettingsセクションでのみ機能するため、ある程度しか役に立ちません。より堅牢なソリューションに非常に興味があります。

以下を編集

これを見ただけです： http://channel9.msdn.com/shows/10-4/10-4-Episode-10-Making-Web-Deployment-Easier/

VS2010には、非常に見栄えのする構成変換があり、複数の構成を簡単に行うことができます。

2
Andrew Barrett

Visual Studioで、xcopyビルドイベントを作成し、すべての構成ファイルを/ configフォルダーに保存します。ビルド構成の後にファイルに名前を付ける場合、つまり、web.configを/config/web.$(Configuration).configで上書きする場合、すべての構成に対して1つのイベントのみが必要です。

1
BC.

これに取り組む私のお気に入りの方法は、configSource属性を使用することです。確かに、私はこれを1つの要素（<connectionStrings>）しかし、web.configのさまざまなセグメントをスワップインおよびスワップアウトする簡単な方法を提供します（これは、インストール時にWebSetupプロジェクトを介して行います）。

1
Ken Browning

また、web.DEV.config、web.TEST.config、web.PROD.configなども使用しています。

プロジェクトが複雑でない場合、この方法が最も簡単で、最も単純で、簡単な方法だと思います。必要以上に複雑にするのは好きではありません。

しかし、私はNAntを使用したことがあり、これにはうまく機能すると思います。さまざまな環境に合わせてビルドを設定できます。 NAntは、使い方を学ぶために少し読んでいますが、かなり柔軟性があります。

http://aspnet.4guysfromrolla.com/articles/120104-1.aspx

http://nant.sourceforge.net/

これをCruiseControl.netおよびNUnitと一緒に使用して、単体テストの検証を伴う自動デイリービルドを実行し、それらがうまく連携していると考えました。

1
dtc

それは本当にあなたが異なるweb.configファイルを使用する原因となっている環境間の違いが何であるかに依存します。現在、各環境で異なる環境が必要な理由について詳しく教えてください。

0
Corey Sunwold

いくつかの回避策があります（すべてがweb.configで実行されるわけではありませんが、同じアイデアです）

  1. パッケージ化された展開には、複数の構成ファイルが含まれています。インストール中に、インストールする環境を指定します。
  2. すべての環境固有の設定を、その環境のデータベースサーバーに移行します。 WebServerは、サーバー名を要求するときにその環境を提供します
  3. 複数の設定（環境ごとに1つ）を提供し、コードを使用して異なる設定を要求します。
  4. 2と3の組み合わせ（アプリケーションサーバー名など、環境に基づいて設定の一部を上書きします）
0
Timur Fanshteyn

ほとんどの異なるバージョン管理ソフトウェア（Subversion、gitなど）を使用して、特定のファイルを無視できます。

したがって、Subversionでは、次のようになります。

configure.template.php-このファイルはバージョン管理されており、空のDSNのconfigure.phpなどのテンプレート化された構成データが含まれています-このファイルは無視されるため、ファイルへの変更は追跡されません。

Subversionでは、これを行う方法は次のとおりです。

svn pe svn：ignore。エディターが開き、configure.phpと入力します

保存して終了し、変更をチェックインすれば、準備は完了です。

0
leftnode