MSBee 1.0 is now code complete, meaning we're just a few days away from the final release. Subsequently, our MSBee shared source release is also on track and will be available soon.
Earlier today, I was reading a blog post by Josh Ledgard, a co-worker on the Solutions team. The post discussed feedback he received on keys to successful source releases and I wanted to respond to some of those suggestions by explaining what we've done for the MSBee release.
Multiple people provided feedback that the open source community is becoming very fond of the Microsoft "permissive" license. We've noticed that as well and the MSBee source release will come with a permissive license.
Another individual mentioned lowering the barrier to entry when it comes to contributing. Specifically, he's been frustrated by projects that require tons of dependencies and, even after installing them, have other nuisances that require additional work before he can successfully build.
For MSBee, we made a conscious effort to significantly reduce the pain of that experience. We've intentionally used publicly available tools for code analysis (FxCop), testing (NUnit), and building the MSBee installer (WiX). All these tools are available as binary distributions so you don't need to build them while you're trying to build MSBee. We also provide a MSBuild file that lets you specify where you’ve installed these tools. This file is imported by all the MSBee projects so once you add your paths to the Settings file, all the projects become aware of the tool locations. Additionally, by using a MSBuild file, we can give you an informative error if you forget to provide a path in the Settings file, instead of a cryptic build error.
We're also providing our unit test and scenario test projects, along with a batch script to run the tests. The unit tests include tests for each task in the MSBee DLL. The scenario tests build test projects using MSBuild with MSBee. Thus, when you make changes to the existing code, you can run these tests to verify that your change didn't break any functionality. Additionally, you can add new tests as needed.
Another user mentioned her desire to have architectural diagrams and relationship trees for classes and project dependencies. While we don't provide that level of documentation with MSBee, you will get the MSBee ReadMe, a spec and design document on the installer, a design document on ResolveComReference, and our Test Plan. Additionally, I spent considerable time supplementing our code with comments that describe how everything works. And our forum is always available for questions.
In short, we've made a concerted effort to make working with the MSBee source a pleasant experience and to eliminate some of the commonly experienced pitfalls. I hope that contributors will feel the same way.
Finally, on an unrelated note, I mentioned in a previous post that I couldn't properly run my tests with NUnit through the External Tools dialog in VS 2005. It turns out there is no VS macro that points to a project's bin\<configuration> directory.
