Bug Tracking

"Jesse is working on a bug tracking system in 100% managed code. Scott has posted an awesome article on the Myth of .NET Purity. Given that I agree with Scott, you might think I'd disagree with Jesse avoiding other system on the basis that they "aren't .NET based". However, Jesse isn't just building a stand alone system - it's integrated with VS.NET. Also, the way you can build bug tracking directly into your production app is very cool. I wonder if Jesse is inspired at all by "Production Debugging for .NET Applications".

I'm interested in Jesse's system because of these features. The whole 100% managed code thing is nice, but as an end user of the system, I just want it to work.

Jesse - you're building in support for web services as well, right?"
[DevHawk]

I definately agree with Scott to a point. In the end, you can't have pure .NET, because even the APIs themselves are going to call COM objects. So, if .NET can do it, why not my app? Well, for one, I want my apps to work under Mono and any other runtimes that come out. Not a big deal today, but planning ahead is a good thing. Additionally, there are penatlies (which Scott did not point out) for marshalling out of process to some COM/COM+ server. Not big penalties, but they are there nonetheless. Both of these issues probably aren't huge, unless you are a purist like me, but the biggest reason we to 100% managed (when possible...we have had to use the Win32 APIs in a few apps), is the marketing perception. As someone once said, "money is the root of all kinds of evil." ;-) If you have a product that is 100% managed code, it somehow seems better than a COM based app with .NET wrappers, or a partially .NET based app, and perception is reality to those how percieve, ie. those people who buy our software.

To answer your question though, I am building WebService support into the system. Basically, it has a few different modes you can run in. In the current mode, it just log bugs to a local XML database (a lot easier to prototype the functionality with). After I get the basic featuers down and move on to making the system more robust, we will be able log bugs to an MSDE or SQL database, or to a set of WebServices. Of course, all this is properly designed with abstract factory patterns, so it is pretty much transparent to the user and easy to swap out implementations that could potentially even talk to a system like FogBugz on the backend and still give all that VS.NET integration goodness. The key here is flexability, because every development team has a different philosophy.