CodeGarden 09 Open Space Minutes -Space 2: Exception Handling in Umbraco

Those of you lucky enough to go to CodeGarden '09 you'll know the format of the Open Space already but for those of you who didn't, Open Space is the time that the attendees are invited to talk about something they're interested in so I proposed two:

1. Space 1: Selling Umbraco
2. Space 2: Exception handing and error reporting in Umbraco (and other .net websites/applications)

I'll write up the Selling Umbraco talk shortly but I wanted to put a few resources together for it first so decided to write this one up first.

First of all we had a brief chat about how everyone handles errors in their applications and the various error handling options available. We discussed three options:

1. Error Handler v2.0
2. ELMAH
3. Exceptioneer

I've only had a brief look at ELMAH and found at the time it was a little too much in the way of RSS feeds etc and I just want an email alert, that said, Lee Kelleher has written a good article about integrating ELMAH with Umbraco here and I've written another article about integrating Error Handler v2.0 into Umbraco here so I'll overview how to integrate Exceptioneer into Umbraco here instead.

Wiring up Exceptioneer with your site couldn't be easier, the best bit is that they do all the hard work for you with their "Integrate" section of the site but to give you a quick snapshot of how easy it is, first of all, download the dll and pop it into your bin folder. Then edit your web.config:

<?xml version="1.0"?>
<configuration> 
    <configSections> 
        <section name="Exceptioneer" type="Exceptioneer.WebClient.ClientModuleConfiguration, Exceptioneer.WebClient" requirePermission="true" /> 
    </configSections>
    
    <!-- This is where you get to specify your API Key and Application Name --> 
    <Exceptioneer ApiKey="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" ApplicationName="YOUR APPLICATION NAME" /> 
    
    <!-- If you're using IIS 6.0 or Visual Studio's built in web server you'll need to add this bit --> 
    <system.web> 
        <httpModules> 
            <add name="Exceptioneer" type="Exceptioneer.WebClient.ClientModule, Exceptioneer.WebClient" /> 
        </httpModules> 
        <!-- If you want to use the JavaScript handling then add the Http Handler as so --> 
        <httpHandlers> 
            <add path="ExceptioneerJavaScript.axd" verb="GET,POST" type="Exceptioneer.WebClient.JavaScriptHandler, Exceptioneer.WebClient" /> 
        </httpHandlers> 
    </system.web> 
    
    <!-- If you're using IIS 7.0 you'll need to add this bit too --> 
    <system.webServer> 
        <validation validateIntegratedModeConfiguration="false"/> 
        <modules> 
            <add name="Exceptioneer" preCondition="managedHandler" type="Exceptioneer.WebClient.ClientModule, Exceptioneer.WebClient" /> 
        </modules> 
        <handlers> 
            <add name="ExceptioneerJavaScript" path="ExceptioneerJavaScript.axd" verb="GET,POST" type="Exceptioneer.WebClient.JavaScriptHandler, Exceptioneer.WebClient" /> 
        </handlers> 
    </system.webServer>
</configuration>

Now, one of the coolest things about Exceptioneer is that you can now also debug JavaScript errors! To debug the javascript errors, just include this script in your templates:

<script src="/ExceptioneerJavaScript.axd?Reporter=true" type="text/javascript"></script>

That's it, you're done. Easy eh? If you want to know more about what it can do, Phil's put together this "lovely" video overview. Exceptioneer have done a great comparison of the main features of comparison Exceptioneer and ELMAH here, the downside though is Exceptioneer is still in beta.

Remember, regardless of how good you think your code is, you should always integrate some form of error handling in your website even if it is just an email to alert you to the fact.

Store common AppSettings in the web.config and an external file (configSource vs. file)

I've started using Rick Strahl's wwAppConfiguration to allow easier access to application constants and one thing that's been bugging me is that it doesn't play nice with configSource -which we update with web deployment projects to specify Development/Staging/Live settings.

The issue is that when you set configSource on the appSettigns node, wwAppConfiguration doesn't correctly set the file's path and instead (when using the default settings) writes the new values within the <appSettings> node. The problem is then that ASP.Net complains that you cannot specify configSource and settings inside the <appSettings> node.

