Slow ASP.NET MVC website startup in case of many view folders

Recently we’ve observed that it takes too long for our ASP.NET MVC web application to be up and running after a build. It didn’t take long to find out that the cause of the problem was the recompilation of Razor views.

Most of people on the Internet are concerned with the downtime of the production environments after rolling out a new version, and the pre-compilation of views is able to solve it. However, in our case it’s the development process that is being hampered, so naturally pre-compilation gains nothing. Other commonly found advices like turning off unused view engines haven’t had significant results as well.

But why does it take so long to compile a bunch of views? It turns out, the complexity of views affect the total time only to a small extent, but what really matters is how much view folders are there, specifically how much views located outside of the current folder a given view uses.

I’ve created a small application based on the default ASP.NET MVC project with several partials added to the Home page:


Let’s see what Mini Profiler can tell us about the rendering times of the Index page right after a build:


Results suggest that the first partial is so complex that it takes a lot of time to render it; however, the view consists only of a small text string, and swapping the content with other partials does not make any difference. Moreover, partials 2 and 3 take practically no time to render, and so does the partial located in the same folder as the view.

Further experimentation confirms that the rendering of a partial itself takes a negligible amount of time – however, the first time framework encounters a new folder, it stumbles quite noticeably , obviously performing some activity.

Why is it so? Let’s run the trusty DotTrace:


Let’s look at CompileWebFile method in Microsoft reference sources:



So it seems that whenever the view compiler sees a web file, it tries to compile the whole directory (but not more!). What happens next is that we run the compiler and wait until it’s done:



Starting a process is an expensive task, of course, so that explains why we were observing a noticeable delay.

The conclusion to be made is that a dashboard style home pages doesn’t play well with ASP.NET MVC if their component views are located in different folders. I do not know a solution to this problem, because the build strategy is buried well inside the MVC internals, so for now the advice would be to keep everything you reference in the same folder as much as possible.

Passing complex objects to ASP.NET MVC action using HTTP GET method via jQuery ajax

Sometimes, you might encounter a minor issue in ASP.NET MVC: via AJAX, you can easily pass whatever object you want to your POST action, but doing so with GET endpoint is not so obvious. Plain object would work, but once it starts to be more complex, containing nested objects, everything breaks down and nested objects properties are never filled in.

As an example, consider this jQuery bit:

var obj= { prop1: "val1", nested: { prop2: "val2" } };
    type: "GET",
    data : obj

This is what it sends to the server:


or, unencoded:


It seems like array syntax is not welcomed by MVC. What IS welcomed then? Turns out, dot member access is parsed quite nicely – all we need to do is to replace foo[bar] with foo.bar in case of non-numeric array index. The sample code, adapted from the following StackOverflow answer http://stackoverflow.com/a/17580574/76176 is like this:

var obj = { prop1: "val1", nested: { prop2: "val2" } };
var data = $.param(obj).replace(/%5b([^0-9].*?)%5d/gi, '.$1');
    type: "GET",
    data : data

Which produces the following result, happily consumed by MVC: