How to Force Bundlecollection to Flush Cached Script Bundles in MVC4

How to force BundleCollection to flush cached script bundles in MVC4

We hear your pain on documentation, unfortunately this feature is still changing quite fast, and generating documentation has some lag, and can be outdated almost immediately. Rick's blog post is up to date, and I've tried to answer questions here as well to spread current info in the meantime. We are currently in the process of setting up our official codeplex site which will have always current documentation.

Now in regards to your specific issue of how to flush bundles form the cache.

1. We store the bundled response inside of the ASP.NET cache using a key generated off of the bundle url requested, i.e. Context.Cache["System.Web.Optimization.Bundle:~/bundles/jquery"] we also setup cache dependencies against all of the files and directories that were used to generate this bundle. So if any of the underlying files or directories change, the cache entry will get flushed.

2. We don't really support live updating of the BundleTable/BundleCollection on a per request basis. The fully supported scenario is that bundles are configured during app start(this is so everything works properly in the web farm scenario, otherwise some bundle requests would end up being 404's if sent to the wrong server). Looking at your code example, my guess is that you are trying to modify the bundle collection dynamically on a particular request? Any kind of bundle administration/reconfiguration should be accompanied by an appdomain reset to guarantee everything has been setup correctly.

So avoid modifying your bundle definitions without recycling your app domain. You are free to modify the actual files inside of your bundles, that should automatically be detected and generate new hashcodes for your bundle urls.

MVC4 Script Bundles Caching issue

The problem appears to be with the Microsoft.AspNet.Web.Optimization NuGet package. After downgrading the version from 1.3.0 to 1.1.0, everything seems to be working fine.

Link to blog post on codeplex which mentioned the same issue

How can we enable caching for Bundles in MVC5

MVC bundles are returned as a single static file to browsers whose cache time is set to 1 year by default. ASP.NET MVC takes care of change tracking of your bundle files and changes bundle url if content of any file is changed or a file is being added / removed from bundle.

As bundles are already cached and change tracking is maintained by asp.net mvc framework, what else cache control do you want on those bundles?

EDIT (in response to comment)

Unfortunately you can not alter that limit. Cache limit is handles by ProcessRequest method of BundleHandler class and this is internal sealed so there is no chance that you can inherit \ override these requests.

For further details you can refer this question.

c# Bundle Transform Break cache

Two options

1. Set context.HttpContext.Response.Cache.SetRevalidation

2. Setting response.Cacheability to NoCache will work, but this would mean that the bundle is never cached

Bundles Caching and Web farms

AFAIK, when building the bundle, the content is hashed in order to create a unique key for it (the extra parameter in the url).

So if you are modifying its contents the hash will change since it actually represents a different bundle. The whole purpose of that is for cache busting when the content changes.

The behavior your are seeing is because bundles are not intended to be used in that dynamic way, since it goes against the idea that the bundle's content is static (and therefore cacheable).

Why not just create a separate bundle for each page?
That way, the "common" bundle, with all the shared code will be cached and reused, and when loading your ABC.aspx page, you always load your "abc" bundle, that will do its own version control on the contents and not affect the common libraries.

Plus, there is an additional downside to modifying the bundle on each page:

If each page delivers a different bundle, then the client will receive all the code for your shared libraries over and over again, once for each page. Even if cached. For example: there would be no point in sending JQuery along with each page.

---

Related Topics