Tales from the Evil Empire

You can do the TODOs today too!

Bertrand Le Roy — Tue, 16 Jun 2009 23:08:00 GMT

If you’re anything like me, you probably litter your code with TODO comments, postponing random tasks for the sake of moving the project forward. And there is of course a non-zero probability that you are going to ship with those comments still in.

So I want to propose the following call to action to all readers of this blog: open your current project and start implementing what’s in those TODOs today.

Finding the TODOs is easy. In Visual Studio, do CTRL+SHIFT+F (search in files), make sure you are searching across the whole solution and search for “TODO”. In the results window, you can click on each result to open the file at the TODO comment location.

While working on a file, you can open the task list window (CTRL+\, CTRL+T), open that drop-down menu and choose “Comments”:

Once you’ve done that, Visual Studio brings you a list of all those TODO comments in the currently open files, which is easier on the eyes than the search results window:

You can now go through those one by one (double-clicking on the TODO in the task list takes you there) and delete the comments once you’ve implemented the feature they describe.

UPDATE: some commenters pointed out that the todo list is limited in scope. I updated the post. Resharper also apparently has a greater feature around that.

Mocking indexer setters with Moq

Bertrand Le Roy — Mon, 15 Jun 2009 22:27:52 GMT

I quite like MoQ because it makes sense for me. Shamefully, I’ve always had some trouble understanding test code that was using mocks built with other frameworks. With MoQ, I can just grok it for some reason. It’s just super-clear to me. It doesn’t mean I have any idea how it really works but for now I’m just happy with the magic.

Anyway, yesterday I wanted to check that a controller action was setting some Application variable (let’s not get into the debate on whether or not it should do that at all). Something like this:

application["foo"] = new Foo();

Now how do I enable the object to be set by the tested code? Well, that one is easy, I can use SetupSet on indexers just fine:

var mockHttpContext = new Mock<HttpContextBase>();
mockHttpContext.SetupSet(
    c => c.Application["foo"] = It.IsAny<object>());

This call tells the mock that it can accept to run code that attempts to set the “Foo” application variable with any object.

But now, what if I want to get a reference to that object from my test code in order to check the value of some of its properties?

Well, MoQ has a Callback method that you can hook to the result of any Setup call. The action that you provide it will be run whenever the setup code is called. The problem with that callback method is that its signature must match that of the setter exactly. Unfortunately, that signature is implicit. If you get it wrong, the test will fail more or less silently (it will just tell you setup failed with little details). To get this right, you need to know what the setter syntactic sugar compiles to, which kinda sucks, but the good news is that you only have to figure it out once, which I just spent some time doing for you (and for myself too, let’s be honest):

var mockHttpContext = new Mock<HttpContextBase>();
Foo map = null;
mockHttpContext
    .SetupSet(c => c.Application["foo"] = It.IsAny<object>())
    .Callback((string name, object m) => { map = (Foo)m; });

Because this is an indexer setter, the compiled code actually takes a name and a value, which is reflected by the signature of the callback lambda. We can now call into the code to test, knowing that when it sets our “Foo” application variable, the local “map” variable of the test code will get set. The test code can then party on the object and assert whatever it wants.

I hope this saves some time whoever is trying to do the same thing.

Why is ASP.NET encoding &’s in script URLs? A tale of looking at entirely the wrong place for a cause to a non-existing bug.

Bertrand Le Roy — Sat, 06 Jun 2009 00:27:15 GMT

Several people have reported seeing errors in their logs that seem to be due to requests such as this:

/ScriptResource.axd?d=
[lots of junk]&
t=ffffffffee24147c

The important part here is the HTML-encoded “&” sequence, which stands for “&” of course. If this exact URL is sent to the server, the server won’t know what to do with the escape sequence (URLs are not supposed to be HTML-encoded on the wire) so the parameters won’t get separated as expected, potentially resulting in a server error. This bug in the toolkit is an example of that: http://ajaxcontroltoolkit.codeplex.com/WorkItem/View.aspx?WorkItemId=13134

Of course, when people see 500 errors popping up in their server logs, they immediately assume the application is failing for some users. Or that some idiot at Microsoft did something incredibly stupid (that’s what we idiots at Microsoft do after all).

