Dec 082014
 

In my last post, I showed a way to generate unit tests for existing code where a pattern exists using .NET’s System.Reflection library. The post showed an executable that would take the paths to a dll and an output file as input parameters where this executable would then tear through the assembly, looking for string properties for which I wanted tests. The exe would generate stub code to ensure that I wouldn’t miss any of the string properties.

I was discussing this with a colleague who suggested that I consider generating a T4 text template within Visual Studio to do this same work.  I had never used the templates before, but have found them to be amazingly simple, yet very useful tools to have in the arsenal.  I was able to take the code from the exe that I described in the last post, incorporate it into a template, and have it generate the same test code in about 5 minutes.

The benefit to using T4 text templates is that they are meta-code that reside within your Visual Studio project.  The cool thing is that the meta code regenerates the output file from the template during builds and after edits to the template.  Because of this close relationship with code in their project, these templates can be used to auto-generate output files that respond to changes in the code.  This can be particularly handy if you are creating schema files, config files, tests, or other forms of output that need to be kept fresh as your code changes.

I took the project that I used in the last post and added the T4 text template.  To do this, I simply added a new Text Template:

AddNewTextTemplate

After adding the template, you can see the template in the Solution Explorer window.  You can also see the generated code file as a child of the text template, as shown here:

TemplateInSolutionExplorer

When you first generate a text template, it puts header information in the .tt file for you that you have to edit.  You’ll notice that code that is to be evaluated is placed inside of <# #> bracketing.  The text within these delimiters will not be shown in the output file, but will contain the code needed to output something useful to the file.

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ assembly name="System.Core" #>
<#@ import namespace="System.Linq" #>
<#@ import namespace="System.Text" #>
<#@ import namespace="System.Collections.Generic" #>
<#@ output extension=".txt" #>

You can see that the default output extension is .txt. I changed that to .cs. You can also see that the template is generated with assembly and import directives. Assembly is like adding a reference to a project and import is analogous to a using directive in a C# file. Since I already knew my dependencies from my prior project, I modified this information to look like this:

<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ output extension=".cs" #>
<#@ assembly name="System"#>
<#@ assembly name="System.Xml"#>
<#@ assembly name="System.Xml.Linq"#>
<#@ import namespace="System" #>
<#@ import namespace="System.Xml.Linq"#>
<#@ import namespace="System.Reflection" #>

This block is code that the template will use when run. It is the list of references (assembly tag) and usings (import tag) that the code I will add later will use.

Next I will add the using statement block that I want my output file to have. This text will not be inside the <# #> delimiters because I actually want to see this code in my output file. Note that this text is not the usings that the template will need to run. Since it is outside of the delimiters, it is seen as simple text to be output:

using System;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

Next, since I was writing a unit test file generator, the namespace and class declaration needed to be added. These were in funky functions in executable in my prior post. These functions added “header” and “footer” information, for lack of better terminology. This was awkward, but here it is quite elegant because I am actually writing this one-time-output text as it will be seen in the output.

namespace MyProject.Tests
{
    [TestClass]
    public class MyTests
    {
    }
}

After this, I extracted the code from the executable I built in the prior post and put it into the template. You’ll notice the <#= stuff #> where I wanted to emit text generated from code into the output file. This is the final text template file:

<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ output extension=".cs" #>
<#@ assembly name="System"#>
<#@ assembly name="System.Xml"#>
<#@ assembly name="System.Xml.Linq"#>
<#@ import namespace="System" #>
<#@ import namespace="System.Xml.Linq"#>
<#@ import namespace="System.Reflection" #>
using System;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace MyProject.Tests
{
	[TestClass]
	public class MyTests
	{
		<#
		var a = Assembly.LoadFrom(@"c:\temp\ProjectToTest\ProjectToTest.dll");
        foreach (var type in a.GetTypes())
        {
            // get all public static properties of MyClass type
            var propertyInfos = type.GetProperties();

            // sort properties by name
            Array.Sort(propertyInfos,
                delegate(PropertyInfo propertyInfo1, PropertyInfo propertyInfo2)
                {
                    return propertyInfo1.Name.CompareTo(propertyInfo2.Name);
                });

            // write property names
            foreach (var propertyInfo in propertyInfos)
            {
                if (propertyInfo.PropertyType == typeof(string))
				{

		#>
[TestMethod]
		public void MyTests_<#=  type.Name.Replace("`", "") #>_<#= propertyInfo.Name #>()
		{
			// Put in code here for your test
		}
		<#
				}
            }
        } 
		#>
	}
}

