0
의 COM 문제를 추적하려고, 내가GUID/PROGID/CLSID 혼란
나는 우리의 코드 라인을 가지고 ... 내 코드를 디버깅과 같은 GUID가 다른 방법을 표현 볼 수 보이는 해요 : class __declspec(uuid("{D4F83347-E58E-11d1-9D47-006008098294}")) 를 호출 한 후, 그 사이에
그리고 다양한 레지스트리 재료 : 디버거에서
CLSID clsid;
::CLSIDFromProgID("myProgId",&clsid);
는 CLSID는 {000AFC9A-3347-D4F8-8EE5-D1119D470060}로 표시됩니다. 나에게 이것은 옳지 않기 때문에 너무 유사하다. 그러나 나는 자동적으로 확인할 수있는 것이 아니다 ... 우리는 D4F8과 3347, 9D47을 가지고 있지만 E58E는 8EE5가된다.
내가 이해할 수있는 방법이 있는가? 왜 이런 일이 일어나고, 나는 비교를 위해 똑같이 보이게 할 수있는 방법이 있습니까?
편집 몇 가지 측면 추적을 지우려면은, 내가 확인했습니다 및 Windows 레지스트리와 우리의 등록 스크립트의 CLSID가 너무 {D4F83347-E58E-11d1-9D47-006008098294}으로 제공됩니다 - 그래서 내 uuid(...)을 통해 문제는 내가 생각 관련이 없습니다.
이렇게 우리는 우리의 reg 스크립트에도 이것을 제시합니다. 예를 들어, 레지스트리에서 'HKEY_CLASSES_ROOT \ myProgId \ CLSID = {D4F83347-E58E-11d1-9D47-006008098294}'즉 내 코드에서 게시 한 것과 동일한 형식을 검사했습니다. 그러면 등록 된 것으로 보이지만 다른 형식으로 반환됩니다. 참고로 progIds를 문자열로 사용하여 물건을 동적으로로드하지만 역사적으로 기원이 상실된 커다란 클라이언트 - 서버 시스템입니다. –
음, Regedit.exe로 살펴보고 실제 값을 확인하십시오. 일치하지 않으면 DLL을 다시 등록하는 것을 잊었거나 등록 코드를 디버그해야합니다. –
내 이전 의견에 따라, 그 regedit에서 _IS_. 이것이 우리가 사용하는 _everyehere_ 형식이지만, MSVC++ 디버거는 CLSIDFromProgID()의 결과를 다른 형식으로 보여줍니다. 실제로 - 이것이 단순히 GUIDS를 제공하는 디버거 문제일까요? –