ngeor.net | blog

Installing Ruby on Rails on Windows 8

Tue, 16 Apr 2013 10:33:00 +0300

I had some problems installing Ruby on Rails on Windows 8 so I'm writing this down as a summary.

Use RubyInstaller. I recommend version 1.9.3. With version 2, I run into various problems trying to build native gems (e.g. libiconv not found). By default this will install Ruby at C:\Ruby193. I also recommend selecting the Add Ruby to the PATH during installation, no need to do it manually later.
From the same site, download DevKit. It's a self extracting archive and you need to extract it to its final location. I extracted it under C:\Ruby193\devkit so it's together with ruby.
Install DevKit: from a command prompt, go to C:\Ruby193\devkit and run ruby dk.rb init and then ruby dk.rb install
Update gem to latest and greatest with gem update --system and then gem update
Install rails with gem install rails
Install sqlite3 with gem install sqlite3

So far so good. At this point we're ready to start going through the tutorial Getting Started with Rails to create our first application. Let's to that with the command rails new blog.

Among other things in the output, you'll notice that some gems are already present (e.g. json, rails) while others are being installed at that moment (e.g. execjs, coffee-script).

Installing coffee-script-source (1.6.2)
Installing execjs (1.4.0)
Installing coffee-script (2.2.0)
Using rack-ssl (1.3.3)
Using json (1.7.7)
Installing rdoc (3.12.2)
Using thor (0.18.1)
Using railties (3.2.13)
Installing coffee-rails (3.2.2)
Installing jquery-rails (2.2.1)
Using rails (3.2.13)
Installing sass (3.2.7)
Installing sass-rails (3.2.6)
Using sqlite3 (1.3.7)
Installing uglifier (2.0.1)
Your bundle is complete!

We can run the application at this point with rails server and indeed it will load the default index.html. Following the tutorial, we can create our first home controller and delete the index.html. The command to do that is rails generate controller home index. You also need to delete index.html and setup home#index as the default route.

This is where I had most of the problems. Instead of seeing my hello world message in this very simple controller, I ended up with the following error message in the command prompt:

Completed 500 Internal Server Error in 208ms

ActionView::Template::Error (
  (in C:/Users/nikolaos/Projects/blog/app/assets/javascripts/home.js.coffee)):
    3: <head>
    4:   <title>Blog</title>
    5:   <%= stylesheet_link_tag    "application", :media => "all" %>
    6:   <%= javascript_include_tag "application" %>
    7:   <%= csrf_meta_tags %>
    8: </head>
    9: <body>
  app/views/layouts/application.html.erb:6:in `_app_views_layouts_application_html_erb___564660063_19500504'


  Rendered C:/Ruby193/lib/ruby/gems/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/templates/rescues/_trace
.erb (1.0ms)
  Rendered C:/Ruby193/lib/ruby/gems/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/templates/rescues/_reque
st_and_response.erb (1.0ms)
  Rendered C:/Ruby193/lib/ruby/gems/1.9.1/gems/actionpack-3.2.13/lib/action_dispatch/middleware/templates/rescues/templa
te_error.erb within rescues/layout (11.0ms)

And this is the error message that the browser showed:

 ExecJS::RuntimeError in Home#index

Showing C:/Users/nikolaos/Projects/blog/app/views/layouts/application.html.erb where line #6 raised:


  (in C:/Users/nikolaos/Projects/blog/app/assets/javascripts/home.js.coffee)

Extracted source (around line #6):

3: <head>
4:   <title>Blog</title>
5:   <%= stylesheet_link_tag    "application", :media => "all" %>
6:   <%= javascript_include_tag "application" %>
7:   <%= csrf_meta_tags %>
8: </head>
9: <body>

Rails.root: C:/Users/nikolaos/Projects/blog
Application Trace | Framework Trace | Full Trace

app/views/layouts/application.html.erb:6:in `_app_views_layouts_application_html_erb___564660063_19500504'

Not very descriptive and a bit disappointing that the hello world tutorial doesn't "just work". The error has something to do with CoffeeScript, since the file it complains about is home.js.coffee. CoffeeScript is a nice little language that compiles into Javascript. Rails comes with out of the box support for this (or at least it claims it does). It uses ExecJS, another gem, to compile CoffeeScript into Javascript. ExecJS relies on the presence of a Javascript runtime in order to be able to do that. A lot of people suggested to bypass this problem by "simply installing node.js". However, ExecJS says that on Windows it just uses Microsoft Windows Script Host. So I decided to keep on searching for a solution. After some more digging I found a thread claiming that this problem is specific to Windows 8 and the solution is to modify ExecJS's code... scary to say the least and, again, very disappointing experience but it did the trick.

