1

私のソリューションには、次の実行可能ファイルの出力構造があります。

％プログラムファイル％
    | |
    +-[マイアプリ名]
          | |
          +-[クライアント]
          | | | |
          | | +-(EXE といくつかの DLL アセンブリ)
          | |
          +-[共通]
          | | | |
          | | +-[スキーマ アセンブリ]
          | | | | | |
          | | | | +-(複数の DLL アセンブリ)
          | | | |
          | | +-(複数の DLL アセンブリ)
          | |
          +-[サーバー]
                | |
                +-(EXE といくつかの DLL アセンブリ)

ソリューション内の各プロジェクトは、異なる DLL アセンブリを参照します。その一部はソリューション内の他のプロジェクトからの出力であり、その他はプレーンなサードパーティ アセンブリです。たとえば、[Client] EXE は、別のディレクトリ ブランチにある [Common] のアセンブリを参照する場合があります。

最終的にインストールされたアプリケーションのファイルのレイアウトをミラーリングするために、すべての参照で "Copy Local" が false に設定されています。

ここで、Visual Studio IDE で参照プロパティを確認すると、すべての参照の「パス」が絶対パスであり、アセンブリの実際の出力場所に対応していることがわかります。それは理解できて正しいです。予想どおり、ソリューションは正常にコンパイルおよび実行されます。

私が理解できないのは、IDE を閉じて [MyAppName] ディレクトリの名前を変更し、[Client] EXE を手動で実行しても、すべてが機能しているように見えるのはなぜですか? 参照パスがリンク時のものと同じでない場合、ランタイムはどのようにアセンブリを見つけますか?

明確にするために、これはまさに私が求めているものです。[MyAppName] ディレクトリの場所や名前に関係なく、正常に動作する半分散型のアプリケーション ファイルのセットです。私の側で特定のパス解決がなくても、これがどのように、そしてなぜ機能するのかを知りたいだけです。

この同様の質問への回答を読みましたが、まだわかりません。

大変助かりました！

4

4 に答える 4

1

私の知る限り、唯一の解決策は、MyAppBase に少なくとも「スタブ」exe を用意し、各アプリケーションの app.config でサブディレクトリを DLL のソースとして定義することです。

NTFS は、他のディレクトリ (つまり、ハード リンク) をサブディレクトリとして "マウント" することをサポートしていますが、それらは非常に自動化されておらず、理論化する以外にその方法を試したことがないため、それがハックとして機能するかどうかはわかりません。

于 2009-04-25T10:13:13.950 に答える
0

.Net が必要なアセンブリを見つける方法は次のとおりです: http://msdn.microsoft.com/en-us/library/yx7xezcf(VS.71).aspx

ステップ 4 は、あなたが読むのに興味深いかもしれません: http://msdn.microsoft.com/en-us/library/15hyw9x3(VS.71).aspx

于 2009-01-20T12:51:33.743 に答える
0

GACutilを使用して、共有アセンブリをグローバル アセンブリ キャッシュに追加することを検討しましたか?

于 2009-01-20T12:53:44.097 に答える
0

コンパイル時に共通フォルダーが binpath パラメーターとして指定された可能性がありますか?

(プライベート binpath の調査を参照)

http://msdn.microsoft.com/en-us/library/15hyw9x3%28VS.71%29.aspx

-マット

于 2010-05-05T02:00:11.067 に答える