私は、/ clrスイッチでコンパイルされたC++/CLIアセンブリを持っているとしましょう。そのアセンブリでは、同じアセンブリ内で定義されたアンマネージ（プレーンなC++）クラスを呼び出すマネージクラスがあります。 Visual Studioを使用してデバッグしているときに、コールスタックを見ると、[管理されていない>管理されていない]および[管理されていない]> [管理された]遷移の発生場所が表示されます。C++/CLI：このシナリオでは、Managed-> Unmanagedの遷移がないのはなぜですか？
私の目にはどんなものがありました：マネージドクラスの1つが同じアセンブリからアンマネージクラスの1つを呼び出すと、マネージド/アンマネージドに移行しないのはなぜですか？管理されていないクラスは何とかその背後でマネージドクラスに変わっていますか？
「管理されていないコード」をマシンコードにコンパイルすることをコンパイラに指示していない可能性があるためです。/clrを有効にすると、すべてのコードがILにコンパイルされます。標準のC++コードには問題はなく、サポートされていない言語構造がいくつかあります。
あなたがソースコードファイル内のコードを混入した場合、あなたは切り替えることに#pragmaを使用することができますが：
#pragma managed(push, off)
// Unmanaged code here
// ...
#pragma managed(pop)
// Your ref classes here
// ...
あなたがアンマネージコードの宣言を含む任意のヘッダを#include場合は、これも必要になります。
彼らはマネージ型としてコンパイルされていないが、彼らはで定義されているソースファイルは/clrなし#pragma unmanagedまたは#pragma managed (off)存在するとコンパイルされている場合、彼らはILのではなく、適切なネイティブコードにコンパイルされますダウン。
個人的には、/clrでプロジェクト全体をコンパイルすることはほとんどありません。/clrを必要な特定のソースファイルでのみ使用して、アンマネージタイプと関数が適切なネイティブコードにコンパイルされるようにします。