You have to modify the file runtimes.rb (assuming you've kept the default paths, it is under C:\Ruby193\lib\ruby\gems\1.9.1\gems\execjs-1.4.0\lib\execjs) and find the block that declares the JScript external runtime (that's Microsoft Windows Script Host) and change it into this:

JScript = ExternalRuntime.new(
  :name        => "JScript",
  :command     => "cscript //E:jscript //Nologo",
  :runner_path => ExecJS.root + "/support/jscript_runner.js",
  :encoding    => 'UTF-8'
)

After this change, my hello world controller worked. I've tried the above procedure in both Windows 8 32 and 64 bits. I was also able to follow the tutorial a bit more by generating the post scaffold and I didn't run into any problems with sqlite, it seems to work. I stopped at the point where he adds a second model, so I don't know if there are any further pitfalls ahead...

BlogEngine.NET MVC - Progress update

Wed, 13 Mar 2013 09:39:00 +0300

Here's a short update on what I've been working on. Time is a bit limited but I like to hack around in this project and that's what it's all about!

Implemented Category and Tag pages
Initial implementation for RSS feed
Showing comments in the post page
Implemented Add, Edit, Delete, Restore and Purge actions for Posts and Pages
Started working on a blog settings page

I'm thinking of perhaps setting up an issue tracker to maintain a log of what needs to be done and what has already been done. I don't think I can do that in CodePlex, because that would have to be a tracker just for my branch and I don't think that's supported. Or maybe set up some rough goals like milestones of the project. I'll see how it goes...

One comment on the Restore and Purge actions: in BlogEngine.NET, when you delete a post or a page it doesn't get completely deleted. It is marked as deleted, but the post file is still there (if you're using the default file based storage). To really delete it, you need to empty the recycle bin in the admin UI. I have taken a different approach in the pages that show lists of posts (homepage, category page, tag page, etc):

you see all the posts (or pages) you're allowed to based on your permissions
that includes deleted posts too!
unpublished and deleted items are presented with a small text label that indicates their status

