All good things, as they say, come to an end. This unfortunately also includes my free SVN hosting service, svn.graffen.dk, that has been running almost non-stop since some time in 2006.

I started svn.graffen.dk as a free hosting service, mostly because no others really existed at the time, and I needed a place to host my own private repositories. It was one of the first services I put online and has by far been the most popular (with more than 1000 registered users, of which about 300 have used it within the past 3 months).

But running a server costs money, bandwidth and time and since I myself have moved on to use other version control systems and haven't used my own service for quite some time, I have decided that it is time to put it to rest. I simply don't have the time or resources to keep it alive any more. 

So that's it. I'll be shutting down the server in about a week's time (end of next week) so if you have anything important on there, please make sure you get it off and put it somewhere else. I can recommend switching to some of the other awesome free services out there, like BitBucket or GitHub. SubVersion is an inferior VCS nowadays anyway ;-)

I'd like to thank you all for using my service - it's been fun watching something I built for fun actually be used by quite a number of people.

So long and thanks for all the fish!

For us .NET/Visual Studio developers, NuGet is definitely the best thing since sliced bread (okay, maybe not, but it sure is great!). If you don’t yet know what NuGet is, it’s basically a package- and dependency manager for Visual Studio and .NET. And if you haven’t started using it yet, you’re doing something wrong

One thing that kind of always bothered me about dependencies is that it’s always been best-practice to have all your libraries checked in to SCM along with your solution. Typically by dumping them in a \Libs folder and referencing them from there.

But source control systems are generally not very optimized for handling binary files, and the size of your repository (and thereby performance) is negatively impacted by dragging around all these DLL files.

With NuGet this is a thing of the past! Using the command line NuGet.exe tool, you can point it at a local config file that tells it which packages to download for you (those of you who already use NuGet are probably already familiar with the packages.config file that lives under each project in your solution).

The only executable file I now have as part of my solution is the latest-and-greatest NuGet.exe which I place in a Tools folder in the root of my solution.

So, to get all this set up in your project, your first step is to create a Tools folder at the solution level of your project. Next, go ahead and grab the latest NuGet.exe from here and put it in your newly created folder.

Now, to each of the projects in your solution, add the following pre-build command:

$(SolutionDir)Tools\Nuget.exe install $(ProjectDir)packages.config -o $(SolutionDir)Packages

Also make sure that the \Packages folder is ignored by yout SCM system of choice (mine is Mercurial) in the same way that you always ignore the Bin and Obj folders.

To test, just delete the \Packages folder from your solution directory and try to do a build. NuGet should now automatically download all the dependencies you have and place them back in \Packages. It takes a little while to run the first time, so don’t panic if nothing happens for a few seconds. If it works and the build succeeds, go ahead and commit everything to source control. You can now continue working without the burden of large unsightly DLLs littering your source repository.

Okay, so while working on the syslog target for NLog, I of course studied the syslog RFC to properly be able to send messages in the correct format.

A syslog message always starts of with a PRI field which is a composite of a Facility number and a Severity number. Facility numbers range from 0 to 23 and Severity numbers from 0 to 7:

enum SyslogFacility
{
    Kernel = 0,
    User = 1,
    Mail = 2,
    Daemons = 3,
    Authorization = 4,
    Syslog = 5,
    Printer = 6,
    News = 7,
    Uucp = 8,
    Clock = 9,
    Authorization2 = 10,
    Ftp = 11,
    Ntp = 12,
    Audit = 13,
    Alert = 14,
    Clock2 = 15,
    Local0 = 16,
    Local1 = 17,
    Local2 = 18,
    Local3 = 19,
    Local4 = 20,
    Local5 = 21,
    Local6 = 22,
    Local7 = 23
}

enum SyslogSeverity
{
    Emergency = 0,
    Alert = 1,
    Critical = 2,
    Error = 3,
    Warning = 4,
    Notice = 5,
    Informational = 6,
    Debug = 7
}

Okay, so to generate the PRI field, we first multiply the Facility by 8 and then add the Severity.
Example:
A message with Facility Local3 and Severity Error gives the following:

19x8+3=155.

So the PRI field in this syslog message would contain the value 155, letting the syslog server identify how to categorize the message.

Now, when the syslog server receives the message, a relatively simple operation allows the server to identify the Facility and Severity of the message.

To find the Facility, the PRI value is run through a bitwise right-shift three times, which leaves us the correct value (19)

int intFacility = intPri >> 3;

To find the Severity, the PRI value is run through an AND 0x7. This again leaves us with the correct Severity (3)

int intSeverity = intPri & 0x7;

My question is not so much how this works (I’ve done the maths on paper and yes it works) but WHY. I just don’t get the mechanics of it.

Why exactly right shift 3 times and why exactly AND 0x7 – how are these two numbers established?

Could I use a similar method to build my own little system containing two parameters with an arbitrary number of values in each? If so, is there a simple way of telling how to first combine the two into a single value for transmitting over the wire, and then how do I figure out how to get back to the two original values, knowing only the combined value and the number of possible values in the two lists?

If someone can explain this to me in relatively simple terms, I’d be really happy (I might even buy you a beer!)