views:

89

answers:

3
// break point set here>>
webRequest = (HttpWebRequest)WebRequest.Create(server);
webRequest.Timeout = 30000;
webRequest.Credentials = CredentialCache.DefaultCredentials;
webRequest.Method = "POST";
webRequest.ContentType = "application/x-www-form-urlencoded";
webRequest.KeepAlive = false;


XmlDocument doc = new XmlDocument();
doc.AppendChild(request.ToXmlElement(doc));
byte[] data = XmlUtil.DocumentToBytes(doc);

webRequest.ContentLength = data.Length;

// write data to stream
requestStream = webRequest.GetRequestStream();
requestStream.Write(data, 0, data.Length);
requestStream.Close();

// get response
HttpWebResponse response = (HttpWebResponse)webRequest.GetResponse();

dataStream = response.GetResponseStream();

I set a break point at the first line above, but for some reason I lose it after webRequest = (HttpWebRequest)WebRequest.Create(server); completes, and never get to hit any debug points beyond in the next lines in this method. It's like it loses site of where it was in terms of debug break points and ultimately hits one later down the line instead of continuing to hit debug points I have added in here such as to the dataStream. I know it did not error out either because I ultimately do get a response back. I want to look at the dataStream but every time it goes out to make the request it never comes back and the rest of the code runs outside of this method after receiving back the response.

A: 

I'm a bit unclear on your problem. Are you setting the breakpoint on the comment line and it's dissapearing from there? If so can you put it on the next line or insert a no-op line at the comment point and go from there? Setting a breakpoint on a comment line requires the debugger and language service jump through a few more hoops and increases the chance of a problem (it should still work but it's a good diagnostic check). Setting a breakpoint on an actual code line shouldn't have any issues.

If you're setting on the actual code line, can you define "dissapear"? Does it completely go away or does it go blank, or does it get a caution sign?

JaredPar
A: 

The first thing to check is that you have Visual Studio set to build in DEBUG mode, not RELEASE mode. In RELEASE mode, the compiler can optimize and reorder statements and thus the code in the source file doesn't necessarily match up with the line numbers stored for the breakpoint.

tvanfosson
+1  A: 

crap, I found that the response was returning null and another part of code was being implemented so the break point was never being hit because it hit my error handling first and stopped there.

That was my first thought. Sometimes, the tools aren't lying :)
gbarry