Did you know that dependency management in the .NET open source space really sucks? For a long time have we been looking at Ruby Gems in envy of the ease of use and simplicity, spawning projects like Horn or  Bricks. And while some of these projects were promising, none really took off in a big way, so here comes another take at it: Some clever guys just talked to the RubyGem people about (ab-)using their existing infrastructure for .NET assemblies. And hey, they agreed to let us use their Gem system to distribute .NET assemblies just the way Ruby people can get Rails and all other Ruby projects.

And behold there it is: nubular (nu)

I won’t go too deep into what nu does and why it’s awesome, read Rob Reynold’s article and you’ll see the light pretty soon. Suffice it to say that nu is to assemblies what apt-get and gems is to Linux people. You just drop to the command line and tell nu you need assembly X, and if a package exists with that name it will automagically pull it down and with it all dependencies and install it to your /lib folder. Best of all, it also allows you to install binaries with it, a feature that turned out to be really cool for dotless.

Anyway, I promised you a really fast way to install dotless. Well, it can’t get any simpler than this, just drop to the command line and type (install instructions on nu are further down in this article):

nu install dotless

And now nu goes out to the gem server and just fetches dotless for you:

The installation just took 3 seconds, and we have the dotless.Core.dll now sitting neatly in our <currentdir>/lib/dotless folder alongside all other libraries we got through nu.

What this install also gives you is a shortcut to the dotless.Compiler.exe. Nu will install a dotless.bat in your C:\Ruby\bin (that should be in your PATH) that you can now use to compile .less files from anywhere:

That’s pretty cool I dare say. And now the best part: Updating dotless just got a lot easier too. Whenever we publish a new version to nu you can just hit

gem update dotless

Installing nu

So far I’ve shown you how to get dotless installed once you already run ruby gems + nubular, but for that all to work you need to install Ruby on your machine first.

Doing so is probably the simplest thing in the world right now, just hit http://rubyinstaller.org/ and you are almost set. You just need to install the nu gem afterwards and you are done installing (takes together under 2 minutes). (Note: Make sure to let the installer add Ruby to your PATH or the whole exercise is futile)

To install the nu gem just type:

gem install nu

It can’t get any simpler than this does it? Oh and btw: Ruby is completely xcopy deployable and will leave no traces behind on your machine. No services are being run and no bad things can happen to you, so there is really no excuse for a developer out there to no just go ahead and install it.

Oh, and after you’ve installed nu you can then go ahead and fetch a complete Fluent Nhibernate + Castle Windsor stack in a matter of seconds, disregarding all dependency issues since nu is handling that for you. And people are putting more stuff there by the minute: Rhino.Mocks, Fluent Nhibernate, Nhibernate, Castle Windsor, Castle DynProxy, Automapper.. etc etc.. Look at the full list and see for your self how much easier you life can become by a simple installation!

Since the dotless 1.1 release we are finally able to present you with good error messages, telling you what line/column the problem was encountered etc. This has led to some tests like this one:

public void DivisionByZero()
{
    AssertExpressionError("Attempted to divide by zero.", 5, "20px / 0");
    AssertExpressionError("Attempted to divide by zero.", 14, "1 + 2 - 3 * 4 / 0");
    AssertExpressionError("Attempted to divide by zero.", 6, "1 + 2 / 0 - 3 * 4 / 0");
}

Usually you just check the exception type, but in this case it’s a generic ParseException that has the additional line/column  info on it and does not wrap the DivideByZeroException in it’s InnerException. Obviously the above failed on my machine due to my German locale and I was getting a different exception message.

I first tried to set the thread’s culture to en-GB but this only changes how formats are handled, there are no English exception texts installed on a German Windows machine.

The obvious solution then was to not hard-code the exception message but retrieve it from the DivideByZeroException:

[Test]
public void DivisionByZero()
{
    var divideByZeroException = new DivideByZeroException();
    AssertExpressionError(divideByZeroException.Message, 5, "20px / 0");
    AssertExpressionError(divideByZeroException.Message, 14, "1 + 2 - 3 * 4 / 0");
    AssertExpressionError(divideByZeroException.Message, 6, "1 + 2 / 0 - 3 * 4 / 0");
}

Takeaway: Make sure you tests run on all locales if your tests rely on exception messages.

In case you haven’t noticed, the main dotless website is down. To be frank: We have no clue why, and I couldn’t reach Chris who owns the server we are running on.
Unfortunately Chris also owns the hostname so we can’t easily migrate to a new host so see this post as a guide to where to get your stuff while we are working to resolve this.

Getting the Source is straight forward, just hit the GitHub repository.

Documentation: I’ve moved all our Documentation to the GitHub Wiki. We do lose the ability to let you try out dotless, but at least the docs are somewhere to be found.

Binary releases: Unfortunately we don’t have a build server, but I’ll try to keep the latest version of the binaries uploaded to the GitHub downloads page.

Object initializers got introduced into C# as part of .NET 3.5 and allow you to define properties through a nice concise syntax that makes code easier to read. Here’s an example:

var daniel = new User()
                    {
                        Username = "Tigraine",
                        Age = 25,
                        Email = "[email protected]"
                    };

In a .NET 2.0 environment the above code would have looked like this:

var daniel = new User();
daniel.Username = "Tigraine";
daniel.Age = 25;
daniel.Email = "[email protected]";

The funny thing here is that the .NET 2 code is not thread safe. If daniel is a public field or static field anywhere, the scheduler could interrupt the Thread right after setting the age, leaving you with an empty email field. This is also the reason why I’d call object initializers expressions: Expressions do by definition yield a value. And if we look at the code the compiler generates for an object initializer you will see this:

User <>g__initLocal0 = new User();
<>g__initLocal0.Username = "Tigraine";
<>g__initLocal0.Age = 0x19;
<>g__initLocal0.Email = "[email protected]";
User daniel = <>g__initLocal0;

The compiler does emit code that constructs the new object in a local variable that gets discarded right afterwards, and only the completed object, with all properties initialized will then be assigned to the variable. This makes this code thread safe. But, you’ll say it doesn’t yield a result thus it’s not really an expression.

Well, rewrite it a bit and you get a expression:

Func<User> expr = () =>
                    {
                        var user = new User();
                        user.Username = "Tigraine";
                        user.Age = 25;
                        user.Email = "[email protected]";
                        return user;
                    };
var daniel = expr();

It’s essentially a function that the compiler generates inline to save the cost of a method call, but it’s semantically a function, thus it yields a value and is a expression.