I'm always looking for new tools to add to my developer's toolbox. One such tool I recently came across is StyleCop for ReSharper.

StyleCop for ReSharper is a ReSharper add-on that enables real-time syntax highlighting of StyleCop rules. Normally, you run StyleCop by selecting "Run StyleCop" from the Tools menu:

The StyleCop for ReSharper takes it one step further by providing the same analysis, but in real-time and with squigglies:

The first thing you'll notice is that every single line has been flagged for violations! That's kind of ridiculous. Fortunately, there's a quick way to reduce that count by loosening up the rules a bit.

Prerequisites

Of course, to use the StyleCop for ReSharper add-on you'll need to have ReSharper. Also, if you attempt to install the add-on without first having installed StyleCop, you'll see this dialog:

The latest version of StyleCop can be downloaded here.

Loosening up StyleCop's Rules

Before we start modifying the default rules, let's learn how to share a single StyleCop settings file across multiple solutions or projects.

StyleCop starts looking for a Settings.StyleCop rules or settings file in the project's local folder first. Regardless of whether it finds one or not, it works up the folder tree, looking for other copies of the file. Once it reaches the top of the chain, it goes back to the default install folder where there should always be a the global version of the file. It is possible to override the global settings by placing a copy of Settings.StyleCop in the local solution or project file. Also, you can have global settings which are overridden by solution-level settings which in turn might be overridden by project-level settings. All depends on how granular you want to get with your rules.

Personally, I only maintain a single Settings.StyleCop file for all of my projects and solutions by putting the file at the development root (d:\dev).

You'll find the global copy of Settings.StyleCop here:

Copy that into your development tree, then double-click on it. That will bring up the StyleCop Project Settings editor:

If you expand the "Enabled rules" nodes you'll see all sorts of rules that you can turn off.

Rules I Can Live Without

Here is the list of rules that I operate without. I'll add to this list as I get further into StyleCop's rule set. In general, I'm trying to adhere to the rules as given, but some of them are just a bit too nitpicky for my tastes.

Rules Off By Default That I Use

The other side of turning off default rules is turning on some that are off by default. Here are those:

Conclusion

If we take a look at the code snippet from above we'll see that the squiggly-indicated violations have gone way down:

Still have some work to do, but at least it's a bit more manageable and realistic.

This is the next part in an ongoing series about setting up a continuous integration system. The series includes:

1. Part 1: Introduction
2. Part 2: Project Folders
3. Part 3: CI Workflow
4. Part 4: CI Server Baseline Software (this post)
   
5. Part 5: CruiseControl.NET Custom Plug-in: Update Version 
6. Part 6: CruiseControl.NET Custom Plug-in: Source Retrieval
7. Part 7: Installing CruiseControl.NET and Custom Plug-ins
8. Part 8: Configuring CruiseControl.NET
9. Part 9: Conclusion

I've covered some of the basics of setting up a continuous integration system thus far: how I set up my development project folders and the general workflow of my CI environment. Now, I'd like to start getting the CI server setup with a run through what I consider baseline software for a build server.

Core Components

In order of installation, here are the "core" pieces of software installed on my CI build server (which runs Windows Server 2003). I consider these core because they're really the absolute minimum you can get by with in a CI environment.

Visual SVN Server / Tortoise SVN 

See my post on installing Visual SVN/TortoiseSVN.

CruiseControl.NET 

CC.NET is, of course, the core of many CI environments. It's the CI workflow engine, coordinating and firing off the necessary events to build source, run unit tests, etc. I'll delve into configuring CC.NET in my next post in this series.

CruiseControl.NET Add-ons

CC.NET has an extensible plug-in architecture. I have leaned on others' work for plug-in's to retrieve source from TFS or VSS, and have written my own to handle version updating (check out assemblyinfo.cs, update assembly version, check-in). I'll detail each of these as part of configuring CruiseControl.NET.

Visual Studio (VS2008 + VS2008SP1)

Why do I install Visual Studio on my build machine?

There's really two reasons for this:

1. There was a time when MSBuild (which comes with .NET; look in "\Windows\Microsoft.NET\Framework\v3.5") would not build setup (.vdproj) projects. Unless this has changed, Visual Studio is required to build setup projects.
2. I sometimes have to load up a project and do a build as I would on my development machine, sometimes just for sanity's sake. While I don't do development tasks on my build machine, having Visual Studio on there is a huge timesaver when things get a little screwy.

If you're using TFS for source control (like we do at my place of employment), you'll also want the TFS Explorer component. One nice thing about TFS and SVN is that they seem to play well with each other, or at least they stay out of each other's way.

Silverlight 3 Tools for Visual Studio 2008 SP1

If you're going to build Silverlight projects, you probably want the latest Silverlight Tools for Visual Studio. The alternative is having to pull dll's from the default install folder and putting them into a project or solution specific imports folder.

CI Utilities

These are key pieces of software, not necessarily 'core', but very nearly as important because of the functionality they provide. Any good CI environment isn't complete without at least some of them.

NUnit 

NCover

I use the free version that comes with TestDriven.NET.

FxCop

TestDriven.NET

Not necessary for CI, but helps with debugging unit tests (which, as stated above under Visual Studio, is sometimes a necessity or at least a timesaver).

7-zip

My command-line zip utility of choice. 

Optional Utilities

Beyond Compare

Sometimes you need to compare two files or a set of directories. This is one of the best comparison tools out there.

Conclusion

