This project is read-only.

Bundling was added to ASP.NET MVC after the original release of JavascriptHelper. Sparing you the ugly details of how I got this to work, using it is simple. Turn it on. It just works. Essentially, you use it exactly like the non-bundling version just described. All bundling & compression is now just handled automatically behind your back. It’s turned on and off using the “transform” attribute of the <libraries> element in the jslibraries.xml file.

One important detail you need to know…. The browser will consider the bundled CSS file as if it were a real file at the web address of the virtual  file, which, by default is at “~/Content”.  The importance of this, is that all URL references in your CSS files (notably, image files) are all relative to that folder, not the folder where the source file actually lives.   This just a fact of bundling--- JavascriptHelper has no control over this.   The Microsoft Wizard-generated code put the jQuery UI CSS files a virtual file “located” in the same folder as the actual files (which leads to new problems.  See below.)


Ugly details that shouldn't matter to you, but I need to vent:

First of all, as far as I can tell, MVC bundling in the beta (not this code; the bundling code provided by Microsoft in the beta), is just broken. The first indication of this is that the "RegisterTemplateBundles()” method loads a very specific set of JS files, with their filenames hard-coded right in the IL code. I’m certain that’s going to be changed before the RTM version.

It also appears that any two bundles given the same virtual file name (regardless of the page it’s on, the content of the bundle or the query string parameter) will get the content of the first bundle created with that name back. If you say “Well, that’s to be expected”, remember that the default bundling code created by the Wizard uses the same virtual file name for every page. That Wizard-generated code also puts every JS file in your ~/Scripts folder into the bundle, so every page uses the same bundle anyway. The problem only shows up when you try to control the bundle contents more closely. When I deviated from the default, I started seeing that the second page I viewed only got the JS files that the first page had requested.

I discovered this when testing a scenario which Microsoft didn’t seem to plan for – a selection of JS files used on a page includes both local files to be bundled, and external files which are not, and with the external files in the middle of the list, requiring two separate bundles on one page.

Say for instance, you are loading jQuery off of a CDN (like the one Microsoft runs), or you are using a WebService where the service wants you to load the API JS file directly from their site (like Microsoft’s Bing Maps), then you’ll have JS files, which would be handled by the JavascriptHelper, which should not be part of the bundle, but may, through the dependency tree, show up between local files. In that case, you’ll need one bundle to be loaded before the external files, and a second to be loaded after them. JavascriptHelper gets this to work, automatically.

So, as you might have guessed, Microsoft rewrote a lot of this for MVC4 RC, and with any rewrites, some code written for the predecessor broke.

So, along with mitigating the first problem listed (they moved the standard included files out of the assembly and put them in Wizard-generated source code, namely, the BundleConfig.cs file placed in the App_Start folder), they also started using different names for different bundles. However, now they seem to have gone the other way entirely, created, by default, several named "bundles" each containing only one file. JavascriptHelper creates as few bundles as needed.

Last edited Jun 22, 2012 at 1:55 AM by JamesCurran, version 2


No comments yet.