nightmare with ASP, IIS6 & VC6 PSDK

[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?

[Alex Blekhman]

"Andrew Wan" wrote:

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?

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

[Andrew Wan]

Just shooting in the air. Did you specify output type within XSLT file?

For HTML output it should be this:

<xsl:output method="html"/>

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

Is this a possibility?

[Alex Blekhman]

"Andrew Wan" wrote:

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

<xsl:output method="html"/>

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:variablebut I believe the
test is failing on our client IIS but works on our IIS.

Is this a possibility?

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

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

Andrew,
Is this classic ASP? If so, you're posting to the ASP.NET Group. Try the asp
group.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"Andrew Wan" wrote:

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?

[David Wang]

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
//

On Feb 15, 10:01 am, "Andrew Wan" <[e-mail]:

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

<xsl:output method="html"/>

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

Is this a possibility?

[Jon Paal]

try here:

microsoft.public.xsl

"Peter Bromberg [C# MVP]" <pb*******@yahoo.yabbadabbadoo.comwrote in message
news:A4**********************************@microsof t.com...

Andrew,
Is this classic ASP? If so, you're posting to the ASP.NET Group. Try the asp
group.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"Andrew Wan" wrote:

>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]

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?

"Alex Blekhman" <xf**@oohay.mocwrote in message
news:ed**************@TK2MSFTNGP04.phx.gbl...

"Andrew Wan" wrote:

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

<xsl:output method="html"/>

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

Is this a possibility?

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

[Anthony Jones]

"Andrew Wan" <an************@hotmail.comwrote in message
news:e9**************@TK2MSFTNGP02.phx.gbl...

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?

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.

[Alex Blekhman]

"Andrew Wan" wrote:

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?

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

[Alex Krawarik [MSFT]]

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.)
"David Wang" <w3*****@gmail.comwrote in message
news:11**********************@p10g2000cwp.googlegr oups.com...

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
//

On Feb 15, 10:01 am, "Andrew Wan" <[e-mail]:

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

<xsl:output method="html"/>

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

Is this a possibility?