Those are the components and utilities I use as a baseline on my CI server. Next couple of posts I'll take a look at some custom CC.NET plug-in's I use as part of my CI process.

This is the next part in an ongoing series about setting up a continuous integration system. The series includes:

1. Part 1: Introduction
2. Part 2: Project Folders
3. Part 3: CI Workflow (this post)
4. Part 4: CI Server Baseline Software
5. Part 5: CruiseControl.NET Custom Plug-in: Update Version
6. Part 6: CruiseControl.NET Custom Plug-in: Source Retrieval
7. Part 7: Installing CruiseControl.NET and Custom Plug-ins
8. Part 8: Configuring CruiseControl.NET
9. Part 9: Conclusion

Before I actually start configuring my CI server I first wanted to present the general workflow my CI process follows.

Continuous Integration Workflow

With the CI environment (server) up and running, the initial action is always a developer checking in source. From there, the CI process is completely automated up until we either hit an error or complete successfully.

On success, the output is, of course, a release candidate set of files. I generally produce many release candidates, but just because the CI environment has produced one doesn't mean I'm going to do a production release. But I always have confidence that I could deploy a particular release candidate because I know it has gone through my unit and integration testing wringer and come out squeaky clean.

Conclusion

My CI workflow no doubt differs from your own; the process is not a "one size fits all" sort of thing. If, however, you've got something I've completely missed, let me know. I'm always looking to enhance or improve my CI process.

Next post, let's start configuring our CI server.

This is the next part in an ongoing series about setting up a continuous integration system. The series includes:

1. Part 1: Introduction
2. Part 2: Project Folders (this post)
   
3. Part 3: CI Workflow
4. Part 4: CI Server Baseline Software
5. Part 5: CruiseControl.NET Custom Plug-in: Update Version
6. Part 6: CruiseControl.NET Custom Plug-in: Source Retrieval
7. Part 7: Installing CruiseControl.NET and Custom Plug-ins
8. Part 8: Configuring CruiseControl.NET
9. Part 9: Conclusion

One of the fundamental aspects of a good continuous integration—even just a local dev environment—is the structure of your project folders. This is a fairly subjective topic as individuals or development groups each have their own philosophy. Here, and without further adieu, I present mine.

Software Development Folder Structure

* = does not get checked into source control

• <drive>: I default to the D drive if I have one. Otherwise, C.
  • archive: This is my project junkyard, for projects I no longer maintain or use, but which I can't quite bring myself to delete.
  • cc.net
    • config: CruiseControl.NET's config file(s) goes here.
  • doc: This is a good place for general software development documentation, best practices docs, or process and procedures sorts of documents. A copy of this post will likely wind up there.
    • images: Contains supporting images for docs found in the doc parent folder.
  • resources: These are resources that span multiple products/projects, like a company logo, for example. You might need or want more than just the sub-folders I currently have defined.
    • icons
    • images
  • sandbox: My development sandbox. This is the ultimate in junk drawers, where anything goes. I dump sample code here, as well as 'trial and error' types of projects. None of it is ever checked-in. If I do want to check something from here in, it gets moved into a solutions folders.
  • setup: This is an environment-wide area for any utilities, batch files, etc. I use to setup my development or build environments. The batch file (download below) that creates my initial folder structure lives here, for example.
  • solutions:
    • Widget (this is just a generic project name placeholder; rename as needed) This is where the .sln file lives. Individual projects then exist under the projects sub-folder.
      • backup: Sometimes I like to take zip file snapshots of my source, or I might have a version of some file that I want to hang on to separate from its source control location. Think of this as a generic project backup folder.
      • bin: This is where all build modules, debug and release, are emitted.
        • ccnet: This exists solely for CruiseControl.NET's benefit as I direct all cc.net output to the listed sub-folders.
          • artifacts: cc.net build artifacts.
            • buildlogs
              • debug
              • release
            • ncover: NCover files produced during cc.net's build.
        • WidgetControl
          • debug
          • release
        • WidgetService
          • debug
          • release
      • db: If there are any schemas (to create the database, for example) or stored procedures that go along with the project, they go here.
        • schema
        • sproc
      • deploy: If the project supports automatic deployment, especially as part of the CI environment, then any batch or script files needed for this process go here.
        • batch
        • scripts
      • doc: This is for project-specific documentation, such as technical or design specs, or usage guidelines.
        • images
      • imports: Any external assemblies the project consumes go here. By default, this typically includes such things as NUnit or log4net. I typically create sub-folders for each import, especially when there are two or more dll's to consider.
      • projects: The root folder for individual projects that live under this solution.
        • WidgetControl: Individual project files (.csproj, for ex.) as well as source files go here.
        • WidgetService
      • releases: As part of my CI environment I always zip up release candidate files (source + build modules) and put them here. Each zip is named with the appropriate cc.net determined version number.
      • test
        • artifacts: So far this winds up being a repository for any files my integration tests require. Not all projects have integration tests, so not all project use this folder
  • tools: This is where, broken down by sub-folder, every tool, gadget, utility, add-on, etc. that I use either for development or as part of my build environment, goes. This might include CruiseControl.NET, NUnit, ReSharper, etc. Basically any piece of software that I might need to download and install in order to restore my build environment or machine. There are varying philosophies on this approach:

Conclusion

That's my development folder structure. You can download the .bat file I use to create the initial structure (this is typically done only once), or tweak it as you see fit.

Next post in this series I'll be talking about continuous integration process workflow.

Download: MkProjFolders.zip