What are the Pros and Cons of using Global.asax? [closed] - asp.net

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Let's collect some tips for evaluating the appropriate use of global.asax.


It's simple to use if your session and application initialization code is very small and application-specific. Using an HttpModule is more useful if you want to reuse code, such as setting up rules for URL rewriting, redirects or auth. An HttpModule can cover everything a Global.asax file can. They can also be removed and added easily using your .config.


I've used it before to catch errors at the application level, and to do something when a user's session expires.
I also tend to use it a lot to provide static properties that read values from the web.config.
I think it ok for stuff like that, though I wouldn't put much more than that in there.


Initializing ASP.NET MVC. :)
Custom user authentication.
Dependency injection, like extending the Ninject HttpApplication.


Its a stiff drink, just be careful not to drink too much and you'll be ok.
I use it for global error handling, and setting up routes in mvc. You don't want to be writing global page_init code in there though.
If you stick to application level events, and make most of the logic actually live in classes that just get called during those events, you will have no problem making use of the global constructs.


It's a nice spot to grab session initiation, and even request initiation. Others have mentioned the error handing aspect, although be careful of exceptions thrown from non-asp.net threads (eg. threadpool or custom thread) as they'll bypass the global.asax handler. Personally I always have one, I think of it as simply part of the plumbing.


I used to use Global.asax for things such as error handling etc, however, I have since gone to using HttpModules to replace this as I can copy it from one project to another without editing the global.asax.


Con of using Global.asax compared to an HttpModule : You will be tempted to write code that's hard to reuse because it will be too tied to that particular application.


I haven't really used Global.asax. I used it's equivalent in classic ASP all the time, but that had mostly to do with certain configurations like database connection strings and such. The config in .net makes a lot of these things a lot easier.
But if you want to implement application and session level events, this is where ou need to go.


Global.asax can inherit from your own class that inherits httpapplication. Gives you more options as well as putting the bulk of the code you might have in global into a class library.
EDIT: Having your HttpApplication class (global.asax parent) in a seperate class library can promote reusability too. Although i agree that using HttpModules is better suited for many tasks, but this still has many uses, for one, cleaner code.


The Session_Start event in Global.asax is a wicked good place to initialize your session variables.

Related

How important are modules and handlers?

Well, I'm just learning ASP.Net, and after reading some books I found that there are this things called Modules which tweak a Request and Handlers that (I think) tweak a response. The problem is that I can't understand how they really work, so I prefer just skip this part and come back to them when I get a bit more comfortable with the ASP.Net framework.
My question is, are they a big part of this framework? Am I going to use them a lot?

ASP.NET modules and handlers are definitely important, but typically they are secondary to pages and services: so it is reasonable to focus on pages and/or services first.
As your understanding grows, modules and handlers will probably start to make more sense when you revisit them.
Having said this, a related SO question explains ASP.NET modules & handlers about as simply as one could hope for.

IIS7 Integrated Pipeline - Request is not available in this context

Is there a way to test if the current request (HttpContext.Current.Request) is available in the Application_Error event of the Global.asax when using Integrated Pipeline with IIS7 in ASP.NET? Currently I am using a try-catch, but it seems like there should be a way to verify rather than catching an exception.

Unfortunately, I believe the answer to your question is no. This question seems to cover what you're asking. You can use reflection, but it doesn't seem very reliable. Articles like this blog post recommend not doing this, and even say:
"Because this event is intended for global initialization activities, any logic that references a specific request is typically a design oversight."
But what does he know about the design of your site, amirite? Your only choice if you really want this is to go back down to Classic.

Is the PreApplicationStartMethod in ASP.NET 4 a good thing?

Disclaimer:
This is the first time I am asking a question that might be classified as subjective. As English is not my first language, it is hard to phrase this right. So please feel free to edit the question in order to make it clearer, or to point me at other ways for asking this.
Intro:
David Ebbo (architect on the ASP.NET team) just posted on Register your HTTP modules at runtime without config using the seemingly undocumented PreApplicationStartMethod assembly level attribute
I have mixed feelings about it.
On the one hand it is good to be able to do things as early in the application startup phase as possible.
On the other hand: Does it suffice? Do we need a PrePreApplicationStartMethod allowing to fiddle with the PreApplicationStartMethod behaviour? What about expansion to non-assembly use (for instance, NuGet already works around the single-use-per-assembly restriction of PreApplicationStartMethod)?
Question: Besides using it for config-less startup, what do you think of the PreApplicationStartMethod attribute?

I think one of the good usages for this is that it allows someone who is writing a 3rd party assembly, or a team that is working on an assembly that will be used in many projects, to be able to use this attribute to initialize stuff w/o requiring the end user/developer to create anything in the global.asax in the application startup events.
There are lots of app specific stuff that people like to/need to configure in global.asax, but if you are creating a DLL, you no longer have to make the user configure your classes in the global.asax, you can just put all your logic in your own init/bootstrap function and rely on asp.net to call your init logic when the app starts.

