ASP.NET MVC Ajax CSRF Protection With jQuery 1.5

Wow, what a mouthful that title is! Anyways, if you can decipher the title, then you are in the right place. While working on Epic Win Hosting I decided that I wanted to put some groundwork in place to allow for a much more dynamic site in the future. As a result of that choice, I used Backbone.js for a good portion of the page interactions. If you haven’t used Backbone, then you owe it to yourself to go check it out. I’ll also be sure to blog about it in the near future.

Since I decided to do a good portion of the UI using backbone, and many of the forms that we post use the jQuery forms plugin, I wanted to make sure that we were protected from CSRF attacks that might come in via Ajax calls. Also, since Backbone.js uses HTTP verbs such as DELETE and PUT, I decided that I wanted the same CSRF protection to work for those as well.

Since the default ASP.NET MVC CSRF protection only works with form posts, I knew I couldn’t use it. But at the same time, I didn’t want to develop my own solution, since that is probably almost as dangerous as not doing it at all. Unless you really know what you are doing, you probably want to avoid writing too much security related code. So instead of implementing it myself, I decided to do some surgery.

I knew that I wanted my CSRF protection to work for any kind of data. So if I did a normal form post or posted some raw JSON data, I didn’t want to have to do things differently. So I knew I couldn’t put the CSRF verification token in the payload of the request in the way that ASP.NET MVC does it (In case you didn’t know, it renders as a hidden field on a form and posts in a normal manner). So instead, I decided to take the Rails approach, and shove the CSRF info into the headers of my Ajax request.

Sidenote:
If you’ve seen the posts about the CSRF vulnerability in Rails recently, don’t worry. The problem with Rails, as far as I can decipher, was that they weren’t requiring the header token to be passed during Ajax calls, instead relying on the same-origin limitations built within browsers to assume that Ajax calls were valid. There appears to be a bug in Flash that allows an attacker to get around this.
Since jQuery 1.5 had come out just recently and I had been drooling over its Ajax rewrite, I knew that this was the perfect time for me to get some good use out of it. jQuery 1.5 introduced a new feature called “Prefilters”, in a nutshell, what prefilters allow you to do is to change the request in some way before it is sent to the server. This would be a perfect place for me to shove my CSRF data into the request!

WARNING: Doing the following may lead to tears and tiny kittens getting hurt…proceed at your own risk.

The first thing I had to do was to rip the anti-forgery token code out of ASP.NET MVC. I couldn’t use the version in MVC 3 because the anti-forgery code was pulled out and put into a non-OSS library. Boo! But, since the MVC 2 code was released under MS-PL (thanks for the tip Phil!), I can legally do this, and more importantly, tell you about it! Thankfully the anti-forgery code is not really woven too deeply into any other classes, so it was easy enough for me to pull out. I went ahead and renamed all of these classes so that I wouldn’t get them confused with the classes in the MVC framework itself.

The Html Piece

I then had to create my own HTML helper to write out the anti-forgery token into the page. I did this by copying the Html.AntiForgeryToken helper and replaced the content with my own classes. The code in the normal anti-forgery helper renders a hidden field, but we don’t want that. So I modified the helper to instead render a meta tag that we can put into the head of our HTML document.

This code renders a html hidden field, but honestly, we don’t really want that. So we need to go into the AntiForgery class and modify it to return a meta tag that we can throw into our header:

?
1
2
3
4


@Html.AjaxAntiForgeryToken()

Easy stuff. We can just put this code in your master page or your root layout page, wherever your html head is located.

The jQuery Piece

Now we need jQuery to grab this CSRF token and use it in our requests. Due to the fancy new jQuery prefilters, this is actually a tiny little chunk of code:


$.ajaxPrefilter(function (options, originalOptions, jqXHR) {
var verificationToken = $("meta[name='__RequestVerificationToken']").attr('content');
if (verificationToken) {
jqXHR.setRequestHeader("X-Request-Verification-Token", verificationToken);
}
});

Very clean, and we don’t have to mess with any of our requests (you could technically do this in jQuery 1.4 if you used ajaxSetup’s “beforeSend” option). In fact, most of my requests are going through Backbone.js and so I don’t have access to them at all! In this chunk of code, we just grab the CSRF token and shove it into a header. Couldn’t get any easier! We don’t care what kind of request it is, because we can always shove the header in, it is up to the action what to do with it.

