Why Unit Test

I came across a great post on unit testing today that provided not just why to unit test, but what to unit test. Differentiating software into “infrastructure” and “end user application” really highlights what sort of code will benefit the most from the approach. Another really useful bit of this article talks about turning bug reports into unit tests. It’s a very smart idea that I’ll try to use on my own code whenever it’s appropriate.

MyGeneration and Gentle.NET

After last week’s post about the stored procs vs. ad-hoc SQL debate, I decided I’d take a look at MyGeneration and Gentle.NET if I could think of the right project. I decided to start with a simple contact form.

Anytime a form has dropdowns, I try to use database tables to populate them.  So I started by copying data for the dropdowns from an existing database to a new one for the project. Once I created a business logic assembly for the new classes to belong to, I fired up MyGeneration and ran the Gentle.NET business entity template. Creating the classes was very easy. the real challenge turned out to be referring to the right Gentle assemblies in my projects. Because I’d included references to Gentle.Common, Gentle.Framework, Gentle.Provider.SQLServer and log4net in the business logic assembly, I thought that was all I needed to do. But the web project wouldn’t compile. In order to get the page working, I had to add Gentle.Common and Gentle.Framework references to web project.

Once I sorted out my reference issues (and added a Gentle.config file), finishing the contact form went very quickly. I developed this bit of code for loading any dropdown list:

private void LoadDropDown(ref DropDownList ddl, IList dropDownItems, string textField, string valueField)
ddl.DataSource = dropDownItems;
ddl.DataTextField = textField;
ddl.DataValueField = valueField;

Here’s how it’s called:

if (!Page.IsPostBack)
this.LoadDropDown(ref ContactTypeList,BLL.ContactType.ListAll(),”Name”,”ContactTypeId”);
this.LoadDropDown(ref SubjectList,BLL.InformationType.ListAll(),”Name”,”InformationTypeId”);
this.LoadDropDown(ref OrgTypeList,BLL.Audience.ListAll(),”Name”,”AudienceId”);

Inspired by Ruby on Rails

Instead of vegging out on TV after work today, I decided to veg out on the web.  Between reading and IM I managed to kill about 2 1/2 hours before I even noticed.  The payoff for this exercise was discovering a little project called the .NET Action Pack.  Rob Conery has taken the concepts of Ruby on Rails and reimplemented them using C# and .NET 2.0.  The screencast he used to demonstrate the action pack was quite impressive.  With a build provider, a configuration file, and a single assembly, you get a whole host of classes that let you query and manipulate a database however you wish that are available at design time.
I’m definitely going to try this out at work tomorrow.

Stored Procedures vs. Ad-hoc SQL Redux

I’ve written on the never-ending stored procs vs. ad-hoc SQL debate before, but there are quite a few more perspectives on both sides of it than I referred to in my previous post. Here are a few of them:

These arguments make me a lot more curious about object-relational mapping and code generation.

C# versus VB.NET

I decided to post on this topic today because of an article I saw on the printer at work this morning. You can check out the entire article yourself here, but what made me decide to post was the author’s assertion that VB.NET can be “considerably less verbose than C#” because of the “with” keyword. He left out the existence of the “using” keyword in C#. The code he writes as an example could be simplified to the following:

using (TabPage tp = tabControl1.TabPages[0]){
tp.BackColor = Color.Red;
tp.BorderStyle = BorderStyle.Fixed3D;
tp.ToolTipText = “Click Me!”;
tp.Text = “Hello world”;

In C#, the keyword does double-duty by indicating inheritance from .NET and COM libraries. In VB.NET, another keyword (Imports) is needed for this task.

The author is right about the existence of more automatic formatting and IntelliSense code-completion in VB.NET. However, I consider it more a hindrance than a help when creating properties. In C#, if you want to create a read-only or write-only property, you write the property with just the get block or the set block. In VB.NET, you’re required to provide a ReadOnly or WriteOnly keyword to get the same effect.

The initial reason I decided to learn C# instead of VB.NET is a demo I saw from Don Box at a Guerilla.NET class in 2001. He took a MS Visual C++ sample app and used the .NET Framework to compile it. He didn’t have to change a single line of code to get this to work. He said at the time that this was the only language that trick was going to work for. He turned out to be right.

Early on, another argument in favor of C# was the number of code samples and books. It seemed heavily in favor of C# versus VB.NET, though the gap has certainly narrowed in subsequent years.

A third argument in favor of C# is what language software products are being built in. I heard plenty of rumors in 2001 about Microsoft rewriting some things in C#. But what’s certainly true is that some companies are building products with C#. Writely, a recent acquisition of Google, is written in C#. Community Server, from Telligent, is also written in C#. NUnit, an excellent unit testing tool (ported from JUnit), is also written in C#. NAnt is a C# port of the Ant build tool.

Mine is just one opinion among many as to whether you should use C# or VB.NET. But when there’s a development team involved, the language to be used should be the one the majority of developers are familiar with. That’s why I chose VB.NET when building MethResources.gov even though I personally prefer C#.

Here are some other opinions on the subject:
Choosing between Visual Basic .NET and C# (by Ted Pattison)
From VB.NET to C# and Back Again (by Darren Neimke and Scott Mitchell)

Open Source on the .NET Platform (part 2)

Back in April, at the end of my first post on the topic of “open source .NET“, I’d written that the next post in the series would be about Community Server. Telligent released version 2.1 of their flagship product just last week.

I first found the product at the end of 2004, when it was still Community Server: Forums. My employer was bidding on a project to provide an online forum to one of our government clients. One option they were considering was to make a copy of a custom online forum they’d already done for another client and modify it to suit the new requirements. This option reminded me of two things I dislike most about custom development:

It didn’t take too many Google searches before I found Community Server: Forums and put it forward as an alternative. The next few paragraphs will discuss how I felt the product stacked up against “the four questions”.

1. Is open source the best choice for this application?
Because of how long online forums have been around, open source is a particularly good choice for this application. I came across a pretty large number of options for online forums when I was searching. That said, a number of them were written in languages like PHP or Perl for UNIX (which helps answer question 2).

2. What platform are your developers most skilled at building for?
As a Microsoft shop, trying to deliver a customized solution on a platform the developers weren’t familiar with was far too high a risk. This eliminated a significant number of the applications I’d seen.

3. Is the best open source application on the .NET platform?
In 2004, I would have said no. To me it seemed more likely that the best open source forum application would be on UNIX, simply because of longevity. But given what the developers we had were familiar with, and the alternative of cut-and-paste inheritance with a classic ASP solution, Community Server: Forums was the best for our purposes.

4. Is it our goal to re-sell an application we’ve extended?
Unlike our experience with IssueTracker, the objective of making money with modified versions of this application was clear from the very beginning.

There are two “barriers to entry” with Community Server that proved significant in our case:

  • C#
  • Documentation

While I had made a deliberate choice to learn C# instead of VB.NET back in 2001, the vast majority of the developers I had to work with had moved to VB.NET from VB. The lack of familiarity with C# syntax led to a number of suboptimal choices for customizing the look, feel, and functionality of a particular instance of Community Server. The relative lack of documentation (both in the source code and stand-alone) made it a challenging platform to extend. I suspect that some of this is by design, as Telligent still makes some portion of their income from custom implementations of Community Server.

On the plus side, Community Server is quite well-built. Its naming and architecture are consistent enough that it took me relatively little time to customize a version of it for my most recent project: pushingback.com. The site is customized in a way that would make it quite easy for us to upgrade the site from Community Server 2.0 to 2.1 if requested. If the companies that currently use it are any indication (Microsoft, Dell, MSNBC), it’s one of the bigger (if not the biggest) successes of open source on the .NET platform.
In my next post on this subject, I’ll discuss an issue that seems unique to open source on .NET–competing products from Microsoft.


I haven’t blogged in awhile since finishing my latest project, pushingback.com. My employer sent me off to Cognos 8 training last week. I’ve spent the rest of the time doing what I can to fill in the void between billable projects. My boss tries to fill in the time by assigning me tasks like documentation, and creating PowerPoint presentation on this or that flavor-of-the-month technology. The latest such assignment is to lead a project to create a web application our clients can use to communicate with us about past, present, and future projects.

My employer was very cheap concerned about the impact on the budget, so when it came time to implement an internal solution for defect/issue tracking back in 2004, we chose to customize the ASP.NET IssueTracker starter kit (I’ve discussed this earlier) instead of dropping some cash on FogBugz or Bugzilla.

Now that my boss has suggested looking at COTS or open source solutions (again), I’ll be spending at least some of this downtime trying to find an improved solution.