This means I am unable to use named constants for WinHttpRequestOption,
AutoLogonPolicy, SslErrorFlag, or SecureProtocol, and the
readablity/maintainability of my script code suffers.
Why were the constants removed? What is the best available workaround?
Also, I appear to be unable to lookup the progid via the ObjectLookup
utility, which is odd.
<http://www.codeguru.com/Cpp/COM-Tech/activex/com/article.php/c5525/>.
BL>I've noticed that Windows Server 2003 no longer includes a WinHTTP DLL.
That is wrong. Win2k3 includes Winhttp.dll. But it resides in the
side-by-side assemblies cache (%SYSTEMROOT%\WinSxS folder) not in the
System32.
BL>Perhaps as a consequence of this, I am no longer able to reference the
BL>WinHTTP TypeLib in a WSF script:
BL><reference object="WinHttp.WinHttpRequest.5.1"/>
I am not sure but may be this is due to WinHTTP version in Win2k3 is 5.2 not
5.1.
BL> Why were the constants removed? What is the best available workaround?
Try to use version-independent ProgID "WinHttp.WinHttpRequest.5".
With best wishes,
Alex Ostapenko.
However, while the DLL's file version is now 5.2, the ProgID is still
5.1. "WinHttp.WinHttpRequest.5" or "WinHttp.WinHttpRequest.5.2" cannot
be created, nor can they be used to reference typelibs.
Are TypeLibs going to be abandoned to force us all to move immediately
to .NET, despite the complete lack of a scripting solution?
I was able to duplicate the problem you are experiencing and am
investigating the cause. I will give you an update once the problem is
understood.
Thanks,
Biao.W. [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
<reference guid="{662901FC-6951-4854-9EB2-D9A2570F2B2E}" version="5.1"/>
That is, instead of specifying the ProgId of the WinHttpRequest object,
specify
the GUID and version of WinHTTP's type library.
Stephen
Is there a registry fix to make the progid lookup this guid?
Thanks!
Not that I am aware of.
From what I understand of this problem, it is either a bug in Windows
Scripting Host, or by-design, as a side-effect WinHTTP being a side-by-side
assembly component on Windows Server 2003 (or perhaps a bit of both).
We confirmed this being a bug due to WSH not being able to lookup typelib
guid correctly for SxS components. Thanks for reporting the issue to
Microsoft.
I believe the workaround suggested by Stephen is the only workaround for
this issue.
We are looking into the possibility of including a fix in the upcoming SP1
release of Windows Server 2003.
Biao.W. [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
I had a similar problem.
We had a Windows 2000 Server and now we have a PHP script running on a
Windows 2003 Webedition.
> Is there a registry fix to make the progid lookup this guid?
I copied the WinHTTP.dll from the SxS directory to the System32 folder.
I used REGSVR32.EXE to register the DLL.
It seems to be working now!
Louis
"Brian Lalonde" <bri...@stcu.org> wrote in message
news:O6KQlqqy...@TK2MSFTNGP11.phx.gbl...