If you’ll notice, the “[TestMethod]” indention looks a little nutty in the text template file. I found that I had to play a little to get the indention right. Also, you can see that I have hard-coded the path to the dll that I wanted to reflect. This could be made better via a project variable somehow.

After the final updates to the template file, Visual Studio automatically generated this output when I saved the template:

using System;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace MyProject.Tests
{
	[TestClass]
	public class MyTests
	{
		[TestMethod]
		public void MyTests_Class1_String1()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class1_String2()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class1_String3()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class1_String4()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class1_String5()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class1_String6()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String1()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String2()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String3()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String4()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String5()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class2_String6()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String1()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String2()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String3()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String4()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String5()
		{
			// Put in code here for your test
		}
		[TestMethod]
		public void MyTests_Class3_String6()
		{
			// Put in code here for your test
		}
			}
}

If I had some severely repetitious checks to make, I could make this file regenerate and change with every change to my code. This is interesting for unit testing, but really has cool applications in other areas, like schema generation, documentation, etc.

Much thanks to my colleague for pointing T4 text templates out to me! This is another cool tool to keep handy.

Jun 162014
 

If you work with 3rd party .NET libraries, you may find yourself in a situation where you would really, really like to see what is going on “beneath the hood” of that black box, 3rd party assembly you are using.  I have encountered cases where the API documentation wasn’t really clear as to what a method would do with a particular parameter.  I have also had cases where the 3rd party library failed on a call and the cause wasn’t readily discoverable.  For these cases, I have called on a very cool tool, Lutz Roeder’s .NET Reflector.  Unfortunately, that tool has now become a commercial, pay-to-use product of Red Gate Software.  There are several nice additions Red Gate has made to the tool, but for simple decompilation, I recommend the use of the open source, ILSpy tool.

ILSpy is a free, no-frills, .NET decompiler that uses reflection to IL to rebuild code back into C# syntax.  It is a very useful tool and can help with the problems I mentioned before where you really need to see inside assemblies where you don’t have access to the source code.  You can see from this example that I used ILSpy to look into the TryOpen method of the vdDocument class from VectorDraw, a 3rd party control for CAD rendering.  I wondered what was going on with file formats that are not native to VectorDraw (i.e. *.vdml and *.vdcl).

ILSpy Showing the vdDocument.TryOpen Method

ILSpy Showing the vdDocument.Open Method

I drilled into the vdDocument.Open method simply by clicking on the method in the deconstructed code.  That led me to the vdDocument.Open method and the ILSpy seamlessly displayed the code for the method:

ILSpy Showing the vdDocument.TryOpen Method

ILSpy Showing the vdDocument.TryOpen Method

From here, ILSpy shows me the code that it has reconstructed.  I can clearly see the branching around the file types and I can continue to drill down through this code.  I can use this to determine intent for the method or I can use this to see how parameters are used in their code.  This definitely comes in handy when there is some confusion around the use of a particular method.

I highly recommend ILSpy for all your .NET decompilation needs.  It is fast, detailed, and best of all it is free!

Apr 302014
 

Don’t Repeat Yourself, or DRY, is a key principle of software engineering.  Various sites on the web and various courses state this principle as

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”

One of the things this means, practically, is that the abstractions that you use in your code should provide for reuse such that there is never a need to copy code.

Reuse of code can be accomplished by properly designing your objects (abstractions) such that they have a single responsibility.  For example, if you have several objects that communicate with a data layer, you should abstract the data layer away into a data access class that is then injected into the constructor of objects that need to converse with the data layer.  This provides for better data encapsulation and allows for better unit testing as you can create a fake for the data access object.  Another example of how you can reuse code is through the use of base classes that provide functionality that is common to a set of potentially derived classes.

