Fixing the Global.asax in ASP.NET 2.0
When I created a default web service project with Visual Studio 2005 first I found no global.asax page was created. Why its not there by default I do not know as you could easily remove it if not needed, and a empty skeletal one has no performance impact anyway.
To add a global.asax, (or web.config for that matter), simply right click the web site or web server project in your solution explorer, select Add New Item from the context menu and then choose Global Application Class (or Web Configuration File for a web.config).
Happy that I finally had a Global.asax in my project, I opened it only to find that there was no class present! With the scripting page model you get a skeletal global.asax something similar to:
The problem as i see it is two fold.
Firstly there is no class object that can be easily referenced from elsewhere in your application. If you were to load configuration information in the application_start event and store it in a global static, you cannot access that static from elsewhere in your application there is no class name to reference by.
Secondly, as there is no class in the global.asax, you cant use "using" statements in the code easily. There may be a way to do this but it doesnt instantly come to hand. If you place a using before the script tag, the keyword isnt recognised. If you place a using after the script tag its not allowed as you are already inside an implicit class!
After a roam on the internet I came up with an excellent reply post by Scott Allen that showed that you can switch back to the code behind model using the inherits attribute to the Application tag:
<%@ Application Language="C#" Inherits="Global" %>
The only other step is to copy the code within the script tag to a normal class file called Global.cs which you add to the project. Then delete the script tag. An example follows:
Thus I now have simple and consistant use of the using keyword along with a class that is accessible from the rest of the web service to get at preloaded configuration information. My config value in this example can now be access by :
All this is of course still possible within the script model. You dont have to use using statements and can explicitly denote classes. You also can probably store configuration items into the application cache collection instead of your own statics. However, when migrating some older applications that were written using statics, the fact that you can still use the code behind model is quite usefull. Personally I prefer the older method as it provides consistenct and I dont think a dynamic recompile on changing global.asax values is that useful or even appropriate.
But I am interested in knowning the rationale for why the VS2005 ASP team have gone down this change path.