Log in

No account? Create an account
Gavin Greig [userpic]

MSBuild - First Impressions

July 6th, 2005 (11:12 pm)

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.