There are different approaches to localizing an ASP.NET application. You can use a global resource file or local ones. The local resource files only applies to a single page or user control, whereas the global can be used from anywhere.

I’ve always used the global resource file located in the App_GlobalResources folder. I like that I can use all the text strings wherever I want. However, I have never used a local resource file for a specific page or user control for that very same reason.

Lately though, I’ve thought that the local resource file might be good for some specific scenarios. For instance if I know that a particular string is only going to be used on one specific page, then I don’t clutter the global resource file with page specific strings. However, then the information is spread over multiple files instead of just the global ones.

It reminds me about HTML style attributes and stylesheets. Is it ok to hardcode styles directly onto a page if the same style is not being implemented anywhere else? In my opinion yes, sometimes it makes sense, but I’m generally against it just like I’ve been against using local resource files.

Do you use local resources and if so, why have you chosen that instead of a global file?


You have probably read all there is to know about getting people to link to your blog before, and this post doesn’t tell you anything you don’t already know. This is merely a nice trick to get many people to link to you, without having to do much work.

Basically, the more people who links to you, the higher your blog ranks in search engines. There are many details to this, but that’s a totally different story written by much smarter people than me.

The trick

This has worked extremely well for me for a long time and it is very easy to pull off. It works no matter what blog platform you use.

You probably have designed your own theme or modified an existing one for your blog. It probably looks really nice too. That’s exactly what Tom Watts thought about my old theme for dasBlog and therefore asked me if it was ok that he included it into the next release of dasBlog. Of course it was. At that point I had already made the theme available for download for anyone interested and a lot of people actually did (I can’t imagine why).

The trick is that I added a piece of text to the bottom of the theme which linked back to my own blog. It looked something like this:

dasBlog theme byMads Kristensen

That sweet traffic

Almost from one day to another, people started to use my theme and links started coming in. After a couple of months when the search engines had done their indexing, my blog got much better ranking because of all the links.

Now I receive a lot of search engine traffic as well as general link traffic and I can thank the theme for a big part of it. So, now you might wonder how to get your theme included in your blog platform of choice.

Get your theme out there

Many of the smaller and mid-sized blog platforms such as dasBlog, Subtext and BlogEngine.NET are probably more than willing to include a nice theme because they might not have that many and they all want to offer as much out of the box as possible. Just write to them and ask if they are interested in including your theme.

For the big platforms such as WordPress and MovableType you probably can’t get your theme bundled. Instead you can add your theme to the various theme sites where people can download themes and also have the download available on your own blog.

It is very easy to get your theme out there with a little effort and the results are noticeable.

For BlogEngine.NET users

After the next release scheduled for this Monday, we are going to release a theme pack with all the themes that didn’t make it into the final release. If you have written a nice theme then we can include it into that pack and into future versions as well. Just remember to add a discrete link to your own blog somewhere.


BlogEngine.NET is designed to be simple and transparent, so that anybody can use all the features in their theme design or extensions without looking to hard for them. All the events can be subscribed to and all properties are exposed on every page or user control in the themes.

However, there is one little feature that hasn’t been announced anywhere – one that most people don’t care about but can mean everything to others.

JavaScript conversion events

A conversion is when a visitor performs an action you would like them to do. In a blog platform it usually means that it is when someone writes a comment or rates a post. Many different web analytics applications such as Google Analytics or Headlight can collect and analyse those conversions by calling a JavaScript function.

When a comment is added or a visitor rates a post, then two different JavaScript functions are called if they exist. The two functions can be added directly to the theme’s master page or added in the tracking script textbox in the admin section.

Adding the functions

To be notified when someone adds a comment, just add this method anywhere in the theme’s master page or in the tracking script textbox under settings in the admin section.

function OnComment(name, email, website, country, body)
   // Do something… 

And to catch when someone rates the post, add this method:

function OnRating(rating)
  // Do something…

This is not part of the BlogEngine.NET 1.0 release, but it had been part of the source code for a couple of months now. So, if you have the latest source from CodePlex, then you can take advantage of this feature already today. If not, wait a week for the next official release.


I’ve received quite a few e-mails about my last post about unit testing and have followed some reactions around the blogosphere as well. There seem to be common believe that I don’t like unit testing or advice against it. This was not the intent.

I know the post sounds very much against unit testing, but that is just poor semantic skills from my side. To sum up what I really meant; here it is:

Unit testing is very useful in some scenarios, but is overkill in others.

Now you might be thinking: So how do I know when unit testing is overkill? The short answer is experience.

If you have enough experience to fully understand the scope of your project and find that you have done similar things many times before successful, then you know. It’s that simple.

When in doubt, unit test - you can do it in a console.


I was asked to write a post about my views on unit testing because it is a hot subject at the moment.

