Nothing fancy

Where is my Microsoft Ajax 3.5 library standalone download?

AGS777 — Sat, 26 Sep 2009 10:31:00 GMT

Today I visited http://www.asp.net/ajax/downloads/ page to download standalone version of Microsoft Ajax 3.5 client library and used "Download the AJAX Library" button as I surely did many times previously. The landing page contained only the following: "This page has been removed. Please visit the ASP.NET Developer Center home page for further information." But I could not find any relevant "further information" on the ASP.NET Developer Center home page. Only a link to the same http://www.asp.net/ajax/downloads/ page I came from. Could someone explain me what happened to this download?

Firebug Lite 1.2 impressions

AGS777 — Fri, 25 Jul 2008 16:40:00 GMT

Not to be verbose - I am really disappointed. Why? Because I was unable to use this hopefully excellent tool with my current development project.

The reason is that pi.js library used in the current release of Firebug Lite extends native JavaScript objects like String, Number, Array and so on. And some of the methods introduced in the library collide with overridings used in my project.

Yes, I know that it is not good idea to extend native JavaScript objects.

But main idea of the post is that while I think that any given application written for specific customer and specific environment CAN AFFORD to use such technique, but debugging tool that is supposed to be absolutely sandboxed and unobtrusive for its hosting environment can't be granted such privileges.

So I am totally disappointed by such design and hope it will be fixed in the subsequent release.

Firefox 3. XSLT Processing Engine bug?

AGS777 — Fri, 20 Jun 2008 21:21:00 GMT

I stumbled upon really strange issue while researching unexpected behavior of existing web application under Firefox 3.

So, there are ultimately simplified steps to reproduce:

1. XML document:

<?xml version="1.0"?>
<items>
    <item>
        <id>1</id>
    </item>
    <item>
        <id>2</id>
    </item>
    <item>
        <id>3</id>
    </item>
</items>

2. XSL stylesheet:

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="html" />
    <xsl:template match="item">
        <tr id="{id}">
            <td>
                <xsl:value-of select="id" />
            </td>
        </tr>
    </xsl:template>
</xsl:stylesheet>

3. Load these XML and XSL documents to Document instances.

4. Transform this XML document using given XSL stylesheet with the following code:

            var processor = new XSLTProcessor();
            processor.importStylesheet(xsl);
            var doc = processor.transformToDocument(xml);

In Firefox 2 we would get following document as a result of this utterly ordinary code:

<transformiix:result xmlns:transformiix="http://www.mozilla.org/TransforMiix">
   <TR id="1">
       <TD>1</TD>
   </TR>
   <TR id="2">
       <TD>2</TD>
   </TR>
   <TR id="3">
       <TD>3</TD>
   </TR>
</transformiix:result>

Since we used transformToDocument and there is no root node in the resulting XML fragment then we have wrapping <transformiix:result /> document element node.

But, as I said, in Firefox 3 result differs. I got following document:

<transformiix:result xmlns:transformiix="http://www.mozilla.org/TransforMiix">
   <transformiix:result>
        <TR id="1">
            <TD>1</TD>
        </TR>
        <TR id="2">
            <TD>2</TD>
        </TR>
   </transformiix:result>
   <TR id="3">
        <TD>3</TD>
   </TR>
</transformiix:result>

Do you see the difference? There is unexpected (at least to me) <transformiix:result /> element wrapping first two <tr /> elements in the resulting document.

And it gets event more interesting with an increase of the number of items in the original document. For example with four items we would get:

<transformiix:result xmlns:transformiix="http://www.mozilla.org/TransforMiix">
    <transformiix:result>
        <transformiix:result>
            <TR id="1">
                <TD>1</TD>
            </TR>
            <TR id="2">
                <TD>2</TD>
            </TR>
        </transformiix:result>
        <TR id="3">
            <TD>3</TD>
        </TR>
    </transformiix:result>
    <TR id="4">
        <TD>4</TD>
    </TR>
</transformiix:result>

And so on...

This behavior starts when the number of elements is equal to or grater than 3.

Any thoughts?

.NET Framework 1.1 Service Pack 1 and Page.RegisterStartupScript

AGS777 — Sat, 17 May 2008 12:36:00 GMT

First, if you are are developing exclusively ASP.NET 2.0+ applications, sorry, there is nothing interesting for you in this post.

Second, if you are involved in some ASP.NET 1.1 projects and have no plans to install new development environment, then, sorry again, there is probably no reason for you to read on either. Ok, I've done all I could to warn you against reading it. Don't blame me for wasting you time, because I am going to start from the very beginning.

