Some .NET Debugging Tools and Tricks

Very interesting case study here of some Microsoft MVPs trying to find an error in a client’s ASP.NET application, while working off-site.
Couple of important, but lesser known debugging tools gets mentioned along the way: Sysinternals for monitoring your Windows server and .NET Reflector (which was previously Roeders Reflector until RedGate took it over) for digging through assembly code. Also Windows Server Minidump is worth knowing about.

A tool not mentioned in that article (because it’s not relevant) is the “Microsoft Intermediate Language Disassembler”, ILDASM – if you need to really take some .NET code apart.
For web application debugging the Fiddler Web Debugger is indispensable. You can get the basic functionality from here in the Firebug net tab – but Fiddler adds more debugging options, like for example the ability to change the data being posted to your web server.

Finally Visual Studio is of course the most used debugging tool for .NET developers, and there are some new debugger features in VS2010 that’s worth knowing about, like the ability to label break points, to pin the data tips to retain the value (and compare to the previous after a refresh) and even append comments to these.

Finally, finally – if you’re lucky enough to own a version of VS2010 Ultimate, you will also have access to IntelliTrace which lets you step backwards up through your code (with some limitation I believe).

Absolutely last finally – the best debugging tool is sometimes to have a cup of coffee, and then fetch one of your colleagues, or a friend or even Irene from reception – and explain to them what the code is trying to do, how it fails, what you have tried to fix it – and nine times out of ten (well six out of ten at least) somewhere along that process – between the coffee and rambling at innocent bystanders – you will probably at the very least come up with something you haven’t considered yet.


Translate a Regular Expression into plain English

Regex Hero – the excellent online .NET regular expression tester – is now able to translate a regular expression into plain English.

The feature is only available in the professional version, but at the time of writing this is priced at a very reasonable $10 per license – very good value for money!

The Umbraco Database – and Content Versioning (Rollback)

Take a look at the lovely picture below. Int’it pretty?
Umbraco Database Diagram - Core Tables

Now working with Umbraco you really don’t (or shouldn’t) care too much about the database and the structure of this, the content is published to the cached XML structure (as described elsewhere), and this is what you work of.
However, I was looking at the very impressive rollback feature of the Umbraco CMS, where you can not only view all previous versions of your document, but also review “diffgrams” of all the document property values before selecting a version to roll back to.
I wanted to see how Umbraco achieved this at a database level (I’ve worked on version systems before, and it’s always a great opportunity to write some hugely over-complicated and convoluted code).

Referring to the tables in the diagram above (click it for full size version) – umbracoNode is your node tree in the content pane of the CMS, from here cmsDocuments get published, and then the actual XML content that gets published is stored in the cmsContent table (which has a 1-to-1 relation over to the cmsContentXML table that holds the actual XML).
Now you’d have thought that different versions of cmsContent would then get saved off in the cmsContentVersion table right…?
But no, this only holds a FK to the cmsContent table, a versionDate and then a “VersionId” which is a GUID.
This GUID turned out to be the key to the puzzle. Even though there’s no relational integrity enforcing this, the versionId guid links into both the cmsDocument and cmsPropertyData tables, both of which also hold versionId GUIDs.
So the cmsPropertyData table is really key in the Umbraco database – this is where your data (the actual values of the document properties) is saved, versioned and published to XML from – if you query it in SQL you can see a rolling history of all the little changes you have made to all the properties of all your documents, and if you order by the versionId – you will see that all properties get saved for each version (not just updated ones).

Overall I would say it’s a slightly surprising design, I’d expect them to version of the actual published XML data, rather than painstakingly save off the history of each property – but of course the problem with just saving the XML blop is that the document structure might change – users can of course add/remove/change properties which will cause problems when you then afterwards want to try and roll back.
What the cmsPropertyData table provides is a sort of dynamic history – where deleting a property from your document type, will also remove (I assume, as you have RI between cmsPropertyData and cmsPropertyType) the version history for that property’s data (across all documents).
The end results being that you always have a version history that is comparable to the current document type (save of course for added properties, but these can of course be compared to their default value).

Anyways – that’s guessing at the reason for the design – but it’s an interesting approach for sure.

