This week, the lead developer on a major open source project, NDoc, resigned. His reasons are valid, if not disappointing (not in him, in the community of NDoc users), but that's not the point. Coming on the heels of this announcement is the announcement about the pending availability of Sandcastle.
What's Sandcastle? Well, the preliminary announcement is a little light on details, but there's a few tidbits that give you a clue that it could be a replacement for the now defunct NDoc: Produces MSDN-like documentation, Build Assember includes syntax generation, and that it's used internally to generate .NET Framework documentation.
I'm interested - if for no other reason than it supports Generics! Anywya, a CTP should be released shortly.
Technorati Tags: NDoc | Sandcastle
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