One thing that I try to advocate for many years is something that I should call DUX – Development User Experience. It means what it should mean : the user experience while you are doing your development.

We know that good software is hard to achieve and that most of the times people care only about what is visible. Crafting all the parts of the code in the right way is also important. The final end user experience is not the only part…

When you build frameworks or lower level components, even if their target is to be used by developers for higher level software, never forget that you still users! Your users are the developers working with your libraries.

Why do I complain? Because DUX is also an important part of the things you should care when you are building libraries. Framework developers usually though about:

• Try to provide the functions needed for the framework with a defined priority order (maybe defined by marketing guys…)
• Try to provide as much functions as possible because a richer framework is better than a framework providing a small set of things.
• Use some unit tests for internal use because most people do.
• Try to care about performance because a framework should do
• Try to fit as much as possible in the current ecosystem
• …certainly a lot of other things

I don’t know if all these things are the main reason I prefer to use open source libraries but in most cases these ones provide a slightly different results when they are realized with a decentralized unordered team:

• Functions are provided because people really needs them
• Delivery and functionalities are not subsidiaries of the market
• You can control functionalities with the unit tests provided and also see how it works (most of the times this is much more efficient than a regular documentation…)

Another good point with open source is that the good and the bad are automatically currated by the community. If your framework doesn’t deserve enough needs, if it is not enough clear about it’s usage and so on, it will die. Simple and efficient.

Frameworks have to be simple and fun to use. The .Net world has a lot of legacy stuff and history that tends to be complicated by essence because it takes its roots in entreprise. Alternatively languages like Ruby have things simple and expressive mostly because it is a developer to developer platform with pragmatism in mind.

Take a simple exemple. Suppose, you are building a shell application. You want to print messages and draw some lines to present things clearly, like this:

--------------------------------------------------------------
-- My App (c) 2013
--------------------------------------------------------------

In C# to build lines like this, you should write all the line in a string and print it like that:

Console.WriteLine("--------------------------------------------------------------");

Or with an iteration if you want to get more reusability :

public string Repeat(string pattern, int timesToRepeat)
	{
		string[] resultArray = new string[timesToRepeat];
		string result = pattern;
		for (int i = 1; i < timesToRepeat; i++)
		{
			result = result+pattern;
		}
		return result;
	}
...
Console.WriteLine(Repeat("-",80));

Instead of that, in the ruby world, you just do that:

puts "-" * 80

Which literally means : “put in standard output the string ‘-’ repeated 80 times. Which one sounds better for you?

Attention: please note that I am a .Net developer, we are just trying to talk about DUX, I am far than saying that Ruby is better than C#, yeap?

Btw, C# is a very high level platform and you have a lot of better things but that’s not the problem here. And In fact you should get more fluent things with a simple extension method like that:

public static string Repeat(this string pattern, int timesToRepeat)
	{
		StringBuilder sb = new StringBuilder();
		for (int i = 0; i < timesToRepeat; i++)
		{
			sb.Append(pattern);
		}
		return sb.ToString();
	}
...
Console.WriteLine("-".Repeat(80));

If you want a shortest way to achieve that you should also try:

String.Join("",Enumerable.Repeat("-",80))

Never forget that software is complicated by essence, so, don’t help this complication, try to make things clean even if your audience are developers!

In the Beginning

Managing binaries, dependencies and packages is such an important point that it is unbelievable  that it takes 10 years to get something like Nuget on .Net from Microsoft…

If you are running Mono for .Net web development on your Mac, it is not better regarding this point…

It was painful with MonoDevelop was the lack of support for Nuget.

We can do things by hand since v2 of Nuget (and before 1.7 btw) because you can use nuget.exe from mono command line but as it wasn’t integrated in solutions and projects it only helps you get binaries.

But let’s see how to setup Nuget on mono.

Install & configure Nuget

First download the las exe:

curl -O -L  http://nuget.org/nuget.exe

As Nuget is a .Net binary, you need to launch it via mono. If your installation is ok – and it should with the installer -, you are able to launch mono from every path in your shell. Note also that you need to specify the framework 4 runtime compatibility to make it work properly. So start the nugget exe, just execute this line:

mono --runtime=v4.0 Nuget.exe [then follow your nuget args]

In order to make this work from every, I should advise you to create an executable shell script that handle that.

In the folder you downloaded Nuget, copy it to /usr/local/bin:

cp Nuget.exe /usr/local/bin

Create a new file for your command, just name it nuget to get the same semantics:

touch nuget

Edit your file and just copy/paste this code:

#!/bin/sh
# add a simple 'nuget' command to Mac OS X shell under Mono
PATH=/usr/local/bin:$PATH
mono --runtime=v4.0 /usr/local/bin/NuGet.exe $*

Then give the correct execution rights to your file:

sudo chmod +x nuget

Then open a new console and try nuget (with a nuget help for exemple). The good point is that you can now use Nuget from everywhere!

You should also have a default config path working with NuGet, if you don’t have one created automatically, create a new fresh one

Local config should be stored at:

~/.config/NuGet/Nuget.config