After a little digging, it turns out that you can use "file" in place of "configSource" for the appSettings node (and sadly only the appSettings node) and it allows you to define values within the <appsettings> node and then override them with your external file. This is fantastic because you can store your "default" values in the web.config and then override some or all of them for your various environments.

The next issue you may run into is if you use web deployment projects, in which case you may get the following error:

web.config(2): error WDP00001: section appSettings in "web.config" has 7 elements but "config\STAGING-appSettings.config" has 19 elements.

To work around this, you just need to untick the "Enforce matching section replacements" checkbox within the properties section and you're good to go!

I hope that helps someone!

C# FileInfo.MoveTo Cannot create a file when that file already exists exception

This was one of those irritating errors that you get when you're trying to do something quickly before you go home and you can't for the life of you fathom the issue.

I had the following code (simple enough):

The fix was simple, you just have to remember to specify the new filename too. (DOH!). Here's the "correct" code.

Hope that helps you out ;)

Fix missing JavaScript file when you rename the Umbraco admin directory

The Error

For those of you who have tried to rename your Umbraco installation directory to something other than the default /umbraco/ you'll have found that TreeInit.aspx throws a JavaScript error along the lines of:

Message: Object expected
Line: 1
Char: 4236
Code: 0
URI: http://www.yourdomain.co.uk/youradmindirector/js/xloadtree.js

As this only really affects the refresh of the tree/close of a couple of dialogues I've not bothered fixing it but basically the issue is outlined well here: http://tinyurl.com/cx9atv

The Fix

If you're using extension less URLs already then it's easy as pie to sort:

1. Open your UrlRewriting config file (/config/UrlRewriting.config)
2. Add this above "</rewrites>":

If you've not already using extension less URLs don't panic, that's easy to setup you can read all about it here. Alternatively you could just copy the js files from one folder to another ;)

The Why

I don't know how many people already rename their admin dir from something else but as Umbraco becomes a more popular choice of CMS you really should consider hiding the folder (the more popular it becomes, the more people will become more familiar with the default admin directory of /umbraco/).

Although there hasn't yet been a breach (AFAIAA) if a vulnerability is found, the first step in prevention is obfuscation -hide your admin directory! A quick Google search will show you how easy some developers have made it for you to find their admin sites.

Maplin loses it’s way with it’s GPS

This came through in my email today and it made me smile:

Quick ASP.Net tip: Half your page size in ASP.Net instantly

Ok it might be a little less than half side but it's near enough. I've been sitting on this for a while and needed to reference it for someone so I thought I'd post quickly about it. One of the most common complaints about .Net is that you have a lot of hidden "content" by the way of hidden inputs and the likes throughout your site. This can easily get corrupt on postback/slowdown the page load times etc.

Really you should be optimising each control on the page (enabling/disabling where relevant) but if you want to cheat (lets face it, we all do):

1. Download the files: PageStateAdapterv1.0.zip (3KB)
2. Put PageStateAdapter.browser into your /App_Browsers/ folder (or create one and add it)
3. Put TSDPageStateAdapter.dll into your website's /bin/ folder
4. Load up your website and checkout your ViewState :)

Incase you're interested in the source for it:

The best example of how much this reduces ViewState by is when you add a large DataGrid to your site.

Post files: PageStateAdapterv1.0.zip (3KB)

Update: Apologies to those of you who downloaded and found it wouldn't compile, the .browser file was a little off (missing the second "PageStateAdapter"). I've updated it and changed the zip file download. Enjoy!

Congratulations, you've installed dasBlog with Web Deploy!

After logging in, be sure to visit all the options under Configuration in the Admin Menu Bar above. There are 26 themes to choose from, and you can also create your own.

 

Visual Studio Tip of the day: Open files/folders in Windows Explorer

A little irritation/time consuming process when you're working with multiple projects on multiple drives/SVN repos/directories is to open the current file's location within Windows Explorer. If you weren't already aware, you can do this from most projects/files by right clicking on the project in the solution browser:

Problem for me (and my mate Chris) is that not only is it just for the Project Item but more importantly it means using the mouse -which is something I'm trying to avoid as much as possible. Then I stumbled across a couple of posts which suggested opening Windows Explorer with Visual Studio's External Tools dialog.

