Technically this isn't specific to ASP.NET MVC at all, that just happens to be how I use Elmah. I started work on an ASP.NET MVC project with certain erroneous preconceived notions. I originally started the database with SQL 2008 in mind because I run Windows 7. An easily accessible staging server used SQL 2005 and it was here that I ran into my first compatibility snag. A database project may be set for an earlier revision but you can't transplant those .bak files and expect them to restore. This is generally 101 level stuff but something I tend to keep in the back of my mind at the worst times.
This staging issue foreshadowed production: the shared hosting company I use is running SQL 2000. Argh! Luckily this process was less painful: I used SQL Publishing Wizard and SQL 2000 in a virtual machine to get the database on the lowest common demoninator. Once in SQL 2000, the backup files will easily restore in any future version of SQL. Because the push to production is so infrequent and changes can be diff'd easier than rebuilt I've settled on a structure of Development: 2005, Staging: 2005, and Production: 2000.
I chose an Elmah version (1.1.11517.2009) that dealt specifically with SQL 2005 but was hopefully new enough to be relative to ASP.NET MVC. Switching to SQL 2000 produced a very minor snag: the database script needed to be downgraded.
Fortunately, and with the help of Google code, I could go back to other revisions of the same file in the Elmah codebase and find a version suited for SQL 2000 dated earlier this year. Here's the diff link to show what changes were made: http://code.google.com/p/elmah/source/diff?spec=svn705&r=643&format=side&path=/trunk/src/Elmah/SQLServer.sql&old_path=/trunk/src/Elmah/SQLServer.sql&old=568. When downgrading to SQL 2000, use the left hand side or you could just download the file.
Update (2019): Since Google Code has long been out of service, Elmah can now be found at https://elmah.github.io/. To get an appropriate SQL 2000 file, you may have to look at v1.0 and v1.1 sources. I would think in 2019 you would likely choose a more recent SQL Server version.
While you are there, you might as well follow the examples given by Scott Mitchell Keeping ELMAH's Error Log Size In Check and Deleting All Records In a Table EXCEPT For the N Most Recently Added Records. Why both? The first prunes any records beyond a date range to keep errors relevant. The second makes sure your database stays small in case of anything that can trigger a large number of records within your date window.
While this post actually has nothing to do with ASP.NET MVC directly, the only common denominator is that I came up with this technique while working on the platform.
To be a true 1:1 copy of the previous website I would be converting to ASP.NET MVC, I had to come up with a way to reintroduce the <blink> tag to XHTML. While you are perfectly able to use <blink> it doesn't actually do any blinking in IE8 or Firefox. To show that properly, jQuery comes to the rescue.
The technique is really pretty simple:
<div id="#alertheader">)setInterval(function() {
jQuery.each(jQuery.browser, function(i) {
if ($.browser.msie) {
$('#alertheader').css({ opacity: '0' }).stop().animate({ opacity: '1' }, "fast", "swing");
}
if ($.browser.mozilla) {
$('#alertheader').stop().animate({ opacity: '1' }, "fast", "swing");
}
});
}, 600);You should hopefully notice the caveat I ran into immediately. IE and Firefox animate their opacity changes differently so it required special handling. An easy exercise for the reader would be to optimize this code to remove the IE/Mozilla check during the setInterval call.
You can achieve similar results by using a series of .fadeOut(x).fadeIn(x) calls but I had to make sure the sum of all calls didn't become less than the setInterval "loop" or it would blink wildly. The other problem it introduces is when text "fades" it can often look weird in either browser if you use a relatively fast interval. This became a headache very early on.
While I can't take whole credit for the technique, the primary Stack Overflow problem that got me started can be found here: https://stackoverflow.com/questions/1375646/jquery-animate-opacity-doesnt-work-properly-on-ie. In the post the user Eric states that jQuery should handle the opacity support for you. It does. For some reason to produce output I felt was adequate, no one definition would work across both browsers.
Most of this may or may not be relevant to your situation but after completing development, staging, and most of the production implementation of an ASP.NET MVC site I wanted to share some of what I learned.
The majority are one or two-off hacks from someone else's code or a down/upgrade where appropriate, creating a Frankenstein. These won't necessarily be in order I don't think.
Elmah
ELMAH_LogError stored procedure to SQL 2000ELMAH_LogError pruning taken from 2 blog posts from a single sourcejQuery uses
Areas
SQL 2000 from 2005
MsBuild scripts - dependency chaining, SqlPubWiz integration via Community Tasks, etc.
I'll try to refer to this verbatim as my defacto outline and even that isn't quite structured correctly enough. It'll work itself out as the posts are made I'm sure. I'm using this to hopefully keep me motivated to completing them all.
I've recently switched hosting providers at the company I work for. Instead of being able to use wildcard mapping or the .mvc file extension mapping, I'm left with .aspx.
The premise of this exercise is easily explained here: http://www.asp.net/learn/mvc/tutorial-08-cs.aspx, specifically Listing #3 under the Hosted Server section.
While this is fine for a default MVC1 project, I've currently implemented Phil Haack's Areas v1 prototype with Steve Sanderson's CreateArea extension method located here http://blog.codeville.net/2008/11/05/app-areas-in-aspnet-mvc-take-2/.
To make the Global.asax change from Listing #3 in the first link (phew), you need to modify all routes to add the .aspx extension. The same goes true for .mvc.
I followed Steve's example verbatim and eliminated the default "" (blank) route because isn't necessary in wildcard mapping. What isn't readily apparent is that you absolutely need this when you do get into file extensions.
The fix is a simple but because it felt like the same route/area I didn't think it would work.
routes.CreateArea("Root", "Namespace.Controllers",
routes.MapRoute(null, string.Empty,
new { controller = "Home", action = "Index", id = string.Empty })
);RouteDebug confirmed it gets hit properly so that should be all you need. I haven't tested to see whether you can just add this route and leave it for both file extension and wildcard mapping but it shouldn't be a problem to just add it and leave it.
Technically it's still comming!!! but I wanted my first post to officially thank Richard Dodsworth aka "Conkerjo" of Sgt. Conker for letting me host my blog and domain on his equipment. Without such a generous gesture, none of this would be possible.
I also wanted to take the time to pimp Sgt. Conker for its XNA goodness as I play a very small roll in keeping it together. There are a number of admins on the back-end in addition to Conkerjo, like Björn Graf (boki), Catalin Zima (CatalinZ), (Cryovat), Casey Young (ElementCy), and Michael Coles (X-Tatic). It is following the tradition of ziggyware.com in trying to be a great aggregate of XNA information and I must say it is doing a great job for a site that is primarily user-driven. If you've contributed to a ziggyware article in the past and would like that content on Sgt. Conker, or would just like to contribute something new, send an email to articles@sgtconker.com. To be clear, Sgt. Conker isn't trying to 1up or replace ziggyware outright but we're trying to capture as much of the great content that is still relevant.