The Backend Piece

Now that we have this verification token getting passed in the header, we just need to verify this token somewhere. The first thing that I did was to copy the ValidateAntiForgeryTokenAttribute class.

Inside of the ValidateAntiForgeryTokenAttribute there is a line that looks like this:


string formValue = context.Request.Form[fieldName];

All we need to do is to grab the value from the header instead of the field:


string formValue =
context.Request.Headers[EpicAntiForgeryData.GetAntiForgeryTokenHeaderName()];

Now we can let the class do the rest of the work.

And Finally…

Now all you have to do is put your new AjaxValidateAntiForgeryToken attribute on your controller actions that you want to validate. When your Ajax event fires, jQuery will append the token to the call then when it hits your controller action, the attribute plucks the value out of the header and the cookie, then it does its magic. You just have to keep in mind that you can’t use the same classes for posting forms regularly anymore, since the header won’t get appended to a non-ajax post.

What ASP.NET MVC Could Learn From Rails

Most developers that are interested in bettering themselves really do want to hear both sides of the story. They want to understand the strengths of other platforms, not so they can move, but so that they can understand how to make their own framework/platform better. When you read this post, I hope you will read it with that in mind. I hope you will see this not as me criticizing your platform, or someone else’s work, but instead as me saying “here is what I think is cool about this other platform, how can your platform get in on that?”

A Tale Of Two Frameworks

There was a time when Ruby on Rails was the hottest thing on the block, and many ASP.NET developers pined for the day when we could leave behind controls and viewstate and move into the glorious world of web development. Cause what we were doing wasn’t web development, don’t kid yourself. Then ASP.NET MVC came out, and a lot of people (myself included) jumped on that bandwagon and have never looked back.

I have been very happy with ASP.NET MVC for a long time. It gives me a simple to use framework that gets out of my way and lets me write real web applications. And I love it! But there is just one problem, websites are quite often complex beasts and ASP.NET MVC only solves a small part of the puzzle. Every project I start I have to pull in a membership system, migrations, an ORM, an IOC container, logging, testing framework, etc… I have to find and plugin all of these tools every time I want to do build another site. (Nuget has helped with the finding and integrating part immensely!)

I guess this is to be expected though, ASP.NET MVC wasn’t really meant to be an opinionated framework. They wanted to produce a framework which would have broad appeal across the hundreds of thousands of .NET developers out there. Not an easy task! They also wanted a smaller framework that they could release in short cycles. Based on their goals, I’d say that they have done a great job.

But because of this they couldn’t just pick different frameworks and include them as defaults. First of all, there were few choices that would not have been controversial. Secondly, if they had made controversial decisions, the framework would have been rejected by early adopters and not seen the adoption that it has now.

Creating a generic framework is fine, as long as you understand what you are giving up to get there. The power of frameworks like Ruby on Rails, Django, or CakePHP is that they span the whole stack. While this might lock you down to doing things in a certain way, in the end the benefit derived from the tight integration is very often worth it.

Walking Through The Problem

In order to demonstrate this, let’s take the example of authentication in a web application. In ASP.NET MVC we have the normal ASP.NET authentication mechanism which we can leverage in order to have users and roles, but as most of us know, a lot of people end up rolling their own or looking for an outside solution. Why? Because the user is part of our domain, and the ASP.NET authentication system forces us to use their tables, stored procs, db deployment tools, etc… It is clunky and not extensible at all. So let’s say we want to build an alternative, what would we have to do?

The first we need is a model that represents a user, we can either include this in the framework, or maybe just let the user define the class that they need, and then implement an interface for us to interact with. Okay, so how do we get the tables in the database? Well, we could create some scripts and put them in the project, then the developer can run those to create the user tables. That doesn’t seem very awesome, what if they aren’t running SQL Server? Yes, some of us do use .NET without SQL Server. What if they need to automate creating the database for testing? Also, how much does it suck to have to manually run the scripts on every machine you need to deploy to?