They're both great ideas but you still need to use the mouse so I thought I'd take the final step and wire up some keyboard shortcuts. I'll recap the process here as I've added/grouped a few of their settings.

Creating the "External Tools"

There's a little productivity tip here for setting the folder in question the root of Windows Explorer, this encourages you to focus on just the work in question (though it can be a little irritating sometimes so I may "undo" this change later.

Custom #1: Open the current solution item in Windows Explorer

Title: Windows Explorer - Item
Command: explorer.exe
Arguments: /select,"$(ItemPath)"

Custom #2: Open the current Visual Studio project in Windows Explorer

Title: Windows Explorer - Project Directory
Command: explorer.exe
Arguments: /root,"$(ProjectDir)"

Custom #3: Open the current Visual Studio solution in Windows Explorer

We've got a number of projects that have useful files/folders stored in the same folder as the solution file so this one's useful to get quick access to them, I think I'll use this one a lot when dealing with SVN.

Title: Windows Explorer - Solution Directory
Command: explorer.exe
Arguments: /root,"$(SolutionDir)"

Custom #4: Open the current solution's binary (bin) directory in Windows Explorer

Useful when you want to get access to the dll i.e. to copy to another folder/upload just the dll to a website.

Title: Windows Explorer - Binary Directory
Command: explorer.exe
Arguments: "$(TargetDir)"

Custom #5: Open the current solution's target build directory in Windows Explorer

This is useful when you have a project that builds to another directory (i.e. a common DLL directory, I'm not sure how many people do this but I've got a couple of projects that do this so I thought I'd share it).

Title: Windows Explorer - Target Directory
Command: explorer.exe
Arguments: "$(BinDir)"

In all instances you can leave the Initial Directory field empty.

Note: On a couple of the directory related commands I've set the "/root" argument, this is a useful little productivity tip I learn a while ago to stop you navigating away from your work. Irritatingly I've not found a way of using the /select and /root commands together. It would also be nice to say "Open the bin folder and set the root to the project folder" but again I've not found a way.

If you're interested in the arguments I'm using there, check out the Microsoft Support article about How To Customize the Windows Explorer Views in Windows XP (these also work in Vista). Alternatively you can read more about the Visual Studio macros for build commands here (some of which are global I believe). I'm interested to see the use of $(TargetDir) as although it'll be useful for non-web projects, however using Web Deployment Projects might make it irrelevant for you.

You should now have 5 new items in your Tools' toolbar:

Wire up the keyboard shortcuts

As mentioned earlier, I want keyboard shortcuts but if you want toolbar icons, you should checkout the end of this post.

Open up the Keyboard settings within the Visual Studio Option dialog (Tools -> Options -> Environment -> Keyboard) -you may need to select the "Show all settings" checkbox in the bottom left of the Options dialog to see the Keyboard option.

In the Show commands containing field enter "Tools.ExternalCommand" to list the set of commands, irritatingly it just labels each command as "Tools.ExternalCommand#" for each command so this bit will require a little thinking on your behalf. My commands are #2-6 (#1 is the Dotfuscator Community Edition command).

I would then wire up the following shortcuts (I've set them up Globally for convenience):

Tools.ExternalCommand2 (Current Item): Ctrl+E, I
Tools.ExternalCommand3 (Current Project): Ctrl+E, P
Tools.ExternalCommand4 (Current Solution): Ctrl+E, S
Tools.ExternalCommand5 (Bin dir): Ctrl+E, B
Tools.ExternalCommand6 (Target dir): Ctrl+E, T

To enter these shortcuts simply press the first combination (in this case Ctrl+E), then press the second key (I -item, P -project, S -solution, B -binary, T -target). I found that a couple of these were already wired up to ReSharper and Pex which is a pain but I don't tend to use those particular shortcuts so I just overrode them

Now you should be able to press Ctrl+E followed by I and get your current item in Explorer.

It'd be nice if I could get it to use a single instance of Explorer and just refocus the items (on another key combo as that's not always the desired action).

Update: After using it a little, I've noticed that in my projects, I had the Bin/TargetDir the wrong way around (now corrected).