Urlrewriting.net IsPostBack always false

I am working on rewriting URLs Urlrewriting.net, and have run into what seems to be a common problem but I can seem to fix it. I'll present a simplified case.

The URL rewriting is working perfectly with the rule:

<urlrewritingnet rewriteOnlyVirtualUrls="true" defaultPage="default.aspx" defaultProvider="RegEx" xmlns="http://www.urlrewriting.net/schemas/config/2006/07">
   <rewrites>
       <add name="catalog" virtualUrl="^~/catalog/(.*)/(.*).aspx" rewriteUrlParameter="ExcludeFromClientQueryString" destinationUrl="~/catalog.aspx?cid=$1&amp;c=$2" ignoreCase="true"/>
   </rewrites>
</urlrewritingnet>

On the page I have a DataList with 2 asp:buttons inside. When clicked, the page refreshes but does nothing.

I followed ScottGu's article to impliment a form control adapter to rewrite the action of the form to match the rewritten URL.

Page URL in the browser: http://...../dev/catalog/13/Music.aspx

<form name="aspnetForm" method="post" action="/dev/catalog/13/Music.aspx" id="aspnetForm"> 

I now see the correct URL on the form action, and when debugging I can see the page load event firing.

The problem now is that every time the page loads Page.IsPostback is false, causing the page to rebind the DataList and therefore ignore the ItemCommand the buttons should be triggering.

if (!Page.IsPostBack)
     PopulateControls();

I'm using .NE开发者_Go百科T 3.5 SP1, there is a ScriptManager on the master page but no UpdatePanel on this page. I've also tried resetting the Form.Action property and bypassing ScottGu's solution with the same result. If I go to the page URL directly without using the rewriter everything works fine.

What am I missing?

It's the LinkButton problem, all the linkbutton should removed from the page include the master page.

Persistence pays off. Turns out the problem was the following code on the master page:

<asp:LinkButton runat="server" PostBackUrl="~/basket.aspx" Text="View Cart" CausesValidation="false" />

I replaced that with a standard <a> tag and everything is working great.

NO IDEA why that would make a difference here. I guess when rewriting URLs any PostBackUrl or NavigateUrls will break the postbacks.

Sammy is right. I spend like 5 hour till find problem.

I read many articles about "ASP.NET Url Re-writing and Postback Problem" till find the problem. You don't need solutions like: http://weblogs.asp.net/jezell/archive/2004/03/15/90045.aspx and they are not working also...

SOLUTION IS : You can use asp:Linkbutton, asp:Button, asp:ImageButton BUT DON'T SET their's postbackurl. Just Use < a > tag instead of linkbutton.

This troubled my mind for 4 hours straight.

The answer I used was actually removing all postbackurl's and navigateurl's.

Everything else failed, but that worked like a charm. Really really insane how that was the problem but it is.

I experienced the same issue - UrlRewriter and a button's postback value always being false. (no LinkButtons with PostBackUrl specified)

I added ScottGu's FormControlAdapter and it worked for me - HOWEVER - after a while I noticed my load times were REALLY suffering. I eventually tracked it down to the base.Render(new RewriteFormHtmlTextWriter(writer)); event in the FormControlAdapter, which would sometimes take over 5 seconds to complete.

If I removed the FormControlAdapter from my .browser file, the home page button would no longer postback correctly (always false).

On my home page the form tag was getting rendered with an empty action attribute <form action="" >

In my situation, the button in question is on my master page. By manually setting the form's action in my MasterPage's Page_Load event (in my case to "default.aspx") I was able to remove the FormControlAdapter and the button posts back correctly.

protected void Page_Load(object sender, EventArgs e)
 {
     if (Request.RawUrl == "/" || Request.RawUrl == "/default.aspx")
         form1.Action = "default.aspx";
     else
         form1.Action = Request.RawUrl;

So it seems, all that's really necessary is to set the form Action. ScottGu's solution is fine and flexible, but seems really slow