Ehsan Mahpour’s Weblog

Let’s use the Enterprise Library 2.0 Logging Application Block in an ASP.NET 2.0 Website using the most simplistic, yet very important case of logging unhandled exceptions. If you log nothing else in your ASP.NET websites, make sure you log unhandled exceptions so that you have some idea of the health of your application.  Enterprise Library 2.0 can email you the exception if you want, but I am going to keep things real simple and just have the exceptions logged to a file on the webserver.

 

Enterprise Library Configuration Tool

Once I create my website in Visual Studio 2005, I immediately open up the Enterprise Library Configuration Tool and use it to open the existing web.config file.  Using only the tool, I then add the logging application block configuration section to web.config, remove all the defaults, and replace them with a simple FlatFile TraceListener that catches all events as shown below:

 

 

The Logging Application Block has a Special Source, called All Events.  Hooking a TraceListener to this event guarantees you will receive all events not being filtered.  Since we have no filters, we get all events.  These events get logged to the FlatFile TraceListener, which points to a log file at the root of my website, called trace.log ( default name ).

 

Catching and Logging Unhandled ASP.NET Exceptions

To catch unhandled exceptions in ASP.NET 2.0, I need to do a couple of things.

First, I need to reference Microsoft.Practices.EnterpriseLibrary.Logging in my website.  When you reference this library, it will also pull over a couple of other assemblies, Common and ObjectBuilder, that it depends upon.

Second, I need to add a Global Application File ( Global.asax ) to the website and enter the following code into Application_Error:

 

<%@ Application Language="C#" %><%@ Import Namespace="Microsoft.Practices.                       EnterpriseLibrary.Logging" %>

<script runat="server">

    void Application_Error(object sender, EventArgs e)     {        Exception ex = Server.GetLastError().GetBaseException();

        string message = ex.Message +                         "\nSOURCE: " + ex.Source +                        "\nFORM: " + Request.Form.ToString() +                         "\nQUERYSTRING: " +                            Request.QueryString.ToString() +                        "\nTARGETSITE: " + ex.TargetSite +                        "\nSTACKTRACE: " + ex.StackTrace;

        Logger.Write(message);    }

</script>

 

Logger is the name of the facade in the Logging Application Block to log messages.  I grab the unhandled exception and send it out to be logged.  The application doesn’t know and doesn’t care where; it is oblivious as to the actual logging strategy.

 

Creating An Unhandled Exception

Let’s open up Default.aspx.cs file and make it throw an exception:

 

public partial class _Default : System.Web.UI.Page {    protected void Page_Load(object sender, EventArgs e)    {        int error = Int32.Parse("bbbbb");    }}

 

The above with throw a System.FormatException error which will be logged in the trace.log file when running the application:

 

Timestamp: 2/15/2006 9:23:30 PM
Message: Input string was not in a correct format…<Stack Trace>

 

Conclusion

In about 15 minutes, you can successfully log unhandled exceptions in your ASP.NET 2.0 websites using Enterprise Library 2.0 Logging Application Block.

 

Source:  David Hayden ( .NET Developer )

Here is the source Link : http://yuiblog.com/blog/2007/01/26/video-hewitt-firebug/

The same way you clean up your house before your guests arrive, the same way you should get your website ready for Google’s crawler, as this is one of the most important guests you will ever have. According to that, here are 10 things you should double check before submitting your website to the index. If you want, you can view this article as the correction of the top 10 mistakes made by webmasters.

1. If you have a splash page on your website, make sure you have a text link that allows you to pass it.
I’ve seen many websites with a fancy flash introduction on the index and no other way to navigate around it. Well, Google can’t read into your flash page, and therefore it cannot bypass it. All you have to do is put a text link to your website’s second index, and the deed is done.

2. Make sure you have no broken links
I know this is kind of obvious, but you’ll be surprised to find out how many errors is the Google crawler experiencing daily due broken links. Therefore, you’d better check and double check every internal link of your webpage before submission. Don’t forget that your links are also your visitor’s paths to your content. It’s not all about Google, you know

3. Check the TITLE tags
Since you are able to search in title tags on Google and since the title tags is displayed in the top of your browser window, I’d say this is an important aspect you need to check. This doesn’t mean you have to compile a >20 keywords list there. Instead, make it a readable sentence since it’s viewable by both crawlers and surfers.

4. Check the META tags
Rumors about Google not caring about META tags are not 100% correct. Google relies on these tags to describe a site when there’s a lot of navigation code that wouldn’t make sense to a human searcher, so why not make sure you’re all in order and set up some valid KEYWORDS and a valid DESCRIPTION. You never know.

5. Check your ALT tags
The ALT tags are probably the most neglected aspect of a website since no one bothers to put them in order. It’s definitely a plus if you do, so Google spider can get a clue about all of your graphics. However, don’t go extreme and start explaining in an ALT tag that a list bullet is a list bullet.

6. Check your frames
If you use frames on your website, you might not be indexed 100%. Google actually recommends that you read an article of Danny Sullivan on Search Engines and Frames. You have to make sure that either Google can read from your frames, either that it has an alternative, defined via the NOFRAMES tag.

7. Do you have dynamically generated pages?
I know the web evolved so much in the last period of time, and more and more websites based on dynamic scripting languages (PHP, ASP, etc) are coming out every second, but Google said they are limiting the amount of dynamic webpages they’re indexing. It’s not too late to consider a compromise and include some static content in your pages. It helps.

8. Update your content regularly
This is an important aspect that you should consider, since Google indexes more quickly pages that get updated on a regular basis. You will notice that the number of pages indexed by the search engine will increase day by day if you update, but will stagnate or decrease if you don’t bring something new. I suggest setting up a META option in the header that will tell Google how frequently should it come back for a reindexing.

9. The robots.txt
This file is a powerful resource if used properly. You have the chance to filter out the bots that crawl your website, and you have the chance of restricting access to certain URL’s that should not be indexed (login pages, admin backends, etc).

10. To cache or not to cache?
Google caches some webpages for quick access, but some webmasters do not like that. The procedure is quite simple. All you have to do is write a line of code between your HEAD tags.

META NAME=”ROBOTS” CONTENT=”NOARCHIVE” - should be enough to stop all robots from caching and archiving the page where the code is embedded.

All these being said, you can now submit your website to Google’s index.