I am working with two ATL-based COM projects.
The both implement DllRegisterServer as just
STDAPI DllRegisterServer(void)
{
// registers object, typelib and all interfaces in typelib
return _Module.RegisterServer(TRUE);
}
which ends up calling
::RegisterTypeLib(pTypeLib, bstrPath, szDir);
in atlbase.h:6516.
But for some reason this call makes one of the projects create
HKEY_CLASSES_ROOT\TypeLib\<guid>\<version>\0\win64
when registered using regsvr32.exe on Windows 7 32 bit.
The other project correctly creates
HKEY_CLASSES_ROOT\TypeLib\<guid>\<version>\0\win32
.
Where should I start looking to find and fix this behavior?
It is strongly possible, that the typelibrary is targeted for the win64 platform.
Check the typelibary's attributes. One may access them via ITypeLib::GetLibAttr:
ITypeLib::GetLibAttr(TLIBATTR **ppTLibAttr)
The TLIBATTR structure has a field of type SYSKIND. It contains a value which indicates the platform.
typedef enum tagSYSKIND {
SYS_WIN16 = 0,
SYS_WIN32 = ( SYS_WIN16 + 1 ),
SYS_MAC = ( SYS_WIN32 + 1 ),
SYS_WIN64 = ( SYS_MAC + 1 )
} SYSKIND;
I hope this will help you to solve the problem
You are building either Win32 DLL or x64 DLL, and the type library is an attached resource. As you have discovered ATL projects use RegisterTypeLib API to have the type library registered, and API will register under bitness of the library resource (that is, normally it is original target platform).
I suppose you obtained HKEY_CLASSES_ROOT\TypeLib\<guid>\<version>\0\win64 registration by building/registering x64 configuration.
Another possible cause is that under Project Setting in Visual Studio, under MIDL, General the Target Environment is set incorrectly - this might end up in registering Win32 DLL resource under win64 subkey.
