The other day a colleague of mine needed to load a strongly typed ADO.NET DataTable from a LINQ to SQL query. We didn't find any good solutions using "The Google", so after a bit of hacking we came up with something similar to this:

    PeopleDataSet ds = new PeopleDataSet();
    using (PeopleDataContext context = new PeopleDataContext())
    {
        (from p in context.Persons
         select new
                    {
                        Row = ds.Person.AddPersonRow(p.Id, p.FirstName, p.LastName)
                    }).ToList();

    }

After ToList() executes we should have a DataTable populated with the results of our query.

I saw something on the Mozilla 2 Project Wiki this morning that I thought was quite clever. It's the notion of defining "anti-goals". How many more projects would be successful if we simply defined what we don't want? Good stuff.

Mozilla 2 Anti Goals

The default model for ASP.NET MVC is the 'Web Application Project'. This makes sense especially when you consider the amount of emphasis the ASP.NET MVC team is putting on TDD.

At the same time I really like the ASP.NET 'Web Site' model. I just find that I'm more productive with it. I decided to hack together some templates for making ASP.NET MVC development possible using the 'Web Site' model.

A few caveats. I couldn't figure out how to get template filtering to work in Visual Studio so I pulled it out. This means that the item templates will probably show up in the IDE more often than they should. If you have any tips on getting template filtering to work properly please let me know.

The templates are for ASP.NET MVC Codeplex Preview 5. The templates only support C#. TDD is not supported.

The project template is contained in this zip file:

MvcWebSite.cs.zip (157 KB)

The item templates are contained in these zip files:

ControllerItemTemplate.cs.zip (.97 KB)
MvcViewPageItemTemplate.cs.zip (2.15 KB)
MvcViewUserControlItemTemplate.cs.zip (1.4 KB)
MvcViewMasterPageItemTemplate.cs.zip (2.35 KB)

I find the 'My Templates' feature in VS to be kind of hokey so I installed these templates directly into the Visual Studio 2008 directory.

Here are the steps to get the templates to show up in Visual Studio:

1. Copy 'MvcWebSite.cs.zip' directly (don't unzip it) into 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ProjectTemplates\Web\CSharp\1033'
2. Copy the remaining item templates into 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\ItemTemplates\Web\CSharp\1033'
3. run the following from the command line: 'devenv.exe /installvstemplates'

The 'File -> New Web Site' dialog should now display a project item called 'ASP.NET MVC Web Site'.

In order for CSS styles to be applied correctly you will need to change the 'Virtual path' property of the web site to '/' (root). Scott Guthrie outlines this process below.

http://weblogs.asp.net/scottgu/archive/2006/12/19/tip-trick-how-to-run-a-root-site-with-the-local-web-server-using-vs-2005-sp1.aspx

NOTE TO MICROSOFT: I would be nice if '/' was the default when creating a new web site.

I've only been playing with it for a few days, but I *REALLY* like this framework. I also whole-heatedly recommend jQuery in Action to help you get up to speed.

Cool! One of the things I love about the current tech environment is the amount of competition between all of the big companies. Competition is the only true driver of innovation. Both users and programmers are going to end up with better technology when all is said and done. Those years of browser stagnation seem like a distant memory now.

Another thing I found interesting in the Wikipedia entry on Google Chrome was the following:

The Gears team were considering a multithreaded browser (noting that a problem with existing web browser implementations was that they are inherently single-threaded) and Chrome implemented this concept with a multiprocessing architecture. A separate process is allocated to each task (eg tabs, plugins), as is the case with modern operating systems. This prevents tasks from interfering with each other which is good for both security and stability; an attacker successfully gaining access to one application does not give them access to all and failure in one application results in a Sad Tab screen of death not unlike the well-known Sad Mac. This strategy exacts a fixed per-process cost up front but results in less memory bloat overall as fragmentation is confined to each process and no longer results in further memory allocations.

Interesting. What this means (on Windows at least) is that when you start up Google Chrome you get two processes:



I can only assume that one instance is for the Chrome host process and one instance is for the initial tab. When you create a new tab and navigate to a web page you will see at least one new instance of chrome.exe. There may be more than one process for the tab depending on the number of plugins on the page.  

After creating a few additional Chrome tabs my 'Windows Task Manager' looks like this:



For a "process hawk" like me this will take a some getting used to!

So this is Microsoft's strategy to defeat Google. Yikes!

UPDATE: 3/19/2008 - Joel Spolsky explains the "big picture" of what's going on here in his Martian Headsets article.

While it’s unlikely that you would ever want to invoke the Volta compiler directly, using it does provide some insight into how Volta works.

Let’s say that you have an existing assembly named BoringObjects.dll.  BoringObjects.dll contains one class named Person.



To do a Volta conversion of this assembly from MSIL to JavaScript execute the following command from the console window. NOTE: you will need "C:\Program Files\Microsoft Live Labs Volta" in your path.

> volta BoringObjects.dll /out:JSOutput

The only argument of interest is /out:JSOutput.  This is the directory that the Volta compiler will write the JavaScript files to.

If we look under our specified output directory we notice that Volta has created a directory that corresponds to the assembly name.  Under that directory there are three items:

[Types] (directory)
assembly.js
typeMapping.js

Under the Types directory there is one file "tA.js" which corresponds to the lone Person class in our original assembly.  If you use /d (debug) option the file will be named "type_0__Person.js" and the JavaScript code will be nicely formatted.

It’s interesting to note that this same structure is seen in "C:\Program Files\Microsoft Live Labs Volta\Cache".  In that directory you will find that some core .NET assemblies and the Volta libraries have been converted to JavaScript. This step is apparently part of the installation process.

A prevalent theme in the Volta documentation is the concept of the three “R”s. These three principles are at the heart of what Volta attempts to provide for developers.  They are retargeting, remodulating, and refactoring.

Retargeting

To me this is the coolest aspect of Volta and the feature that makes it a very interesting technology. At its core Volta is a compiler or more accurately a recompiler.  Instead of recompiling the source code Volta uses a technique called MSIL rewriting. This is what enables the developer to write client-side browser code in C#. Since all CLR languages compile to MSIL, Volta can use that as the common denominator. Volta is capable of MSIL to MSIL, and MSIL to JavaScript conversion.

Remodulating

Another goal of the Volta toolset is seamless cross-browser support. As the documentation states:

 Volta hides as many browser-specific differences as possible, but still allows developers to leverage the unique capabilities of particular browsers. Instead of targeting solely the intersection of browser capabilities, Volta targets the entire union, but makes the intersection browser-agnostic. This is browser remodulating.

Remodulating also deals with the debugging experience. Regardless of the browser platform developers will be stepping through their application code within Visual Studio. That's assuming of course that your target is either IE or FireFox which are the only browsers supported in the current release.

Refactoring

Volta refactoring is about enabling developers to create their applications while deferring decisions about what tier a particular component will run in. In my opinion this will be the most controversial feature of the toolset.  Larry O’Brien has some reservations about it:

This sounds like a bad idea to me. You can't refactor away the difference between an in-memory method call and an Internet message: one happens in nanoseconds and the other in milliseconds

I have some questions of my own about this. The docs claim that:

During development, all code runs in the client for ease of testing and debugging.

What are the implications of this? Not every .NET class is meant to run in a browser context. Does Volta offer any automatic guidance with regard to this? The notion of clicking a “Split Tiers” check box and decorating a class with a [RunAtOrigin] does seem implicitly powerful, I’m just curious to know where the model breaks down. I will try to answer these questions and others as I dig deeper into the framework.