New version of NLog released

In July last year, Jarek came with the announcement, that he would stop actively developing NLog and needed someone to take over. I thought it would be shame if one of the best logging frameworks for .NET died, so I started developing and maintaining.

This was half a year ago, and the last release were almost 2 years ago, so now it is time for a new version of NLog, version 2.0.1. This is purely a bug fix release, so everyone using NLog 2.0.0.2, should be able to upgrade to the new version.

For those interested in what has been fixed in v2.0.1, take a look at milestone 2.0.1 on GitHub. The new release can be downloaded from NuGet.

Chain of Responsibility "Monad"

Most of us know design patterns, and most of us know Chain of Responsibility.

In my opinion this is a very useful pattern, but a lot of the implementation found online, have this feeling of oldness upon them.

The text book example is something like:

To me this seems old school. Sure it works, it's readable and well documented, but wouldn't you like something more like this instead?

At least I like it much better, and that is the most important :)

So how is this implemented? Well it is pretty straightforward, it consists of:

• ChainElement<TOutput> which contains the result and whether it was handled or not.
• IChain<TInput, TOutput> which is an interface defining a single part of the chain.
• ChainExtensions which contains extension methods for chaining.

The whole implementation can be seen below:

The magic happens in the extension methods, it basically allows you to build a list and feed it an input until it's handled.

A handler could be implemented like this:

By: Kim Christensen

QueryAll in RavenDB

RavenDB is an awesome NoSQL product, if you don’t know it, I strongly suggest you take a look at it. It tries to be safe by default, which is at great idea, but sometimes you just need to get more than 1024 documents. Yes, this could indicate a misuse of RavenDB, but again sometimes it is needed, and the only way to do this in RavenDB is to use paging.

It is easy enough to do paging, but it requires some code and could easily be implemented in an extension method like this:

It extends an IRavenQueryable with a QueryAll method which uses paging to get all results of the query.

It should be use with great care, this totally circumvents the safe-by-default design implemented in RavenDB, and the results are iterated when calling QueryAll, so after this call the database aren’t hit anymore. Use it as you please, but be careful, it can ruin performance and should only be used when strictly necessary.

Inside the MvcSiteMapProvider - Part 5: The ISiteMapNodeUrlResolver

• Inside the MvcSiteMapProvider - Part 1
• Inside the MvcSiteMapProvider - Part 2: Dynamic node providers
• Inside the MvcSiteMapProvider – Part 3: The ISiteMapVisibilityProvider
• Inside the MvcSiteMapProvider - Part 4: The IAclModule
• Inside the MvcSiteMapProvider - Part 5: The ISiteMapNodeUrlResolver

The ISiteMapNodeUrlResolver defines how URLs are resolved. The default URL resolver are fine most of the time, as it uses the different ways to resolve URLs built-in to ASP.NET MVC. But sometimes it is necessary to create a custom resolver, for example if all URL are required to be lower or upper case. In this post I’ll try to explain exactly how the default resolver works and how to implement a custom resolver.

Inside the MvcSiteMapProvider - Part 4: The IAclModule

• Inside the MvcSiteMapProvider - Part 1
• Inside the MvcSiteMapProvider - Part 2: Dynamic node providers
• Inside the MvcSiteMapProvider – Part 3: The ISiteMapVisibilityProvider
• Inside the MvcSiteMapProvider - Part 4: The IAclModule
• Inside the MvcSiteMapProvider - Part 5: The ISiteMapNodeUrlResolver

The IAclModule extension point in MvcSiteMapProvider, are just like the ISiteMapVisibilityProvider very useful and easily implemented. It allows you to control which nodes are accessible to users. The default module checks for [Authorize] attributes on action methods and the roles attribute defined in the sitemap XML. The documentation lacks some information about the role attribute, and some about the creation of the actual module, this will be addressed in this post.

Inside the MvcSiteMapProvider - Part 3: The ISiteMapVisibilityProvider

• Inside the MvcSiteMapProvider - Part 1
• Inside the MvcSiteMapProvider - Part 2: Dynamic node providers
• Inside the MvcSiteMapProvider – Part 3: The ISiteMapVisibilityProvider
• Inside the MvcSiteMapProvider - Part 4: The IAclModule
• Inside the MvcSiteMapProvider - Part 5: The ISiteMapNodeUrlResolver

This part is all about the ISiteMapVisibilityProvider in the MvcSiteMapProvider. The usage is well described on the “Advanced Node Visibility” wiki page, and is very easy to use.
Ever wanted to only show specific sitemap nodes to authenticated users or only unauthenticated? With a specific role? All this can be done in 5 minutes with the ISiteMapVisibilityProvider.

Inside the MvcSiteMapProvider - Part 2: Dynamic node providers

• Inside the MvcSiteMapProvider - Part 1
• Inside the MvcSiteMapProvider - Part 2: Dynamic node providers
• Inside the MvcSiteMapProvider – Part 3: The ISiteMapVisibilityProvider
• Inside the MvcSiteMapProvider - Part 4: The IAclModule
• Inside the MvcSiteMapProvider - Part 5: The ISiteMapNodeUrlResolver

Dynamic node providers gives you the ability to add dynamically generate nodes to the sitemap, fx. pages generated from a database. This is one of the most used extension points in the MvcSiteMapProvider, and it is also easy to implement.