Tales from the Evil Empire : .NET

Fun with C# 4.0’s dynamic

Bertrand Le Roy — Thu, 17 Sep 2009 07:50:29 GMT

There’s been some debate recently on the new “dynamic” keyword in C# 4.0. As has been the case with many features before it, some love it, some hate it, some say it bloats the language, yadda yadda yadda. People said that about lambdas. Me, I’ll just use it where I see a use case, thank you very much.

In the case of dynamic, another frequent comment is that a statically-typed language should not try to look like a dynamic language. Well, I just don’t believe in that distinction.

Being dynamic is a trait that a language can have, and some have it more than others. But as soon as a language has a dictionary type or indexers, and most modern languages do, it starts having dynamicity. What people call a dynamic language is just one where it’s the only available type.

Now there is type safety of course, but to me that’s a different feature that is not as coupled with “statically-typed-ness” as we usually tend to think. Case in point, many modern JavaScript engines analyze the code in order to apply many of the optimization techniques that static languages have been applying at compile-time.

So just how dynamic was C# before 4.0? Well, there are dictionaries and indexers, as I’ve said, but there are also other interesting and less known features such as custom type descriptors. Go look them up if you don’t know about them. Type descriptors are for example used to provide a level of indirection between a design surface and the components being edited.

But type descriptors can also be built completely dynamically and decide to expose a completely virtual object model that is entirely built at runtime. Of course, the client code for that object has to go through the right APIs to make use of that quasi-dynamic model. And of course those APIs are not simple. Implementing a custom type descriptor in itself is not exactly trivial.

If anything, the dynamic keyword is going to provide a friendlier syntax for this sort of thing. One problem is that it has no relationship whatsoever with custom type descriptors.

So I thought I’d try to bridge that gap. How can we take a type that exposes a custom type descriptor, such as DataRowView, and transform that into something that plays nice with the dynamic keyword? What we want to be able to write is something like the following:

var table = new DataTable("People");
table.Columns.Add("FirstName", typeof(string));
table.Columns.Add("LastName", typeof(string));
table.Columns.Add("Children", typeof(int));
table.LoadDataRow(
    new object[] {"Bertrand", "Le Roy", 2},
    LoadOption.OverwriteChanges);
var tableView = new DataView(table);

dynamic dynRecord = 
    new TypeDescriptorDynamicWrapper(tableView[0]);
Console.WriteLine("{0} {1} has {2} children.", 
    dynRecord.FirstName, 
    dynRecord.LastName, 
    dynRecord.Children);

To do that, I built the TypeDescriptorDynamicWrapper that you see being used above. What is does is pretty simple, as it just inherits from DynamicObject and implements TryGetMember as follows:

public override bool TryGetMember(
    GetMemberBinder binder, out object result) {

    var name = binder.Name;
    var property = _properties.Find(
        p => p.Name.Equals(name,
            binder.IgnoreCase ?
            StringComparison.OrdinalIgnoreCase :
            StringComparison.Ordinal));
    if (property == null) {
        result = null;
        return false;
    }
    result = property.GetValue(
        _descriptor.GetPropertyOwner(null));
    return true;
}

As you can see, the method just finds the right property on the type descriptor and delegates to it if it finds it. I didn’t implement the setting of properties but it would be fairly easy to do so.

Using that simple wrapper, the program above just works and displays:

Bertrand Le Roy has 2 children.

That was easy. Now what about the reverse, getting any dynamic object to expose a custom type descriptor?

Well, that’s where things get tricky.

The dynamic capabilities of C# 4.0 are targeted at two things:

Providing syntactic sugar for getting to dynamic members that looks like accessing statically-defined ones.
An easy way to create dynamic types by implementing a form of method_missing.

But there is one thing that exists in DLR but didn’t make it to C# yet, which is the ability to easily reflect on dynamic objects (other than by using the #1 syntactic sugar above).

For example, in JavaScript, a.foo and a[“foo”] are exactly the same thing, which enables easy reflection: you can enumerate the members of an arbitrary object and do stuff like a[someStringVariable].

Doing the same thing with C# on dynamic objects is much more difficult. The equivalent of a.foo is easy, but not the equivalent of a[someStringVariable].

