타사 구성 요소에 대한 COM 대리자

두 개의 타사 구성 요소에 액세스해야하는 데이터를 결합해야하는 작은 DLL 구성 요소를 작성 중이며 그 중 하나는 32 비트 전용이고 다른 하나는 64 비트 전용입니다. 둘 다 TypeLib에 등록되어 있으며 Automation과 호환되므로 마샬링이 문제가되어서는 안됩니다.타사 구성 요소에 대한 COM 대리자

설명서를 올바르게 이해했다면 구성 요소에도 AppID 및 DllSurrogate 키가없는 한 대리모에서 강제로로드 할 수있는 방법이 없습니다. 둘 다 제 3 자 구성 요소이기 때문에 등록을 수정하는 것이 다소 바람직하지 않습니다.

여분의 종속성이없는 DLL 구성 요소의 대리 프로세스에서 AppID가없는 구성 요소의 개체를 활성화하는 방법이 있습니까? 아니면 아무도 왜 이것이 나쁜 아이디어라고 설명 할 수 있습니까?

출처

2011-12-16 Simon Richter

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682432 % 28v = vs.85 % 29.aspx –

사용자 지정 대리자가 서버 구성 요소에 AppID가 있어야하므로 COM은 클래스를 인스턴스화 할 대리자를 알 수 없습니다. ? 이를 추가하면 이는 내 구성 요소뿐만 아니라 모든 클라이언트에도 영향을 미칩니다. 표준 구성의 대리인은 잘 작동해야합니다. –

[Raymond Chen] (http://blogs.msdn.com/b/oldnewthing/archive/2009/02/12/9413816.aspx)는 Explorer가 * DllSurrogate로 등록되지 않은 'CoCreateInstance' 개체를 어떻게 든 사용할 수 있다고 제안합니다 * 그들이 대리모에서 만들어 지도록 열쇠 - 나는 방법에 흥미가있을 것입니다. –

예, 다음과 같은 방법으로 대리 용으로 32 비트 전용 DLL을로드하고 64 비트 프로세스에서 액세스 할 수 있습니다. 사용할 수있는 마샬 러가 있으면 일반적으로 표준 마샬 러를 사용하기 때문에 일반적으로 형식 라이브러리가있는 구성 요소가있을 경우 작동합니다. 객체가 64 비트 버전이 존재하지 않거나 처음부터이 문제가 없기 때문에 객체가 사용자 정의 prox/stub을 요구하면 작동하지 않습니다.

먼저 AppID가 필요합니다. DLL에 이미 AppID가있는 경우이를 사용해야합니다. 관심있는 CoClass의 CLSID 키를 확인하면 알 수 있습니다.

여기에 사용 된 예제는 Capicom.HashedData 및 Capicom.EncryptedData 클래스입니다. Capicom은 32 비트 전용입니다.

32 비트 버전이므로 Regedit의 32 비트 버전을 사용해야합니다. 32 비트에서 액세스하려는 64 비트 구성 요소가있는 경우 다른 구성 요소를 사용하십시오. (이것은 32 비트 호환성 레이어의 레지스트리 가상화 때문입니다. regedit의 일치하는 bitness 버전을 사용하면 올바른 가상 버전의 레지스트리를 편집하여이 문제를 해결할 수 있습니다.

Windows Registry Editor Version 5.00 


;;; Capicom AppID - just using the Capicom.EncryptedData CLSID 
;;; Use default surrogate = empty string 
[HKEY_CLASSES_ROOT\AppID\{A440BD76-CFE1-4D46-AB1F-15F238437A3D}] 
"DllSurrogate"="" 

;;; Capicom.EncryptedData 
[HKEY_CLASSES_ROOT\CLSID\{A440BD76-CFE1-4D46-AB1F-15F238437A3D}] 
AppID="{A440BD76-CFE1-4D46-AB1F-15F238437A3D}" 

;;; Capicom.HashedData - use same AppID for all!!!!! 
[HKEY_CLASSES_ROOT\CLSID\{CE32ABF6-475D-41F6-BF82-D27F03E3D38B}] 
AppID="{A440BD76-CFE1-4D46-AB1F-15F238437A3D}"

myComponent-dllhost.reg 파일에 저장하면됩니다.

c:\windows\sysWow64\regedit.exe "myComponent-dllhost.reg"

이제 64 비트 스크립트/COM 호스트에서 Capicom.HashedData 및 Capicom.EncryptedData에 액세스 할 수 있어야합니다.

참고 : 기본 OLE 자동화 유형에 대한

이 경우에만 작동합니다. VBScript 또는 JavaScript의 Windows Scripting Host 스크립트와 호환되는 모든 개체는 OK 여야합니다.
직접 생성 가능한 개체에만 AppID를 추가해야합니다. 기본적으로 InprocServer32 항목이 있습니다. 팩토리에서 생성되거나 자식 객체로만 사용할 수있는 객체에는 AppID가 추가 될 필요가 없습니다.
이미 AppID가있는 경우 빈 문자열 "DllSurrogate"항목을 추가하면됩니다. 그게 다야!
은 DLL의 일반 클라이언트에 영향을줍니다. 비트가 일치하는 한 이전과 마찬가지로 프로세스 내에서 계속로드됩니다. 유일한 차이점은 다른 bitness의 클라이언트에서 out-of-process를 인스턴스화하는 것이 가능해진다는 것입니다.

출처

2012-01-17 19:35:17 Ben

나는 이미 그 일을했지만 설치자로부터 다른 구성 요소 (이 경우, Lotus Notes 및 Rational ClearCase)의 등록을 수정하는 것을 꺼려하여 레지스트리를 수정하지 않고도이 작업을 수행 할 수 있는지 궁금합니다. . –

부끄러워하지 마십시오! OTOH, 정말로 원한다면 같은 비트의 도우미 객체를 만들 수 있습니다.이 객체는 단지'HRESULT CreateObject ([in] BSTR progID, [out, retval] IUnknown ** ppRetVal)'메소드를 가지고 있습니다. 대리인 내부에서 객체를 생성하고 반환하십시오. – Ben

그게 좋은 생각입니다. –

타사 구성 요소에 대한 COM 대리자

답변

관련 문제