Hello all,

 

I am having an issue on my OnePageCheckout control.  I currently have a few UpdatePanels around the Shipping Address, the Shipping Method and the Order Totals section which cause a partial page update when one of them gets updated.

 

Here is the problem that I am having:  All of a sudden, the 'Dynamic.aspx' URL rewriting is broken.  When it initially requests the page, it works as expected..  It rewrites the URL as '/Dynamic.aspx?<querystring>'.  However, when the UpdatePanels cause a PostBack, the URL suddenly changes to '/Store/Dynamic.aspx?<querystring>' and the whole page breaks..

 

I've tried moving all of the AddressInput and ShippingMethod user control code into OnePageCheckout and simplified their usage just to make sure that something strange wasn't happening with the communication between the user controls...  Still no luck. 

 

As soon as the URL gets incorrectly rewritten, ALL links on the page are broken.  So, for example, if I click around between the Shipping Address, change the Shipping Methods a few times, then click on the 'Shopping Cart' button at the top of the page, it tries to go to the URL '/Store/Dynamic.aspx?<querystring for Shopping Cart page>'

 

This is strange behaviour, and I can not replicate it using the internal Webserver in Visual Studio.  I wrote debugging code in the UrlRewriterHttpModule, and in the internal Webserver, I see that it calls the UrlRewriterHttpModule every time it does a postback, including the partial page updates from the UpdatePanel..  However, in Production, it only calls UrlRewriterHttpModule on the INITIAL load of the page.  The partial page postbacks do not cause the rewriting module to be called, so presumably the Webserver is internally rewriting that URL.

 

This is using DotShoppingCart v3.11, and Production is running Windows Server 2008 Enterprise.

 

I would appreciate any help..  This is urgent because the problem is happening on a live site.

 

Thanks,

-Mark

 

Are you using Visual Studio 2010 to publish DSC to the live server? If so, I believe this is due to a Visual Studio bug. The workaround is to delete App_Browsers.dll from the published web\bin folder and then copy Web\App_Browsers folder to published folder.

YES!!  That fixed it!

 

Yes, I was using Visual Studio 2010 to publish, and though it was copying the App_Browsers folder correctly, that App_Browsers.dll that was compiled did not seem to activate the code.  Deleting the App_Browsers.dll fixed the problem.

 

Thank-you very, very much for your quick reply.  I only wish I posted a few days ago instead of beating my head against the wall trying to figure out why it was rewriting URLs incorrectly!

 

Thanks again,

-Mark