Strange behaviour of ASPNet?

Hi all, I am using master page in my site at http://www.educationfound.com

I noticed that when using IE to come to my site via a search engine, the back button does not work. I am puzzled to why, and I noticed that in the page history, there are three http://www.educationfound.com. This is very surprising for me, since there is no such problem in firefox and chrome. Is there any workaround for this so that there is only one page history?

Secondly, I would like to enquire about the garbarge code generated by Mircrosoft when you use master page file. For some strange reasons, it generate a super long viewstate data. I am concern if this will result in being ranked lower in search engines as a result of these garbage information.

Help is very much appreciated.

Regards,

Yu-Jin

 

I also use masterpages but I've never seen anything like what is happening with the browser history and your site. I suspect there is some sort of redirect bug in the code.

So far as viewstate goes, it is possible to disable it on a page by page basis which will remove most of the viewstate content, but not all of it. If you actually do need some viewstate it can also be controlled on a server control by control basis.

Finally there is probably one last thing you can do - move the viewstate to the bottom of the page so it will have a negligable effect on crawler algorithms.

 

Hi Bruce,

There's nothing native in the .NET framework that enables you to do it, but there are a number of documented methods that I've come across.

• http://www.hanselman.com/blog/MovingViewStateToTheBottomOfThePage.aspx
• http://www.webpronews.com/expertarticles/2006/11/28/aspnet-httpmodule-for-moving-viewstate-to-bottom
• http://www.dotnetdiary.com/labels/Moving ViewState Field.html
• The DotNetNuke method. I've not actually had sight of this code but since it's so widely used, it's definitely worth a look because it will be a very tried and tested method.
• ..other documented solutions out there since this is just one of a number of pet peeves in the lives of many ASP.NET developers.

Note that deciding to move viewstate may not be entirely without its own problems. For instance in David Sugdens' dotnetdiary article above, he reports that he has had to cope with an ASP.NET AJAX (ScriptManager) issue that has come about.

I'm in agreement with a lot of people on the fact that it was definitely a bad design choice by Microsoft back in the day, to decide to position viewstate at the top of the page and not easily enable developers to modify its position.

 

Update: this issue really caught my imagination so I pressed on with some further research today and I've found there is actually a .NET 2.0+ framework supported method for storing viewstate in session memory server side. It's news to me but you really can't be too hard on yourself when the framework is so massive!

Here is the MSDN documentation that describes the method http://msdn.microsoft.com/en-us/library/system.web.ui.sessionpagestatepersister.aspx. I read that the default ASP.NET persistence mechanism is to store view state on the client (in the outputted markup) using the HiddenFieldPageStatePersister class, but this behaviour is easily modified by using the SessionPageStatePersister in a PageAdapter.

This solves the 'viewstate bloat in the page' problem and probably renders all of those previously mentioned methods of moving viewstate to the bottom of the page redundant.

I've not actually tried this method myself yet but one report does mention that even when using the SessionPageStatePersister, there is still a small amount of viewstate data written out to the page markup. I believe that this small amount of viewstate contains the page hash key and I suspect it is the same viewstate written out by ASP.NET even when viewstate is disabled in the page with EnableViewState="False". There is even a way of removing this last morsel of markup outputted viewstate if absolutely necessary..

I'm happy I learnt something new today

 

...Yup I've been chatting with some of the guys on the ASP.NET team/CH9 and they all seem to be admitting that this has been a tack in the Lions paw for some time now.

 

Thank you for your suggestions

Hi all,

Thank you for your suggestions. I was surprised by the responses generated, and it is very interesting for me to learn from you experienced developer out there.

I found the bug with the http://www.educationfound.com having 3 page history - it seems that the google friendconnect control have a nasty habit of fetching data that result in this strange event (it will count as a second page in the eyes of IE when it loads, as will almost any other widgets). Very surprising news for me.

As for viewstate, I tried disabling it, and found to my horror (or expectation), that the page state does not persist on postback. e.g. it is fine if you do not have user selected choice or allow users to make selections or have code that persists on postback. But when you have postback in the same page, your data are all lost. It is very irriating when users fill in a form, hit an error, and have to fill in the form again.

It is very interesting regarding viewstate. but I found that google and most search engines to a large extend ignore the garbage it produces (horray for ASP.NET developers like us), and focus on the content, so it is not a major problem. Even if the viewstate is at the back of the page, it does not make any differences to the ranking. The ranking of the page is determined by relevance of keywords to the content, and google page rank alogorithm.

Which brings me to ask: how do I get my site listed in Bing (msn search?).. I don't understand the technology behind MSN.

Regards,

Yu-Jin