I can't think of one good reason for anyone to ever use System.Transactions.TransactionScope. There have been a lot of positive articles written about this class over time. I don't want to link to any of them because then you might be tempted to believe that this class is actually useful - as I did. I wanted to believe. I really did. Then I actually used it.

About 6 months ago, I tried to use TransactionScope, and things were great. I developed the system and had no issues. Then, when deploying to a client, I found out that it doesn't work with MSSQL 2000. I thought the requirements were ironed out that we were using MSSQL 2005, but it turns out that wasn't the case after all. Sure, there are ways to get it to work with MSSQL 2000, but at that point, I figured I'd just use the SqlTransaction directly.

Fast forward to today. I see MSSQL Compact Edition 3.5 is shipping, and it claims support for TransactionScope on desktop applications. Perfect! However, my unit testing shows that connections won't enlist in the transaction when using TransactionScope. To make matters worse, TransactionScope behaves differently when using MSSQL 2005 and MSSQL CE. So much for the ubiquitous advice of  using TransactionScope in unit tests.

My advice? Feel free to use TransactionScope if you will only ever hit MSSQL 2005 on the backend. Even then, I would triple check that it works properly because I have lost all faith in this class. As for me, I plan on ignoring this class completely due to the ill-implemented effort.

Here is my quick and dirty laundry list of issues that I've been having with MSBuild over the past few days.

• You can't detect which target is being executed, therefore conditional execution of tasks cannot be driven by targets. Instead, you need to start a crazy chain of adding targets and updating properties and adding the new target to DependsOnTargets for the original target. No wonder the build file becomes unwieldy so quickly.
• It is very unintuitive and cumbersome to update property values. If I want to set a property one way in one case, and another way in a different case, it is not easy. Besides, the syntax for the CreateProperty task is way more complex than it needs to be to simply update a property.
• Brutal gymnastics are required to get around customizing build properties outside of the confines of the Configuration mechanism for a given project. For example, let's say I want to change the DocumentationFile parameter used in csc.exe, or change the NoWarn directive. If you're calling an MSBuild task on your solution, you need to specify those command-line parameters as /p: parameters from the command-line or track what you want to do and add the actual command-line parameters to the Properties attribute. It should be as simple as overriding the default build properties that exist in the csproj file, but that doesn't work.
• It lacks a way to list descriptive tags for all defined targets (c.f. "nant -projecthelp").

Apparently, I'm not the only one who sees this as a problem. I think Martin's idea of using a lightweight/script language to control the build is the way to go. Granted, I'm coming to this conclusion 4 years after he is, but the point is still valid today. I'd like to have more language elements in my build process to deal with branch, loop and flow so I can react better than I can with an XML file.

My bottom line: MSBuild may be a good tool for VS.NET to use because it can tightly control the format, but it is not a generic solution for controlling a medium-to-big size build process.

I've had some conversations with people about the label of ALT.NET. They are of the opinion that it causes controversy by setting up the "elitist" vs. "everyone else" mentality. This is not a new observations (see here and here, e.g.).

I'd like to propose that the divisiveness of the ALT.NET moniker be abolished as quickly as possible. To that end, my proposal for the name is Pragmatic.NET. It's both a state of mind and an homage to the Pragmatic Programmer series that touches on several of the topics important to this group.

Discuss...

I'm more than a little disappointed that I missed the ALT.NET conference in Austin, but I'm extremely happy that it looks like the movement has crystallized and gained enough momentum to be a legitimate option for .NET developers. Steve Kronsnoble made an analogy to the Agile Manifesto, where it took a bunch of informal participants and related ideas and turned them into industry standards. Hopefully, when looking back on this event years from now, people will be able to identify this as the genesis of  .NET.

I really like the idea of ALT.NET, and it maps to discussions I've had with many developers about trying to find a "Garden Path" of .NET development. Some percentage of .NET developers will use whatever Microsoft tells them to without question. That's fine, but that's not how I think. I like to grab the best technology no matter where I find it (Open Source, other languages, etc.) . I want to talk about things like NHibernate, Spring.NET, Subsonic, the new ASP.MVC framework, Domain Driven Design, Test Driven Design, Unit Testing, and on and on. To me, that's the excitement of ALT.NET.

To do my part, I'd like to start a discussion on where and when to hold a local Milwaukee version of this OpenSpace conference. If you're passionate about .NET development and want to help shape this new movement in the Milwaukee area, please leave a comment so we can find a way to move the ball forward.

I've been working more with data-binding and the ObjectBindingSource component that I wrote about here. Here is some stripped-down sample code to help investigate more data-binding concepts.

class Customer { 
  int Id;
  BindingList Orders;
}

class Order {
  int OrderNumber;
  Product ProductInfo;
}

class Product {
  string Vendor;
  Product Self;
}

Assume that we want individual GUI components for the Customer object, and a grid to display the associated orders, with the related Product information displayed along with the Order. Here are some quick pseudo-code tips to get things wired up properly.

• CustomerObjectBindingSource.DataSource = typeof(Customer)
• CustomerObjectBindingSource.BindableProperties.Add("Orders"). (If you don't do this, the detail ObjectBindingSource won't work later on.)
• OrdersObjectBindingSource.DataSource = CustomerObjectBindingSource and OrdersObjectBindingSource.DataMember = "Orders"
• OrdersObjectBindingSource.BindableProperties.Add("Product")
• DataGridView.DataSource = OrdersObjectBindingSource
• Modify the DataGridView column for Product by setting:
  • column.DataSource = ProductsBindingSource
  • column.DisplayMember = "Name"
  • column.ValueMember = Self
• **IMPORTANT** - Use the same object references everywhere for the product objects (i.e. in the DataGridView column and where you access them in your code). In the sample, I use the productBindingSource component for both the lookup in the grid and the way to lookup individual Product instances. Another alternative that I tested is to use a singleton class for the collection. If you don't do this, you will get the dreaded "DataGridViewComboBoxCell value is not valid" error when the grid tries to populate the Product value.

For concrete details, download this project. I look forward to your comments.

Here are a couple of things to remember when you want to use a parameterized LIKE clause in a SELECT statement.

When using a parameter to an integer ID column, you need to break the statement apart so that the parameter stands apart from the wildcard characters:

string sql = 
  @"SELECT * FROM myTable WHERE iId like '[%]' + @iId + '[%]'";

However, that same syntax will not work if you are using a varchar column. Instead, you need to embed the wildcard characters directly into the paramter's value:

string sql =
  @"SELECT * FROM myTable WHERE vcDesc like @iId";

cmd.Parameters.Add(new SqlParameter("@vcDesc", "%" + desc + "%"));

The second syntax works in both cases, so it probably just makes sense to use that everywhere and not worry

Subtitle: How to force .NET Grids to respect Object-Oriented designs

Microsoft clearly intended the DataGridView to be used with databases and primitives. With the company inventing .NET making it difficult to write GUIs with a proper domain model, it's no wonder that the majority of .NET code out there is littered with data-access metaphors.

Take the following code (yes, I know there are fields here, but it takes less space):

public class County
{
    public County() {}
    public string name;
    public double taxRate;
}

public class CountyTax
{
    public CountyTax() {}
    public County County;
    public double Amount;
}

There is no way out of the box to get a DataGridView to display and edit the CountyTax object's County and Amount fields. I'd like to have a combo box to display a list of county names, select one, and then enter an amount. Later, I can calculate the tax by multiplying the TaxRate for the selected county and the Amount I entered. In other words, I want to employ good domain design principles.

Here are a couple of solutions, depending on whether or not you want to add extra code to each grid, and use reflection or get some design-time support in a fairly encapsulated solution with faster-than-reflection performance.

I haven't had a chance to check out Orcas, but I can only hope that Microsoft has finally seen the light and will treat object-oriented developers to a fully functioning grid.

I would like to propose a Developer's Hippocratic Oath that would start with: "First, do no harm". ¹ Too often, a developer makes a change to a system that later proves to be disruptive or harmful. Yes, humans will always find a way to introduce bugs into code; however, we can all strive to reduce the impact of those bugs by:

• Understanding the infrastructure and tooling support, and pledge to make it better by automating more of it. Time spent automating things here reduces the chances of manual error later.
• Adopting a culture of testing. Unit testing tools are ubiquitous at this point. Even if you can't test everything, you can start by testing something.
• Fostering a spirit of continuous improvement in both talent and code. Take the time to refactor that code that bothers you. If it bothers you, it bothers someone else. Remember, refactoring requires discipline and unit testing to be complete!
• Fixing a bug at the source of it's error, rather than applying a band-aid further downstream - regardless of the schedule pressure.

Anything else you care to add before we codify this?

Nitpicker's Corner²

¹Yes, I know that the exact phrase "First, do no harm" is not actually in the Hippocratic oath. However, it is pithy and memorable and serves the purpose and intent perfectly in this context of establishing a new oath for Developers. If we want to vote on just naming it the Misercratic Oath for Software Developers (thanks, Steve!), we could go that way, too.

²With apologies to Raymond Chen.

Moving from a legacy system, one needs to appropriately deal with bad data in the database. For example, in order to put a primary key on a table, the column(s) in that primary key must be able to uniquely identify one record. If you need to find rows with duplicate entries before adding a primary key, you can start with this query:

select Id
from MyTable
group by Id
having count(*) > 1