Microsoft MVP성태의 닷넷 이야기
Managed 어셈블리에서의 COM EntryPoint procaddress 문제 [링크 복사], [링크+제목 복사],
조회: 15429
글쓴 사람
뽀로로
홈페이지
첨부 파일
 

COM쪽 지식이 부족하여, 질문에 상황 설명이 정확하게 될 수 있을지 모르겠습니다만 양해 부탁드리겠습니다.

현재 상황은 아래와 같습니다.
이전에 W32기반으로 개발된 내부 엔진이 있는 상태이며, 이 엔진은 COM으로 제작된 DLL들을 통해 확장 기능을 구현하고 있습니다. UI또한 이런 식으로 확장이 되어 있는데, 현재 .NET 3.5CF 기반으로 제작된 WPF 기반의 UI 어플리케이션과 이 엔진을 연동해야 할 필요성이 생긴 상태입니다.

기존의 경우, 엔진과 UI 확장 모두 W32기반으로 구성되어 있고 이를 위한 COM 인터페이스는 확정이 된 상태라, COM interop을 통해 이를 구현하는 managed assembly로 UI기반을 대체하고 이를 UI 어플리케이션과 연동하고자 하는 계획을 가지고 있습니다. 헌데 문제는, 엔진 내부에서 확장 모듈을 불러 올 때 명시적으로 몇몇 EntryPoint를 체크하고 있는데, DllCanUnloadNow() / DllGetClassObject()의 두 함수의 주소를 확장 DLL 로딩시에 반드시 저장하도록 하고 있습니다만 Managed 어셈블리에서는 이 Entrypoint를 찾지 못하고 있습니다. 제 COM interop 구현에 문제가 있는 것인지, 아니면 우회할 수 있는 방법이 있는지 여쭙고자 질문을 드립니다.








[최초 등록일: ]
[최종 수정일: 12/12/2011]


비밀번호

댓글 작성자
 



2011-12-13 10시28분
다소 이해할 수 없는 상황인데요. 해당 COM 개체로부터 DllCanUnloadNow/DllGetClassObject 함수의 주소를 가져올 수 없다면 - 즉 EntryPoint를 가져올 수 없다면, '사용'하는 것 역시 안되어야 정상일텐데요. (개별적인 사용은 되나요?)

그리고, 위의 글 만으로는 제가 추측할 수 있는 방법이 거의 없습니다.

'Win32 기반으로 개발된 내부 엔진'이라고 했으니... 어쨌든 그 엔진의 소스 코드를 디버깅하면 쉽게 나올 수 있는 문제가 아닐까 싶은데요. 어차피 정형화된 GetProcAddress와 LoadLibrary를 사용하고 있을테니까요.
정성태

NoWriterDateCnt.TitleFile(s)