This project is read-only.

1.1.0

Rating: No reviews yet
Downloads: 0
Released: Aug 30, 2013
Updated: Aug 30, 2013 by
Dev status: Stable Help Icon

Available Downloads

There are no downloads associated with this release.

Release Notes

Microsoft ASP.NET Web Optimization 1.1.0

Install from NuGet: https://nuget.org/packages/microsoft.aspnet.web.optimization

Features

The following list includes the major features and bug fixes included in this release. It is not meant to be a comprehensive list of every change made. For a detailed list, see the following:

Virtual Path Provider (VPP) Support

ASP.NET’s virtual path provider can be absolutely essential for certain application types. For example, a CMS application may store resources in a database or a path that is different than what would be a direct mapping to the file system. The Web optimization framework now supports virtual path providers and can be configured to use a custom provider with code like the following:

BundleTable.VirtualPathProvider = HostingEnvironment.VirtualPathProvider;

Note that this code example simply restates the default framework behavior as we use the hosting environment’s VPP if you don’t specify your own.

CDN Fallback

In the first version of the framework, an alternate CDN location could be specified for a bundle. Based on a configuration setting, the framework would then either emit a link to the local bundle path or to the CDN path.

However, this feature didn't address the case where the client should fall back to the local bundle path in the event that the CDN was unavailable. In this release, we’ve added this support by way of a new property on the bundle, CdnFallbackExpression. For example, consider the case where jquery is referenced from a CDN location and then can fallback to the local bundle in the case that the CDN resource is unavailable. For this case, BundleConfig.RegisterBundles should contain the following:

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, both optimizations mode (non-debug) and CDN support are enabled. The CDN path is also specified as “foohost” (a known invalid location) for the jquery bundle. The fallback expression “windows.jquery” is then added. As you may 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 check 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 the local jquery bundle.

Element Template Strings

In version 1.0.0, choosing to have full control over your HTML markup meant giving up debug/release support. We’ve eliminated that tradeoff in this 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, the following can be used to render the jquery bundle with HTML5 markup that takes advantage of the new async attribute:

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

This renders the following markup when in debug mode…

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

…And, when in release mode (optimizations enabled)…

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

Per-Item Transformations

One of the biggest requests made of Web optimization 1.0.0 was to enable per-item transformations in addition to enabling transformations on an entire bundle. Additionally, in most cases, the motivation for the request was related to the need to rewrite links to resources from within individual CSS files. As an example, consider the following bundle configuration code:

var cssBundle = new Bundle("~/bundles/css");
cssBundle.Include("~/Content/StyleSheet1.css"); 
bundles.Add(cssBundle);

In this case, the bundle includes a CSS file which is located in the Content folder has the following simple style rule.

body {
    background-image: url('../Images/background.jpg')
}

In this case, because the URL at which the bundle is located (/bundles/css) has the same depth as StyleSheet1.css, the relative reference to background.jpg will work. However, what happens if the relative locations of these 2 resources changes as a result of changing the URL at which the bundle is exposed. Consider the following:

var cssBundle = new Bundle("~/bundles/some/deeper/path/css");
cssBundle.Include("~/Content/StyleSheet1.css"); 
bundles.Add(cssBundle);

In this case, the style rule, when loaded at this depth, will look for the background image at /bundles/some/deeper/images/background.jpg and, of course, will not find it. To prevent this behavior, the URL reference in StyleSheet1.css needs to be rewritten based on the bundle URL.

This version of Web optimization enables transformations to be applied for individual items in a bundle. Additionally, for the URL rewriting scenario, it also includes the CssRewriteUrlTransform item transformation class. Therefore, the code above can be rewritten as the following:

var cssBundle = new Bundle("~/bundles/doesnt/matter/where/css");
cssBundle.Include("~/Content/StyleSheet1.css", new CssRewriteUrlTransform());
bundles.Add(cssBundle);

Now, whenever the style bundle is referenced in a page, regardless of the bundle path, the URL to background.jpg will be rewritten so that it points to the correct location.

Added Directory Filters and Moved *.min.js

One of the early scenarios for the Web optimization framework involved including an entire directory and then applying rules to filter from a bundle different variations of a script file for different optimization modes based on some known file conventions. One example of these known conventions was *.min.js. As such, the expectation was that when running in debug mode, somefile.min.js would be excluded from the bundle and somefile.js would be included. Conversely, when running in release mode, somefile.min.js would be included in the bundle and somefile.js would not.

In practice, however, this scenario was not followed, and the global filtering rules introduced friction. More specifically, in practice, developers included script and style files directly in bundles rather than adding everything in a directory. Additionally, many developers used libraries that only included a *.min.js. Unfortunately, because the filter rules were global, those *.min.js files were excluded when running in debug mode, even if there was not a non-minified version to fall back to - resulting in a broken page.

In order to remove the friction while still providing the initially envisioned functionality, the global filter rules have been moved to a new ignore list called bundles.DirectoryFilter. This means that resources added to a bundle directly will never be excluded from the bundle, regardless of the mode (unless you add your own pattern to the global ignore list which is empty by default). However, the conventions will continue to apply when you included the contents of a directory using IncludeDirectory. By default, the directory filter ignores the following patterns:
  • *.intellisense.js
  • *-vsdoc.js
  • *.debug.js
  • *.min.js
  • *.min.css
  • *.map

Reviews for this release

No reviews yet for this release.