Cache Buster Strategy in ASP.Net

asp.net, browser-cache

Solution

The answer to cache buster variables in ASP.Net is to use one of the various CSS/JS minification libraries.

I was thinking that the cache buster variables would need to be updated with each deployment to our servers, but the minification libraries apply a hash tag based on the contents of the individual CSS/JS files.

Since I am developing a .Net 3.5 website my choices were a little restricted. I ended up using SquishIt (available as a NuGet package) and it was SO easy to integrate.

<link href="/<my_css_path>/<css_file_1>.css" rel="stylesheet" type="text/css" />
<link href="/<my_css_path>/<css_file_2>.css" rel="stylesheet" type="text/css" />
<link href="/<my_css_path>/<css_file_3>.css" rel="stylesheet" type="text/css" />

became

<%= Bundle.Css()
    .Add("~/<my_css_path>")
    .Render("~/<my_css_path>/combined_#.css") %>

and that is basically it! Similar idea with the javascript. As long as `debug="true"` in your web.config for local development and `debug="false"` for your staging/production environments, SquishIt will leave your CSS/JS unseparated and unminified for local development and then combine, minify and hash (for cache busting) for your other environments.

Problem

What is a good strategy for automatically applying and/or updating cache buster variables on my javascript and stylesheet references in an ASP.Net website? E.g. Transforming ``` <script type="text/javascript" src="/js/myScript.js" /> ``` to ``` <script type="text/javascript" src="/js/myScript.js?rev=12345" /> ``` UPDATE: Continuous Integration is not required. I am using continuous integration (Jenkins to be specific), so it would be great if the method for updating the variables was based on the build number for instance. While I can live with applying the original variables manually in the source code and just updating them via the strategy, it would be a nice addition if the strategy could also apply the original variable if it did not already exist (say to legacy code). Off the top of my head, I can imagine using a Powershell script that scans through all *.aspx and *.ascx files and uses a regular expression to find the appropriate references and update them. But you know what they say about using regular expressions... then I have two problems :)

Original source