Case in point, a quick peek into the source code of the application’s pages immediately reveals that the script tags generated by ScriptManager do indeed generate these URLs:

So that’s where it came from! See? When I copy this URL into the browser’s URL bar, I do get the same error!

Then ensue various more or less rational reactions such as:

Correlate the user agent to the faulty requests (which correlates more or less with normal browser usage, i.e. lots of IE and then lots of Firefox, when there is a large enough sample).
Blame IE6 (lots of these requests come from IE6, hence it must be responsible: IE6 sucks).
“Fix” ScriptManager and remove the HTML encoding.

Well, by copying the URL from the source view into the URL bar, you did indeed reproduce the problem. A little too well. Better than you realize.

This is why. All of the errors in your server logs come from people doing precisely what you just did: copy the URL from the source view into the browser’s URL bar. They do it for various reasons: look at the source code for the scripts, understand what these weird URLs are, who knows?

But the point is, you will never be able to reproduce these errors during normal use of the application. There is nothing to fix here. The value that gets sent to the server never has the “&” sequence. You can verify it in IE6, you can verify it in any browser on any OS, it will just work.

When putting a URL in an HTML attribute, you should *always* HTML-encode it. It’s the standard, and for good reason (it enables the browser to tell between “&”, “&” and “&amp;”, it enables quotes to be embedded into attributes, etc.).

A consequence of that is that if you’re going to copy the value of one of these attributes from the source view, you should do what the browser does when parsing the HTML: decode the value first (in other words, replace “&” with “&”).

So yes, people do fail to do that and copy the URL without decoding. Well, they are not supposed to do that, nor do they need to do it. The error is normal, it results from a bad URL having been entered manually. Nobody would be surprised to get an error when querying foo.aspx?somenumber=thisisnotanumber for example. Same thing here. Pretty much.

Of course, this is not entirely trivial to figure out and I did pull my remaining hair a bit trying to understand what was going on, and you tend to trust people when they tell you there is a problem, especially when the description seems to make sense. There is some sort of confirmation bias going on there. But the more I looked at the different pieces of evidence, the more this explanation looked like the most likely, by far.

But of course, I may be missing something…

Survey: Ajax usage among .NET developers

Bertrand Le Roy — Fri, 22 May 2009 19:13:20 GMT

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 Simone’s is the only one that focuses on .NET developers.

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

Simone’s post:
http://codeclimber.net.nz/archive/2009/05/21/ajax-usage-among-.net-developers-in-2009.aspx

Twitter contest: what can you code in 130 characters?

Bertrand Le Roy — Thu, 21 May 2009 04:59:00 GMT

I just posted the following snippet on Twitter. The exercise is to write meaningful and preferably cool code that fits in a Twitter message along with the #twitcode keyword, which leaves 130 characters.

private static readonly byte[] _blankGif =
  Convert.FromBase64String(
      "R0lGODlhAQABAID/AMDAwAAAACH5BAEAAAAALAAAAAABAAEAAAEBMgA7");

I can’t wait to see what people come up with.

Monitor the results from here:
http://search.twitter.com/search?q=%23twitcode

setInterval is (moderately) evil

Bertrand Le Roy — Fri, 15 May 2009 05:04:36 GMT

JavaScript has two ways of delaying execution of code: setInterval and setTimeout. Both take a function or a string as the first parameter, and a number of milliseconds as the second parameter. The only difference is that the code provided to setInterval will run every n milliseconds whereas the code in setTimeout will run only once.

Before I explain why I think setInterval is evil, allow me to rant on a related subject for a paragraph: you should never pass a string into any of those functions and instead always pass a function reference (unless you really, really know what you’re doing). If you pass a string, it will have to be evaluated on the fly, and eval is quite evil itself (unless you really, really know what you’re doing). It might seem tempting to generate code this way to inject dynamic parameters, but there are better ways of doing that, using currying. In Microsoft Ajax, for example, we provide the handy Function.createCallback and Function.createDelegate for exactly that usage.

Anyways now let’s get back to the issue at hand: setInterval is evil. To better compare, let’s assume you have a reason to use setInterval (why else would you be reading this?). Here’s the code you might write:

