2011-04-08 5 views
1

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

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

  • 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

+0

私はApp1のApplicationBaseをc:¥Program Files¥My Company¥My Big Systemに設定できればを使用できます。私はこれをプログラムで簡単に(私は思うが)十分に行うことができますが、私は設定によって多分applicationBaseを設定できますか? – PeteH

+0

私は* codeBaseを使用することができますが、私はセットアップでカスタムアクションからこれをすべて設定することもできますが、.configファイルで終わることになるblurbのボリュームはまだ嫌です。 – PeteH

+0

私はGACの使用を検討していますが、自分のシステムが「グローバル」と考えるのは非常に面倒です。 – PeteH

答えて

0

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

  • 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を除く)をすべて配置することになりました。

0

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

+0

申し訳ありませんが、私は言っておくべきです、私はかなりVS2010セットアッププロジェクトを使用することに制約があります。しかし、私はこれがポイントを逃したと思う。私は簡単に説明したようにファイルをレイアウトするためにセットアッププロジェクトを手に入れることができます。インストール時に問題が発生するのではなく、問題が実行時に参照を見つけることができなくなると思います。 – PeteH

0

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

+0

それは素晴らしいニュースです。残念ながら私はEclipseを使用していません – PeteH

関連する問題