3

I have created a new ASP.NET 4.5.1 web forms project.

I have used bundling & minification in MVC 4 previously.

Why is there a bundle.config file in the root - and a BundleConfig.cs file in App_Start - that both appear to list files to be bundled?

What is each for and why do they appear to do the same thing?

This question was asked here but not really answered (even though it is marked as such): Bundling resources via bundle.config vs BundleConfig.cs in ASP.NET 4.5 WebForms

Community
  • 1
  • 1
niico
  • 11,206
  • 23
  • 78
  • 161
  • In my webforms Web Application (not Web Site) project type, I use <%: System.Web.Optimization.Styles.Render("~/bundles/Content/css") %> for stuff declared in BundleConfig.cs, but for stuff declared in Bundle.config, I use Microsoft.AspNet.Web.Optimization.WebForms tagPrefix="webopt" like this: . The former seems like the MVC way and the latter the webforms way. I have not thoroughly tested all the possibilities with respect to minification. It is not DRY to use two different optimization assemblies. – subsci Mar 24 '14 at 21:42
  • Thanks. I agree it's not DRY - I'd like to understand which is best and only use one. – niico Mar 25 '14 at 00:35
  • BundleReference actually calls `Styles.Render` when rendering normally. However, it also has support for the Design Mode, so that the styles will be applied correctly there, whereas they wouldn't be with `Styles.Render`. Since there isn't a Design Mode for MVC projects, it's not applicable there. If you don't care about Design Mode in WebForms projects, then you could switch to `Styles.Render` if you prefer. – Elezar Jun 14 '14 at 00:18
  • possible duplicate of [Bundling resources via bundle.config vs BundleConfig.cs in ASP.NET 4.5 WebForms](http://stackoverflow.com/questions/13726956/bundling-resources-via-bundle-config-vs-bundleconfig-cs-in-asp-net-4-5-webforms) – Spontifixus Oct 08 '14 at 11:37

1 Answers1

5

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'm sure some completely reasonable people would disagree with that.

As far as the default VS template for Web Forms projects having both, I'm guessing it's just to demonstrate that both options are available, since it's not doing anything in BundleConfig.cs that couldn't also be done in Bundle.config.

Elezar
  • 1,467
  • 1
  • 15
  • 22