One of the most common configurations people use when setting up ELMAH is email exception logging so that you get notified whenever “shit’s goin’ down” on your site. This leads to a follow on issue that stems from this in that you end up receiving 100’s of emails a couple of times a week as your website gets scanned by evil doers looking for vulnerabilities – but there is a simple and elegant solution.

Web.config transformations have been around for a while now, and a lot of developers use them in their staple day-to-day environment deployment strategies – hell, Scott Hanselman was spouting about them way back in the beginning on 2010 with his “Web Deployment Made Awesome: If you’re using XCOPY, you’re doing it wrong” post. As usual though, one size does not fit all – and in the case of Continuous Integration fans out there that may have specific build-configuration-based build and deployment scenarios (such as myself), there is the need to have finer grained control over the Web.config transformation process. If this sounds like you, then this post is aimed to deliver.

Adding Accessibility to a website for access by sight or hearing impaired users is a thought that many developers have post build. Along with this, when you’re tasked with the job of building an accessible website, Visual Studio probably wouldn’t initially be a tool that comes to mind, but Visual Studio has everyone fooled on this topic as it has this functionality covered, you just need to look a little below the surface.

TeamCity is one of the greatest tools to hit the Continuous Integration world, with free licensing for 20 build configurations and an easy to use interface it ticks all the right boxes (not to mention ease of use for Windows Users) – but once you splash out on an Enterprise license and grow your installation to house many build configurations you start to want more power, and this is when a second build agent is your ticket to freedom.

ASP.Net’s [Authorize] attribute is another cool feature that makes it easy to add authentication at the Controller level when building a website, but the real goldmine here is that like nearly everything else in ASP.Net MVC, you can pick apart the functionality and extend it yourself – In this post we will take a look at creating our own custom Authentication attribute.

Anyone who asks me will know that i love the simplicity and elegance of creating ASP.Net MVC’s custom data annotations when writing your own validation in ASP.Net MVC. One situation that can be a tricky one to dig yourself out of when coming to more advanced validation logic is writing custom validation attributes that can see/compare properties between itself and other model properties.

The XML Serializer built into the .Net framework is a pretty cool side-utility when working with anything that consumes XML. A few years ago I posted about how your should Make your XML strongly-typed: Because you can and it’s easy in which I discussed how easy and awesome it is to use the XSD.exe tool to quickly convert an XML file into a XSD and then further covnert into a Serializable c# class file. The only not-so-perfect part of using the XML Serializer is that it by default adds namespace and schema attributes that point at the W3C standard declarations – but it’s just as easy to remove these so your resulting XML looks perfectly like your original XML file.

Microsoft SQL Server's Profiler is a necessity when digging around on a SQL server trying to find any bottlenecks or long running queries. How you personally lock down your profiling session to show only your application's data access appears, from the experience of looking over others' shoulders as well as how I personally go about it, to be a "how you taught yourself one day when first debugging queries". Like most things in dev-land someone had this problem WAY before you and there is a final, easy solution.

One of the subtleties I've found recently while working with the Windows Phone 7 SDK is found when working with the ApplicationBar programmatically. There are a number of differences that the ApplicationBar has when compared to a normal Windows Phone 7 Silverlight control – these very differences can be really frustrating if you are not aware of them as they stop you from interacting with it in the same way you do other Silverlight controls. Hopefully after we’ve taken a closer look it will make sense why they are so.

When updating a project’s Database Schema as part of your deployment strategy, you want to automate as much of the process as possible to avoid human errors. If you have a Visual Studio Premium installed on your build server, generating schema update scripts is easy to achieve with the built-in database tools that the IDE contains. I will show you how to do this easily and also automatically deploy the changes to your destination server with the awesomeness of TeamCity.