Forget about using reflection, it doesn’t work on dynamic objects because dynamic really is a compiler trick. There is no such thing as a “dynamic” type to reflect on. It’s a keyword that tells the compiler to relax type-checking and generate code to access those dynamic members at runtime. If you try to reflect on an instance of one of the dynamic-friendly type, such as ExpandoObject, you’ll see the statically-defined members of that type, but not the dynamic ones. In a way, you’re looking at the messenger instead of the message.

This is a problem because in order to wrap an arbitrary dynamic object into a custom type descriptor, we need to be able to reflect on the dynamic members of that object.

To solve the problem, and with some help from the nice folks who are building the DLR, I compiled a simple program that sets and gets a property on a dynamic object, an then I looked at the generated code from Reflector (“luckily”, Reflector is not yet aware of dynamic and shows the generated code instead of something closer to the actual code you wrote).

I was then able to refactor that code and replace the string constants for the accessed member with a method parameter, thus creating a generic way to access dynamic object properties:

public static object GetValue(
    object dyn, string propName) {

    // Warning: this is rather expensive,
    // and should be cached in a real app
    var GetterSite = 
        CallSite<Func<CallSite, object, object>>
        .Create(
          new CSharpGetMemberBinder(propName,
            dyn.GetType(),
            new CSharpArgumentInfo[] {
              new CSharpArgumentInfo(
                  CSharpArgumentInfoFlags.None, null)
            }));
    return GetterSite.Target(GetterSite, dyn);
}

public static void SetValue(
    object dyn, string propName, object val) {

    // Warning: this is rather expensive,
    // and should be cached in a real app
    var SetterSite = 
      CallSite<Func<CallSite, object, object, object>>
      .Create(
        new CSharpSetMemberBinder(propName,
          dyn.GetType(),
          new CSharpArgumentInfo[] {
            new CSharpArgumentInfo(
              CSharpArgumentInfoFlags.None, null),
            new CSharpArgumentInfo(
              CSharpArgumentInfoFlags.LiteralConstant |
              CSharpArgumentInfoFlags.UseCompileTimeType,
              null)
          }));
    SetterSite.Target(SetterSite, dyn, val);
}

Once we have that, implementing the custom type provider is relatively straightforward. The only part that is not immediately obvious is how to enumerate the properties of the dynamic object.

This is done as follows. Dynamic objects implement IDynamicMetaObjetProvider, which has a GetMetaObject method, which returns a DynamicMetaObject object on which you can call GetDynamicMemberNames to get the list of members.

We can now take any dynamic object and for example present it in a property grid, which is one of those components that know how to handle custom type descriptors but not the new dynamic objects:

dynamic person = new ExpandoObject();
person.FirstName = "Bertrand";
person.LastName = "Le Roy";
person.Children = 2;
propertyGrid1.SelectedObject = 
    new DynamicTypeDescriptorWrapper(person);

And here’s what the results look like:

In conclusion, I’d say that although we are having a healthy debate on the dynamic keyword (and we should have that debate), I’m confident that in one or two years, we’ll have some incredibly imaginative uses of the feature that will simply blow us away and will make the current conversation a little sillier than it seems today. The feature itself is also in its infancy and not only will the use cases emerge way beyond what even its designers envisioned, it will also grow and become more usable with future versions of the language, as is made clear by the gap in functionality that still exists today with the full DLR project.

You can download the code for this article here:
http://weblogs.asp.net/blogs/bleroy/Samples/Bleroy.Sample.Dynamic.zip

Hiring for new super-secret project

Bertrand Le Roy — Thu, 30 Jul 2009 20:35:06 GMT

Well, I guess it’s not so super-secret anymore now but these last few months, I’ve been transitioning from ASP.NET Ajax to a new project that aims at helping ASP.NET communities build Open Source applications on ASP.NET. It’s a lot of fun and the good news is that you can join in. We are hiring a senior developer:

https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=1&jid=4567&jlang=EN

Please mention me (Bertrand Le Roy, bleroy at Microsoft) as the referral if you apply. ;)

Mocking indexer getters with Moq

Bertrand Le Roy — Thu, 16 Jul 2009 23:42:17 GMT

This is a follow-up on that other post: Mocking indexer setters with Moq.

So thanks to that post, we now know how to intercept the setting of a particular indexed property (in our example, an application variable) and set a local variable with the value that was set by the tested code.

Now if you want the application to return that same value when queried by the tested code, you also need to mock the indexer getter.

