The last month has been really dedicated to finishing some of the feature development in our new product.  The new product is an XBAP application, so some of my time has been devoted to figuring out ways to implement features in partial trust. 

The end of the month brought my first foray into deploying the XBAP, which I know is going to be a pain.  Not so much because of creating virtual directories, etc, but because any time I change one of the files in the XBAP, the manifest files need regenerated.  I thought the Mage.exe tool would be able to help me with this, but it turns out the tool has a problem with regenerating hashes when the .deploy extension is used.  Overall, deploying this thing in an install format is going to be painful.

My current workload is solely bug fixing.  With our main focus on completing feature development, some of the lower priority bugs were overlooked, and now we’re forced to go back through and hit those bugs hard to clean them up.  I’m doing my part (19 cleared on Friday, and I’m hoping to hit 20 today), but I still have other issues to attend to.  Oh well, such is life as a developer, I suppose.

No, it wasn’t exceptionally warm, but it was extremely humid.  I sweat a LOT, and running in humidity (with little to no wind) takes it’s toll on me.  No excuse, I supposed.  But it was an enjoyable morning.  Tomorrow it’s back to work.

Work has been rather hectic. I have an awful lot of quarterly objectives that I need to meet in the next three days, so I’ve been kind of busy pushing out new features and wrapping up some of my objectives. I don’t think I’ll have a problem finishing up, but it’s definitely going to be tight.

Firefox has some add-ons like Twitkit and the GMail Manager that allowed some interactivity, but that mean that I had to have Firefox open all the time. Sadly, when I’m really focused on development, I don’t usually have that open.

A co-worker noticed my tweet about Twitter’s IM service being down for some time. He pointed me to Digsby, which is the current uber client for IM, Email, and several social networking sites (Facebook, MySpace, and Twitter are the only ones currently implemented). Given my new fascination with Facebook, I thought I’d give it a try. So far, I’m impressed.

The ability to tweet from the IM client works great (better than Twitter’s own IM bot). The integration into Facebook chat means I’m on Facebook chat pretty much all day, which is pretty fun. And, since my various email accounts (2 gmails, yahoo, msn, and a couple pop accounts) are easily manageable within Digsby, it looks like Trillian is out. It’s served me well, but the Digsby client seems much more integrated.

What’s that mean? Well, my days are spent fixing bugs (and implementing features) in our new product in preparation for a release within the next month or so. My nights and weekends are filled with cleaning and fixing our current house. Our townhouse is only three years old, so it’s in wonderful shape, but there are some touch-ups here and there that need done (some drywall patches, a few paint touch-ups, and general top to bottom cleaning).

I’m getting a little burned out at this point, but hopefully we can sell this place and get into the new house before Christmas. Our fingers are crossed.

I actually thought I had a solution: Have the WCF service include error details. What that does is send back a SOAP FaultException (System.ServiceModel.FaultException<T>), where T is a System.ServiceModel.ExceptionDetail). From there, I could examine the ExceptionDetail and detemine what type of exception was thrown and handle it appropriately. All well and good, although throwing those exceptions around makes the service somewhat vulnerable, since users can use exceptions to glean information about the system.

I could live with that, except for the fact that my system didn’t work in partial trust. Why? Because System.ServiceModel.ExceptionDetail is not serializable in partial trust (one of its properties doesn’t have a setter or something). So it was back to the drawing board.

A Google search or seven led me to Guy Burstein’s blog post about WCF Exception handling using Microsoft’s Enterprise Library and it’s Exception Handling Application Block. Basically, the MS Enterprise Library has some classes that allow me to automatically wrap and generate a SOAP FaultException with any internal type (T from above) that I want. That means that I can return the data that I want AND I can filter the exceptions as I wish.

It’s a pretty slick system, but getting it working tooks some time. I think most of my time dealt with little idiosyncracies, like where the classes are defined, how the application block is configured, etc. One thing I will not for posterity is that your fault class (The class you want to go into the SOAP exception) cannot be a “class within a class.” I couldn’t figure out the proper full name for that, and it ended up giving me headaches. So I moved the class to the namespace level, and everything worked ok.

I’m not going to repeat all the steps, as Guy’s blog does an excellent job of describing the steps. Once I get some time (ha!), I’d like to look into the automated logging of the exceptions, as I think that would be extremely helpful.

I tip my hat to Michael Phelps. To swim 17 races in 8 or so days is just insane, especially breaking 7 world records in the process. However, I have to give the same congratulations to Phelps’ relay teammates, particularly Jason Lezak. Those guys gave their all to help Phelps complete his quest, and it shows that swimming seems to be an individual affair, but certain races showcase the teamwork required to really dominate.

That being said, I really wonder how many swimming medalists live and train in the US? It seems that there are a lot of people who swim for their home country but live and train in the US. I guess that really shows the dominance of the US in this sport.

It’s actually a pretty slick little class. The guts of it are a few static methods which take an exception. From there, the class will categorize the exception based on type, display the message to the user, and log the exception to an XML log file as determined by the log level. Since we’re trying to get our application to run in .Net’s partial trust, I had to use the IsolatedStorage classes in order to save the XML.

The bulk of the work actually came in handling our “fatal” exceptions We expect exceptions of type ValidationException and ApplicationException, so we handle those with a simple message box and let the user get back to work. Other exceptions, however, are unrecoverable, so I created a dialog page that displays the error to the user and allows them to send the report (via web service) to us. Not only did I have to get the error dialog to work, but I had to re-style it, which took at least 4 or 5 hours.

Extras? Well, the the log level is also used to specify the number of stack frames that get written to the log. It also specifies whether or not our non-fatal exceptions get written to the log. I also took a few extra steps to “lock down” the class so it’s easy to use and not very easy to misuse.

So, see, I do work.

As far as work goes, I’m pretty busy trying to wrap up my projects for the month and get a jumpstart on my quarterly objectives. I just realized that I have some extra projects (like creating an installer for our new product) that may take up a good portion of my time next month, so I’m trying to get my development done this month.

I had really hoped to get to all of my development tasks, but I had about a week and a half of straight bug fixing in order to help get bugs down for a release at the end of this month. We’re getting there, but there is a lot more to do before we can wrap it up.