Monday, September 21, 2009

Cleaning up enumerations

When working on existing code I occasionally run into an enumeration class similar to this:

  public class PowertoolsConstants
  {
      public enum Powertools
      {
          PowerDrill = 0, // Standard, corded drill
          Chainsaw,       // Everyone's favorite
          CircularSaw     // If the chainsaw is out of gas, use this
      }
 
      public static Powertools ConvertFromString(string s)
      {
          switch (s)
          {
              case "PowerDrill":
                  return Powertools.PowerDrill;
              case "0":
                  return Powertools.PowerDrill;
              case "Chainsaw":
                  return Powertools.Chainsaw;
              case "1":
                  return Powertools.Chainsaw;
              case "CircularSaw":
                  return Powertools.CircularSaw;
              case "2":
                  return Powertools.CircularSaw;
              default:
                  throw new Exception("Unknown Powertool");
          }
      }
 
      public static string ConvertFromPowertool(Powertools p)
      {
          switch (p)
          {
              case Powertools.Chainsaw:
                  return "Chainsaw";
              case Powertools.CircularSaw:
                  return "CircularSaw";
              case Powertools.PowerDrill:
                  return "PowerDrill";
              default:
                  return "Unknown";
          }
      }
  }


Nothing too complex, but it can be cleaned up a bit. For starters, accessing the enum currently requires referencing the class:

  PowertoolsConstants.Powertools tool =
      PowertoolsConstants.Powertools.Chainsaw;


If we move the enum declaration above the class we can remove the class reference:

  Powertools tool = Powertools.Chainsaw;


Next is addressing the two methods in the class: ConvertFromString and ConvertFromPowertool. The purpose of these methods is to switch between our enumeration and a string representation of the enum, perhaps to store values in an xml file or database. As the .Net Framework already contains this functionality, the methods are not necessary and can be deleted.

To convert from an enum value to a string we can use Enum.GetName

  string toolName = Enum.GetName(typeof(Powertools), tool);


To convert from a string to an enum value we can use Enum.Parse. Note that this will throw an ArgumentException if an invalid string is passed in.

  tool = (Powertools)Enum.Parse(typeof(Powertools), toolName);


With the two methods removed, the class PowertoolsConstants is empty and can be deleted.

One final thing to look at are the comments beside the enum values. These appear to be usage notes. If a developer using the enum needs to know this information, he shouldn't have to open this code to get it. The way to correct this is to replace the existing comments with xml-style comments.

  public enum Powertools
  {
      /// <summary>
      /// Standard, corded drill
      /// </summary>
      PowerDrill = 0,
 
      /// <summary>
      /// Everyone's favorite
      /// </summary>
      Chainsaw,
 
      /// <summary>
      /// If the chainsaw is out of gas, use this
      /// </summary>
      CircularSaw
  }


Doing this will provide the developer with Intellisense hints as they code:

Wednesday, August 19, 2009

Parameterized tests in NUnit

In an earlier post I showed how to pass parameters to test methods using an NUnit RowTest extension. As of version 2.5, the extensions are no longer packaged with the NUnit installer. The good news is that the addition of parameterized tests replaces the RowTest and adds a number of new features as well.

For reference, my previous RowTest looked like this:

[RowTest]
[Row(2, 3)]
[Row(-1, -4)]
public void AddTwoNumbers(int x, int y)
{
    Assert.AreEqual(x + y, Add(x, y),
        "Add returned incorrect result");
}

A basic switch to a parameterized test is a matter of dropping the RowTest attribute and replacing each Row attribute with a similarly-formatted TestCase attribute. The new code, which creates two distinct tests as before, looks like this:

[TestCase(2, 3)]
[TestCase(-1, -4)]
public void AddTwoNumbers(int x, int y)
{
    Assert.AreEqual(x + y, Add(x, y),
        "Add returned incorrect result");
}

In addition to single parameters you can now specify ranges. If I want to test values of X from 1 to 5, with a Y value of 1, I can do so using the Range and Values attributes, like so:

[Test]
public void AddTwoNumbers(
                    [Range(1, 5)]int x,
                    [Values(1)]int y)
{
    Assert.AreEqual(x + y, Add(x, y),
        "Add returned incorrect result");
}        

In the test runner, this shows up as five distinct unit tests


If I specify the range 1-5 for both X and Y, NUnit defaults to creating 25 unique tests. This is the default Combinatorial attribute.


If I wish to use a value from each range only once, I instead mark the test as Sequential

