Do I really need to register WinHttp on Windows Server 2008 before using WinHttpRequest.5.1?
Basically I think this is a bug in Windows Server 2008, but I am not a COM ninja so it seems equally likely that I'm just doing something dumb. The question is: bug or programmer error?
We use WinHttpRequest (the ActiveX component of WinHttp) to read http:// and https://. The ProgID we are using to look up the component is WinHttp.WinHttpRequest.5.1.
Our application worked fine on XP and Windows Server 2003. Under Windows Server 2008 we would get an error (0x800029C4A "Error loading type library/DLL") loading the type library. Re-registering winhttp fixes the issue. The question is, why?
After numerous deadends, I found the following in the registry.
Windows 2008 Server SP2 as installed:
Name=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{662901FC-6951-4854-9EB2-D9A2570F2B2E}\5.1\0\win32=%SystemRoot%\system32\winhttp.dll
Type=REG_SZ
Data=%SystemRoot%\system32\winhttp.dll
After calling regsvr32 %SystemRoot%\System32\WinHttp.dll, this key changes value:
Name=HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib\{662901FC-6951-4854-9EB2-D9A2570F2B2E}\5.1\0\win32
Type=REG_SZ
Data=C:\Windows\system32\winhttp.dll
My understanding is that keys of type REG_EXPAND_SZ expand system paths like %SystemRoot% but REG_SZ do not. So either the type should be REG_EXPAND_SZ, or the expanded path should be used. Re-registering WinHttp fixes the path and thus fixes WinHttpRequest. (As far as I can tell, XP used C:\Windows\System32\winhttp.dll and Server 2003 used a SxS install that works for me>0
So I think this is a bug, and I filed a bug with Microsoft (or at least as much as I could do from the swamp that is connect.microsoft.com.) But here's the part I don't get: since Windows Server 2008 and Vista are very similar, it seems likely that this issue is present in Vista also. WinHttpRequest has got to be a commonly used object. The masses should be screaming, but after lots of googling I found only one thread where people encountered this problem.
Re-registering winhttp fixes the issue, so that's what we're doing. I'm posting this because a) I just can't believe that it is best practice to re-register this commonly-used component and b) if it is a bug, maybe this will help somebody else.
-Rob
Answer
Yes, this turns out to be a bug in manifest of W2K8, but not necessarily the manifest for Vista. Microsoft seems to be aware of this issue and Microsoft should be able to fix this in next release. Current work around for WinHTTP as well as ServerXmlHttp is to manually register the COM component.