Did you know that Windows came with an embedded database?

Did you know that this embedded database is the power behind Active Directory & Exchange?

Did you know that this is actually part of Windows' API and is exposed to developers?

Did you know that it requires no installation and has zero administration overhead?

Did you know there is a .Net API?

Well, the answer for all of that is that you probably didn't know that, but it is true!

The embedded database is called Esent, and the managed library for this API was just released.

This is an implementation of ISAM DB, and I have been playing around with it for the last few days. It isn't as nice for .Net developers as I would like it to be (but Laurion is working on that).

I think making this public is a great thing, and the options that this opens up are quite interesting. I took that for a spin and came up with this tiny bit of code that allow me to store JSON documents:

https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/branches/rhino-divandb

It is not done, not nearly done, but the fact that I could rely on the embedded DB to do so made my life so much easier. I wish I knew about that when I played with Rhino Queues, it would have made my life so much simpler.

This is a post about Oxite, but it is actually not about the code base. There has been a lot said about this, and I think that I can solidly put myself on the side that spouts WTF and now seeks access to memory altering drugs.

What I wanted to talk about here is actually the way that this was handled. It didn't take long for people to start noticing the actual code quality of this in contrast to its marketing promise:

We heart you so much, that we thought of everything. Oxite was developed carefully and painstakingly to be a great blog sample, or a starting point for your own web site project with CMS needs. Its line-up of sexy attributes includes: provider-based architecture allowing you to swap out database and search providers (SQL Server DB, local and Live search providers included), built for testability and hence most likely to be voted "hottest in class" by TDD fans (repositories, everything has an interface, etc.)

The community reaction was mostly negative, especially since this was positioned as official sample application. The marketing for Oxite is actually quite amazing, when you consider that they have a channel 9 show, a visit mix site, a really nicely done codeplex site, a push from Microsoft evangelist and other things that I forget.

Very quickly, there was a response from more well known sources at Microsoft. It is interesting to watch the actual phrasing of the responses from those people. You have to admire the level of verbal acrobatics that they had do do. Again, I am more interested in the back story than in the code.

Scott Hanselman has this to say about the way Oxite was released:

I don't know the Oxite guys, and I didn't know they were working on anything. Thing is, anyone at Microsoft can put a project together, blog about it, and say "this aims to be a good example of...". Clearly it's not a good example and it shouldn't be advertised as one.

The fact that PhilHa, who owns ASP.NET MVC, didn't know it was going on, kind of makes that point. Any samples from Microsoft that intend to show a Best Practice should be reviewed by Phil, and certainly vetted by the community. David Nelson nailed that point clearly.

I think that this is really interested. "Anyone at Microsoft can put a project together and..."

Well, actually, no, they can't. Oh, they can do that for personal stuff, but they can't do that for Microsoft stuff. I had the chance to work with the P&P a couple of times, and I had the pleasure of seeing the release process from their side. Some of that is unique for P&P, I assume, but there are things that are certainly shared for all of Microsoft. A security review, for example, or the bloody annoying trademark stuff that give us names such as Windows Pillow Foundation Community Extended Express Edition for Professional Database Developers And Administrators 2008 R4.2.

There are other things, and among them, especially if you put out a best practice app, is to actually talk to the team that own this.

So, they can't do that. Or, to be rather more exact, they shouldn't have done that. Except that it appears that they did, I can see no other option given the information that is publicly available. Because there is absolutely no question that Oxite has been extremely damaging to Microsoft from a PR perspective. The worst part is that it was pushed as "we thought of everything" and "hottest in class".

