"Ondrej Pokluda" <archiv.ondrej@a...> wrote in message
news:e4CGL17JIHA.1324@T......
> Hi all,
>
> for years we used code like (I used now MSDN code, but we used pretty
> much the same, there is not much rocket science in using createProcessor)
> For test I used createProcessor.xsl from MSDN.
>
> var xslt = new ActiveXObject("Msxml2.XSLTemplate");
> var xslDoc = new ActiveXObject("Msxml2.FreeThreadedDOMDocument");
> var xslProc;
> xslDoc.async = false;
> xslDoc.load("createProcessor.xsl");
> if (xslDoc.parseError.errorCode != 0) {
>    var myErr = xslDoc.parseError;
>    WScript.Echo("You have error " + myErr.reason);
> } else {
>    xslt.stylesheet = xslDoc;
>    var xmlDoc = new ActiveXObject("Msxml2.DOMDocument");
>    xmlDoc.async = false;
>    xmlDoc.load("books.xml");
>    if (xmlDoc.parseError.errorCode != 0) {
>       var myErr = xmlDoc.parseError;
>       WScript.Echo("You have error " + myErr.reason);
>    } else {
>       xslProc = xslt.createProcessor();
>       xslProc.input = xmlDoc;
>       xslProc.addParameter("param1", "Hello");
>       xslProc.transform();
>       WScript.Echo(xslProc.output);
>    }
> }
>
> Never problems other than our errors in xsl or xml format.
> Suddenly we experienced problem. On *SOME* machines this program failed,
so
> far never
> on English version of windows, always on XP. Error was caused at line
>
> xslt.stylesheet = xslDoc;
>
> We have it in C++ as well so using debugger line
>
>  pXSLTmpl->putref_stylesheet(pXSLDoc);
>
> (which is its equivalent in C++ using smart pointers) gives an exception,
> but not _com_error, as is usual, but access violation that is caught by
> catch (...)
>
> By comparing MSDN code and our code I fugured out that changing
>
> var xslDoc = new ActiveXObject("Msxml2.FreeThreadedDOMDocument");
>
> into
>
> var xslDoc = new ActiveXObject("Msxml2.FreeThreadedDOMDocument.3.0");
>
> solves problem. I suspect MSXML update causes problem. So my questions are
>
> 1. What happened during updates of MSXML, that program stopped to work?
> 2. What is necessary and sufficient condition that this bahaviour occures?
> 3. How can we prevent this ?
> 4. Using version-free coms was considered a good practice for reliable
> components.
> Is it no longer true?

I'm not too sure about all your other questions but to the last, yes its no
longer true.

Its better to use the version 3.0 ProgID.  Msxml3 is ubiquitous on the
current windows platforms and certainly on the currently in support ones.

Sometimes due to poor installers the "version-free" prog IDs are redirected
back to older dlls.  This means that from one client to another the
"version-free" prog ID may end up have slightly different behaviours and
features.  In fact with recent updates of IE the pre version 3 classes have
been killed so its possible that on some clients using the older ProgIDs
could fail altogether.

The "version-free" ProgIDs never point to a version later to 3.0 anyway.


-- 
Anthony Jones - MVP ASP/ASP.NET