VS によってビルドされた (純粋なネイティブ C++) .DLL があります。クライアントとして、ネイティブ C++ アプリケーションと、C++/CLI で記述されたこの DLL の .Net-Wrapper があります。最後に、C# で記述された .Net-Wrapper 用のクライアント アプリケーションがいくつかあります。
問題は、native.dll を .Net の世界とは異なる方法で配布する必要があり、VS がその DLL を追跡しないことです。そのため、すべての C# アプリを正しく動作させるには、各実行可能ディレクトリにコピーするか、%PATH% 内のどこかに配置する必要があります (開発者のコンピューターでは、異なるバージョンの DLL を使用して異なるアプリを起動する可能性があるため、この方法は避けます)。ラッパー DLL を参照する UserControls がある場合は、さらに大きな問題が発生します。DLL を VS のディレクトリにコピーするか、再度 %PATH% にコピーする必要があります。しかし、最悪のケースは Translator ツールで発生します。このツールは .Net アセンブリを追跡し、外部のトランスレータに送信できる Translator パッケージにパックします。私の知る限り、ネイティブ .DLL をそのパッケージに配置する方法はありません。
そこで、ネイティブ DLL を .Net-Wrapper に静的にリンクして、問題を解決する予定です。ただし、ネイティブ アプリケーションの場合、このネイティブ DLL は依然として DLL である必要があります。
したがって、2 つの選択肢があります。
- 2 つのプロジェクトを作成します (1 つは静的ライブラリを生成するプロジェクト、もう 1 つは動的ライブラリを作成するプロジェクト => これを避けるようにします)
- DLLを静的にリンクするソリューションを見つける
- VS が 1 つのプロジェクトから 2 つの出力を生成する方法を見つける
ベストアンサー1
dll の C++ プロジェクト ファイルで、DLL を生成する構成と .lib を生成する構成の 2 つの構成を作成します。.NET/C++ プロジェクトは複数のビルド構成をサポートできるため、2 つのプロジェクトは必要ありません (リリース バージョンとデバッグ バージョンのビルドが異なるのは、このためです)。