app.configファイルを制御する方法が必要

Question

現在、ソリューションの開発に携わっているのは4人です。このソリューションは、中央実行可能プロジェクト（Windowsサービス）といくつかのクラスライブラリソリューションで構成されています。 Windowsサービスにはapp.configファイルがありますが、何らかの理由でCopy to Output Directory設定が「Do not copy」に設定されているため、この説明は無視してください。

app.configファイルを持つ2つの異なるクラスライブラリプロジェクトがあります。いずれかのプロジェクトでは、これはMyClassLibrary.dll.configとしてbin \ Debugフォルダにコピーされ、他のDLLのbin \ DebugフォルダにはMyOtherClassLibrary.dll.configとapp.configの両方が含まれます。それがどうして起こったのか分かりません。

これは、ソリューション内のすべてのapp.configファイルです。

ソリューションにはMSTestプロジェクトがあります。 [TestClass]属性を持つ複数のクラスがあり、それぞれに独自の.csファイルがあります。このプロジェクトのbin \ Debugフォルダを見ると、MyClassLibrary.dllとApp.configが見つかりますが、MyOtherClassLibrary.dllは見つかりません。これは奇妙ですが、それは私が見るものです。

これらのテストのいずれかを実行すると、ファイルはソリューションのTestResultsフォルダにある特別なテストフォルダにコピーされます。そのフォルダを見ると、MyTestProject.dll.configファイルしか見つかりません。これを開くと、その内容はapp.configファイルの内容になります。

ここでは何が起こっていますか？私はVisual Studioのすべての設定ファイルを一緒にマージしたと思った？ MyClassLibrary.dll.configファイルの設定が不足していると（明らかに）、それに依存するコードが壊れてしまいます。

これをどのように修正しますか？

トニー

編集：私はちょうどダブルMyClassLibraryビン\ Debugフォルダの両方のapp.config & MyClassLibrary.dll.configを持って&を確認し、私は私がMyOtherClassLibraryで見ていたが正常であると思い

。これらの設定をすべて管理する方法が必要です。

Answer 1

の設定ファイルが1つだけ必要です。実行中のプロジェクト（コンソールプロジェクト、Webアプリケーションプロジェクトなど）に含めることができます。クラスライブラリのいずれかのクラスがコンフィグレーション値を参照している場合は、実行中のプロジェクトからそのクラスへのアクセス/スコープが必要です。私は自動マージを見たことがない。

Answer 2

はあなたのメイン設定にあなたの設定を引っ張ったり、ビルドの一部が、私はここに多少の関連方法でこれに触れマージ何かを実装： Visual studio 2010 - Per Developer/machine/environment Web.Config settings

をあなたは自動的に外デフォルトでコピーされたものを得ることはありませんあなたメイン設定、それはそのように動作しません。

Answer 3

いいえ、VSは設定ファイルを一緒にマージしません。これは、2つ以上の実行可能ファイルをプロジェクトとして生成するソリューションを持つことが可能であるため、これを実行しません。常にクラスライブラリとして終わり、実行可能ファイルが1つしかないプロジェクトであっても、app.configsをマージすることは懸念の分離のためには良い考えではありません。プロジェクトライブラリは、参照コードがメソッドとメソッドをインスタンス化するための外部インタフェースのみを必要とする「ブラックボックス」でなければなりません。 app.configとその情報は、実装上の詳細であり、必要とするプロジェクトだけが知っている必要があり、それを参照するプロジェクトではありません。また、別の実行可能ファイルとは独立してプロジェクトライブラリを再コンパイルして新しいDLLをプッシュした場合、どのように設定ファイルをマージするのですか？

プロジェクトにapp.configがある場合、そのプロジェクトの設定が明確に作成され、別のものと区別されます。

configsに共通のデータがある場合、それらのセクションの外部設定ファイルを指定し、 "configSource"属性を使用して各プロジェクトの "メイン"設定ファイルから参照することで冗長データの量を最小限に抑えることができます。

Answer 4

ジャスト（web.configファイルとはapp.configファイルを含む）は、このような設定ファイルで起こる二つのものがあることに注意してください：あるとして

1. あなたは、ファイルを展開します。変換の対象となる可能性がありますが、ファイルはそのまま名前で展開されます。

2. アセンブリに属する​​としてコンパイルされます。だから私のプロジェクトはがありますProjectOneという名前

これは重要なことは（ProjectOneは「ProjectOne」であるために私のアセンブリを想定して）コンパイルしProjectOne.dll.configと改称のapp.configファイルのあるその理由はすべての範囲について。この名前の変更は、プロジェクトアセンブリが独自の設定ファイルに最初にアクセスできるようにするため、設計によるものです。シナリオ1の実際のapp.configよりも優先されます。

MSBuildがファイルにアクセスしないようにファイルのプロパティを変更することで、シナリオ2が発生しないようにすることができます。それから、それをそのまま展開しようとするかもしれません。この状況では、ビルドオーダーに基づいて以前にデプロイされたビルドを上書きします。