This operation is also not entirely trivial. Here’s how you do it: you do a SetupGet chained with a Returns with a lambda expression as the parameter:

mockHttpContext
    .SetupGet(c => c.Application["foo"])
    .Returns(() => (object)map);

That last point about using a lambda is pretty important. If you just use map as the parameter for Returns, Moq will hold on to a reference to whatever object map contained at the time the call to Returns is made. This might very well be null, if you started with the code in our previous setter example. If you use a lambda on the other hand, Moq will not hold on to the value of map but to the expression that returns the value of map. The execution is deferred. Now every time the tested code exercises that path, Moq will evaluate the expression, which will return the current value of map.

Also of interest, whereas we had to explicitly have an index parameter for the callback lambda in the case of the setter, Returns needs no such thing, and this example actually has little code that is specific to indexed properties. The trick about the lambda in the Returns in particular applies just as well to mocking getters for non-indexed properties.

A (less) simple include for ASP.NET

Bertrand Le Roy — Fri, 10 Jul 2009 22:57:00 GMT

In yesterday’s post, I published the code for a simple include method for ASP.NET that I’ve been using in a couple of places, only to realize that it was fine for what I was doing but probably not very useful beyond that.

So I spent some time today broadening its scope. It now supports nested includes (I modified the original post to reflect that change) and also setting properties on the control.

You can still do plain includes:

<% this.Include("contents.ascx"); %>

But now you can also set properties on the included user control using an anonymous object:

<% this.Include("contents.ascx", new {number=2, what="A"}); %>

The code for the helper considerably grew along the way but it’s still reasonable:

using System;
using System.Linq;
using System.Reflection;
using System.Web.UI;

public static class IncludeHelper {
    public static void Include(this TemplateControl host,
                               string virtualPath) {
        Include(host, virtualPath, null);
    }

    public static void Include(this TemplateControl host,
                               string virtualPath,
                               object properties) {
        var resolvedPath = host.ResolveUrl(virtualPath);
        var include = host.LoadControl(resolvedPath);
        if (properties != null) {
            var includeType = include.GetType();
            foreach (var fieldInfo in
                         properties.GetType().GetProperties()) {
                var targetInfo = includeType.GetMember(
                    fieldInfo.Name,
                    MemberTypes.Field |
                    MemberTypes.Property,
                    BindingFlags.IgnoreCase |
                    BindingFlags.Instance |
                    BindingFlags.Public)
                    .FirstOrDefault();
                var targetPropertyInfo = targetInfo as PropertyInfo;
                if (targetPropertyInfo != null) {
                    targetPropertyInfo.SetValue(
                        include,
                        fieldInfo.GetValue(properties, null),
                        null);
                }
                else {
                    var targetFieldInfo = targetInfo as FieldInfo;
                    if (targetFieldInfo != null) {
                        targetFieldInfo.SetValue(
                            include,
                            fieldInfo.GetValue(properties, null));
                    }
                    else {
                        throw new ArgumentException(
                            "There is no property of field with " +
                            "that name on the target control.",
                            fieldInfo.Name);
                    }
                }
            }
        }
        using (var writer =
                   new HtmlTextWriter(host.Page.Response.Output)) {
            include.RenderControl(writer);
        }
    }
}

I hope this helps. Again, if you are OK with the regular syntax to include a user controls, you probably shouldn’t use this and stick to what you know. I built this because I’m not entirely satisfied with that syntax and because I have a clear use case where it makes more sense. Make your own opinion and follow it :)

Note: The control is still not going into the control tree, which breaks lots of stuff. I don't really care that much about it but it may be important to you so I thought I'd point it out.

A simple include for ASP.NET

Bertrand Le Roy — Thu, 09 Jul 2009 23:30:55 GMT

In yesterday’s post, I alluded to a simple include extension method that I like to use when I don’t care about designer support. In a comment, Andrew asked if I could share the code for it, so here it is.

I never liked the regular way of including user controls in WebForms and how they require a registration and a declaration, both of which are more verbose than they need to be. A plain #include would work but is a little outdated (and if I’m not mistaken it’s not even available by default in IIS7).

My Include method is quite similar to MVC’s RenderPartial except that it doesn’t deal with view data. It’s a plain and simple include. Just give it the relative path to a user control:

<% this.Include("Header.ascx"); %>

Here’s the code for that extension method:

using System.Web;
using System.Web.UI;

public static class IncludeHelper {
    public static void Include(this TemplateControl host,
                               string virtualPath) {
        var resolvedPath = host.ResolveUrl(virtualPath);
        var include = host.LoadControl(resolvedPath);
        using (var writer =
                   new HtmlTextWriter(host.Page.Response.Output)) {
            include.RenderControl(writer);
        }
    }
}

It just resolves the path, loads the control and renders it in place.

To use that method, just drop the code as a cs file into App_code if you’re using a web site, or just add it to your project otherwise.

I played with the idea of enabling an anonymous object parameter to set properties on the user control, but I guess if you’re going to do that, the benefits of the helper get dimmer and going with the regular WebForms user control registration and tags is probably just easier (you’ll get IntelliSense on the properties for example).

Disclaimer/update: No, this does not run the control through the page lifecycle (although it could by adding it to the page’s control tree and removing it after rendering it). No, if you use master pages you probably don’t need it. No, you can’t set properties.

This is just the simplest include I could build, and it does only that: including contents. If it seems useless to you, it probably is. I published it mainly because I was asked to. :)

Update: I wrote a more complex version that can set properties on the included controls:
http://weblogs.asp.net/bleroy/archive/2009/07/10/a-less-simple-include-for-asp-net.aspx

Are Master Pages too complex?

Bertrand Le Roy — Wed, 08 Jul 2009 23:38:00 GMT

Master Pages are a wonderful concept that as developers we highly value. It’s the sort of pattern that just looks like the right thing to do (to our twisted, concept hungry developer minds) and that even makes you wonder why we haven’t done it that way since the beginning of time (1990). For the record, master pages were invented by David Ebbo, who is behind a lot of the smartest things in ASP.NET.

Just in case you have no idea, what are Master Pages? Before master pages, sharing layout between pages was done using includes (or user controls). For example, your typical hello world page might have looked like this:

<%@ Page Language="C#" %>
<%@ Register TagPrefix="include" TagName="header"
             Src="~/HelloHeader.ascx" %>
<%@ Register TagPrefix="include" TagName="footer"
             Src="~/HelloFooter.ascx" %>
<!DOCTYPE html>
<html>
<head>
    <title>Hello world with includes</title>
</head>
<body>
    <div>
    <include:header runat="server" />
    Hello world!
    <include:footer runat="server" />
    </div>
</body>
</html>

Notice that the page does contain markup that is not specific to the page (boilerplate markup mainly that you could put into includes as well, but only at the cost of breaking beginnings and ends of semantic blocks into separate includes).

As a side note, I’ve always thought the user control syntax above was overly verbose when all you want is a plain include. It has the one advantage of enabling the Visual Studio designer but having a separate registration and declaration seems overkill. The #include directive still exists but I personally prefer to use a simple helper extension method to Page that brings the code down to this (MVC gives you Html.RenderPartial, which is roughly equivalent):

<%@ Page Language="C#" %>
<!DOCTYPE html>
<html>
<head>
    <title>Hello world with includes</title>
    <meta name="keywords" content="hello world" />
</head>
<body>
    <div>
    <% this.Include("HelloHeader.ascx"); %>
    Hello world!
    <% this.Include("HelloFooter.ascx"); %>
    </div>
</body>
</html>

With master pages, you can get rid of all common markup and really limit what you put into the page to just what varies from page to page. for example, the above hello world page might be written like this:

<%@ Page Language="C#" MasterPageFile="~/MasterPage.master"
    Title="Hello world!" %>

<asp:Content ContentPlaceHolderID="head" Runat="Server">
    <meta name="keywords" content="hello world" />
</asp:Content>
<asp:Content ContentPlaceHolderID="content" Runat="Server">
    Hello from the content page!
</asp:Content>

That is clean, but pretty puzzling the first time you see it. To understand where the markup comes from, you need to track that @Page directive and understand that you need to look into the corresponding master page file:

<%@ Master Language="C#" %>
<!DOCTYPE html>
<html>
<head runat="server">
    <title>Master page</title>
    <asp:ContentPlaceHolder id="head" runat="server">
    </asp:ContentPlaceHolder>
