All about Global.asax

This file is used by the application to hold application-level events, objects, and variables — all of which are accessible application-wide. Active Server Pages developers had something similar with the Global.asa file.

Your ASP.NET applications can have only a single Global.asax file. This file supports a number of items.

When it is created, you are given the following template:

<%@ Application Language="VB" %>
<script runat="server">

Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs on application startup
End Sub

Sub Application_End(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs on application shutdown
End Sub

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs when an unhandled error occurs
End Sub

Sub Session_Start(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs when a new session is started
End Sub

Sub Session_End(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs when a session ends.
' Note: The Session_End event is raised only when the sessionstate mode
' is set to InProc in the Web.config file. If session mode is
' set to StateServer
' or SQLServer, the event is not raised.
End Sub

</script>

Just as you can work with page-level events in your .aspx pages, you can work with overall application
events from the Global.asax file.

In addition to the events listed in this code example, the following list
details some of the events you can structure inside this file:

- Application_Start: Called when the application receives its very first request. It is an ideal spot in your application to assign any application-level variables or state that must be maintained across all users.

- Session_Start: Similar to the Application_Start event except that this event is fired when an individual user accesses the application for the first time. For instance, the Application_Start event fires once when the first request comes in, which gets the application going, but the Session_Start is invoked for each end user who requests something from the application for the first time.

- Application_BeginRequest: Although it not listed in the preceding template provided by Visual Studio 2008, the Application_BeginRequest event is triggered before each and every request that comes its way. This means that when a request comes into the server, before this request is processed, the Application_BeginRequest is triggered and dealt with before any processing of the request occurs.

- Application_AuthenticateRequest: Triggered for each request and enables you to set up custom authentications for a request.

- Application_Error: Triggered when an error is thrown anywhere in the application by any user of the application. This is an ideal spot to provide application-wide error handling or an event recording the errors to the server’s event logs.

- Session_End: When running in InProc mode, this event is triggered when an end user leaves the application.

- Application_End: Triggered when the application comes to an end. This is an event that most ASP.NET developers won’t use that often because ASP.NET does such a good job of closing and cleaning up any objects that are left around.

In addition to the global application events that the Global.asax file provides access to, you can also use directives in this file as you can with other ASP.NET pages. The Global.asax file allows for the following directives:

- @Application
- @Assembly
- @Import

These directives perform in the same way when they are used with other ASP.NET page types.

How to place two classes written in different languages in App_Code

What is App_Code ?

The \App_Code folder is meant to store your classes, .wsdl files, and typed datasets. Any of these items stored in this folder are then automatically available to all the pages within your solution.

Everything placed in the \App_Code folder is compiled into a single assembly. The class files placed within the \App_Code folder are not required to use a specific language. This means that even if all the pages of the solution are written in Visual Basic 2008, the class in the \App_Code folder of the solution can be built in C#.
Here is a small catch...

Because all the classes contained in this folder are built into a single assembly, you cannot have classes of different languages sitting in the root \App_Code folder, as in the following example:

\App_Code
Class1.cs
Class2.vb

Having two classes made up of different languages in the \App_Code folder causes an
error to be thrown. It is impossible for the assigned compiler to work with two different languages.

Therefore, in order to be able to work with multiple languages in your \App_Code folder, you must make some changes to the folder structure and to the web.config file.

The first step is to add two new subfolders to the \App_Code folder
— a \VB folder and a \CS folder.
This gives you the following folder structure:
\App_Code
  \VB
  \CS

This still will not correctly compile these class files into separate assemblies, at least not until you make some additions to the web.config file.

In the web.config file , change the <compilation>
node so that it is structured as following:

<compilation>
<codeSubDirectories>
<add directoryName="VB"></add>
<add directoryName="CS"></add>
</codeSubDirectories>
</compilation>

Now that this is in place in your web.config file, you can work with each of the classes in your ASP.NET pages. In addition, any C# class placed in the CS folder is now automatically compiled just like any of the classes placed in the VB folder.

NOTE: The name of sub directories are'VB' and 'CS' for this example. You can put any name you wish to.

SharePoint Server 2010 Preliminary System Requirements

Sharepoint Server 2010 is on its way and it is high time to get ourself familiar with the system requirement of SharePoint Server 2010..

• SharePoint Server 2010 will be 64 bit only.
• SharePoint Server 2010 requires 64 bit Windows Server 2008 (R2)
• SharePoint Server 2010 requires 64 bit SQL Server 2005 or 2008
• SharePoint Server 2010 will support only IE7, IE8 and Firefox 3.x on Windows OS.
• IE6 will not be supported by SharePoint Server 2010

The reason SharePoint platform is upgrading to 64 bit is to utilize the full power of extra bits while using 64 bit bus.

SharePoint performance and scalability can benefit significantly from 64-bit SQL Server and the throughput increases are significant enough for us to make the difficult decision to only support SharePoint Server 2010 on 64-bit SQL Server 2005 or 2008. It has been our strong recommendation for some time that SharePoint Server 2007 customers take advantage of 64-bit SQL Server due to the inherent performance and scale benefits it can provide.

Look out for the space for more news on SharePoint Server 2010.....

Varun