Scott Williams’s Ramblings

Part of writing software is that you encounter bugs, some pedestrian, some pretty obscure. When I encounter the latter, I like to write about them, just to help guide the way for the next person stuck on this.

I have been trying to get some existing WCF Services up and running under IIS on Windows 7, but was getting the following error:

HTTP Error 404.17 - Not Found
The requested content appears to be script and will not be served by the static file handler.

My understanding was that IIS was able to see the file, but didn’t know what to do with it; there wasn’t a proper handler associated with the .svc extension on the URL.

The weird thing was that I had specifically defined this extension in my web.config, and it was showing up in the Handler Mappings in IIS! It should have been using: C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll but was not.

I banged my head on the wall for a while, took some Advil, and sat back down. A Co-worker sent me some of his machine configurations, which spurred me into the answer. I was using Windows x64, and the app had originally been written on a 32-bit system.

The correct dll to handle the extension is in the Framework64 folder. I changed my path to: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll and the service was loaded.

So, the moral of the story is that you really need to understand that a 64-bit machine has a couple of configurations that are different than a 32-bit one.

Alright kids, buckle your seats because we’re about to drop some science. One of the core features of ASP.NET MVC is extensibility, and in this post I’m going to show how extensible it can be. You can provide significant functionality to your codebase and still allow it to be small and flexible.

Read On

Say you have a class with a property that’s a string. Using object initializers you can do this little nugget:

Product p = new Product { ProductName = Console.ReadLine() };

It will work as you’d expect (prompt you for input, then assign it to ProductName). However, that’s pretty easy to miss when you’re quickly scanning code. I’m generally in favor of fewer lines of code, but in this case it would be good design to just break this into two lines.

Mapping data between types on a Web Service can be a collosal pain. There are various frameworks out there that can speed things up, but sometimes you just need to do it by hand. Fortunately some of the features introduced with C# 3 can help speed things up.

Say the type on the server looks like this:

class ServerType {
    public int ProductId { get; set; }
}

And your client type looks like:

class ClientType {
    public int Id { get; set; }
}

[This is a gross simplification, typically the types have more differences, but it gets the point across.]

Let’s say that the web service takes a List<ServerType> as one of its parameters too. Typically before C# you would need to do something like this:

public List ConvertClientList(List<ClientType> clientTypes) {
    List serverTypes = new List<ServerType>();
    foreach (ClientType clientType in clientTypes) {
        ServerType serverType = new ServerType();
        serverType.ProductId = clientType.Id;
        serverTypes.Add(serverType);
    }
    return serverTypes;
}

Ugh. That is far too much code and typing. Fortunately we can drop that to a one-liner with LINQ and Class Initializers:

var serverTypes =
    clientTypes.Select(c => new ServerType { ProductId = c.Id }).ToList();

Bingo. Let’s walk through this a little bit just to be clear. On every item in the clientTypes List, the Select function is being called. It is instantiating a new ServerType object and setting the ProductId property. The default payload of the function in select is to return the expression, hence the lack of a ‘return’ statement; it is implied. Select returns an IQueryable by default to allow more chaining of expressions. Here we don’t need to do that, so we convert the whole thing back to a List.

The Select function is very powerful. It let’s you transform a collection of objects of one type to something else entirely. The result doesn’t even have to be a known type! For further magic on Select, read this article.

Disclaimer: I have not worked as a full time software tester, so this point of view is from a developer who would love to see the following qualities in QA personnel that I work with.

Say you had an object model that was generated from a database like so:

public class Lecture {
	public List<Speaker_Lecture> Speakers { get; set; }
}

public class Speaker_Lecture {
	public Lecture Lecture { get; set; }
	public Speaker Speaker { get; set; }
}

public class Speaker {
	public string Name { get; set; }
}

Unfortunately, you’re stuck with that semi-ugly Speaker_Lecture model, and cannot change it. How would you get a list of all the Speakers for a set of Lectures?

Without LINQ, I imagine you’d create an empty List of Speakers and then have nested foreach loops to go through the list of Lectures, and then the Speakers within those Speaker_Lectures. Kind of ugly.

But with LINQ, you can collapse it to one [long] line:

var speakers = lectures.Select(
    lec => lec.Speakers.Select(spk => spk.Speaker))
    .Aggregate((list, next) => next).Distinct();

And you’ll get a nice happy IEnumerable of Speaker.

What is it doing there? Well, the first select extracts the Speaker_Lecture objects from the lectures. Then, it extracts the Speakers from those objects. However, at this point, the Select function gives us a collection of a collection, which we do not want. Fortunately, Aggregate will walk through those collections and flatten them out to a single list. Distinct removes any duplicates.

Recently, I had a Dictionary<string, string> object that I wanted to display as a single string, essentially like “[key1] => value1  [key2] => value2” and so on. Back in the olden days of .NET 2.0 and prior, you could have just done it like this:

string s = ""; // Or a StringBuilder
foreach (string key in dict.Keys) {
    s += string.Format("[{0}] => {1}  ", key, dict[key]);
}

This was my first thought to solve the issue, but I wasn’t exactly thrilled with it. I knew that in Python this would be a relatively simple reduce (as in Map/Reduce) operation and could be done on one line.

