Now that I have my MVC 5 app properly configured to run on IIS and connecting to a local Sql Express instance, I need to bring in my supporting packages that provide the necessary plumbing such automatic exception logging and background thread support.
1. ELMAH (Error Logging Modules and Handlers) : automatically logs uncaught error at runtime and fits nicely into an existing app route without further configuration. It even logs exceptions still when “CustomError” is set on inside the root config file. It also support manual log (Elmah.ErrorSignal.FromCurrentContext().Raise(ExceptionInstance||Message)) as any other logging framework such as my log4Net which I tend to use when WPF’ing. both logging framework mentioned here are open source and pluggable. To install ELMAH RUN THE FOLLOWING COMMAND in the Package Manager Console: Install-Package Elmah.MVC
Looking at the Web.config at the root of the application, ELMAH does a few modifications to our file. It adds a sectionGroup named “elmah” containing a few sections representing the default providers or strategies used by the library; a few appsettings Key-value pairs for quick configuration dealing with things such as authorization-requirement for access to the elmah log page located at /elmah. It also registers a few http modules and handlers necessary it to intercepts the errors as they occur in the pipeline. That said, what would happen to exceptions raised from thread not initialized by an incoming request? interesting question
Next, you will also need to download a DDL script for creating database objects. I downloaded MS SQL Server DDL Script to generate the data objects on SQL server express.
Following the recommendation of ELMAH v1.2 SP2 Sample web.config , modify the root web.config for ELMAH to log errors to SQL Server.
“allowRemoteAccess” can be set to either 0 for local only access to the log files or 1 for both remote and local. errorLog enable us to specify the repository of the data to be logged. In this instance, I am using the the app default connection string. That’s all. Now you can launch your app and perhaps throw an exception and then go to “www.yourSite.com/elmah” to view your log.
2. WebActivator. reading the description in the image below, gives a clear idea
concerning its use. With WebActivator installed, we can now use the webacivator PreApplicationStartMethod or PostApplicationStartMethod or even ApplicationShutdownMethod to have some logic execute very early on, before global.asax’s Application_Start gets to run or afterward or even when the app shuts down respectively. These attributes are applied at the assembly level pointing to a static class’s static method containing the logic we want to execute.
3.WebBackgrounder is essential when running background task that may live off the request; that is continue even after request completion. In a normal scenario, the background task would immediately terminate; but with WebBackgrounder, a task is kept alive until completion even preventing IIS from recycling the app while the task is running. If the task is to run in a farm environment requiring some sort of synchronization, then WebBacgrounder.EntityFramework may fit the bill.
4. Quartz.NET may be utile depending on the application scenarios. It is a scheduling component in the non-UI sense for executing task based on certain criteria. To prevent IIS from recycling a running Job, your IJob implementation should also implement the IRegisteredObject found under System.Web.Hosting namespace and prevent the only override-able method “Stop” from returning until the job has completed.
Usually perform essential configurations synchronously using WebActivator PostApplicationStartMethod before launching quartz scheduling configuration code on the background using WebBackgrounder