We can compare those to Scott's BabySmash or to Rob Conery's Storefront (although I don't believe that even at their worst, they would have made me cry). Those were clearly labeled as learning projects, and that made all the difference.

Which bring us to the current state of affairs. Scott Hanselman said something that I utterly disagree with about this:

Oxite is Open Source. If you don't like it, and there are very valid reasons today for concern, I would sincerely encourage you to refactor it and share the results.

Open Source is not a way to get other people to fix bad code. I think that this is the wrong thing to do. However it got there, this was published with the impression that Microsoft is standing behind it. While my response would have been to kill the project, remove the site and deny that it has ever existed, Microsoft has chosen to keep it alive. I believe that by doing so, and I think that they have done so by not either killing the project or officially stating that this is not a Microsoft project, that Microsoft is now accountable for this project quality and its fitness to serve as an example application.

And yes, I do mean that what looks very much like a rouge project being released into the wild is now Microsoft's problem to fix. See above for the difference between stating the source (Microsoft vs. individual) and the effect that it has on the perception of the project.

Rob Conery's has picked up the ball and seems to be making rapid progress at it, judging from his twitter stream.

I think that this is the best solution all together. We get to see a good restructuring approach, and knowing Rob, we will end up with a good sample app. More to the point, that was the appropriate response to what happened.

It also has another side effect, which is pretty major one, it turning all that negative PR into a positive one, by stepping in, acknowledging the problems and fixing them.

This is the fix for the ExecutionEngineException that appeared in .Net 3.5 SP1, and was found by Rhino Mocks.

You can get it here: http://support.microsoft.com/?id=957541

David Kean has an interesting post here: "I can't believe Microsoft didn't make [Enter API Name Here] public"

In particular, he mentions this aging argument:

Developing good APIs is extremely difficult, especially the first time around. When we get things wrong (and we do get things wrong), trying to maintain backwards compatibility often stifles innovation as we try to correct these scenarios. Unfortunately, unlike others, we don't have the luxury to make only 95% of our new versions backwards compatible with our previous versions.

I have a lot of problems with this statement. Chief among them is the treating the users as people who should be cuddled. Actually, I don't really have a problem with cuddling, the real problem is that this is literally putting road blocks for progress.

The Microsoft backward compatibility strategy is a major reason why the default approach is to close down everything. Now, it is not as if there isn't a well defined way of saying: Touch that on your responsibility. This is quite pervasive, actually:

This API supports the .NET Framework infrastructure and is not intended to be used directly from your code.

But I think that this isn't actually the problem. The problem is that the rules that Microsoft has chosen to accept are broken. In that type of game, you are always losing. The only thing that you can do is to change the rate in which you are losing at.

Change the rules, treat the users as consenting adults, and you'll be able to do so much more, because the task ahead of you would be so much simpler.

On a day that I have to give 3 presentations, I open up windows and I refuse to log me in, instead, I get this thing:

And then it refuse to activate! Turning the window installation to a brick!

I solved that eventually, but that was a really scary time.

As you probably know by now, I have been working on an ASP.Net MVC project for the last two weeks. Based on that, I think that I can base a pretty good opinion about it.

Are you ready for it?

[insert significant pause here]

I like it.

Now, just to be clear. I like it not only in comparison to WebForms. I like it on its own. In other words, I don't consider the ASP.Net MVC to be a default choice if all you have is that or WebForms.

The pros of using an MVC framework are well known by now, so I wouldn't go blathering about that. ASP.Net MVC certainly hits a lot of those points. Another benefit that wasn't obvious to me was the default view engine, which uses the same WebForms editor. This means that we get intellisense. That was surprisingly nice to have.

Unfortunately, the WebForms view engine is also useless for any intermediate to advance scenarios, because it only allows you to render directly to the response, and doesn't allow you to capture the output of views and partials and process them further.

Another problem that I encountered with the framework is that, to someone who has been doing MVC for years, is it extremely non obvious at times. My default mode of learning is to dive into the code, and in general, this has been a successful way of doing things across many projects that I learned. I don't really like it that I run into brick walls along the way with ASP.Net MVC, but I should point out that my thinking about how things should work is based on my work with MonoRail, and it is likely affecting my expectation about the way the ASP.Net MVC behaves. Even so, there are several design decisions made there that I strongly disagree with.

The most problematic issue that I run into with the ASP.Net MVC during the last too weeks, and the reason that I don't consider the ASP.Net MVC vs. MonoRail to be a coin toss, is that a lot of the code is internal.

Now, I didn't actually went over the ASP.Net MVC source code. But I did tried to do things with it and was blocked several times because some of the things that I wanted to do are internal (IBuildManager comes to mind as a repeated example). The obsession with internal, and the resulting limitations of what I can do with the framework, is a huge problem for me in just about any Microsoft product. In this project, I explicitly didn't set out to create any complex site. I built a very trivial data driven CMS. Nevertheless, I hit a lot of those internal API, grr!

Most of those occur when trying to do anything interesting with the web forms view engine. There is enough friction using that that is it worth dropping it (web forms view engine) all together, even with the bonus of having intellisense in the views.

From the point of view of actual framework, I found it pleasant to work with for most of the time. And the extensions points that are open are very useful (OnActionExecuting, OnActionExecuted are good example of that). I think that in order to really get the benefits of the framework, I am going to have follow Jeremy Miller's footsteps and rip out all the thinks that I don't care about and replace them with a heavily opinionated and customized version.

The good news is that it is possible, and without too much problem.

This is getting annoying, to tell you the truth. I am trying to develop an application here, not do QA.

Let us take the following class:

public class IdAndName
{
    public long Id { get; set; }
    public string Name { get; set; }
}

And the following code:

var idAndNames = new[]
{
    new IdAndName {Id = 1, Name = "one"},
    new IdAndName {Id = 2, Name = "two"}
};
var list2 = new SelectList(idAndNames, "Id", "Name", idAndNames[1]);
var result2 = Html.DropDownList("test",list2);
	

What would you expect the value of result2 to be? I would expect it to render a <select> with two items, the second of which should be selected. Here it what it is generating:

<select id="test" name="test">
	<option value="1">one</option>
	<option value="2">two</option>
</select>

Notice that there is no selected attribute on the second one.

I will suffice with GRRRRRRRRRR!!!!! at this point.

Take a look at the following code. What would you expect the result of this code to be?

Leaving aside the question of exactly what I am doing here, or why. What I thought this should do was to render the partial view into the string writer.

The method signature of Render most strongly suggest that this is what it would do. What it actually does is to render the partial view directly into the response. Following the code a bit more, it looks like you literally cannot do this.

ASP.Net MVC views are hard coded to use the current request ( ViewPage.RenderView ). I checked a bit, and without basically faking the entire HttpContext and all its associated objects, that doesn't seem to be happening.

There are two problems here:

• The API lies about what it is doing
• There is no simple & obvious way to get the output of a view except directly into the response.

Create new ASP.Net MVC application:

Create an action that take non nullable argument called 'id':

[HandleError]
public class HomeController : Controller
{
    public ActionResult Index()
    {
        ViewData["Title"] = "Home Page";
        ViewData["Message"] = "Welcome to ASP.NET MVC!";

        return View();
    }

    public ActionResult Test(int id)
    {
        return Content(id.ToString());
    }

    public ActionResult About()
    {
        ViewData["Title"] = "About Page";

        return View();
    }
}

Go to home/index.aspx and add the following before the final </asp:Content> tag:

    <% using(Html.BeginForm("Test","Home")){ %>
        <%=Html.Hidden("id",2) %>
        <input type="submit" value="test" />
    <%} %>

Visit the site and see that you indeed have a test button on the page. Click the button.

Get an exception:

I am going to assume this is a bug.

This is on the ASP.Net MVC beta bits.

This works:

This doesn't:

I haven't bothered to find why, but that is surprising to me. (Note that here the enctype is specified as "multipart/form-data", which may or may not be related)

Update: It is not related.

The real culprit, as best I was able to reconstruct is because of this piece of code:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.MapRoute(
        "Default", 
        "{controller}/{action}/{id}", 
        new {controller = "Home", action = "Index", id = String.Empty} 
        );
}

It looks fairly innocuous, doesn't it?

Except that this means that when ASP.Net MVC looks for a matching value for the "id" parameter, it will only look in the route parameters, and not look at the request parameters.

I found this surprising, to say the least.