I recently presented a course on best practices for Object Oriented Design at my company and ran across a very cool tool that was mentioned in a Pluralsight course by Steve Smith.  The tool is Atomiq by goldfinch.  It is a completely free tool that they make available (self-admitedly) to drum up business for their static analysis tool, Nitriq.  Atomiq searches your code and finds code duplication and similarities.  It provides statistics and and easy way to navigate to duplications within the code.  It provides a very nifty graphic to show where duplicates are and it even has a command line exe for which a threshold can be set for use with a continuous integration builder (very cool!).

I decided to test drive Atomiq using some old code to which I had access.  I knew this code would give Atomiq a run for its money as this code has been around for a decade and has been touched and tweaked and, well, defiled by many developers.  After letting Atomiq analyze the entire project, this is the wheel graphic that was generated by Atomiq:

Wheel Output From Atomiq For Solution with Lots of Repetition

Wheel Output From Atomiq For Solution with Lots of Repetition – (Class Names Removed to Protect the Innocent)

As I suspected, Atomiq found many sources of repetition in this solution.  Each line crossing this Spirograph looking picture represents an opportunity to refactor this code such that the repetition goes down and the maintainability goes up.

I had another project where I was playing around prototyping a couple ICommand objects for use in ESRI’s ArcMap.  In this project, the two commands were generated using the ArcMap ICommand generation tool in Microsoft Visual Studio.  Because the classes were auto-generated, the same base code was added to each.  For example, this code (along with a few other lines) was auto-generated into both classes:


#region COM Registration Function(s)
[ComRegisterFunction]
[ComVisible(false)]
static void RegisterFunction(Type registerType)
{
    // Required for ArcGIS Component Category Registrar support
    ArcGisCategoryRegistration(registerType);
}

[ComUnregisterFunction]
[ComVisible(false)]
static void UnregisterFunction(Type registerType)
{
    // Required for ArcGIS Component Category Registrar support
    ArcGisCategoryUnregistration(registerType);
}
#endregion

This duplicated code caused Atomiq to (rightly) generate this graph:

Atomiq Output Because of Duplicate Auto-Generated ICommand Template Code

Atomiq Output Because of Duplicate Auto-Generated ICommand Template Code

For this particular duplication, Atomiq found 65 lines that were similar.  Also, Atomiq showed this similarity view, that showed the same code side-by-side:

Atomiq Similarity View Showing ESRI ICommand Boilerplate

Atomiq Similarity View Showing ESRI ICommand Boilerplate

This is one example where Atomiq shows a great place to do some refactoring.  By pulling all of the ESRI ArcMap boilerplate code into a base class, we can move all of this duplicate code to one place and then create derived classes from this base class.  For this example, I just started by refactoring out a part of the similar code, as shown here:


using ESRI.ArcGIS.ADF.BaseClasses

// Base class from which all other ESRI ICommands should be derived for code reuse

[ComVisible(true)]
public abstract class MyBaseCommand : BaseCommand
{
    [ComRegisterFunction]
    [ComVisible(false)]
    static void RegisterFunction(Type registerType)
    {
        // Required for ArcGIS Component Category Registrar support
        ArcGisCategoryRegistration(registerType);
    }

    [ComUnregisterFunction]
    [ComVisible(false)]
    static void UnregisterFunction(Type registerType)
    {
        // Required for ArcGIS Component Category Registrar support
        ArcGisCategoryUnregistration(registerType);
    }

    // Move other common ICommand code here

}

After reanalyzing the code, the 65 similar lines dropped to 55:

After refactoring - Duplicate Lines Dropped from 65 to 55

After refactoring – Duplicate Lines Dropped from 65 to 55

By iterating in this same fashion, Atomiq can help to eliminate duplications and make this code more maintainable.

While there is no silver bullet, Atomiq is a very good (and very free) tool to use in making sure that you write code that complies with the DRY principle.  When coupled with the command line version for a continuous integration builder, this is a great way to improve code quality.

Sep 202013
 

The .NET Framework provides a straight-forward and fairly easy syntax to use for callbacks.  These callbacks can be used for all sorts of messaging within your system.  These messages can signal a UI event, like a button press, or they can be used to send a message to many objects serially (multicasting).