Well, we could write code to connect to the database and run the DDL to create a table. That would be more automatic. But again, what database are they running, which connection do we use, how do we let the user modify their user object to fit their needs if we need to create the table? Arrrrgh! Okay, let’s just punt on that and say that we will just create scripts for a few databases, and let the user modify and then run them manually, or integrate the scripts into their build process. That sucks.

Now how do we get the user model in and out of the database? We don’t really know how the developer is going to be doing data access, so we can’t pull the user from the database within the framework, we will have to force the user to implement a class that we can call and get users, in the same way that the provider model is currently implemented in .NET. This isn’t terrible, just inconvenient.

So now we are at the point where we have a database table, and we can pull users from the database. The only problem is that the developer has had to implement an interface on his user object, manually edit and run scripts, implement a persistence mechanism (most likely an ORM), and implement a provider to allow us to perform CRUD operations on users. And we are just getting started! What about creating a controller, views, adding routes, validation, sending e-mails, etc…? There are a lot of pieces that go into a successful authentication mechanism, this isn’t easy stuff.

In the ASP.NET MVC world, all of these problems may seem overwhelming. Sure, we could implement a full solution, but we’d have to make a lot of assumptions and force the user into tools that they might not be using. Or we include our own tools, and bypass their stack in the same way that the ASP.NET providers work. This disconnect is what frameworks like Sharp Architecture try to solve, but third party libraries could never depend on frameworks like this until their adoption reached a critical mass. Otherwise they would be spending a lot of effort, for every little return.

How Would You Do This In Rails?

In Rails there are a few different frameworks available to do authentication. The one that I have used is Devise. In order to use Devise, the first thing we would do is to add the gem to our Gemfile (a gem is like a NuGet package, if you don’t know what a NuGet package is, go here) with a line like this:

?
1
gem ‘devise’, ‘~> 1.3.4’
Then we just run “bundle install” and the gem is installed into our project. Now we have to configure devise. We can run this command (you can type out ‘generate’ instead of ‘g’ if you want):

?
1
rails g
And it will show you all of the generators available to you. You will see a section for Devise. Devise is able to hook into these generators and do some really powerful stuff. We can see from this list that there is a generator for devise called “devise:install”. We can run that:

?
1
rails g devise:install
Now Devise has installed its configuration file into your app, and you are almost ready to go. You’ll notice there is another generator just called “devise”, if we run that it tells us to give it a model name so it can generate a User model for you. Because everything in Rails has a place, you simply run this command:

?
1
rails g devise User
And it drops User model into your /app/models folder, generates a migration for you, and puts routes into your routes.rb file. Now all I have to do is run my migrations (I can edit the migration or create another migration to edit my user table, allowing me to completely customize my user):

?
1
rake db:migrate
And now my database tables are created and everything is ready to go. I can put this on my controller:

?
1
before_filter :authenticate_user!
And now that controller will redirect me to a login/signup page, allow me to create an account, send confirmation e-mails (if I want), etc… I also have a number of helper methods that I can run like “user_signed_in?” or “current_user” in order to interact with users on a more fine grained level.

What Happened There?

Well, you saw the power and productivity of a full stack framework. Devise knows what tools you are using (or how to integrate with them), and where everything goes. Because of this we don’t need to tell it how to create a model, create database tables, save/retrieve users from the database, how to connect to the database, how to send e-mail, etc… These are all configuration and sensible defaults that have already been setup in your application.

And for anything that isn’t automated, there are Rails generators that we can hook into to create config files, add routes, views, and any other assets. We are able to do this because most everything has a place in a Rails app. Rails is a very opinionated framework, and it shows. If you follow the “Rails Way” then things will be smooth and super productive.

How Do We Make ASP.NET MVC Better?

That is a very difficult question. You see, the Rails community long ago agreed to go along with the “Rails Way” in exchange for increased productivity and integration. I’m not sure that the .NET developer community would respond favorably to the kinds of changes which would be required to bring ASP.NET MVC up to the level of integration that Rails enjoys.

This doesn’t mean that they can’t come close though. One thing they could do is start to favor certain tools more in the framework. Start to setup conventions and tools that developers are expected to use, and let them know that if they stray, they are on their own. However, the problems here are obvious. The tools that are going to be made the defaults will be Microsoft’s own tools, like Entity Framework or MEF. This could create some serious friction with the developer community if they start to integrate too tightly with these tools.

