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

Here is the target that I used to generate an FxCop report and integrate it seamlessly into the CC.NET web dashboard.

<FxCop
  TargetAssemblies="$(TargetAssembly)"
  RuleLibraries="@(FxCopRuleAssemblies)"
  AnalysisReportFileName="FxCop.xml"
  FailOnError="False"
  ApplyOutXsl="False"
  OutputXslFilename="Vendor\FxCop\Xml\FxCopReport.xsl"
  Verbose="False"
  IncludeSummaryReport="True"
  WorkingDirectory="$(MSBuildProjectDirectory)"
  ToolPath="$(MSBuildProjectDirectory)\Vendor\FxCop"/>

The key here is to be sure that ApplyOutXsl is set to False. If it's set to True, then the output will not get logged into the CC.NET log, which means when the dashboard tries to find it, it won't be there.

The other thing of note here is that I have all of my third-party tools, like FxCop, Sandcastle, Enterprise Library, etc. in a Vendor subdirectory of my project. By doing this, I can pick up the one Vendor folder and get another project up to speed quickly (through copying or Subversion externals).

When customizing the appearance of the CC.NET Web Dashboard, you often need to modify the file c:\Program Files\CruiseControl.NET\webdashboard\dashboard.config. However, you won't see the changes you make there reflected back in the browser until that file is reloaded.

The easiest way to reload dashboard.config is to quickly modify web.config (add a space and delete it), and save. This forces IIS to reload the web application, which in turn causes dashboard.config to give up it's new settings. This is especially useful in a hosted environment where you don't have access to administration-level tools.

An alternative would be to just bounce the entire web server by stopping and starting the service, but that's not always feasible nor practical.

When you need to extract more information from the MSBuild script, you can use the following syntax:

  msbuild /v:diag build.proj

There are other verbosity options available, too. Very handy when you need to easily find out what's going on behind the scenes.

I'm working a lot on agile .NET project setup right now. One of the standards in this arena is CruiseControl.Net. We also use Subversion and MSBuild, which means we need to use MSBuild Tasks to use the custom Subversion tasks. The documentation for MSBuildTasks is, well, "Open Sourcey". For the Subversion tasks, not all tasks have example MSBuild fragments. In addition, the descriptions of most properties or classes are just one sentence circular summaries.

For example, if you need to commit just one file inside the MSBuild script, you would use the SvnCommit task. You might do this as part of a depoyment process where you set version numbers on files before creating an installer. This is the snippet that I finally settled on to update just that one file:

<ItemGroup>
  <CodeFiles Include="Properties\AssemblyInfo.cs" />
</ItemGroup>

<!-- Later on, inside a Target, use this -->
<SvnCommit
  Targets="@(CodeFiles)"
  Message="$(CCNetLabel)"
  Password="pwd"
  UserName="user"
/>

The reason for this is that SvnCommit descends from SvnClient, which is too generalized of a base class. For example, the SvnCommit.RepositoryPath property does not work as one might expect. Specifically, in my case, when I specified the RepositoryPath attribute in the msbuild file, I received the following error. It turns out that you should just not specify the RepositoryPath attribute at all (see the documentation for "svn help commit" to see that a URL is not passed in on the command-line, but rather, svn figures out the URL from the working copy).

    svn: 'svn://x.y.z/project/trunk' is a URL, but URLs cannot be commit targets


Also, SvnCommit.LocalPath should not be used. It ends up generating a command-line similar to the following, which ends up committing everything in the LocalPath and down. Remember, all I wanted was to update one specific file, so it turns out that the LocalPath attribute is getting in the way here.

svn.exe commit "full\path\to\my\working\directory" 

  "Properties\AssemblyInfo.cs" --username user --password pwd 

  --message "1.8.1.2" --non-ineractive --no-auth-cache

To sum up:

• Don't specify the RepositoryPath attribute in an SvnCommit task
• Don't specify the LocalPath attribute in an SvnCommit task
• Specify a ToolPath entry that points to the folder that holds svn.exe if it's not in the default location (c:\Program Files\Subversion\)
• Setting the Verbose attribute does not work because it is defined as a nullable boolean

Edited on 10/10/2007 for clarity due to comments made by Steve Trefethen. Thanks, Steve!