Breakpoints after Response.Redirect in ASP.NET 2.0

[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

 

[Juan T. Llibre]

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.

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.

 

[venner]

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

 

[Juan T. Llibre]

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

?




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]

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

 

[Juan T. Llibre]

re:

The issue is that after redirecting to the CAS site, I can't hit
breakpoints _anywhere_ in my application, ever.

I'm running Response.Redirect("nextpage.aspx"); in most cases, although
with find in files I found a Response.Redirect ("nextpage.aspx", true);

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




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