How to inspect XML streams from the debugger in Visual Studio 2003
Asked Answered
F

2

13

I've got to edit an XSLT stylesheet, but I'm flying blind because the XML input only exists fleetingly in a bunch of streams. I can debug into the code, but can't figure out how to get the contents of the streams out into text I can look at (and run through the XSLT manually while I'm editing them).

The code is part of a big old legacy system, I can modify it in a debug environment if absolutely necessary, but it runs in a windows service connected up to a bunch of MSMQs. So for various reasons I'd rather be able to use the debugger to see the XML without having to change the code first.

Code much simplified, is something like this: (C# - but remember it's .net 1.1 in VS 2003.)

This is the function that gets the XML as a stream, which is then fed into some sort of XSLT transform object. I've tried looking at the writer and xmlStream objects in the watch windows and the immediate window, but can't quite fathom how to see the actual XML.

private MemoryStream GetXml()
{
    MemoryStream xmlStream;
    xmlStream = new MemoryStream();
    XmlWriter writer = new XmlTextWriter(xmlStream, Encoding.UTF8);
    writer.WriteStartDocument();
    //etc etc...
    writer.WriteEndDocument();
    writer.Flush();
    xmlStream.Position = 0;
    return xmlStream; //Goes off to XSLT transform thingy!
}

All help much appreciated.

Freezer answered 6/5, 2009 at 16:17 Comment(0)
Z
19

You could simply add this expression to your watch window after the MemoryStream is ready:

(new StreamReader(xmlStream)).ReadToEnd();

Watch expressions don't need to be simple variable values. They can be complex expressions, but they will have side-effects. As you've noted, this will interrupt execution, since the stream contents will be read out completely. You could recreate the stream after the interruption with another expression, if you need to re-start execution.

This situation arises frequently when debuging code with streams, so I avoid them for simple, self-contained tasks. Unfortunately, for large systems, it's not always easy to know in advance whether you should make your code stream-oriented or not, since it depends greatly on how it will be used. I consider the use of streams to be a premature optimization in many cases, however.

Zacynthus answered 29/5, 2009 at 16:13 Comment(1)
For anyone coming across this answer from Google (like I did), please also bear in mind you may need to reset the Stream pointer to the beginning if it has already been read from. This can be done using xmlStream.Position = 0; or xmlStream.Seek(0, SeekOrigin.Begin);. Since the watched expression doesn't automatically update after doing this, I'd recommend executing both commands from the Immediate Window.Ea
F
1

OK, I've not succeeded in using the debugger without modifying the code. I added in the following snippet, which lets me either put a breakpoint in or use debugview.

private MemoryStream GetXml()
{
    MemoryStream xmlStream;
    xmlStream = new MemoryStream();
    XmlWriter writer = new XmlTextWriter(xmlStream, Encoding.UTF8);
    writer.WriteStartDocument();
    //etc etc...
    writer.WriteEndDocument();
    writer.Flush();
    xmlStream.Position = 0;

    #if DEBUG
    string temp;
    StreamReader st=new StreamReader(xmlStream);
    temp=st.ReadToEnd();
    Debug.WriteLine(temp);
    #endif

    return xmlStream; //Goes off to XSLT transform thingy!
}

I'd still prefer to simply look at the xmlstream object in the debugger somehow, even if it disrupts the flow of execution, but in the meantime this is the best I've managed.

Freezer answered 6/5, 2009 at 17:50 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.