An MVC Uber-Framework?

Another interesting path would be to see some full stack frameworks spring up on top of ASP.NET MVC. Maybe Microsoft could implement another framework on top of ASP.NET MVC which would be fully integrated, but could be tossed out if you just wanted just the underlying web framework. As long as this framework was simple and powerful enough, you would probably see a large number of developers jump on board, which would give OSS creators a reason to integrate with it. On the MS platform, a tool like this usually has to come from within Microsoft itself, otherwise it has an extremely hard time gaining any momentum.

I can see a lot of eyes rolling and hands shooting up after that last paragraph, but hear me out. If Microsoft continues down the path they are now, and they start integrating things like Entity Framework and MEF as defaults, but not truly integrated, then all we are going to get is a bunch of code generation when we start a project. This isn’t going to help OSS developers extend the framework. But, if they could instead tease out the web layer from the rest, and build a more integrated application stack on top of it, that would go a lot further. I’d love to hear people’s feedback on this.

Will It Change?

I don’t know! ASP.NET MVC is a fine framework. I just don’t feel like it is as productive as it could be. Good, solid, testable web development just doesn’t have to be as hard as it currently is with ASP.NET MVC. ASP.NET MVC has given us a good start on the web layer, but hooking up our applications to this front end is often repetitive, clumsy, and cumbersome. All I want is for my whole stack to play nicely together, is that really too much to ask?

Read hidden field value in asp.net from jquery

Often we are confused about how to read values set in asp.net HiddenField from jquery and use the values in the web form. Many-a-times we see the threads over the asp.net forums about the difficulties associated with reading asp.net HiddenField values. I have tried to give easy and fast way to read values and set values of hidden filed in asp.net using jquery.
You may first download the latest jquery file from jquery.com.
asp.net webform – design page
view plainprint?

