0

私は現在、Borland C++3.0の時代遅れのインストールを使用してコンパイルしている多くのレガシーコードを持っています。

このコードには、C＃.NETアプリケーションで抽出して使用したいルールエンジンがあります。

ルールエンジンを独自のDLLに抽出する場合、移植する時間がない既存のレガシーコードとC＃.NETアプリの両方からこのDLLを呼び出せるようにする必要があります。

古いBorlandコンパイラを使用してDLLをビルドすると、C＃.NetプロジェクトからDLLを参照する方法がわかりません。DllImportはBadImageFormatExceptionで失敗します。この例外をグーグルで検索すると、64ビット対応のプログラムをコンパイルして32ビットをロードするときに、ほとんどの人がこの問題に遭遇することがわかります。つまり、16ビットDLLを生成していると合理的に確信しており、これに対する回避策はないようです。

32ビットコンパイラとリンカを備えた新しいBorland5コンパイラをダウンロードできますが、それでも同じ問題が発生するため、おそらくそこにも問題があります。

これは私のC＃呼び出しコードです

[DllImport( "C:\\NSDB\\BorlandDLL\\BorlandDLL.dll", ExactSpelling = false, CallingConvention = CallingConvention.Cdecl )]
static extern int Version();

public frmHelpAbout()
{
    InitializeComponent();

    lblIssueVersion.Text =  + Version();
}

これは私のDLLコードです

int Version()
{
    return 93;
}

私のコンパイラフラグとリンカフラグはすべて完全な当て推量です-これが私の主な問題であることを願っています

DLLコードが__stdcall、extern"C"などで装飾されていないことに気づきました。Borland C ++ 3.0が、必要な種類の呼び出し規約を強制するために理解している正しい記号のセットを見つけることができないようです。

だから、質問：

1）DllImportはBorland C ++ 3.0から生成されたコードを処理できますか？1b）そうでない場合、Borland C + 5.5.1コンパイラで動作するようにコードを移植し、DllImportを動作させることができますか？

2）問題を解決できますか？DLLコードを.NETに移植した場合、古いBorlandコードを取得して呼び出すことができるでしょうか。

3）この古いBorlandプロジェクトから必要なコードを簡単に抽出できる革新的なソリューションは他にありますか？

4

3 に答える 3

2

私の知る限り、DllImportは、.Netアプリと同じワードサイズのアンマネージDLLに対してのみ機能します。たとえば、64ビットの.NetアプリのDllImportは64ビットのdllでのみ機能し、32ビットの.Netアプリは32ビットのdllのみをロードできます。 16ビットdll。

いくつかの可能な解決策が思い浮かびます：

  1. スティーブはCOMの使用について言及しました。.Netアプリを64ビットのままにしておきたい場合は、COMを使用して次のように機能させることができます。Cコードを32ビットdllとして再コンパイルし、.Netを使用してそのdllの32ビットCOMラッパーを記述します。次に、64ビットの.Netアプリで32ビットのCOMサーバーを呼び出し、次に32ビットのdllを呼び出します。MSDNには、アンマネージコードとの相互運用に関する情報があります。

  2. dllと.Netアプリの両方を32ビット用にコンパイルします。DllImportはdllをロードできるはずです。（Cコードをでラップextern "C"し、dllでTDUMPまたはDUMPBINユーティリティを実行して、名前のマングリングを確認する必要がある場合があります）。

  3. すべてのCソースコードがある場合、Borlandコンパイラを忘れて、VisualStudioのC++コンパイラでコードをビルドできますか？

于 2009-09-24T14:49:16.887 に答える
0

.netはCOMを呼び出し、COMとして非常に喜んで呼び出すことができます（適切にCOM調整されたhappyの値の場合）。したがって、古いネイティブコードが適切なCOMインターフェイスを提供する場合は、それを直接使用してみることができます（ただし、 32ビットビルド）。

すべてを1つのプロセスに含める必要がない場合、別のアプローチは、コードをC ++ /CLIアセンブリおよびBorlandDLLとしてビルドすることです（ファイルがある場合は、ファイルだけが含まれるファイル.cが必要になります）。 .netプロジェクト）。.cpp#include.c

于 2009-09-24T13:28:24.397 に答える
0

32ビット.NETと32ビットC-DLLの両方を使用している場合は、問題はありません。32ビットアプリケーションから16ビットコードを簡単に呼び出すことはできないとほぼ100％確信しています（ただし、これを行うソリューションを見たことがあると思います。ここで「サンク」という言葉が思い浮かびますか？）。

.NETとDLLの両方が32ビットの場合、上記で行っていることは問題ありませんが、Borland DLLには、他の「通常の」C-DLLとの互換性がないという問題があったことを覚えています。

COMについてのSteveGilhamの答えは無視できると思います。あなたの場合、COMは必要でも、良い選択肢でもないからです。

于 2009-09-24T14:31:27.203 に答える