Followers of the IHttpHandler

We Are Hiring

Note: this entry has moved.

About ten months ago Daniel Cazzulino and I decided to start ClariuS Consulting SA, with the aim of building a unique company that would be the greatest place to work and build a long-term career. So far, our expectations had been *greatly* surpassed (and I really mean greatly here). We've been incorporating more people to the team, but we're in need for more!

At ClariuS we do all kind of interesting and exciting work. We help customers get up to speed with .Net by providing superb training, mentoring and consulting. We also write a lot of code. We present @ several conferences (locally and worldwide) and we write articles and books. So there are really lots of things to do depending on your profile and your preferences.

If you happen to live anywhere near Argentina and you’re a smart guy that can get things done, then we definitively want to hear about you. Either ping Daniel (kzu AT clariusconsulting DOT net) or me or the more formally jobs AT clariusconsulting DOT net.

Also, if you’re not living in Argentina or anywhere near but you’re available for contract work we are also interested in hearing from you.

Whidbey Cross Page Posting: Avoiding the Ugly Response.Write

Note: this entry has moved.

Quick Catchup: you may have heard about the new upcoming Cross Page Posting feature in ASP.NET Whidbey, in a nutshell: you will be able to post from page A to page B and while executing in Page B do some cool things like accessing the control tree for page A.

I was having dinner the other night with my gf and we where talking about *I don’t remember exactly what* when one sleeping thread in my head popped up and suddenly told me: “What about if the posting page uses Response.Write, that will be cause a mess!”.

Not having paid much attention to this feature before (read: not having run Reflector through it) I was pretty sure that if both pages were sharing the same HttpContext (which sounded logical to me) and the posting page called Response.Write to write its UI for example, then, when posted to another page, the target page UI will get all messed up with the posting page UI. Best of all this didn’t look like a bug at all, this was only good news, another excellent reason for people to finally start cleaning up calls to Response.Write in their code.

So, I quickly wrote the 3 lines of code required to test this scenario and hit Ctrl-F5.

I first browsed to –lets call it– Page “A” which included some garbage written out by calls to Response.Write. Then I clicked a button on Page “A” to cross post to Page “B” and expected Page “B” output to include the previous garbage… so far… no luck… Page “B” output was not including this… disappointing… :-(

At this point I started thinking that someone (read: the ASP.NET team) may have considered this before (just a year or two maybe? :-)) and included some workaround to make the life of developers using Response.Write much easier.

It was time for “the tool” to enter scene. It didn’t took me more than a minute or two to find out what was really happening, and yes, someone had thought about this before…

What is happening here is that before executing the posted page (Page “A”) from the target page (Page “B”), ASP.NET is cleverly switching the writer used by the HttpResponse instance with a dummy one, using a new internal (yes internal, sorry) method whose signature is:

               internal TextWriter SwitchWriter(TextWriter writer);

After the posted page (Page “A”) has finished executing (and their controls are ready to be accessed by the target Page “B”) ASP.NET will switch again HttpResponse’s writer to the *real* writer this time thus allowing Page “B” to properly output whatever it needs to.

This is just an example of Whidbey helping the reputation of some ASP.NET developers :-)

Nonsense Viewstate Usage (and a Lot of Microsoft Sincerity)

Note: this entry has moved.

A few days ago I stumped at the following sample (Whidbey docs required):

ms-help://MS.VSCC.v80/MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VisualStudio.v80.en/cpref/html/T_System_Web_Handlers_AssemblyResourceLoader.htm

In the code for that sample a custom control is built; you will find that a constructor taking two arguments is provided but not used; why is it provided at all is beyond me.

        public TextWithImage(string text, string imageName) {

            ViewState["Text"] = text;

            ViewState["ImageName"] = imageName;

        }

But what is really bad about the previous constructor? It’s the lack of sense of storing values into viewstate in a constructor when viewstate tracking has not been started yet; anything you put in there will not be persisted into viewstate.

As these samples are and will be followed by thousands and thousands of people I believed it was really necessary to not show such a thing. People actually learn from samples and this one will not help any in that matter.

So I filed this bug using LadyBug and telling:

Description:  Opened by vga on 2004-10-31 at 00:27:49 

In the sample used here:

ms-help://MS.VSCC.v80/MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VisualStudio.v80.en/cpref/html/T_System_Web_Handlers_AssemblyResourceLoader.htm#codeExampleToggle

A ctor taking two arguments is provided although not used by the sample. This ctor actually stores into viewstate the two arguments passed.

Storing values into viewstate in a ctor is nonsense as viewstate tracking hasn't started yet thus these values won't be persisted.

Please consider deleting the mentioned ctor from the sample as:

1) its not used at all

2) its showing a nonsense usage of viewstate

And less than two days later I got the following (the highlighting is mine):

Resolution: Fixed

Closed by Microsoft on 2004-11-02 at 11:15:43 

Thanks for your comments,

you are right that manipulating view state in the constructor in that way is silly. I've changed the sample to have a default constructor; the control is still usable in this way and still demonstrates the important thing, which is how to use the AssemblyResourceLoader to get at some type of resource compiled with the assembly.

Regards, Alex 

Don’t you just love that much sincerity? :-) I know I do!

BTW, Alex if you happen to read this, please while you’re at it modifying the sample make sure to also change the referenced filename map6.gif to something like… map.gif? Or if you really want to get funny with filenames then you could try map872-b-northEast.gif… :-)