AutomaticChainsaw

Correctly disposing of objects - implement IDisposable

2010-08-31T16:53:00.001-05:00

To continue with our FxCop backlog, we are going to look at a couple rules dealing with IDisposable. Consider the following class:

  public class TimedProcessor

      Timer startTimer = new Timer();

      public TimedProcessor(double interval)

          startTimer = new Timer(interval);

          startTimer.Elapsed += timer_Elapsed;

      void timer_Elapsed(object sender, ElapsedEventArgs e)

          Console.WriteLine("Do work here");

Running FxCop on this will report a violation of the rule Types that own disposable fields should be disposable. The problem is that the startTimer field is of type Timer, which implements IDisposable. To properly use the timer, we need to call its Dispose method as soon as we are done with it. The solution is to implement IDisposable on our class and make sure we call startTimer.Dispose().

The class after fixing the violation:

  public class TimedProcessor : IDisposable

      Timer startTimer = new Timer();

      public TimedProcessor(double interval)

          startTimer = new Timer(interval);

          startTimer.Elapsed += timer_Elapsed;

      void timer_Elapsed(object sender, ElapsedEventArgs e)

          Console.WriteLine("Do work here");

      public void Dispose()

          if (startTimer != null)

              startTimer.Dispose();

Note that I check for null before calling Dispose. If an error elsewhere left the object in an invalid state, we don't want our Dispose method to throw a NullReferenceException.

Now, say we add a second field called endTimer. Running FxCop now will report a violation of the rule Disposable fields should be disposed. In this case we have already implemented IDisposable, but not all of our disposable fields have been addressed. To fix this, we need to modify our Dispose method slightly:

  public void Dispose()

      if (startTimer != null)

          startTimer.Dispose();

      if (endTimer != null)

          endTimer.Dispose();

A custom FxCop rule - calling Debug methods

2010-07-14T11:10:00.000-05:00

While working on a recent production issue, we ran into an interesting problem. We suspected an exception was being thrown when calling an external site, but we couldn't prove it. Our usual method of exception handling is to save the details to a rolling log file. This particular service, however, was failing without leaving behind any info as to why. Digging through the code revealed a catch block similar to this:

  catch (Exception ex)

      Debug.WriteLine(ex.ToString());

For now, ignore the fact that you will only see output using something like DebugView. The real problem is that when the code is compiled in Release mode, calls to Debug.WriteLine are removed completely. So in the example above, the catch block will be empty.

To reduce the odds of this sort of thing happening in the future, I decided to write a custom FxCop rule to locate any calls to methods that had been tagged with a "Debug" conditional. It wasn't as easy as I had expected, but there is an excellent tutorial on the subject. The only difficulty I had was in locating the ConditionalSymbol property in the class tree.

For anyone interested, here is the xml rule file:

    <?xml version="1.0" encoding="utf-8" ?>

    <Rules FriendlyName="Custom Rules">

        <Rule TypeName="DoNotCallDebugConditionalMethods" Category="CustomRules" CheckId="PG1001">

            <Name>Do not call debug conditional methods</Name>

            <Description>Calls to methods marked with the DEBUG conditional will be removed

            from Release builds.</Description>

            <Url></Url>

            <Resolution>Replace the call to '{0}' with a more appropriate call</Resolution>

            <MessageLevel Certainty="100">Warning</MessageLevel>

            <Email></Email>

            <FixCategories>DependsOnFix</FixCategories>

            <Owner></Owner>

        </Rule>

    </Rules>

And the code:

  namespace CustomFxCopRules

      /// <summary>

      /// Warns of any methods being called that are removed from non-debug builds,

      /// such as Debug.WriteLine()

      /// </summary>

      public class DoNotCallDebugConditionalMethods : BaseIntrospectionRule

          public DoNotCallDebugConditionalMethods()

              : base("DoNotCallDebugConditionalMethods", "CustomFxCopRules.rules.xml",

                  typeof(DoNotCallDebugConditionalMethods).Assembly)

{ }

          public override ProblemCollection Check(Member member)

              Method method = member as Method;

              if (method != null)

                  VisitStatements(method.Body.Statements);

              return Problems;

          public override void VisitMethodCall(MethodCall call)

              var member = ((MemberBinding)call.Callee).BoundMember;

              var method = (Method)member;

              var symbol = method.ConditionalSymbol;

              if (!string.IsNullOrEmpty(symbol) && symbol.Contains("DEBUG"))

                  Problems.Add(new Problem(GetResolution(method.FullName), call.SourceContext));

In space, no one can hear you scream

2010-06-25T10:30:00.000-05:00

Lately, most of my time is being spent refactoring legacy code. Everywhere I look I find try/catch blocks wrapped around a few lines of code. It appears the developer was using this as a way to "fix" bugs - by catching and eating the exception instead of tracking down the root cause. Enabling exception breakpoints and attempting to run the code is enough to make a developer scream. Unfortunately, if the exception isn't rethrown...

   catch (Exception)

       // No one can hear you scream!

I may have to put that on a t-shirt...

Proper exception usage

2010-06-21T13:26:00.000-05:00

Continuing our FxCop code cleanup, I decided to focus the next set of rules on working with exceptions.

Do not raise reserved exception types

These exceptions (such as SystemException and OutOfMemoryException) were designed as base classes or for CLR use only. Instead of using one of these, either find a more specific one in the .Net Framework or create your own.

  public static void ThrowsBaseException()

      // This is too vague to be useful

      throw new Exception("Bummer");

Instantiate argument exceptions correctly

The following is an example violation. Note that the thrown exception doesn't inform the caller which argument was at fault or how it was supposed to be called.

  public static int Divide(int dividend, int divisor)

      if (divisor == 0)

          throw new ArgumentException();

      return dividend / divisor;

To fix this, use a constructor that takes the name of the parameter and/or a string message stating the problem.

  throw new ArgumentException("Divisor cannot be 0", "divisor");

Do not raise exceptions in unexpected locations

Certain methods are generally assumed to never throw an exception when called (equality operators) or only throw certain exceptions (such as property getters.) To be consistent, your code should follow a similar pattern.

For example, the debugger uses the ToString method to display information. The following will cause issues while debugging:

  public override string ToString()

      throw new Exception("Don't do this!");

Do not raise exceptions in exception clauses

The following code attempts to call the Divide method with a divisor of zero:

  public void ThrowsExceptionFromFinally()

try

          Divide(12, 0);

      finally

          throw new Exception("Ouch");

Based on the method defined previously, the code should throw an ArgumentException. In this example, however, the ArgumentException is lost due to a new exception being thrown from the finally block. If you want to thrown a new exception, do so from a catch block and include the caught exception as the inner exception.

  catch (ArgumentException ex)

      throw new Exception("Ouch", ex);

Exceptions should be public

The previous rules dealt with exceptions built into the .Net Framework. The last two deal with custom exceptions. Take the following custom exception class:

  internal class MyCustomException : Exception

      public MyCustomException()

      public MyCustomException(string message)

          : base(message)

Note that the class is marked internal. The problem with this is that outside the assembly, the only way to handle this exception is to catch the base Exception (which is a bad thing.) The simple fix is to make the class public.

Implement standard exception constructors

Using the above exception class, note there are currently two constructors. The base Exception, however, defines two others - one to allow inner exceptions and one for serialization. Correcting the violation means making sure all four standard constructors have been defined. To fix the above class, the following methods need to be added:

  public MyCustomException(string message, Exception innerException)

      : base(message, innerException)

  protected MyCustomException(SerializationInfo info, StreamingContext context)

      : base(info, context)

Easy pickings: Class-level FxCop warnings

2010-05-14T09:29:00.002-05:00

The last batch of FxCop warnings proved to require a lot more effort than I had anticipated. It's amazing how much dead code accumulates over the years. For the next set of rules I decided to pick ones that were easy to fix but, more importantly, had few actual violations in our projects.

Abstract types should not have constructors

The following class violates the rule:

  public abstract class MyAbstractClass

      public MyAbstractClass()

          // Do setup code for derived classes

A class defined as abstract can't be instantiated directly. Thus, the only purpose for a constructor is to allow for default setup when a derived class is created. To fix the issue, change the constructor accessibility to protected.

Do not declare protected members in sealed types
Do not declare virtual members in sealed types

A sealed class is one that cannot be used as a base class. Protected and virtual members are useful for derived classes, which is a contradiction. Fix the protected member by making it private instead. As for the virtual members, this is a C++ issue only, as C# and VB.Net will fail to compile. To fix this for C++, unseal the class or remove the virtual modifier.

  public sealed class MySealedClass

      protected void Process()

          // Might as well be private

      public virtual void WillNotCompile()

          // A C++ feature only, so that was easy :)

Static holder types should be sealed
Static holder types should not have constructors

Take the following:

  public class MyStaticClass

      public static void DoWork()

          // Do stuff here...

This class only contains static members, so there is no reason to create instances of the class. When this is compiled, however, the class will be given a default public constructor. Prior to .Net 2.0, the fix was to implement an empty constructor and set the access level to private. Beginning with .Net 2.0, an easier fix is to set the class itself to static.

Unit test all enum values with NUnit

2010-04-19T13:49:00.000-05:00

In an older post I demonstrated NUnit's built-in parameterized tests feature. This allows a developer to call a single method to run multiple tests.

Let's say I want to run the test for each value in an enumeration. Using the TestCase attribute, I can write the test like this:

  [TestCase(Powertools.Chainsaw)]

  [TestCase(Powertools.CircularSaw)]

  [TestCase(Powertools.PowerDrill)]

  public void PowerToolsTestExplicit(Powertools p)

      // Do test

Which is fine, but what if I add a new value to the enum? Instead of having to add another attribute to the test, it would be easier to loop over all enum values at runtime. With the TestCaseSource attribute I can do just that.

Within my unit test class I first create a method that returns an IEnumerable (in this case Array) containing the enum values:

  public Array GetPowerTools()

      return Enum.GetValues(typeof(Powertools));

Then I create my unit test and decorate it with the TestCaseSource attribute. The attribute constructor takes one parameter, sourceName, which is the name of the method to call:

  [TestCaseSource("GetPowerTools")]

  public void PowerToolsTestWithIEnumerable(Powertools p)

      // Do test

In either case, this expands my unit tests as expected. The second method is easier to maintain and less likely to allow untested code into the system.

Remove unused code

2010-03-29T16:34:00.000-05:00

When considering the next set of FxCop rules to enable on the build server, my first thought was to look at those dealing with properly disposing of objects. Scanning the active projects at work has revealed a rule-set slightly more important - unused code. In some of our older code bases there are a variety of methods, variables, etc. that are no longer being used. Deleting the dead code will make it easier to understand what the code is actually doing. In many cases, this will also fix a variety of other FxCop issues, as the flagged items are no longer present. Why fix what you will eventually delete?

And before I go over the rules I should emphasize deletion of dead code. I've seen numerous instances where a developer has commented out, #ifdef'd, or otherwise excluded a section of code. In some cases this was to finish or re-implement the code later. In other cases it was to remove code not currently needed. Regardless, this should be avoided. Tracking previous revisions of code is what source control is for.

The first rule to address is Avoid uninstantiated internal classes. This is a class not visible outside the assembly and is never actually used within that assembly. If you're lucky, deleting this class will improve a variety of code metrics (the number of FxCop warnings being just one of them.)

For the next examples I reference the following class:

    9   public class Unused
   10   {
   11       int unusedPrivateField;
   12 
   13       private void UnusedPrivateCode()
   14       {
   15           Debug.WriteLine("This method isn't called");
   16       }
   17 
   18       internal void DoWork()
   19       {
   20           int unusedLocal;
   21           Debug.WriteLine("This is the only method possibly called");
   22       }
   23   }

Working through the code, line 11 returns a warning for the rule Avoid unused private fields. Notice that none of the methods use it and it isn't exposed through a property.

Next, the method UnusedPrivateCode violates, you guessed it, Avoid uncalled private code. This method is uncalled locally and unreachable outside the class.

The final violation is of type Remove unused locals, at line 20. The variable is not used within the method and can be removed. Note that this rule will also fire if the variable is assigned to, but its value is never actually used. An example:

   18   public void DoWork()
   19   {
   20       int unusedLocal = 0;
   21       unusedLocal = 12; // Still not using...
   22   }

Rethrowing exceptions to preserve stack details

2010-03-04T23:20:00.002-06:00

In my last post, I described our plan at work to introduce FxCop into our development process. The first rule we will be enforcing is RethrowToPreserveStackDetails.

The following example violates the rule:

   12   public void MyTest()

   13   {

   14       Process();

   15   }

   17   public void Process()

   18   {

   19       try

   20       {

   21           int result = Calculator.Divide(12, 0);

   22       }

   23       catch (DivideByZeroException ex)

   24       {

   25           // React, likely by logging

   26           throw ex; // <- This is wrong

   27       }

   28   }

Executing this code results in the following logged callstack

  ...FxCopTests.Process() in C:\test\FxCopTests.cs:line 26
  ...FxCopTests.MyTest() in C:\test\FxCopTests.cs:line 14

Note that the callstack ends with line 26, which is in the catch block. In this example the real exception location isn't hard to find. Unfortunately, production code is rarely this simple.

The problem here is that calling "throw ex" causes the callstack info to be created at that point. If you were creating a new exception and throwing it this would be desired behavior. With an existing exception you don't want the original callstack to be overwritten.

The fix for this code is easy enough - replace:

  throw ex;

with

  throw;

After this change, the callstack correctly points to the line throwing the exception

  ...Calculator.Divide(Int32 x, Int32 y) in C:\test\Calculator.cs:line 11
  ...FxCopTests.Process() in C:\test\FxCopTests.cs:line 26
  ...FxCopTests.MyTest() in C:\test\FxCopTests.cs:line 14

FxCop: A starting point

2010-02-16T19:33:00.001-06:00

In an effort to improve overall code quality at work, we are initiating manual and automated code reviews. One of the tools we will be using for automated reviews is FxCop. There are just two minor issues with this:

Running every rule on an existing code base usually results in a massive backlog
Most developers, myself included, are unfamiliar with at least some of the rules

Granted, several of the rules categories can be turned off on most projects (Portability and Interoperability come to mind.) There are also a few rules that are unimportant or largely obsolete. This still leaves a sizeable list of rules to deal with.

Our planned approach is to enable several of the rules as warnings on the build server. After the developers have addressed any issues, the build will be modified to fail on future violations of those rules. Slowly adding rules, first as warnings and then as errors, will allow us to clean up our existing code base and prevent new violations from being introduced. As we go I will be putting together examples of violations and fixes. I'll post the examples for those who want to follow along at home.

More than one way to sort a List<>

2009-11-13T16:41:00.000-06:00

One operation you occasionally need to perform is sorting a generic list of objects. Often developers code handle with an inline delegate. If I wanted to sort a collection of boardgames by rating, my code might look like this:

  games.Sort(

      delegate(BoardGame a, BoardGame b)

          if (a.Rating < b.Rating)

              return 1;

          if (a.Rating > b.Rating)

              return -1;

          return 0;

});

Although this works, it tends to look a bit cluttered. It also increases a method's complexity and doesn't adhere to the idea of separation of concerns. If we only need to sort Boardgames in this one location, a better solution is to move the comparison code into a separate method in the same class. The new method looks like this:

  public int CompareBoardgamesByRank(BoardGame a, BoardGame b)

      if (a.Rating < b.Rating)

          return 1;

      if (a.Rating > b.Rating)

          return -1;

      return 0;

Our call to Sort looks like this:

  games.Sort(CompareBoardgamesByRank);

This makes the code much cleaner for a single sort. If we want to sort Boardgames by rating from multiple locations, we need a better place to store the comparison method. If we implement IComparable on our Boardgame class, we can create a CompareTo method on the class like so:

  public int CompareTo(object obj)

      BoardGame b = (BoardGame)obj;

      if (Rating < b.Rating)

          return 1;

      if (Rating > b.Rating)

          return -1;

      return 0;

Since the class now has a default comparison, we no longer need to specify a delegate when calling Sort - the CompareTo method will automatically be executed with an empty call:

  games.Sort();

What if we need additional comparison methods for our Boardgame? An easy way to handle this is to create static methods on the class, which will be available anywhere that Boardgame can be accessed. Here are a couple methods I've added to my Boardgame class:

  public static int CompareByName(BoardGame a, BoardGame b)

      return string.Compare(a.Name, b.Name);

  public static int CompareByRankAssending(BoardGame a, BoardGame b)

      if (a.Rating > b.Rating)

          return 1;

      if (a.Rating < b.Rating)

          return -1;

      return 0;

Which I can now pass into the Sort method:

  games.Sort(BoardGame.CompareByRankAssending);

Refactoring assemblies without breaking existing apps

2009-10-20T17:31:00.000-05:00

Over time, most development shops identify common code that needs to be used across multiple projects. This code is eventually collected into a single assembly, usually something like Common.dll or Utilities.dll. In the beginning this is a decent way to eliminate code duplication. Over time, however, this single assembly becomes difficult to maintain.

At this point the obvious fix is to split the assembly into multiple smaller ones. Unfortunately, by then the single assembly is used on numerous projects. A major refactoring now requires extensive changes across all of these referencing applications. This realization usually stops any refactoring effort, leaving the utilities assembly to continue growing larger and more unwieldy.

To look at potential solutions, I've created a Utilities assembly with the following Logger class:

  namespace Utilities

      public class Logger

          public void LogError(string message)

              Debug.WriteLine("Error: " + message);

The goal is to move this class to a separate assembly called LoggingUtilities.

One solution is to use the TypeForwardedTo attribute. This is an assembly-level attribute that flags a specified class as having moved. To use this, I start by moving the Logger class to my new assembly. Note that I keep the same namespace as before - this is required for the forwarding to work.

Next I add a reference to LoggingUtilities within Utilities.

Finally, I open up AssemblyInfo.cs file in the Utilities project and add the following line:

  [assembly: TypeForwardedTo(typeof(Utilities.Logger))]

If I recompile the dlls and drop them in a folder with my existing application, it will continue to function even though the class has been moved.

This takes care of keeping the current compiled code running, but what about future versions? If I open up the source for one of my applications and attempt to compile, I now receive errors stating "The type or namespace name 'Logger' could not be found." It seems the redirection works at runtime but not at compile time. For someone not familiar with the previous refactoring, this could prove an interesting issue to track down.

In my opinion, there is a far better solution than using the TypeForwardedTo attribute. Going back to the original code, this time I copy the code to the new assembly (as opposed to moving it.) On the copy I change the namespace to match my new assembly.

  namespace LoggingUtilities

      public class Logger

          public void LogError(string message)

              Debug.WriteLine("Error: " + message);

In my original Logger class, I create an instance of my new Logger. Each method in the original class now forwards requests to the new Logger instance. In this way, I am wrapping the new class in the original. This allows applications to still use the old class, though the functionality has been moved.

  public class Logger

      LoggingUtilities.Logger _logger =

          new LoggingUtilities.Logger();

      [Obsolete("Use LoggingUtilities.Logger instead")]

      public void LogError(string message)

          _logger.LogError(message);

As before we need to evaluate referencing projects. Because our original class still exists, these applications will continue to compile.

Note that I've added an "Obsolete" attribute to the LogError method. This means we will receive a compiler warning (or error) that we need to change our application to use the new class. This makes it clear what needs to be modified, saving time on any rework.

Code can be both clean and efficient

2009-10-18T13:21:00.002-05:00

Chapter 26 of Code Complete focuses on code tuning - the art of modifying code to improve performance. One example given is a switched loop:

  for (i = 0; i < count; i++)

      if (sumType == SUMTYPE_NET)

          netSum = netSum + amount[i];

      else

          grossSum = grossSum + amount[i];

Notice the 'if' statement inside the loop. If the array is rather large, this statement will be evaluate numerous times, despite the fact that the result will never change. The recommended solution is to unswitch the loop, so the 'if' statement is only evaluated once:

  if (sumType == SUMTYPE_NET)

      for (i = 0; i < count; i++)

          netSum = netSum + amount[i];

  else

      for (i = 0; i < count; i++)

          grossSum = grossSum + amount[i];

This recommendation was given with one warning: this code is harder to maintain. If the logic for the loops needs to change, you have to make sure to change both loops to match.

As with most coding tasks, there is more than one possible solution. In this case the ideal approach is to have both a single comparison and a single loop. If we throw one additional variable into the code, we can calculate the summation and then add it accordingly:

  for (i = 0; i < count; i++)

      arraySum = arraySum + amount[i];

  if (sumType == SUMTYPE_NET)

      netSum = netSum + arraySum;

  else

      grossSum = grossSum + arraySum;

Export filtered Access data to Excel

2009-10-17T22:18:00.001-05:00

In my free time I've been creating an MSAccess database containing a few data-entry forms. One of these forms allows the user to filter records based on several different criteria. This part was relatively straightforward. The difficulty was in trying to export the filtered information to an Excel spreadsheet. Although this functionality exists in Access, the installed help file was less than helpful. Forum posts seemed to contain partial solutions or solve something almost, but not quite what I was trying to do.

The following VBA subroutine is the eventual solution:

Private Sub Export_Click()
    Dim whereClause As String
    
    ' Generate our WHERE clause based on form values
    whereClause = GenerateFilterClause
    
    ' If we have no filter, export nothing
    If IsEmptyString(Nz(whereClause)) Then
        Exit Sub
    End If
    
    Dim query As String
    query = "SELECT DISTINCTROW Contacts.* " & _
            " FROM Contacts " & _
            " INNER JOIN Applications " & _
            " ON Contacts.ContactID = Applications.ContactID " & _
            " WHERE " & whereClause & ";"
    
    Dim filename As String
    filename = "c:\test.xls"

    ' Placeholder query already in the database
    Dim queryName As String
    queryName = "FilterExportQuery"

    ' Update the placeholder with the created query
    CurrentDb.QueryDefs(queryName).SQL = query

    ' Run the export
    DoCmd.TransferSpreadsheet acExport, acSpreadsheetTypeExcel9, queryName, filename
End Sub

Monitoring log files in real time

2009-10-12T02:52:00.001-05:00

Debugging Windows services, especially in a test or production environment, can be tricky. In many cases you won't have access to the box. You certainly won't have the ability to step through the code.

Thus, you are usually forced to monitor log files, looking for an indication of where the problem occurred. The typical method is to start by opening the file in Notepad. Then, when you want to see more recent log entries, you close and reopen the file. This is mildly annoying when dealing with a single service. If your business workflow is split among multiple services, this becomes incredibly inefficient.

An easier solution is to use a log monitor app such as BareTail. For this little demo I am using the free version of the tool.

I have three separate services logging to files named "process1.log", "process2.log" and "process3.log." To keep it simple I am only logging the RequestID for each received request. Here I have loaded all three logs into BareTail.

When I send a new request to the system it should update each log file. BareTail monitors the logs and displays any updates. In the screenshot below, note the new Request ID #2918891. Note also that the document tabs for each file show a green arrow - this indicates an update was made.

As you view each tab, the green arrow will be cleared to visually show which files you have already reviewed.

Say you were trying to debug a request that fails to make it through the system. A quick glance at the document tabs will show you how far a request made it through the system. After reviewing each log (to clear the green markers) we submit another request. In the following screenshot, note that we have a green arrow for process1.log and process2.log, but none for process3.log. So either the second process failed to send the message on, or the third process failed to receive it.

Cleaning up enumerations

2009-09-21T09:43:00.003-05:00

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:

Parameterized tests in NUnit

2009-08-19T21:55:00.005-05:00

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

Save WinForm control values between executions

2009-08-12T11:29:00.007-05:00

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;

No-hassle SQL connection strings

2009-07-14T19:28:00.002-05:00

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.

Quickly escape strings in xml

2009-07-06T02:15:00.000-05:00

If you spend much time working with xml, you will find yourself needing to escape strings. Replacing '<' with '<' 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...

An easier way to manage CruiseControl.Net projects

2009-05-19T13:29:00.001-05:00

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>

Mmc load failure

2009-04-06T10:20:00.007-05:00

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.

Runtime profiling a COM registration failure

2009-03-27T10:58:00.009-05:00

As a continuation of my last post, we had another registration error with the same legacy installer. This time the problem was with mssoap30.dll. Loading the dll in Dependency Walker revealed a single error with dwmapi.dll.

With a bit of web searching we found that dwmapi.dll is only present on Vista and later machines. Since we weren't using that dll directly it shouldn't be the cause of our issue on Windows XP.

At this point it would appear we have all necessary dlls and that our problem must be elsewhere. The documentation on Dependency Walker, however, provides some useful information:

When a module is first opened by Dependency Walker, it is immediately scanned for all implicit, delay-load, and forwarded dependencies. Once all the modules have been scanned, the results are displayed. In addition to these known dependencies, modules are free to load other modules at run-time without any prior warning to the operating system. These types of dependencies are known as dynamic or explicit dependencies. There is really no way to detect dynamic dependencies without actually running the application and watching it to see what modules it loads at run-time.

Version 2.0 and later of Dependency Walker provides a Profile option from the menu. If you have a dll loaded, however, the item is disabled - you have to load an executable first.

For this to work, you need to load regsvr32.exe, which will enable the menu items. Once done, select Profile > Start Profiling to bring up the Profile Module dialog. The only necessary change is to add the dll being registered to the "Program arguments" setting.

Press OK and wait for the application to run. Eventually you will see the usual registration error message box, which you can simply click to continue. Once finished, scrolling through the results shows a couple errors for mssoapr3.dll.

The first error states that the file path specified can't be found. Double-clicking the error shows that it is looking for the dll under "c:\temp\1033". The second states that it cannot find the file - this time in the same folder as the dll we tried to register. So it seems either location is valid for this particular dependency.

Once we add mssoapr3.dll to the same folder, mssoap30.dll registers without issue.

COM dll registration failure

2009-03-24T13:04:00.005-05:00

Every shop has at least one legacy piece of software they have to support. Written in VB6. With lots of copy/paste code and sections that may or may not still be active. By a developer long since gone from the company. It's bad enough to have to deal with the code itself, but try and rebuild the equally-convoluted installer and you might just go mad.

Our problem wasn't in rebuilding the installer, per-se, but in getting it to run successfully afterward. One issue we ran into were COM dlls that failed to self register.

When we attempted to run regsvr32 on this particular dll, we were given an error dialog stating:

LoadLibrary("C:\WINDOWS\system32\pcmcom.dll") failed - The specified module could not be found.

This particular issue is often due to a missing dependency. To verify this we opened up Dependency Walker and loaded pcmcom.dll. In the screenshot below, you can see the yellow question mark symbol next to pcm.dll - our missing dependency. Once we found pcm.dll and its dependencies, pcmcom.dll registered without issue.