[Test, Sequential]
public void AddTwoNumbers(
                    [Range(1, 5)]int x,
                    [Range(1, 5)]int y)
{
    Assert.AreEqual(x + y, Add(x, y),
        "Add returned incorrect result");
}        

which produces the desired effect

Wednesday, August 12, 2009

Save WinForm control values between executions

Say I have a test application that submits info to a webservice. Because this webservice has a few issues, I may need to retry a request several times to get a valid response. I've added a control to set the number of retries.


Specifying the control's Value property at design-time sets the starting value at runtime. If a user wants to set a different value, he must do so each time he starts the app. To make things more user-friendly it would be better to save the control's value between executions.

To do so, start by selecting the desired control in the designer. In the Properties window, expand the ApplicationSettings entry and select the ellipsis (...) for the PropertyBinding sub-entry.


In the Application Settings dialog that appears, select the dropdown next to the 'Value' entry, as this is the property we wish to persist.


Select the '(New...)' link from the popup, which brings up the New Application Setting dialog.


Specify the default value and name of the config setting (and modify the Scope if necessary) and press OK. This will update the Application Settings dialog to show the newly added entry.


Press OK to close the dialog. With the property binding set, the application will automatically load the value at startup. The only thing left is to save the modified value. In the form's FormClosing event handler, add the following line:

Properties.Settings.Default.Save();


At this point the change is ready to test. Start the application and modify the control's value. Without doing anything else, close the application. Now restart the app. Note the control contains the modified value.

It would seem the desired functionality is complete but there is one more item that needs to address. If you look for the saved settings file, you will find it under

C:\Documents and Settings\<username>\Local Settings\Application Data\<Company>\<AppName>\<version>

If the version number for the application is changed, the previously saved setting won't be loaded. The application needs to know to upgrade the saved settings the first time it runs.

Start by adding a new application setting called UpgradeSettings. This will be used to make sure we only upgrade the settings once. Otherwise, any newly saved settings will be replaced by the previous version's settings every time the app starts.


The final step is to add the upgrade logic to Program.cs. In the Main method, add the following code immediately before the call to Application.Run.

if (Convert.ToBoolean(Properties.Settings.Default["UpgradeSettings"]))
{
    Properties.Settings.Default.Upgrade();
    Properties.Settings.Default["UpgradeSettings"] = false;
}

Tuesday, July 14, 2009

No-hassle SQL connection strings

Most applications working with a database handle the connection string in one of two ways: Hard-coding the full string or doing some amount of string concatenation. A typical concatenation method looks something like this:

public string OldMethod(string server, string database,
                        string username, string password)
{
    string connectionString = "Data Source=" + server + ";";
    connectionString += "Initial Catalog=" + database + ";";
    connectionString += "User ID=" + username + ";";
    connectionString += "Password=" + password;
 
    return connectionString;
}

I admit this is fairly simple code. The only potential issues might be a property name typo or a misplaced (or missing) semicolon. But why hassle with even that much when the dotNet Framework has the same functionality built into the SqlConnectionStringBuilder class? With a reference to System.Data.SqlClient, the above method can be replaced with:

public string NewMethod(string server, string database,
                        string username, string password)
{
    SqlConnectionStringBuilder connBuilder 
        = new SqlConnectionStringBuilder();
 
    connBuilder.UserID = username;
    connBuilder.Password = password;
    connBuilder.InitialCatalog = database;
    connBuilder.DataSource = server;
 
    return connBuilder.ToString();
}

In either case, the output is identical:

Data Source=myServer;Initial Catalog=myDatabase;User ID=myUser;Password=myPassword

Note: If you are working with a database other than MSSQL, there are several other classes derived from the common DbConnectionStringBuilder base class, such as OdbcConnectionStringBuilder and OracleConnectionStringBuilder.

Monday, July 6, 2009

Quickly escape strings in xml

If you spend much time working with xml, you will find yourself needing to escape strings. Replacing '<' with '&lt;' for example. Usually the code written to do so looks something like this:

escapedItem = itemToEscape.Replace("&", "&amp;")
                          .Replace("<", "&lt;")
                          .Replace(">", "&gt;")
                          .Replace("'", "&apos;")
                          .Replace("\"", "&quot;");

Though this technically works, there is an easier way built right in to the .Net framework. If we reference System.Security we can replace the above code with

escapedItem = SecurityElement.Escape(itemToEscape);

In both cases, the string

If (x < 2) & (y > 3), where \"x\" isn't...

is replaced with

