Friday, September 17, 2010

Continuous deployment on Steroids

Although I don't agree to very idea of commit to production, but still lots to learn from this article-

http://timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day/

I still vouch for Idea of Workflow based commit to production.

Wednesday, July 21, 2010

One elegant way to log the time it took to process a request in ASP.NET

Global.asax and the HttpApplication class

Posted by scott on Saturday, January 24, 2004

The Global class derived from HttpApplication has many uses, including managing application and request state.
The global.asax file setup by Visual Studio.NET gives every web application a Global class derived from HttpApplication. The class contains event handlers such as Application_Start and Session_Start.

There is a tendency to think each web application will have a single instance of Global. Indeed, in most frameworks an object representing the “application” is a singleton – only one exists. Also, we know the ASP.NET runtime calls Application_Start only once when the application starts. All of these clues seem to imply there would be only one instance of a Global object in our application, but these clues are actually misleading.

The ASP.NET runtime maintains a pool of HttpApplication objects. When an incoming request arrives, the runtime takes an HttpApplication object from the pool to pair with the request. The object remains associated with the request, and only that request, until the request processing is complete. When the request is finished the runtime may return the object to the pool, and later pull it out to service another request later – but only one request at a time is associated with an HttpApplication object.


Application State versus Request State
The Application object (of type HttpApplicationState) is what we generally think of when we need to store information global to the application. The Application object is a convenient place to store information such as a database connection string.



private void Page_Load(object sender, System.EventArgs e)
{
string connectionString =
Application["ConnectionString"].ToString();
. . . .
}


You can also make your own static variables in the HttpApplication class to carry application state. For example, the above information could also be stored like this:


public class Global : System.Web.HttpApplication
{
public static
readonly string ConnectionString = "connection information";

. . .
}


You can access the member from anywhere in your ASP.NET code like so:



string connectionString = Global.ConnectionString;


It is important to make the string a static member (you could also make a static property accessor) if you want the member to be global for the application.

If you instead use member (non-static) variables, you can use these for request state. For instance, the following code will print out the number of milliseconds used to process a request in the output window of the debugger.



public class Global : System.Web.HttpApplication
{

protected DateTime beginRequestTime;

protected void Application_BeginRequest(Object sender, EventArgs e)
{
beginRequestTime = DateTime.Now;
}

protected void Application_EndRequest(Object sender, EventArgs e)
{
string messageFormat = "Elapsed request time (ms) = {0}";
TimeSpan diffTime = DateTime.Now - beginRequestTime;
Trace.WriteLine(
String.Format(
messageFormat, diffTime.TotalMilliseconds
)
);
}
. . .
}


Now, returning to the question of application state. Which is better: storing object references in the Application object, or making static member variables and properties in the Global class? Both approaches have pros and cons.

Keeping global data in static members of the Global class gives you strong typing. Unlike the Application object, you will not need to typecast or convert values. It is the difference between the following two sections:



DataSet cachedData = (DataSet)Application[“MyDataSet”];
string myString = Application[“MyString”].ToString();

DataSet cachedData = Global.MyDataSet;
string = Global.MyString;


Strong typing gives you cleaner, more robust code. In performance critical situations it can also save the overhead of running conversions. If you are storing value types, such as integers, strong typing avoids the overhead of boxing and unboxing the value into an object (see references). Also, as mentioned in a previous article, the Application object also has some small overhead due to locking. If you initialize your global data only once and never modify or write to the data, you can avoid the locking overhead with static members on the Global class. If you take this approach, I recommend using accessor properties with only get methods to make sure the data is read only.

If you read as well as write static members of the Global class, remember to be thread safe. The Application object already provides thread safety through a course grained reader / writer lock.

The safest place to initialize the global data is during the Application_Start event.Even though there are multiple instances of the Global object around, the runtime only invokes Application_Start on the first instance of Global it creates. An ideal time to initialize request state is during Application_BeginRequest. Request state variables generally do not require thread safety, as each object services only one request at a time.



by K. Scott Allen (scott @ OdeToCode.com)

Friday, January 15, 2010

Google Outlook Calendar Sync on Windows 2003

After lots of efforts I managed to install Google outlook calendar sync on my Windows 2003 server. By default it supports installation to Windows XP and Windows Vista only.
Solution was damn simple -
Right click on GoogleCalendarSync_Installer.exe and go to properties, then go to Compatability tab, check the 'Run this program in compatibilty mode for;' flag and choose windows XP, click ok and try run again..... Boom it worked :-))))
Something new for me to learn and store on this pagefile.

Tuesday, January 5, 2010

Things to Remember

TypeForwardTo attribute (Use to divert the search for a class from one Assembly to other Assembly without Recompiling the Caller application)
-->For this attribute to work, You cannot change the namespace of the Class if you shift it to other assembly :-(
----------------------------------------------------------------------------------------------
Use HashTable against ListDictionary if n >10 ( See Microsoft documentation )
--> No evidence to support this, except to the fact that HybridDictionary uses an Internal flag to switch the data type ( from ListDictionary to Hashtable) when elements are greater than 10 .
----------------------------------------------------------------------------------------------
ServiceController (Can be used to create you own service manager for Windows service)
--> We should write our own service manager because MMC snap in does not support custom commands.
------------------------------------------------------------------------------------------------
Set ANSI_NULLS ON
--> Do not use Equal and not equals operator with Null when using this , instead use Is Null and Is Not Null operators
------------------------------------------------------------------------------------------------
Set Quoted_Identifier ON
--> Can's use double quotes for string comparison if it is ON :-(
If you want to use [Where name = "Ankur Jindal"] instead of [Where name = 'Ankur Jindal'] then Set Quoted_Identifier OFF

Labels