A place for spare thoughts


Checking solutions and project files against some set of rules at build-time

Filed under: MSBuild, Unit testing, VisualStudio — Ivan Danilov @ 04:23

Currently I’m busy with multi-solution project. There’re several teams on the project and each team works on one or several solutions. Sometimes together, sometimes not. There are network of dependencies between solutions (e.g. some shared library that is produced as build artifact of one solution and used by two other).

Clearly that we have some set of rules how things should be organized. And this set at some stage became complex enough to be almost unmaintainable manually.

For example, each project should contain property named OutputRoot defined relative to $(SolutionDir) and OutputPath should be relative to it. Thus we achieve that every artifact is placed to some well-known place under OutputRoot which could be redefined from msbuild command line.

Or the rule that requires HintPaths properties for references should be relative to that $(OutputRoot) or $(SolutionDir). So that no one could place absolute path there that will work only in his environment. Well, it could work on others machines as well by some lucky accident. But build robustness is not that sort of things we want to have by accident.

Also there’s some general rules:

  • every C# project (*.csproj file) should belong to the solution and only one;
  • solutions can’t be nested so if some folder has *.sln file – entire tree from this point should have to other *.slns;
  • ProjectReference couldn’t point outside of solution directory or have absolute path;
  • every project should have property TreatWarningsAsErrors with value true;
  • if Deployment project exists in solution – every other project should have reference to it;
  • test projects (we are using convenience that test projects should be named like *.Tests) are marked with corresponding guids so that test runner can run them;
  • etc…

And so the idea of having some kind of source checker was born. In fact, *.sln and *.csproj are not very complex formats to parse. And we’re not going to support every possible thing in them. We want only to read and check some set of rules.

This source checker now runs on each commit in the source control from the build server and tests every rule we decided to check. If some rule was violated – it reports that, fails build and suggests what should you do to fix the thing.

It is able also to ignore some directories (for example it ignores itself because it shouldn’t be built into $(OutputRoot)). Other useful thing is that it could be integrated with TeamCity so that build log looks pretty there (you should specify /teamcity key in the command line).

Also rules could be easily added or removed.

It proved to be very useful in our day-to-day work and so I’d like to share them with everybody.

It could be not production quality sometimes and several hard-coded things could be inside but nevertheless it is still usable.

Sources could be found here. It is targeting .NET 4.0, but currently it is almost trivial to retarget it against .NET 3.5, so if you’re still there – it is not a problem.



  1. […] UPDATE: I’ve written such post. See here. […]

    Pingback by Deployment as part of development build « A place for spare thoughts — 25/07/2011 @ 04:25

  2. […] simple rule to check some of these things is below. It is almost trivial to plug it in SourceChecker I described before (actually we have this rule […]

    Pingback by Checking correctness of DependencyProperty declarations « A place for spare thoughts — 23/08/2011 @ 19:44

  3. […] as much as possible and detect errors in compile-time or build-time (on build server where some additional checks are taking […]

    Pingback by Property Injection for infrastructural dependencies in practice, part 1 « A place for spare thoughts — 12/09/2012 @ 21:41

  4. Good day! I was interested to know if setting up a blogging site such your own: https://sparethought.wordpress.com/2011/07/25/checking-solutions-and-project-files-against-some-set-of-rules-at-build-time/ is
    challenging to do for inexperienced people? I’ve been hoping
    to set up my own blog for a while now but have been turned off because I’ve always believed it required tons of
    work. What do you think? Bless you

    Comment by twitter.com — 27/03/2017 @ 15:13

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: