Effective web development with Visual Studio 2012: innovations in packaging and minification of scripts and styles

With the release of Visual Studio 2012, the tool responsible for the automatic minification and packaging of scripts and styles Web Optimization Framework has received a big update. These changes serve two purposes:

1. Provide full control over packaged packages that are registered by default web application templates.
2. Support debugging and publishing modes so that during debugging packages are not packaged and automatic when the application is hosted on the server.

Major changes

In order to provide a solution to the problems posed, the framework has made some changes in the moments related to how packages are defined and registered and how reference is made to packaged packages in a view.

Registration Changes

The EnableDefaultBundles mechanism used earlier becomes obsolete and will be removed in the final version of Visual Studio 2012.

When you create a new project, you can find in it a new file, App_Start \ BundleConfig.cs, which contains the only RegisterBundles method that is called in global.asax when the application is started.
')
This new method is designed to perform all the tasks for creating and registering all the packaging packages for your project. In previous versions of the framework, the default registration process for assemblies was performed by calling the built-in assembly methods: RegisterTemplateBundles or EnableDefaultBundles. Now this call is available as a code in your project, which allows you to flexibly manage the registration and package creation.

In addition, in the new version of Visual Studio 2012 RC, the default packaging packages were divided for different types of scripts: jQuery, jQuery UI, validations, and so on. This allows you to manage sets of scripts to be included in the pages.

In addition, the packaging package registration process has been simplified. For example, if you previously had to write the following code:

bundle = new Bundle("~/Content/themes/base/css", csstransformer); bundle.AddFile("~/Content/themes/base/jquery.ui.core.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.resizable.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.selectable.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.accordion.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.autocomplete.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.button.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.dialog.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.slider.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.tabs.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.datepicker.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.progressbar.css", true); bundle.AddFile("~/Content/themes/base/jquery.ui.theme.css", true); bundles.Add(bundle); 

Then in the new version you can define it as follows:

 bundles.Add(new StyleBundle("~/Content/themes/base/css").Include( "~/Content/themes/base/jquery.ui.core.css", "~/Content/themes/base/jquery.ui.resizable.css", "~/Content/themes/base/jquery.ui.selectable.css", "~/Content/themes/base/jquery.ui.accordion.css", "~/Content/themes/base/jquery.ui.autocomplete.css", "~/Content/themes/base/jquery.ui.button.css", "~/Content/themes/base/jquery.ui.dialog.css", "~/Content/themes/base/jquery.ui.slider.css", "~/Content/themes/base/jquery.ui.tabs.css", "~/Content/themes/base/jquery.ui.datepicker.css", "~/Content/themes/base/jquery.ui.progressbar.css", "~/Content/themes/base/jquery.ui.theme.css")); 

As you can see, there are several improvements here:

• Creating a strictly typed packaging class for styles and scripts will automatically apply the appropriate default minifiers
• Added support for script definition chains that simplifies writing code and avoids specifying three configuration parameters
• Added the ability to transfer data about scripts through parameters, thus avoiding a multiple call to AddXXX.

Changes in the use of packaging packages in views

In addition to simplifying the process of creating and registering packaging packages, the process of using packages in views has also been improved. These changes should greatly simplify the task of reconfiguring how minification and packaging should work depending on current development tasks (debugging or release).

In previous versions, the link to the package in the presentation was created using the helper method in the script tag, for example:

<link href = '@ BundleTable.Bundles.ResolveBundleUrl (“~ / Content / themes / base / css”)' rel = ”stylesheet” type = ”text / css” />

<script src = '@ BundleTable.Bundles.ResolveBundleUrl (“~ / Scripts / js”)'> </ script>

Although this approach generally works well for URL dereference purposes and even for obtaining a unique versioned URL, it shows its disadvantages when working in debug mode. When debugging, we would like to see each script or style in a separate line on the page.

In the new version, this problem is solved by registering the packaging packages on the page with the following code:

@ Styles.Render (“~ / Content / themes / base / css”)

@ Scripts.Render (“~ / Scripts / js”)

Additionally, these helper methods can take parameters with an array of rendering URLs on the pages, so you can specify the output of several packages at once:

@ Styles.Render (“~ / Content / themes / base / css”, “~ / Content / css”)

Thanks to this approach, in debug mode, scripts and styles that are defined using packaging packages will be rendered on the page as separate files. When you put the site into the production server on the production server these scripts and styles will be rendered in the form of packaged minified packages.

By default, switching modes depends on the IsDebuggingEnabled property of the current HttpContext context, which means that you can control the behavior of the packaging mechanism through the web.config setting:

<compilation debug = ”false” />

You can override this behavior by implementing your own version of the static EnableOptimizations property of the BundleTable class.

Although these properties allow you to control switching between debugging and release modes, there may be plenty of examples of when you need more flexible control and generation of markup, depending on many other factors. The new version of the framework continues to support this scenario, thanks to helper methods:

<script type = ”text / javascript” src = '@ Scripts.Url (“~ / bundles / modernizr”)'> </ script>

This approach allows you to fully control the markup of style definitions and scripts.

Connecting third-party minification libraries

The Web Optimization Framework, in addition to standard JsMinify and CssMinify, supports third-party libraries for minifying and packaging scripts and styles. The new version adds the ability to transform script files and styles in multiple ways. For example, you can transform an LESS style into CSS, and then package it:

 var lessBundle = new Bundle("~/My/Less").IncludeDirectory("~/My", "*.less"); lessBundle.Transforms.Add(new LessTransform()); lessBundle.Transforms.Add(new CssMinify()); bundles.Add(lessBundle); 

The order of such a transformation is determined by the order of adding libraries to the collection.