上記のすべての良いアドバイスに同意しました。そうは言っても、外部DLLが一般的に必要とされない有効なシナリオがあるのではないでしょうか。だからここにあなたがすることです。それらをラップして分離します。（インターフェイスを作成するよりも抽象化のレベルが高いため、保守が少し簡単です）。
Visual Studioでは、外部DLLを参照する特定のVSプロジェクトを再コンパイルしない場合、それらのDLLを手元に用意しなくても、残りのVSソリューションのプロジェクトをコンパイルする必要があります。したがって、何らかの方法で外部DLLを独自のDLLでラップし、それらのラッパーをバイナリのみとして配布する場合、ソースコードを共有する人は、メインソリューションをコンパイルするために外部DLLを必要としません。
考慮事項：1。ラッパーコードを分離されたプロジェクトに分離するための追加作業。2.他のVSプロジェクトは、ラッパーDLLへの参照を、「プロジェクト参照」ではなく「LIB」フォルダーへの「ファイルシステム」参照として追加する必要があります。3. VSソリューション構成では、ラッパーDLLのコンパイルを無効にする必要があります。必要に応じて、それらを明示的に再コンパイルするために、新しい構成を追加する必要があります。4.各ラッパーDLLのVSプロジェクト定義には、ビルド後のイベントを含めて、予想される「LIB」フォルダーの場所にコピーする必要があります。5.実行時に、外部DLLはアプリケーションのbinディレクトリまたはマシンのGACに存在するか、明示的にロードされている必要があります。注：それらが欠落している場合、それらが欠落していると実行時エラーが発生するのは、実行時に実際に呼び出されたときのみです。すなわち 一般的な状況でコードがそれらを呼び出さない場合は、それらを持っている必要はありません。6.実行時に、外部DLLのロードエラーをキャッチし、「この関数を使用するには、次の製品をインストールしてください：xyz」というかなりのエラーメッセージをユーザーに表示できます。「AssemblyLoadException...FusionLogViewerを使用してください...など」を表示するよりも優れています。7。アプリケーションの起動時に、不足しているDLLをテストおよび検出し、それらに依存する特定の機能を無効にすることができます。
例：このパターンによれば、Microsoft CRMおよびSAPと統合するアプリケーションを作成できますが、特定の機能、つまりインポート/エクスポートのみを対象としています。
設計時に、開発者がラッパーを変更する必要がない場合は、これらの外部DLLがなくても再コンパイルできます。実行時に、ユーザーがこの関数を呼び出さない場合、アプリケーションはラッパーを呼び出さないため、外部DLLは必要ありません。