Breakpoints after Response.Redirect in ASP.NET 2.0

  • Thread starter Thread starter venner
  • Start date Start date
V

venner

I'm having an issue with an ASP.NET website after upgrading to ASP.NET
2.0. The website makes use of a central authentication service (CAS)
provided at the university I work for. Each page checks a session
variable, and if it is not present, does a Response.Redirect to a
webpage for the CAS passing a url parameter for the url to post back
to. The CAS provides a page for the user to log into, validates the
username and password, and then POSTs encrypted data back to the page I
provided. The information is then decrypted and validated, and if the
user was properly logged in, they are allowed to continue.

The code all seems to run fine. However, the problem I am having is
that after this authentication process I cannot hit breakpoints. That
is, if I place a breakpoint on the page before this Redirect, execution
breaks, and I can step through my code. However, if I put a breakpoint
after the Redirect, execution will not break.

Anyone know how to make my breakpoints function properly with this
off-site redirect?

Thanks,
Eric
 
re:
if I place a breakpoint on the page before this Redirect, execution
breaks, and I can step through my code. However, if I put a breakpoint
after the Redirect, execution will not break.
Click to expand...

See : http://support.microsoft.com/kb/312629/EN-US

If you use the Response.End, Response.Redirect,
or Server.Transfer method, a ThreadAbortException exception occurs.

The Response.End method ends the page execution and shifts the execution
to the Application_EndRequest event in the application's event pipeline.
The line of code that follows Response.End is not executed.

This problem occurs in the Response.Redirect and Server.Transfer
methods because both methods call Response.End internally.

To work around this problem, use one of the following methods:

1. For Response.End, call the HttpContext.Current.ApplicationInstance.CompleteRequest
method instead of Response.End to bypass the code execution to the Application_EndRequest event.

2. For Response.Redirect, use an overload, Response.Redirect(String url, bool endResponse)
that passes false for the endResponse parameter to suppress the internal call to Response.End.

For example: Response.Redirect ("nextpage.aspx", false);

That will prevent Response.End from being called internally,
which will allow your code to continue executing.




Juan T. Llibre, asp.net MVP
aspnetfaq.com : http://www.aspnetfaq.com/
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
 
Sorry, I don't think I made the problem very clear. The issue is not
that breakpoints aren't hit in the code directly after the redirect.
The issue is that after redirecting to the CAS site, I can't hit
breakpoints _anywhere_ in my application, ever.

So, for example, lets say the page that CAS posts to has a button on
it, and lets say I put a breakpoint in both the button handler and in
the login page before the redirect to CAS. I will hit the breakpoint
before the redirect, and I can step along through the code until the
redirect. Then, in the browser, the page changes to the CAS login. I
log in, and am directed back to my site on a completely different page.
Now, when I press the button, the button handler executes correctly
(which I verify by having it write something to the database), but
execution does not break at the breakpoint that is placed in the button
handler. When I go into the code now, and look at the breakpoint I
added, it has a warning sign, and says "The breakpoint will not
currently be hit. No symbols have been loaded for this document."

Thanks,
Eric
 
Eric,

Are you running

Response.Redirect("nextpage.aspx");
or
Response.Redirect ("nextpage.aspx", false);

?

Also, are you running, in web.config,

<compilation debug="true">
or
<compilation debug="false">

?



Juan T. Llibre, asp.net MVP
aspnetfaq.com : http://www.aspnetfaq.com/
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
Sorry, I don't think I made the problem very clear. The issue is not
that breakpoints aren't hit in the code directly after the redirect.
The issue is that after redirecting to the CAS site, I can't hit
breakpoints _anywhere_ in my application, ever.

So, for example, lets say the page that CAS posts to has a button on
it, and lets say I put a breakpoint in both the button handler and in
the login page before the redirect to CAS. I will hit the breakpoint
before the redirect, and I can step along through the code until the
redirect. Then, in the browser, the page changes to the CAS login. I
log in, and am directed back to my site on a completely different page.
Now, when I press the button, the button handler executes correctly
(which I verify by having it write something to the database), but
execution does not break at the breakpoint that is placed in the button
handler. When I go into the code now, and look at the breakpoint I
added, it has a warning sign, and says "The breakpoint will not
currently be hit. No symbols have been loaded for this document."

Thanks,
Eric
 
I'm running Response.Redirect("nextpage.aspx"); in most cases, although
with find in files I found a Response.Redirect ("nextpage.aspx", true);
in one spot. I don't think it is being hit in the case I was running
before though.

Web.config setting is: <compilation defaultLanguage="c#" debug="true">
Thanks,
Eric
 
re:
The issue is that after redirecting to the CAS site, I can't hit
breakpoints _anywhere_ in my application, ever.
Click to expand...
I'm running Response.Redirect("nextpage.aspx"); in most cases, although
with find in files I found a Response.Redirect ("nextpage.aspx", true);
Click to expand...

I'd try testing whether you can hit breakpoints
after redirecting to the CAS site, if you use :

Response.Redirect ("nextpage.aspx", false);
in your redirects.

If that doesn't fix the situation and you can repro,
I'd bug the behavior at the Feedback Center:

http://connect.microsoft.com/feedback/default.aspx?SiteID=210

Notice that the URL for the Feedback Center has changed...



Juan T. Llibre, asp.net MVP
aspnetfaq.com : http://www.aspnetfaq.com/
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
I'm running Response.Redirect("nextpage.aspx"); in most cases, although
with find in files I found a Response.Redirect ("nextpage.aspx", true);
in one spot. I don't think it is being hit in the case I was running
before though.

Web.config setting is: <compilation defaultLanguage="c#" debug="true">
Thanks,
Eric
 
Try to add the following line to your .aspx page:
<%@ OutputCache Location="None" VaryByParam="None" %>

I've been having the same problems and I found out the web browser loads the
page from the browser's cache, not from the server.

My goal is to move any query string parameters to the Session instance and
reload the page. If a specific product is requested the following link is
used: products.aspx?productId=1.
The server should then detect the productId in the query parameter, store
value 1 in the Session["productId'] and reload the page. I use
Response.Redirect(products.aspx) for that.

I have a breakpoint set in the Page_Init of products.aspx. The first time the
page loads, Visual Studio debugger pauses the application. The second time the
page loads, the debugger pauses only once. I expect it to pause twice.

What SHOULD happen is:
- Page_Init loads.
- Detects the redirect parameter in the query string.
- Stores the product id in the Session instance.
- Redirects the user to products.aspx.
- Page_Init loads.
- Displays product with product id == 1.

What HAPPENS is:
- Page_Init loads.
- Detects the redirect parameter in the query string.
- Stores the product id in the Session instance.
- Redirects the user to products.aspx.
- Browsers detects request for products.aspx and retrieves page from cache.

I found out about this after installing DebugBar and inspecting the HTTP requests/response.
 
Back
Top