Subversion revision corruption

2009-03-20T11:27:00.005-05:00

Say that three times fast...

We ran into an interesting issue earlier this week with Subversion. When attempting to perform any sort of operation on one of our repositories, the operation failed with an error stating "Final line in revision file longer than 64 characters svn: PROPFIND of '/svn/myRepository/myProject'."

When a checkin is made to Subversion, the file differences are compressed and saved to disk under \myRepository\db\revs\. Each checkin will be in a separate file named to match the revision number. Thus revision 1200 is saved to a file named "1200" (no extension.) If you open one of these files in a text editor, you will mostly see unreadable binary. One noticeable feature in all of the files is a pair of numbers on the last line - "10550 10745" perhaps. In our particular case the final revision contained two additional lines following the number pair:

100.1.1.10 - myUser [16/Mar/2009:10:12:06 -0500] "PROPFIND /svn/myRepository/!svn/bln/2914 HTTP/1.1" 207 464
100.1.1.10 - myUser [16/Mar/2009:10:12:06 -0500] "PROPFIND /svn/myRepository/myProject HTTP/1.1" 207 714

These lines are normally found in the Apache log file - not a good sign. A web search verified that it is a known issue with no resolution. The good news is that the page links to a Python script that attempts to repair corrupt revisions. (More information on using the script can be found here.)

The bad news? The script didn't entirely work for us - some of the header info on the compressed diffs had been lost. Fortunately, it did remove the Apache log info from the tail of the file, so other developers could again work. The only section now corrupt was the project where the revision error occurred. This project started returning an error stating "Checksum mismatch while reading representation."

With the issue isolated, the next step was to remove the corrupt revision. Unfortunately, the only way to do that in Subversion is to export the good revisions and then build a new repository using those exports. Say revision 120 is bad and we have a total of 150 revisions. We start by dumping revisions 1 through 119 to a file:

svnadmin dump c:\myRepository\ -r1:119 > c:\DumpPart1.dmp

We then need an incremental dump for changes 121 through 150:

svnadmin dump c:\myRepository\ -r121:150 -- incremental > c:\DumpPart2.dmp

Rename the folder "myRepository" to something else as a quick backup, then create a new database:

svnadmin create c:\myRepository

Copy any config files from the backup repository (such as user accounts) then load the dumps into the new database:

svnadmin load c:\myRepository < c:\DumpPart1.dmp
svnadmin load c:\myRepository < c:\DumpPart2.dmp

One item of note: Loading a Subversion dump effectively creates new checkins for each item in that dump. All items in the second dump above will have a revision number one lower than previously - checkin 121 in the old database becomes checkin 120 in the new database. Though I've not seen it, some developers may receive an error if their local code contains a newer revision number than the database. As I ran a few test checkins after creating the new database, this wasn't a problem.

Debugging InstallUtil.exe

2009-03-06T09:18:00.005-06:00

The project I'm currently working on contains a Windows service with a number of performance counters. To run the code on a dev machine, we prefer to do so without first running an msi. So to get the performance counters installed, we tried to run installutil on the service executable. Which of course returned a vague error message and rolled back the changes. Fortunately, this type of problem wasn't too difficult to debug.

To demonstrate, I've created a new application and added a class that inherits from Installer. I've overridden the OnBeforeInstall event as follows:

protected override void OnBeforeInstall(IDictionary savedState)

    base.OnBeforeInstall(savedState);

    string nullString = null;

    int invalidLength = nullString.Length;

If I attempt to run "InstallUtil MyApp.exe" I receive the following within the console output:

An exception occurred in the OnBeforeInstall event handler of MyApp.MyAppInstaller.
System.NullReferenceException: Object reference not set to an instance of an object.

For trivial code such as my above sample, tracking down the problem should take most developers all of five minutes. Once you have a non-trivial amount of code (which was the case at work) you need a little more information. If I call "InstallUtil /ShowCallStack MyApp.exe" I receive the exact line where the problem occurs:

An exception occurred during the Install phase.
System.InvalidOperationException: An exception occurred in the OnBeforeInstall e
vent handler of MyApp.MyAppInstaller.
at System.Configuration.Install.Installer.Install(IDictionary stateSaver)
at System.Configuration.Install.Installer.Install(IDictionary stateSaver)
at System.Configuration.Install.AssemblyInstaller.Install(IDictionary savedState)
at System.Configuration.Install.Installer.Install(IDictionary stateSaver)
at System.Configuration.Install.TransactedInstaller.Install(IDictionary savedState)
The inner exception System.NullReferenceException was thrown with the following
error message: Object reference not set to an instance of an object..
at InstalUtilDebugging.MyAppInstaller.OnBeforeInstall(IDictionary savedState)
in C:\source\temp\InstalUtilDebugging\MyAppInstaller.cs:line 23
at System.Configuration.Install.Installer.Install(IDictionary stateSaver)

In many cases, this will be enough to solve the problem. There may be cases, however, where you need to attach a debugger to the process and step through the code to see where a problem actually started. To do this I add the following line to the beginning of OnBeforeInstall:

System.Diagnostics.Debugger.Launch();

After I recompile and again run InstallUtil, I am given a JIT Debugger dialog which allow me to attach to the process.

I select the instance of VisualStudio that has my install code and click 'Yes' to begin debugging. You may be given a warning stating "There is no source code available for the current location." Click 'OK' and press F10 once - this will show the Debugger.Launch statement as the current line of code being executed. From here debugging works as in any application.

Visual Studio installer projects - which project did I forget to include?

2009-02-17T16:04:00.007-06:00

I made an interesting discovery while working on a project the other day. As I watched the compiler output from a particularly large solution I noticed several of the required assemblies were being built after the installer project. The reason was that someone forgot to add these assemblies to the installer. Normally this isn't hard to find and fix, but this particular solution has 150 projects, 149 of which need to be included in the installer. Manually comparing the list of installer dependencies to the list of projects takes quite a bit of time and is error-prone. Fortunately we can use the Project Dependencies screen to quickly find the missing items.

To illustrate, I've create a simple solution with five assembly projects and an installer project.

As I add each project to the installer, we see the primary output added within the installer

It looks simple enough when you only have a few projects. Add a couple dozen more and you can see that things are going to become more difficult.

To get a better view of the installer's dependencies, right-click on the solution in the Solution Explorer and choose "Properties." On the Property Pages dialog, choose Common Properties > Project Dependencies from the tree on the left. Under the Project dropdown on the right, select the installer project.

Here is my installer before adding any projects

After I add AssemblyA to the installer, the Project Dependencies looks like this

Notice the box beside AssemblyA now contains a checkbox. As I continue adding projects, each of these will be similarly checked. Below is an example after all but one assembly has been added. Even with 149 projects to include, it takes very little time to scan through the list and see which items remain unchecked.

Subversion failure to copy file

2009-02-11T12:33:00.003-06:00

We ran into some difficulty today adding a new project to our build server. We kept getting an svn error stating:

"Can't copy 'C:\MyProject\_svn\tmp\text-base\web.config.svn-base' to 'C:\MyProject\_svn\tmp\web.config.tmp.tmp'.

Not the most helpful of error messages, as I have no knowledge of the inner-workings of svn. Fortunately, a quick Google search turned up a TortoiseSVN FAQ entry that proved useful.

In our code repository we had two web.config files in the same directory. The only difference was one had an initial uppercase 'W' while the second was lowercase. SVN handles this just fine internally. The problem occurs when you attempt to pull them down to the same location on a Windows machine. Since Windows ignores casing, these were being treated as the same file. SVN was complaining that the folder didn't contain the second copy of the file. Deleting one of the copies in SVN fixed the build error.

Row tests in NUnit

2009-01-23T14:30:00.007-06:00

[Update 8/19/09: As of version 2.5, the extensions are no longer installed with NUnit. See my post on parameterized tests for a replacement.]

File this one under "old features I'm only now learning about." It seems NUnit has had a RowTest extension built in since March of 08...

For example, let's say I have a method called Add that adds two integers and returns the result. (The internals of that method are highly complex and I won't go into details here.) If you wanted to test two positive integers, a unit test would look like this:

[Test]

public void AddTwoPositiveNumbers()

    Assert.AreEqual(2 + 3, Add(2, 3),

        "Add returned incorrect result");

To test two negative integers you would historically create a second, nearly identical unit test:

[Test]

public void AddTwoNegativeNumbers()

    Assert.AreEqual(-1 + -4, Add(-1, -4),

        "Add returned incorrect result");

For reference, the two tests will appear under the class name when viewed through the NUnit GUI.

Now, these don't seem too bad, but what happens if you needs lots of nearly-identical tests? Or these tests need to perform additional steps? Copy/paste is a bad programming practice, even for unit tests. Fortunately, Nunit provides an extension (under the NUnit.Framework.Extensions namespace not surprisingly) that makes life much easier - the RowTest.

To use, create a single test method with parameters for the varying test data. Decorate the method with a RowTest attribute, and one Row attribute for each test case. The above unit tests can now be replaced by:

[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");

Changes to the test set becomes much easier, as does adding new tests. In the GUI, you'll see each Row split out as an individual test beneath the generic test:

Debugging XSL Transformations in VisualStudio 2005

2008-12-12T10:46:00.010-06:00

I've been doing a bit of work lately with XSL transforms. While searching for a good transform debugging tool, I found that I had a decent one already installed - VisualStudio. To demonstrate, I pulled sample xml and xslt from the W3Schools site. (Click on each image to see a larger version.)

With the xsl template loaded in VS, right-click anywhere on the xslt and choose Properties. In the Properties window, set the Input value to point to the sample xml file (cdcatalog.xml in this case.)

At this point you can run the transform to view the output. Choose "XML" > "Debug XSLT" from the menu.

Nothing terribly interesting so far. The real fun doesn't start until you realize you can set breakpoints within the xslt. This is done the same as with other types of code files (by clicking the grey strip on the left or pressing F9.) Now, when you start the debugger, processing stops at the specified line. As expected, hovering the mouse over a variable or expression gives you a tooltip with the value.

Several of the other debug windows are also usable in this mode, such as the Locals and Immediate window.

New Year's Resolutions

2008-12-11T14:52:00.002-06:00

I was looking through my "to blog" list recently and I was reminded of something: I have a LOT of items on my list. Two or three times the number of posts I've written thus far. What's worse is some of these items would actually make an entire series of posts. At my current rate of posting (once or twice a month) I'm never going to finish.

Then there are the computer books sitting on my shelf, several of which I've not read much passed the intro. Some may not be worth digging into right now, but a few of them are "must reads." Code Complete for example. Or Head First Design Patterns. I've not finished either of them, and have yet to fully grok what I have read.

The question then is how to tackle these lists? It seems the only way to stay motivated is to come up with a schedule and then stick to it. Read one chapter a week. Write a blog post a week. Or if I work it just right, I could write a blog post on the chapter I just read. But what if I get bored with one subject? Do I switch between books each week, or should I stick to one until I finish? If I want to post on what I'm reading, how much original content is necessary and how much can I quote or link to?

I'm off to ponder these questions (or read web comics, I've not decided which.) What are your thoughts on the subject? Do you have any professional goals to tackle next year? (Or even non-professional goals?) And if so, how do you plan to keep on track?

Batch permission change for MSSQL stored procs

2008-11-18T10:01:00.003-06:00

I recently ran into a batch of existing stored procs that needed additional execute permissions. After some digging on the web I was able to put together a simple script to make the changes. Since I'll likely need it again in the future, I decided to throw it out here.

Assuming all of the stored procs contain the string 'MyApp' in the name, and all need execute permissions added for 'myuser', the following will make the necessary change

  declare @SQL varchar(8000)

  select @SQL = isnull(@SQL, '') +

    'grant execute on [' +

    routine_schema + '].[' +

    routine_name + '] to [myuser];'

  from information_schema.routines

  where SPECIFIC_NAME like '%MyApp%'

  exec (@SQL )

Refactor - Moving duplicate code to a separate method

2008-09-11T20:51:00.010-05:00

I've mentioned in previous posts that it pains me to see developers use copy/paste to write code. It's more error prone, as you have to make sure all necessary changes are made to the copy. It's also harder to maintain since finding a bug in one copy of the code means making changes to the others - assuming you can find those copies. Depending on the circumstances, it can also be harder to read the code. As I keep running into less-than-ideal code, I decided a few posts were in order.

Today, let's look at a method that builds an XmlDocument based on values from a database. Here, the info is passed in a DataRow object.

public XmlDocument GenerateMailingLabel(DataRow subscriber)

  XmlDocument doc = new XmlDocument();

  doc.LoadXml("<MailingLabel><SendTo /></MailingLabel>");

  XmlNode sendToNode = doc.SelectSingleNode("//SendTo");

  XmlAttribute attribute = doc.CreateAttribute("FirstName");

  attribute.Value = subscriber["FirstName"].ToString();

  sendToNode.Attributes.Append(attribute);

  attribute = doc.CreateAttribute("LastName");

  attribute.Value = subscriber["LastName"].ToString();

  sendToNode.Attributes.Append(attribute);

  attribute = doc.CreateAttribute("StreetAddress");

  attribute.Value = subscriber["StreetAddress"].ToString();

  sendToNode.Attributes.Append(attribute);

  attribute = doc.CreateAttribute("City");

  attribute.Value = subscriber["City"].ToString();

  sendToNode.Attributes.Append(attribute);

  attribute = doc.CreateAttribute("State");

  attribute.Value = subscriber["State"].ToString();

  sendToNode.Attributes.Append(attribute);

  attribute = doc.CreateAttribute("Zip");

  attribute.Value = subscriber["Zip"].ToString();

  sendToNode.Attributes.Append(attribute);

  return doc;

