2009-04-23 33 views
7

コンパイルされたアセンブリに含める必要がある任意の数の補足ファイルを持つクラスライブラリプロジェクトがあるとします(単純なテキストファイルやラップされた従来のアンマネージDLLなど)相互接続層としてのアセンブリ)。補足ファイルをアセンブリ自体に埋め込むのはrelatively straightforwardですが、これは不可能または望ましくない状況があります。外部ファイルをアセンブリに関連付ける方法

"Copy to Output Directory"に適切な値を指定してこれらのファイルをプロジェクトに追加すると、「サイドカー」ファイルとして表示されるようになります(アセンブリと並んでファイルがアセンブリーと関連している可能性があります)。ソリューション内に完全に自己完結型のプロジェクトには十分です。しかし、別のソリューションの別のプロジェクトでアセンブリへの参照が追加されても、サイドカーファイルは自動的にはピックアップされません。どのようにして結果のアセンブリをマークして、アセンブリを参照するものにも関連するサイドカーファイルを含める必要があることがわかるようにする方法はありますか?これどうやってやるの?

+0

私は "TFS Dependency Replicator"を提案しようとしていましたが、サイドカーファイルではなくアセンブリーでしか動作しません。 – RobS

答えて

2

al.exeを使用することもできますが、C#コンパイラオプションもあります。/linkresource C#コンパイラオプションを使用して、マルチファイルアセンブリを作成する必要があります。命令はhereですが、コマンドは次のようになります。

N.dllは、マネージアセンブリが行くところはどこでも行きます ネイティブDLLある
csc /linkresource:N.dll /t:library A.cs 

で非常に明確な説明があります(GACに含みます。)私が提供したリンク。

+0

私はリンクされたドキュメントと複数のファイルアセンブリに関する私が見つけたいくつかの他のものを読みましたが、私はまだこれが私の質問に答えるのにどのように適用できるか分かりません。たとえば、管理対象アセンブリでラップされたアンマネージドDLLの問題を解決するために、これをどのように使用して上位の管理下で使用するために共通のライブラリの場所で利用できるようにする必要があるかについて、 (管理されたラッパーを簡単に参照できますが、アンマネージDLLは出力ディレクトリに自動的には含まれません)。 – iammichael

+0

編集していただきありがとうございます。これは問題を解決するのに適しているようです。しかし、シンプルなビジュアルスタジオビルドからMSBuildまたは他のコマンドラインベースのビルドに変更する必要があるため(リンクリファレンスには「Visual Studioではこのコンパイラオプションは使用できず、プログラムでは変更できません」)、I確認するために現時点ではテストすることができません。確かに有望に見える。 – iammichael

+0

検証できなかったし、そうする時間を予想していないし、ファイルのための理想的でないマニュアルコピーを使用してしまったが、これは質問に対する実際の答えのようだ。受け入れています。 – iammichael

1

ソリューションのセットアップを作成しましたか?アプリケーションのインストールディレクトリにサイドカーファイルターゲティングを含めるオプションがあります。

別のオプションとして、サイドカーファイルをアセンブリリソースに含め、最初に実行するときにディスクにアンラップすることもできます。

+0

サイドカーファイルを使用するライブラリコードの変更の頻度は、インストールする必要はありませんそれがアプリケーション開発者によって使用可能になる前に。また、アプリケーションインストーラー(基本となるライブラリを含める必要があります)は、サイドカーファイルについて自動的に認識しません。 サイドカーファイルを組み込みアセンブリリソースとして組み込み、それをディスクに展開することは、我々が検討する必要がある興味深い考えです。私はすべてのユースケースを満たすだろうと確信していません。 – iammichael

+0

私たちは実際にInteropのdllやその他のリソースのアンラップを実行しました。これを使って「パスによるアセンブリ解決」問題を解決しました。どのアプリケーションドメインまたはホストプロセスからアセンブリを実行しても、実行時にディスクに動的に展開され、最近ラップ解除されたアセンブリへの参照が解決されます。これは、アプリケーションの更新を配布する際にも有用であることが判明しました。 –

+1

実行ユーザーがinterop DLLをディスクに書き込めないという問題が発生しましたか? – iammichael

0

残念ながら、私は間違いなくこのユースケースを見ることができますが、Visual Studioにはビルトインサポートがたくさんあるようです。

ソースコントロールにSubversionを使用する場合は、外部参照として外部定義としてリンクすることができます。これはソースコードをもたらし、DLL参照の代わりにプロジェクト参照として必要なアセンブリへの参照を作成してから、出力ディレクトリの規則へのコピーが有効になります。

