環境間での web.config 設定の違いを処理するための良いヒントはありますか? ソース コントロール システムの Web 階層外に 'config' フォルダーを作成し、展開プロセスで適切な構成ファイル (web.dev.config、web.staging.config、web.production.config) を展開時に Web フォルダーにコピーすることを検討しました。アプリの起動時に構成設定 (WCF エンドポイント、接続文字列など) をプログラムで変更する方法に関する投稿も見ました。
ここでベストプラクティスと見なされるものは何ですか? また、これらのアプローチや他のアプローチについて、皆さんはどのような経験をしましたか?
2010年9月更新
Visual Studio 2010ではこの機能が次のように追加されていることに注意してください。web.config 変換ビルド構成マネージャー (ビルド | 構成マネージャー...) を使用して、プロジェクトにさまざまな構成 (デバッグ、開発、ステージング、リリースなど) を作成すると、VS はソリューションに web.*.config ファイルを追加します。既定の web.config には、デバッグに使用するベースライン設定が含まれています。web.release.config、web.staging.config などには、アクティブなビルド構成に基づいてプロジェクトを発行するたびに適用される XSLT 変換が含まれています。
ベストアンサー1
私のアプローチは、複数の構成ファイルを用意することです。環境に依存しないもの (つまり、開発、ステージング、または本番環境かどうかは関係ありません) はすべて web.config ファイルに入れます。環境に固有のもの (つまり、データベース接続情報、ログ、デバッグ設定など) は、環境に固有の local.config ファイルに入れます。次に、configSource を使用して、local.config 設定を web.config に含めることができます (http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx）
その後、Web.config をソース管理にチェックインできます。local.config ファイルをチェックインしないでください。チェックインすると、デプロイ スクリプトで正しいファイルをデプロイする必要が生じます。