いくつかのフォルダにまたがるアプリケーションの展開....ほぼ<probing>

Question

私は非常に大規模なシステムを展開し、多くのコンポーネントを搭載しており、かなり拡張可能であるように構築されています。ほとんどすべてに必要なコアコンポーネントと、より特殊化したものを扱うコンポーネントのセットがあります（それぞれのセットが独自のアプリケーションである点では今は必ずしも真実ではありませんが、その方向に向かいました...）

デプロイするときにいくつかの構造を試してみたいと思います。私はの線に沿って考えていた：

• C：\プログラムファイル\ MyCompanyの\ MyBigSystemのApp1 \
• C：\プログラムファイル\ MyCompanyの\ MyBigSystem App2の\
• C：\プログラムファイル\ MyCompanyの\ MyBigSystem \ App3起動
• C：\プログラムファイル\ MyCompanyの\ MyBigSystem \ APPN
• C：\プログラムファイル\ MyCompanyの\ MyBigSystem \コア

などのファイル... \ App1は間違いなく... \ Coreの依存ファイルを持っていますが、明らかにこれらのファイルを... \ App1フォルダに再配布しないようにしたいと思います。私は、App1がCoreフォルダからそれらを取得するようにします。

私はこれが可能かどうかを確認するのに苦労しています。

は、ここではいくつかの制約との観測だ：

現在、すべてのコンポーネントは、静的な参照を使用して構築されています。私は、この姿勢を放棄するよりも、すべてを単一のフォルダに展開する可能性が高いです。さらに、私はこの展開構造を前提とするプログラムコードを変更したくありません。 Assembly.LoadFromを使用するか、appDomainのパスをスマートに設定するなど、卸売りの変更はありません。

ただし、セットアップ時に書き込むことができるので、app.configエントリには順応します。

私は一見理想的な見えたが、なぜなら私は<コードベース>見てきましたサブディレクトリ

であることのその制約を不適当になってしまった、>プロービング<を見て（と非常に簡単にテスト）しています - 私はこれを完全に読んでいなかった。なぜなら、十数組のコアアセンブリを個別に登録しなければならなかったからだ。（それを言っても、私が問題を抱える準備ができたら、自分が望むものを手に入れることができたようだ。

他にも私が考えているアプローチはありますか？

TIA、Pete

Answer 1

最終的に私はほとんど私が望んでいたが、かなりではない。私が望むすべてのフォルダ構造で終わった....

• C：\プログラムファイル\ MyCompanyの\ MyBigSystem \ App1の
• C：\プログラムファイル\ MyCompanyの\ MyBigSystem \ App2の
• C：\プログラムファイル\ MyCompanyの\ MyBigSystem \ App3起動
• C： \プログラムファイル\ MyCompanyの\ MyBigSystem APPN \
• C：\プログラムファイル\ MyCompanyの\ MyBigSystemコア

\ ....しかし、持っていた「MyBigでメインの実行可能ファイルを置くためにシステム」フォルダ、つまり

• C：\プログラムファイル\ MyCompanyの\ MyBigSystem \ App1.exe
• C：\プログラムファイル\ MyCompanyの\ MyBigSystem \ App1.exe.config
• C：\プログラムファイル\ MyCompanyの\ MyBigSystem \ App2.exe
• C：\プログラムファイル\ MyCompanyの\ MyBigSystem \ App2.exe.config

私は実行ファイル設定ファイルで<probing>のエントリ、例えばと、この構造体を補足

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <probing privatePath="Core"/> 
    </assemblyBinding> 
    </runtime> 

これは、私が合理的に願っていたほどルートフォルダを整理しておくように思えました。また、App6はApp1の従属ライブラリにアクセスすることができます。この理由から私はGACから離れていました。Appsをアプリケーションに依存させることができれば、GACにはすべてが必要であることがわかりました。不適切なのはGACにあるのが分かります）。

このアプローチでは、設定で主な課題は、VS Setupプロジェクトで、（、サブフォルダ内の.exeと.exe.configを除く）をすべて配置することになりました。

Answer 2

おそらくコンパイルする必要があり、リリースしないでください。サードパーティのインストーラを使うのが最も簡単です。インストールシールドがいいです。

Answer 3

Eclipseを使用している場合は、コアのプロジェクトをソースライブラリとして作成し、他のすべてのプロジェクトに含めることができます。