Global village ceilidh and sports day

I don't know whether it's just better mikes on the crowd, or the focussing effect of Murrayfield Stadium, but watching Live8 Edinburgh on the box it looks much more emotional than the Hyde Park gig - and it's not just awe at the vision of Lenny Henry wearing a sporran with antlers! Actually, a number of the commentators and participants have commented on how much better the atmosphere is here than it was in London on Saturday. I choose not to dismiss this as the usual snake-oil!

What with one thing and another, it's a big day in the UK. Not only are they rocking in Auld Reekie, the G8 are meeting somewhere central for a change, and some wee village far off in one of the remoter outlying parts of the south seems to have good news about holding a sports day too.

No doubt there will be down sides to all that's going on and, folk being folk, we'll likely hear a lot more about them in the coming days and years than we will the good stuff. But overall, I think today is a good and hopeful day when good will, good intentions and good fortune outweigh the bad stuff. Savour it, there's few enough of them.

Resourcefulness

How cool is Visual Studio 2005's handling of resources? FxCop picks you up on it if you're daft enough to use a string literal, and VS2005 itself offers to autogenerate a class that exposes the strings to code as properties. Combined with the great handling of internationalised resources, this promises to make our lives a lot easier.

Previously, creating and consuming resources in an internationalisable way has been - maybe not difficult, but definitely a bit painful and a lot of work.

Today, I created a handful of new resources and a couple of new resource files in side projects, including appropriate accessor classes in under ten minutes. I also scrapped our own pre-existing classes for doing the same job. They were good enough, but not quite as flexible as the autogenerated classes can be.

It's always satisfying to be able to reduce the amount of code we directly write and maintain.

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.