Automatically compress embedded JavaScript resources with Microsoft Ajax Minifier

Recently Microsoft has announced yet another useful addition to an ASP.NET developer tool belt: Microsoft Ajax Minifier, a tool that enables you to reduce the size of a JavaScript file by removing unnecessary content from it. Clearly this is an extremely useful tool and the ASP.NET development community has gladly embraced it (just google it up to see a lot of positive responses). The tool indeed works very well and there have even been a number of articles comparing it to other well-known JavaScript compression tools that proved its quality. So there are no doubts whether to use the Minifier or not.

The question however is how to use it. Microsoft Ajax Minifier package does include a set of documentation that explains how to use the tool and even discusses a couple of usage scenarios. Unfortunately the way I wanted to use the Minifier is not covered in the documentation and for some reason I haven't found useful information on the Internet too so I've decided to do some research and share my findings with the community.

So how would I like to use the Minifier? Here are the requirements:

1. I want to automatically compress embedded JavaScript resources in any project of my web application solution.
2. I want the compressed JavaScripts have the original names so I don't have to change the references in HTML mark-up.
3. I want the compression to be done only when I switch to the Release mode in Visual Studio. When I am in the Debug mode I want all the JavaScript files to be uncompressed for easier debugging.
4. I want compressed JavaScript files never overrides the original JavaScript files and I don't want to keep the compressed JavaScripts so whenever I modify my JavaScript code the compressed resources are always up-to-date.

I believe that the requirements above describe one of the most common web application solution configuration so if there is a way to achieve them it would be very useful.

Can I achieve the requirements above with the Microsoft Ajax Minifier? The answer is yes. The solution is kind of obvious: since the Microsoft Ajax Minifier includes an MSBuild task I just need to modify a project file where I have embedded JavaScript resources that I need to be compressed to include the Microsoft Ajax Minifier build task. It does not sound complicated and below is the solution which is simple indeed. Just include the following XML in your project file right before the closing </Project> tag (in most cases):

<!-- Minify all JavaScript files that were embedded as resources -->
<Import Project="$(MSBuildExtensionsPath)\Microsoft\MicrosoftAjax\ajaxmin.tasks" />
<PropertyGroup>
<ResGenDependsOn>
MinifyJavaScript;
$(ResGenDependsOn)
</ResGenDependsOn>
</PropertyGroup>
<Target Name="MinifyJavaScript" Condition=" '$(ConfigurationName)'=='Release' ">
<Copy SourceFiles="@(EmbeddedResource)" DestinationFolder="$(IntermediateOutputPath)" Condition="'%(Extension)'=='.js'">
<Output TaskParameter="DestinationFiles" ItemName="EmbeddedJavaScriptResource" />
</Copy>
<AjaxMin SourceFiles="@(EmbeddedJavaScriptResource)" SourceExtensionPattern="\.js$" TargetExtension=".js" />
<ItemGroup>
<EmbeddedResource Remove="@(EmbeddedResource)" Condition="'%(Extension)'=='.js'" />
<EmbeddedResource Include="@(EmbeddedJavaScriptResource)" />
<FileWrites Include="@(EmbeddedJavaScriptResource)" />
</ItemGroup>
</Target>

What this script does is when the solution configuration is 'Release' it finds all the project embedded resource files with the extension '.js' and creates their compressed versions with the same names in the intermediate output folder where they are picked from later by the build process.

A few tips

As you may have noticed the Microsoft Ajax Minifier MSBuild task is referenced from the default folder where it was copied to by the installer. If you want to reference it from a different location, for example if you have a shared development environment and want to have similar setting for everyone, just copy two files ajaxmin.dll and ajaxmintask.dll to another location and include the <UsingTask> tag (below) instead of the <Import> tag in the script above:

<UsingTask TaskName="AjaxMin" AssemblyFile="$(MSBuildProjectDirectory)\..\Build\AjaxMinTask.dll" />

The presented script performs so called 'Normal Crunching' (see the Ajax Minifier documentation) of the JavaScript code which already does a pretty good job that is good enough in most of the cases: compression rate is over 50%. If you would like to turn on the 'Hypercrunching' mode (see the Ajax Minifier documentation) you only need to modify one line of the script to include the 'LocalRenaming' option of the Ajax Minifier:

<AjaxMin SourceFiles="@(EmbeddedJavaScriptResource)" SourceExtensionPattern="\.js$" TargetExtension=".js" LocalRenaming="CrunchAll" />

And the last note is: don't use the default Hypercrunching mode or RemoveUnneededCode option with the ASP.NET AJAX Framework as it does not work properly with it.

Using the Microsoft Ajax Library 3.5 with the CDN

Recently Microsoft has announced its Microsoft Ajax content delivery network (CDN) which can significantly improve the performance of any ASP.NET AJAX web application. When it was first announced the CDN was almost useless for the current web applications based on ASP.NET 3.5 since it did not host the Microsoft Ajax library 3.5 and did not support content delivery via SSL. However in a very short period of time Microsoft was able to fix those problems (good job!) and now web applications built on ASP.NET 3.5 can benefit from using Microsoft Ajax CDN.

