SSW has a list of 41?rules that they've put out there that can be used as guidelines for running successful projects. I perused the list, and for the most part, they're spot on.

One item I hadn't seen was number 5 - about synching up development vs. production web.config settings. SSW uses an approach based on machine name - so if you have a key for WebServiceUrl, you'd have DevLaptop_WebServiceUrl for your local machine, and DevServer_WebServiceUrl as the key for your dev server. I've never done it that way, but it's an interesting approach - and could see some use for it in the future. I've typically used either the ability to have a developer.config file that's not checked into source control (file attribute for appSettings), or, more recently, using a web deployment project to make our dev, staging, and production builds, and use the built-in ability to swap out sections with other files - we have a production.appSettings.config, staging.appSettings.config, and dev.appSettings.config, and those get put into the appSettings section in our web.config when the build happens.

Others that I hadn't seen? Database tools. I use Red Gate's SQL Compare to do our database upgrades, but it's not part of our build process. Having some sort of SQL deployment tool in our build process is a goal, but a lofty one at this point.

I like the point about referencing projects over DLLs. Even for stable DLLs, if I have access to the project, I'd rather have the project reference, if for no other reason than when I'm debugging, I can still step through the code if I need to - not swap out my reference for a debug DLL - because if you reference a DLL directly, it should be the release version!

By the way, the actual author of this list looks like it's Adam Cogan, who's been on dnrTV for the past four weeks talking about SQL Reporting Services (part 1 |?part 2 |?part 3)?and Visual Studio Team System (part 1).

Technorati Tags: SSW | Adam+Cogan | dnrTV | Rules | .NET