Speed Up Your Kentico Debugging in Visual Studio
Introduction
Any seasoned ASP.Net developer knows that building your project(s) before starting a debugging session is an important step to take to ensure that there are no silly coding mistakes lurking around. Most seasoned Kentico developers know that performing a full build on a Kentico web site project can be time consuming if there is not a Solid State Drive in use on the computer running Visual Studio.
I myself have experienced this issue many times over, and a long time ago I finally decided to see what options there are out there for speeding up the process. During my recent journey to Kentico Connection Prague, a few of the other Kentico MVPs reminded me that I had never put out a blog post about a simple trick that you can take to speed up your debugging session in Kentico. Today I am going to illustrate one method that might just save you and other Kentico developers out there some time.
The Issue
As a Kentico developer you might be familiar with this type of activity in your Output window after you click the Start Debugging button in the Visual Studio IDE.
And yes, you probably know that it is not the fastest thing in the world to complete. As it turns out, the issue of slow build times with Visual Studio and Kentico are pretty much due to the way the ASP.Net framework handles compilation in a website project. Basically the C# compiler inspects each directory and file that is contained within your project root directory and tries to compile everything it possibly can.
Because Kentico has a large number of class files to support its highly functional platform, the process of iterating through each of the files in each of the directories can take a long time with a slow hard drive. The reason the process is slow is that the C# compiler builds the project in pseudo alphabetical order, and it takes time to organize 9,000 plus files. You would have this behavior with any large ASP.Net solution.
The Fix
Today I am going to show you a strategy for improving the build time of Kentico in Visual Studio. Take note of how I say "strategy" and not "best practice". I am classifying it as such only because the solution that I am going to overview is not a silver bullet solution that fits every single project and/or website that is built with Kentico. It does however apply to those of you that are using the web site project type in Visual Studio for your Kentico site.
The solution is to change a few project settings in Visual Studio that basically turn off compilation of the web site before it runs. Yes, that is right I said turn it off. Hopefully you did not fall out of your chair after you read that. Fear not dear reader, as a web site project type this is actually an allowed scenario. When you disable the Build at Startup settings you are basically telling the C# compiler to not run until you need the exact used code as the actual page requests come in. You are telling the compiler to compile in a totally ad-hoc manner. The ASP.Net team has termed this Just-In-Time (JIT) compilation.
To configure your Kentico project to rely on only this compilation model you must disable the Build at Startup functionality of your website. To start open up the Configuration Manager for your solution which can be found in the Build menu once your Kentico solution is open.
Opening up the Configuration Manager shows all the projects in your solution. Un-check the Build checkboxes, as the screen shot below shows:
Next open up the Property Pages dialog by right clicking the web site projects top root node in Solution Explorer. It is the item second from the bottom of the list.
On the Build vertical tab change the change the Start action to No Build and un-check the Build Web site as part of solution.
Save and close everything after that. Hit F5 or click Start Debugging and you should no longer have any build happening before Visual Studio starts the built in webserver and a browser window should pop right up and start loading the home page of your Kentico site.
A Warning
Take heed, there are situations where this approach does not make sense. The main one being that if you are using the web application project type this will not help you. The compilation model is different for web applications as it is handled in a mostly pre-compilation manner. Also if you are using the web site project and have a continuous integration or continuous delivery solution in place you might not want to use this setting likely would not want to do this permanently because it could allow errors in to the code that you may be oblivious to. And no one wants to break the build right ?
Conclusion
There you have it. This is how I sometimes increase the speed of Kentico debugging. This makes a ton of sense when you want to get into troubleshooting an issue with one page or one isolated piece of functionality. Do use your best judgment though, I can’t say I would leave it like this 100% of the time.
I am also curious if anyone handles this issue differently. If you do let me know in the comments if you have a better way that you recommend speeding up the build time in a Kentico project.
Let me leave you also with this nugget: There are a few very smart developers, who may or may not work at a certain company that you all know, out there who may be working on a better solution to this puzzle as well. Stay tuned for that.