Development

It’s been a while since I’ve started using StyleCop in my projects. Last year I managed to sneak it in to my company’s projects as well. Applying it to existing projects and fixing all the errors was a tiring process at first but I believe it was worth it. It really helps for consistency. Regardless of the developer of a certain block of code it’s very easy to read it because everybody has to adhere to same rules across the company. Here are a few tips to manage this:

01. Force StyleCop warnings to be treated as errors. I hate warnings completely actually. That’s why I set treat warnings as errors to All on the projects I work on. This helps to eliminate many potential bugs before they become an issue.

Treat warnings as errors

Unfortunately, StyleCop errors are not included in this. But with a little tweak we can turn on this feature for StyleCop warnings as well. Just add the following line to your project’s .csproj file inside the first PropertyGroup tag:

<stylecoptreaterrorsaswarnings>false</stylecoptreaterrorsaswarnings>

The wording is the opposite of Visual Studio’s (treat errors as warnings instead of the other way around) so we have to set this to false. After reloading the project, you won’t be able to successfully build your project without fixing all the StyleCop rule violations (which is a good thing!)

02. Integrate StyleCop to MSBuild Naturally if the process is not automatic it won’t work. If, as a developer, it’s left to me to right-click on the project and run StyleCop manually I’d forget it after a few times. The easiest way to integrate it with MSBuild is adding StyleCop.MSBuild NuGet package to your project. Alternatively if you have installed full StyleCop application you have StyleCop.Targets file under your installation directory. By adding that file to the project you can achieve MSBuild integration.

For multiple developer environment it’s best to use a fixed path so that when someone new starts working on the project they can still build the project. To accomplish that, we mapped R drive to a folder that contains the targets file so that the build doesn’t break. Of course needless to say new developers have to do the mapping to make this work.

03. Run StyleCop on the server as well The problem with manually enabling treating warnings as errors feature on the developer system is that it can be easily forgotten or can be temporarily disabled for some reason. When the developer forgets to re-enable it,he/she can check-in code that violates code convention rules. To avoid that we should reject code on the source control during the check-in process.This is where StyleCopSVN comes in. Of course as the name implies this solution works only for SVN. I haven’t yet looked into other source control systems like Git or TFS for this feature yet. You can get SVNStyleCop here: http://svnstylecop.codeplex.com/

The way it works is quite simple and the official page has a good tutorial about it. Mainly you override the pre-commit hook and run StyleCop from before the code is submitted. The problem with this is that you have to maintain a separate copy of rules and StyleCop files so when you update your rules you have to remember to update it on the server as well.

04. Use symbolic links to maintain one global rule set Windows Vista (and above) comes with a handy utility called mklink. By entering the following command you can create a symbolic link to Settings.StyleCop file anywhere you please.

mklink /H Settings.StyleCop {Path for the actual file}

This way all projects are going use the same settings file. The problem is it’s a tad cumbersome especially if your project involves lots of projects.

05. A better approach for one rule set to rule them all I was pondering for minimizing user efforts to deploy StyleCop and it hit me! Our beloved NuGet could take care of it as well. StyleCop has already a package in the official NuGet repository but the problem with it is that it comes with its own StyleCop rule file so it’s not quite suitable for a team environment. Even not for a single developer because all projects will have different rules and it can quickly become a maintenance nightmare. The idea of using NuGet is creating a package that contains StyleCop rules and libraries. When the package is installed it copies the libraries, rules and targets file under the project. Also an install script can be used to add the import project and treat warnings as errors settings mentioned in tips 1 & 2. The advantages of this method are:

  • All projects installing the package will be using the same rule set downloaded from server
  • MSBuild integration is done automatically
  • Treat warnings as errors update is done automatically
  • No configuration needed (i.e: Mapping drives, creating symbolic links etc)

The disadvantage is if rules are updated the package needs to be re-installed for he projects. It’s still not perfect but compared to other methods I think it’s a neat way of distributing and enforcing StyleCop rules.

Tips & Tricks

I like Windows Live Writer and I use it for blogging. The problem is I start multiple posts at once, take some notes on them and save them as drafts. Sometimes when I’m on a different machine I want to add some notes on the existing drafts but (you guessed it) the drafts are saved locally on a different machine. I already have Dropbox installed almost on my machines so I decided to harness it to the task.

STEP 01: Delete the My Blog Posts folder in the destination machine. The local folder is created automatically under %UserProfile%\Documents\My Weblog Posts. Delete this folder. Make sure LiveWriter is closed before deleting it.

STEP 02: Create a directory junction A directory junction is a mapping to another folder. In Windows 7 you can use mklink command to create directory junctions (as well as symbolic and hard links)

mklink /D "%UserProfile%\Documents\My Weblog Posts" {PATH_TO_DROPBOX_ROOT}\My Weblog Posts"

Enter the correct path to your dropbox folder and that’s it. Now you can enjoy the ease of synchronized blog drafts.

Security

I learned a neat trick to force Windows check a USB device plugged in to be able to log on the system. The tool to use for that is syskey, an ancient tool introduced to Windows with Windows NT SP3. Here’s how to do it:

  1. Insert your USB drive. As syskey only supports floopy disk change the drive letter to A.

  2. Run syskey (From command prompt or by pressing WinKey + R then entering syskey)

  3. Select Store Startup Key on Floppy Disk

SysKey

After you restart the machine, Windows will check your “floppy” USB drive and if it is not there it will display the error message: “This computer is configured to use a floppy disk during startup. Please insert the disk and click OK”. After you insert the disk you can logon by entering your password.