</head>
<body>
    <h1>Hello from a master page</h1>
    <div>
        <asp:ContentPlaceHolder id="content" runat="server">
        </asp:ContentPlaceHolder>
    </div>
    Footer says hi.
</body>
</html>

You need to understand that those content place holder ids correspond to other controls that are in the master page and that the framework will make the match.

Master pages also come with the price of mangled ids, but that’s an implementation detail (one could imagine an implementation that wouldn’t suffer from that problem). The price we pay for master pages also comes in the form of a weird control tree: master pages are really implemented as user controls that get included by the page, a concept that is the inverse of the model they seem to promote; in other words, the implementation is the reverse of the concept, in a way. There are also complications about putting contents in the head section (head must be runat=server, script tags are tricky, setting the title, etc.).

So are master pages worth the price? It depends on who your audience is and on how your pages are built.

By audience, I mean the person who is going to write the views. If it’s just you and you are a developer, they might actually be a pretty solid choice. But if external designers are going to build the views, maybe you need to pause and try not to think as a developer for a moment.

The main problem with the include approach (and the reason why master pages were invented) is that the outer markup for the page needs to be on all pages. So if you decide to change that markup, you need to do so on all pages.

But in more and more applications, in particular CMS, this problem becomes moot. If your application decouples the content from the view code, and if the layout or view to use for a given content can be determined at runtime by a themeing engine, you might end-up with templates that look like this:

<%@ Page Language="C#" %>
<!DOCTYPE html>
<html>
<head>
    <title><%= Title %></title>
</head>
<body>
    <div>
    <% this.RenderZone("Header"); %>
    <% this.RenderZone("Contents"); %>
    <% this.RenderZone("Footer"); %>
    </div>
</body>
</html>

This is actually no different in concept from master pages (there are place holders in generic markup and no specific contents) but the contents do not come from a content page. Instead, they are dynamically inserted by the application.

The template file then becomes no more than layout. It is easy to understand and easier to assign a different layout to any given contents.

So in general there is no perfect answer on whether you should use master pages or not, but if you are able, in your application, to decouple page layout from contents, there is an opportunity to have clean and easy to understand markup that also maximizes re-use.

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.

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

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

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

Some MIX talks

Bertrand Le Roy — Mon, 23 Mar 2009 04:14:22 GMT

Stephen Walther just published links to the video, slides and sample code for his Ajax talk at MIX09:

http://stephenwalther.com/blog/archive/2009/03/22/mix-slides-code-and-session-recording.aspx

It’s pretty cool to see all the work we put into Ajax this past year or so presented at MIX. This is a really nice presentation, like Stephen’s always are.

Another presentation I had lots of fun watching (not just because the speaker is making an incredible impression of me but also because I’ve been spending a good part of my time lately contributing to the application he’s showing) is Rob Conery’s. Rob is showing an interesting way to develop ASP.NET applications, aimed at ease of use and customization rather than architectural purity. Check it out, let me know what you think…

http://videos.visitmix.com/MIX09/T62F

How to reflect over a delegate’s signature

Bertrand Le Roy — Fri, 23 Jan 2009 22:41:00 GMT

I’ve done some tricky work with delegates recently and I’ve had a hard time trying to reflect over the signature of a delegate type. I feel a little silly now that the solution to this has been provided to me by Eric Lippert. It’s actually quite simple, just reflect over the Invoke method:

MethodInfo invoke = typeof(Func<string, bool>).GetMethod("Invoke");
Console.WriteLine(invoke.ReturnType.Name);

I hope this helps others…

Wally’s introduction to 3.5 SP1

Bertrand Le Roy — Mon, 29 Dec 2008 19:36:18 GMT

Wally McClure, MVP extraordinaire and ASP Insider, just published a short book about the new features in ASP.NET 3.5 SP1. It is a short and to the point read that should get you started in no time. I wouldn’t have shown web service access as the main advantage of jQuery myself (the selector and animation support adds more value for ASP.NET Ajax developers) but that’s a minor thing, and there are plenty of other resources to learn about jQuery. Topics in Wally’s book include:

Ajax History
Script Combining (including ScriptReferenceProfiler)
jQuery
Routing
Entity Framework
Dynamic Data
ADO.NET Data Services

http://www.wrox.com/WileyCDA/WroxTitle/New-Features-in-ASP-NET-3-5-Service-Pack-1.productCd-0470457341.html