これが可能でない場合は、ビルドのリモートアセンブリから最新のサイドカーファイルをコピーするために、ソリューション内プロジェクトのビルド前/ビルドイベントにコマンドを含めることもできます。もちろん、プロジェクトにDLLを含めると自動的に設定されないという注意点があります。手動で設定する必要があります。

+0

私たちはSubversionではなくTFSを使用していますが、ライブラリを参照するアプリケーションが個々のサイドカーファイルについて知る必要がないため、問題が解決するかどうかはわかりません(私が思うなら、説明ごとにプロジェクト参照として追加します)。でも、ここであなたが言っていることを誤解しているかもしれません。プレ/ポストビルドイベントに関しては、それが自動でないことは、ある種のディール・ブレーカーです。ルーカスの私のコメントもまた、ビルド前/後のイベントを提案した人のコメントも参照してください。 – iammichael

+0

何らかの外観定義を使用していた場合、それはあなたのソリューションに含まれているプロジェクトの仮想コピーを含むようなものです。その後、インクルードされたプロジェクトのサイドカーファイルごとに、Visual Studioのプロパティエディタの[出力ディレクトリにコピー]属性を[常にコピー]に設定できます。これを行い、プロジェクト参照でプロジェクトをインクルードし、ソリューションをビルドすると、Visual Studioはサイドカーファイルをプライマリ出力ディレクトリにコピーすることを認識しています。 –

0

私はこれまでにこれを処理しています。その共通の問題です。

あなたは、いくつかのポストビルドアクションを作成することができます

http://www.codingday.com/execute-batch-commands-before-or-after-compilation-using-pre-build-or-post-build-events/

希望はこのことができます... :)

+0

ライブラリでのビルド後のアクションでは、ライブラリアセンブリは、ライブラリアセンブリに依存するアプリケーションと追加のファイルが必要な場所を知る必要があります。ライブラリーに応じてアプリをプレビルドするということは、アプリがコピーする内容を知る必要があり、その情報はライブラリー自体だけが知っていることを意味します。依存関係のチェーンが長くなり、手作業でコピーしなければならないサイドカーファイルについて知る必要があるライブラリの複数の層があると、状況はさらに複雑になります。したがって、これは必要性を完全には満たしていません。 – iammichael

0

あなたが参照の間違った種類を使用しているように私には見えます。参照には参照とプロジェクト参照の2種類があります。参照とは、特定のアセンブリへの明示的な参照です。 ProjectReferenceは別のプロジェクトへの参照です(例:.csproj)。

あなたが探しているのはProjectReferenceです。 VSとデフォルトのMSBuildターゲットは、CopyLocalを実行するように設定されています。 "サイドカー"ファイルにCopyToOutputPathをtrueに設定すると、このプロジェクトのすべてのProjectReferencesも同じファイルを取得します。

IDEのソリューション間でProjectReferencesを使用できるかどうかはわかりません。私はslnファイルが関連していないMSBuildをたくさん扱っています。

+0

ええ、物事が1つの解決策の中にある場合、プロジェクトを参照しても問題ありません。私はその質問にそれを暗示しています。別のソリューションでは動作しません。また、ライブラリプロジェクトファイルがない場合(つまり、アプリケーション開発者が実際のプロジェクトファイルではなくアセンブラとサイドカーファイルを持っている場合)にはうまく機能しません。 – iammichael

0

私たちがプロジェクトで行ったことは、これらすべてのことを行うために別々のビルドファイルとして作成したことです。

ビルドファイルには、主なソリューションをビルドするためのタグを用意し、ビルド後に必要なファイルをコピーするタグを追加することができます。

NAntもオプションですが、現在はRakeをビルド/デバッグの自動化として使用しています。

これはVisual Studio内では統合できないため、デバッグ時にVisual Studioに最後にvsjitdebugger.exeを実行するタスク(MSBuild、NAntまたはRakeのいずれか)を作成します。 。

これはちょうど私のスタイルです。あなた自身のスタイルを作成することもできます。

1

ライブラリとその依存関係を含むmerge moduleを作成するとどうなりますか?インストーラはこのモジュールを参照する必要がありますが、必要なファイルがすべて存在することを確認します。

+0

状況によっては動作しますが、現在はライブラリコンポーネントまたはWebアプリケーションのインストーラを使用していないため、展開プロセスと開発プロセスの両方でオーバーヘッドが大きくなります。 – iammichael

1

私は、リンク元とコピーの参照を使用するのが非常に簡単なsolutionをはるかに良く見つけました。

関連する問題