New Web Optimization Pre-Release Package on NuGet | Howard Dierking

:

Today we pushed a new [pre]release of ASP.NET Web optimization to nuget.org – version 1.1.0-alpha1. This release includes some bug fixes and also a few new features that we wanted to share sooner than later. You may have also noticed that WebGrease 1.3.0 was published to NuGet just a few days ago – 1.3.0 addresses several bugs found in the JavaScript and CSS minification process, so regardless of whether you choose to update Web optimization, make sure to update your WebGrease package.

Here are the new features included in 1.1.0-alpha1 –

CDN fallback

In the first version of the library, we enabled you to specify an alternate CDN location for a bundle and then tell the framework whether or not that CDN path should be used instead of the local path when BundleTable.EnableOptimizations=true (or the ASP.NET debug configuration attribute is set to false when not explicitly setting the EnableOptimizations property).

However, this feature didn’t address the case where you wanted to start with a CDN path and then fall back to the origin server in the case that the CDN was unavailable. In this latest release, we’ve added this support by way of a new property on the bundle, CdnFallbackExpression.  For example, consider the case where we want to reference jquery from a CDN location and then fallback to the local bundle in the case that jquery cannot be reached on the CDN. For this, we need the following entries in the BundleConfig class’ RegisterBundles method..

bundles.UseCdn = true;

BundleTable.EnableOptimizations = true;

var jqb = new ScriptBundle(“~/bundles/jquery”, “foohost”)

.Include(“~/Scripts/jquery-{version}.js”);

jqb.CdnFallbackExpression = “window.jquery”;

bundles.Add(jqb);

In this code, we’ve enabled both optimizations mode and CDN support; we’ve also specified the CDN path as “foohost” (a known invalid location) for the jquery bundle. We then simply need to add the fallback expression “windows.jquery”. As you already know, this represents the jquery object and it will be used in the following script generated by the framework.

<script>

(window.jquery)||document.write(‘<script src=”/bundles/jquery”><\/script>’);

</script>

This script will query to see if the jquery object exists (indicating that jquery was successfully fetched from the CDN), and if not, will write a new script tag into the DOM with the src pointed at jquery on my server.

Element template strings

It used to be that choosing to have full control over your HTML markup meant giving up debug/release support. We’ve eliminated that tradeoff in this latest release with the “RenderFormat” method.  This helper method accepts, in addition to the usual list of bundle references, a format string which represents the HTML to render. For example, to render the jquery bundle with HTML5 markup that takes advantage of the new async attribute, I can use the following:

@Scripts.RenderFormat(“<script src='{0}’ async></script>”,”~/bundles/jquery”)

I’m now able to see that the async attribute is present when optimizations are turned off…

<script src=’/Scripts/jquery-1.7.1.js’ async></script>

…And, of course, when they are turned on…

<script src=’http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.1.min.js’ async></script>

Virtual Path Provider

Finally, while it may not one of those scenarios that is broadly used, supporting ASP.NET’s virtual path provider is absolutely necessary for certain application types – a good example is CMS applications that may store resources in a database or a path that is different than what would be a direct mapping to the file system.  The new Web optimization framework release now supports VPP, and while I’m not going to show how to develop a custom VPP (that topic would probably take a post or 4 by itself), here’s how you configure the Web optimization framework to use it.

BundleTable.VirtualPathProvider = HostingEnvironment.VirtualPathProvider;

Note that this code example is a no-op, since we default to use the hosting environment’s VPP if you don’t specify your own.

What’s Next?

As we continue towards the stable 1.1.0 release, the one additional feature that we’re working on, which has been pretty highly requested, is support for build-time optimization. There is some support for this today via the executable that is included in the WebGrease package – however, it’s not a first class feature, and that’s what we want to enable. More to come as that feature gets a little more baked…

So take a look at the new alpha release and let us know what you think at http://aspnetoptimization.codeplex.com/