nightmare with ASP, IIS6 & VC6 PSDK

  • Thread starter Thread starter Andrew Wan
  • Start date Start date
A

Andrew Wan

I have been having a nightmare with ASP/ASP.NET & IIS6.

We use Msxml2.DOMDocument.4.0 object to create a XML object in ASP. The
Msxml2.DOMDocument.4.0 is from the Windows Platform SDK Feb 2003 (the last
version compatible with VC6). Then we use
TranslateXSLT(XMLDocument.transformNode) passing in a xsl file path. Our
pages work perfectly fine under IIS5 & IIS6 onsite. However strange things
happening at our clients IIS6:

- transformation just displays the xml nodes instead of the html code.

Probably it's nothing to do with IIS6. Maybe it's Msxml2.DOMDocument.4.0
from Platform SDK Feb 2003?

Anyone has any ideas?
 
Andrew Wan said:
I have been having a nightmare with ASP/ASP.NET & IIS6.

We use Msxml2.DOMDocument.4.0 object to create a XML
object in ASP. The
Msxml2.DOMDocument.4.0 is from the Windows Platform SDK
Feb 2003 (the last
version compatible with VC6). Then we use
TranslateXSLT(XMLDocument.transformNode) passing in a xsl
file path. Our
pages work perfectly fine under IIS5 & IIS6 onsite.
However strange things
happening at our clients IIS6:

- transformation just displays the xml nodes instead of
the html code.

Probably it's nothing to do with IIS6. Maybe it's
Msxml2.DOMDocument.4.0
from Platform SDK Feb 2003?
Click to expand...


Just shooting in the air. Did you specify output type within
XSLT file? For HTML output it should be this:

<xsl:output method="html"/>


Alex
 
Just shooting in the air. Did you specify output type within XSLT file?
For HTML output it should be this:

<xsl:output method="html"/>
Click to expand...

Sorry, actually it's outputting html fine. However the logic condition
<xsl:when test="$var = 'here'"></xsl:when> is not working we believe. All
other text variables are assigned correctly using <xsl:variable> but I
believe the test is failing on our client IIS but works on our IIS.

Is this a possibility?
 
Andrew Wan said:
Sorry, actually it's outputting html fine. However the
logic condition <xsl:when test="$var = 'here'"></xsl:when>
is not working we believe. All other text variables are
assigned correctly using <xsl:variable> but I believe the
test is failing on our client IIS but works on our IIS.

Is this a possibility?
Click to expand...


I have hard time believeing that the same version of XSLT
processor behaves differently on other machine. Probably
`$var' contains something different than "here". You can try
`ms:string-compare' function if you need case insensitive or
language dependant comparison.

Alex
 
Andrew,
Is this classic ASP? If so, you're posting to the ASP.NET Group. Try the asp
group.
Peter
 
Do you and your client have the same msxml4.dll binary in %windir%
\System32 ?

msxml4.dll is 32bit-only and does not ship as a part of any version of
Windows, so you both have to install its Redistributable separately...
and the question is whether you are using the same binary version.

I suspect you are not using the same msxml4.dll as your client, and
either you have fix or the customer has a regression in msxml4.dll.
There have been patches of msxml4.dll.

In which case this issue has nothing to do with ASP, IIS6, VC6, nor
ASP.Net, so take back your claims of a nightmare with that
combination! :-)


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
 
I am aware there are two XSLT versions (1.0 and 2.0). Also my conditional
logic is like:

<xsl:choose>
<xsl:when test="$var = 'here'"></xsl:when>
<xsl:otherwise>
<xsl:call-template name="Toolbar1"/>
</xsl:otherwise>
</xsl:choose>

When $var does contain 'here', the call-template still gets executed. So am
wondering whether XSLT 2.0 bypasses a xsl:when clause when it's empty?
 
Andrew Wan said:
I am aware there are two XSLT versions (1.0 and 2.0). Also my conditional
logic is like:

<xsl:choose>
<xsl:when test="$var = 'here'"></xsl:when>
<xsl:otherwise>
<xsl:call-template name="Toolbar1"/>
</xsl:otherwise>
</xsl:choose>

When $var does contain 'here', the call-template still gets executed. So am
wondering whether XSLT 2.0 bypasses a xsl:when clause when it's empty?
Click to expand...

I note this Q has not yet appeared in microsoft.public.xsl. You really
should post it there you will get more focused support there than here.
 
Andrew Wan said:
I am aware there are two XSLT versions (1.0 and 2.0). Also
my conditional logic is like:

<xsl:choose>
<xsl:when test="$var = 'here'"></xsl:when>
<xsl:otherwise>
<xsl:call-template name="Toolbar1"/>
</xsl:otherwise>
</xsl:choose>

When $var does contain 'here', the call-template still
gets executed. So am wondering whether XSLT 2.0 bypasses a
xsl:when clause when it's empty?
Click to expand...


First of all, MSXML4 supports XSLT v1.0. Moreover, you must
specify XSLT version with `version' attribute of
`xsl:stylesheet' element:

<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
....
</xsl:stylesheet>

Second, you can spare redundant `xsl:otherwise' element if
you use `!=' operator:

<xsl:when test="$var != 'here'">
...
</xsl:when>

Actually, in the code you posted, the whole `xsl:choose' can
be replacd with single `xsl:if':

<xsl:if test="$var != 'here'">
<xsl:call-template name="Toolbar1"/>
</xsl:if>

Also, if you have an access to Visual Studio 2005 or
Altova's XMLSpy, then you will be able to debug XSLT
processing step by step and examine variables during
transformation.

HTH
Alex
 
Some good suggestions going on in this thread; outside of the implementation
details, I'd like to reenforce a few things:

At this time, Microsoft only supports XSLT 1.0 in *all* of its native and
managed XSLT engine implementations. XSLT 2.0 became a recommendation a very
short while ago and we are working towards that end, but the XSLT spec
version is not your issue here.

We have been trying to get the message out: when possible, do not develop
against MSXML 4.0. It's nearing its end of life, which means at some point
in the future it will stop being supported in the browser, and on future
versions of Windows. As others have mentioned, its also an x86-only binary.
When possible use MSXML 6.0. MSXML 6.0 supports ia64 and x64 as well as x86,
and we are working very hard to increase its installed base. If you are
concerned about the currently installed base (re: MSXML 6.0), and are not
redisting MSXML yourself, then develop against MSXML 3.0, which is quite
up-to-date wrt security and reliability and is found on every supported
Windows platform.

IF your issue does in fact turn out to be due to a regression in MSXML 4 on
one sever vs the other, I'd love to know about it. (Pls send a repro my
way.)
 
Back
Top