나는 마이크로 소프트와 티켓을 제기와 제안 된 솔루션은 실제 활성화 컨텍스트 버그에 대한 해결 방법입니다.
//Create your own activation context pointing to the manifest
ACTCTX actCtx;
ULONG_PTR pCtxCookie;
//initialize actCtx with your manifest name and path
....
HANDLE hActCtx = CreateActCtx(&actCtx);
ActivateActCtx(hActCtx, &pCtxCookie);
....
//surround EVERY CALL to CreateInstance with the null activation context, otherwise you will get an error on DeactivateActCtx!!!
ULONG_PTR cookie; //do not reuse the pCtxCookie!!!
ActivateActCtx(NULL, &cookie);
HRESULT hr = classA.CreateInstance(__uuidof(SxSNET::SxSClass));
DeactivateActCtx(0, cookie); //deactivate the null context
...
//deactivate and deallocate your actual manifest based activation context
DeactivateActCtx(0, pCtxCookie);
ReleaseActCtx(hActCtx);
해결책은 작동하지 않습니다. 이 솔루션의 문제점은 null 컨텍스트가 격리 된 컨텍스트를 사용하는 .NET 어셈블리가 아닌 등록 된 버전의 .NET 어셈블리에 강제로 바인딩된다는 것입니다. 때문에 GAC 프로세스의 bin 경로에 모든하지만 매니페스트 위치에 보이지 않는 바인딩 검색 로직의 .NET 어셈블리를 호출 할 때 등록이 필요없는 COM 버그가 있습니다. 마이크로 소프트에 따르면
: 융합 관리되는 COM 구성 요소를 정의하고 구현 된 .NET 어셈블리에 대한 실패 프로빙 때문에
이 오류가 발생합니다. .NET 런타임은 실행 가능한 경로 또는 전역 어셈블리 캐시에 상대적인 파일 만 검색합니다. Reg-Free 관리 COM Interop의 경우 루트 매니페스트 경로를 무시합니다.
나는이 미래에 누군가가 도움이되기를 바랍니다.