There's nothing terribly complex going on here. It starts by creating a new, nearly empty XmlDocument. It then pulls necessary values out of the DataRow and adds them as attributes to the <SendTo> node. Modifying existing attributes appears to be easy, as each one is isolated to a single block of three lines. Adding new attributes is similarly straightforward. Copy an existing block, paste it just before the 'return', and then modify the two string literals. If it's so easy to work with, why change the code?

First, you have to make sure you modify both string literals correctly. Fail to modify one or both of them and you have a bug that may not be caught any time soon.

Second, these types of methods tend to become long. It may be easy to read currently, but what happens when you have twenty attributes to add to the document? Picking out a particular block to modify becomes a bit more challenging. This is especially true if you're currently lacking in sleep and/or caffein.

Third, a structural change to the xml document becomes a slow, tedious task. Maybe halfway through the project someone decides you need to create sub-elements instead of attributes for each value. In the above code, you have six sets of changes to make.

A better solution would be to pull the block of three lines into a separate method:

private void CreateAttribute(string attributeName, string columnName,

  XmlDocument doc, XmlNode sendToNode, DataRow subscriber)

  XmlAttribute attribute = doc.CreateAttribute(attributeName);

  attribute.Value = subscriber[columnName].ToString();

  sendToNode.Attributes.Append(attribute);

Once we've done this, each block of code in the GenerateMailingLabel method can be reduced to a single line:

public XmlDocument GenerateMailingLabel(DataRow subscriber)

  XmlDocument doc = new XmlDocument();

  doc.LoadXml("<MailingLabel><SendTo /></MailingLabel>");

  XmlNode sendToNode = doc.SelectSingleNode("//SendTo");

  CreateAttribute("FirstName", "FirstName", doc,

    sendToNode, subscriber);

  CreateAttribute("LastName", "LastName", doc,

    sendToNode, subscriber);

  CreateAttribute("StreetAddress", "StreetAddress", doc,

    sendToNode, subscriber);

  CreateAttribute("City", "City", doc,

    sendToNode, subscriber);

  CreateAttribute("State", "State", doc,

    sendToNode, subscriber);

  CreateAttribute("Zip", "Zip", doc,

    sendToNode, subscriber);

  return doc;

Now adding a new attribute requires one additional line instead of three. Even better, bug fixes or structural changes will be limited to a single section of code. In either case, changes can be made faster and with less risk of introducing bugs.

Verify user membership in an AD group

2008-08-29T16:22:00.005-05:00

Occasionally, when working on a WinForms application, I need to validate the current user against an Active Directory group before letting the application run. Though not a complex task, it usually takes me a bit of time to research (Translation: I have to copy code from several web sites and modify to suit my needs.) So I figured I'd post my own implementation here for others to use in their research. That, and maybe save myself a bit of time in the future.

The first step is to get the list of AD groups the current user belongs to. The magic necessary to make this happen is contained in the System.DirectoryServices namespace. The code to return the list looks like so:


internal static List<string> GetADGroupsForCurrentUser()
{
    List<string> groups = new List<string>();
    string domainName = Environment.UserDomainName;
    DirectoryEntry entry = new DirectoryEntry("LDAP://"
          + domainName);
    string filter = "(samAccountName="
          + Environment.UserName + ")";

    DirectorySearcher search = 
          new DirectorySearcher(entry, filter);
    search.PropertiesToLoad.Add("memberOf");

    SearchResult results = search.FindOne();
    int groupsCount = results.Properties.Count;
    for (int i = 0; i < groupsCount; i++)
    {
        string groupString = 
            results.Properties["memberOf"][i].ToString();
        groups.Add(groupString);
    }

    return groups;
}

Once we have the list, we need to loop through it looking for the desired AD group. The strings returned from the above code contain comma-delimited properties (something like "CN=MyDomainGroup,OU=Security Groups,DC=local".) Because of this I'm using the Contains method to search the string for the desired domain name. I'm sure there's another way to do this, but whatever works...


public static bool CurrentUserIsAuthorized(string authorizedGroupName)
{
    List<string> activeDirectoryGroups =
          GetADGroupsForCurrentUser();
    foreach (string group in activeDirectoryGroups)
    {
        if (group.Contains(authorizedGroupName))
            return true;
    }

    return false;
}

Intellisense for WCF config files

2008-08-27T09:17:00.003-05:00

I found it slightly irritating that there is no intellisense for WCF config files built into VS2005. Fortunately a quick Google search turned up a blog post with a solution. I figured I'd post it here so I can find it later. That, plus it allows me to meet my self-imposed quota of at least one blog entry per month :)

The solution can be found here.

Don't make me GAC

2008-07-13T14:17:00.005-05:00

We discovered an interesting "feature" in VisualStudio 2005 a couple days ago. Let's say I have a solution containing a Utilities project and a web site referencing that project. The Utilities assembly references a third-party dll (log4net in this case.) When the web site is compiled, it automatically pulls any dependent files into its 'bin' folder. Note the presence of log4net.dll

This seems fairly straightforward. But let's say I then load the solution on another computer (a build server perhaps.) The code compiles as before, but this time it doesn't pull in log4net.dll

At this point, I could manually copy the dll into the folder, right? That was my first thought, which of course proved to be wrong. The reason is that we also have an install project for the site. The installer is set to use all output files from the web project. If we add files to the site, the installer will automatically include them in the next compile. Unfortunately, when I manually add the dll to the bin folder, the installer overlooks it.

My next thought was to directly reference the log4net.dll in the web project.

Which still compiles on my box. And still ignores the dll on the build server. At this point, we opened up the references dialog on the build box. Much to our surprise, the dll is being referenced in the GAC

It seems that when a web project loads, it first looks in the GAC for referenced assemblies. If it finds them there, it ignores the files originally pointed to. Because of this, VisStudio doesn't copy the files to the bin folder. Which of course means the installer won't contain the dll.

Ideally, the dll shouldn't have been GAC'd on the build server. Since removing it from the GAC would cause us other issues, our workaround was to hard-code log4net.dll in the install project.

Note: The web site was built using the out-of-the-box project template, which doesn't create an actual .proj file. Microsoft later released a Web Application Project (with VS2005 SP1) that does create a .proj. It's possible that this would force the dll to load from the file reference, but I've not tested that theory.

Wrapping a class in a singleton

2008-06-22T14:31:00.006-05:00

My current task at work has me building a new application, using an existing framework as the base. One of the classes in this framework wraps access to the config file (which is actually kept in the database.) As soon as this class is instantiated, it retrieves the config info from the database. I wanted a way to keep a single instance around for the lifetime of the application. Otherwise, I'd be hitting the database multiple times to pull down the same information.

One option would have been to create an instance in the app's constructor. The downside to that approach is that I'd have to pass it into every method that might need it. Instead I chose to use the singleton pattern.

Below is a quick example. Marking the MyConfig class as static means it can't be instantiated. The static constructor will be called once and only once - the first time the class is accessed. This constructor creates an instance of the CommonConfig class, which can be accessed through the Config property. Now, regardless of how many times my code accesses MyConfig.Config, the database is only hit once.

    public static class MyConfig

        static readonly CommonConfig _commonConfig;

        static MyConfig()

            _commonConfig = new CommonConfig();

        public static CommonConfig Config

get

                return _commonConfig;

Add scroll wheel support to VB6

2008-05-09T14:04:00.002-05:00

Yes, you read that right. The client I'm currently assigned to has a significant amount of legacy code in VB6. Not an ideal situation, but at least it isn't COBOL.

Anyway, one of the first things I noticed after loading a project was that I couldn't scroll through the code using the mouse wheel. It turns out the VB6 IDE didn't include wheel support. Fortunately, there's an add-in from Microsoft that fixes this. See KB article 837910 for the download and install instructions.

And yes, I'm aware that this probably doesn't pertain to you (if it does, I feel your pain.) The post is mainly a bookmark for my own reference. Any sympathy it generates is just a bonus :)

DotNetMigrations

2008-05-08T12:29:00.002-05:00

A friend of mine recently ported the Ruby on Rails "Migrations" tool to .Net. Assuming you can get all of the developers on a team to script out their database changes (and matching rollbacks) this tool will make it easier to build, update and deploy your database. It also becomes trivial to revert the changes when something breaks unexpectedly.

You can find details here.

Adding entries to a file's right-click menu

2008-05-08T10:32:00.005-05:00

When setting up a new developer computer, there are a number of tools and shortcuts I typically want. One of these is the ability to register COM dlls through Explorer's right-click menu. The easiest way to add this is through the registry.

Standard warning: I'm sure you're aware that messing with the registry may cause all sorts of problems. Proceed with caution. Unless of course it's not your computer you're messing with. In which case, hack away.

Start regedit from the Run dialog (keyboard shortcut: Win+R.) Under HKCR (HKEY_CLASSES_ROOT) locate the extension of the file to modify - .dll in this case. In the list of properties, you should see a "(Default)" string with the internal name of the file type. For dll it will be "dllfile."

Further down, still under HKCR, will be an entry for dllfile. This is where the changes will be made.

Under dllfile, expand the "shell" key. Add a new key and set the name as you want it to appear on the right-click menu (mine is "register".) Within that, add another key with the value "command." The "(Default)" string needs be set to the command that you want to run. For this exercise it will be:

regsvr32.exe "%1"

Regsvr32 is the command-line utility to register the COM component. The %1 in quotes tells Windows to pass in the filename and path as the first parameter.

Once this is done, you should be able to right-click on any dll and see the new entry.

This takes care of one machine. Now that you have the shortcut defined, it would be useful to copy this to other machines. To do so, right-click on the "register" key and choose Export. Saving the selected branch will give you a .reg file with the changes. Copy the file to another computer and double-click to import it into the registry of that computer.

Metadata? But the code's right there...

2008-05-02T10:01:00.008-05:00

Here's a highly complex bit of code I've been working on

In this example I have a Customer class in MyAssembly2, which you can see is a separate project in the solution. On the main form of the application I'm making a call to the Customer instance method SaveToDatabase. If I right-click on the method call and choose "Go To Definition" I'm taken to a page of metadata.

This lets me see method signatures but not the code within those methods. If I were to try the same thing for my Utilities class, however, I'm taken to the .cs file within MyAssembly1. So what's the difference?

Here are the reference properties for the two assemblies:

The two are almost identical, but if you look closely, you'll see that MyAssembly2 has a "Specific Version" property where MyAssembly1 does not. This is because MyAssembly2 was added as a file reference - we pointed VisualStudio at the compiled dll instead of the project. Because of this, VS doesn't know that the dll and project are really one and the same.

The fix is a simple matter of deleting the reference to MyAssembly2 and re-adding - this time as a project reference.

Everyone should be good at something

2008-04-29T11:20:00.001-05:00

Anyone who's worked with me in recent years knows how much I love deleting code. It could be removing something that's obsolete or refactoring to reduce duplication. Or maybe the requirements change mid-project. Needless to say, some question whether my SLOC (source lines of code) output is positive or negative.

Regardless, I stumbled upon a shortcut in VisualStudio (Shift + Del) that deletes the entire line where the cursor is located. No more selecting the whole line and then pressing Delete. I've become a code-deletion ninja!

Unlocking files when Visual Studio can't

2008-03-14T11:07:00.002-05:00

There's an option in Visual Studio that, on compile, will pull all of your XML comments out into separate files. These can then be combined into a help file using a tool like Sandcastle. Most of the time this feature works correctly. If you cancel a build in process, or the compile fails, VS occasionally fails to release the file lock. From that point on, the compile fails with an error stating the file is in use by another process. I've not found a way within VS to force an unlock short of closing the app.

There is, however, a faster way using Process Explorer. Start Process Explorer and select Find > Find Handle or DLL... from the menu. Enter all or part of the filename currently locked, then click Search. You should see the guilty process - devenv.exe in this case.

Double-clicking on the entry will display a list of handles for that app, with the selected handle highlighted. Right-click on the selection and choose Close Handle. You'll see a dialog warning about potential crashes or system instability (meaning don't try this with a system file.) Tell it to continue and the handle will be closed. VS will again compile without issue.

I can read the file myself, thank you

2008-02-26T09:11:00.003-06:00

I've been downloading a number of PDFs lately, and the one thing that has been bugging me is the slow performance of Adobe Reader. Fortunately, I've found at least one of the major causes - the accessibility features. When opening a PDF, I was occasionally presented with a dialog stating "Please wait while the document is being prepared for reading." A quick search on the web located others with the same problem. This post, along with one of the comments, led me to the solution:

Locate the install folder (C:\Program Files\Adobe\Reader 8.0\Reader\plug_ins) and delete the following files

Accessibility.api

MakeAccessible.api

ReadOutLoud.api

Though I didn't break out the stopwatch, the performance improvement was significant. Before, there would be a pause after scrolling more than a page or two. Now, I can hold the PageDown key and see dozens of pages fly by before any pause (probably to allocate more memory.)

Automate config changes for different environments

2008-02-12T09:59:00.000-06:00

Most applications I've worked on contain one or more config files. These are generally used to track web service locations, database connection strings, and logging information. Keeping these settings outside the code makes it easy to modify them without a recompile. This is especially useful when moving a deployment from dev to test, or from test to production.