Once you have this, you can play with nuget, with your own repositories too, but you still closed in the command shell.

If you work with MonoDevelop, you have to create your package folder, your packages config file and then reference your binaries manually. It’s not an ideal configuration but that’s better than nohting

Nuget support on Monodevelop

Install

This morning my eyes flashed after a tweet of David Fowler:

nuget monodevelop support

Ok, let’s see what is it about?

This is about an Addin written by Matt Ward. You can find the sources on his github 

You can build it and install it by your own, but Matt did the things well and provided a Monodevelop addin channel with this:

http://mrward.github.com/monodevelop-nuget-addin-repository/3.0.5/main.mrep

Click on Monodevelop, then Add-in manager. Select Gallery and manage repositories:

monodevelop addin repositories

Then click [Add] and paste the url:

Add repository definition url

Once you have it, you should get a new addin available:

new addin

Select it and install.

Let’s try a web project with Nancy!

First, create a new empty ASP.NET web project:

New empty asp.net project

Before playing with Nuget, Add a web.config file because it is not provided by default with this project template:

add web.config on monodevelop

Then you should try to run it but obviously you’ll get nothing.

Now, right click on references:

References with Nuget

So cool! We have now Nuget resources just here! Select Manage Nuget Packages.

You’ll have a box just as the one you use to use under Visual Studio (if you are in click-click mode instead of the Package manager console which is a Powershell host of course…):

Nuget box

Just start with typing ‘Nancy.host’, select ‘Nancy.Hosting.Aspnet’ then Add. You can see in the messages, that it handles correctly the download of Nancy.dll too.

Then add a new class to your project with your HomeModule with a simple test route:

using System;
using Nancy;

namespace Demo
{
	public class HomeModule : NancyModule
	{
		public HomeModule ()
		{
			Get ["/(.*)"] = _ => "Yes it works!";
		}
	}
}

That’s supposed to be enough for now. Build and run. Guess what? it doesn’t work.

Why? Remember that nuget installation features under Visual Studio are full of Powershell and transforming files are part of it. So, remember that when you install something with Monodevelop Nuget you don’t have the transforms like web.config updates!

UPDATE: Thanks to author Matt Ward that points an explication for that in the comments: “PowerShell is not actually needed for the web.config transform to be applied. It is not currently working in the MonoDevelop NuGet addin due to a bug. The addin is not detecting the project is a web project and ignoring the transform. Transforms for app.config files are currently working.”

Then open your web.config file and update  it  to setup Nancy handler:

<?xml version="1.0"?>
<!--
Web.config file for Demo.
The settings that can be used in this file are documented at
http://www.mono-project.com/Config_system.web and

http://msdn2.microsoft.com/en-us/library/b5ysx397.aspx

-->
<configuration>
<system.web>
<compilation defaultLanguage="C#" debug="true" targetFramework="4.0">
<assemblies>
</assemblies>
</compilation>
<customErrors mode="RemoteOnly">
</customErrors>
<authentication mode="None">
</authentication>
<authorization>
<allow users="*" />
</authorization>
<httpHandlers>
<add verb="*" type="Nancy.Hosting.Aspnet.NancyHttpRequestHandler" path="*"/>
</httpHandlers>
<trace enabled="false" localOnly="true" pageOutput="false" requestLimit="10" traceMode="SortByTime" />
<sessionState mode="InProc" cookieless="false" timeout="20" />
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
<pages>
</pages>
</system.web>
<system.webServer> <modules runAllManagedModulesForAllRequests="true"/> <validation validateIntegratedModeConfiguration="false"/> <handlers> <add name="Nancy" verb="*" type="Nancy.Hosting.Aspnet.NancyHttpRequestHandler" path="*"/> </handlers> </system.webServer>
</configuration>

Re-run it and now it works!

How easy to do .Net web!

Just to finish with that and show you how cool it is, relaunch Nuget manager and Add also Nancy.ViewEngines.Razor, jQuery and Twitter bootstrap.

Create Folders Views/Home and add a new html file called “Index.cshtml”

If you’re like me and never remember the right syntax for bootstrapping things, keep a visible bookmark to Twitter bootstrap page and take this one as exemple:

http://twitter.github.com/bootstrap/examples/marketing-narrow.html

Copy paste the source on your file as exemple, then update it to fit your config, paths and update the main block (just extracts with updated things ):

...
<title>Nuget on MonoDevelop</title>
...
<link href="/Content/bootstrap.css" rel="stylesheet">
...
<link href="/Content/bootstrap-responsive.css" rel="stylesheet">
...
<div class="jumbotron">
<h1>Nuget on MonoDevelop!</h1>
<p class="lead">
Get started with .Net Web dev on Mac with Monodevelop, Nuget, Nancy and Bootstrap!
</p>
<p>Generated at @Model.Generated by @Model.Author
<a class="btn btn-large btn-success" href="#">It's alive</a>
</div>

Then update your home module to return the Razor view and with a small model class to test passing things to the view