Umbraco, ASP.NET MVC/MVP, Unit Testing and Version 5.0

So – it’s the return of the Umbraco, and quite a bit has changed since I last spent time with this lovely beast – but it looks like a lot more is about to change.
Since I last worked with this I’ve been working on a couple of ASP.NET MVC projects, which really is great – and like most everyone else I am of course now going around saying how I “cannot believe!” that we all managed to put up with “classic ASP.NET” for so long… bit like we all felt about “classic ASP” a few years back.

So coming back to Umbraco with my new shiny MVC hat on, I of course straight off starting speculating how I could do unit testing and IoC stuff on here.
Turns out Aaron Powell is your main man on this. He’s cooked up a very nice solution where he combines the ASP.NET MVP project with his own (or Farm Codes own) Linq to Umbraco project, and achieves something very close to the stuff we have with ASP.NET MVC. Views (presenters) and Controllers and he is even able to unit test his Umbraco dependent controllers without a HttpContext by using Linq to Umbraco.

The one small fly in the ointment (don’t you hate it when there’s a fly in your favourite ointment?), is that Umbraco 5.0 is going to be based on ASP.NET MVC, and so, one assumes, will have full support for developing MVC .NET macros (almost wrote usercontrols there).
This kind of leaves you with a hard choice for a 4.5/4.6 solution.
Frameworks like ASP.NET MVP, admirable as they are, are almost certainly going to die away in favour of ASP.NET MVC. I can’t see anyone choosing this over the official MVC framework for a new project, and as MVC can also co-exist with classic ASP.NET, it’s very difficult to see any real future for such a project.
It even seems the devs themselves agree, last update on their codeplex site is more than 6 months old at the time of writing, and what’s available is a 0.9 version.
So of course you have to ask yourself, is this the best foundation for my new project?

For enterprise projects this becomes even more relevant, if you start plugging ASP.NET MVP and Linq2Umbraco into your project – you are pretty much on your own, any dedicated Umbraco support can’t be expected to answer or solve problems that might be related to this.

Seems to me, the best approach right now, is to accept that for the time being Umbraco is a classic ASP.NET framework. So do your unit testing on your business layer, and then (if u get the time) do integration tesing with WhatIn or Selenium – and then wait around for brilliant people like Mr. Aaron Powell (who I believe is on the Umbraco core team) to get all the good stuff into version 5.0 – and use this for your next project.
Most likely you would also be able to upgrade from 4.x to 5, and start adding MVC code into your solutiuon at that point – if you’re really, really desperate to use MVC.

I think the overall issue here is also the slightly geeky “must have the latest gadget/tool/framework” mindset – I’m not questioning that ASP.NET MVC is the future, but ASP.NET 4.0 is not just something to be completely ignored, it’s still the flagship (even though all the hot chicks are over on the MVC Cruiser drinking mojitos) and will remain so for the time being.
Before ASP.NET MVC, there was of course a load of ALT.NET writing about how to keep the ASPX/ASCX layer as thin and stupid (that’s how I like my UI) as possible, which mainly means you should have extremely simple event handlers as a rule of thumb (if/else), delegating all the heavy lifting into reusable and testable business/service classes. Also there is nothing stopping us from adding IoC containers to classic ASP.NET, and setting up the business layer as a series of testable services.

There – I feel much better now. Who needs ASP.NET MVC anyway… :0)

Debugging and Troubleshooting Umbraco XSLT (and .NET)

First and most important – append this to whatever URL is not working: ?umbDebugShowTrace=true. This gives you quite an amazing amount of information.
It’s based on the default ASP.NET trace – but the Umbraco people have (as always) been very diligent, and provided us with a ton of extra information written to the trace.
For example you will find that on the PreInit ASP.NET page life cycle event, the node matching the current URL is fetched using XPATH (of course), and then added to the cache, so you will only see this XPATH being executed on republish.
After this, in the Init page event, cached macros are loaded in, and then any XSLT transformations are handled after this.
If you go change your Macro settings in some way (or just recycle the app pool to flush all caching), you will see the Macro being rendered- and then loaded from the Umbraco cache next time round.
What’s interesting is that XSLT is not cached, the transformation are always executed. As XSLT is extremely fast and in this case working on the cached Umbraco XML (every time you publish something, the entire site structure is rendered as XML and saved on disk (/app_data/umbraco.config) and also cached in-memory on the server), there’s of course no need to cache the results of this work, as the process is already very efficient.