On most of these projects, the preferred method used by developers is to keep multiple config files in the source repository. These are distinguished by simple renaming of the files (such as app.config, app_qa.config, app_prod.config.) In theory this should work - once you have the config files set up for each environment, deployment requires replacing the file as appropriate. And if you use a .bat file or build script, the file rename will be automatic.

The scenario usually overlooked, however, is the case where something in the config changes. Maybe a new web service is being used by the application. Or perhaps a new assembly needs to be referenced. In my experience, the developer often makes the changes to the main file (app.config), but forgets to make the same changes to the others. During development the code appears to work fine. Unfortunately, the app fails to run in the QA environment. Usually, some amount of time is spent by the developer before realizing that the problem is with the config.

To reduce this sort of issue, I recommend only keeping one config in the source repository. This config will contain the values necessary to run in the development environment. During the build process, the config is updated for the target environment. The MSBuild Community Tasks contains a FileUpdate task that makes this easy.

Let's say you have a config file with the following:


<appSettings>
    <add key="MyWebService" value="http://localhost/service/MyWebService.asmx" />
</appSettings>

The msbuild script to deploy to QA would contain:


<PropertyGroup>
    <MyAppConfigFile>c:\source\MyApp\app.config</MyAppConfigFile>
    <MyWebServiceRegex>http://.*/service/MyWebService.asmx</MyWebServiceRegex>
    <QaWebServicePath>http://QaServer/service/MyWebService.asmx</QaWebServicePath>
</PropertyGroup>
<Target Name="ConfigureQA">
    <FileUpdate
       Files="$(MyAppConfigFile)"
       Regex="$(MyWebServiceRegex)"
       ReplacementText="$(QaWebServicePath)" />
</Target>

A twisted, yet valid observation

2008-01-03T08:30:00.000-06:00

Today, I again saw what is an all too frequent occurence in some dev shops - a failed build.

Rather, a grossly negligent failed build. One that could have easily been avoided. So to that developer, and others of similar ilk, I send this message:

I know you only changed one line in a single file. And I'm aware it takes ten minutes to build the solution on your machine. I even realize that no one was going to pull down code at that precise moment.

Nothing, however, pains the resident Build Guy more than that big red Build Failed icon. Every time I see that, a little piece of me dies.

And no, Fellow-Programmer-Who-Shall-Remain-Nameless, remembering to build immediately after checking in the file is not "close enough." Sure you'll have the fix checked in even as the build reports the failure. And sure, any other time of the day I would have been wandering the halls and never would have known. But apologies won't help. It's still too little, too late. It's like applying the brakes after running over the cat...

Customizing DataTips

2008-01-01T15:44:00.000-06:00

A convenient debugging tool in Visual Studio is the ability to hover the mouse over an object and see the information currently stored there. This is referred to as a DataTip.

If the class is derived from a base class, or contains other objects within, you can drill down to see those values as well. Depending on the complexity of the object however, this can become tedious. This is especially true if there are a couple values that you always want to see when debugging.

To quickly see one or more properties on a class, you can do so using the DebuggerDisplay attribute in System.Diagnostics. If I add the following to MyBaseClass, I can view the value of X without expanding the DataTip. (The property to display is placed in braces.)


[DebuggerDisplay("The value of X is: {X}")]

If I derive a new class from MyBaseClass, I can set a DebuggerDisplay attribute that accesses values both from this class and the base.


[DebuggerDisplay("{X}, {Y}")]
class MyDerivedClass : MyBaseClass
{
    private int _y;
    public int Y
    {
        get { return _y; }
        set { _y = value; }
    }
}

Treat Warnings as Errors

2007-12-28T08:49:00.000-06:00

In a previous post I mentioned the importance of fixing compiler warnings. I forgot about a useful project setting in Visual Studio that will cause all build warnings to display as errors instead. From the project's properties page, select the Build tab. Under "Treat warnings as errors," set the value to "All." While this may be difficult to justify on existing projects with hundreds of warnings, this is something that should be set on all new projects.

Quick and dirty debugging - DebugView and Trace.WriteLine

2007-11-06T08:29:00.000-06:00

Here's another debug scenario for you. After taking great effort in testing your application you hand it off to QA. They throw it back with some interesting bug. Using the exact same steps, you're unable to reproduce on your machine. You have a general idea of where the app is failing, but can't be sure precisely what the issue is.

At this point one usually resorts to some sort of logging. These logging statements are placed in strategic locations through the suspect code (at every other line.) If the bug is in the UI, the common method is MessageBox.Show. If the problem is in an underlying assembly, you must resort to writing output to a text file. The downside is that lots of message boxes wear you out, and it's always a pain tracking down the necessary code to write files.

An easier option is to call Trace.WriteLine (located in System.Diagnostics.) In my sample application (MyApp) I have a single button. Inside the Click event, I add the following line

 Trace.WriteLine("Button1 was clicked");

The event then calls a method in a separate library. In this library method, I've added the following line ('x' was the parameter passed into the method)

 Trace.WriteLine("SomeMethod - Parameter x: " + x.ToString());

When I run the application from VisualStudio and click the button, the Output window contains the trace messages

That's fine if you're running VS, but what about on a QA box? For that I'm using DebugView. After starting up the utility, I fire up the sample application. Click the button (which again calls Trace.Writeline) and DebugView displays the messages previously seen in Visual Studio.

Invalid Data Source crashes Visual Studio

2007-11-06T08:23:00.000-06:00

Binding data object to a WinForms control is usually straightforward. Say you have a ComboBox control. Clicking the triangle on the top-right will display the ComboBox Tasks dialog.

Once you check the box to "Use data bound items" you start by selecting the Data Source. Normally, clicking the Data Source dropdown provides you with a list of existing items, as well as the option to create a new one. A few days ago we ran into an issue where, instead of the datasources list, we were given this rather entertaining dialog

With a few hints from the blogging community, we were directed to the Data Sources window (Data > Show Data Sources, or Shift+Alt+D.)

Notice the first entry has an error icon. This is due to a datasource pointing to a non-existent class. Right-click the invalid entry and choose Remove Object. Now the Data Source dropdown behaves as expected.

Debugging with the Fusion logger

2007-11-01T11:02:00.000-05:00

If you've spent much time developing, you've probably run into this scenario. You're working along coding a new application. Everything runs on your machine. Then you hand it off to someone to test (that, or load it on the production server - let the users tell you what's wrong.) Unfortunately, the app crashes as soon as you attempt to start it. Looking in the Event Logs, you see generic .Net errors, but nothing that appears to help. Short of installing VisualStudio on the box in question, how do you track down the issue?

One place to start is the Fusion logs. For this demo, I've created a class library (MyClassLib) and a command-line app (MyConsoleApp.) The app makes a single method call into the library and then exits. Nothing interesting to see when everything works. If I delete MyClassLib.dll and run the application, I witness a rather unpleasant dialog

When an app closes in a violent manner, the first place to look is the computer's event logs. Unfortunately, the only entry for the app looks something like:

"Faulting application myconsoleapp.exe, version 1.0.0.0, stamp 47293d14, faulting module kernel32.dll, version 5.1.2600.3119, stamp 46239bd5, debug? 0, fault address 0x00012a5b."

So now we turn to the Fusion logs. The first step is to copy the Assembly Binding Log Viewer (fuslogvw.exe) from any machine with VS2005. Start it up; it looks something like this:

Click on the Settings button. In the dialog, select "Log bind failures to disk." Check the box to "Enable custom log path" and specify an already-existing folder (the app won't create it for you.)

Note: According to official documentation, you should be able to use the default log directory. In my experience, that never seemed to work.

With the logger set up I again attempt to run the application. Which again crashes. Going back to the Fusion log viewer, click Refresh. I now have a single entry

Clicking on the entry loads the details in Internet Explorer (shown below.) If you look halfway down the log, you'll see the reference to MyClassLib. Near the end, you'll see the various locations it searched for the file. Now it's a simple matter of finding a copy of my dll and placing in the search path.

*** Assembly Binder Log Entry (10/31/2007 @ 10:14:45 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable C:\temp\testcode\MyConsoleApp\bin\Release\MyConsoleApp.exe
--- A detailed error log follows.

=== Pre-bind state information ===
LOG: User = SH\pgoins
LOG: DisplayName = MyClassLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///C:/temp/testcode/MyConsoleApp/bin/Release/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MyConsoleApp.exe
Calling assembly : MyConsoleApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/temp/testcode/MyConsoleApp/bin/Release/MyClassLib.DLL.
LOG: Attempting download of new URL file:///C:/temp/testcode/MyConsoleApp/bin/Release/MyClassLib/MyClassLib.DLL.
LOG: Attempting download of new URL file:///C:/temp/testcode/MyConsoleApp/bin/Release/MyClassLib.EXE.
LOG: Attempting download of new URL file:///C:/temp/testcode/MyConsoleApp/bin/Release/MyClassLib/MyClassLib.EXE.
LOG: All probing URLs attempted and failed.

Implicit conversions

2007-10-19T12:50:00.000-05:00

I'm working on a project where request and response messages are serialized before sending across the wire. We do this by calling an override of ToString(). So a line in the code might look like

    response = myProvider.ProcessMessage(myMessage.ToString());

If I try to type

    response = myProvider.ProcessMessage(myMessage);

I get a build error stating that it cannot implicitly convert type 'SomeCoolMessage' to 'string.' So, what if I want to implicitly convert between the two? In the SomeCoolMessage class I add a new operator

    public static implicit operator string(SomeCoolMessage m)
    {
        return m.ToString();
    }

Now I can write

    response = myProvider.ProcessMessage(myMessage);

and everything just works.

Lessons learned

2007-10-05T16:43:00.000-05:00

My current project is nearing completion of Phase 1. Along the way, I've compiled a list of observations, lessons learned, etc, some of which I've already blogged. Here are a few more:

1) When possible, use project references instead of file references. It may seem convenient to break up the code into smaller solutions and use file references across solutions. Problems arise when you have one master solution that builds all of the projects - you must explicitly set the build order. With project references, VisualStudio determines the proper order for you, meaning less maintenance. Also, when you right-click on a method/class/whatever and choose "Go To Definition," file references will take you to a page of metadata instead of the actual code.

2) Refactor often, and sooner rather than later. Say you're working on set of classes that use a common interface. You then decide to build a base class from that interface, and derive the other classes from the base. Don't leave old classes as-is and use the base only for new classes. One issue is you potentially leave bugs that the base was specifically designed to address. Another is that when a new team member joins the project, he will likely use existing code as a template for adding new functionality. If he sees the non-base-derived class and builds his own directly from the interface, refactoring later becomes more difficult.

3) Remove dead code. When you replace one method with another, delete the old method. When functionality is no longer required, delete that functionality. Don't leave it in. Don't comment it out. If you need that code later, pull it from your source repository. As the source grows in size, you'll have enough to deal with without adding the extra hassle associated with dead code.

4) Obsolete code if you can't currently delete it. Say you replace a method with another, but you can't replace all of the method calls at the moment (this especially happens with public methods.) Mark the method as obsolete and note the proper method to use instead. In C# this looks like [Obsolete("Use method foo instead")].

5) When changing the database schema, change the data access code at the same time. Until these two are in sync, your code doesn't work. You should have failing unit tests to flag the issues, but that's not always the case. In that instance, your first indication that there is a mismatch is when a developer attempts to run code that he thought was working. Often, the developer attempts to track down the problem, which another dev already knew about. All of which leads to wasted time.

6) Reduce confusion within the code. Maybe there's a method being incorrectly called, or called when another should have been used instead. It's not enough to correct the developer. Look at why the error occurred. Perhaps better comments on the method would help (use xml comments to populate intellisense.) Or perhaps the method could be named better. The problem may also be due to poorly architected code in need of refactoring. Bottom line: fix the issue instead of addressing symptoms.

7) If you can't unit test the entire codebase, write tests for the error-prone code. Ideally you want 100% code coverage from your unit tests. In reality this isn't going to happen. Therefore, focus unit tests on problematic and/or complex areas of code. We have lots of code binding to dataset columns. These columns are taken directly from the database. If a column was dropped from the table, you won't receive a compiler error on row["DroppedColumn"] but you will receive a runtime exception. These issues need to be caught by the unit tests, not the QA team.

8) Code generation must be handled very carefully. Most see code generation as an easy way to save time on a project. This is especially true for database access code - basic CRUD operations don't change from one table to the next. Once you have the first generation complete, how you proceed becomes critical. Say you spend a few weeks writing code that uses the autogen code. Someone then decides to make changes to the templates and regen everything. While the intent may have been valid, this regen quite likely broke existing code. At a minimum, your unit tests fail and you can easily find and fix all of the problems. But even then, time must be spent on the fix. If you don't have a decent set of unit tests - be prepared for the increase in tickets from QA. Unless your autogen code is truly separate from the rest of the project, it's probably better in the long run to gen once and modify by hand after that.

Hidden Desktops and NUnitForms

2007-09-24T09:10:00.000-05:00

In my last post I noted a problem working with NUnitForms. I was unable to get the hidden desktop to work with a [SetUp] method. After digging through the source code, I have my solution.

The code that sets up the hidden desktop is in the method init(). This method is marked with the [SetUp] attribute. When I created my own method with this attribute, init() was no longer being called. Thus, no hidden desktop.

The solution is to override the Setup() method provided in NUnitFormsTest, but to not mark it with the [SetUp] attribute. The last thing init() does before exiting is make a call to Setup(). The TearDown attribute and method have a similar implementation.

