Gavin Greig (ggreig) wrote,
Gavin Greig
ggreig

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
Subscribe

  • Electric Hurdy Gurdy

    Check out Guilhem Desq, lead hurdy gurdy player in Arcane Alchemists: Transmutation sounds like a Bond theme: This entry was…

  • Inside the Mark I Tank

    Here’s a really interesting video from the World of Tanks people. Yes, it’s a YouTube video, but you can drag your viewpoint around to see the…

  • 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…

  • Post a new comment

    Error

    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.
  • 0 comments