One of my current projects is ASP.NET 1.1 Web Application. It is already released and rather stable. And yesterday I got new development machine on my workplace and migrated all my data to it. .NET Frameworks 1.1, 2.0, 3.0, 3.5 were preinstalled before I first logged in (thanks to our system administrators). I installed VS 2003 and SP1 for it, VS 2008, SVN client, some other necessary utilities and components. Then, updated sources from source control for the mentioned ASP.NET 1.1 Web Application and started it. Bang! Script error - some variable is undefined.

Actually there were a bunch of such errors on the page. As I intentionally mentioned earlier, the application is stable. And this particular page was not changed for quite some time.

Brief research of the generated HTML source, code-behind class and respective web controls revealed the cause of the exception: there was a sequence of similar Page.RegisterStartupScript statements which went in pairs. The first one in a pair registered some JavaScript object, and the second one - used the object in another declaration.

First I checked source control's log - no related changes. Then, the next suspect - application configuration changes that could cause such behavior. But no, all the related controls' declarations on the page are static.

Ok, code was not changed, application is working fine on QA environment. So, something is wrong with my new machine. But what?

I had a dim recollection that there is something wrong with the sequence of script registration in ASP.NET 1.1. But common sense told me that if something wrong could happen then it would had happened long ago.

Still, I opened Reflector and found such code inside RegisterScriptBlock method of System.Web.UI.Page class:

     if (scriptBlocks == null)
    {
        scriptBlocks = new HybridDictionary();
    }

As you probably well aware of, HybridDictionary changes its internal storage from ListDictionary to Hashtable starting from its ninth element. So, of course we cannot rely on any specific order of script registrations if script blocks are stored in HybridDictionary. But how did it work earlier and how the same code works on development server and QA environment without any bugs reported?

So, I copied Reflector to the development server and found following code in the same RegisterScriptBlock method that I reviewed on my machine:

    if (scriptBlocks == null)
    {
        scriptBlocks = new ListDictionary();
    }

The code was fixed. But where did the fix come from? I recalled that there is a service pack for .NET 1.1 that I installed on my old development machine several years ago. Google promptly gave me a link.

File name: NDP1.1sp1-KB867460-X86.exe, Version: 1, Date Published: 8/30/2004, Download Size: 10.2 MB

Why am I presenting all this information here? Because the fix did not help, though I was almost certain that it should. The same HybridDictionary.

That's was fiasco. My working day was over several hours ago. Finish.

But today I decided to reproduce the issue at home. Fortunately I had a virtual machine with Windows XP and fortunately the copy of .NET 1.1 System.Web.dll had the same version as the one at work (i.e. HybridDictionary is used in RegisterScriptBlock).

So I started googling again and found the second service pack. Strangely enough it has the same name (i.e. .NET Framework 1.1 Service Pack 1) though with a lengthy suffix (.NET Framework 1.1 Service Pack 1 SYSTEM.WEB.DLL and MSCOREE.DLL Security Update for Windows 2000, Windows XP, Windows 2003 Server x64/IA64 and Windows 2003 Server R2 x64/IA64) .

Like the previous service pack that I found, description for this one states that its purpose - security improvements. No mentions of ASP.NET-specific modifications. I could not find any documentation which describes the changes in detail.

But the main thing is that this second "Service Pack 1" done what I wanted. Eventually I had my ListDictionary back.

The summary is:

1) there are at least TWO patches called ".NET 1.1 Service Pack 1";

2) both of them state that they are focused on security improvements, but

3) one of them changes at least one fundamental aspect of ASP.NET 1.1 behavior.

Thank you for reading. Good luck.

Array.prototype.slice vs manual array creation

AGS777 — Sun, 17 Feb 2008 22:22:00 GMT

In a constant pursuit of new and more effective ways to implement common JavaScript code patterns I've recently found out (sorry for such probably trivial finding but it was a real news for me) that Array.prototype.slice method can be easily used to make instance of Array from an arguments object.
I instantly decided to use it in my current projects. Currently the same task is performed by simple iteration through members of the arguments object and filling in respective members of a new Array instance.
I was pretty sure that performance of the new variant will be significantly better. It is a native method call after all instead of interpreted JavaScript code. Nevertheless, I wanted to run simple comparison tests and wrote following code:

The code is self-explanatory. I used four arguments for method calls. 10000 iterations. An alias for Array.prototype.slice method was added to avoid unnecessary lookup.

The results were surprising. You can see them on the screenshot below.

Of the four major browsers that I tested the code against, (FF 3.0b3, IE7, Opera 9.50 Alpha and Safari 3.0.4 (Windows)) only Safari proved my initial expectations.
Why is that? Did I make some error in my test code that I can't notice?

By the way, Opera 9.5 is really fast.