When the documentation seems to be lacking, it's always nice to have the source code.

WinForms testing using NUnitForms

2007-09-21T10:25:00.000-05:00

I've been spending a lot of time lately coding screens for a WinForms application. Although I've written unit tests for the server components, the client side is somewhat lacking. Each time I change a screen I have to manually test those changes and verify I didn't break anything. In an attempt at automating the process, I've started looking at NUnitForms, an extension to NUnit.

Setup

1) Install NUnitForms
2) Create a project for your NUnit tests. Configure NUnit as normal.
3) Add references to your application project, NUnitForms, System.Windows.Forms, and any third-party controls you use on your application's forms.
4) In the test fixtures, add 'using NUnit.Extensions.Forms'

Basic forms testing

Let's say my application under test (AUT) contains a form, Form1. The first step is to create and display an instance of that form


    Form1 testForm = new Form1();
    testForm.Show();

Say the form has a button - btnOne. Pressing the button programatically looks like this


    ButtonTester btnOneTester = new ButtonTester("btnOne");
    btnOneTester.Click();

Upon clicking this button, a label was updated with the everyone's favorite power tool. To verify


    LabelTester labelOneTester = new LabelTester("labelOne");
    Assert.AreEqual("Chainsaw", labelOneTester.Text, "Label text doesn't match expected");

Though it's not required, it's probably a good idea to close the form instead of letting it fall out of scope


    testForm.Close();

Using the hidden desktop

Running these tests on your local machine doesn't pose any issues. If you run them on a build server, however, you'll likely find that they fail - there's no window for the forms to be displayed in. Fortunately, you can send them to a hidden desktop.

To do so, your test fixture must inherit from NUnitFormTest. Then, add the following property to the class


    public override bool UseHidden
    {
        get { return true; }
    }

One warning - In most of my test fixtures, I tend to put common code in a [Setup] method. I'm finding that when I have this defined, forms are not being sent to the hidden desktop. I've not spent much time on it, so I'm not sure if it's something I'm doing wrong, or if it's a bug in the tool. I'll post more info if/when I figure it out.

Silverlight preparation

2007-09-16T16:12:00.000-05:00

A friend recently decided to start a monthly Hack Day for a small group of colleagues. Given that it's often difficult to motivate oneself to study new technology, the idea is to gather like-minded slackers and force each other to do a little research.

After some discussion, we decided on Silverlight as the first topic. Here's what I did in preparation:

1) Downloaded a VPC image of Orcas (aka VS2008.) You have to download a base image along with the Orcas image - nearly 14GB total.

2) Installed various 1.0 and 1.1 packages:

Silverlight 1.0 Runtime
Silverlight 1.0 SDK
Silverlight 1.1 Alpha Refresh
Silverlight Tools for VS2008
Expression Blend 2 August Preview

3) Watched the Getting Started video and a few Blend tutorials

Uncompressed images and file sizes

2007-09-16T14:22:00.000-05:00

Scanning paper documents can be a useful way to transfer and store data. This of course assumes you are scanning bitonal, with some form of image compression. If you were to scan in 24-bit color with no compression, you'd find the output less than useful.

To see this, let's start with a 1 inch square, at 10 dots per inch (dpi.) The total number of dots (pixels) is 10x10, or 100. If we create a larger square, say 5 inches on each side, we now have 25 square inches. At 10dpi, that's 2500 pixels (100 dots per square x 25 squares.) If we scanned a normal sheet of paper (8.5x11) we have a total of 93500 pixels.

Going back to the 1 inch square, say we double the dpi to 20. What does that do to the pixel count? You might initially say it doubles. If you calculate it, however, you find that you quadrupled the number (20x20 = 400.)

The total number of pixels can be found using the formula:


 (horizontal dpi * image width in inches) * (vertical dpi * image height in inches) = total pixels

A normal sheet of paper, scanned at 100dpi


 (100 * 8.5) * (100 * 11) = 935,000 pixels

The other item to consider is the bit depth of the image. For a bitonal image, each pixel is represented by 1 bit (black or white.) Color images, such as photos, are saved with RGB values for each pixel. This typically requires one byte per color, or three bytes per pixel

To calculate the total number of bytes per image:


 total pixels * bytes per pixel = total bytes

A normal sheet of paper, again at 100dpi, scanned in 1 bit-per-pixel (bpp)


 935000 * 0.125 = 116,875 bytes

That same page, scanned in 24bpp


 935000 * 3 = 2,805,000 bytes (~2.5MB)

As you can see, scanning in full color without compression creates much larger images. Again with 24bit color, here are some common scanner dpi's with their resulting image sizes (in bytes.)


 200 dpi = (200 * 8.5) * (200 * 11) * 3 = 11,220,000

 300 dpi = (300 * 8.5) * (300 * 11) * 3 = 25,245,000

 600 dpi = (600 * 8.5) * (600 * 11) * 3 = 100,980,000

Upgrading from NUnit 2.2 to 2.4

2007-09-04T14:49:00.000-05:00

Until recently, I was running NUnit 2.2.9 on both my work and home computers. This weekend I decided to upgrade my home computer to version 2.4.3. The quick and painless process went as follows:

1) Uninstall v2.2.9
2) Install v2.4.3
3) Open an existing project containing unit tests
4) Updating the references to point to the new assemblies
5) Compile and run...

Well, it all worked except for that last step. At one point, I seem to recall NUnit requiring you to reference nunit.core. Whatever that reason, it's no longer a requirement, and was the cause of the build failure. After removing the reference, everything ran as before.

Constraint-based assertions

One of the most noticeable changes in version 2.4 was the inclusion of constraint-based assertions, similar to some of the mock frameworks available. Previously, you might write assertions like:

Assert.IsTrue(age < 21);
Assert.AreEqual(9, age);

Using constraints, you can now write:

Assert.That(age, Is.LessThan(21));
Assert.That(age, Is.EqualTo(9));

Also, if your test fixture is derived from AssertionHelper, you can shorten the previous lines to:

Expect(age, LessThan(21));
Expect(age, EqualTo(9));

Note: you will need to add using statements for NUnit.Framework.Constraints and NUnit.Framework.SyntaxHelpers. For more examples, including comparisons to the older Assert methods, look for AssertSyntaxTests.cs under the NUnit install directory.

Custom Code Snippets

2007-08-16T09:19:00.000-05:00

I'm not exactly sure when snippets were added to VisualStudio. I'm also not sure why I neglected them this long. I guess I just wasn't one of the Cool Kids. Hopefully I can make amends.

In case you are unfamiliar with snippets, this is the feature that lets you type 'prop' inside a class definition, press 'Tab' twice, and end up with a complete property definition. Even better, it highlights the items to modify, and you can easily Tab between them as you edit.

This is cool. Knowing this is there and using the built-in snippets, however, doesn't make one cool. True coolness occurs when one creates one's own. My journey began with an existing .snippet file. The path to these can be found in the Code Snippet Manager (under the Tools menu.) A few changes and I had the following:


<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>test</Title>
      <Shortcut>test</Shortcut>
      <Description>Code snippet for NUnit test</Description>
      <Author>Pedro</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>testName</ID>
          <ToolTip>Test name</ToolTip>
          <Default>myUnitTest</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[[Test]
    public void $testName$()
    {            
        Assert.Fail("TODO: Implement test");$end$
    }]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

For those following along at home, save the above as a .snippet file. This can either be placed with the existing snippets, or in the "My Code Snippets" folder buried under "My Documents." Once saved, the Snippet Manager should list the new file.

To try it out, open up a .cs file containing unit tests. In a blank area between existing tests, type 'test' and press 'Tab' twice. Assuming I didn't screw up the above xml, you should now have the start of a new unit test.

Compiler warnings are a Bad Thing

2007-07-25T12:39:00.000-05:00

Most projects I've worked on contained a sizeable number of compiler warnings. These are usually ignored by developers as being unimportant. So there are a few (dozen) variables defined that are never used - so what? Duplicate 'using' statements - that can't hurt anything...

It's true that some warnings are mostly harmless. The problem is that these warnings often hide other, more important ones. A few serious ones that come to mind:

- Unreachable code. Perhaps there's a return statement halfway through a function. Or a conditional that will always evaluate true (or false.) These often have unintended side effects.

- A variable is never assigned to, and will always have a default value. You've created a variable, foo, that you're using in your code, perhaps in a method call or conditional. The problem is, you never set foo to anything. It's possible the variable should be removed or replaced with a constant. But it's also possible you forgot to retrieve or calculate something.

- A class member hides an inherited member. Maybe you intended to replace it with your own. In that case, use 'new' to explicitly document the desired effect. If hiding was unintentional, you're better off renaming the member. Otherwise, you may later decide you need that hidden item. At which point you end up with a bit of code rework.

Single responsibility builds

2007-07-24T08:35:00.000-05:00

When I joined my current project, the CI build server (CC.Net) was already in place. For the most part, things were in working order. One item I took exception to was the fact that every build copied files to the development server. The idea being that a developer can run tests to verify that all of the pieces are working correctly. For most of the team, however, this is instead used as a convenient way to code the UI without running the services locally. This makes sense.

The problem, however, comes in when a significant change is made to that code (as in the recent data access changes.) Much of the code still has bugs to work out, despite the fact that the code compiles. The way the build is set up, the copies to the server happen after the compile, regardless of the unit test results. The end result is that after the change, developers could no longer test against the server's build.

Ideally, the continuous build process would not touch the dev server files. Instead, a separate build is created to copy the files on demand (using a Force Build in CC.Net.) When the build is in a faulty state, UI developers can continue working off a known-good base, while others can iron out the bugs in the server code. Another option would be to fail the build if any unit tests fail, so the file copies aren't carried out. Of course, this assumes the tests normally pass.

Always address failing unit tests

2007-07-23T17:22:00.001-05:00

I cannot stress enough the value of unit tests. Whether adding new features or refactoring existing code, you want some validation that you haven't broken existing functionality. Unit tests are usually the fastest way to accomplish this.

This is why it annoys me when unit tests are left in a failing state. In some cases, the tests are invalid and need to be removed. In other cases, they need to be updated to match code changes. Regardless of why a test now fails, it needs to be corrected.

On a project I'm currently involved in, there was a significant rework of data access code. As you can imagine, this introduced a number of bugs, many of which were caught by now-failing unit tests. This is a good thing - that's what the unit tests are for. The problem is that the 50 newly-failing unit tests are mixed in with the 40 already-failing unit tests. We need the new failures fixed quickly, but sorting these from the "junk" unit tests will take time.

Debugging with Exception Breakpoints

2007-07-17T14:39:00.000-05:00

How many times has this happened to you? You're working on code that's not quite functioning correctly. You suspect there's an exception being thrown somewhere, but it's being caught and ignored. Maybe this was intentional, or maybe it was poorly written code. Either way, you need to locate the problem. Visual Studio 2005 has a handy little tool to help - Exception Breakpoints.

Say you have code that looks like this:


    try
    {
        int a = 2;
        int b = 0;
        int c = a / b;  // does not compute
    }
    catch
    {
        // Do nothing
    }

If you were to run this code, you'd never know that there was a problem (well, not until you tried to use the value of 'c' elsewhere.) What we want to do is have the debugger break as soon as an exception is thrown. To do this, open the Exceptions dialog, either through the menu (Debug > Exceptions) or the keyboard shortcut (Ctrl+D followed by E).

Under the Thrown column, check the box next to the Common Language Runtime Exceptions. Now, when an exception is thrown, VS immediately breaks at the offending line of code. One word of warning - Depending on the size of the code, you may find far more exceptions being thrown than you had expected.

Notes On Unit Testing

2007-06-29T08:25:00.000-05:00

Lately, I seem to be spending a lot of time writing and updating unit tests. Along the way, I've made a number of observations. The syntax I'm using is taken from NUnit, but the ideas apply to any unit test framework.

1) If you choose to Ignore a unit test, note why it's being ignored and optionally how it is to be addressed. In NUnit, the attribute looks like this:

 [Ignore("We can't run this test until the hardware is in place")]

Not only is it easier for a dev to figure out later, but it will show up in the build report, making it easy to see the reason without opening up the code.

2) Similarly, use comments in all Assert statements noting the reason for the failure. Again the NUnit syntax

 Assert.AreEqual(expectedAge, actualAge, "Actual age doesn't match expected");

Without this, the NUnit report tells you that 12 didn't match 45, but it doesn't tell you whether you were comparing age or IQ.

3) Never copy/paste code. We all follow this rule in production code, but it is often ignored when writing unit tests. If every test requires a login before doing anything useful, move the login code to a separate method and mark it with a SetUp attribute. If some tests need to fail login, leave off the Setup attribute, but call the method from those unit tests that need it. Note also that you can use Asserts in these methods, so you can still verify proper execution within the methods.

4) Use constants whenever appropriate. If every unit test accesses the same server, move the server name to a string constant. This way, when you later shift to a new test box, you only replace one string.

5) Use a TearDown method to clean up after a test. Largely, this is to reduce the copy/paste of code (see item #3.) This also has to do with not using "try/finally" blocks. It is true that a failed Assert statement is simply throwing an exception. And technically, you could do code cleanup inside a finally block. But this isn't a clean solution (which is why the TearDown attribute exists.) One note: you may have to do some checking within the method. You wouldn't want to dispose a null object.

6) Never hard-code expected values from a database. I've seen numerous unit tests similar to:

 Assert.AreEqual(14, user.ID);

Primary keys are particularly problematic, but any field could cause issues, especially if users (or other unit tests) update values in the table.

