Bundling resources via bundle.config vs BundleConfig.cs in ASP.NET 4.5 WebForms

Question

Regarding ASP.NET 4.5\'s new System.Web.Optimization / Microsoft.AspNet.Web.Optimization:

Can anyone explain the difference in the use of bundling resources using th

Answer 1

As far as I can tell, the accepted answer doesn't actually answer the question at all. It discusses the benefits of the bundling framework, but not how using the BundleConfig.cs is different than using the bundle.config file.

A lot of it comes down to whether you prefer working in code or in markup, but each does have some pros that are specific to that method.

For the bundle.config, there's really only a single benefit, but it is a big one. By using it, you can manage bundles without having to touch code at all. This means that you can make changes without recompiling, making quick deployments easier. Also, it means that your front-end developer, who is going to be most familiar with the files that should be bundled, can define the bundles without having to work with any back-end code.

However, there are quite a few limitations on what you can specify in the Bundle.config. For instance, you can't specify any custom transformations to be applied to individual items or bundles. The only bundle properties that you're able to set are the Path, CdnPath, and CdnFallbackExpression. You can't set the Orderer or EnableFileExtensionReplacements properties. You don't have a way to include a directory including all subdirectories (like you can with the IncludeDirectory method). Basically, there's a LOT of functionality that is only available through the back-end code. Granted, a lot of this you could set by using back-end code to retrieve a bundle that was defined in the bundle.config, and then manipulating. But if you're going to do that, you might as well create the bundle in the back-end, also.

My personal philosophy is to use bundle.config unless I need to do something with the bundle that's not possible that way. However, I do agree that having them all in one place is ideal. If I decide I need to use the class, then I'll use that for all of my bundles of that type (I do sometimes put my JS bundles in the class and my CSS bundles in the .config file, though). I'm sure some completely reasonable people would disagree with that process, though.

Answer 2

Can anyone explain the difference in the use of bundling resources using the BundleConfig.cs class file as opposed to the bundle.config xml file?

The difference is that you would have to read, parse and load the content of the bundle.config at runtime. Hence, using BundleConfig.cs class file could be simpler.

1) why you wouldn't just do them both one particular way for simplicity

Totally agree.

2) why anyone would prefer to hard-code resources like that in a class file?

Simply put: easy to understand.

It seems like a much more dynamic approach to just put them in an xml file that can be changed on-the-fly if necessary.

Yes, but you have to write more code to detect when changes happen and then add/remove/replace existing setup. If done poorly, it could lead to UI issues at runtime.

Also, if there is any real documentation on System.Web.Optimization, I would love to know the location (because I sure can't find it).

Already answered above, but I would repeat: http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification

Answer 3

this documentation explains it all better than I ever could

http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification

One of the nicest things is this:

The bundling framework follows several common conventions such as:

Selecting “.min” file for release when “FileX.min.js” and “FileX.js” exist.

Selecting the non “.min” version for debug. Ignoring “-vsdoc” files (such as jquery-1.7.1-vsdoc.js), which are used only by IntelliSense.