The basis for all of this communication comes from ye olden callback.  The callback is simply a method where a pointer to a function is passed and then that pointer is used to (you guessed it) call back to that function.  This works well and has for years.  However, the problem with this methodology is that it is not type-safe.  That is, the function callback is merely a pointer to a location in memory where the function resides.  There is no guarantee that the function will have the expected signature of the code doing the callback.  This is where delegates come into play in the .NET Framework.

System.Delegate is a type in the .NET Framework Class Library that is used as a type-safe wrapper for a callback.  The delegate allows the CLR to ensure that all calls through the delegate will have the proper parameters.  Further, System.Delegate is extended with the System.MulticastDelegate type to allow for callbacks to multiple clients.

Events are a special type of delegate that provide protection for event calling and for the underlying delegates invocation list.  That is, only the class that defined the class my invoke the event and subscribers are allowed to add/remove only themselves from the invocation list.  Events are commonly used with UI objects, such as buttons, grids, trees, and other controls to callback to the underlying code when the user performs an action.

Defining and using events in the .NET framework is really straight-forward.  This sample shows the 3 steps to create and use a simple event:


using System;
using System.Threading;

namespace SimpleEventsExample
{
    /////////////////////////////////////////////////////////////////////////////////////////////////////////////
    // This is a simple example to demonstrate events. Remember these 3 things when setting up an event:
    // 1. Create a Type derived from EventArgs to pass back information pertaining to the event.
    // 2. Create an event that passes back the EventArgs instance in the object that is to publish the event
    // 3. Subscribe to the event in the objects that are to listen to the event.
    /////////////////////////////////////////////////////////////////////////////////////////////////////////////

    /// 1. Create a Type derived from EventArgs to pass back information pertaining to the event.
    ///
    /// This is a Type derived from EventArgs whose payload is the current time at the time of the
    /// event and the seconds that have transpired since the beginning of the run.
    internal class SecondsCountdownClockExpiredArgs : EventArgs
    {
        internal SecondsCountdownClockExpiredArgs(DateTime currentTime, int secondsEllapsedSinceStart)
        {
            CurrentTime = currentTime;
            SecondsEllapsedSinceStart = secondsEllapsedSinceStart;
        }
        internal DateTime CurrentTime { get; set; }
        internal int SecondsEllapsedSinceStart { set; get; }
    }

    /// 2. Create an event that passes back the EventArgs instance in the object that is to publish the event
    ///
    /// This is the object that will be firing the event. It will allow subscription to the event via
    /// a public event.
    internal class SecondsCountdownClock
    {
        private const int MillisecondsInASecond = 1000;
        private readonly int _timerInterval;
        private int _secondsEllapsedSinceStart;
        private readonly int _seconds;

        // Define a public event to which listeners can sign up for notification
        public event EventHandler&lt;SecondsCountdownClockExpiredArgs&gt; SecondsCountdownClockExpired;

        internal SecondsCountdownClock(int seconds)
        {
            _seconds = seconds;
            _timerInterval = seconds * MillisecondsInASecond;
        }

        // Cheesy countdown timer that wakes up and fires based on the interval entered.
        internal void StartTheCountdown()
        {
            Console.WriteLine("Seconds Countdown Clock set to expire every {0} seconds", _seconds);
            for (; ; )
            {
                Thread.Sleep(_timerInterval);
                IncrementTimer();
            }
        }

        // When the interval has been reached, this function is called. If there are subscribers to the event,
        // create a new event args class, put information in the class, and fire the event.
        private void IncrementTimer()
        {
            _secondsEllapsedSinceStart += _seconds;
            if (SecondsCountdownClockExpired != null) SecondsCountdownClockExpired(this, new SecondsCountdownClockExpiredArgs(DateTime.Now, _secondsEllapsedSinceStart));
        }
    }

    /// 3. Subscribe to the event in the objects that are to listen to the event.
    ///
    /// This observer object will subscribe to the clock event and will output information to the console
    /// about the event.
    internal class ClockObserver
    {
        internal ClockObserver(SecondsCountdownClock secondsCountdownClock)
        {
            // Subscribe to the SecondsCountdownClockExpired event
            secondsCountdownClock.SecondsCountdownClockExpired += secondsCountdownClock_SecondsCountdownClockExpired;
        }

