I'm currently fighting with the .NET Viewstate and it is starting to wear me down. Having found that some of the pages in one of our applications is made up of around 80% viewstate I have looked into reducing this where I can.
I have looked at (and am happy with) disabling viewstate for controls that do not need it (labels, buttons etc) and have made some small gains here.
I'm now looking at viewstate compression and while I can demonstrate a 40-50% decrease in size it does not seem to be playing well with my application.
Scenario:
Page contains a few dropdown lists, a button and a Grdiview (hence the need to deal with the ViewState!). When the page loads the DDLs are populated and default selections are made. Pressing the OK button results in the Gridview being populated as expected.
Now the problem: With Viewstate Compression enabled, if the user changes the selected items in the DDLs before clicking the OK button they will get a 'Required Field Validator' error indicating that a selection has not been made in one of the DDLs - but this is not the case! Disabling the compression code removes the problem and the page operates as expected (i.e. as it has for months!).
Could the problem be down to the viewstate now being stored in a key other than __VIEWSTATE [the code that I have seen use different key names - VSTATE for instance).
My page sources look like this;
Page Source with Compression (note the empty __VIEWSTATE key):
<div>
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<input type="hidden" name="__LASTFOCUS" id="__LASTFOCUS" value="" />
<input type="hidden" name="__VSTATE" id="__VSTATE" value="H4sIAAAAAEAO29B2AcSZYlJ
.
.
MKd2afqdaImFR5UiFXVyQPwLPA//8xt+pMsSQ8vlOklcoNgmZfJd8hHvk6/S/7UbxxAJTjzZfp6Qcm039
h3d3dvvPO7/Oa/7i57uemj1H2a/gw5lJQ+ySjFRtPZUL7A/3o2ImFR5UiFXVyLPA+38At70F1EkwAAA=" />
<input type="hidden" name="__VIEWSTATE" id="
__VIEWSTATE" value="" />
</div>
Page Source without Compression:
<div>
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<input type="hidden" name="__LASTFOCUS" id="__LASTFOCUS" value="" />
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMTYxOTM1NDg4N
A9kFgJmD2QWAgIDD2QWAgIFD2QWAmYPZBYKAgEPZBYIAgcPZBYCAgMPDxYCHgRUZXh0BRdEYXduQyBbY2hhbm
dlIHBhc3N3b3JkXWRkAgkPFgIeB1Zpc2libGVoFgQCAQ8PFgIfAAUFQWRtaW5kZAIDDw8WAh8ABQUxNDoyNGR
.
.
.
.
.
.
kAgsPDxYEHwAFWVNlbGVjdGVkIFNlcnZpY2UgVXNlcjogPGEgY2xhc3M9J3N1U2VsZWN0b3InIGhyZWY9J2xp
c3RzZXJ2aWNldXNlcnMuYXNweCc+PGI+bm9uZTwvYj48L2E+HwFoZGQCDw8QZGQWAGQCBQ8UKwADZDwrABQEA
BYSHg9QYXJlbnRJdGVtQ2xhc3MFC2lnbW5fUGFyZW50HhdUb3BMZXZlbFBhcmVudEl0ZW1DbGFzcwUTaWdtbl
Ub3BFBhcmVudB4KSlNGaWxlTmFtZWUeFlRvcExldmVsSG92ZXJJdGVtQ2xhc3MFNGlnbW5fVG9wTGV"
/>
</div>
How does .NET know where the VIEWSTATE is stored and does it know that i have moved it?
Do I need to make any other changes to my code apart from implementing SavePageStateToPersistenceMedium and LoadPageStateFromPersistenceMedium?
hey viewstate compression works for me without any problems. basically i have a baseclass for all my aspx pages which use viewstate. even i am using a different viewstate key to save my viewstate. however you have to override 2 methods for this:
1) - to save viewstate
2) - to load viewstate
as long as you are doing this, you should have no problems. see below code which i am using for my baseclass
using System;
using System.IO;
using System.Web.UI;
namespace XC.UI.WebForms
{
public class PageBase : System.Web.UI.Page
{
protected override object LoadPageStateFromPersistenceMedium()
{
string viewState = Request.Form["__VSTATE"];
byte[] bytes = Convert.FromBase64String(viewState);
bytes = XC.Common.ViewStateHelper.Decompress(bytes);
LosFormatter formatter = new LosFormatter();
return formatter.Deserialize(Convert.ToBase64String(bytes));
}
protected override void SavePageStateToPersistenceMedium(object viewState)
{
LosFormatter formatter = new LosFormatter();
StringWriter writer = new StringWriter();
formatter.Serialize(writer, viewState);
string viewStateString = writer.ToString();
byte[] bytes = Convert.FromBase64String(viewStateString);
bytes = XC.Common.ViewStateHelper.Compress(bytes);
ClientScript.RegisterHiddenField("__VSTATE", Convert.ToBase64String(bytes));
}
}
}
if you are using ajax in your page please change this line of code. It will solve your problem.
ClientScript.RegisterHiddenField("__VSTATE", Convert.ToBase64String(bytes));
replace above statement with ScriptManager.
ScriptManager.RegisterHiddenField(this, "__VSTATE", Convert.ToBase64String(bytes));
There is a constant hidden in .NET that holds the viewstate field name. We did compression by hooking in the methods you describe but keeping the viewstate name same without issues.
This may be overkill, but there is a very cool hardware solution to this problem at www.strangeloop.net. No affiliation, just impressed by the technology.
Back to the page tho - what kinds of controls are generating all this viewstate? Grids? You indicated you went over this already, but do watch out for 'unnecessary runats' with tables, td's, tr's, div's, etc. that have runat="server" set. The entire contents of those controls get persisted in viewstate. We recently chopped 40% off our viewstate payload by recognizing a div was client-side and didn't need runat="server".
Compression didnt work for me as it just got it down by 40%. I had 200-300KB ViewStates and was degrading application performance drastically.
I wrote some viewstate substitution technique which replaced it with a GUID token on the page and saved the actual data on server itself in a database.
Here is the code and technique.
http://ashishnangla.com/2011/07/21/reducing-size-of-viewstate-in-asp-net-webforms-by-writing-a-custom-viewstate-provider-pagestatepersister-part-12/
The following answer is not mine, but OP's (that was included in the question). I'm moving it out of the question and making this a community wiki.
I've got to the bottom of this - well almost, I have it working! For some reason using the ClientScript.RegisterHiddenField method appears to have been the source of the problem. Modifying the code to utilise the base class save method, i.e. base.SavePageStateToPersistenceMedium(compressedBytes) and processing the Pair object returned by base.LoadPageStateFromPersistenceMedium() I now have a working solution. Test show a reduction of aroun 70% on the test page so I'm pretty happy with that.
Now that I have compression working I need to recommend that the next (first proper) Code Review has a focus on removing viewstate where it is not needed.
Related
I am curious: is it possible to read the initial state of a DropDownList control using JavaScript?
Let’s say that when the page is loaded in the browser, the dropdown has ten options. Then, using JavaScript I remove all the options.
Can I read the ASP.NET ViewState to get the initial ten options and restore them?
The short answer is yes you can use JavaScript to read the viewstate values as they are stored in a field called __viewstate, which is rendered in the browser as an input field like this:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
The problem you will run into is the __viewstate value is encrypted.
My suggestion is to use a hidden field to store the values of the dropdown or whatever else you want to store and then access the value like this:
<input type="hidden" id="hiddenField" runat="server" value="" />
Then in your code-behind, since the input has the runat="server" you can set the value to whatever you wish, like this:
hiddenField.Value= ViewState["dropdownvalues"].ToString();
Finally, you can use JavaScript to get the values from the hidden field, like this:
<script type="text/javascript">
function test()
{
var name = document.getElementById('hiddenField').value;
alert(name)
}
</script>
Is it possible to get the value of the view state that ASP.NET writes in:
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
, before the processing is done for the page, in C#, in one of the page events, such as
OnSaveStateComplete
If so, how?
Thanks!
Simple answer - no.
You could start playing with internal methods like System.Web.UI.Control.SaveViewStateRecursive using Reflection but you have a very good chance that whatever you will build will stop working on the next .NET Framework update.
If you want to provide custom storage mechanism for ViewState you would implement PageStatePersister.
I am trying to do something from scratch in asp
I would like to get something like below. From basic hard coded values.
http://localhost:2478/Default.aspx?phone=905123456&order=123456
After that I want to use this parameter in my variables for SQLquery
I am new to asp.net and vb , I'm learning. Can you please explain me in details? Any helps will be appreciate.
Can you please provide any basic code from where I can start
Based on your latest comments:
<form method="get" action="default.aspx">
<input type="text" name="phone" />
<input type="text" name="order" />
<input type="submit" value="submit" />
</form>
Key points:
method=get (fields are in url instead of body)
note that the form above doesn't have runat=server (more below) - it's a plain HTML Form on plain HTML page
in the context of ASP.Net Web forms, you may run into issues particularly if you are using Master Pages (you can't nest forms, and a Master page is a container for your entire page).
ASP.Net forms do POSTbacks - re: method=post
You can use/add plain forms in an ASP.Net page as long as you don't nest them (outside of the server side ASP.Net form).
If you have no choice (e.g. Master Page), you'll have to construct the Querystring manually after a POSTback, then Response.Redirect to some other target (adding the querystring manually).
there are other non-ASP.Net-y ways of doing it - e.g. javascript, but that a different story
I'm working on an application which generates a list of customers from a db. I have disabled ViewState in default.aspx, but now when I viewed the source code of the generated HTML page I saw that the ViewState is on.
I've tried to add both ViewStateMode="Disabled" and EnableViewState="False" (separately and even together) without any luck.
What can be wrong?
ViewState code from the source code if it helps:
<div class="aspNetHidden">
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="88luWaDvrTt0+OWLhB and a lots of characters after this...
EDIT: Now when I looked again in the source code I can see the following which I find strange:
There's A LOT of ViewState characters (takes 15-20 seconds to scroll through it)
There's two places with ViewState code, separate from each other
ASP.Net pages have both Control State and View State. Control State is for absolutely critical data that the control can't function without (at least in theory).
View State and Control State are both stored in the same field. A site with View State completely disabled may still have Control State.
Unfortunately, ASP.Net is quite inconsistent as to how it differentiates between the two. For example, a DropDownList will no longer fire change events with View State disabled. I consider that a critical function of a drop down and I would be happy to spend the few bytes of space to store the currently selected value in Control State so that a change could be detected.
If you are wondering about the contents of the hidden field containing state, you can decode it. It can be very useful for detecting View State "leaks".
Looking at the MSDN documentation, even when you disable it, it is still used to detect postbacks:
Even if EnableViewState is false, the page might contain a hidden view
state field that is used by ASP.NET to detect a postback.
You can deserialize the viewstate to see who's putting data in there:
LosFormatter lf = new LosFormatter();
object deserialized = lf.Deserialize("!!! YOUR VIEWSTATE HERE !!!");
Attach a debugger and have a look at the contents of deserialized
I have an html page that I am converting over to an asp .net page. This page contained a form that accesses an external website that I have no control over. There is some sample code below:
<asp:Content ID="sample" ContentPlaceHolderID="body" Runat="Server">
<form name="Subscribe" method="post" action="http://anexternalwebsitehere.com/subscribe.asp">
<input type="text" name="email" size="45" maxlength="120" />
<input type="submit" name="submit" value="Subscribe" />
</form>
</asp:Content>
The form is more complicated than the example I have provided, but it gives a rough idea of what i need to convert over. Here are the problems I have encountered.
If I leave it as is:
When you click on the submit button you have a postback to the current page and not to the external page
If simply convert everything over to be asp form controls and change the postback url:
The id's become some convoluted "ctl00_body_ctl00" which the external page is not able to interpret.
Note: I do need the page to be an aspx page because I am using a master page for other content on the page.
Additional note: this is not Microsoft MVC.
What am I missing?
The issue was with nested forms as others have mentioned.
I was able to fix all my issues by simply doing the following:
Remove the extra form element i was adding.
Leave all controls as simply html controls, except for the submit button.
Replace the submit button with an asp .net button, and set the postback url.
The old code is as follows:
<asp:Content ID="sample" ContentPlaceHolderID="body" Runat="Server">
<form name="Subscribe" method="post" action="http://anexternalwebsitehere.com/subscribe.asp">
<input type="text" name="email" size="45" maxlength="120" />
<input type="submit" name="submit" value="Subscribe" />
</form>
</asp:Content>
The new code:
<asp:Content ID="sample" ContentPlaceHolderID="body" Runat="Server">
<input type="text" name="email" size="45" maxlength="120" />
<input type="submit" name="submit" value="Subscribe" />
<asp:button postbackurl="http://anexternalwebsitehere.com/subscribe.asp" text="Subscribe" runat="server" />
</asp:Content>
This fixes any of the issues with invalid nested forms as there are none. It also addresses the issue of asp .net renaming the asp elements because the only control that is being renamed is the asp button control which was not necessary for the submission to succeed.
Since you probably have the server form tag on your masterpage spanning your contentplaceholder, this new form you're declaring will be placed inside the server-form (by server-form i mean the one asp.net use for postbacks with runat="server")
I've had cases when i needed a special non-server form on an aspx page that already had a server-form, and the way i solved the problem was to place this non-server form outside the server-form - what i mean is, place it after the server-form. Since you use masterpages, you will need a new contentplaceholder on that masterpage, you can call it "noform". It is placed after the server-form so any content put in this noform will be placed outside the server-form. This mean no asp.net controls will work in this specific contentplaceholder (noform) since they won't be picked up by the framework, but you will be able to place your non-server form there and do your magic on that.
The problem, as you've probably guessed, is that you've got one form inside another form - ie the legacy form is appearing inside the ASP.NET form required by the master page.
One quick (if rather clunky) way to get around this is to close the ASP.NET form above the legacy form, and then open a new form below the legacy form. This means you've got three forms on the page, none of which are nested.
So you end up with something like this:
<asp:Content ID="sample" ContentPlaceHolderID="body" Runat="Server">
</form>
<form name="Subscribe" method="post" action="http://anexternalwebsitehere.com/subscribe.asp">
<input type="text" name="email" size="45" maxlength="120" />
<input type="submit" name="submit" value="Subscribe" />
</form>
<form method="post" action="myAspNetPage.aspx">
</asp:Content>
The closing </form> tag at the start closes the ASP.NET from the master page. You then have your form, which should now work as expected. Then the open <form> tag at the end simply ensures that the closing </form> tag from the master page is valid HTML.
Obviously anything appearing on the master page after the legacy form won't be within the standard ASP.NET form, so this may not work for you depending on how the rest of your page is structured.
It's not a particularly elegant solution, but it works as a quick fix (depending on what else is on your master page). We've used it where we had one legacy form required on a site with hundreds of pages, so we simply wanted a one-off fix rather than anything that affected the master page itself.
In our case, we couldn't change the legacy form as this was supplied by a third-party, regularly changed, and needed to be dropped into the ASP.NET page without a developer getting involved to amend it (eg as opposed to Brian's solution to his own question which requires editing the form and is clearly a better option in his case - and probably in most other cases where there is a similar problem).
Your button's click event will handle submission of the url and data.
//C# source
protected void button_Click(object sender, EventArgs e)
}
string customURL = "http://anexternalwebsitehere.com/";
string emailValue = textBoxEmail.Text; //of course validate this for proper email...
customURL += "page.aspx?email=" + emailValue;
Response.Redirect(customURL);
}