There’s loads more stuff like this in the trace – but what is really, really useful – is that you get the full XSLT exceptions in stead of the default “failed to load XSLT file…” error.

If umbDebugShowTrace does not provide you with enough info to solve your problem, you will find that you can attach Visual Studio to whatever local process your site is running in (Casini or the IIS w3p) – and from here debug everything, even your XSLT files (try it, setting a breakpoint in your XSLT actually works).

Nice selection of VS keyboard shortcuts

Excellent post:

This one especially – missed that for ages: Ctrl+Alt+L – Solution Explorer
Then hit esc to return to the code editor – neat!

What’s New in ASP.NET 4 and .NET 4?

Seems MS are churning out new versions of everything at a pace – or is it just me? Quite often you fall into the trap of just tagging along – when I start a new website now and VS asks me – “do you want this in 3.5 or 4.0” – well I go for 4.0.
Why shouldn’t I? It’s nice to be up to date right? But of course the better question is “why should I?”

Well for the .NET framework it’s of course the case that 3.5 was built on top of the 2.0 CLR, and as such they we’re really just additions to the 2.0 framework (some people have speculated that MS were keen to speed up the advancement of their version numbers (Java EE recently made it to 6), and really 3.0 and 3.5 would have made a lot more sense as 2.1 and 2.2).
The .NET 4 framework however uses a grand spanking new CLR (with some improvements to garbage collections, and changes to allow support for functional programming ao), and a load of additional features to the framework.

Some C# changes include optional and named parameters which essentially allows you to pass only some parameters and/or in any order you like. Also we have a new keyword: dynamic. Basically this switches off type checking for parameters defined as such – so I can for example do this:

		public MyMethod(dynamic someObject)

And the compiler will not attempt to check if someObject does indeed have a DoSomethingCrazy method. This is mainly intended for COM objects, but could also be used for reflection – and tbh could also be misused something awful.
You could start throwing dynamic objects around the place and pretty soon you’d have half of your application outside the compilers type checking – but of course why would anyone ever want to do that? (What could possibly go wrong?)
Kind of reminds me of the var keyword that was introduced in 3.0 – of course as this was just a convenience (the compiler would infer the type from the usage, and perform full type checking on compilation (if not intellisense had picked it up already)) – but it had (has) the same potential for misuse that dynamic does, imho anyway.
The var keyword was needed to support Linq – but pretty soon you saw code all over the place looking like Javascript – which did not really pose any risks – but on picking up someone elses code, the problem is that you have to start doing type inference as well – it’s not just the compiler.
When someone writes var x = GoGetMyThing(); – what do you think x is?
So you sit around hovering your mouse over stuff relying on good old Intellisense to do your job for you.
Anyways – of course as frameworks have to support more and more functionality, the potential for misuse will inevitable increase. And as someone pointed out the other day: I am of course free to programme all my projects in .NET 1.1 if it’s something I feel that strongly about.

With 4.0 we also got an update to the Visual Studio IDE – VS2010 – which besides a very neat design and a new and improved default font (Consolas) – also has some very useful new features.
A really nice feature you should def get to know is the Navigate To – use “ctrl+,” to pop this up. It basically allows you to search through everything, from file names to methods, interfaces – etc, and you can even use CamelCase or abbreviations to narrow your search.
Reference Highlighting is another one of my favourites – hover your mouse over any variable in the code window, and instances of this will be highlighted throughout the document. I’m telling ya – if MS ever removed Intellisense you’d see some stressed MS developers around.
Call hierarchy is an improvement to the “view all references” option – which allows you to see calls to and calls from any method or property. Very nifty when getting to know a new project. Also you can see all implementations of an interface (use this when you do the “go to ref” and you end up looking at the same interface every time) as well as all overrides of virtual and abstract members.
Also there is some improved support for unit testing, including the ability to stub out your code from the unit test that you of course always write before you do anything (don’t you? of course you do).

Moving swiftly along to the core of the matter (for me anyway) – ASP.NET 4.0: