このエンタープライズ アプリケーションには、dll として参照されるアセンブリと、プロジェクトとして参照されるアセンブリがあります。
dll として参照されるものについては、「特定のバージョン」設定を false に変更しました。
プロジェクトとして参照されているものには、そのような設定はありません。参照されているプロジェクト アセンブリの 1 つに修正プログラムを展開する必要がある場合、ランタイムは検索対象のバージョンをどのように認識しますか? メイン プロジェクトもデプロイする必要がありますか?
ここで理解しておくべき重要なことは、「特定のバージョン」は実行時のアプリケーションの動作とは関係がないということです。.net ランタイムがアセンブリを解決する方法には影響しません。
すべての「特定のバージョン」は、Visual Studio (コンパイラではなく) に、プロジェクトが IDE に読み込まれるときに、解決可能な場所で DLL 参照が利用できない場合、同じ DLL の別のバージョンを受け入れるかどうかを通知します。"特定のバージョン" が TRUE に設定されていて、プロジェクトの一部の依存関係をアンインストールまたは削除すると、Visual Studio はソリューション エクスプローラーでその参照に小さな感嘆符を配置します。"特定のバージョン" が FALSE に設定されていて、その DLL の別のバージョンが利用可能である場合 (VS がそれを見つけることができると仮定)、Visual Studio は代わりにその DLL を参照するようにフォールバックします。もちろん、これは次回のビルド時にのみ現れます...新しい出力は「フォールバック DLL」を参照します。
結果の出力は同じですが、プロジェクトがコンパイルされたときに参照していた DLL バージョンが、実行時に必要となる DLL バージョンであるという点で、別のバージョンに置き換えることはできません (もちろん、私は参照のみを行っています)。ここでは厳密に名前が付けられた DLL に、明示的に宣言されたバージョンのリダイレクトを無視します)。
特定のシナリオでこれが意味することは、特定のバージョン管理を使用していない場合、プロジェクトをコンパイルしたときにプロジェクトがどのような依存関係を持っていたかを追跡する必要があるということです (Excel スプレッドシートは誰ですか? うーん...) -ソース管理を調べれば、プロジェクトが参照しているバージョンが実際にプロジェクトにコンパイルされたものであることを保証できます。もちろん、公開するすべてのバイナリのコピーを保持する必要があります。そのため、それらを調べて、顧客にデプロイされたものを確認できます...
あなたの質問に答えるために-いいえ、メインプロジェクトを展開する必要はありません-展開時にそれらの依存プロジェクトのバージョンを知る必要があるだけなので、互換性のあるホットフィックスをビルドできます...
...または、新しい DLL を作成し、古いバージョンから新しいバージョンへのアセンブリ バインド リダイレクトを実行します。