<!DOCTYPE html>
<html>
<head>
    <title>setInterval</title>
    <script type="text/javascript">
        var interval = setInterval(appendDateToBody, 5000);
 
        function appendDateToBody() {
            document.body.appendChild(
                document.createTextNode(new Date() + " "));
        }

        function stopInterval() {
            clearInterval(interval);
        }
    </script>
</head>
<body>
    <input type="button" value="Stop" onclick="stopInterval();" />
</body>
</html>

Both APIs have a corresponding clear API that enables the developer to cancel the interval or timeout. To identify what interval or timeout you’re cancelling, you pass into the API a token that is whatever value the call to setInterval or setTimeout returned. And that’s a first reason why setInterval is (mildly) evil: if you lose that token, there is no way you can ever stop that code from running every five seconds until you navigate away from the page. But that is a minor inconvenience, it just means you need to carefully manage your own stuff, right? Well, actually if code that you don’t know or don’t control created that interval, you’re probably in trouble even if you kept your own house real nice and tidy…

But the real reason why I dislike setInterval is that it is quite hard to debug, in particular if you have more than one running simultaneously. For example, if you have two intervals, one running every 100 milliseconds, the other every five seconds, and if you want to debug the second one, the first one will constantly get triggered and will get in the way.

So what, you might say, is the alternative? Well, here is code that is quasi-equivalent to the code above, but that uses the much less evil setTimeout:

var interval = setTimeout(appendDateToBody, 5000);

function appendDateToBody() {
    document.body.appendChild(
        document.createTextNode(new Date() + " "));
    interval = setTimeout(appendDateToBody, 5000);
}

function stopInterval() {
    clearTimeout(interval);
}

Here, instead of taking a subscription for life, we’re just renewing the lease as we go. The big advantage of this code is that to stop the interval, you don’t need the token. Actually, I rarely even bother to keep hold of it. All you have to do is skip the line of code that renews the timeout for the next iteration. So no housekeeping to do, and if during a debugging session you need to get one of the interval functions out of the way, just drag your debugger’s current execution pointer to the end of the function, hit F5 and you’ll never see that function run ever again, boom, it’s out of the way and you can focus on your own debugging.

So to summarize, replacing setInterval with setTimeout is easy, pain-free and removes the inconveniences of setInterval. So while the setInterval evil is about at the level of not replacing the cap of the toothpaste, the non-evil alternative is so easy that I can’t see a reason not to forget about setInterval for good.

New release of the Ajax Control Toolkit

Bertrand Le Roy — Thu, 14 May 2009 05:19:00 GMT

A new version of the AJAX Control Toolkit is now available for download from the CodePlex website. It contains three new controls:

HTMLEditor - allows you to easily create and edit HTML content. You can edit in WYSIWYG mode or in HTML source mode. The control exists as a server-side extender but can also be instantiated purely on the client-side with a single line of code. Many thanks to Obout for building this.

ComboBox - provides a DropDownList of items, combined with TextBox. Different modes determine the interplay between the text entry and the list of items. this control behaves very much like a Windows combo. Many thanks to Dan Ludwig for building this.

ColorPicker - can be attached to any ASP.NET TextBox control to provide client-side color-picking functionality from a popup. Many thanks to Alexander Turlov for building this.

The ASP.NET website has been updated with new videos and tutorials for these controls.

This new release also includes fixes for over 20 of the most voted bugs in existing AJAX Control Toolkit controls and now features minimized release versions of the script files.

The release can be downloaded as a server dll or as a set of files for use with pure client-side applications.

http://ajaxcontroltoolkit.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27326

Creating jQuery plug-ins from MicrosoftAjax components

Bertrand Le Roy — Tue, 05 May 2009 05:23:00 GMT

We had an interesting discussion recently on the ASP Insiders mailing list and ended up talking about what cool stuff we could build on top of jQuery. Many interesting things were mentioned and it was a very useful discussion but one suggestion in particular struck my curiosity as it was something I had investigated before and that could be improved on with very little code.

I had already written a little plugin to enable instantiation of Microsoft Ajax components on the results of a jQuery selector:

jQuery.fn.create = function(type, properties) {
    return this.each(function() {
        Sys.Component.create(type, properties, {}, {}, this);
    });
};

I have another version that is a little more elaborate and takes a bag of properties and events instead of just properties (get it from the attached sample) but you get the idea. This makes it fairly easy to instantiate components based on a selector:

$(":text.nomorethanfive")
    .create(Bleroy.Sample.CharCount, { maxLength: 5 });

But if this were a native jQuery plugin instead of a Microsoft Ajax component, as Rick Strahl suggested, chances are you’d do something like this instead:

$(":text.nomorethanfive").charCount({ maxLength: 5 });

We can actually get that exact result fairly easily by writing a plugin that is specific to this component, but we can’t expect every Microsoft Ajax component author to also write a jQuery plugin, can we? We can do better than that. Here is a second small piece of code that is still generic but is in the business of creating jQuery plugins:

Sys.Component.exposeTojQuery = function(type, pluginName) {
    return jQuery.fn[pluginName] = function(properties) {
        return this.each(function() {
            Sys.Component.create(type, properties, {}, {}, this);
        });
    }
}

Like above, the version in the sample is better than that in that it supports events in addition to properties but again you get the idea. Thanks to this function, we can create a jQuery plugin for any existing Microsoft Ajax component with a single line of code:

Sys.Component.exposeTojQuery(Bleroy.Sample.CharCount, "charCount");

After this call, we can write exactly the code we wrote before, but without having had to write a specific plugin. We can then use charCount like a native jQuery plugin:

$(":text.nomorethanfive").charCount({ maxLength: 5 });

This is really easy to use, and I quite like it. We could for example add the following line of code to the new MicrosoftAjaxTemplates.js:

if (jQuery)
    Sys.Component.exposeTojQuery(Sys.UI.DataView, "dataView");

This would enable us to instantiate DataView controls as simply as this:

<ul class="dv">
    <li>{{ $dataItem }}</li>
</ul>
<script type="text/javascript">
    $(".dv").dataView({ data: ["foo", "bar", "baz"] });
</script>

Get the code from here (you need to include jquery-1.3.2.js to the script folder):
http://weblogs.asp.net/blogs/bleroy/Samples/jQueryCreate.zip

Five gems of XBLA

Bertrand Le Roy — Sun, 03 May 2009 07:20:44 GMT

The Maw is a charming and seriously fun game that is going to make you smile from start to finish.
Puzzle Quest is one of those “just one more” time sinks. The improbable mix of puzzle gaming and RPG is just awesome. The sequel, Galactrix, is pretty good too (but quite buggy, you might want to wait for a patch or at least regularly copy your game save).
Portal is simply the best game ever, at least for me. Portal proves once more that the simplest ideas can be the deepest and does so with amazing grace and mastery of the art of video games.
Banjo Kazooie and Banjo Tooie were two of the best N64 games, maybe on par with Super Mario but with that unique Rare sense of humour.
Cloning Clyde: smart and funny.

What are your favorite XBLA games?

Glimmer: visually build jQuery animations and stuff

Bertrand Le Roy — Tue, 28 Apr 2009 18:35:29 GMT

If you’re still intimidated by jQuery or DOM manipulation in general, if you need to quickly build web animations, if you’re more a designer guy, if you think tooling makes sense, or a combination of the above, you should probably check out Glimmer.

In a nutshell, Glimmer is a visual tool that builds HTML animations, menus, tooltips on jQuery. It builds all the code you need (HTML, CSS and JavaScript with jQuery) at the click of a button.

Check it out!
http://visitmix.com/Articles/Glimmer-a-jQuery-Interactive-Design-Tool

A blog on Microsoft Ajax client templates and data

Bertrand Le Roy — Tue, 21 Apr 2009 21:45:01 GMT

Politian has a great blog series where he goes into the details of building a data-driven Ajax application using the new 4.0 client templates and data.

Check it out!
http://politian.wordpress.com/

CSS isolation: there has got to be a better way

Bertrand Le Roy — Tue, 14 Apr 2009 07:26:04 GMT

CSS can be a tricky thing. I’m trying to do something that I think should be pretty simple. Let’s say a page contains a section (e.g. an admin panel) that must be styled independently from the rest of the page, but consistently and predictably. The DOM and CSS for the main part of the page is undetermined (e.g. because it’s part of a user-defined theme). Of course, you could use iframes, which are about the only isolation mechanism in HTML but we can’t do this here because iframes are quite rigid in shape (they are rectangles), they make scripting the DOM more difficult and they pretty much require an additional round-trip to the server to serve their contents.

