Pitfalls of ASP.NET Precompilation of Views
As a developer, there is nothing worse than thinking one version of the codebase has been deployed, when in reality you are dealing with another version. This scenario plays out when dealing with .NET pre compilation of views.
There are some benefits to pre compilation. For one, since the views
are compiled upon deployment, the first user who visits a page gets the
benefit of a faster experience. This is because instead of the .NET view
code being compiled at first access, it is already compiled and
therefore gets immediately transferred over the wire.
A second benefit from ASP.NET precompile of views is that errors are caught at compile time rather than at run time. This results in a better code base and less error prone code, exactly like the advantages of .NET and Java over dynamically typed languages such as Python, Perl, or PHP.
However, there is one pitfall that I have experienced that has the potential to outweigh these benefits. It comes after of deployment of pre compiled code. In certain instances, when a codebase has been flagged as pre-compiled, ASP.NET does not clear out its temporary files folder where it stores compiled views. This results in old code being left in the wild when you believe you have deployed new code. This is deeply troubling as I even went so far as to decompile certain views with JetBrains dotPeek, and they were identical to the views I believed had been deployed. However, even after deployment, since the code was pre-compiled, IIS did not clear out its temporary internet files and so old code was still being executed. This is a major pitfall and needs to be mentioned. The solution is, when you are encountering weird behavior on a pre-compiled site, clear the .NET temporary files location!
It seems the root of this problem really rears its ugly head when you deploy one version of the code that is precompiled, and then turn precompile off and deploy another version. Since pre-compiled and regular views are two different files, both exist in the IIS bin/temp file directories. If the temp directory hasn’t been cleaned out, then once IIS starts up, it has to decide which one of the files it needs to take – the pre compiled or non pre-compiled versions. It will default to take the pre-compiled version, and if the code has changed, you will generate an exception when that view needs to be loaded, as it does not contain the correct data structures that the updated controller expects.
Another pitfall having regarding pre compilation of views has to do with third party code. If you have read my previous blog posts, you would know that I have been dealing a lot with the Sitecore CMS system recently. Sitecore has two types of servers: A CM server, or master server, in which internal users make edits to Sitecore pages. After edits have been made and are ready for production, these edits are “published” to CD (content delivery or CDN) servers, which are the servers that customers actually hit when visiting the site in production.
It turns out that the Sitecore code is not meant to be pre-compiled. Since Sitecore is not meant to be precompiled, when publishing content, we need to withdraw some of the Sitecore files from being published to the CD servers, and only publish Sitecore files that have been precompiled. Otherwise, if you publish files that have not been pre-compiled, the CD servers in production would throw errors. We have had to modify our deployment process to only deploy a subset of the Sitecore CM files to the CD servers, which is a time consuming process to set up.