XanderLand

So, last month I quit my job as opened up shop as a consultant. It’s been an enjoyable adventure so far, and I’ve been posed with a fair number of new challenges, one of which was that I needed a bug-tracking solution.

Now I wanted an application with web, mobile, web service and Windows interfaces, because you never know how you might want to extend something like this. I wanted something in ASP.Net, because I’ve got machines set up to run it, and I’m more comfortable with ASP.Net then just about anything else. I also wanted it to either be open-source, or at least extensible to some measure so that I could tweak it.

I’ve used various commercial and free products in this space before…Primarily Bugzilla and a Windows-based commercial interface called IssueView. (It had a web interface as well, but we hadn’t implemented it.) They were ok, but they didn’t meet as many of my criteria as the ASP.Net IssueTracker Starter Kit.

The IssueTracker is open-source, written in C#, and comes with both web and mobile interfaces. Do I really *need* Windows and web service interfaces? Do I *need* to be able to tweak it? Truthfully, no, but the fact of the matter is, I like to tinker, and it looks like a fun project.

I’ve gotten it installed now, and over the course of the weekend I’ve had a chance to look it over, and start to make the changes that I want.

The first issue that I had is that all of the business logic is buried in the web application itself. That’s fine, for the most part, for the product as it ships, though it is kinda weird that the mobile application (which is in a separate solution entirely, as shipped) had a reference back to the web app. For my purposes, however, it just wouldn’t do. The last thing that I need for the eventual distributed Windows app interface is a reference to a web project, so I pulled all of the business logic and the data layer out into a separate core library (XseIssueTrackerCore), which turned out to be remarkably easy. The business layer and presentation layer didn’t turn out to be anywhere near as strongly-coupled as I feared they might be.

The second issue was more interesting. The business layer *was* coupled to the web interface in that one of the security classes was expecting an HttpContext to be passed in, which again, obviously won’t work for a Windows interface. It would, however, work for both the web and mobile interfaces and so instead of repatriating it to the web application, I broke it out into a library specific to HTTP interfaces which I called XseIssueTracker.Web. Naturally, I expected this to break the callers until I updated their references, but to my surprise, it didn’t. The solution built fine, ran fine, and otherwise appeared to run without a hitch. I need to do a global find at some point in the future to see if it’s being called somewhere weird that I haven’t found, or if it’s really and truly useless.

I’ve got a ton that I want to do to it…I can’t stop coming up with ideas, and I’ve got far more than I want to cover now, so I think that I’m going to continue this thread in the future. Until then….