私のDirectShowアプリケーションには、32ビットWindowsバージョンのIntel Threading Building Blocks（tbb.dll）に対するリンクのソースがないサードパーティのDLL（32ビットDirectShowフィルター）があります。
同じプロセスで自分のDLLでスレッドビルディングブロックを使用したい場合（たとえば、別の32ビットDirectShowフィルター）、このサードパーティのDLLの作成者が使用したのと同じバージョンのVisual Studioを使用する必要がありますか？
編集-バージョンに依存しない_mtライブラリが、このシナリオで使用するのにおそらく最適なライブラリであることに気づきました。サードパーティベンダーがこの_mtdll用にビルドしていない場合はどうなりますか？
私自身のスレッディングビルディングブロックのインストールでは、Visual Studioのバージョン（2005、2008、2010、および「MT」）ごとにtbb.dllのバージョンが異なることに気付きました（まだ何であるかはわかりません）。これの明らかな理由の1つは、異なるバージョンのtbb.dllが異なるバージョンのVisualStudioランタイムライブラリDLLに対してリンクしていることです。検査によってどのバージョンのtbb.dllが必要かを判断することは可能ですか、それとも使用されているコンパイラのバージョンを示すバイナリ内の文字列を探す必要がありますか（サードパーティのDLLはVisual Studioランタイムを静的にリンクしているようです）？
私が知る限り、tbb.dllはマニフェストを使用せず、バージョン管理を並べて使用し、コンパイラのバージョンごとに同じ名前が付けられています。最後の手段は、別のtbb.dllの名前を変更し、インポートライブラリをハックするか、名前を変更したdllを参照するようにインポートすることですが、実際にはこれを避けたいと思います。リンカーオプションを使用してインポートをリダイレクトするクリーンな方法はありますか？
これらのDLLは正常に動作するDirectShowフィルターであるため、VisualStudioランタイムまたはTBBオブジェクトをそれらの間で受け渡すことはありません。これは明らかに危険です。それらの相互作用は、標準のCOMDirectShow呼び出しを介した相互の呼び出しに制限されます。