The real problem to solve here is that if the main CSS for the page defines very general styles that for example target all elements with a given tag name, and those styles are going to bleed into our specialized region unless we find a way to block that CSS from cascading down. Ideally, you’d have an attribute on the tag, something like inheritcss=”false”, but no such thing exists.

So the only way I’ve found to solve this problem is to write a stylesheet that explicitly resets the defaults for all properties and all elements. Here is an excerpt from the CssIsolation.css file:

.isolate *
{
    background: white none repeat scroll 0% 0%;
    border: 0px none black;
    border-collapse: separate;
    border-spacing: 0px;
[...]
    z-index: auto;
}
.isolate p 
{
    display:block;
    margin-top: 16px;
    margin-bottom: 16px;
}
.isolate strong, .isolate b 
{
    font-weight: bold;
}
.isolate h1
{
    display: block;
    font-size: xx-large;
    font-weight: bold;
    margin-top: 21px;
    margin-bottom: 21px;
}

This is lame for a number of reasons:

Defaults might vary from browser to browser (this is particularly true of fonts and sizes).
Some styles can’t be reset to defaults, such as default button styles (at least, not without using browser-specific styles that aren’t consistently available):
An exhaustive list of tags and style properties is sure to be wrong now or in the future (I did CSS 2, so it’s already outdated by CSS3).

Still, imperfect as it is, this is a solution that works reasonably well and can be improved as problems are found. The equivalent of that inheritcss=”false” attribute, using my isolation stylesheet, is to set class=”isolate” on the parent element of the section of the page you want to isolate. None of the styles defined for the rest of the page (which is defined just as usual, with no difference whatsoever) should bleed then.

Here a snapshot of my test page, where you can see, side-by-side, unstyled HTML and HTML with reset styles:

Differences exist but are quite subtle.

The HTML for an isolated section is defined like this:

<div class="isolate" id="isolated1">
    Isolated 1...
</div>

If for example the main style sheet defines the style of lists like follows, this style won’t bleed into any element that has the isolate class (on the right on the next screenshot), just because we set the “isolate” class on the parent element.

ul li 
{
    list-style-type: square;
}
ol li 
{
    list-style-type: upper-roman;
}

You can then style each of these sections independently by just qualifying each of the style selectors with the ID of the parent element. In other words, just paste “#isolated1” in front of each selector of the local stylesheet, if the id of the parent element is “isolated1”:

#isolated1 p
{
    color: Green;
    border: solid 1px black;
}

This style will override the isolation CSS because it is qualified by id, which always wins over styles that are only qualified by class:

I really wish one of you will tell me how stupid I am for not knowing about feature/hack X that is way simpler and gets you to the same place… There has got to be a better way.

The code for the isolation stylesheet, as well as the test pages, can be found here:
http://weblogs.asp.net/blogs/bleroy/Samples/CssIsolation.zip

Quantum computing done right

Bertrand Le Roy — Wed, 01 Apr 2009 23:44:00 GMT

I know as a good microsoftee I should be supportive of what my employer does no matter what it is, and I might get fired for this post, but Eilon’s latest article is wrong on so many levels I have to step up with whatever integrity I have left and fix this mess.

In his post, he exposes the new ShrödingOr<TDead, TAlive> type that will be introduced in .NET 5.0 as part of the System.QuantumEntanglement namespace. Well, let’s face it, the current implementation has nothing quantum about it.

Here’s how I would have written it:

namespace System.QuantumEntanglement {
    public class SchrödingOr<TDead, TAlive> {
        private Complex _howDead;
        private Complex _howAlive;

        public SchrödingOr(Complex howDead, Complex howAlive) {
            _howDead = howDead;
            _howAlive = howAlive;
        }

        public Type Measure() {
            double howAliveSquareModulus =
                _howAlive.Real * _howAlive.Real +
                _howAlive.Imaginary * _howAlive.Imaginary;
            double howDeadSquareModulus =
                _howDead.Real * _howDead.Real +
                _howDead.Imaginary * _howDead.Imaginary;
            double probabilityOfBeingAlive = howAliveSquareModulus /
                (howAliveSquareModulus + howDeadSquareModulus);

            if ((new Random()).NextDouble() < probabilityOfBeingAlive) {
                _howAlive = new Complex(1, 0);
                _howDead = new Complex(0, 0);
                return typeof(TAlive);
            } else {
                _howAlive = new Complex(0, 0);
                _howDead = new Complex(1, 0);
                return typeof(TDead);
            }
        }
    }
}