I find this view a bit simpler, at least for now... of course the recycle bin concept is probably better (you delete a post for a reason, you don't want to see it in your face all the time) but that will come later.

Things to come up next:

pagination for homepage and similar pages
submitting comments
uploading images to a post (I want to use ImageResizing.Net here)
implement contact form
implement blog settings page (only settings that are used).
support markdown formatting in posts and pages

and more, much more!

BlogEngine.NET MVC - Posts and Pages

Sat, 09 Mar 2013 10:18:00 +0300

In the latest commit on BlogEngine.NET MVC, which is always available here, the following have been added:

Page controller. Pages have URLs like http://localhost/page/my-page or http://localhost/secondary-blog/page/my-page if it's on a secondary blog
Post controller. Post URLs are similar to pages, but the URL segment 'page' changes into 'post'. In addition, BlogEngine.NET supports two versions of URLs: simple (the ones we just described) and timestamped, where the post slug is prefixed by the date of the post. The latter looks like http://localhost/post/2013/03/09/my-post. This preference is set in blog settings and it's already been taken into account in BlogEngine.NET MVC! Depending on the preference, the correct post URL will be generated. Also, the 'incorrect' URL will redirect to the correct one to ensure we don't end up with duplicate URLs (for SEO reasons).
Stub Archive, Contact and Feed views, so that all the URLs of the homepage point to somewhere.

Mapping the post URL

Mapping the post route is quite simple:

// map posts, with timestamped links
MapBlogRoute(routes,
    name: "PostWithTimestamp",
    url: "post/{year}/{month}/{day}/{slug}/{action}",
    defaults: new { controller = "Post", action = "Index" },
    constraints: new { year = @"\d\d\d\d", month = @"[0-1]\d", day = @"[0-3]\d" }
    );

MapBlogRoute is a helper method that maps the route twice, once for the primary blog and once for the secondary blogs. The constraints make sure we match only numerical values for year, month and day. For month and day, we also make sure the first digit is in the expected range. So if someone tries to access http://localhost/post/2013/20/01/my-post, MVC won't even bother to find the post because no route will match the URL.

We also need to map the post URL without the timestamp. This is the same situation we saw with the blog name parameter: because the date parameters are in the middle of the URL, they can't be simply ignored.

// map posts, without timestamped links
MapBlogRoute(routes,
    name: "PostWithoutTimestamp",
    url: "post/{slug}/{action}",
    defaults: new { controller = "Post", action = "Index" }
    );

Simple enough!

Generating URLs to posts

In the views, we'll be generating links to posts. We want a simple way of passing a post and getting a URL to that post. Plus, the URL should respect the blog settings regarding whether the user wants timestamped post URLs or plain URLs. This is best done in a view helper. Here's the method that does the trick. It's inside HtmlHelpers/UrlHelpers, were more extension methods like these can be put:

/// <summary>
/// Gets the URL of a post.
/// </summary>
/// <remarks>
/// <see cref="BlogSettings.TimeStampPostLinks"/> controls if the URL
/// will contain the date of the post or not.
/// </remarks>
/// <param name="urlHelper">The url helper.</param>
/// <param name="post">The post.</param>
/// <returns>The URL of the post.</returns>
public static string PostUrl(this UrlHelper urlHelper, Post post)
{
    BlogSettings blogSettings = BlogSettings.GetInstanceSettings(post.Blog);
    object defaults;
    if (blogSettings.TimeStampPostLinks)
    {
        defaults = new
        {
            blogName = BlogNameInRoute(post.Blog),
            year = post.DateCreated.ToString("yyyy"),
            month = post.DateCreated.ToString("MM"),
            day = post.DateCreated.ToString("dd"),
            slug = post.Slug
        };
    }
    else
    {
        defaults = new
        {
            blogName = BlogNameInRoute(post.Blog),
            slug = post.Slug
        };
    }

    return urlHelper.Action("Index", "Post", defaults);
}

To use this helper, we need to import it in the view. It's just an extension method, so basically you just need to import the namespace. Here it is in action inside the updated homepage view:

@using BlogEngine.Core
@using BlogEngine.Mvc.Helpers
@{
    ViewBag.Title = BlogSettings.Instance.Name;
}

<h2>@ViewBag.Title</h2>
<ul>
    @foreach (Post post in ViewBag.Posts)
    {
        <li><a href="@Url.PostUrl(post)">@post.Title</a></li>
    }
</ul>

What's next? Since we have posts and pages and we're able to login, maybe next time we can edit a post...

BlogEngine.NET MVC - Login time

Thu, 07 Mar 2013 10:11:00 +0300

It's not difficult to implement a basic login system. BlogEngine.NET comes with its own membership and roles providers, so all we need to do is create a controller that uses the standard Membership features of .NET.

To speed things up, I copy pasted the AccountController that is generated when you create a new MVC project in Visual Studio and select the template Internet Application. That controller actually does a whole lot more than what we need (e.g. authenticate via Facebook), so I removed the extra parts, keeping only the login functionality.

The login form does look a bit crappy, but I'm not interested in styling anything so far:

And after logging in with admin admin (the default credentials of BlogEngine.NET), you get a nice welcome message in the homepage:

We're logged in!

But wait, there's more!

I added some HTML into the layout (it seems that's the name for master pages in ASP.NET MVC) of the site that is dependent on the current blog. That means that for every view that is been rendered, it is important we don't forget to set the Blog.InstanceIdOverride property, otherwise BlogEngine.NET will attempt to figure out the current blog on its own.

Now, we could go and make some base controller class that has that functionality as a method, but it's too soon to start building class hierarchies that we might later regret (although the base controller will probably come in handy later). Plus, ASP.NET MVC has a cool feature called action filters. You can create a .NET attribute and decorate an action or even a controller and affect the executing action.

With that in mind, I implemented a SetCurrentBlogAttribute and I decorated my two controllers (HomeController and AccountController). The attribute intercepts each executing action and determines what the current blog is. The implementation is based on the GetBlog method we saw in the previous post. The whole attribute implementation looks like this:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
public class SetCurrentBlogAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        base.OnActionExecuting(filterContext);

        string blogName = null;
        if (filterContext.RouteData.Values.ContainsKey("blogName"))
        {
            blogName = filterContext.RouteData.Values["blogName"] as string;
        }

        Blog blog;
        if (string.IsNullOrWhiteSpace(blogName))
        {
            // we're loading the primary blog
            blog = Blog.Blogs.Find(b => b.IsActive && b.IsPrimary && !b.IsDeleted);
        }
        else
        {
            // we're loading a secondary blog
            blog = Blog.Blogs.Find(b => b.IsActive
                && !b.IsPrimary
                && !b.IsDeleted
                && string.Equals(blogName, b.Name, StringComparison.InvariantCultureIgnoreCase));
        }

        if (blog == null)
        {
            // TODO: return 404 instead
            throw new InvalidOperationException("Blog not found");
        }

        // important: this will make BlogEngine.Core use this blog as the 'current' blog
        // and don't make any assumptions using the URL etc
        Blog.InstanceIdOverride = blog.Id;
    }
}

