バックグラウンド
私たちのビルドは、ant とカスタム タスクを使用して、Visual Studio プロジェクト/ソリューションと一部の Java プロジェクトをビルドします。その構造は基本的に大きなツリーであり、プロジェクトからの成果物は通常、共通のビルド ディレクトリにコピーされます。
これは以前は完全に混乱していましたが、ant スクリプトを大幅に簡素化し、現在は Visual Studio プロジェクト/ソリューションのほとんどを使用しています。これらのプロジェクトは非常に古く、2013 年までのすべてのバージョンの Visual Studio でアップグレードされています。私が行った変更の一部は、既定のプロジェクト プロパティとマクロをできるだけ多く使用することでした。これらのほとんどは、以前はハードコードされていました。
$(Configuration) マクロを使用して成果物をさまざまな構成から分離するようにプロジェクトを変更しましたが、これらは他のソリューションの他の依存プロジェクトの共通の場所にコピーされます。そのため、混乱を避け、実際にデバッグ ビルドがすべてのデバッグ ライブラリにリンクしていることを確認するために (以前は発生していませんでした)、ターゲット名にサフィックスを追加しました。たとえば、デバッグ Unicode ビルドのターゲット名は $(ProjectName)DU になります。
問題
これまでのところこれは素晴らしいことですが、COM ライブラリの 1 つでこれらの変更を完了する方法がわかりません。このライブラリには IDL ファイルがあり、MIDL コンパイラは TLB ファイルを生成します。これは良い方法ではないかもしれませんが、今のところ、ビルドに応じて TLB ファイルにも異なる接尾辞を付けたいと思いました。問題は、MIDL 構成のタイプ ライブラリ プロパティを変更すると、RC ファイルのコンパイル時ディレクティブが壊れることです。_UNICODE または _DEBUG が設定されているかどうかに応じて、TEXTINCLUDE ブロックで #ifdefs を使用できる可能性があると考えました (RC ファイルを壊さないように [リソース インクルード] ダイアログを介して行う場合)。また、#ifdef チェックが必要な他の importlib 属性があることも意味します。
現時点では、TLB ファイルの名前を変更しなくても機能しますが、それは現在、このソリューション内でのみ使用されているためです。
誰かがこのようなことをしたことがありますか、またはより良い解決策を知っていますか?
アップデート
ここで本当に知っておく必要があるのは、ある COM DLL の型を別の COM DLL で使用する最良の方法は何ですか? importlib を使用する必要がありますか? MSDN のドキュメントによると、ほとんどの場合、代わりにインポートを使用する必要があります。私はこれを試しましたが、たくさんのものを壊しました。