        static void secondsCountdownClock_SecondsCountdownClockExpired(object sender, SecondsCountdownClockExpiredArgs e)
        {
            Console.WriteLine("Current Time: {0:h:mm:ss}        Seconds Ellapsed Since Start: {1}", e.CurrentTime, e.SecondsEllapsedSinceStart);
        }
    }

    /// This program is a test harness that creates the countdown clock and creates and observer to listen to clock events.
    /// After it generates the clock and observer, it kicks things off by starting the clock.
    class Program
    {
        static void Main(string[] args)
        {
            // Create the clock that will publish clock events
            var seconds = Convert.ToInt16(args[0]);
            var theSecondsCountdownClock = new SecondsCountdownClock(seconds);

            // Create the observer that will listen to clock events and pass the clock pointer to its constructor
            new ClockObserver(theSecondsCountdownClock);

            // Kick off the clock
            theSecondsCountdownClock.StartTheCountdown();
        }
    }
}

Here is the output:

Output from the Seconds Countdown Clock - Demonstrating Events

Output from the Seconds Countdown Clock – Demonstrating Events

Although this sample isn’t very complicated, it is interesting to see what is going on under the covers with the Event type.  The Event type is really a special type of Delegate, which can be seen when examining the intermediate language using the ILDASM.exe tool.  A cursory look at the SimpleEventsExample.SecondsCountdownClock type shows the add and remove methods for the event:

ILdasm With Event Add and Remove

ILdasm With Event Add and Remove

Now look at the deconstruction of the add_SecondsCountdownClockExpired into IL:

Intermediate Language Showing Delete Combine

Intermediate Language Showing Delete Combine

You can see from the ILDASM output on line IL_000b that System.Delegate::Combine is the underlying mechanism used for adding to the event listener.  Further, looking at the IL for remove shows the underlying delegate remove.

Could you use a Delegate type for this?  Yes, you could, but the Event type is particularly designed for this sort of work.  It can only be raised in the class in which it was defined and it protects the invocation list (the list in the underlying delegate class) from being modified arbitrarily, which protects your code and makes for more robust software.

Aug 032013
 

As a developer (and a power user), I find myself annoyed at the User Account Control (UAC) in Windows.  It prompts.  It nags.  It mothers.  On my development machine and VMs, in particular, I find that I want to completely disable UAC.  This allows me to run scripts and utilities in batch files and in post-build steps without interruption and grief.   To accomplish this, I run the following .reg file to directly update the UAC keys in the Windows registry:


Windows Registry Editor Version 5.00

; Disable User Account Control
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLUA"=dword:00000000
"ConsentPromptBehaviorAdmin"=dword:00000002
"ConsentPromptBehaviorUser"=dword:00000001

; Permanently disable User Account Control
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\luafv]
"Start"=dword:00000004

All you have to do is put this into a text document named admin.reg, run it, and allow the modifications to the registry.  You will then have to restart.  When you have gotten this right, you can see right at the top of Visual Studio in the title that you are in Administrator mode, which give you unfettered access to all manner of goodness:

VSAdministratorMode

One other trick that you can do (if your IT shop changes the settings back by default – and they wouldn’t do that if they knew this was a development box, right?) is put this in your machine startup.  That way, you always reset after you reboot.

We could debate the finer points of UAC here and make all sorts of arguments as to why you should leave it on.  You should only use this reg file if you really know what you are doing and really need to have open access to your Windows GAC and registry.

Jul 302013
 

If you have worked with Microsoft’s Visual Studio IDE for any time at all, you are likely very familiar with all of the goodies that you can get through TOOLS\Extensions and Updates…  One that I have found to be extremely helpful is Einar Egilsson’s StopOnFirstBuildError.  This one is especially helpful if you have a solution that has many projects.

SFBE

It’s amazing how much time you can save in a large solution by simply stopping and correcting errors at the first sign of trouble, especially when you have inter-solution dependencies that will just fail to build anyway.