$(function () {
//reading hidden field value
var mySite = $(\’#HiddenField1\’).val();
//displaying the value in an asp.net Label control
$(\’#lblSiteName\’).html(\’My site is: \’ + mySite);
//setting value of HiddenField control
$(\’#HiddenField1\’).val(\’New site is: http://asp.net\’)
});

asp.net webform – code page (in c#)
view plainprint?
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
HiddenField1.Value = “http://dotnetspidor.blogspot.com”;
}
}
Known issue
If you have put the asp.net HiddenField control below the script tags, you may end up reading ‘undefined’ values. To solve the issue, I recommend putting the hidden fields at the top of the page just below the form tag.
Further, if you are using asp.net Master Page, please make changes in the jquery codes respectively. In such case, I recommend the following syntax:
var mySite=$(‘[id$=HiddenField1]’).val();
The system $= means the value that end with HiddenField1. This works since you usually see the id HiddenFiled1 used with master page rendered as ctl00_ContentPlaceholder1_HiddenField1.

Happy programming!

Introduction to Mixins For the C# Developer

If you are a C# developer then you may keep hearing about all the cool kids from Smalltalk, Ruby, Python, Scala using these crazy things called mixins. You may even be a little jealous, not because you want the feature, but because they have a feature with an awesome name like “mixin”. The name is pretty sweet. And in fact, it is fairly self-explanatory since mixins are all about “mixing-in behaviors”.

It is actually an Aspect Oriented Programming (AOP) term which is defined by wikipedia as:

A mixin is a class that provides a certain functionality to be inherited by a subclass, but is not meant to stand alone. Inheriting from a mixin is not a form of specialization but is rather a means to collect functionality. A class may inherit most or all of its functionality by inheriting from one or more mixins through multiple inheritance.

No wonder people are confused! That isn’t exactly clear. So let’s try to clear it up just a tiny bit…

Let’s say that we have a C# class that looks like this:

public class Person{
public string Name { get; set; }
public int Age { get; set; }
}
Looks good. And we have another C# class that looks like this:

public class Car{
public string Make { get; set; }
public string Model { get; set; }
}
Mmmmkay. These classes obviously don’t have anything to do with one another, and hopefully they aren’t in the same object hierarchy. What if we need to do something like, say, serialize to XML? In .NET we would normally decorate the type with a SerializableAttribute and then we would fire up an instance of the XmlSerializer by abstracting it into a method like this:

public static string SerializeToXml(Object obj)
{
var xmlSerializer = new XmlSerializer(obj.GetType());
using (var memoryStream = new MemoryStream())
{
using (var xmlWriter = new XmlTextWriter(memoryStream, new UTF8Encoding(false)))
{
xmlSerializer.Serialize(xmlWriter, obj);
}
return Encoding.UTF8.GetString(memoryStream.GetBuffer());
}
}
So now when we need to serialize a class, we can just do this:

string xml = XmlHelper.SerializeToXml(person);
That isn’t too bad, but what if we wanted to do something like this:

string xml = person.SerializeToXml();

In C# 3.0 and later we can introduce an extension method to get exactly that behavior:

public static class XmlExtensions
{
public static string SerializeToXml(this Object obj)
{
var xmlSerializer = new XmlSerializer(obj.GetType());
using (var memoryStream = new MemoryStream())
{
using (var xmlWriter = new XmlTextWriter(memoryStream, new UTF8Encoding(false)))
{
xmlSerializer.Serialize(xmlWriter, obj);
}
return Encoding.UTF8.GetString(memoryStream.GetBuffer());
}
}

}
Now you see what we are doing here, we are creating an extension method on Object so that we can use this on any class. (Well, it really is just a compiler trick, but it “appears” that we have this method on every class) We are performing a very weak form of a mixin, because we now have a similar behavior for any object, even if it doesn’t necessarily have the same inheritance hierarchy. So, why do I say that this is a “weak” mixin? We are sharing behavior across multiple classes, right?

Well, I say it is “weak”, but I really should say that it is not a mixin at all because true mixins have state as well as methods. For example, in the above scenario, let’s say we wanted to cache the result of the serialization so that the next time we called it, we would get the same result? This obviously isn’t something you’d want to do unless you had change tracking, but in the C# extension method, this is impossible. There is no way to associate state with the particular instance.

So how do other languages support this behavior? Well, Ruby supports it with a concept called modules which look very similar to classes and allow those modules to be “included” with classes. Ruby even allows you to apply mixins at runtime, which could be a very powerful, albeit potentially confusing, feature. Python solves the problem by allowing multiple inheritance, so I guess you could say that they aren’t really mixins either. It solves all the same problems as mixins though, but it does add a bit of complexity to the implementation (See the Diamond Problem).

In terms of being similar to C#, the Scala solution is the most interesting. Perhaps because Scala is a statically typed and compile-time bound language (for the most part), and so it has some of the hurdles with implementing mixins that C# would face. In Scala the feature is called “traits” and traits can be applied to both classes and instances during construction.

I’m not going to show you the Scala implementation of traits, but what I am going to do is make up a syntax for C# traits so that we can implement the behavior we want above. So first we are going to have to decide on a keyword for this new construct, and I am going to just use the Scala “trait” keyword. In Scala traits look like classes, because that is essentially what they are. They are classes which are not inherited from, but rather “applied” to another class. In fact, traits can even descend from abstract classes.

Nothing Past This Line is Valid C#!

So our C# trait might look something like this:

trait XmlSerializer{
public string SerializeToXml()
{
var xmlSerializer = new XmlSerializer(this.GetType());
using (var memoryStream = new MemoryStream())
{
using (var xmlWriter = new XmlTextWriter(memoryStream, new UTF8Encoding(false)))
{
xmlSerializer.Serialize(xmlWriter, this);
}
return Encoding.UTF8.GetString(memoryStream.GetBuffer());
}
}
}
Neato. We could then take this trait, and apply it to our class like using the “with” keyword:

public class Person with XmlSerializer {
public string Name { get; set; }
public int Age { get; set; }
}
Cool, so we have replicated the behavior of the extension method. But now how about that caching? Well, we wouldn’t even need to touch the Person class, we would only have to change the trait:

trait XmlSerializer{
private string xml;

public string SerializeToXml()
{
if (String.IsNullOrEmpty(xml)){
var xmlSerializer = new XmlSerializer(this.GetType());
using (var memoryStream = new MemoryStream())
{
using (var xmlWriter = new XmlTextWriter(memoryStream, new UTF8Encoding(false)))
{
xmlSerializer.Serialize(xmlWriter, this);
}
xml = Encoding.UTF8.GetString(memoryStream.GetBuffer());
}
}
return xml;
}
}
Nice. Now if you think about it, if traits had the ability to support abstract members, then you wouldn’t need interfaces at all, would you? Well, it just so happens that Scala doesn’t have interfaces, and uses traits in this exact capacity. If you declare a mixin with all abstract methods, then have an interface. It becomes even more powerful when you declare mixins with abstract methods that are used by concrete methods that are also declared within the mixin. Head hurting yet? It is some pretty powerful stuff, and should be used as any powerful tool should be, judiciously.

One final note about Scala traits, which I mentioned earlier, is that they can be applied to instances during construction. This is an interesting behavior because it allows individual instances of classes to have a trait applied. If you think about trying to apply an interface at runtime, then you will realize that any trait that you would apply at runtime would have to contain no abstract methods, otherwise you would have no way to tell if the class implemented the methods that were being applied. This is why Scala only allows traits to be applied at construction of an instance, this way Scala can do checking at compile time to determine if the class implements all of the abstract methods that are needed. So, in C# this syntax would look something like this:

var person = new Person() with XmlSerializable;
And if we needed to pass this into a method, we could do this:

public string DoSomething(Person with XmlSerializable person){
return person.serializeToXml();
}

Checking XML for Semantic Equivalence in C#

I was writing a bit of code for a small project and it was creating some XML that I need to pass to another application. So in order to test this functionality, I needed to compare the XML generated by my API against some hard coded XML. I started off with this:


var expectedXml = @"testvalue";

var actualXml = MyAPI.DoSomeStuff().GenerateXml();

Assert.Equal(expectedXml, actualXml);

But I quickly found out that this wasn’t going to scale. Once the XML got too large, it would carry over too far making my tests read horribly. So, I did this:


var expectedXml = @"

testvalue

";

var actualXml = MyAPI.DoSomeStuff().GenerateXml();

Assert.Equal(expectedXml, actualXml);

The problem was that now the XML wasn’t equivalent. Well, it is semantically equivalent, it just isn’t equivalent for a string comparison. The reason for this is that all of that extra white space and EOL characters screws up the comparison. You might be thinking, well, just strip out white space and EOL characters. It ain’t that easy. What happens when that white space is inside of an xml element. Well, at that point it becomes meaningful for comparison purposes.

So I didn’t want to write my own comparison code (who wants to write that?) so I started hunting around. Since I was already using the .NET 3.5 XElement libraries, I started looking there first. I came across a little method on the XNode class called DeepEquals, and guess what, it does exactly what I want. It compares a node and all child nodes for semantic equivalence. I’m sure that there are probably a few gotchas in there for me, but after preliminary tests, it appears to work perfectly.

I created a little method to do my XML asserts for me:


private void AssertEqualXml(string expectedXml, string actualXml)
{
Assert.IsTrue(XNode.DeepEquals(XElement.Parse(expectedXml), XElement.Parse(actualXml)),
String.Format("{0} \n does not equal \n{1}", actualXml, expectedXml));
}

There you have it. It loads the expected and actual XML into XElements and then calls “DeepEquals” on them. Now I can write my XML to compare is the most readable fashion and not worry about how they are going to compare.

Overloading Dynamic

If you’ve been checking out Visual Studio 2010 (or reading my blog) then you might have noticed the new “dynamic” keyword in C# 4.0. So what is the dynamic keyword? The dynamic keyword allows us to perform late-binding in C#! What is late-binding you ask? Well, that means that operations on the variable aren’t bound at compile time, they are instead bound at runtime. By “bound” I mean that which particular member to invoke is decided while the application is running, not during compilation.

In the past, you might have seen examples of dynamic using a sample like this:


dynamic value = "test string";

value.DoSomethingSuper();

Now obviously the String class does not have a method called “DoSomethingSuper”, but this code will compile. It will blow up at runtime with an error saying that the string class does not contain a definition for “DoSomethingSuper”. If you want a more in depth look at the basic usage of the keyword, see the linked post above.

So Much Dynamicness

What is really interesting is that the dynamic keyword isn’t just for declaring local variables. We can use it for method parameters, return types, and almost anywhere that we can specify a type. Which means that we could actually write something like this (note that you might now want to, you could):


public static dynamic DoSomethingDynamic(dynamic dyn1, dynamic dyn2)
{
return dyn1 + dyn2;
}

Interesting. So this method does basically what we would find in any dynamic language such as Python or Ruby. I can call it like this:


DoSomethingDynamic(3, 5);

Or I can call it like this:


DoSomethingDynamic(3.5, 5.2);

Or even like this:


DoSomethingDynamic("hello", "there");

And guess what, it works like you would expect. The first two calls are added, and the third call is concatenated together. It truly does allow you to have fully dynamic behavior in C#. We can even support fully dynamic classes with (ala method_missing) using DynamicObject.

An Overload Of Dynamic

But there is one little wrinkle that C# has to deal with that traditional dynamic languages like Ruby and Python don’t have to deal with. And that wrinkle is method overloading. Think about that, in a dynamic language, you don’t specify types on method parameters, so there is nothing to overload. The only thing that methods signatures are based off of is the number of parameters.

But C# still has types. And it has a dynamic type. Hmmmmmmm. That is interesting. So what happens when we declare the above method, but then we declare something like this?


public static dynamic DoSomethingDynamic(string dyn1, dynamic dyn2)
{
return "nope!";
}

Interesting. Method overloading with dynamic. Suddenly we are in a situation where we have to factor in dynamic as part of the process. So in the above, what happens? Well, thankfully they implemented it in the most obvious way. Types take precedence over dynamic. So if we have the above method, and call it like this:


Console.WriteLine(DoSomethingDynamic("hello", 5));

Then instead of picking the (dynamic, dynamic) overload, the C# compiler picks the overload that matches the most types. But what happens if we implemented these methods:


public static dynamic DoSomethingDynamic(string dyn1, dynamic dyn2)
{
return "string first!";
}

public static dynamic DoSomethingDynamic(dynamic dyn1, string dyn2)
{
return "string second!";
}

Looks like we’ve got a bit of a conundrum. If we call this method with (string, string) how would we know which method to call? Well, we can’t, and the C# compiler just throws its hands up and says “The call is ambiguous between the following methods or properties” Well that stinks.

The easiest solution would just be to implement an overload that implemented (string,string) and then you couldn’t find yourself in this situation. So, you may be thinking, well, wouldn’t this always be caught by the compiler?

Can The Compiler Save Us?

Well, let’s consider the situation where you have an overload with (dynamic, dynamic), (string, dynamic), and (dynamic,string). Then we have some code that looks like this:


dynamic val1 = "test";
dynamic val2 = "test2";
Console.WriteLine(DoSomethingDynamic(val1, val2));


Ahhhhhhhhhh! Brain teaser. What do you think will happen? Well, we are dealing with all dynamic variables here, so this is going to compile. And when we run it, do you think that the method with the (dynamic, dynamic) signature will be called? That might make sense at first, but consider that dynamic variables perform method overload resolution at runtime. So, those variables are dynamically typed, but they are strings.

So what happens at runtime is that we determine that those variables are strings, and we try to find out what method overloads are available… and we find the ambiguity… at runtime! Here is the proof:

Did you happen to notice the references to “object” in the method signatures? Where did that come from? Well, it just so happens that dynamic isn’t really a type. It is just an object with a bit of extra behavior added during compilation.

Dynamic Is Special

So, if we were to look at the reflected code for this we would see that the two variable declarations look like this:


object val1 = "test";
object val2 = "test2";

Okay, but what about that special behavior we were talking about? Well that comes in where these variables are used. In this case we have two method calls. The first one is to DoSomethingDynamic and the next is to Console.WriteLine. In order to invoke these methods with dynamic variables we need to create these things called “call sites”. Call sites are merely objects that represent a call to a method which is created at runtime during the first invoke. These classes are what allow the method resolution and caching on each call to occur at runtime. They look something like this (truncated for brevity):


private static void Main(string[] args)
{
object val1 = "test";
object val2 = "test2";
if (o__SiteContainer0.p__Site1 == null)
{
o__SiteContainer0.p__Site1 =
CallSite<Action>.Create(...);
}
if (o__SiteContainer0.p__Site2 == null)
{
o__SiteContainer0.p__Site2 =
CallSite<Func>
.Create(...);
}
o__SiteContainer0.p__Site1.Target.Invoke(...);
}

The importance of this is that when you compile a method which has dynamic parameters but is being passes statically typed variables, there doesn’t really need to be any special behavior when the method is invoked. It is inside of the method where we are dealing with these dynamic paramters that we will start seeing CallSites get created. So, the method will look like this:


[return: Dynamic]
public static object DoSomethingDynamic([Dynamic] object dyn1, [Dynamic] object dyn2)
{
if (o__SiteContainer4.p__Site5 == null)
{
o__SiteContainer4.p__Site5 =
CallSite<Func>.Create(...);
}
return o__SiteContainer4
.p__Site5.Target.Invoke(...);
}

Hmmm, so when we are doing method resolution the (dynamic, dynamic) method just looks like (object, object)! So does that mean if we did this:


dynamic val1 = new Object();
dynamic val2 = new Object();
Console.WriteLine(DoSomethingDynamic(val1, val2));

That it would then call the method with the (dynamic, dynamic) signature? Well, yes it does. 🙂 Phew. And with that, we can now get a better picture of the implications of method overloading and our use of dynamic.

Reflecting

So, what does all of this mean? Why is it important? Well, it depends on how you look at it. Are you going to have to deal with method overloading involving dynamic very often? Probably not. Is it interesting to see how much thought and effort it takes in order to design a feature like this? You bet it is.

C# Closures Explained

Thanks to all of the functional goodness that was put into C# 3.0 we have a ton of power at our disposal. Unfortunately with a lot of this power also comes increased complexity. Programmers usually exacerbate the complexity problem, because unfortunately we often like to sound like we are smarter than we actually are.

We often like to use big words and lots of acronyms to scare away the neophytes. Oh crap, there I go again…

Anyways, one of these topics that is blindingly simple is closures. But I continue to see definitions that are as clear as mud to the average developer. Let’s go ahead and look at the Wikipedia definition of a closure:

“In computer science, a closure is a first-class function with free variables that are bound in the lexical environment.”

All clear, right? Well, if it is for you, then super… you can stop reading. But if not, and the next time this topic comes up you want to sound like Super Duper Computer Science Guy™ … then keep reading.

Sir, Your Functions Are First Class

So first, what is a “first-class function”? A first class function simply means that it is a function which your language treats as a first class data type. It means that you can assign a function to a variable, pass it around, and invoke it… just like a normal function. In C# we can create a first class function using anonymous methods:


Func myFunc = delegate(string var1)
{
return "some value";
};

Or we can do it using lambdas:


Func myFunc = var1 => "some value";

Both of those are functionally equivalent, and they just create a method that takes a string and returns a string. We can call that method by invoking the variable just like we would any method:

string myVar = myFunc(“something”);

This means that C# supports first class functions, yay!

Like My Variables Free

And so now we have first-class functions with free variables… And what, pray tell, is a free variable? A free variable just happens to be a variable which is referenced in a function which is not a parameter of the function or a local variable of the function. Okay, so it might look like this:


var myVar = "this is good";

Func myFunc = delegate(string var1)
{
return var1 + myVar;
};

Okay, so the anonymous delegate is referencing a variable that is in its enclosing scope. That variable isn’t a parameter, and it isn’t a local variable. So it is a free variable.

How Does It Work?

Well, the next question I always ask is, how does it work. And normally when people ask me this question I say “very carefully”, but that is only because I am annoying. In reality this is implemented in a more straightforward manner than you might think. What we are really doing here is binding up a method with some data and passing it around. Geez, I sure do wish we had something like that in C#… oh wait, we do, it is called a class!

You see, the C# compiler detects when a delegate forms a closure which is passed out of the current scope and it promotes the delegate, and the associated local variables into a compiler generated class. This way, it simply needs a bit of compiler trickery to pass around an instance of the compiler generated class, so each time we invoke the delegate we are actually calling the method on this class. Once we are no longer holding a reference to this delegate, the class can be garbage collected and it all works exactly as it is supposed to!