私は最適化アルゴリズムに取り組んでいるので、パフォーマンスが本当に重要です。VS2008でコンパイルした場合のアルゴリズムはVS2008と比較して約8倍高速です。グーグルはそれが私のせいではないことを示しています（例：https ：//stackoverflow.com/a/5560184/890355を参照）。問題は、最終的なプロジェクトをVS2008でビルドする必要があることです。
私がよく使う解決策は、VS 2010でDLLとしてアルゴリズムを構築し、それをメインプロジェクトにリンクすることです。VS2008でDLLでVC++2010ランタイムライブラリを使用することは可能ですか？もしそうなら、それを行うための最も痛みの少ない方法は何ですか？他のアイデアはありますか？ありがとう。
ランタイムは問題ではありません。DLLをVC2010ランタイムにリンクし、そのDLLを他のプロジェクトで使用することを妨げるものは何もありません。これらのプロジェクトがVisualC++2008またはその他の言語を使用して構築されているかどうかは関係ありません。
トリッキーな部分は、DLLインターフェイスの設計です。一部のC++クラスをエクスポートするだけでは、異なるコンパイラ間の非互換性にさらされるため、リスクが伴います。あなたの最善の策は、Cスタイルのインターフェースを公開するか、COMを使用することだと思います。COMが最善のアプローチだと思いますが、テクノロジーに慣れていない場合は、Cスタイルのインターフェイスで問題なく動作します。（インターフェースが単純な場合、COMもやり過ぎになる可能性があります。）
注意すればできます。MSのドキュメントにいくつかのヒントが記載されています。私はここの前にこの質問に答えました：
Visual Studioの下位バージョンが、Visual Studioの上位バージョンを使用して構築されたdllを使用できるかどうか疑問に思っていますか？
2010部分を外部のDLLに移動する以外に、2008ライブラリと2010ライブラリを1つの実行可能ファイルに結合する他の方法を求める場合、答えはおそらく「これを実現する他の簡単な方法はありません」です。
ただし、「VS2008でのVC++ 2010ランタイムライブラリ...（古い2008 IDEの2010ライブラリに対して構築されている）」ではなく、「2008でコンパイルされたプログラムで2010でコンパイルされたDLLを使用する」場合、それは完全に可能です。
プロジェクトで行う最も簡単な方法は、静的にリンクされた標準ライブラリ（MFCを使用する場合）に対してビルド（.exeとDLLの両方）してLoadLibraryから、.exeで使用してDLLをロードすることです。_declspec (dllexport)DLLでは、関数（できればextern "C" {}ガード内）をエクスポート（ ）して、.exeから.exeで使用できGetProcAddressます。
静的リンケージと明示的なロードにより、さまざまなランタイムによって引き起こされる多くの不整合のバグからあなたを救うことができます。
DLLの読み込みと関数呼び出しのコストが心配な場合は、これらの呼び出しをできるだけ少なくすることができます（おそらく、アルゴリズムだけでなく、より高レベルのロジックもDLLに移動することによって）。このissieも参照してください。
また、ネイティブマルチターゲティングを使用してすべてのコードを1つのIDE（2010）でビルドできます（ただし、メインアプリとDLLをそれぞれv9ライブラリとv10ライブラリに対して別々にビルドする必要があります）。