Gavin Greig (ggreig) wrote,
Gavin Greig

MSBuild - First Impressions

Well, I haven't done too much with MSBuild yet. I've spent most of my time fixing a number of issues highlighted by the most recent version of FxCop - and rediscovering what is apparently a known issue in FxCop. It throws up a lot of spurious errors if the Office spellchecker isn't installed.

MSBuild still looks good, and we still want to migrate to it and away from NAnt. However, we've only partially made the move this week, and the reason is that one of the strengths MSBuild shares with NAnt isn't fully fleshed out yet. A lot of useful work is achieved by add-in "tasks" that can be defined by users in order to extend the functionality of the basic tool.

Quite simply, the pre-existing tasks available for NAnt are more mature than those available for MSBuild. Although our use of NAnt is limited, we're still using functionality that doesn't seem to be there for MSBuild yet.

Most importantly for us, this includes integration with the SourceSafe source control system. Nant's add-in tasks can accomplish checking out and checking in, and its "get" functionality will delete any files that have been removed from source control as well as just retrieving the files that are there.

It's the absence of check-out and check-in that's a bit frustrating, as we have a target that checks out and updates SourceMonitor metrics files before checking them back in again. Although it's not essential to our core build process, we want to keep it and see it as a ground-breaker for future tasks more integral to the build.

We could develop our own tasks - and in fact, I've signed up to the relevant GotDotNet workspace for the tasks created by Microsoft Research so that we can do this - but it's something we'll have to think about fitting into our schedule rather than "just doing it".

On the other hand, having the text-based MSBuild project files within Visual Studio meant that I was able to go in and fix a less-than-ideal file naming decision taken by the autogeneration from resources mentioned in my previous post.

We have two projects that target different platforms, but have a lot of code in common and hence share a folder. Autogenerating a resource accessor class in each project from a shared resource file resulted in one file called Blah.Designer.cs and another called Blah1.Designer.CS. We were able to replace these with names that made a more meaningful differentiation.

It's possible that, instead of doing as we've done in upgrading these projects, we should look into creating a single project with separate build configurations for the different platforms. However, I'm not sure at the moment whether this is possible, and it certainly wasn't when we originally created the projects under VS2003.
Tags: software development, work

  • 20 Years

    On the first of October, it was 20 years since I started work at Insights, and today I got my fourth block signifying a period of 5 years…

  • Weekend - Peter Pan, Bon Scott and Sydney Padua

    It’s been a while since I wrote, you know, actual words here – nearly six months, which is my longest gap ever – so I thought I’d make a cursory…

  • Open Live Writer

    When I first started blogging, I used LiveJournal’s own facilities to edit my posts, but for many years now, I’ve used Windows Live Writer instead…

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.