アセンブリdllを別のプログラマと共有する際に、コンテンツファイルについてどうすればよいですか？

Question

ビルドアクションをコンテンツ（常にコピー）に設定したすべてのコンテンツファイル（XMLやスキーマファイル、イメージファイルなど）を持つライブラリプロジェクトがあります。

このライブラリプロジェクトは、ライブラリを参照するテストアプリケーション（WPF）も持つVisual Studioソリューションで動作します。

私がソリューションをビルドすると、依存ライブラリプロジェクトのすべてのコンテンツファイルがテストアプリケーションのbinフォルダにコピーされます。また、ライブラリプロジェクトのbinフォルダにコピーされます。

今日私は、私のライブラリプロジェクトによって生成されたアセンブリDLLを、彼が参照できるように別のプログラマに渡しました。しかし、それだけでは不十分だということは、私には起こりませんでした。彼にもコンテンツファイルを与える必要がありました。だから彼は自分のプロジェクトに加えました。

この解決策は機能しますが、私はそれに不快です。コンテンツファイルがプロジェクトファイルに混在しているのは気に入らない。これにより、誤って変更または削除される可能性が高くなります。

私は、コンテンツファイルが関係しているときに他のプログラマーとライブラリを共有する方法についていくつかの助言を得ることができると期待しています。

注：コンテンツファイルを非表示にしようとしているわけではありません（このライブラリを参照しているプログラマがアクセスできることは実際には重要です）。しかし、参照するプロジェクトとは別にしても、プロジェクトのコンパイル時にbinフォルダに移動します。私は、コードファイルとxamlファイルではなく、ソリューションにライブラリプロジェクトがあるかのようにしたいと思っています。

ありがとうございました。

EDIT：私に発生し

ひとつのアイデアは、私は新しいクラスライブラリプロジェクトに私のライブラリプロジェクトからわずかフォルダの構造とコンテンツファイルをコピーすることができたということです。次に、私のライブラリプロジェクトを参照する人は、この最小クラスライブラリを自分のソリューションに追加できます。彼らは依然としてdllを別のステップとして参照する必要がありますが、これは現在のソリューションよりもはるかに優れています。多分私は、ライブラリプロジェクトから最小クラスのライブラリにすべてのコンテンツファイルを自動的にコピーするポストビルドイベントを書くこともできます。 （今、私は実際にビルドイベントを書く方法を研究しなければなりません:)）。コメント歓迎。

EDIT 2：

私は私がと幸せになるだろうと思う解決策を考え出すために私の元編集上に構築されました。下の私の答えを見てください。

Answer 1

私は、ライブラリプロジェクトからコンテンツファイルを削除し、コンテンツのみを含む新しい「コンテンツオンリー」ライブラリプロジェクトに配置することにしました。誰かがライブラリプロジェクトを使用する必要がある場合は、dllとコンテンツのみのライブラリプロジェクトフォルダを共有するだけです。こうすることで、ソリューションフォルダ内のプロジェクトとコンテンツファイルの関係はまったく変わらず、コンパイル時にすべてが自動的に更新されます。

Answer 2

コンテンツファイルに埋め込みリソースを作成します。あなたはAssembly.GetManifestResourceStream()でそれらに得ることができます。アセンブリをより移植性の高いものにします。実行時にファイルシステムの場所に依存しなくなりました。