Subversion and Team Foundation Server

There’s a Codeplex project that enables developers to use their Subversion clients with Team Foundation Server (TFS). It’s certainly an interesting project, though I don’t quite grasp the rationale. TFS is really expensive, so if a shop can afford it, they can afford Team Explorer too.

I found out about initially via TheServerSide.NET.

Ruby on Microsoft

This piece by Martin Fowler interests me more for his contention that the best technical leaders are abandoning .NET than for what he writes about Ruby. It’s the sort of argument that seems true because anecdotal evidence seems readily available.  I’d be interested to see if there’s more quantitative backing for the assertion.

Some poking around on Google did reveal at least a couple statistics:

“Rails.NET” Revisited

It’s been almost a year since I learned about the .NET Action Pack. Since then, the project has changed names (to SubSonic) and switched to using Google Code as a repository (though they still use CodePlex for other things). The team appears to have enhanced it significantly, including the addition of a command-line utility and support for non-web applications.
Since we’re short-staffed at work, we definitely need to jump on anything that will generate code for us.

Fun with Settings.settings

Apparently this is where Visual Studio 2005 stores connection strings when you add strongly-typed datasets in an application.  Even though I had an app.config file and I’d changed it to point to a new database, I was still getting SqlExceptions when I ran my unit tests.  I just didn’t know the old value was still stored in Settings.settings and needed to be updated.

VSS Shadow Folders

We still use Visual SourceSafe at my job for version control.  I inherited the administrative duties (for one VSS database and a TFS installation) after one of my colleagues left to join a startup.  We found a legitimate need for its “shadow folders” functionality not long ago, and finally implemented them this morning.  I came across this page when figuring out the particulars.

Guiding principles for developers

This list comes courtesy of Patrick Cauldwell, an architect at Corillian Corp.  I’m definitely in favor of most of their list, especially test-driven development, continuous integration, and buy vs. build.  I’m not so sure about the Windows authentication point simply because it takes so much effort to get developers access to our databases at work.

Slimming down the FxCop rule set

I asked a group of consultants currently working in my office for advice on which FxCop rules were actually applicable to our environment.  One particularly useful piece of advice was to consider whether or not unknown people or applications would be using what I’d written.  It allowed me to disable the following rules:

  • Mark assemblies with CLSCompliant.  Since there won’t be any third-party users of the assemblies I ran FxCop on, that rule can go away.
  • Mark assemblies with ComVisible.  The same argument as above applies to this rule.
  • Assemblies should have valid strong names.  Once we get certificates, we would reactivate this rule.

I’ll revisit the list periodically to make changes as I improve my understanding.