This way, the state really is a (complex) linear combination of the dead and alive types, which are the eigenstates of the system. Once you’ve created the state, you can never get it back unless you do a measurement. When you do that, the object collapses its state to one of the eigenstates based on probabilities determined by the actual quantum state of the system.

The first measurement is random but once you’ve measured it, the cat remains alive or dead forever (the entanglement is destroyed by the measure).

Here’s a little console app that creates a cat, puts it in the box and then opens the box:

static void Main(string[] args) {
    // put the cat in the box
    var cat = new SchrödingOr<DeadCat, LiveCat>(
        new Complex(1, 0), new Complex(1, 0));
    // Open the box
    Console.Write(cat.Measure() == typeof(DeadCat) ?
        "Cat is dead." : "Cat is alive");
    Console.ReadKey();
}

This, I believe, is a much more realistic and useful implementation of SchrödingOr.

The code: http://weblogs.asp.net/blogs/bleroy/Samples/Quantum.zip

Eilon’s original article: http://weblogs.asp.net/leftslipper/archive/2009/04/01/the-string-or-the-cat-a-new-net-framework-library.aspx

Some ASP.NET compiler black magic

Bertrand Le Roy — Mon, 30 Mar 2009 23:48:00 GMT

In the work we’ve been doing with Rob on the Kona commerce app, our quest for extreme pluggability has led us to look at quite a few interesting features of ASP.NET compilation. Features I didn’t know about before Dmitry and David pointed them out for me. I thought I’d share…

It starts with the <%@ Assembly src= %> and <%@ Reference virtualpath= %> directives which you may have seen show up in IntelliSense when building a page. But what are they doing exactly and what differentiates them?

They both enable you to reference code that is in a different file in the site. With both of them, you get full IntelliSense on the referenced code, but they don’t reference the same kinds of files. @Reference is meant to reference a specific class whereas @Assembly brings in an arbitrary code file. As a consequence, @Reference needs a file where there is a well-defined default class, such as a Page or a User Control. @Assembly on the other hand will enable you to reference an arbitrary code file with as many classes as you wish and get the compiler to dynamically build a neat assembly out of it. The difference really amounts to whether or not the build provider implements GetGeneratedType, which the aspx and ascx build provider implements, and which generic code file providers typically don’t. In other words, if you built your own Build Provider and implemented that method, the files it compiles could be referenced using Reference. Without it, ASP.NET wouldn’t know which type to pick as the referenced one. But @Assembly will still work.

Building an assembly from a virtual path was really important for us because it enables a file anywhere in the web site to be dynamically compiled and used, which is exactly how we wanted plug-ins to work: we could have put the plug-ins into App_code (which does dynamic compilation automatically) but the name is not exactly intuitive, and it limits your ability to mix languages within the same folder. Please note that there *is* a way to mix languages in App_code:

<system.web>
  <compilation debug="true">
    <codeSubDirectories>
      <add directoryName="cs"/>
      <add directoryName="js"/>
    </codeSubDirectories>
  </compilation>
</system.web>

This config setting instructs the compiler to compile the cs and js folders in App_code into separate assemblies, which is all we need to allow for multiple languages. But we can do better than that.

It so happens that the compiler feature that enables the Assembly directive is also available as a public API (that works in Medium Trust):

BuildManager.GetCompiledAssembly

Seriously, this is now officially my favorite API in the whole .NET framework. This quite remarkable API takes a code file within the site and compiles it into an assembly (if that hasn’t already been done by a previous call to that API or by an @Assembly directive). What you get back from it is an Assembly object, which you can reflect on (using public reflection, which works in Medium Trust) and use any way you want.

This will enable us to dynamically compile the files in a Plugins top-level directory of the app. Doing so, we are getting multi-language support without config settings or special folders, nicer folder name and bonus points for not shutting down the app domain every effing time any file is touched. Bye bye App_code!

