C ++とVB6にCOMオブジェクトがあり、すべてがVisual Studio 2003を使用してコンパイルおよびパッケージ化されています。C++はDLLを生成し、VB6はEXEを生成するため、レガシーコードからDLLを呼び出すEXEなどを呼び出すことができます。
これらをVisualStudio2008に移行する必要があります。ただし、いくつか質問があります。
1）C ++をコンパイルしてDLLを生成できます-（大丈夫だと思います）2）VB.NetにはVB6としてCOM / ActviveXを生成するオプションがないため、わかりません-Windowsexeを生成して呼び出しますdllですが、機能しません。いくつかのCOM呼び出しがあるからだと思います。
では、COM / ActiveXを取り除き、何かを提供するための最良の解決策は何でしょうか。
C ++でコンパイルし、VB.netで参照を追加してロードしますか？これを試しましたが、DLLがロードされません........。
VBコードがアウトプロセスCOMサーバーなのか、C ++inprocCOMオブジェクトを使用するクライアントなのかを明確にしていません。
VBコードがクライアントの場合は、コクラスへのCOM参照を使用して、VB.Net実行可能ファイルとしてビルドを使用できます。ビルド中にC ++オブジェクトを登録したくない場合は、タイプライブラリのTlbImpツールを使用して、VB.Netコードから参照するマネージド相互運用機能アセンブリを生成します。
VB.CodeがアウトプロセスCOMサーバーである場合は、COMを介してクレジットできるようにするクラスにCOMVisible属性をマークしてから、RegAsmツールを使用してアセンブリをCOMに登録する必要があります。
もう1つの方法は、C++コードをマネージC++としてコンパイルし、VBコードから標準のマネージアセンブリとして参照することです。このアプローチの利点は、COM相互運用レイヤーを完全にバイパスし、管理された世界に完全にとどまることができることです。これには、特定の完全な利点があります。一方、2つの欠点があります。a）GACに配置しない限り、その特定のクライアントだけがC ++コードにアクセスできること、およびb）マネージC++の記述には少しの立ち上げが必要です。あなたのシナリオでは、COMはVB6コードから低レベルのC ++に移行するための便利な方法としてのみ使用されたように思われるため、最初のものが影響を与えるとは思いません。ただし、2つ目は問題が発生する可能性があります。
更新：コメントの更新に基づくと、実際にはVBコードから直接呼び出されるC ++コードがあり、他のクライアントからCOMを介して呼び出されているようです。
これが実際に当てはまる場合は、VB6コードをVB.Netとして再コンパイルし（2つのプラットフォームは完全に同一ではないため、コードにいくつかの変更を加える必要がある場合があります）、COMVisibleを使用して公開することをお勧めします。 COMオブジェクトとして使用し、P /Invokeを使用して現在のC++コードを消費します（これは、現在VB6コードが消費する方法とかなり似ています）。C++をマネージC++コンポーネントとして再コンパイルする必要はありません。
少し誤解しているようです。.netは、COM/VBとは完全に異なる環境です。.netが管理されている間、これらはいわゆるアンマネージコードです。InterOpと呼ばれるものを使用して一方から他方に呼び出すことができます（これには多くの種類があります）。
最初のvb6-これを.netに変換するには、アプリケーションを再コーディングする必要があります。.netはVBではありません。言語は似ていますが。
.netもアクティブではありませんX。c ++ dll（comまたはその他の方法で.netに）を再コンパイルすることはできません。ただし、マネージコードとアンマネージコードの間にあるマネージC++と呼ばれる特別なバージョンのC++があります。
次のオプションがあります。
C ++ DLLが通常のDLL（COMではない）であるかのように聞こえ、Declareステートメントを使用してVB6にアクセスできました。
2つのオプションがあります。