/ clr：pureプロジェクトの混合DLLを使用する
https://stackoverflow.com/questions/291559
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
DLLと共にプロジェクトを構築しています。
Dllはネイティブコードをサポートする必要があるため、/ clrとして宣言しました。 私のプロジェクトは最初は/ clrプロジェクトでもあり、すべてが順調でした。ただし、いくつかのNUnitテストを含めたいので、メインプロジェクトを/ clrから/ clr：pureに切り替える必要がありました。
すべては引き続きコンパイルされますが、Dll呼び出しは実行時エラーを生成します。 / clrに戻すと、すべて問題ありません
私のDLLでは、エクスポートされた関数は次のように宣言されています：
#define DllExport __declspec( dllexport )
DllExport bool DisplayScan(bool bShow, bool bAllPasses) { }
エクスポートされたすべての関数の実名を含む.defファイルも作成しました
LIBRARY "Controller"
EXPORTS
DisplayScan
メインプロジェクトから、インポートは次のように宣言されます：
#define _DllImport [DllImport("Controller.dll", CallingConvention = CallingConvention::Cdecl)] static
_DllImport bool DisplayScan(bool bShow, bool bAllPasses)
このような問題に遭遇したことはありますか？
解決
OKすべてが今動作しています
実際には、最初から機能しています。
モラル：char *をstd :: stringにキャストしようとしないでください
奇妙なこと：関数から戻るまで/ clrで問題ありません。 / clr：pure
ですぐにクラッシュします他のヒント
基本的に、あなたはサポートされていないことをしています。 / clr：pureおよびネイティブDLLエクスポート。 このMSDNの記事から引用されているように、＆quot;純粋なアセンブリは、純粋なアセンブリのエントリポイントは__clrcall呼び出し規約を使用するため、ネイティブ関数から呼び出し可能です。＆quot;
最善の回避策はわかりません。ただし、少し実験してみると、おそらく__clrcall呼び出し規則を/ clrオプションで利用できます。 こちらのリンク役に立つかもしれません。私が収集できるものから、これらのマネージクラスをエクスポートし、マネージNUnitテストプロジェクトなどのマネージアセンブリ内からそれらを使用できますが、アンマネージエクスポートは別のメソッドシグネチャで保持する必要があります。エクスポート経由で.netクラスを公開するとすぐに、__ clrcall呼び出し規約を使用する必要があることに注意してください。
/ clr：pureの利点
パフォーマンスの向上：純粋なアセンブリにはMSILのみが含まれているため、ネイティブ関数は存在しないため、マネージド/アンマネージドトランジションは不要です。 （P / Invokeを介して行われる関数呼び出しは、このルールの例外です。）
AppDomain Awareness：マネージ関数とCLRデータ型はアプリケーションドメイン内に存在し、それらの可視性とアクセシビリティに影響します。純粋なアセンブリはドメインに対応しているため（タイプごとに__declspec（appdomain）が暗黙的に指定されているため）、他の.NETコンポーネントからタイプと機能にアクセスする方が簡単で安全です。その結果、純粋なアセンブリは、混合アセンブリよりも他の.NETコンポーネントとより簡単に相互運用できます。
非ディスクローディング：純粋なアセンブリはメモリ内にロードでき、ストリーミングすることもできます。これは、.NETアセンブリをストアドプロシージャとして使用するために不可欠です。これは、Windowsのロードメカニズムに依存するため、実行するためにディスク上に存在する必要がある混合アセンブリとは異なります。
Reflection：混合実行可能ファイルをリフレクトすることはできませんが、純粋なアセンブリは完全なリフレクションをサポートします。詳細については、Reflection（C ++ / CLI）を参照してください。
ホストの制御性：純粋なアセンブリにはMSILのみが含まれているため、CLRをホストし、そのデフォルトの動作を変更するアプリケーションで使用すると、混合アセンブリよりも予測可能かつ柔軟に動作します。
/ clr：pureの制限
このセクションでは、/ clr：pureで現在サポートされていない機能について説明します。
Pureアセンブリは、アンマネージ関数によって呼び出すことはできません。したがって、純粋なアセンブリはCOMインターフェイスを実装したり、ネイティブコールバックを公開したりできません。純粋なアセンブリは、__ declspec（dllexport）または.DEFファイルを介して関数をエクスポートできません。また、__ clrcall規則で宣言された関数は、__ declspec（dllimport）を介してインポートできません。ネイティブモジュールの関数は、純粋なアセンブリから呼び出すことができますが、純粋なアセンブリはネイティブ呼び出し可能な関数を公開できないため、純粋なアセンブリの機能を公開するには、混合アセンブリのマネージ関数を使用する必要があります。詳細については、「方法：/ clr：pureに移行する（C ++ / CLI）」を参照してください。
ATLおよびMFCライブラリは、Visual C ++のピュアモードコンパイルではサポートされていません。
Pure .netmodulesは、Visual C ++リンカーへの入力として受け入れられません。ただし、純粋な.objファイルはリンカーによって受け入れられ、.objファイルにはnetmodulesに含まれる情報のスーパーセットが含まれます。詳細については、リンカー入力としての.netmoduleファイルを参照してください。
コンパイラCOMサポート（#import）はサポートされていません。これにより、純粋なアセンブリにアンマネージ命令が導入されるためです。
位置合わせと例外処理の浮動小数点オプションは、純粋なアセンブリでは調整できません。その結果、__ declspec（align）は使用できません。これにより、fpieee.hなどのヘッダーファイルが/ clr：pureと互換性がなくなります。
PSDKのGetLastError関数は、/ clr：pureでコンパイルするときに未定義の動作を引き起こす可能性があります。
conventionCallingConvention = CallingConvention :: Cdeclを呼び出している問題です...そのような関数を定義するか、stdcallまたはclrcallを使用してください。cleclは純粋なC向けです
または問題はここにあります： 関数externを静的ではなく定義します