So how do you make MicrosoftAjax.js file being referenced from the CDN as opposed to the embedded file? Quite easy actually with the help of the ScriptManager control. Add the following declaration to a page (or Master page) where there is a ScriptManager control:

<asp:scriptmanager runat="server" enablepartialrendering="false">
  <scripts>
    <asp:scriptreference name="MicrosoftAjax.js" path="http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js" />
  </scripts>
</asp:ScriptManager>

What that declaration means is that the script with a name MicrosoftAjax.js which is always automatically referenced by a ScriptManager from the System.Web.Extensions dll now should be referenced from that location: http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js.

This is how it is referenced by default:

<script src="/ScriptResource.axd?d=eYUqBJhfSVL41hIDYkBL0tfaps9hoQId_48PydfbcyWH41vNvL68sk-l7P9FLAPz7b4vtI8WkZ-ezAF0b_ZkyG52wt9oUtaQ5ezFfGBr7LY1&t=ffffffffef976216" type="text/javascript"></script>

and after we include the new ScriptReference declaration:

<script src="http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js" type="text/javascript"></script>

ScriptManager is even smart enough to automatically reference the debug version MicrosoftAjax.debug.js from the CDN when debugging is enabled in the web.config file:

Web.config:
<compilation debug="true">

HTML:
<script src="http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.debug.js" type="text/javascript"></script>

So this is clear: we have our MicrosoftAjax.js referenced from the CDN and that improves our web application performance and saves us and the visitors some bandwidth since an internet browser will reuse the same cached copy of the MicrosoftAjax.js from the CDN for different web applications that reference it.

Using the CDN conditionally

What if we only wanted to reference MicrosoftAjax.js from the CDN when the web application is deployed to a production environment and use an embedded version in a development environment? That would make sense in order for the developers to work without having to be connected to the Internet. Once again it can be done but this time we'll need to write some code. We are going to add the MicrosoftAjax.js script reference dynamically depending on the debug value in the web.config file; we only add the script reference when debug="false":

protected void Page_Load(object sender, EventArgs e)
{
  if (!Context.IsDebuggingEnabled)
  {
    ScriptManager sm = ScriptManager.GetCurrent(this);
    sm.Scripts.Add(new ScriptReference 
      {Name = "MicrosoftAjax.js", Path = "http://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js"});
  }
}

Using the CDN via SSL

Another major case is when our web application has pages that are served via SSL. In this case we want to automatically select the correct CDN URL for the MicrosoftAjax.js. In order to do that we just modify the previous code:

protected void Page_Load(object sender, EventArgs e)
{
  if (!Context.IsDebuggingEnabled)
  {
    ScriptManager sm = ScriptManager.GetCurrent(this);
    sm.Scripts.Add(new ScriptReference 
       {Name = "MicrosoftAjax.js", Path = Request.Url.Scheme + "://ajax.microsoft.com/ajax/3.5/MicrosoftAjax.js"});
  }
}

So that's it for now. Enjoy using the Microsoft Ajax CDN.

Talk about P&P Web Client Software Factory on Toronto Architecture User Group meeting

Developing modular web applications is a popular topic in development communities especially after ASP.NET MVC framework has been introduced by Microsoft. However ASP.NET MVC is not the first and only framework that can help on that way.

I'll be talking about building modular enterprise-class modern web applications with the help of MVP design pattern and Microsoft Patterns and Practices Web Client Software Factory framework on the next meeting of Toronto Architecture User Group on Thursday October 29th. To attend please register online here.

Problem with Internet Explorer 8 Debugger on Windows 7

I continue to evaluate Windows 7 after upgrading from Windows Vista and share some experience (mostly bad of course, so people would not step on the same problem again). As I mentioned before, overall upgrade was smooth and mostly everything works OK. However time to time I stumble upon some really annoying problems that did not exist on Windows Vista and therefore need to be solved for Windows 7 from scratch.

One of the recent problems was Daemon Tools not working on Windows 7 and it was solved by installing Magic Disc. Now there is one more thing: after upgrading to Windows 7 I am not able to use IE8 Debugger. When I pressed F12 the Debugger icon appeared on the task bar but I can not switch to its window: it's not visible.

So obviously I searched over the Internet and luckily there was one post on Stack Overflow (apart from those guessing about a window being outside of the screen) that suggested that there may be some wrong setting in Windows registry. And there are some registry keys related to IE8 debugger! So the solution was to remove WindowsPos, Pinned and UseDevToolsDebugger keys from the [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IEDevTools] section. That completely solved the problem.

Unfortunately I can not tell whether those keys existed in Windows Vista and were incompatible with Windows 7 or their values have been incorrectly modified during the upgrade. But after removing them and starting IE8 debugger they haven't appeared again. So probably they are not needed anymore.

How to map .ISO file to a drive in Windows 7