public class HomeModule : NancyModule
	{
		public HomeModule ()
		{
		Get ["/(.*)"] = _ =>
                   View ["Index", new HomeInfo (
                          DateTime.Now, "Rui Carvalho")];
		}
	}

	public class HomeInfo
	{
		public DateTime Generated { get; private set; }
		public string Author { get; private set; }

		public HomeInfo (DateTime generated, string author)
		{
			Generated = generated;
			Author = author;
		}
	}

Run it and enjoy more happy dappy path of web development with Nancy, Nuget and Mono on your Mac

Nancy with twitter bootstrap

cheers!

echo “packages/” > .gitignore

Well, that’s the problem. The file doesn’t work because it’s not encoded with UTF-8. So you have to encode and save it and everything works as expected.

Almost all the “RESTful” web service I’ve seen until now are constructed around two main media-types; JSON and XML. Less employed but still interesting in some scenarios is Atom. The most prevailing is the JSON media-type because of the increasing number of Js frameworks that have showed up since few years for building client side web sites.

But what about HTML ?

HTML is here since the very beginning of the web but still not very used in RESTful api as media-type. When we look back on the recent framework releases for building RESTful API in the .NET world we notice that HTML templated view generation is not supported OOTB. While for example ASP.NET Web API or Nancy allows you to do what you want by bending a little bit a framework (Nancy just have another Nuget package) you still have a feeling that HTML is something that doesn’t fit very well to the RESTful API design.

HTML from the very beginning was meant to represent informative documents that contains links to related documents which perfectly fit to the principle of media-type for REST API design. As identified by R. Fielding related to the “Web architectural style”, one of the six constraints that has to be respected is Uniform Interface. The interactions between clients, servers and other network based intermediaries depends on the uniformity of their interfaces. If any of the components stray from the established standards, then the Web’s communication system breaks down.

HTML and Uniform interface

The uniform interface boils down to the four constraints identified by R. Fielding :

1. Identification of resources
2. Manipulation of resources through representations
3. Self-descriptive messages
4. Hypermedia as the engine of application state (HATEOAS)

Let’s see how it is related to the HTML media-type.

Identification of resources : Each  resource should be addressed by a unique identifier such as a URI. So this constraint is not directly related to the HTML media-type.

Manipulation of resources through representations :  Clients manipulate representations of resources. The same exact resource can be represented to different clients in different ways. For example, a document might be represented as HTML to a web browser, and as JSON to an automated program. The key idea here is that the representation is a way to interact with the resource but it is not the resource itself. This conceptual distinction allows the resource to be represented in different ways and formats without ever changing its identifier. The HTML is a valid representation of resource.

Self-descriptive messages : A resource’s desired state can be represented within a client’s request message. A resource’s current state may be represented within the response message that comes back from a server. The self-descriptive messages may include metadata to convey additional details regarding the resource state, the representation format and size, and the message itself. Moreover through the HTTP headers it’s possible to organize the various types of metadata into uniform fields. The HTML is a valid media-type as self-descriptive message.

Hypermedia as the engine of application state (HATEOAS) : A resource’s state representation includes links to related resources. Links are the threads that weave the Web together by allowing users to traverse information and applications in a meaningful and directed manner. The presence, or absence, of a link on a page is an important part of the resource’s current state. HTML has hyperlinks so this constraint is also valid.

There is no point to prove that HTML is valid as representation of the resource. It’s from the very beginning of the web. After all, if your web browser couldn’t render HTML documents, the human Web would have been stunted from the start. Typically, resource representations such as HTML are meant for human consumption via a web browser. Browsers are the most common computer agents on the Web today. Another software agent consumes the XML or JSON representations as part of a business-to-business process.

RESTful API and templated view generation.

Here we go straight to the point. The main confusion among the developer community is not the HTML as a media-type but the constraints that are directly related to the web sites view construction. I talk here about .NET platform but I think the same constraints apply everywhere.

Templated view generation is a mean of transforming html templates for web pages filling them with data (often from different sources) into HTML pages. The problem is that :

HTML page != HTML representation of the resource

What does this statement imply ? In fact very much. Because when we’re building a web site, what we’re used to see in our browser is not just a simple HTML representation of a specific resource but often very complex HTML view construction mixing up the data from different sources and using child html views for the name of reusability. This means :

• MasterPages/Layouts are used to guarantee a consistent look and feel of the rendered HTML.
• PartialViews are used for keeping in one place common html code and using it in different parent views.
• URI is not used as resource identification but as handler of page generation using very often mixed resources of different kind or different data view projection to present user with the UI for the functional use case at hand (dashbord, shoping cart, item detail page, etc.)
• Web site navigation is here for broader user experience of the web site, not just for the purpose of the resource state transformation (HATEOAS).
• The presentation of the HTML is altered with CSS.
• Other client frameworks like js are used.
• Many other reasons

Going further with the analysis we see that achieving both i.e building RESTful API and html based web site is almost impossible. If we would like to go down this path it means that underlying framework we use to build our RESTful api with, in all the cases, is just returning resource representation in Json/Xml/Html with it’s hypermedia links. But in the case of the web site the page construction (master pages, and content page composition, etc.) should be handled by something else that is not of the responsibility of the RESTful API framework and that is used later in the pipeline. Well, as far as I know this doesn’t exist yet.

