1.Edit update
http://www.codeproject.com/script/Articles/ArticleVersion.aspx?aid=37207&av=11488
1.master page
http://msdn.microsoft.com/en-us/library/c8y19k6h.aspx
http://en.csharp-online.net/ECMA-334:_17.6.3_Virtual,_sealed,_override,_and_abstract_accessors
http://www.csharpfriends.com/Articles/getArticle.aspx?articleID=67
opps:dojo
http://www.ibm.com/developerworks/web/library/wa-ground2/index.html
http://weblogs.asp.net/jgalloway/archive/2011/09/21/jon-talks-asp-net-mvc-4-asp-net-4-5-asp-net-web-pages-2-and-visual-studio-11-on-jesse-liberty-s-quot-yet-another-podcast-quot.aspx
Tuesday, 25 January 2011
Thursday, 6 January 2011
InProc / OutProc comparison ?
Storage location
* InProc - session kept as live objects in web server (aspnet_wp.exe). Use "cookieless" configuration in web.config to "munge" the sessionId onto the URL (solves cookie/domain/path RFC problems too!)
* StateServer - session serialized and stored in memory in a separate process (aspnet_state.exe). State Server can run on another machine
* SQLServer - session serialized and stored in SQL server
Performance
* InProc - Fastest, but the more session data, the more memory is consumed on the web server, and that can affect performance.
* StateServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 15% slower than InProc. However, the cost of serialization/deserialization can affect performance if you're storing lots
of objects. You have to do performance testing for your own scenario.
* SQLServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 25% slower than InProc. Same warning about serialization as in StateServer.
Robustness
* InProc - Session state will be lost if the worker process (aspnet_wp.exe) recycles, or if the appdomain restarts. It's because session state is stored in the memory space of an appdomain. For details, see KB324772.
* StateServer - Solve the session state loss problem in InProc mode. Allows a webfarm to store session on a central server. Single point of failure at the State Server.
* SQLServer - Similar to StateServer. Moreover, session state data can survive a SQL server restart, and you can also take advantage of SQL server failover cluster, after you've followed instructions in KB 311029.
* InProc - session kept as live objects in web server (aspnet_wp.exe). Use "cookieless" configuration in web.config to "munge" the sessionId onto the URL (solves cookie/domain/path RFC problems too!)
* StateServer - session serialized and stored in memory in a separate process (aspnet_state.exe). State Server can run on another machine
* SQLServer - session serialized and stored in SQL server
Performance
* InProc - Fastest, but the more session data, the more memory is consumed on the web server, and that can affect performance.
* StateServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 15% slower than InProc. However, the cost of serialization/deserialization can affect performance if you're storing lots
of objects. You have to do performance testing for your own scenario.
* SQLServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 25% slower than InProc. Same warning about serialization as in StateServer.
Robustness
* InProc - Session state will be lost if the worker process (aspnet_wp.exe) recycles, or if the appdomain restarts. It's because session state is stored in the memory space of an appdomain. For details, see KB324772.
* StateServer - Solve the session state loss problem in InProc mode. Allows a webfarm to store session on a central server. Single point of failure at the State Server.
* SQLServer - Similar to StateServer. Moreover, session state data can survive a SQL server restart, and you can also take advantage of SQL server failover cluster, after you've followed instructions in KB 311029.
how to check session is expired or not if expired then redirect to login page
protected void Page_Load()
{
if (Context.Session != null)
{
if (Session.IsNewSession)
{
string cookieHeader = Request.Headers["Cookie"];
if ((null != cookieHeader) && (cookieHeader.IndexOf("ASP.NET_SessionId") >= 0))
{
Response.Redirect("sessionTimeout.htm");
}
}
}
}
{
if (Context.Session != null)
{
if (Session.IsNewSession)
{
string cookieHeader = Request.Headers["Cookie"];
if ((null != cookieHeader) && (cookieHeader.IndexOf("ASP.NET_SessionId") >= 0))
{
Response.Redirect("sessionTimeout.htm");
}
}
}
}
Monday, 3 January 2011
web sevices security
http://www.15seconds.com/issue/020312.htm
http://www.beansoftware.com/ASP.NET-Tutorials/Managing-State-Web-Service.aspx
http://www.beansoftware.com/ASP.NET-Tutorials/Managing-State-Web-Service.aspx
Delegates AND Generics
http://en.csharp-online.net/CSharp_Delegates_and_Events
http://www.15seconds.com/issue/020815.htm
http://www.15seconds.com/issue/031024.htm
http://www.15seconds.com/issue/020815.htm
http://www.15seconds.com/issue/031024.htm
Subscribe to:
Posts (Atom)