One approach is to pull data using some other means. Perhaps by using inline SQL. Perhaps there's another stored proc or service that returns the same info. Either method means the tests don't need to be updated simply because the data changes.

A second approach is to use mock objects and avoid real data altogether. Assuming you've coded to an interface, you can use a tool like NMock or Rhino.Mocks to simulate data retrieval.

7) Test for exception cases using the ExpectedException attribute. There's no need to write a try/catch block, just to verify that a particular exception was thrown. ExpectedException can handle that for you, saving time writing code. One argument against it is that you can only test one exception case per test. You could instead have multiple try/catch tests within a single unit test. The problem here is that NUnit logs one error per test. If you have multiple errors, only one will be logged. You won't notice the other issues until the first has been addressed.

And Most Importantly:

8) Fix broken unit tests (Keep the unit tests current.) I've seen instances where unit tests were written to verify current behavior, but were then ignored as the code was modified. A large portion of a unit test's value comes from its ability to monitor code, flagging errors as soon as they are introduced.

Stopping a COM+ Application Via the Command Line

2007-06-21T12:27:00.000-05:00

I'm currently working on a project requiring multiple steps to deploy correctly. Being the efficient (aka lazy) developer that I am, I decided to automate some of the process. One step calls for stopping a COM+ application. I'm assuming there's a command line utility to handle this, but I've not yet found it. I tried consulting a friendly guru, but that didn't help. So, I was forced to write the VBScript below.

To use, create a new file, StopComApp.vbs, and add the following:

 dim objCatalog
 set objCatalog = CreateObject("COMAdmin.COMAdminCatalog")

 set args = WScript.Arguments
 serviceName = args.Item(0)

 objCatalog.ShutDownApplication serviceName

To use, run the following from the command prompt (or batch file):

 wscript StopComApp.vbs <AppName>

A Useful Way To Launch WinDiff

2007-06-10T13:30:00.000-05:00

A co-worker recently expressed his annoyance that certain tools installed with Visual Studio didn't have Start menu shortcuts. One in particular was WinDiff. In my experience, however, starting WinDiff by itself was never very useful. Once it was running you still had to browse to the files (or folders) you wanted to compare. I prefer selecting two items, right-clicking, and choosing WinDiff from the menu.

To set this up, create a new file, windiff.bat, with the following:

 "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\WinDiff.exe" %1 %2

Save the file to C:\Documents and Settings\<username>\SendTo

To use, select two files in the same folder. Right-click and choose Send To > windiff.bat. This can also be used to diff the contents of two folders.

Pseudo-changesets In SourceSafe

2007-06-04T13:22:00.000-05:00

Let's say you make a code change that spans multiple files across several projects. When the change is complete, you need to check in all of the files at the same time. Otherwise, you end up with a broken build. Most source-control systems include the concept of a changeset. As you check out files, they are grouped in a specified set. After the modifications have been made and tested, you check in the changeset as opposed to the individual files. The bad news: SourceSafe doesn't include changesets. The good news: you can work around the limitation.

I previously added the MSBuild.Community.Tasks code to SourceSafe. Let's say I modified code within the XmlQuery task. This also required changing the unit tests. To see all of the relevant checkouts, select the folder common to both projects ('Source' in this case.)

From the menu, choose View > Search > Status Search. In the "Search for Status" dialog, select the options to display files checked out to you, in current project and all subprojects. Click OK.

The search results will look similar to this

Select the necessary files, right-click and choose Check In from the menu. Assuming you selected the correct files, the code should be updated without breaking the build.

VS2005 Item Templates

2007-05-22T13:38:00.002-05:00

I've been spending a lot of time lately coding unit tests. If I were writing tests for a class named Chainsaw, I would start with a blank class file, and modify til it looks something like this:

using System;

using System.Collections.Generic;

using System.Text;

using NUnit.Framework;

using Pedro.PowerTools;

namespace Pedro.PowerTools.UnitTests

    [TestFixture]

    public class ChainsawUnitTests

        ChainsawAdapter myAdapter;

        [TestFixtureSetUp]

        public void FixtureSetUp()

            myAdapter = new ChainsawAdapter();

If you were to compare all of the TestFixtures in the assembly, you would find:

For the most part, I have the same 'using' statements in each
They all have the same namespace
The class name for each TestFixture is the class to test, followed by "UnitTests"
The data adapter name is the class to test, followed by "Adapter"

*Note - Yes, I'm testing several layers at once. Call it efficient. Call it lazy. It's simply my preference.

Though this isn't difficult to create by hand, there's an easier way - Item Templates. What I want is a way to right-click on my Project, choose Add > New Item, pick "MyUnitTests" from the list, and have it magically create the basic code. Turns out it's quite simple.

Start by placing the above code in a .cs file. Choose File > Export Template... from the menu. In the Choose Template Type screen, select "Item template" and the project where the .cs file exists.

Click Next. In the Select Item To Export screen, check the box beside the .cs file (ChainsawUnitTests.cs in my case.)

Click Next. Under Select Item References, check the box for nunit.framework. Ignore the warning.

Click Next. On the Select Template Options screen, enter the Template name and description. Make sure the box to "Display an explorer window..." is checked, and click Finish.

Once the template is generated, it will be placed in a .zip with the name of the template (for me, this is MyUnitTests.zip.) This is a decent start, but we need to modify a few things.

Open the .zip, and you should see the following files:

_TemplateIcon.ico
ChainsawUnitTests.cs
MyTemplate.vstemplate

Open MyTemplate.vstemplate. Near the end of the file, you should see the following <ProjectItem>

<ProjectItem SubType="Code" TargetFileName="$fileinputname$.cs" ReplaceParameters="true">ChainsawUnitTests.cs</ProjectItem>

In VS2005, when you choose to create a new item for a project, it asks for a filename. This filename, minus the extension, is placed in $fileinputname$. For this template, however, I want to type in the class to test, and have it generate a filename using the classname, followed by "UnitTests.cs". So let's change the line to

<ProjectItem SubType="Code" TargetFileName="$fileinputname$UnitTests.cs" ReplaceParameters="true">ChainsawUnitTests.cs</ProjectItem>

Save the file, and let's open ChainsawUnitTests.cs. It looks nearly identical to the original

namespace $rootnamespace$

    [TestFixture]

    public class $safeitemname$

        ChainsawAdapter myAdapter;

        [TestFixtureSetUp]

        public void FixtureSetUp()

            myAdapter = new ChainsawAdapter();

In fact, the only changes made were to the namespace and classname. Earlier, I mentioned wanting to type in the class to be tested, as opposed to the unit test class, when adding an item through the wizard. This is because I want to replace "Chainsaw" in each instance of "ChainsawAdapter" with the class I'm testing. As you may have already guessed, this comes from $fileinputname$. Two replacements and we have the following:

using System;

using System.Collections.Generic;

using System.Text;

using NUnit.Framework;

using Pedro.PowerTools;

namespace $rootnamespace$

    [TestFixture]

    public class $safeitemname$

        $fileinputname$Adapter myAdapter;

        [TestFixtureSetUp]

        public void FixtureSetUp()

            myAdapter = new $fileinputname$Adapter();

Save the changes and re-zip the files. Drop the .zip in your custom ItemTemplates folder (the location can be found and/or modified in the VS Options dialog, under "Projects and Solutions" > "General." Having done all that, go back to the test project in VS. Right-click on the project and choose Add > New Item. In the Templates dialog, you should see your new template near the bottom of the dialog. Enter "DrillPress.cs" into the Name textbox and click Add.

Assuming all went well, VS should generate DrillPressUnitTests.cs with the following content:

using System;

using System.Collections.Generic;

using System.Text;

using NUnit.Framework;

namespace test1

    [TestFixture]

    public class DrillPressUnitTests

        DrillPressAdapter myAdapter;

        [TestFixtureSetUp]

        public void FixtureSetUp()

            myAdapter = new DrillPressAdapter();

Reducing the size of ccnet.config

2007-05-18T08:41:00.001-05:00

[Update 5/19/09: The latest version of CCNet makes this much easier by using a Configuration Preprocessor. I have a short writeup here.]

My demo setup only contains two projects, and there are already a few items that have been duplicated. Items such as paths to SourceSafe and MSBuild executables. As you add more projects, you find yourself copying and pasting lots of info. This isn't recommended when writing code, so why should a config be any different?

Let's take a look at the sourcecontrol blocks. First, my still-empty custom tasks project


    <sourcecontrol type="vss" autoGetSource="true">
        <ssdir>c:\vss</ssdir>
        <executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>
        <project>$/MSBuild.Chainsaw.Tasks</project>
        <workingDirectory>MSBuild.Chainsaw.Tasks</workingDirectory>
    </sourcecontrol>

Then the MSBuild Community Tasks


    <sourcecontrol type="vss" autoGetSource="true">
        <ssdir>c:\vss</ssdir>
        <executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>
        <project>$/MSBuild.Community.Tasks</project>
        <workingDirectory>MSBuild.Community.Tasks</workingDirectory>
    </sourcecontrol>

Both <ssdir> and <executable> are identical. To simplify things, add the following to the top of the config (above the opening <cruisecontrol>)


<!DOCTYPE cruisecontrol [
    <!ENTITY ssCommon 
        "
            <ssdir>c:\vss</ssdir>
            <executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>

        ">
]>

Now, those sections can be replaced with "&ssCommon;", like so


    <sourcecontrol type="vss" autoGetSource="true">
        &ssCommon;
        <project>$/MSBuild.Chainsaw.Tasks</project>
        <workingDirectory>MSBuild.Chainsaw.Tasks</workingDirectory>
    </sourcecontrol>

Adding FxCop to the build

2007-05-18T08:29:00.000-05:00

Most (though certainly not all) developers agree that code reviews are a useful step in the development process. I won't go into specific benefits, as there are numerous writings on the subject.

One of the downsides, however, is that code reviews take time. In fact, you could spend more time reviewing the code than you did writing it. This is where FxCop can help. Though it won't catch problems with things like business rules, it does flag various issues related to performance, security, and code consistency/maintainability. By adding it to the build, we get a decent code review with every checkin.

For this demo, I downloaded the source for the MSBuild Community Tasks. Dropping this into SourceSafe, I set up a new project in CruiseControl.Net.


    <project name="MSBuild.Community.Tasks">
        <sourcecontrol type="vss" autoGetSource="true">
            <ssdir>c:\vss</ssdir>
            <executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>
            <project>$/MSBuild.Community.Tasks</project>
            <workingDirectory>MSBuild.Community.Tasks</workingDirectory>
        </sourcecontrol>
        <tasks>
            <msbuild>
                <executable>c:\winnt\Microsoft.Net\Framework\v2.0.50727\msbuild.exe</executable>
                <projectFile>MSBuild.Community.Tasks\Source\MSBuild.Community.Tasks.sln</projectFile>
                <buildArgs>/noconsolelogger </buildArgs>
                <logger>c:\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
            </msbuild>
        </tasks>
        <publishers>
            <statistics/>
            <xmllogger/>
        </publishers>
    </project>

To add FxCop, we first need to create a project file. Start FxCop. From the menu, choose File > Save Project. Out of laziness, I saved the file as c:\DefaultRules.FxCop. Now to update the build file. Below the <msbuild> section, add the following


    <exec>
        <executable>C:\Program Files\Microsoft FxCop 1.35\FxCopCmd.exe</executable>
        <buildArgs>/project:"C:\DefaultRules.FxCop" /fo /q /searchgac /file:"%CCNetWorkingDirectory%\MSBuild.Community.Tasks\Source\MSBuild.Community.Tasks\bin\Debug\MSBuild.Community.Tasks.dll" /out:FxCopLog.xml</buildArgs>
    </exec>

Within the <publishers> section, add


    <merge>
        <files>
            <file>FxCopLog.xml</file>
        </files>
    </merge>

Save these changes and force a build - which fails. Looking at the project report, it looks like everything should have worked. We even have FxCop information on the page. The Build Log, however, notes the missing dependency Microsoft.VisualStuido.SourceSafe.Interop. The assembly isn't being copied to the build output folder.

To fix, open the .sln in VisualStudio. Under the project's References, select the missing interop and set the Copy Local property to True. Checkin the modified project and you should see a successful build.

Now we have FxCop info displaying on the Build Report. We also have a detailed FxCop Report we can access from the Dashboard's menu. Which is all well and good, but the reports aren't the most useful.

Fortunately, you can download alternative stylesheets from the Thoughtworks site. Unzip fxcop-summary.xsl and FxCopReport.xsl, and place in \webdashboard\xsl\ under the cc.net install directory. Open FxCopReport.xsl in your favorite xml editor. Replace all instances of

src="images/

with

src="/ccnet/images/

With the new reports in place, reload the dashboard. If all goes as planned, you should see slightly improved FxCop reports. Note these still aren't perfect, and there are likely others available on the web.

Continuous Integration = Consistently Compileable Code

2007-05-07T08:23:00.000-05:00

*Note: This is a continuation of my previous post

"Now that we have basic SS usage defined, where does CC.Net fit into the picture?" Simple - it's what makes sure the code is in a usable state at all times.

Let's say you've finished creating the xml logger and checked everything in. But say you forget to check in one file. Everything builds on your machine, so you don't see the problem. You're pulled from the project and another dev comes in later to continue. Only, when he gets latest and attempts a compile, he receives a number of build errors. Now he wastes time tracking down the cause of the problem - a missing or outdated file - and who might have that file. Maybe you have the file, and he's wasted fifteen minutes. But say you no longer have that file. Now your colleague wasted that time, only to find out someone will have to recreate the work.

Say instead you are working on code at the same time as another dev. His job is to create the data and business layers, while you focus on the front end. Somewhere during development, your colleague decides to modify a few method signatures. Methods that you happen to be using. And your colleague fails to warn you. At some point you'll get latest, only to find that you can no longer compile your code. It's likely that both of you must stop what you are working on and get the build back into a good state. If there are only two of you, it might take twenty minutes. As the number of devs on a project increases, the time required to restabilize the code likewise increases.

I previously worked on a project that had over a dozen developers. Due somewhat to poor architecture, a break anywhere caused problems for the entire team. The choices were to get latest and spend the morning stabilizing the build, or using outdated code, which meant integration later became even more difficult.

Fortunately, these problems are easy to address using CruiseControl.Net. Its job is to monitor the source code repository for any changes. As soon as a change is made, CC.Net gets latest and rebuilds the code. If the compile fails, everyone on the team is immediately (within a few minutes anyway) notified of the failure. The dev who checked in the broken code can address the problem, and other team members know not to get latest for the moment.

Regarding a broken build - if you aren't working on a fix, stay away from the repository. Getting latest means the code on your box will no longer compile. Checking in code may make things worse. It's best to fix one build break before possibly introducing another.

One more thing - if you break the build, fixing it should be your top priority. If you check in code at the end of the day, hang around to verify the build is still good. If you're in a hurry and can't wait for the build, don't check in the code. You're more likely to forget something in your haste, increasing the odds of a break.

Source Code Control 101

2007-05-03T08:17:00.000-05:00

At work, we're moving toward a more standardized development process. Part of that standardization is on the usage of SourceSafe for source code control, and CruiseControl.Net for continuous integration (CI.) The developers on the team come from a variety of backgrounds, and have different levels of experience with CI. As the resident Build Guy, I've spent the most time with the tools and decided to lay out my thoughts on the process.

*Note that these are not the only tools available, and with SourceSafe in particular there are certainly better options. These are simply the tools we are working with.

*Note also that I intended to cover both SS and CC.Net in a single post. It ended up a bit longer than expected, so I'm splitting it into two entries. This post is limited to source code control. The next will dig into continuous integration.

SourceSafe as version control

SourceSafe is not merely a way to back up code in case of hard drive failure. It is a way to revision your code. It allows you to define checkpoints in completed work. It provides an easy way to compare changes and roll back work if you find yourself going down the wrong path.

For example, let's say you're updating a desktop application. The current app generates a text file as output. The goals for the next release are to enhance the logging and to generate xml instead of plain text. To start, you decide to replace the existing log with xml. Looking at the code, you realize the log messages are scattered throughout the entire app. Unless each message is to be a self-contained element, this makes it difficult to generate well-formed xml.

So you begin by creating a custom logger class. This lets you track where in the xml tree you are, and ensures the output is well-formed. After you've finished testing the logger, it's time to replace all of the old logging code with calls to the new class. Right?

Not just yet. Now that you have working code it needs to be checked into SourceSafe. "It doesn't do anything yet," you say? True. However, even though the class isn't used, it's still a functioning piece of code. If you have to switch projects now, you know you can come back later and pick up with a working app.

"What if you need to make a bug fix and release to production?" The code isn't being used, remember? So there shouldn't be an issue.

With the logger checked into SourceSafe, it's time to replace the existing logging code. At the start, everything seems fine. But several hours into the process, you realize something. It appears there's a bit of rarely-used code that logs info in a non-trivial, non-standard way. No problem - you can update the xml logger to deal with the new info. A few changes, which you of course check into SS, and you're back to replacing code. But shortly thereafter, for whatever reason, you realize the logger changes shouldn't have been made. Now what?

Fortunately, the previous revision exists in SourceSafe. It's easy to roll back the code and continue with your work. But say you hadn't checked in the changes? Instead, you would have had to manually modify the code until you were back to the point you were before. If you've ever tried this, you know it's not often a trivial matter. It certainly takes longer than the minute or two required for a SourceSafe rollback.

SourceSafe allows collaboration

Most software projects involve several team members contributing code. This requires some means of getting updated code to the other developers. It may also require a new developer to come in and pick up where another left off.

Going back to the xml logger, say you have the logger code checked in and are pulled off to work on another project. A new developer comes in and is tasked with replacing the old log code. All the new guy has to do is get latest from SS and he can continue right where you left off. Or maybe he comes in at the point where you've added to the logger (just before you realized those changes weren't necessary.) Once the new guy figures out what's going on, it's as easy for him to roll back the code as it would have been for you. There's a clear snapshot of where the code was before the change.