Well, of course that’s now one assembly per code file, which could be a problem if you have 800 plug-ins in your app, but then again if that’s the case maybe it’s time you moved all those into a nice pre-compiled assembly. Or do some clean-up. Anyway, this will work just fine for the type of scale we have in mind.

A question you may ask at this point is what exactly happens when one of those files is modified. Well, the BuildManager will generate a new assembly and “forget” about the old one. And when I say forget, I don’t mean it’s getting unloaded, just that it won’t get used anymore (unless you have code that held on to a reference). That means that potentially, there could be some assembly rot after a while if your files change often. To mitigate that, BuildManager has a set of rules that it uses to determine that it needs to restart the app domain after a while. Just like App_code, just a lot less often. Basically, the rules are pretty much the same as for aspx or ascx files.

All right, so this is all quite useful (I know I’m going to use that stuff a lot, at least). How about a useless hack now? (if you don’t like a fun hack, feel free to skip the rest of this post)

So think about all the neat stuff we could do by combining this with Virtual Path Providers... Except that in ASP.NET up to and including 3.5 SP1, Virtual Path Providers don’t work in Medium Trust. Neither do Build Providers, which would also be quite neat to play with. Bummer.

But wait, people in the team thought about that and wondered what harm exactly you could do with VPPs and BPs that you couldn’t already do by simply writing code and well, the answer is pretty much nothing. So the good news is that VPPs and BPs will work in Medium Trust in ASP.NET 4.0. Hurray!

So just for the sake of it, here’s the real black magic part of this post. Please note that there is more than one better way to do what I’m about to do and pretty much all of them would be simpler. I’m just hacking here and it’s going to be relatively convoluted.

And as Adam Savage says, “don’t try any of what you’re about to see at home. Ever!”. Seriously, this is dangerous code that has too many holes to count and that I wouldn’t run on anything but Visual Studio’s built-in web server (which is limited to requests from the same machine). Again, just hacking for fun here.

The thing I’ve done is build a VPP that takes an operation embedded in the file name and builds a function that executes that operation. So for example, if you ask it for “A+B.cs”, it will get you a cs file that contains a class that has a method that takes two arguments and returns their sum:

namespace Dynamic {
    public static class Calculator {
        public static double Operation(double A, double B) {
            return A + B;
        }
    }
}

Mix that with the amazing BuildManager.GetCompiledAssembly and we have dynamic compilation of a user-specified function. Which is the scariest part of course, but still fun, eh?

The usual disclaimer to use this at your own risk applies… I also didn’t spend too much time encoding the file name in the VPP thingy so some operations won’t go through too well. Multiplications for example. But eh, even the brightest minds don’t get everything right the first time.

http://weblogs.asp.net/blogs/bleroy/Samples/VppTest.zip

asp:menu fix for IE8 problem available

Bertrand Le Roy — Mon, 23 Mar 2009 21:20:00 GMT

Internet Explorer 8 is a unique release in the history of Internet Explorer in more than one way, but the decision to make standards mode the default means that authors of existing sites are impacted by it, if only to set the compatibility mode to IE7.

But what if your site is built using components that render out markup and script over which you have little control, such as ASP.NET WebControls? Well, if one of the controls fails in IE8 standards mode, you need to either switch to compatibility mode (ouch!) or you need the component developer to ship an updated version.

During the whole IE8 development cycle, we monitored the behavior of existing controls. Most ASP.NET built-in controls have been doing just fine in IE8, or the faulty behavior was actually due to an IE bug that we reported and that got fixed.

All except asp:menu. It so happens that the menu control is making a bad assumption on what the default value for z-index should be. We debated this at length with the IE team, but it became clear as we did so that they were right and that we were wrong. We had to fix that.

So here it is, the patch for menu is out and you can apply it to build IE8-compatible ASP.NET WebForms sites…

Windows 2000, XP, Server 2003:
http://code.msdn.microsoft.com/KB962351/Release/ProjectReleases.aspx?ReleaseId=2294

Windows Vista, Server 2008:
http://code.msdn.microsoft.com/KB967535/Release/ProjectReleases.aspx?ReleaseId=2328

UPDATE: the KB article can now be found here:
http://support.microsoft.com/kb/962351