Back to all posts

Avoiding Unexpected Bundling Issues with ASP.NET MVC

Posted on Jul 14, 2016

Posted in category:

One of the most commonly overlooked tasks that I find when working with development groups is the act of Bundling and Minification of CSS and JS resources. There are many solutions to accomplish this task and various developers will have their own preferred frameworks. I personally find that the features provided by ASP.NET meet many of my needs quite well, however, there is one common gotcha that can impact production deployments that might not get fully tested. This post is not specifically about HOW to bundle with ASP.NET, but is more around how to prevent unexpected issues in production.

The Issue

This post was sparked by a production issue that I experienced working with a project recently. This project was an ASP.NET MVC project with a large number of resources that were registered through the bundling process. The development site deployment worked flawlessly and developers had been testing there for weeks. However, the day that the application was published to production all of the bundled files were returning 404 or similar errors! Not good!

The Resolution

It is important to remember that by default ASP.NET does not actually bundle and minify files unless the web.config indicates that the application is not running in debug mode. This is an aspect that is often forgotten by developers and results in production deployment issues on a regular basis. In our situation, the issue was that a created bundle used a URL fragment that referenced a similar file path to that of real assets. IIS took over the request and identified that the file couldn't be found.

To prevent this, we want to make sure that our bundle paths do not reference our existing folder structures. My typical recommendation is to use something similar to /bundles/scripts and /bundles/styles, or similar. This way we can know for sure that our bundles will not conflict with any other resource and that IIS will handle things properly. Additionally, we need to address the situation of our development environment and how to ensure that we ALWAYS bundle. The solution for this is to add BundleTable.EnableOptimizations = true; to our bundle registration. By doing this, even if in debug mode we will still bundle our resources.


The lesson learned here was to use a unique bundle path and to ensure that we are actually testing the optimized files, rather than just having our bundle include each of the files. As a personal rule of thumb, I recommend just forcing the optimizations, unless there is a specific debugging need. Barring this, ensure that your QA/Development environments are properly set to bundle so you don't end up practicing in production. You can read more about bundling in the Official ASP.NET Documentation on bundling.