I’m very ambivalent about unit testing and always have been for many different reasons. Although testing is very important, I often find unit testing to be a time consuming liability but it depends on the project.

Good for static classes

Over the years I’ve build many helper class libraries which is used in many projects and can be considered as business independent fundamental classes. All the classes in those libraries are static and therefore cannot be considered to be entities, but merely a logical placeholder for static methods that works independently.

To unit test such libraries is a must have. They are simple to write and maintain and unit testing is important because the libraries are used in a vast amount of different projects.

Object orientation and business entities

A unit is the smallest testable part of an application which means that for object orientated applications/libraries it will always be a class or business entity. Of course you can test the individual methods, functions and constructors but it doesn’t make much sense since the business entity is to be considered as a single unit and also works as such in real scenarios.

For me it makes more sense to conduct use-case testing on business entities. It works much like unit testing, but is constructed so they test a complete flow of operations on the class. For instance, if I had a class called Dog, then I would write a use-case test that simulated how a real person would use the class. First Feed the Dog, then Pet it and then Walk it before it needs to Sleep.

For that purpose it doesn’t really matter if you use unit testing frameworks such as xUnit or write it in a console application in the same Visual Studio solution. I like both approaches equally, but most often write a console application because I find it simpler.


Financial applications used by banks or government applications needs to be tested extremely well. Those types of applications deal with people’s personal data and money and must never ever fail. The same goes for applications that ships on CD's or DVD's unless they are updated automatically over the Internet.

There needs to be automatic tests running every day and both unit testing and use-case testing is very important. The 80/20 rule does not apply here; it needs to be as close to 100% code coverage as possible and each class needs to be use-case tested for dozens of scenarios.

To test this properly you need professional testers and QA’s because the test is as important as the application itself.

What about no test

The most common thing is to have no test but the application itself. Admit it; you do this all the time as well. Is it a dumb idea to use the application to test its dependent libraries and itself and not doing unit or use-case testing? No it definitely is not. The end user application/website is the ultimate test, but there is a serious problem with not having an automated test harness. If an error occurs you can spend more time finding the problem than it takes to fix it. For smaller projects though, I find it perfectly acceptable to test from the GUI without a test harness.

Also, it is very difficult to test GUI’s automatically so it will be a good idea in most cases to use a test harness for every project in the application stack and then create a procedure for testing the actual GUI. In most cases it has to be done by humans manually.

Test driven development

TDD is one of the hyped methodologies that I never really understood. I can’t get my head around writing the test before the class it tests. In C# it doesn’t make sense to me, because if I write a test to call a non-existing class and its methods and properties, then it will not compile. Then when I write the actual class I often compile to check for errors. That doesn’t work either, because the test references some methods I haven’t written yet and as so cannot compile.

Besides, in most cases I don’t know 100% what properties and methods the class needs and which of them is public or private. Then I need to get back and change the test and thereby looses the point of writing the test before the class.

User driven development

For smaller projects with few dependencies user driven development is for me the best way to test. Consider a rather small project like BlogEngine.NET with one web project and one class library. The class library is only used by the web project and nowhere else. That means that the class library has no classes, methods or properties that is not used by the web project so by testing the web project, the class library get’s 100% code coverage.

If a new feature needs to be implemented in both the web project and class library I use the web project to test the class library. That’s because I’m as much a user as a developer of the project. If you are not the end user, then you should test as much as you can on the web project and then get a co-worker or the customer to test when you feel confident it works. It’s always a good idea to let the customer test as early in the process as possible.

Simple code is simple to test

If you always make sure your code is simple, clean and refactored, then testing is equally simple to write. Complex code needs complex testing and the maintenance of the tests will increase with every change to the code. Every time you change a little thing, you need to rewrite many tests if your code is complex. That goes for both unit testing and use-case testing.


I find unit testing to be good for very few types of projects – helper class libraries and never-fail-applications. User driven development with use-case testing is my absolute favourite. I don’t see the big difference in using a xUnit framework or using a console application, because you only get the benefit from a test project when something fails. For automatic testing though, you need a testing framework that logs the results.

This is how I would manually test different projects.

  • Helper class libraries – unit testing in xUnit or console by the 80/20 rule
  • Never-fail-applications – automatic unit and use-case testing written by QA’s. Full coverage
  • GUI’s – test yourself, then a co-worker and then let the customer test
  • Business object layer – use-case testing in xUnit or console by the 80/20 rule
  • Data access layer – unit test in xUnit by the 80/20 rule

Again, it is very important to note that it all depends on the type and size of the project. If you don’t have a build- or versioning server to handle automatic unit testing, then you have to do it manually. If you have the ability to automate unit testing, a xUnit framework is the way to go but full code coverage is not always necessary and not all projects need unit testing.