I thought that there must be a similar way using LINQ to get a one-liner. There is no Extension Method called “Reduce,” but the equivalent is Aggregate. The only catch is that for the Aggregate function, the generic accumulator type must be the same as what is in the dictionary, which in this case was a key/value pair.

The solution is still technically a one liner, but I split it up for readability’s sake. You can use Select to munge the pair into a single string.

IDictionary foo; // Fill foo in here
string prettyPrint = foo.
    Select(pair => string.Format("[{0}] => {1} ", pair.Key, pair.Value)).
    Aggregate((acc, s) => acc += s);

If you have a bit of a Functional programming background, this makes sense, though if you do not, it may not be as readable.

I like frameworks. I spent far too much time in my programming infancy reinventing the wheel, and I don’t want to ever have to write more code than I have to again. Thus, I like relying on frameworks to take the tedium out of certain parts of the craft.

However, a problem arises when you don’t know what that framework is doing. Recently I spent many hours tracking down one specific bug that needed a single line changed to fix. In this specific case it was in an ASP.NET WebForms app. A <button> tag was used to make some fancy ajaxy calls via jQuery and PageMethods and the onclick event. The problem was that the form that was supposed to be displayed only appeared for a few seconds, then vanished again.

I poured through the code, set many breakpoints, broke out both Firebug and the Safari debugger (both proved useless due to the actual problem). Despite all of this, I still couldn’t figure out what the heck was going on. Finally, after I was ready to jump off the parking garage, the light bulb clicked on.

The <button> tag behaves like <input type=”submit” />; it sends a postback. And since the form was wrapped in an UpdatePanel, it was executing both the jQuery ajax, as well as the ASP.NET ajax, which were clobbering each other. In Firefox, the jQuery code finished first, and was then overwritten by the Page_Load from the UpdatePanel, causing our freshly rendered form to go away.

Changing the <button> to <input type=”button” /> fixed things. There are plenty of other fixes for this issue, but that’s what we used.

ASP.NET WebForms and ASP.NET Ajax like to abstract many of the “complicated” web development concepts away from the developer. I’m not going to comment on whether this is a good or bad thing, but it can present issues if you are using some mechanism and are not aware of what is going on under the hood. These problems usually don’t even manifest until late in a project- when the bosses are breathing down your neck and wondering why the app isn’t finished yet.

Does this mean we should abandon frameworks entirely and code everything in C (or assembler)? Certainly not, but if you are going to use that extra super duper happy UpdatePanel, you had better know what it is going to do to everything inside of it.

I gave two talks at Desert Code Camp this last weekend on ASP.NET MVC. The talks went well enough, though the time was far too short to cover everything I wanted to. I did get requests to share the code created during the sessions. So, here it is, for the most part.

http://krazyyak.com/sogeti/DemoBlog.zip

I say “for the most part” because it’s not the exact same stuff written during the presentation. I went through, cleaned up, and commented many of the methods and functions in everything.

The stuff with StructureMap is still pretty rough; I’m not a StructureMap expert, but I want to learn more about it. I’ll hopefully be able to blog about it in July.

As far as a disclaimer, this code is public domain and should be only used for demonstration/educational purposes. I offer no warranties on it, etc. Actually using it for a blog engine is probably a bad idea.

Feel free to discuss it here and ask questions.

In the project I am currently working on, we are using JavaScript and jQuery in just about everything. One of the frustrations that I have been seeing is that I’ll render a view representing an object, but also want a JSON version of that object to manipulate. I am also quite anal when it comes to keeping my code clean and separating the concerns; I did not want to have JavaScript strewn throughout my HTML or vice versa.

I considered a couple of options. The first just involved making an AJAX call to the server and having it return a JsonResult. This is clean, but I did not want to effectively double my calls to the server.

I also considered extending the MVC framework and writing my own ActionResult class that returned both HTML and JSON. However, that also “felt” wrong; like I was short-circuiting the framework. I would have had to rely on JavaScript on the client side to parse the resulting object and place the HTML, not something I want to be doing with all of my views.

I let it sit on the backburner for a while, and then today came up with a pretty good solution. It’s not ideal, but it works well enough for me. I created a simple HtmlHelper extension that just dumps the JSON out into a variable:

using System.Web.Script.Serialization;

    public static class JsonExtensions {
        public static string Json(this HtmlHelper html, string variableName) {
            return Json(html, variableName, html.ViewData.Model);
        }

        public static string Json(this HtmlHelper html, string variableName, object model) {
            TagBuilder tag = new TagBuilder("script");
            tag.Attributes.Add("type", "text/javascript");
            JavaScriptSerializer jsonSerializer = new JavaScriptSerializer();
            tag.InnerHtml = "var " + variableName + " = " + jsonSerializer.Serialize(model) + ";";
            return tag.ToString();
        }
    }

You call it from a page like so:

<%= Html.Json("foo") %>
<%= Html.Json("bar", Model.Something) %>

This is not an ideal solution, you are still technically putting JavaScript in the HTML. But, it does not make an extra call to the server, and the markup in the IDE is still very clean.

Another approach I considered was to have an Action that returned a JavaScriptResult that consisted of the same thing. You could then add a script tag like:

<script type="text/javascript" src="/javascript/MyObject/1000">

The catch though is that it would cause more overhead, especially if the app was designed in such a way that the retrievals are expensive (ours is).

I’m still ruminating on that perfect scenario, but for now I’ll be doing it this way.