Can I build one to have both ?

Or, could I use HTML as the representation of the resource to build a web site with. Moreover, thanks to the content-negotiation I would also have a RESTful API. That is a fair question to answer. I think that I we go down the path of ASP.NET API and Nancy, templated view generation is far more complex than just a resource representation in the given format like HTML for example. A REST resource has it’s own semantics and business meaning that doesn’t necessarily align with the UI considerations and especially doesn’t care about how it is presented to the user.

I understand now why ASP.NET Web Api has it’s own existence compared to ASP.NET. Many people were ranting after the release of the ASP.NET Web Api that Microsoft is confusing the developer community because both ASP.NET MVC and API seemed to handle many common responsibilities. But in fact no.

This means that for me bothering with HTML as media-type has no value. I still want build one and have both. That’s why my choice will be to build a RESTFul API with a framework like ASP.NET Web API, Nancy or event Node.js serving a JSON/XML. I want use a templated view generation on the server side. I’d rather use a view composition on the client side with JS framework like AngularJs. I would have then the best of two worlds ; less code to write and greater encapsulation of responsibilities i.e APIs serves just resources, view and templates are composed on the client.

Big thanks to Simone Chiaretta(@simonech) and Ugo Lattanzi(@imperugo) for starting all this, for the big organisation work and to be such kind people

I really hope to help them next time and hope that we can manage to create the event in Paris next year.

For this edition, I did a presentation about “Simplicity”, why it matters and how to achieve it with tiny frameworks and tools.

You can find the slides just below.

I’ll publish the sources for all my samples as soon as I’ll organise them better and clean a little bit. You’ll find them here:

https://github.com/rhwy/SimplicityWeb.Net

***

After the conference, this means sunday, I finally took some time to enjoy the city. There is a lot of things to see in Milano, but you can find most of them in the old city center. In that way, I went for a walk from the hotel to these hotests point for about 4 hours.

You can find below some pics, really nice time

Another thing that was nice in the trip was the transportation. Nowadays, we use to take plane as a default solution, but sometimes train should be a really nice alternative! It was direct, starting from Paris, nearest station from house, then a very nice and comfortable trip of 7 hours while you can work, have lunch, then you arrive in the near center of Milano. That was really a good choice for me, and also a real joy of crossing the Alps by train.

Again, it was very nice to see all this people, a special mention for nice discussions with Chris Massey (@camassey), Robert Mühsig (@robert0muehsig), Kris (@Kvdm) and so much more!

Hope to see Milan again next year and hope to see you all for the 2013 Paris Edition

cheers!

I am working on a small library to help working with some dynamic stuff, but the target is mainly to use dynamics to simplify configuration and exchange data when types are not needed. This started as a demo project, but as I used some differents classes and techniques in different projects I tought it should be interesting to share all that in a full functional library and, at least it should be interesting help to learn a few things.

By the way, this is not the target of this first post about it, it’s only about refactoring. As this starts in a demo mode, most of the code was not really well constructed, even if it is almost well tested and most parts were done in TDD mode.

Let’s analyse a method I have:

private  void InitializeSetter()
{
    var expBoxy = _setterExpression.Body;

    if (expBoxy.NodeType == ExpressionType.Convert)
    {
        var convertExp = (UnaryExpression)expBoxy;
        var operand = (MemberExpression)convertExp.Operand;

        if (operand.Member is PropertyInfo)
        {
            PropertyInfo pi = typeof(T).GetProperty(operand.Member.Name);
            _setter = pi.GetValueSetter<T>();
        }

    }
    else if (expBoxy.NodeType == ExpressionType.MemberAccess)
    {
        var operand = (MemberExpression)expBoxy;

        if (operand.Member is PropertyInfo)
        {
            PropertyInfo pi = typeof(T).GetProperty(operand.Member.Name);
            _setter = pi.GetValueSetter<T>();
        }

    }
    else
    {
        throw new InvalidOperationException("Expression is not valid to set a property, should be something like x=>x.Name");
    }
}

This is not too long, but when I get back reviewing the code, it is almost complicated. And why it is complicated because this ends up with too much responsabilities and this does not use the full power of open close principles…

To complete this method, this is also the properties of this class and the constructor:

private Action<T, object> _setter;
private readonly Expression<Func<T, object>> _setterExpression;
private readonly ConfigurationMappingsBase<T> _source;

public Action<string, Action<T, object>> UpdateSource { private get; set; }

public PropertySetterExpression(ConfigurationMappingsBase<T> source, Expression<Func<T, object>> setterExpression)
{
    _source = source;
    _setterExpression = setterExpression;
    InitializeSetter();
}

Ok, Let’s analyse the code now.

I get all my properties from the constructor, that’s the good design point, but just in the constructor It begins to fail. It relays too much on ‘Void’ methods to set magicaly stuff and that matters!

As, the goal of InitializeSetter is to initialize the member _setter with some content of the member _setterExpression Let’s do it in another way:

public PropertySetterExpression(ConfigurationMappingsBase<T> source, Expression<Func<T, object>> setterExpression)
{
    _source = source;
    _setterExpression = setterExpression;
    _setter = InitializeSetter(_setterExpression);
}

private Action<T, object> InitializeSetter(Expression<Func<T, object>> expression)
{
    var expBoxy = _setterExpression.Body;
    return null; //temp hack
}

Ok, it compiles again and I have no more magical void method stuff, and I should test now this method (But I don’t want to, as I consider it as an internal mechanism and I made it private, but that’s another debate

But, what do I in the method? I get the Body – which is of type Expression and I work with it. Shouldn’t it be better to pass it directly and avoid a new var?

public PropertySetterExpression(ConfigurationMappingsBase<T> source, Expression<Func<T, object>> setterExpression)
{
    _source = source;
    _setterExpression = setterExpression;
    _setter = InitializeSetter(_setterExpression.Body);
}

private Action<T, object> InitializeSetter(Expression expression)
{
    if (expression.NodeType == ExpressionType.Convert)
    {
        var convertExp = (UnaryExpression)expression;
    }
    else if (expression.NodeType == ExpressionType.MemberAccess)
    {
        var operand = (MemberExpression)expression;
    }
    else
    {
        throw new InvalidOperationException("Expression");
    }
}

Now, What did I do with this expression? I rely on my procedural methods deeply printed in my reptilian cortex to make an if-then-else construct to do some work based on the type information of the expression and then cast it to the right type…That’s not too much object oriented no? And more, it violates the OCP…

Let’s rewrite it in an object way:

public PropertySetterExpression(ConfigurationMappingsBase<T> source, Expression<Func<T, object>> setterExpression)
{
    _source = source;
    _setterExpression = setterExpression;
    _setter = InitializeSetter(_setterExpression.Body);
}

private Action<T, object> InitializeSetter(UnaryExpression expression)
{
    var operand = (MemberExpression)expression.Operand;

    if (operand.Member is PropertyInfo)
    {
        var pi = typeof(T).GetProperty(operand.Member.Name);
        return pi.GetValueSetter<T>();
    }
    return null;
}

private Action<T, object> InitializeSetter(MemberExpression expression)
{
    if (expression.Member is PropertyInfo)
    {
        PropertyInfo pi = typeof(T).GetProperty(expression.Member.Name);
        _setter = pi.GetValueSetter<T>();
    }
    return null;
}

private Action<T, object> InitializeSetter(Expression expression)
{
    throw new InvalidOperationException("Expression");
}

Well, much better. But, I focuses me much more on what the code do right now, this can be simplified again:

The code of the unary expression, gets the member and do the same code that the member expression one, and as I had to return a value, I had to set to null, this means that my original code should failed If I don’t fall in the right path (or at least my _setter value should be null). Let’s do a last refactor:

public PropertySetterExpression(ConfigurationMappingsBase<T> source, Expression<Func<T, object>> setterExpression)
{
    _source = source;
    _setterExpression = setterExpression;
    _setter = InitializeSetter(_setterExpression.Body);
}

private Action<T, object> InitializeSetter(UnaryExpression expression)
{
    return InitializeSetter(expression.Operand);
}

private Action<T, object> InitializeSetter(MemberExpression expression)
{
    if (expression.Member is PropertyInfo)
    {
        var pi = typeof(T).GetProperty(expression.Member.Name);
        return pi.GetValueSetter<T>();
    }
    return InitializeSetter(expression);
}

private Action<T, object> InitializeSetter(Expression expression)
{
    throw new InvalidOperationException("Expression");
}

I am now quite happy with that, and that’s all for the theorical part .

But wait…My tests fail now!

Why do they fail? Because of two things:

• Expressions don’t rely on an interface but on public abstract class Expression : this means that our _setterExpression.Body will always fall on the last generic method.
• and because the type PropertyExpression which I need implicitely here is defined as internal class PropertyExpression : MemberExpression…

I don’t want to criticize the design of the Linq Expressions namespace, because I can imagine this design has it’s own very good reasons to be like that. But in my simple condition of developper and user of their framework I don’t agree with the way I have to work with it.

That’s why in this real life scenario, I finally end up with this code in order to make tests pass:

public PropertySetterExpression(ConfigurationMappingsBase<T> source, Expression<Func<T, object>> setterExpression)
{
    _source = source;
    _setterExpression = setterExpression;
    _setter = InitializeSetter(_setterExpression.Body);
}

private Action<T, object> InitializeSetter(UnaryExpression expression)
{
    return InitializeSetter(expression.Operand as MemberExpression);
}

private Action<T, object> InitializeSetter(MemberExpression expression)
{
    if (expression.Member is PropertyInfo)
    {
        var pi = typeof(T).GetProperty(expression.Member.Name);
        return pi.GetValueSetter<T>();
    }
    throw new InvalidOperationException("Expression");
}

private Action<T, object> InitializeSetter(Expression expression)
{
    if (expression.NodeType == ExpressionType.Convert)
        return InitializeSetter((UnaryExpression) expression);
    if (expression.NodeType == ExpressionType.MemberAccess)
        return InitializeSetter((MemberExpression) expression);
    throw new InvalidOperationException("Expression");
}

Still better than my very first iteration but not as good as I want.

Any thoughts?

ASP.NET ThreadPool facts

• ASP.NET uses threads from a common language runtime (CLR) thread pool to process requests. As long as there are threads available in the thread pool, ASP.NET has no trouble dispatching incoming requests.
• Async delegates use the threads from ThreadPool.

When you should start thinking about implementing asynchronous execution ?

• When your application performs relatively lengthy I/O operations (database queries, Web service calls, and other I/O operations).
• If you want to do I/O work, then you should be using an I/O thread (I/O Completion Port) and specifically you should be using the async callbacks supported by whatever library class you’re using. Theirs names start with the words Begin and End.
• If requests are computationally cheap to process, then parallelism is probably an unnecessary overhead.
• If the incoming request rate is high, then adding more parallelism will likely yield few benefits and could actually decrease performance, since the incoming rate of work may be high enough to keep the CPUs busy.

Should I create new Threads ?

• Avoid creating new threads like you would avoid the plague.
• If you are actually queuing enough work items to prevent ASP.NET from processing further requests, then you should be starving the thread pool! If you are running literally hundreds of CPU-intensive operations at the same time, what good would it do to have another worker thread to serve an ASP.NET request, when the machine is already overloaded.

What about the TPL and async await? Does it solve my problems ?

• TPL can adapt to use available resources within a process. If the server is already loaded, the TPL can use as little as one worker and make forward progress. If the server is mostly free, they can grow to use as many workers as the ThreadPool can spare.
• Tasks use threadpool threads to execute.
• When async/await will not consume an additional ThreadPool thread ? Only in the case you are using BCL Async methods. that uses an IOCP thread to execute the IO bound operation.

If you are trying to async execute some sync code or your own library code, that code will probably use an additional ThreadPool thread unless you explicitly use the IOCP ThreadPool or your own ThreadPool. But as far as I know you can’t chose whatever you want to use a IOCP thread, and making correct implementation of the ThreadPool is not worth the effort. I doubt someone does a better one that already exists.

I scratched only the surface but if you have more suggestions don’t hesitate to leave me a comment.

Thomas

Good news? Bad news?

I don’t know… I am still not convinced by the capacity of Microsoft to produce with a real OSS community a really pen source project. This time, and it’s quite new for them, they claims to accept pull requests from community.

I am not sure that it will make a big difference with the past, but I may be wrong (and I hope so!)

Just before continuing, I am not here to say that all this asp.net web stack and oss stories are a mess! I am still a big fan of the stack and I am only writing about some thoughts and experiments.

So, I git clone!

Obviously we can spend hours discussing philosophy about Microsoft misconception on open source, but to begin, the better way is to try it.

I don’t know if it is on purpose to be on the “OSS Move”, but CodePlex support since a few time Git. It’s another good news!

Oh wait…Perhaps we missed something?

1. If you’re true open source now, why not choosing a neutral platform –like GitHub – instead of a Microsoft source showcase without any soul like Codeplex?
2. Codeplex supporting git is good, but,  after svn or mercurial some years ago because it was the trend of the moment, doesn’t it undermines the solutions based on TFS a little bit? Or finally they are now convinced that TFS is not good for distributed open source project? Must probably, it is to let the platform die silently and empower in the future a platform based on the Tfs Cloud solution – which can be most intelligent solution.

So I can clone without installing the 300Mo iso of TFS explorer and that’s nice

git clone https://git01.codeplex.com/aspnetwebstack.git

That’s pretty quick (due to git compression, yeah!) and I can navigate the sources now.

Build It

I don’t know if everyone is more serious than me but one thing I always do after getting some sources, is to type “build” in the shell and see what happened, don’t you? It’s just to see if it can work immediately on a simple way. Let’s call it a “Download and Run” pattern.

I was a little bit disappointed with all screaming in red…And I forgot to say that, like most people, I explicitly forgot to read the recommendations and “README” you should read after downloading something.

So that’s it. It’s not clear on the project home page, but if you go to Documentation, you have most of the solutions to your problems:

1. Download SkipStrongNames, and unzip it. From an elevated command prompt, run “skipstrongnames -e" to allow you to run unit tests against the delay-signed binaries.
2. Don’t try to open directly the Runtime.sln  and “enable nuget restore” before launching a first build command. I will run a mess when you try to launch build.cmd later…

Additional Tip: You may need to manually add a specific Microsoft nuget development feed for some packages not yet officially distributed: In Visual Studio, open Tools/Library Package Manager/Settings Then in Packages Sources add new with this url:

http://www.myget.org/F/f05dce941ae4485090b04586209c8b08/

So, after applying SkipStrongNames (did I already mention that I hate StrongNames?), just restore your nuget packages:

./build.cmd RestorePackages

Then try to build it (without restore).

I said hope, because depending on your current configuration and state it may work or not:

• Having .Net 4.5 and/or aspnet mvc4 beta installed may cause troubles
• Having some data components may cause troubles (Maybe Sql 2012 is one…)

I finally get it working after removing .Net 4.5/mvc4 and removing the Microsoft.Web.Http.Data.Test project…

But, after uninstalling these components, msbuild 4 disappear too and mvc3 template projects just not work anymore.

A few words more

It’s is interesting to have the real sources of all the web stack but use it with caution.

It’s usually hard to compose with some beta versions from Microsoft that are not compatible with other tools but it’s also the case with these sources.

It’s far to be an independent project, and I can understand why it’s not, but it’s quite difficult to exploit and contribute to sources with these inter-dependencies.

I just hope that it will open some minds and bring real innovation. In the other hand, I hope it will help people usually using basically Microsoft products to have a new point of view on new ways of working.

Thomas.Dispose();

CodeDistillers.WaitFormPendingFinalizers();

• Official “Using the Web API Dependency Resolver”
• “Autofac ASP.NET Web API (Beta) Integration“
• “Web Api and Ninject”

What stands out is that every implementation relays on System.Web.Http.Services.IDependencyResolver interface which is similar to the one introduced in the ASP.NET MVC 3 and which lives in the System.Web.Mvc namespace to avoid confusion. Let’s look at it’s implementation details :

   1: public interface IDependencyResolver

   2: {

   3:     object GetService(System.Type serviceType);

   4:     IEnumerable<object> GetServices(System.Type serviceType);

   5: }

Since it was introduced in MVC 3 I’ve never used it because of it’s lack of “Release” method and the fact that there is now way cleaning-up resolved services from you DI container. If it’s not a problem for all DI containers, it is certainly a problem for Castle.Windsor which tracks resolved components. Mike Hadlow already spotted it was a problem and wrote a blog post “The MVC 3.0 IDependencyResolver interface is broken. Don’t use it with Windsor.” I think that this problem still remains with a WebApi IDependencyResolver interface and that’s why I decided to not use it. But will I manage to do it ?

Self Hosting

My current WebApi project is using self hosting feature and for the moment I won’t be interested in IIS hosting. After all, there should not be significant differences between two hosting options on adding IoC container support. We will check it after.

Given that in ASP.NET MVC 3 we weren’t compelled to implement IDependencyResolver at all I started to figure out what other hooks WebApi offers in order to set up my Composition Root. After few minutes of inspecting WebApi’s API, I found IHttpControllerFactory in the System.Web.Http.Dispatcher namespace which seems to me like a viable seam for connecting my own implementation. This interface is quite similar to the one from the System.Web.Mvc namespace and is all what I need.

   1: public interface IHttpControllerFactory

   2: {

   3:     IHttpController CreateController(HttpControllerContext controllerContext, 

   4:                                                         string controllerName);

   5:     void ReleaseController(IHttpController controller);

   6: }

As you noticed, there is “Create” and “Release” controller methods which allows me to use it with Castle.Windsor. Let’s look at it :

   1: public class WindsorHttpControllerFactory : IHttpControllerFactory

   2: {

   3:     private readonly IWindsorContainer _windsorContainer;

   4:  

   5:     public WindsorHttpControllerFactory(IWindsorContainer windsorContainer)

   6:     {

   7:         if (windsorContainer == null)

   8:             throw new ArgumentNullException("windsorContainer", 

   9:                             "The instance of the container cannot be null.");

  10:  

  11:         _windsorContainer = windsorContainer;

  12:     }

  13:  

  14:     public IHttpController CreateController(

  15:                                     HttpControllerContext controllerContext, 

  16:                                     string controllerName)

  17:     {

  18:         var controllerFullName = string.Format("{0}.{1}{2}", 

  19:                     typeof(OrderController).Namespace, 

  20:                     controllerName, ControllerSuffix);

  21:         var controllerType = Type.GetType(controllerFullName);

  22:  

  23:         return _windsorContainer.Resolve(controllerType) as IHttpController;

  24:     }

  25:  

  26:     public void ReleaseController(IHttpController controller)

  27:     {

  28:         var disposableController = controller as IDisposable;

  29:         if (disposableController != null)

  30:             disposableController.Dispose();

  31:  

  32:         _windsorContainer.Release(controller);

  33:     }

  34: }

Straightforward implementation that doesn’t need any comments. Next step is to register it in the WebApi framework.

First Fail : Registration

I really should start from there… Looking into the WebApi’s API I can’t really find where to register my own implementation into the framework. It seems that there is nothing similar to ControllerBuilder.Current.SetControllerFactory. My current startup code is like this :

   1: var config = new HttpSelfHostConfiguration("http://localhost:6666");

   2: config.Routes.MapHttpRoute("defualt", "{controller}/{id}", 

   3:                                 new {id = RouteParameter.Optional});

   4: var server = new HttpSelfHostServer(config);

   5:  

   6: server.OpenAsync().Wait();

Once again, standard initialization. But there is nothing on the HttpSelfHostConfiguration class that allows defining your own IHttpControllerFactory implementation. The only thing I can see is HttpSelfHostConfiguration.ServiceResolver.SetResolver methods with it’s overrides. It seems that there is no way to avoid implementing IDependencyResolver interface. So let’s do it.

Rolling out my own Dependency Resolver

As my unique solution is to implement my own IDependencyResolver so let’s do it :

   1: public class WindsorDependencyResolver : IDependencyResolver

   2: {

   3:     private readonly WindsorContainer _windsorContainer;

   4:  

   5:     public WindsorDependencyResolver(WindsorContainer windsorContainer)

   6:     {

   7:         if (windsorContainer == null)

   8:             throw new ArgumentNullException("windsorContainer", 

   9:                         "The instance of the container cannot be null.");

  10:  

  11:         _windsorContainer = windsorContainer;

  12:     }

  13:  

  14:     public object GetService(Type serviceType)

  15:     {

  16:         try

  17:         {

  18:             return _windsorContainer.Resolve(serviceType);

  19:         }

  20:         catch (ComponentNotFoundException)

  21:         {

  22:             return null;

  23:         }

  24:     }

  25:  

  26:     public IEnumerable<object> GetServices(Type serviceType)

  27:     {

  28:         try

  29:         {

  30:             return _windsorContainer.ResolveAll(serviceType).Cast<object>();

  31:         }

  32:         catch (ComponentNotFoundException)

  33:         {

  34:             return new List<object>();

  35:         }

  36:     }

  37: }

Then we have to register it as follows :

   1: static void Main(string[] args)

   2: {

   3:     var container = new WindsorContainer();

   4:     container.Install(FromAssembly.This());

   5:  

   6:     var config = new HttpSelfHostConfiguration("http://localhost:6666");

   7:     config.ServiceResolver.SetResolver

   8:                         (new WindsorDependencyResolver(container));

   9:     config.Routes.MapHttpRoute("defualt", 

  10:                 "{controller}/{id}", new { id = RouteParameter.Optional });

  11:     

  12:     using (var server = new HttpSelfHostServer(config))

  13:     {

  14:         server.OpenAsync().Wait();

  15:  

  16:         Console.WriteLine("The server is running.");

  17:         Console.ReadLine();

  18:     }

  19:  

  20:     container.Dispose();

  21: }

   1: public class ControllerFactoryInstaller : IWindsorInstaller

   2: {

   3:     public void Install(IWindsorContainer container, IConfigurationStore store)

   4:     {

   5:         container.Register(

   6:             Component.For<IHttpControllerFactory>().Instance(

   7:                 new WindsorHttpControllerFactory(container)));

   8:     }

   9: }

Note, that the default liftetime when unspecified is Singleton.

We’re ready to test.

Second Fail : Testing in Fiddler

To my surprise, when calling my service I end up with the following error (sorry for the French) :

{"ExceptionType":"System.NullReferenceException","Message":"La référence d’objet n’est pas définie à une instance d’un objet.","StackTrace":"   à System.Web.Http.ApiController.ExecuteAsync(HttpControllerContext controllerContext, CancellationToken cancellationToken)\u000d\u000a   à System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsyncInternal(HttpRequestMessage request, CancellationToken cancellationToken)\u000d\u000a   à System.Web.Http.Dispatcher.HttpControllerDispatcher.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)"}

For me it brakes the POLA. After wandering on Internet I didn’t find anything helpful. I decompiled some WebApi code sources, debugged once again and found that the instance of HttpControllerContext passed to my controller factory was a bit strange. In fact ControllerDescriptor and Controller properties was not assigned. By trial and error I ended up modifying my implementation like this :

   1: public IHttpController CreateController(HttpControllerContext controllerContext, 

   2:                                                             string controllerName)

   3: {

   4:     var controllerFullName = string.Format("{0}.{1}{2}", 

   5:                                                 typeof(OrderController).Namespace, 

   6:                                                 controllerName, ControllerSuffix);

   7:     var controllerType = Type.GetType(controllerFullName);

   8:  

   9:     controllerContext.ControllerDescriptor = 

  10:                 new HttpControllerDescriptor(controllerContext.Configuration, 

  11:                                                     controllerName, controllerType);

  12:     controllerContext.Controller = 

  13:                     _windsorContainer.Resolve(controllerType) as IHttpController;

  14:  

  15:     return controllerContext.Controller;

  16: }

Now everything works as expected. It’s a bit weird as these properties seem to be optional from the point of view of the API, or at least they should be provided with the instance of HttpControllerContext.

In Closing

As you see, there is no way to get rid of IDependencyResolver in the WebApi compared to MVC. It’s a pity because it puts another burden on the developer to implement an interface that doesn’t act as a composition root. In fact our composition root is resolved from the implementation of IDependencyResolver so it’s a bit confusing. It’s understandable from the point of view of ASP.NET team which wanted to make IDependencyResolver a central piece of IoC support in the WebApi framework but for me it presents some design flaws as the API is not clear enough which seams should be used and how exactly implement them.

In the next post I’ll do the test implementing it in IIS hosting environment.

Thomas.Dispose();

CodeDistillers.WaitForPendingFinalizers();