My blog is now running on cmScribe 5.0. This will mean nothing to most people reading this, but it's a big deal to me, because in 5.0 I managed to achieve a whole lot of things that have been goals of mine for cmScribe since before it had a name, and before anyone else who still works at NetReach now was even employed there. Except for Will but he cheated by leaving and coming back.
The upgrade process is fairly seamless but under the hood everything's changed. As well as running on .NET 2.0 (we could run on 3.0, but since the two are identical, why bother?) we're taking full advantage of the new capabilities of the 2.0 version of the framework: every ArrayList and Hashtable in our code has been replaced by a List<> or a Dictionary<> and our custom-coded nullable type wrappers have been replaced by the framework's Nullable<>. Instead of a kludged-together build process, we integrate nicely into Visual Studio's build process using msbuild. We've moved from SourceSafe to Team Foundation internally. And taken advantage of the fact that msbuild and tf are true managed applications by replacing all our hacky vbscript, perl and bat scripts for branching, upgrading and pushing with a single C# application.
The change that's most interesting to me is that in 5.0 we've managed to make cmScribe truly modular. We had something like modules before, but everything got compiled in one go into the same assembly, so there was no way to enforce rules about what code depended on what (except for me going over to people's cubes and saying OMGWTFBBQ at them). We also had a nasty habit of adding customizations to individual customer installations of cmScribe by changing files that were part of cmScribe itself; this was expedient but always caused issues when it came time to upgrade to a newer version.
Today, each module is built separately; dependencies are declared explicitly (and circular dependencies are impossible). And we've added - and enforced the use of - mechanisms to customize the behavior of cmScribe panels by adding extensions to them, rather than changing the original. The extensions typically live in a separate module from the panel being extended, so the base cmScribe modules are used unchanged.
The end result being that cmScribe modules are strictly separated from each other, and customer customizations are strictly separated from core cmScribe code.
Next up: trying to convince the Powers that Be that building a community of developers around some of the cmScribe core modules is possible and valuable and that liberty is the best way to achieve that :)