I find that debugging and fixing errors probably takes up around 25% of my day. Sitting in front of a PC not knowing why something is broken is very annoying, to say the least. Over the years, I have, unfortunately, had to come up with and discover many different ways to debug. This article is going to recommend some tools and tips to try and help reduce this time.
The old adage turn it off and on is every bit as relevant in CMS development as anywhere else in the tech world. Here’s how to reset an Episerver solution. If I have an odd issue, these are my first go to tips.
Open your command prompt and type IISRESET
If you have used Nugent and your Visual studio is a bit funky, like intellisense is broken etc… kill all visual studio processes and re-open
If you have renamed a namespace and get a duplicate assembly warning, clean your temp internet files from here: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files and use unlocker to delete the files (do an IISRESET afterwards)
After trying to clean your solution, if you still have a vague error message, then it might be time to hit the logs. My first port of call is usually the System logs. Open Event Viewer by clicking the Start button Picture of the Start button, clicking Control Panel, clicking System and Security, clicking Administrative Tools, and then double-clicking Event Viewer., Windows -> System. Have a look for all the red items (note these logs normally have a 10 minute delay)
Check your IIS logs, these are usually found here by default : C:\inetpub\logs\LogFiles
Taking a look inside third-party assemblies
If you are stuck calling an API and you have no idea how it works.. look at the code! If you use Dotpeek or back in the day reflector, you can open up .dll files and look at what the method your calling is doing. In the past I’ve used this to figure out bugs in the API, why I”m getting an error or even if a method is supported or not.
Sometime you might be calling an API and you want to know what’s going on in the background in SQL itself. I had an example in commerce recently where I needed to figure out how the Business Foundation API worked. Using SQL profiler allowed me to see what store procedures and database calls an API makes. If you have the expensive version of SQL you get profiler included (although you have to install it). There is also a free tool called Express Profiler. Simply point it at your database, instantly start recording and then perform the API call you’re interested in. After this you can see what calls are made.
Back in the old days, Firebug used to be the go to tool for CSS woes. Nowadays, my CSS tool of choice is the chrome developer tool. Right click on any page in chrome and select inspect element. In here you will also get a host of tools to modify CSS on the fly, inspect what HTML has been rendered, how long files have taken to download, what’s cached, what your cookies are set to.
Figuring out what files Windows is calling
There are time when you might want to known what Windows is up to. For example, you may have a scheduled task that needs to be read in a list of files in a folder, you need to check which files the task is calling but you can’t see anything as it’s all run in the background.
Testing all the links on your site work
First, for SEO and good practice, you want to make sure all the links on your site work. One cautionary tale is that a broken link that throws an exception can actually allow an outside source to take down your website. In my case, I had a container page (that should never have been viewed) causing a stack overflow. If the page was called more than 5 times in 5 minutes IIS would take the site down.. causing the 503 Service Unavailable response… ahhh!
The tool I used to figure this out was Xenu’s Link Sleuth. Xenu will spider your site and will check that all of your links work.