Centralised Version Control (VCS) providers like TFS and SVN always rely on a central server to store and maintain your project’s source control assets. While Git is an example “distributed” version control (DVCS) it is still most commonly used with developers relying on a central store for everyone to push and pull commits to and from. There are a number of options are your disposal so let’s take a look.

Few generations get to see as many epic battles for mindshare as our recent generations – in the 80’s it was VHS and Betamax and this decade we’ve seen Git and Mercurial duking it out. Developers have voted with their commits, and I’m pretty sure Git won the war. When setting our to use Git there are lots of basic tutorials, but none that approach it from a zero-to-hero in a team environment. In this blog series I am going to trying to set out to change all that by walking you through the steps from working in a non-Git source control environment to using DVCS with other people.

I’ve been lucky enough to get my hands on a Lenovo ThinkPad X240 test device for a review. Lenovo has been making a number of changes to their line of business notebooks recently, and I wanted to get in and get my hands on one to check it out, as a developer first and foremost and a ThinkPad zealot second. The changes made to the new line of devices are numerous – some changes awesome and innovative, while others leave you pondering the overall direction. Will I be buying one? Read on the find out.

Sometimes your ASP.Net sites crash or hang, and you have no idea why. No exceptions, no event logs. This leaves you a little light on places to start your debug investigation journey. Microsoft Developers who live a little closer to the metal (i.e. non web developers) will know of tools like WinDbg, but for web developers these tools can seem a little scary/low level. This post is aimed at allowing you to get a closer view on your ASP.Net website at the time of a failure, without any of complexity of learning WinDbg on your own.

In years past building Visual Studio Extensions have often been considered the realm of the big boys. Staff working at Jetbrains or the Microsoft employees of the world. Last year I saw a talk given by Mads Kristensen aimed at taking away some of this stigma and showing how easy the guys at Microsoft have tried to make it for developers like you and me to just up and write extensions. I’ve been wanting to build one ever since, but haven’t had a good enough excuse to jump right in – until now. Here follows the creation of “OnCheckin Web.config Transformer”.

When writing forms for your ASP.Net MVC websites the common approach to ensuring only real people use them site is to simply add an Html.AntiForgeryToken() to your form’s view mark-up and controller and be on your way. I've recently found out this approach while simple, can actually have pretty serious affects on both how your visitors use of your site as well as their view of it’s professionalism and stability – two things you really don’t want any trouble with.

In web and software development we all know what it’s like to finish a project and have it leave a bad taste with either your team or your stakeholders. Often left with thoughts of “if we’d just had time to slip that last feature in”, “I wish we’d understood that requirement earlier. or even worse “I wish we’d given that more testing time”. The problem is that as humans we’re incredibly good at this kind of thinking, but by using Agile processes to change this thinking both your development team and stakeholders alike will be a much happier bunch.

The past year has been a crazier year than most for me. I moved jobs to working in publishing where I've created a new thriving user group within the very company (post to come soon), launched the most awesome way for ASP.Net web developers to deploy their sites and generally loved being a developer for another 365 days. Our jobs are made so much easier by the online contributions of others, and moving into another year we get a chance to give something back.

Over the past two weeks I've begun moving a lot of my hosting infrastructure onto Microsoft Azure. This has consisted of all sorts of configuration – virtual networks, VPN's, backups, servers, databases and sites. One of my sites uses Code First Migrations at it's core, and during the migration simply nothing would work. After much pain and frustration I made the worst mental leap a developer can make: I came to the simple conclusion that is was everyone else's fault. Like most of these kinds of problems, I was to blame all along.

When configuring an Azure Virtual Network one of the most common things you'll want to do is setup a Point-to-Site VPN so that you can actually get to your servers to manage and maintain them. Azure Point-to-Site VPNs use client certificates to secure connections which can be quite complicated to configure so Microsoft has gone the extra mile to make it easy for you to configure and get setup – sadly at the cost of losing the ability to connect through the command line or through PowerShell – Let's change that.