In this tutorial, I will share eight handy debugging tips that you can use whenever you hit a roadmap building something cool with Episerver CMS. Some developers seem to find debugging difficult. Not being able to debug an issue quickly can be the difference between an average developer and someone who seems to have ninja abilities 🐱‍👤. I'd guess that debugging and fixing errors typically consumes around 25% of my time, so being able to do this efficiently will make you a master. Sitting in front of a PC not knowing why something is broken to nor working, to put it mildly, is fucking annoying 😉. Over the years, I have, unfortunately, had to come up with and discover many different ways to debug Episerver and this article is going to go over the most useful ones 🔥🔥🔥

Reset All The Things

The old adage of turn it off and on, is every bit as relevant in CMS development as anywhere else in the tech world. If I have an odd issue, the first thing I do is turn things on and off. Here's how to reset an Episerver solution. To reset your local webserver quickly, open your command prompt as an admin, type in IISRESET. If your Visual Studio is a bit funky, like Intelli-sense is broken etc... reset Visual Studio. When doing this make sure processes named devenv.exe (Visual Studio),VBCSCompiler.exe(Visual Studio caching process) and any namedwcw3.exe` (IIS) are closed and reset. After this, re-open your Visual Studio.

Next, you want to purge the cache. If you have renamed a namespace, or, get a duplicate assembly warning, clean your temp internet files. You can do this from here:

C ➡ Windows ➡ Microsoft.NET ➡ Framework64 ➡ v4.0.30319 ➡ Temporary ASP.NET Files

These files will be locked if you try to delete them. Use Unlocker, or Lock Hunter to unlock and delete the files. Remember, when doing this always do an IISRESET afterwards.

Debugging

After trying to clean your solution, if you still encounter an Episerver issue, it might be a good time to hit the logs. My first port of call is usually the System logs. You can open event viewer by clicking the Start button then clicking on:

Control Panel ➡ System and Security ➡ Administrative Tools

Next, double-click on the Event Viewer option. In Event Viewer you can find any IIS related logs here:

Windows ➡ System

Have a look at all the errors. These are the ones with the red icon next to them to see if any relate to your site. A thing worth pointing out is that sometimes these logs can have a 10-minute delay before they appear. Next, check your IIS logs, these are usually found here by default:

Resetting, clearing and checking logs will usually fix 80% of your errors.

Reflection On Third-Party Assemblies

Another root cause for issues occurring in my project is either my own stupidity or lack of knowledge on some part of the CMS. If you are unsure about how some core bit of functionality works.. look at the code! You use use either Dotpeek for free of .NET Reflector to do this. Using these tools you can open up any EPiserver .dll files and look inside them. None of the code is obfuscated so you can always figure out what's going on with a bit of detective work. I use this approach a lot to figure out, why an error is being thrown.

SQL Profiling

Sometimes you might be making a call in code to Episerver 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 a SQL profiler allowed me to see what store procedures and database calls the API made. 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 that people with no budget can use. Simply point the profiling tool at your database, start recording the requests, and then perform the API call you're interested in debugging. After the request is complete, stop recording and you can retrace what calls were made., what data was passed and what data was returned.

CSS Issues

Nowadays all browsers ship with pretty powerful developer tools. To open the Chrome dev-tools click Shift + CTRL + J. Alternatively, right-click on any page in Chrome and select the Inspect Element option. Here, you will also get a host of tools to modify CSS on the fly, inspect what HTML has been rendered, discover how long files have taken to download, what's cached, what your cookies are set to and loads more. CSS wise I would also recommend ColourZilla, Page Ruler.

Inspect Network Requests

If you're trying to debug, you need to be able to see what requests your browser and application are making. You can use your browsers dev tools to see what requests your website is making. Within a browser, you can easily check the request headers and the response. How though do you capture what requests an API is making, an Episerver scheduled task requests, or if you re using the CMS in a headless mode what requests its making? To capture all HTTP requests being made on your local machine, you can use either Fiddler or Charles Proxy. These tools will capture everything, not just browser-related requests. This can be really handy for end-to-end debugging. If you need to capture more things than the requests made by your browser, use one of these tools!

Inspect Windows

There are times when you might want to know what Windows is up to in the background. For example, you may have an Episerver scheduled task that needs to read in a list of files from a folder and then do some processing on them. You need to check which files the task is calling but you can't see anything as it's all run in the background. In this case, this SysMon provides detailed information about process creations, network connections, and changes to file creation time. If you want to check that your file system is being called correctly, this is the tool for you! I use this all the time to debug scheduled tasks, or, APIs that need to read from local file storage.

Testing All The Links On Your Site

When debugging, you will want to make sure that all the links and pages on your site work. In some instances, a broken page can actually take down your website 😔. I remember on one project, I had a container page. The container page had no view and it wasn't linked to on the site and the only way to access it was via a breadcrumb. The page was not checked by QA and we all missed it. When called this page would cause a stack overflow. If the page was called more than 5 times in 5 minutes, IIS would take the site down. This is an IIS thing, more than 5 stack-overflows in 5 minutes will turn off the server. This error resulted in the site randomly turning off in production... ahhh! The tool I used to debug this issue was Xenu's Link Sleuth. Xenu will spider your site and will also check that all of your links work. Using this tool will allow you to see if any of your pages are throwing 500 errors. If you find any, inspect them to see what's gone wrong!

I hope this list helps at least one day there get to leave work on time 😉. Happy Coding 🤘