So, recently I have upgraded my laptop from Windows Vista to Windows 7. The upgrade process was straight forward and flawless and everything so far was OK except one thing: the Daemon Tools that I've been using for mapping .ISO image files since 2004 on various Windows systems refuses to work on Windows 7. Even Windows 7 compatibility mode does not help: Daemon Tools manages to recognize Windows 7 anyways. Luckily there is another tool that provides with absolutely the same functionality and also free: Magic Disc. It works under Windows 7 flawlessly and really makes my life easier: no need to burn ISO files on CD/DVD anymore.

ASP.NET user name availability check using WCSF Validation Bundle

An average web site offering membership and protected content for its members requires users to sign up by visiting a sign-up or register page that allows a user to enter some information and create an account. A couple of pieces if information that users are commonly asked to enter are a User name or Login name and user's email. One potential problem with such user input is checking that entered login name and/or email address are available for registration and haven't been used by other users. When it's the case multiple attempts of entering available values can be very annoying and frustrating for users even making them to refuse registration on a web site. So improving user experience when validating login name and email is quite an important task.

How to set programmatically a value of a watermarked TextBox via JavaScript

There is an updated version of the article for the latest Ajax Control Toolkit release: http://blog.turlov.com/2010/05/how-to-set-programmatically-value-of.html

If you use ASP.NET AJAX and AJAX Control Toolkit you may find it useful to decorate some of your TextBox controls on a page with a TextBoxWatermark AJAX extender control from the AJAX Control Toolkit. It's fairly easy to use and a nice tool for improving both the page look and user experience. However if you need to set a value of a TextBox decorated with the TextBoxWatermark extender programmatically via JavaScript on the client-side you may notice that the behavior of the watermarked TextBox is different. If you use the regular way to set a value like this:

$get(textBoxId).value = someText;

then the value displayed in the TextBox on the page will change to the set value but the watermarked look will still be present and other AJAX Control Toolkit TextBox extenders (like a Calendar extender, for instance) will not recognize the new value. This happens because the TextBoxWatermark extender can not recognize and intercept your JavaScript operation since it's designed to serve user interactions. However there is a correct way of programmatic access to the TextBox's value. We modify the code above like that:

var textBox = $get(textBoxId);
if (textBox.AjaxControlToolkitTextBoxWrapper) {
    textBox.AjaxControlToolkitTextBoxWrapper.set_Value(someText);
}
else {
    textBox.value = someText;
}

The explanation is that most of the TextBox extenders from the AJAX Control Toolkit including a TextBoxWatermark extender use a special proxy class AjaxControlToolkitTextBoxWrapper to manipulate with the input elements. The proxy adds a special property AjaxControlToolkitTextBoxWrapper to the input element that contains a reference to itself allowing to access the value of the input element correctly. Similarly, if you need to get a value of a watermarked TextBox you do it like this:

var textBox = $get(textBoxId), text;
if (textBox.AjaxControlToolkitTextBoxWrapper) {
    text = textBox.AjaxControlToolkitTextBoxWrapper.get_Value();
}
else {
    text = textBox.value;
}

New version of ASP.NET AJAX Control Toolkit released

The new release of ASP.NET AJAX Control Toolkit is available for download. Bertrand Le Roy has written a very informative post about it.

What I particularly like in this new release is that the Color Picker extender is now included in the Ajax Control Toolkit. Hooray!

Along with the new Toolkit release there come a whole bunch of new tutorials and videos. Among them there are this particularly nice tutorial about the Color Picker extender and another excellent video tutorial by Joe Stagner. Thank you folks for such a great job!

What that means for the Color Picker Extender users is that they don't have to download it separately from Codeplex anymore because it is included in the Ajax Control Toolkit. For those who cannot yet switch to the new version of ACT the original Color Picker Extender control will continue to be available on Codeplex. During the next few days I will prepare and upload a new release synced up with the Ajax Control Toolkit.

It is very educating to read people's opinions about the new release of ACT in response to blog posts and on Codeplex. In general, the responses are positive, but occasionally there are some complaints, mostly about little things.

I would like to remind everybody that Ajax Control Toolkit is a completely community-based initiative (with, of course, the initial kick-off help from Microsoft) and people who work on it take time out of their personal calendars so let's be more tolerant and if you've come across something really bad please use the Issue Tracker.

As I mentioned before, I specifically was interested in reading responses about the ColorPicker.  Interestingly, all the complaints were about its look and feel, not about functionality. I admit that the UI it provides is rather simplistic but here is my question back: why don't you all take some time and come up with feedbacks and suggestions on what can be improved?

Since the ColorPicker was publicly available on CodePlex it's been downloaded more then 2000 times (and I don't count downloads of ACT source code) and only a few people suggested something about improving it. I take it as everybody has been satisfied.

Now that the CPE is a part of the ACT and has a bit more visibility I suggest that people who have suggestions or concerns please don't hesitate to speak up.

Survey: Ajax usage among .NET developers

If you haven’t already and you are a .NET developer, please take a couple minutes and answer this survey, whether you use Ajax or not. There are a number of Ajax surveys around, but this is the only one that focuses on .NET developers.

The survey:
http://www.zoomerang.com/Survey/?p=WEB22973CYKW2H