best practices for logging in ASP.net MVC?

What's the best way to log in ASP.net MVC? I mean any event, I'm currently using NLog but I know there are a lot of possible ways to do it.

I use log4net, its quite good. There are some issues to be aware of, you can learn more about them here. I also recommend Elmah, for me I use it on every project I do, its a prerequisite.

I don't think there is a best framework/tool or standard way in ASP.net MVC. Just do it the way you would in any other framework. When I set up logging, I usually think of it as a resource available to the rest of the application, rather than being tied to a particular tier. This is common, and in fact logging is the standard example given when introducing Aspect Oriented Programming. See:
Logging mentioned in the wikipedia entry on AOP
Another AOP into that uses logging as the example
Depending on what exactly you're trying to log, consider using action filters; a great way to log what page requests are made and for error handling coverage. Non-MVC asp.net apps usually do something in the global.asax, as mentioned here. In fact, even if you use the action filters, which I would suggest, also include some basic error handling in the global.asax 's application_error event; it will fire a little more dependably than the action filters if something really crazy happens.
Other than that, call your logging resource at the point where the stuff happens that's interesting to you. DB or File? Either works, and as long as it's encapsulated in a good method or two, you can always switch that later.

What Url rewriter do you use for ASP.Net? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I've looked at several URL rewriters for ASP.Net and IIS and was wondering what everyone else uses, and why.
Here are the ones that I have used or looked at:
ThunderMain URLRewriter: used in a previous project, didn't quite have the flexibility/performance we were looking for
Ewal UrlMapper: used in a current project, but source seems to be abandoned
UrlRewritingNet.UrlRewrite: seems like a decent library but documentation's poor grammar leaves me feeling uneasy
UrlRewriter.NET: this is my current fav, has great flexibility, although the extra functions pumped into the replacement regexs changes the standard .Net regex syntax a bit
Managed Fusion URL Rewriter: I found this one in a previous question on stack overflow, but haven't tried it out yet, from the example syntax, it doesn't seem to be editable via web.config

There's System.Web.Routing that was just released with .NET 3.5.
You can just use Request.RewritePath() in a custom HttpModule
I prefer using an IHttpHandlerFactory implementation and have full control over all incoming URLs and where they're mapped to.

If I were starting a new web project now I'd be looking at using MVC from scratch. That uses re-written URLs as standard.

+1 UrlRewritingNET.URLRewrite -- used in several hundred services/portals/sites on a single box without issue for years! (#Jason -- that is the one you're talking about, right?)
and I've also used the URLRewriter.NET on a personal site, and found it, ah, interesting. #travis, you're right about the changed syntax, but once you get used to it, it's good.

IIS 7 has an URL Rewrite Module that is fairly capable and integrates well with IIS.

I've used UrlRewriting.NET before on a very high-traffic site - it worked great for us. I believe the developers are German, so the English documentation is probably not as good as it could be. I'd highly recommend it.

I've had a good experience with Ionic's ISAPI Rewrite Filter which is very similar to ISAPI_Rewrite, except free. Both are modeled after mod_rewrite and are ISAPI filters, so you can't manage them in code as you have to set them up in IIS.

I would not recommend UrlRewritingNet if you are in an IIS7 Windows 2008 environment.
Reason:
UrlRewritingNet requires that you app pool mode = Classic and NOT integrated.
This is not optimal
Also, their project seems very dead that last 2 years.

I just installed Helicon's ISAPI Rewrite 3. Works exactly like htaccess. I'm diggin it so far.

I used .NET URL Rewriter and Reverse Proxy with great success. It's almost on par with mod_rewrite and uses almost all of the same syntax's. The owner of the project is extremely helpful and friendly and the product works great. This gem provides both Rewriting and Proxy functionality, which many solutions don't offer. IMO, worth a look.

+1 for UrlRewritingNet.UrlRewrite too but why do I always need to end my URL with .aspx? I think it should be improved better regular expression partern.
Why do I always have to end with aspx in virtualURL localhost/Products/Beverages.aspx", "localhost/Products/Condiments.aspx". I just want to type localhost/Products/Beverages", "localhost/Products/Condiments" which look like MVC route.
This one look good but it is not working for my site. I still can't figure it out.

asp.net routing serves the requirement of url rewriting as well and even much more than. With asp.net routing you can not just "rewrite the url" but create custom handlers for various requests.
asp.net routing however requires at least asp.net sp1.
The basic thing that you do for a simple routing to work is add a few route handlers in the Application_Start even inside the Global.asax.cs file.
protected void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}
private static void RegisterRoutes(RouteCollection routes)
{
routes.Add("Routing1", new Route("/Blog/id/2","/Blog.aspx"));
}

Resources