/CLR에서 혼합 DLL 사용 : 순수한 프로젝트
https://stackoverflow.com/questions/291559
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
DLL과 함께 프로젝트를 구축하고 있습니다.
DLL은 기본 코드를 지원하므로 A /CLR로 선언했습니다. 저의 프로젝트는 초기에도 /CLR 프로젝트였으며 모든 것이 괜찮 았습니다. 그러나 나는 몇 가지 수녀 테스트를 포함 시키려고하므로 메인 프로젝트를 /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)
그런 문제를 겪은 사람이 있습니까?
해결책
좋아, 이제 모든 것이 작동하고 있습니다
실제로, 그것은 처음부터 작동했습니다.
Moral : char*를 std :: string에 던지려고하지 마십시오.
이상한 것 : 함수에서 돌아올 때까지 /clr에서 괜찮습니다. /clr : pure에서 즉시 충돌합니다
다른 팁
기본적으로 당신은 지원되지 않는 일을하고 있습니다. /CLR : 순수하고 기본 DLL 수출. 인용 된대로 이 MSDN 기사 "순수한 어셈블리의 진입 지점은 __clrcall 호출 협약을 사용하기 때문에 순수한 어셈블리는 기본 기능에서 호출 할 수있는 기능을 수출 할 수 없습니다."
최고의 해결 방법을 잘 모르겠습니다. 그러나 약간의 실험으로 /CLR 옵션을 사용하여 __clrcall 통화 규칙을 활용할 수 있습니다. 여기 링크가 있습니다 유용 할 수 있습니다. 내가 수집 할 수있는 것에서 당신은 관리 된 클래스를 내보내고 관리 된 Nunit 테스트 프로젝트와 같은 관리 조립품 내에서 소비 할 수 있어야하지만 관리되지 않은 수출을 다른 방법 서명으로 유지하십시오. 수출을 통해 .NET 클래스를 노출하자마자 __clrcall 전화 컨벤션을 사용해야합니다.
/CLR의 장점 : 순수합니다
더 나은 성능 : 순수한 어셈블리에는 MSIL 만 포함되므로 기본 기능이 없으므로 관리/관리되지 않는 전환이 필요하지 않습니다. (P/Invoke를 통해 이루어진 기능 호출은이 규칙의 예외입니다.)
AppDomain 인식 : 관리 기능 및 CLR 데이터 유형은 애플리케이션 도메인 내에 존재하므로 가시성 및 접근성에 영향을 미칩니다. 순수한 어셈블리는 도메인 인식 (__declspec (appdomain)이 각 유형에 대해 암시 됨)이므로 다른 .NET 구성 요소에서 유형과 기능에 액세스하는 것이 더 쉽고 안전합니다. 결과적으로, 순수한 어셈블리는 혼합 어셈블리보다 다른 .NET 구성 요소와 더 쉽게 상호 작용합니다.
비 디스크 로딩 : 순수한 어셈블리는 메모리에서로드하고 심지어 스트리밍 할 수 있습니다. 이는 .NET 어셈블리를 저장 절차로 사용하는 데 필수적입니다. 이는 Windows 로딩 메커니즘에 대한 의존성으로 인해 실행하려면 디스크에 존재 해야하는 혼합 어셈블리와 다릅니다.
반사 : 혼합 실행 파이브를 반사하는 것은 불가능하지만, 순수한 어셈블리는 완전한 반사지지를 제공합니다. 자세한 내용은 반사 (C ++/CLI)를 참조하십시오.
호스트 제어 성 : 순수한 어셈블리에는 MSIL 만 포함되므로 CLR을 호스팅하고 기본 동작을 수정하는 응용 분야에 사용될 때 혼합 어셈블리보다 더 예측 가능하고 유연하게 행동합니다.
/CLR의 한계 : 순수한
이 섹션에서는 현재 /CLR : Pure가 지원하지 않는 기능을 다룹니다.
순수한 어셈블리는 관리되지 않는 기능으로 호출 할 수 없습니다. 따라서 순수한 어셈블리는 COM 인터페이스를 구현하거나 기본 콜백을 노출시킬 수 없습니다. 순수한 어셈블리는 __declspec (dllexport) 또는 .def 파일을 통해 기능을 내보낼 수 없습니다. 또한 __clrcall 컨벤션으로 선언 된 기능은 __declspec (dllimport)를 통해 가져올 수 없습니다. 기본 모듈의 함수는 순수한 어셈블리에서 호출 될 수 있지만 순수한 어셈블리는 기본적으로 전달 가능한 기능을 노출시킬 수 없으므로 혼합 어셈블리의 관리 기능을 통해 순수한 어셈블리에서 기능을 노출해야합니다. 자세한 내용은 방법을 참조하십시오 : /CLR : Pure (C ++ /CLI)로 마이그레이션하십시오.
ATL 및 MFC 라이브러리는 Visual C ++의 순수한 모드 컴파일에 의해 지원되지 않습니다.
순수한 .netModules는 Visual C ++ 링커에 대한 입력으로 허용되지 않습니다. 그러나 순수한 .obj 파일은 링커에 의해 허용되며 .obj 파일에는 netModules에 포함 된 정보가 포함되어 있습니다. 자세한 내용은 .netModule 파일을 링커 입력으로 참조하십시오.
Compiler Com Support (#import)는 지원되지 않습니다.
정렬 및 예외 처리를위한 부동 소수점 옵션은 순수한 어셈블리의 경우 조정할 수 없습니다. 결과적으로 __declSpec (정렬)를 사용할 수 없습니다. 이로 인해 fpieee.h와 같은 일부 헤더 파일, /clr : pure와 호환되지 않습니다.
PSDK의 getLasterror 함수는 /CLR : Pure와 컴파일 할 때 정의되지 않은 동작을 제공 할 수 있습니다.
귀하의 문제는 ConventionCallingConvention = CallingConvention :: CDECL을 호출하는 것입니다. CDECL ... 그 기능을 정의하거나 stdCall 또는 clrcall을 사용합니다. Clecl은 순수한 C입니다.
또는 문제는 여기에 있습니다 : 해당 기능을 정적으로 정의하지 않음 정의