So, as long as there is a 'blogName' parameter in the route, the correct blog will be set as current blog and we'll be able to seamlessly use the standard BlogEngine.Core API.

Coming up next? Building up post and page links... stay tuned!

BlogEngine.NET MVC - Hello world

Wed, 06 Mar 2013 16:02:00 +0300

So, to share a bit more of my excitement, here's a screenshot of the classic ASP.NET and the MVC versions running side by side:

So we got a homepage working! Hurray! Keep on reading for more in depth details.

Copy pasting from the website

Before we even start, we need to copy paste a few things from the website project into the MVC project:

copy pasted the App_Data folder into the MVC project. We have in this way the same start up sample data as the web site project.
modified the Web.config to have the necessary BlogEngine sections, the BlogEngine related app settings and the BlogEngine Membership and Roles providers.

Routing

For rendering the blog's homepage, we need to map two routes:

one route for the primary blog that corresponds to the root URL e.g. http://myhost/
one route for all the secondary blogs that correspond to URLs like http://myhost/myblog/

BlogEngine.NET supports multiple blogs (in fact my site is built with that feature) so we're going to support this feature. Unfortunately, the 'myblog' URL segment is in the beginning of the URL so, after a short investigation I did, it seems that optional URL parameters only work at the end of the URL.

The problem is clearer when you think of the URLs that we'll be building next, for instance the URLs of posts and pages. So http://myhost/page/mypage and http://myhost/myblog/page/myotherpage need to be two different routes:

page/{pageName}/{action} (primary blog's pages route)
{blogName}/page/{pageName}/{action} (secondary blog's pages route)

because the {blogName} parameter appears in the beginning of the URL.

Of course there's going to be only one controller handling this:

public class PageController
{

    public ActionResult Index(string blogName, string pageName)
    {
    }

I'll try again to see if it's possible to do it with a single route definition, but it's not really a problem, just an annoying detail of implementation.

Routing constraint

To make sure our secondary blog route doesn't collide with action names, we're going to use a custom routing constraint. Here's how the secondary blog's homepage is mapped:

routes.MapRoute(
    name: "SecondaryHome",
    url: "{blogName}/{action}",
    defaults: new { controller = "Home", action = "Index" },
    constraints: new { blogName = new BlogNameConstraint() }
    );

and here's the implementation of the constraint:

/// <summary>
/// Routing constraint that matches a secondary blog name.
/// </summary>
public class BlogNameConstraint : IRouteConstraint
{
    public bool Match(HttpContextBase httpContext,
            Route route,
            string parameterName,
            RouteValueDictionary values,
            RouteDirection routeDirection)
    {
        // match if the blog is active, not deleted, not primary and the name matches of course
        string blogName = (string)values[parameterName];
        return !string.IsNullOrWhiteSpace(blogName) &&
               Blog.Blogs.Any(
                   b => !b.IsDeleted
                       && !b.IsPrimary
                       && b.IsActive
                       && string.Equals(b.Name, blogName, StringComparison.InvariantCultureIgnoreCase));
    }
}

With this constraint, the URL:

http://myhost/Feed will be interpreted as the primary blog's RSS feed (action = Feed).

but this URL:

http://myhost/blog will be interpreted as the secondary blog's homepage (action = Index), and not as the non-existing 'blog' action of the primary blog route.

Unless of course... you chose to name your secondary blog after an existing action of the HomeController. Let's say our HomeController has an action called Feed that renders the RSS feed of the blog (we're probably going to built it). If you call your secondary blog 'Feed', it will be impossible to determine if the URL:

http://myhost/Feed

is supposed to be the primary blog's RSS feed or the secondary blog's homepage.

So the conclusion is: you must not name your secondary blogs after actions of the homepage controller. Also, you shouldn't shoot yourself in the foot, but you already knew that.

Controller implementation

The controller's default implementation is very simple:

    public ActionResult Index(string blogName)
    {
        Blog blog = GetBlog(blogName);
        ViewBag.Blog = blog;
        ViewBag.Posts = Post.Posts.Take(BlogSettings.Instance.PostsPerPage).ToArray();
        return View();
    }

this should look familiar to a person who's used BlogEngine before. The important work is happening of course in that GetBlog method. Let's have a look:

    private Blog GetBlog(string blogName)
    {
        Blog blog;
        if (string.IsNullOrWhiteSpace(blogName))
        {
            // we're loading the primary blog
            blog = Blog.Blogs.FirstOrDefault(b => b.IsActive && b.IsPrimary && !b.IsDeleted);
        }
        else
        {
            // we're loading a secondary blog
            blog = Blog.Blogs.FirstOrDefault(b => b.IsActive 
                    && !b.IsPrimary
                    && !b.IsDeleted
                    && string.Equals(blogName, b.Name, StringComparison.InvariantCultureIgnoreCase));
        }

        if (blog == null)
        {
            // TODO: return 404 instead
            throw new InvalidOperationException("Blog not found");
        }

        // important: this will make BlogEngine.Core use this blog as the 'current' blog
        // and don't make any assumptions using the URL etc
        Blog.InstanceIdOverride = blog.Id;
        return blog;
    }

So, like I said before, the blogName can indicate we're loading a secondary blog. If it's missing, then we're loading the primary blog of the site.

The BlogEngine API heavily relies on Blog.CurrentInstance, which indicates what the current blog is. When you're loading Posts, it is loading Posts for the current blog. When you're loading blog settings, it is loading the settings of the current blog, and so on. Figuring out what the current blog is, is something that is heavily intertwined with the current HttpContent, the URLs, the request, etc. We really don't want to use that plumbing, because it's not MVC and because we already know what the current blog is based on MVC routing. Luckily, there's an InstanceIdOverride property that we can use to tell BlogEngine.NET what the current blog is. If that property is set, the default logic that evaluates the current blog is never executed.

The code is available on Codeplex!

BlogEngine.NET MVC

Wed, 06 Mar 2013 14:16:00 +0300

Finally, I got to play with ASP.NET MVC for a real project at work. I really enjoyed it, but it lasted only for a few weeks.

I decided to dig into it a bit more, as a learning exercise at first. I started working on implementing BlogEngine.NET as an MVC project, keeping the same core but with a different frontend. I coded away a little bit during the weekend and made great progress fast.

I'll try to re-create that work publicly and extend it, on a fork available on CodePlex. As I add more code, I'll be blogging about it here.

The code committed so far contains pretty much nothing:

an empty MVC project
the solution upgraded to Visual Studio 2012 format
the existing web project using IIS Express
NuGet Package Restore enabled (to avoid committing all the package binaries)

In the end of this project, if it is successful, I'll use it to run my site (eat your own dogfood and all that).

w3c-nant version 1.2.0 released

Sat, 16 Feb 2013 17:14:00 +0300

Version 1.2.0 of w3c-nant was released today. This version contains some improvements submitted by Rob Richardson:

ability to store the status code of an FTP task in a property, using the new resultproperty attribute
better handling of exceptions
ftpUpload task exposes the overwritecondition attribute, which was previously only available through the core API. This way you can control when remote file will be overwritten during upload.
less messages in the log file, unless verbose is turned on

Also a small bug was fixed regarding the Never value of overwrite condition: instead of uploading only files that don't exist remotely, this mode would instead always overwrite remote files and never upload new ones.

Ακόμα πιο νέο ανεπίσημο podcast για Ελληνοφρένεια

Thu, 07 Feb 2013 00:36:00 +0300

Διαθέσιμο εδώ:

http://ngeor.net/ellinofreneia/rssnew.xml

Το παλιό podcast βασίζεται στο real.gr και υπάρχουν δύο προβλήματα κατά καιρούς:

καμιά φορά (όπως σήμερα) δεν ανεβάζουν τις εκπομπές εκεί εγκαίρως ή και καθόλου
περιστασιακά μπορεί η HTML που ανεβάζουν (είναι προφανώς με το χέρι κάθε φορά) να περιέχει μικρές διαφορές (ή ακόμα και λάθη τύπου λατινικό M στη θέση του ελληνικού Μ) που «μπερδεύουν» το πρόγραμμά μου που ανιχνεύει τις εκπομπές...

Το "ακόμα πιο νέο" ανεπίσημο podcast τσιμπάει τις εκπομπές από το ellinofreneia.net. Ελπίζω αυτό να πάει καλύτερα.

Τα παλιά URLs θα εξακολουθούν να ενημερώνονται μέχρι νεωτέρας.

Πώς να βάλετε το "ακόμα πιο νέο" ανεπίσημο podcast της Ελληνοφρένειας στο iTunes

Ακολουθώντας τα παρακάτω βήματα:

Ανοίξτε το iTunes
Πηγαίνετε στο μενού File, επιλέξτε Subscribe to Podcast
Στο παραθυράκι που ζητάει το URL, δώστε το URL που υπάρχει στην αρχή αυτού του post

Αν όλα πάνε καλά, θα το αναγνωρίσει και θα αρχίσει να κατεβάζει την τελευταία εκπομπή.

State of Greece, October 2012

Sun, 14 Oct 2012 09:41:00 +0300

A lot of things are happening in Greece and they're happening fast. People are worried that Greece will leave the eurozone because of the economy. But I think they should be worried that Greece will leave the EU because of its constant decline from a state of law and order. Instead of solving the economy's problems, the applied policies are turning the uneducated masses to fascism at numbers never seen in the past.

Police

In the western world, the police is usually an impartial tool that is used to keep law and order. Their motto is "to serve and protect" (at least in American TV shows). In Greece that motto is becoming "to serve and protect our neo-nazi friends".

In the recent elections, neo-nazi party got more votes in the designated polling stations where riot police officers vote.
People are been preemptively detained by the police before scheduled protests.
Police started publishing photos of people they arrest during protests online on the police website. What is funny here is that they don't even hesitate posting photos of people they've previously beaten up, making sometimes their website look like a hospital website...
The most shocking report (shocking to people who didn't see this coming) was Guardian's report of Abu Ghraib style tortures in Attica General Police Directorate (GADA). Minister's response? He's thinking of suing the Guardian. Maybe he should also sue organizations that report Greece as #4 in the list of human rights violations. Greek media have completely buried this story.
In general, the police seems to operate beyond the law. They always had, but not as open as this. Another story by the Guardian where a riot police officer used a protestor as a human shield passed by without any reaction by the police or the government.

Neo-nazis escalate violence

In the western world, these people belong in prison. In Germany, their symbols are illegal. In Greece, these street thugs and night life criminals are now members of the parliament. As any other parliament party, they get free money (probably EU money since Greece is bankrupt). From a zero point nothing percent in the previous elections, they rose to a whopping 7 percent. According to the polls, their popularity is soaring and they appear to be at 10 percent.

Children are stopped on streets by motorcycle gangs asked to prove they're Greek by reciting the alphabet or so. These reports allegedly come from complaints on embassies in Greece that the victims made.
Food drive for Greeks only
Blood drive for Greeks only (this idea was rejected by doctors as racist)
Petrol bombing of immigrant houses, beating up random immigrants based on their skin tone. The police role in this is typically to ignore the victim's complain and check out if they have a permit.
Attacking benches of immigrants in flea markets, assuming the role of the police (with the presence of neo-nazi MPs).
Meanwhile, I understand that Greek TV is presenting the neo-nazi in the life style section as a harmless sensation. I don't watch Greek TV (or any TV) so I don't know the extent of this.
Most recent absurdity: the government was fast to comply to a neo-nazi MP's question about how many foreign children exist in public kindergartens. Local authorities refused to reply to the government with that data. One of the promises of the neo-nazi party before the elections was that they will enter hospitals and schools to kick out foreigners.
Most recent stunt: neo-nazi MPs together with fanatic Christians cancel the premiere of a 'blaspheme' theater play. In that incident a journalist got beaten up by a neo-nazi MP in front of the police.
They're spreading their hate speech even in New York. At least there the Greek community was swift to condemn them.

Economy

Nothing good here either. Lending money from the EU and IMF in order to solve the money lending problem. It's usually quiet until the time comes where Greece has to receive the next loan installment and then everyone starts running around panicking.

Unemployment continues to rise constantly, reaching around 25%
Economy to enter the 6th year of recession.
MPs continue to get jobs for their children in the parliament, just like in the good old days.
No real reforms. Only new taxes upon taxes. People who could tax evade will continue to tax evade.

Summary

The economy is not doing very well, but it is exposing the backward side of Greece. Institutions don't live up to their role. In the collapse of the organized state, if there ever was one, the gap is been filled by nationalists. The rule of law is losing to the rule of might. Unless the official state decides to uphold the law, things will only get worse.

Run dotCover from msbuild and ccnet

Sun, 02 Sep 2012 09:52:00 +0300

TeamCity is a very nice tool that I use at home. Unfortunately the free license allows up to 20 configurations. That's why I'm experimenting also with another free tool, CruiseControl. It's definitely not as easy as TeamCity, you have to edit (which means learn) an XML file that the server picks up. In general, it probably supports what TeamCity supports, but you have to make everything yourself with a lot of work. Then again, it's completely free.

What I wanted to setup is code coverage. TeamCity offers its own tool out of the box, dotCover. Since that tool is just a command line program, I figured I could reuse it in CruiseControl.

dotCover

dotCover is the tool that does the work behind the scenes. In order to invoke it manually, in combination with NUnit, you'll have to run the dotCover executable like this (all command lines are broken down to multiple lines for readability, should be in a single line):

dotCover analyse
    /TargetExecutable:nunit-console.exe
    /TargetArguments:MyProject.Tests.dll
    /TargetWorkingDir:MyProject.Tests\bin\Debug
    /Output:report.xml

This command will run the tests in the MyProject.Tests.dll with nunit and produce an XML code coverage report in report.xml. The XML report can be useful for generating graphs and statistics (haven't experimented with that yet). It is however possible to generate a much more friendly HTML report by running the command like this:

dotCover analyse
    /TargetExecutable:nunit-console.exe
    /TargetArguments:MyProject.Tests.dll
    /TargetWorkingDir:MyProject.Tests\bin\Debug
    /ReportType:HTML
    /Output:report.html

This will generate the report.html file and a folder with CSS and JS that provide a pretty code coverage report.

It is also possible to generate both the XML and HTML reports. To do that, you only need to run the time consuming dotCover coverage part just once. Then, you run dotCover again twice to generate the two reports, telling it to work on the intermediate coverage report file produced on the first run. We'll use that in our build file.

Environment Variables

The previous examples of course assume that the dotCover and nunit-console executables are in the same folder or in the PATH. Usually, that's not the case. To make our setup more robust, we'll introduce two environment variables before going any further:

DOTCOVER_HOME -> C:\TeamCity\buildAgent\tools\dotCover
NUNIT_HOME -> C:\Program Files (x86)\NUnit 2.5.10\bin\net-2.0

The first path is the path where dotCover.exe resides. The second path is where nunit-console.exe should be found.

MSBuild

Now is the time to hack into our csproj file. We could do this directly in CruiseControl's ccnet.config file actually. However, I prefer modifying the csproj file because:

the syntax is simpler
I can run it from my development machine as well as from my build server
even if I switch to a different build server, it will work (provided it supports msbuild)

We'll use the AfterBuild target. Also, because we typically don't want to run dotCover on every build on our development machine (or maybe you do, your call), we'll only launch dotCover if a certain parameter is passed to msbuild, e.g. RunDotCover=true.

We need to configure the exec task. It accepts a single command line. Because it's likely that our executables (dotCover and nunit-console) are in paths that contain spaces, we need to wrap these paths in quotes. In MSBuild that is actually done in an ugly way, using the " escape:

<Exec Command="&quot;$(DOTCOVER_HOME)\dotCover&quot;
     /TargetExecutable:&quot;$(NUNIT_HOME)\nunit-console.exe&quot;" />

Let's define some properties first to keep things a bit neat:

<PropertyGroup>
    <DotCoverOutputPath>$(OutputPath)dotCover\</DotCoverOutputPath>
    <DotCoverExe>&quot;$(DOTCOVER_HOME)\dotCover.exe&quot;</DotCoverExe>
    <NUnitConsoleExe>&quot;$(NUNIT_HOME)\nunit-console.exe&quot;</NUnitConsoleExe>
    <DotCoverFilters>+:MyProject*;-:nunit*</DotCoverFilters>
</PropertyGroup>

The properties we just defined are:

DotCoverOutputPath. The path where dotCover will place its reports. That's typically bin\Debug\dotCover. Notice that we're building on top of the existing OutputPath property, so if we're targeting 64bit build the path will adjust itself to bin\x64\Debug\dotCover.
DotCoverExe. This is the full path of the dotCover.exe. Notice how we're using the DOTCOVER_HOME environment variable.
NUnitConsoleExe. This is the full path of the nunit-console.exe. Again, we're building on top of the environment variable we defined earlier. No need to worry if it's under Program Files or Program Files (x86) or a custom location.
DotCoverFilters. This is going to be used as the Filters argument to the dotCover call. It has a strange syntax (you can read about it in dotCover's help message) that allows you to include or exclude assemblies and namespaces from the final report. The value specified in the above code block says we want to keep anything that starts with "MyProject" and we want to exclude nunit from the report (by default it gets included too).

With these properties, let's see how our AfterBuild target looks like now:

<Target Name="AfterBuild" Condition="$(RunDotCover) != ''">
    <Message Text="Running dotCover" />
    <Exec Command="$(DotCoverExe) cover /TargetExecutable:$(NUnitConsoleExe)
        /TargetArguments=$(AssemblyName).dll
        /TargetWorkingDir=$(OutputPath)
        /Output=$(DotCoverOutputPath)$(AssemblyName).cover
        /Filters=$(DotCoverFilters)" />
    <Message Text="Creating XML report" />
    <Exec Command="$(DotCoverExe) report
        /Source:$(DotCoverOutputPath)$(AssemblyName).cover
        /Output:$(DotCoverOutputPath)$(AssemblyName).xml" />    
    <Message Text="Creating HTML report" />
    <Exec Command="$(DotCoverExe) report
        /Source:$(DotCoverOutputPath)$(AssemblyName).cover
        /Output:$(DotCoverOutputPath)$(AssemblyName).html
        /ReportType:HTML" />
</Target>

We're reusing the AssemblyName property. So if our test project is called MyProject.Tests, we'll end up with a folder bin\Debug\dotCover containing the following:

MyProject.Tests.cover - dotCover's code coverage report (the intermediate file needed to generate the text reports)
MyProject.Tests.xml - the XML report
MyProject.Tests.html (and a subfolder with CSS and JS) - the HTML report

Notice also that the target will only run if the RunDotCover parameter has been set. So by default when you're just building in Visual Studio this target won't get invoked. We'll be passing that parameter through CCNet (short for CruiseControl.NET).

CCNet

Let's now have a look at CruiseControl's configuration.

msbuild task

We'll need a msbuild task in CCNet:

<msbuild>
    <targets>Rebuild</targets>
    <projectFile>$(ProjectName).sln</projectFile>
    <executable>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe</executable>
    <buildArgs>/p:BUILD_NUMBER=$[$CCNetLabel] /p:RunDotCover=true</buildArgs>
</msbuild>

Note that we're passing the RunDotCover argument to msbuild. The /p: syntax is basically that same as if you would invoke msbuild from the command line. That's all there is to it, if we run the build now in CCNet, it will invoke dotCover and it will generate the code coverage report. ProjectName is a variable I have defined to make this block reusable: it's basically the solution name without the sln file name extension. We can do the same for the RunDotCover argument:

<msbuild>
    <targets>Rebuild</targets>
    <projectFile>$(ProjectName).sln</projectFile>
    <executable>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe</executable>
    <buildArgs>/p:BUILD_NUMBER=$[$CCNetLabel] /p:RunDotCover=$(RunDotCover)</buildArgs>
</msbuild>

So we can reuse this block even for projects that don't need dotCover. In that case, we simply won't define the RunDotCover argument in that project's scope.

Using the XML report

It's a good idea to include the report of nunit (TestResult.xml) and dotCover's XML into the build log. This way you can write an XSLT file to present the results nicely in the Web Dashboard. You can do that with a merge publisher.

<merge>
    <files>
        <!-- nunit report -->
        <file>$(ProjectName).Tests$(binDebug)\TestResult.xml</file>
        <!-- dotCover report -->
        <file>$(ProjectName).Tests$(binDebug)\dotCover\$(ProjectName).Tests.xml</file>
    </files>
</merge>

Note that I'm using the ProjectName variable again, assuming that test project is called $(ProjectName).Tests. This is typically the case (e.g. MyProject.Tests) and it shows that if you stick to naming conventions you can easily reuse these blocks in ccnet's configuration file.

Another idea for using the XML report is to fail the build if code coverage drops below a certain percentage. Again, I haven't done this, and it will probably need some custom code (a standard TeamCity feature by the way).

Using the HTML report

Publish dotCover's HTML report in the artifacts folder and you'll get the nice HTML report available through your web server (assuming you're publishing artifacts through the web server that is):

<cb:if expr="'$(RunDotCover)' == 'true'">
    <buildpublisher>
        <sourceDir>$[$CCNetWorkingDirectory]\$(ProjectName).Tests$(OutputPath)\dotCover</sourceDir>
        <publishDir>$(WorkingMainDir)$(ArtifactsDir)$(ProjectName)\dotCover</publishDir>
        <useLabelSubDirectory>true</useLabelSubDirectory>
        <alwaysPublish>false</alwaysPublish>                    
    </buildpublisher>
</cb:if>

What is happening here:

We only invoke this publisher when the RunDotCover variable was set to true. This way we make this block reusable even for projects that don't need dotCover.
There's a $(OutputPath) variable that needs to be defined, same as in msbuild. It's also supposed to contain the bin\Debug path. Keeping the same variable names as msbuild whenever possible is a good idea to avoid confusion.
The publishDir points to the standard artifacts publishing folder, with an extra dotCover subfolder in order to keep reports contained under the same root folder.
The useLabelSubDirectory is set to true so that reports will be divided per build and also we can keep the old reports as a reference.

In my case, the final result is that my pretty HTML report is found at:

http://myserver/artifacts/MyProject/dotCover/1.0.0.0/MyProject.Tests.html

Conclusion

This took a lot of work to figure out and it helped me learn a few things about msbuild and dotCover. In the end, the extra benefit of tools like ccnet is that you'll have to dive into it and in the process you'll learn about a lot of things that you don't normally need to know. On the other hand, the benefit of tools like TeamCity is that you can accomplish these things with a few clicks of the mouse :)

Hope this helps.