If you use Bundling from MVC , you have two options for disabling caching:
- Use BundleTable.EnableOptimizations . This indicates merging to minimize and optimize your package even during debugging. It generates a hash in the process, based on the contents of the script, so your clients' browsers can cache this file for a long time. The next time you modify the file, it will generate a whole different hash so that your customers can see your changes. The downside is that your script will become unreadable and you cannot debug it, so this may not be the best option.
- Use
System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("url", true) to resolve your URL script, the second parameter ( true ) requires a hash that should be generated using this way, preventing caching from your browser when changing file. This is exactly the same hash generated in the first embodiment, but without an indication.
I created a small demo showing that the second option prevents caching, the trick is getting a hash created from your script contents without decreasing your script.
I created a script file called myscript.js with this content:
$(document).ready(function () { alert('a'); });
Then I added this to my BundleConfig.cs :
// PLEASE NOTE this is **NOT** a ScriptBundle bundles.Add(new Bundle("~/bundles/myscripts").Include( "~/Scripts/myscript*"));
If you add a ScriptBundle , you will again get a mini-response, since the ScriptBundle is just a Bundle using the JsMinify ( source ) transform. That's why we just use the Bundle .
Now you can simply add your script using this method to resolve the script URL with the hash application. You can use Script.Render
@Scripts.Render(System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/bundles/myscripts", true))
Or script tag:
<script src="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/bundles/myscripts", true)"></script>
In either case, a URL with a hash will be created to prevent caching:

After editing my file:

source share