Bundling resources via bundle.config vs BundleConfig.cs in ASP.NET 4.5 WebForms
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 the BundleConfig.cs class file as opposed to the bundle.config xml file?
I've seen some articles showing bundling both js and css in BundleConfig.cs, while others showing bundling js in BundleConfig.cs and css in bundle.config.
I guess I don't understand #1) why you wouldn't just do them both one particular way for simplicity - and #2) why anyone would prefer to hard-code resources like that in a class file? 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.
It seems like more articles actually lean toward using BundleConfig.cs than anything else. Is there some particular pro or con that encourages this?
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).
Thanks-
Answer
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.