Checkin frequency

So you now see a few benefits of source code control. The next question you may have is "How often do I check in my code?" It depends on what you are doing, but the general answer is "Often." A few times a week is typical, and multiple times a day is entirely possible. The key is to find stopping points throughout the project.

Say you start coding a new multi-tiered application. You begin by writing a few classes in the data layer, making sure you can connect to the database. As soon as you have these compiling and running correctly, check the code in. As you add new classes, check them in. There's no reason to wait until the entire layer is code complete.

Say instead you are working on a desktop application. You begin by placing a few controls on a blank form. Maybe you hook those controls to business logic. Or maybe you prefer to setup the layout before making the code do anything useful. Either way, each piece of logic and each set of controls define a discrete unit of work. Hook up a couple buttons and check the code in. Add logic to traverse the local hard drive, then check the code in. With a bit of practice, you should recognize several good checkin opportunities on any given day. That's not to say you need to check code in this often, but once a day is certainly possible.

One final thought - before checking in the code, make sure it compiles and runs on your box. Checking in code that doesn't compile only hinders development. I'll cover this next time when I introduce continuous integration using CruiseControl.Net.

CC.Net - Project Report Page

2007-04-27T17:19:00.000-05:00

In CC.Net, the Project Report page provides general information for a project.

Most of the items should be straightforward. One thing you may notice is that the "View Statistics" link doesn't work. Clicking the link gives an exception page stating "Object reference not set to an instance of an object." The problem is that the <statistics> publisher wasn't specified. Add the following to ccnet.config, within <project></project>

    <publishers>
        <statistics/>
    </publishers>

Reload the page... "Unexpected exception caught on server." The other pages now fail with the same error. Not exactly the desired results. Digging through the exception details, it appears the Log Publisher is missing. Yet it was there a minute ago?

It turns out a default publisher is used if one isn't specified. You can see this by removing the <publishers> section and clicking Project Configuration on the left. This page gives the project's entire XML listing, both the entries in ccnet.config and any defaults you don't override. A useful addition.

Anyway, the publisher error is a simple fix:

    <publishers>
        <statistics/>
        <xmllogger/>
    </publishers>

The pages again load. On top of that, we now have statistics. Or, will, as soon as we run another build. Force a build, and you should see basic stats for the project.

Nothing fancy, but it's a start.

One more useful feature is the External Links item. With this, you can easily add links to other resources - project documentation, bug server, etc. Again, this is added within <project></project>

    <externalLinks>
        <externalLink name="Project Documentation" url="\\fileserver\project1\project.doc" />
    </externalLinks>

CruiseControl.Net 101 - Projects

2007-04-25T08:45:00.000-05:00

Last time, we installed CC.Net and created a blank project. This time, we'll have that project actually *do* something.

The first thing we need is something in source control to point to. I happen to have a SourceSafe database at c:\vss, so I'll use that. In SourceSafe (SS), I've created a new project, MSBuild.Chainsaw.Tasks. There aren't any files in there currently, but we'll get to that shortly. For now, let's add the following to ccnet.config, between the <project></project> tags:


        <sourcecontrol type="vss" autoGetSource="true">
            <ssdir>c:\vss</ssdir>
            <executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>
            <project>$/MSBuild.Chainsaw.Tasks</project>
            <workingDirectory>MSBuild.Chainsaw.Tasks</workingDirectory>
        </sourcecontrol>

This tells CC.Net to monitor the project $/MSBuild.Chainsaw.Tasks and any sub-projects. If files are added or checked into the project, CC.Net will kick off a build. At this point, we should test the updated project.

Start Visual Studio 2005 (VS2005) and create a new C# Windows Class Library. Give it a name of MSBuild.Chainsaw.Tasks. Do not check the boxes to "Create directory for solution" or "Add to Source Control." The former is unnecessary, the later would ruin my cleverly devised plan. Once the project is generated, save the files and close VS2005. Nope, we're not actually writing code. We'll have to save that for another time.

Back in SS, drag the solution file into $/MSBuild.Chainsaw.Tasks. Open the CCTray app. You should see the Last Build Label increment (CC.Net looks for changes once a minute, so you might have to wait a few seconds.) The build still shows green - we haven't specified any tasks to perform. Open Windows Explorer and browse to your CC.Net install folder. Expand \server\Project 1\WorkingDirectory\MSBuild.Chainsaw.Tasks. You should see the .sln file, meaning it's at least pulling the source correctly.

To compile with MSBuild, there is one more piece we need. By default, msbuild sends text output to the console. CC.Net requires XML output from all of the build tasks. You'll need to download ThoughtWorks.CruiseControl.MSBuild.dll. Out of shear laziness, I place this file in the root of the c: drive.

With that out of the way, let's go back to ccnet.config. Add the following to the file:


        <tasks>
            <msbuild>
                <executable>c:\winnt\Microsoft.Net\Framework\v2.0.50727\msbuild.exe</executable>
                <projectFile>MSBuild.Chainsaw.Tasks\MSBuild.Chainsaw.Tasks.sln</projectFile>
                <buildArgs>/noconsolelogger </buildArgs>
                <logger>c:\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
            </msbuild>
        </tasks>

Note: The <executable> tag is necessary if you're running on Windows2000. If you're on WinXP, it isn't required.

Save the config and go back to CCTray. Hmm... Nothing happened. That's of course by design - nothing's changed in SS. To test the config change we need to force a build. This can be done with the Force button in the Dashboard, or by right-clicking the project in CCTray and choosing Force Build.

After the build runs, the CCTray icon will be red. In the Dashboard, the Last Build Status shows "Failure." To look at the details, open Project 1 in the Dashboard. Select the most recent build. The Build Report for this build doesn't tell us much (we'll fix this shortly.) Click "View Build Log" from the menu on the left. This is the raw XML output from the build. If you look in the <msbuild> section, you should see a line that includes 'The project file "MSBuild.Chainsaw.Tasks.csproj" was not found.' Not surprising since we didn't add it to SS yet.

Before we fix this error, let's modify the report to show MSBuild output. In Windows Explorer, browse to \webdashboard in the install folder. Open dashboard.config. Locate the following:


    <buildPlugins>
        <buildReportBuildPlugin>
            <xslFileNames>
                <xslFile>xsl\header.xsl</xslFile>
                <xslFile>xsl\modifications.xsl</xslFile>
                <xslFile>xsl\compile.xsl</xslFile>

Beneath this, add the line:


                <xslFile>xsl\compile-msbuild.xsl</xslFile>

This will format msbuild output within the build report. Note that the ordering of the .xsl files determines the ordering in the report. Also, if there are items you aren't interested in, those lines can be removed from the config.

After you save the config, force another build and verify that you now have two additional sections in the Build Report - Errors and Warnings.

Now to fix the build error. Add the remaining files from the MSBuild.Chainsaw.Tasks project to SS. Having done that, we wait patiently while CC.Net kicks off another build. Assuming all the files were added, the build should complete successfully.

Sorry for the lengthy post. I could have stopped somewhere in the middle, but the one thing I can't stand is a broken build. My co-workers can attest to this.

CruiseControl.Net 101 - Installation

2007-04-20T17:27:00.000-05:00

My plan is to start with few entries covering the basic setup, configuration and usage of CC.Net. This way, if I'm hit by a bus, someone else at work can take over as the BuildGuy. Or they can wipe the machine and turn it into an mp3 server. Their choice.

The server install (v1.2.1) is rather straightforward, though you'll want IIS loaded beforehand. During the install, check the boxes to install as a service, and to create a virtual directory in IIS. Note the service (CruiseControl.NET Server) is set to Manual startup, and eventually needs to be switched to Automatic. While configuring projects, however, you may find it easier to debug running the console.

Once installed, start the console or service and point your browser to http://localhost/ccnet/. If the Dashboard is displayed, good job. Your install went smoother than mine. Because I installed IIS after the .NET framework, I received an error stating "Failed to access IIS metabase." Running "aspnet_regiis -i -enable" took care of the issue.

Now that we have the server running, we need a project. Open ccnet.config - located in "C:\Program Files\CruiseControl.NET\server" on my box. Replace the contents with:

<cruisecontrol>
     <project name="Project 1">
     </project>
</cruisecontrol>

No, it doesn't do anything - I'm not in any hurry. Save the file and go back to the Dashboard. You should now see "Project 1" in the list.

With that in place, install the CC.NET TrayApp. One installed, we want to add Project 1 to the list of monitored projects. In CCTray, go to File > Settings. On the Build Projects tab, click Add. Click Add Server. The Build Server dialog now visible provides three methods of connecting to the server. Either the dashboard or remoting options will work.

Once you've selected a connection method, the Project list now contains the build server and a single project (Project 1.) Select the project and click OK. Click OK to close the settings, and you should now see the status of the project. This will match the info displayed on the Dashboard.

Well, that was fun. Maybe next time we'll have the server do something useful. But I make no promises...