April 30, 2008

VIEWSTATE Serialization

The most important thing for an end user of a website is the how fast the page loads and our responsibility is to make them happy.

Frequent thing to achieve this is to review the code and write the code such a way that it performs better (in terms of processing time) but what after this ?

What if we still can increase the page serving speed. Apart from the code performance it is the ISP's speed and the size of the page that affects the download speed for a web page.


what if we can decrease the size of the page to some extent ( the size generated after the server side scripting finishes ( i mean the final rendered output)

for every server control if it's ViewState is enabled the data is kept in a viewstate in some encoded format(base64 encoded string as everyone says.)

wo when showing a control on a page keeps data in the rendered output of control as well in the viewstate along with the

state ( previous state) information ( doubles the size of final rendered output..!!)

straighaway coming to the topic we can have this VIEWSTATE buddy help us remotely ( not being rendered with the page so by decreasing the final rendered page out put size)

This can be done keeping the VIEWSTATE in the session or keep it at the server. I am keeping it at the web server as I have got the access to the web server and I have developed one web service that deletes files(holding the VIEWSTATE on the web server) after a day. In short its upto you to write code into the SaveViewState and GetViewState methods.

try the following code snippet ( just paste it in the code behind file of your aspx page)

protected override object LoadPageStateFromPersistenceMedium()
{
object _objViewState;
string _strViewState;
_strViewState = GetViewState();
LosFormatter _lFormater =
new LosFormatter();
try
{
//if(_strViewState!=String.Empty)
_objViewState = _lFormater.Deserialize(_strViewState);
//else
//_objViewState="";
}
catch{
throw new HttpException("Invalid ViewState");
}
return _objViewState;
}
protected override void SavePageStateToPersistenceMedium(object viewState)
{
StringBuilder _sBuilder =
new StringBuilder();
StringWriter _sWriter = new StringWriter(_sBuilder);
LosFormatter _lFormater = new LosFormatter();
_lFormater.Serialize(_sWriter,viewState);
_sWriter.Close();
SaveViewState(_sBuilder.ToString());
}
#region Save and Get ViewStateData
private void SaveViewState(string _vState)
{
// keep identicle files user-wise ( byadding sessionid) and page wise (for different pages by aading this.toString())
string _file = @Request.ServerVariables["APPL_PHYSICAL_PATH"]+Session.SessionID+this.ToString()+".txt";
FileStream _fS = new FileStream(_file,System.IO.FileMode.OpenOrCreate,System.IO.FileAccess.ReadWrite,System.IO.FileShare.ReadWrite);
StreamWriter _sW = new StreamWriter(_fS);
_sW.Write(_vState);
_sW.Close();
_fS.Close();
}
private string GetViewState()
{
string _file = @Request.ServerVariables["APPL_PHYSICAL_PATH"]+Session.SessionID+this.ToString()+".txt";
string _retValue=String.Empty;
if(File.Exists(_file))
{
StreamReader _sRead = new StreamReader(_file);
_retValue= _sRead.ReadToEnd();
_sRead.Close();
}
return _retValue;
}

happy programming..........

one more thing not to forget if you are using above code and storing the VIEWSTATE on web server in files.

keep a code in your Session_End in the global.asax.cs file (works when your Session State uses InProc mode) to remove the above files to keep the web-server tension free !!!

Submit this story to DotNetKicks

C# Pre Processor Directives

One of the good features of C# that we rarely use are the Pre Processor directives. Let's see how we can use them for us.

In general practice, we always write some test code in the application. As in JavaScript we use temporary alerts, in C# code behind too (or even in class library project) we use test code like temporary emailing and writing hardcode emails in the application emails. And very often this kind of code goes to production machine that is undesirable as well disastrous. To avoid this we can use the conditional compilation directives. Let's see how to use them


We are going to use three directives #define, #if, #endif. We can define the symbol in a file using the #define directive like

#define TESTCODE (this will define a symbol named TESTCODE)


And then we can write our test code within the conditional compilation #if directive as below

#if TESTCODE (if the TESTCODE symbol is defined using the #define then true, false otherwise)


// Test Code goes here.....
#endif

Also this is a very good way to handle multiple environments like in one project we had three environments like DEVELOPER, STAGE, PRODUCTION and we also had different databases. Now it may happen that we do not want the test data in our production database so that we can define these three symbols and then in the function returning the connection string we can conditionally return the appropriate connection string as below


internal string GetConnectionString() {

string conStr = "";


#if DEVELOPEMENT
conStr = "development database connection string";
#endif
#if STAGE
conStr = "Stage database connection string";
#endif
#if PRODUCTION
conStr = "Production database connection string";
#endif
return conStr;
}

HOW TO DEFINE:


So now only if you have the above line (#define TESTCODE) in your file the above conditional code will compile, not otherwise. So in case you do not want the test code to be moved to the production environment dll then just go to the file and remove the #define TESTCODE.
These conditional compilation symbols can be defined at file level or the project level. To define it at file level we can put the #define SYMBOLNAME in the file itself. To define the project level symbol follow the below steps.
Right click the .csproj (project file) -> click Properties -> go to Build tab -> find the Conditional compilation symbol and write the symbols in the text boxes. Multiple symbols can be separated by comma.
Now in ASP.NET 2.0 website this can be in the web.config file too as below
<system.codedom>
<
compilers>
<
compiler language="c#;cs;csharp" extension=".cs"
type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089"
compilerOptions="/d:SYMBOL1,SYMBOL2"/>
<
/compilers>
<
/system.codedom>

USE #warning AND #error IN CODE REVIEW:

Two other important directives are #warning and #error. Let us see how can we use them. These directives can be used while reviewing the code. As when some senior programming guy reviewing the code and if he find some better alternative for a piece of code he/she can put a warning there like

#warning Method implemented incorrectly. Do not use static variables.


So whenever the code is compiled, we will find the above warning in the output window and the Error list window. If we find some bad code that is written wrongly then we can put #error MESSAGE so that the code will not be compiled ant the message will be shown in the output and the Error list window

Submit this story to DotNetKicks