This info is for those of you who are using the transformNodeToObje­ct method

in an ASP page to send the results of the transform directly to the ASP

Response object.

The security update 955069 includes a change in behaviour where the IStream

passed in the output parameter has its Commit method called where in older

version this never called. The IStream implemention in on ASP Response

object will through an error if its Commit method is called.

Workarounds:

1. Don't install 955069 (not recommend its a security update).

2. Create an IStream wrapper object that delegates to an inner IStream

except the Commit method.

3. Don't use transfomNodeToObjec­t just transformNode and Response.Write

4. Send XML and get your client to do the transform

Option 2 only really an option if you the tools and the control over the

server to implement it.

Option 3 if you were generating large content with buffering turned off

transformNodeToObje­ct is pretty effecient, with transformNode and

Response.Write you are going to use more memory and will need a buffer size

big enough to handle the result (or slice up the result). You will also

need to consider encoding, where ToObject would have encoded to CharSet

transformNode always returns unicode. Hence the best approach would be to

set Response.CharSet = "UTF-8" (you were doing that already right?) and

Response.CodePage = 65001. On 2000 SP4 with IIS5 this gets trickier still

because the Response object doesn't have a CodePage property, you would need

to do it on the session then set the codepage back to its original value

after the Write.

Option 4 is well worthwhile if you can stand the upheaval but for new code

its worth considering.

--

Anthony Jones - MVP ASP/ASP.NET

"Anthony Jones" wrote:

Hi Anthony,

Thanks for your help on all this. All the pages in my web site show the

error that was not there before. Check it out. www.markallenonline­.com

I have a classic ASP web site and most of the pages use something like

this

Dim objXML1

Dim objXSL

Set objXML1 = Server.CreateObject­("Microsoft.XMLDOM")­

Set objXSL = getXMLDoc("default.­xsl")

call objXML1.transformNo­detoobject(objXSL, Response)

I am tempted to uninstall the security update (Workaround 1) if I can.

However I would be willing to implement the wrapper you mentioned

(workaround

2). If it worked. I would do the coding. Every page unfortunately. Could

help

me with some sample code for this. It would be appreciated.

Workaround 3 I tried however, my web site works in three languages and

when

I do the transform to an intermediate object document and then do

Response.Write I then loose all special foreign characters somehow. If I

transform right to the response object the special characters in German

and

Spanish show correctly and works great.

Workaround 4 is not an option for me.

Again thanks for the help. I was waiting for something like this to happen

with all the automatic updates.

"Luis Vargas" <Luis Vargas@discussions.­microsoft.com> wrote in message

news:AB0F7A56-440C-­428E-8240-E7F08B300A­01@microsoft.com...

Response.CodePage = 65001

Response.CharSet = "UTF-8"

Response.Write objXML1.transformNo­de(objXSL)

This code should work for all characters.

Does the above not work for you?

Can you provide an example characters you are having trouble with?

--

Anthony Jones - MVP ASP/ASP.NET