If (x &lt; 2) &amp; (y &gt; 3), where &quot;x&quot; isn&apos;t...

Tuesday, May 19, 2009

An easier way to manage CruiseControl.Net projects

In a much older post I showed a quick way to remove duplication in a CruiseControl.Net (CCNet) config file. Since then, CCNet has added a Configuration Preprocessor to not only simplify this process, but also split the ccnet.config into multiple files - one per project.

To start with, we need to modify ccnet.config to specify the correct xml namespace:

<cruisecontrol xmlns:cb="urn:ccnet.config.builder">

Now we move an existing project from ccnet.config into a separate file. Note this new file starts with 'project' as the root node, and must also have the correct xml namespace.

<project xmlns:cb="urn:ccnet.config.builder">
    <name>My Test Project</name>
    <triggers>
        <intervalTrigger seconds="60" />
    </triggers>
    <sourcecontrol type="svn">
        <executable>svn.exe</executable>
        <trunkUrl>svn://MySourceServer/myAppPath</trunkUrl>
        <workingDirectory>C:\CCNetProjects\MyTestProject</workingDirectory>
        <username>svnUser</username>
        <password>svnPassword</password>
        <autoGetSource>true</autoGetSource>
    </sourcecontrol>
    <tasks>
        <msbuild>
            <logger>c:\ThoughtWorks.CruiseControl.MSBuild.dll</logger>
            <projectFile>MyTestProject.sln</projectFile>
            <buildArgs>/noconsolelogger</buildArgs>
            <targets>Build</targets>
            <workingDirectory>D:\CCNetProjects\MyTestProject</workingDirectory>
        </msbuild>
    </tasks>
    <publishers>
        <statistics/>
        <xmllogger/>
        <artifactcleanup cleanUpMethod="KeepLastXBuilds" cleanUpValue="25" />
    </publishers>
</project>

In the main ccnet.config, our project information can be replaced with an include that points to our new project config:

<cb:include href="C:\MyTestApp.ccnet.config" />

Instead of one massive config file, we now split it by project. This makes adding, removing, or modifying projects much easier. As an added bonus, CCNet monitors the project-specific config files and reloads them if anything changes.

I mentioned that we can also use the preprocessor to reduce duplication. In the project config above, note the Subversion username and password nodes:

<username>svnUser</username>
<password>svnPassword</password>

If we define these values in each individual config, changing them requires a find/replace across multiple files. What we want to do is define them once in the main ccnet.config and then include them in our project configs. To do this, we start by adding the following to ccnet.config

<cb:define name="svnCredentials">
    <username>svnUser</username>
    <password>svnPasswrod</password>
</cb:define>

In our project config we can replace the two credential nodes with a single reference to 'svnCredentials'. If we ever change the account our buildserver uses to pull code, we only need to change the credentials once.

<sourcecontrol type="svn">
    <executable>svn.exe</executable>
    <trunkUrl>svn://MySourceServer/myAppPath</trunkUrl>
    <workingDirectory>C:\CCNetProjects\MyTestProject</workingDirectory>
    <cb:svnCredentials/>
    <autoGetSource>true</autoGetSource>
</sourcecontrol>

Monday, April 6, 2009

Mmc load failure

After running our legacy installer we ran into yet another problem - the Computer Management administrative app quit working. Attempting to start it gave an error stating:

MMC cannot open the file C:\WINDOWS\system32\compmgmt.msc.

This may be because the file does not exist, is not an MMC console, or was created by a later version of MMC. This may also be because you do not have sufficient access rights to the file.


To debug this particular issue, we turn to Process Monitor. When we start up the app, the first item shown is a filter dialog. For this session, we need to add mmc.exe to the list of processes to monitor.


Though it's useful to see all activity for a given process, we are generally focused on errors. To make this easier, we want to highlight any log entries that do not have a Result of 'SUCCESS'


Once we have Process Monitor configured and running, we can start the Computer Management tool. The logs will quickly fill up with registry and filesystem events, many of which will be highlighted


In the above screenshot, notice the registry ReadOpenKey failures for various items under "HKCR\CLSID\{2933BF90-7B36-11d2-B20E-00C04F983E60}". I don't know off hand what those sub-items specify, but without them I do know you will be unable to load the associated COM object. To determine what dll was at fault, we went to another computer and looked for that section in the registry.


Note above the default value of "C:\WINDOWS\system32\msxml3.dll." For whatever reason, our installer was unregistering this system dll - definitely not a good thing. Fixing the problem on the broken box was as simple as running regsvr32 on msxml3.dll.