Simple and Generic ICommand Implementation for Usage in XAML

Preface

The Commanding Overview says “Commanding is an input mechanism in Windows Presentation Foundation (WPF) which provides input handling at a more semantic level than device input. Examples of commands are the Copy, Cut, and Paste operations found on many applications.

Well, one should extent the definition and mention Windows Store apps too. Commanding is not limited to WPF.

When looking for a sample implementation that could be used in Windows Store apps too, I found this forum post: ICommand and MVVM.

The implementation looked quite easy to me, but lacks of type safeness from my point of view.

So I extended the DelegateCommand class from this post to be more typesafe.

Generic ICommand Implementation

/// <summary>
/// Generic implementation of <see cref="ICommand"/>.
/// </summary>
/// <typeparam name="T">
/// Type of the parameter the command expects.
/// </typeparam>
/// <remarks>
/// Copied from http://social.msdn.microsoft.com/Forums/en-US/f457c906-56d3-49c7-91c4-cc35a6ec5d35/icommand-and-mvvm
/// </remarks>
public class DelegateCommand<T> : ICommand
{
  #region Private Properties

  /// <summary>
  /// Gets / sets the action to be executed.
  /// </summary>
  private Action<T> ExecuteAction { get; set; }

  #endregion Private Properties


  #region Public Events

  /// <summary>
  /// Occurs when changes occur that affect whether 
  /// the command should execute.
  /// </summary>
  public event EventHandler CanExecuteChanged;

  #endregion Public Events


  #region Public Constructors

  /// <summary>
  /// Initializes a new instance of <see cref="DelegateCommand"/>
  /// with the action to be executed.
  /// </summary>
  /// <param name="executeAction">
  /// Action to be executed.
  /// </param>
  public DelegateCommand
    (
    Action<T> executeAction
    )
  {
    ExecuteAction = executeAction;
  }

  #endregion Public Constructors


  #region Public Methods

  /// <summary>
  /// Determines whether the command can execute in its current state.
  /// </summary>
  /// <param name="parameter">Data used by the command.</param>
  /// <returns>
  /// <c>true</c> if this command can be executed; 
  /// otherwise, <c>false</c>.
  /// </returns>
  public bool CanExecute
    (
    object parameter
    )
  {
    return true;
  }

  /// <summary>
  /// Invokes the method to be called.
  /// </summary>
  /// <param name="parameter">Data used by the command.</param>
  public void Execute
    (
    object parameter
    )
  {
    ExecuteAction((T) Convert.ChangeType(parameter, typeof(T)));
  }

  #endregion Public Methods
}

Usage

This class is used something like this:

public class MyViewModel
{
  …
  public ICommand SomeMethodCommand { get; private set; }
  …
    public MyViewModel ()
    {
      // Set the command.
      SomeMethodCommand = new DelegateCommand(SomeMethod);
    }
  …
    public void SomeMethod
      (
      bool value
      )
    {
      // Do something
    }
}

The usage in XAML is like this:

<Button Content="Invoke SomeMethod" 
  Command="{Binding SomeMethodCommand}" 
  CommandParameter="true"/>

where the DataContext of the page is set to an instance of MyViewModel.

Limitations of the Implementation

As said, this is a simple implementation of ICommand.

It does not evaluate the value passed to CanExecute. And it does not fire an event in case the CanExecute state changes (which is not implemented here too).

Links

Commanding Overview

Forum Post ICommand and MVVM

Home-made Private Accessor for Visual Studio 2012+

Why Home-made?

Short answer: Starting with Visual Studio 2012, private accessors cannot be created any more by the IDE.

It seems that this does not bother too many people. The ‘Bring Back Private Accessor’ suggestion on UserVoice has not found any supporters right now.

Nevertheless, I still need access to private members of classes for testing purposes. And I do not want to declare them as internal because these members should not be (mis)used from within the same assembly.

Update 2013-11-09

Axel Mayer noted in the MSDN forums post How to create private accessors in VS 2012 that one can use the command line tool publicize.exe to create private accessors too. See Use Publicize.exe to Create Private Accessors for Visual Studio 2012+ for a detailed description.

The Goals

Just a few things:

  • Type safety
  • Protect from typos
  • Easy to handle when rename is required
  • Encapsulate / hide the use of PrivateObject

Use of PrivateObject

Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject is the base class to build up our own private accessor infrastructure. Well, infrastructure is such a big word. As you will see later, this infrastructure is really lightweight.

The direct use of PrivateObject has some disadvantages. You always have to use strings as parameters to invoke a method or get / set the value of a property. So there is a good chance the call of a method fails because I mistyped the method name. Some casting issues come up too. And using async / await in .NET 4.5, the direct use of PrivateObject.Invoke does not look really funny.

The direct use of PrivateObject looks like this

// Create an instance of the class to be tested.
ClassToBeTested instance = new ClassToBeTested ();

// Create a PrivateObject to access private methods of instance.
PrivateObject privateObject = new PrivateObject(instance);

// Create parameter values
object[] args = new object[] { "SomeValue" };

// Call the method to be tested via reflection, 
// and pass the parameter, and cast the result
int result = (int) privateObject.Invoke("PrivateMethod", args);

// Do some validation stuff

Create an Accessor Class

The first step to get away from this unpleasant and code inflating use of PrivateObject is to create an accessor class inside the unit test assembly.

This accessor class will hide the usage of PrivateObject. It gives type safety and helps to avoid typos on method- and property names. In case a member of the tested class is renamed, there is one single place to change in the test assembly. All other changes in the unit test can be done by Visual Studio renaming support.

A short version of the accessor to ClassToBeTested might look like this:

internal ClassToBeTestedAccessor
{
  private PrivateObject PrivateObject { get; set; }

  internal ClassToBeTestedAccessor()
  {
    PrivateObject = new PrivateObject(new ClassToBeTested());
  }

  internal int PrivateMethod
    (
    string parameter
    )
  {
    return ((int) PrivateObject
      .Invoke("PrivateMethod", new object[] { parameter }));
  }
}

And the test method using the accessor changes to this:

// Create an instance of the accessor.
ClassToBeTestedAccessor accessor = new ClassToBeTestedAccessor ();

// Call the method to be tested
int result = accessor.PrivateMethod("SomeValue");

// Do some validation stuff

Now the test method itself already looks the way I like it.

Make Accessor Reusable

Let’s assume there is the need for more than one accessor class in the test assembly. Then it might make sense to put some functionality into a base class for reuse purposes.

The base class should keep the instance of the tested class and the PrivateObject to access it. This means it have to be generic to get a type safe implementation.

This will be the starting point:

internal abstract class PrivateAccessorBase<T>
{
  private PrivateObject PrivateObject { get; set; }

  public T TestInstance 
    { get { return ((T)PrivateObject.Target); } }

  internal PrivateAccessorBase
      (
      T instance
      )
    {
      PrivateObject = new PrivateObject(instance);
    }
}

Please notice the public property TestInstance. This proporty gives access to the instance that is encapsulated by the private accessor. In case the unit test method needs to access public members of the tested class too, use this proporty.

What is common in my unit tests is to get or set the value of a property and to call a method. Therefore, the base class should offer the ability to do that.

Property Access

To get a property value, one might implement a method like this:

protected TReturnValue GetPropertyValue<TReturnValue>
  (
    string propertyName
  )
{
  return ((TReturnValue)PrivateObject
    .GetProperty(propertyName, null));
}

But this implementation still requires to pass the name of the property as a string. This can be avoided by using the call stack (in case you are using .NET 4.5 or higher, please have a look below to avoid StackFrame usage):

protected TReturnValue GetPropertyValue<TReturnValue>()
{
  // Need to remove the "get_" prefix from the caller's name
  string propertyName 
    = new StackFrame(1, true).GetMethod().Name
      .Replace("get_", String.Empty);

  return ((TReturnValue)PrivateObject
    .GetProperty(propertyName, null));
}

Setting a property value looks quite similar:

protected void SetPropertyValue
  (
  object value
  )
{
  // Need to remove the "set_" prefix from the caller's name
  string propertyName 
    = new StackFrame(1, true).GetMethod().Name
      .Replace("set_", String.Empty);

  PrivateObject.SetProperty(propertyName, value, new object[] { });
}

Having this base class, we can implement the ClassToBeTestedAccessor like this:

internal ClassToBeTestedAccessor
  : PrivateAccessorBase<ClassToBeTested>
{
  internal ClassToBeTestedAccessor ()
    : base(new ClassToBeTested())
  {
  }

  internal int PrivateProperty
  {
    get { return (GetPropertyValue<int>()); }
    set { SetPropertyValue(value); }
  }
}

The usage of the property by the test class does not differ from the usage of ‘normal’ properties:

// Create an instance of the accessor.
ClassToBeTestedAccessor accessor = new ClassToBeTestedAccessor ();

// Set the value
accessor.PrivateProperty = 231;

Debug.WriteLine("PrivateProperty: >{0}<", accessor.PrivateProperty); 

Method Access

Based on this, it is simple to implement the access of non-public methods in the accessor base class.

// Implemented by PrivateAccessorBase
protected TReturnValue Invoke<TReturnValue>
  (
   params object[] parameter
  )
{
  return ((TReturnValue)PrivateObject.Invoke(
    new StackFrame(1, true).GetMethod().Name, parameter));
}

The accessor class uses this method like this:

// Usage by ClassToBeTestedAccessor
internal int PrivateMethod
  (
  string parameter
  )
{
  return (Invoke(parameter));
}

Using the PrivateAccessorBase together with a derived accessor class, the typo danger is eliminated. We got type safety, the accessor implementation does not contain PrivateObject usage, and there is a single place to be changed when some property or method names of the tested class will change.

Preconditions

There is only one precondition: The properties and methods names of the accessor class have to match 100 percent with the corresponding members of the tested class!

Avoid Inlining

One thing really important when using the StackFrame is to make sure the caller's name will not change. How might this happen? When the JIT compiler thinks it should optimize the code by inlining methods.

This would be fatal when using the call stack to get the name of the original caller. As soon as a method is inlined, the call stack changes.

Sample: Assume ClassToBeTestedAccessor.PrivateMethod will be optimized, because it only contains the call to PrivateAccessorBase.Invoke. In this case, the name of the caller in PrivateAccessorBase.Invoke won't be 'PrivateMethod' any more, but the name of the method that called ClassToBeTestedAccessor.PrivateMethod. Using this name, let's assume it is 'TestPrivateMethod', as the method name parameter of PrivateObject.Invoke, the test will fail with an exception, telling the method 'TestPrivateMethod' was not found.

Even if unit tests normally run in debug mode (the 'Optimize code' option is not set in the project's build configuration), one should be aware of this. To make sure the JIT compiler does not inline a method, set the [MethodImpl(MethodImplOptions.NoInlining)] attribute. The sample solution shows how and where.

Changes in .NET 4.5

In case you can use .NET 4.5 or above, you don't have to care about inline optimization 🙂

.NET 4.5 introduced the class CallerMemberNameAttribute. Using this class, there is no need to worry about these things. The attribute is processed by the C# compiler when it produces the IL code. Optimization is done by the JIT compiler later on (see forum post CallerMemberNameAttribute and Inlining).

For the .NET 4.5 implementation, the usage of MethodImpl and StackFrame is obsolete. The PrivateAccessorBase changes to this:

// Implemented by PrivateAccessorBase
protected TReturnValue GetPropertyValue<TReturnValue>
  (
  [CallerMemberName] string callerName = null
  )
{
  return ((TReturnValue)PrivateObject.GetProperty(callerName, null));
}

protected void SetPropertyValue
  (
  object value,
  [CallerMemberName] string callerName = null
  )
{
  PrivateObject.SetProperty(callerName, value, new object[] { });
}

protected TReturnValue Invoke<TReturnValue>
  (
  [CallerMemberName] string callerName = null,
  params object[] parameter
  )
{
  return ((TReturnValue)PrivateObject.Invoke(callerName, parameter));
}

Please notice that even the removal of the 'get_' / 'set_' prefix is not required any more.

The ClassToBeTestedAccessor has to name the parameter passed to PrivateAccessorBase.Invoke to make sure the first parameter is not interpreted as the caller method name.

// Implemented by ClassToBeTestedAccessor
internal string ProtectedMethod
  (
  string parameterValue
  )
{
  // Need to name the parameter, 
  // otherwise the first parameter will be 
  // interpreted as caller's name.
  return (Invoke(parameter: parameterValue));
}

Test Static Member

To access static class members, no class instance or PrivateObject is required. The PrivateAccessorBase collects all properties and methods the type defines, using the static constrcutor.

// Implemented by PrivateAccessorBase
private static IEnumerable DeclaredProperties { get; set; }

private static IEnumerable DeclaredMethods { get; set; }
…
static PrivateAccessorBase()
{
  TypeInfo typeInfo = typeof(T).GetTypeInfo();

  PrivateAccessorBase<T>.DeclaredProperties 
    = typeInfo.DeclaredProperties;

  PrivateAccessorBase<T>.DeclaredMethods 
    = typeInfo.DeclaredMethods;
}

One have to search for the property / method having the matching name, and invoke it.

// Implemented by PrivateAccessorBase
protected static TReturnValue GetStaticPropertyValue<TReturnValue>
  (
  [CallerMemberName] string callerName = null
  )
{
  return ((TReturnValue)PrivateAccessorBase<T>
    .DeclaredProperties
      .Single(info => info.Name.Equals(callerName))
        .GetValue(null));
}

protected static void SetStaticPropertyValue
  (
  object value,
  [CallerMemberName] string callerName = null
  )
{
  PrivateAccessorBase<T>.DeclaredProperties
    .Single(info => info.Name.Equals(callerName))
      .SetValue(null, value);
}

protected static void InvokeStatic
  (
  [CallerMemberName] string callerName = null,
  params object[] parameter
  )
{
  PrivateAccessorBase<T>.DeclaredMethods
    .Single(info => info.Name.Equals(callerName))
      .Invoke(null, parameter);
}

Please note that this is the .NET 4.5 implementation. For .NET version < 4.5, please refer to the sample solution.

Test Async Methods

Having the above in place, and putting it together with the description of the post Unit-Testing of Private Async Methods with Visual Studio, it is easy to extend the base class to be ready for calling async methods.

// Implemented by PrivateAccessorBase
protected async Task<TReturnValue> InvokeAsync<TReturnValue>
  (
  [CallerMemberName] string callerName = null,
  params object[] parameter
  )
{
  TReturnValue returnValue 
    = await (Task<TReturnValue>)PrivateObject
      .Invoke(callerName, parameter);

  return (returnValue);
}

The derived class uses it like this:

// Implemented by ClassToBeTestedAccessor
internal async Task<double> PrivateMethodWithReturnValueAsync
  (
  int millisecondsDelay,
  string outputText
  )
{
  double returnValue 
    = await InvokeAsync<double>
      (parameter: new object[] { millisecondsDelay, outputText });

  return (returnValue);
}

And the testing class uses the accessor this way:

// Implemented by ClassToBeTestedTest
[TestMethod]
public async Task TestPrivateMethodWithReturnValueAsync()
{
  int millisecondsDelay = 300;
  string testValue = "method unit test";

  ClassToBeTestedAccessor accessor 
    = new ClassToBeTestedAccessor();

  double result 
    = await accessor
      .PrivateMethodWithReturnValueAsync(millisecondsDelay, testValue);

  // Do validation stuff
}

Not Complete

The intention of this post and the sample solution is to give you an idea on how to create a home-made private accessor, and what to take care of when doing so.

The intention is not to offer a complete substitute of Visual Studio's Private Accessor Creation feature.

Accordingly, not all possible unit test scenarios are covered. Please feel free to extend the code for your needs and share your solutions and ideas with us by adding comments describing it.

Conclusion

Having this accessor base class, the creation of private accessors should be quite easy. Of course, not as easy as clicking a menu item, but better than fiddling around with PrivateObject.

The code snippets in this post might look a little bit complex and / or confusing. In this case, try to focus on the test class and accessor. Forget about the PrivateAccessorBase.

I hope you agree that both the creation of the accessor and the usage by the test class will be very comfortable and straightforward, having PrivateAccessorBase in place.

The Sample Solution

The sample solution contains four projects:

  • ConsoleApplication contains the class to be tested, based on .NET 4.0.
  • ConsoleApplication.4.5 contains the class to be tested, based on .NET 4.5.
  • ConsoleApplication.Test contains the PrivateAccessorBase, the accessor class, and the unit test class for ConsoleApplication, based on .NET 4.0.
  • ConsoleApplication.Test.4.5 contains the PrivateAccessorBase, the accessor class, and the unit test class for ConsoleApplication.4.5, based on .NET 4.5.

The class that is tested is ClassWithNonPublicMembers, located in the ConsoleApplication… projects.

You need Visual Studio 2012 or higher to build the solution.

Here you can download the code.

Test Explorer Output

Links

Upgrading Unit Tests from Visual Studio 2010

'Bring Back Private Accessor' suggestion on UserVoice

Eric Gunnerson's Compendium: Why doesn't C# have an 'inline' keyword?

CallerMemberNameAttribute

Forum question CallerMemberNameAttribute and Inlining

MSDN forum post How to create private accessors in VS 2012

Use Publicize.exe to Create Private Accessors for Visual Studio 2012+

Unit-Testing of Private Async Methods with Visual Studio

Description

Given there is the need to unit-test a private async method. The class to be tested might look like this:

public ClassWithPrivateAsyncMethod
{

// Some stuff

  private async Task PrivateMethodAsync
    (
    string input
    )
  {
    // Call some async framework method
    var result = await SomeFrameworkMethodAsync(input);
    // do something with the result
  }

// Some more stuff

}

In former – pre VS 2012 – times, one would have right-clicked inside this method, selected “Create Private Accessor…” and “Create Unit Tests…”, and implemented the test. Well, this was then, and this is now. Nowadays, Visual Studio does not have the ability to create private accessors and unit test bodies.

But still, you are able to create a unit test yourself. And instead of having a private accessor, we can use Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject, which is included in %Program Files (x86)%\Microsoft Visual Studio 11.0\Common7\IDE\ReferenceAssemblies\v4.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll (path might vary slightly with version changes, this is the path for Visual Studio 2012). To use this assembly, I had to set the Copy Local property of the reference to true.

Instead of wring much more prose, here is the implementation of the unit test method:

using Mut = Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestPlatform.UnitTestFramework;
// some other usings

[TestClass]
public ClassWithPrivateAsyncMethodTest
{
  [TestMethod]
  public async Task TestPrivateMethodAsync()
  {
    // Create an instance of the class to be tested.
    ClassWithPrivateAsyncMethod instance 
      = new ClassWithPrivateAsyncMethod();

    // Create a PrivateObject to access private methods of instance.
    Mut.PrivateObject privateObject 
      = new Mut.PrivateObject(instance);

    // Create parameter values
    object[] args = new object[] { "SomeValue" };

    // Call the method to be tested via reflection, 
    // pass the parameter, and await the return
    await (Task)privateObject.Invoke("PrivateMethodAsync", args);

    // Do some validation stuff
  }

// Some more stuff

}

Have a look at the checklist to be sure not to miss a detail.

Checklist

Check Combine async with return type Task in method declaration. Even if the method returns void, the declaration should be async Task. Otherwise, it cannot be awaited, what would lead to some trouble in testing the method.

Check Add reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll in your test project. You have to browse for it. The assembly can be found in %Program Files (x86)%\Microsoft Visual Studio 11.0\Common7\IDE\ReferenceAssemblies\v4.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll (path might vary slightly with version changes, this is the path for Visual Studio 2012).

Check Set Copy Local to true for the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll reference.

Check Declare an alias for the Microsoft.VisualStudio.TestTools.UnitTesting namespace if you also use Microsoft.VisualStudio.TestPlatform.UnitTestFramework. This helps you to avoid using classes of the wrong namespace. There are some overlappings.

Check Declare testing method async Task, not async void. Otherwise, it will not be recognized as a test method, even when the TestMethodAttribute is set.

Check Use PrivateObject to access private methods of instances. It is located in the namespace Microsoft.VisualStudio.TestTools.UnitTesting.

Check Cast PrivateObject.Invoke‘s return value to Task to make sure the call can be awaited.

Check Await PrivateObject.Invoke. Otherwise, the tests in the testing method might be performed before the tested method returns.

Links

Async Return Types (C# and Visual Basic)

Handling of Out-Parameters with .NET Reflection

Using Windows Store App Resource Libraries in C# / XAML

Introduction

Given there is a Windows Store app. Some of the resources that this app needs are part of a library. This library contains a XAML file (ApplicationStyles.xaml) for application specific styles and the StandardStyles.xaml that is generated when a new Windows Store App (XAML) project is created. ApplicationStyles.xaml uses StandardStyle.xaml. Means, some styles defined in this file are based on styles that are defined in StandardStyles.xaml. And of course, the styles defined in the library will be used by XAML files that are located in the app.exe.

Scenario

Referencing in App.xaml of App.exe

The App.xaml of the app.exe only needs to reference to ApplicationStyles.xaml of the lib.

<Application.Resources>
  <ResourceDictionary
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <ResourceDictionary.MergedDictionaries>
      <ResourceDictionary
        Source="ms-appx:///InstanceFactory_ResourceLib/Assets/ApplicationStyles.xaml"/>
    </ResourceDictionary.MergedDictionaries>
  </ResourceDictionary>
</Application.Resources>

This means the file ApplicationStyles.xaml is located in the directory Assets of a library named InstanceFactory_ResourceLib.

The way to reference the resource dictionary of a lib in Windows Store apps differs from referencing in WPF or Silverlight. In WPF / Silverlight, the Source attribute would be set to /InstanceFactory.ResourceLib;component/Assets/ApplicationStyles.xaml.

The obvious difference is the usage of ms-appx URI prefix. Also, there is no separation of the library name (name of the output file) and the path the the XAML file (‘;component‘ in WPF / Silverlight).

What might be overseen is the fact that Windows Store apps can’t handle dot-separation of the library name. This is why the library in the Windows Store version contains an underscore, not a dot as separator.

It is also worth to mention that one have to put three dashes behind the ms-appx URI prefix.

Referencing Inside of Resource.lib

Because ApplicationStyles.xaml and StandardStyles.xaml are both part of the same assembly, and are located in the same directory, one might tend to include the StandardStyles.xaml into ApplicationStyles.xaml like this:

<ResourceDictionary.MergedDictionaries>
  <ResourceDictionary Source="StandardStyles.xaml"/>
</ResourceDictionary.MergedDictionaries>

But this will not work. It might compile, but the app crashes on startup.

Although both files are part of the same library, you have to reference the StandardStyles.xaml the same way as if it was part of a different lib, means using the URI syntax shown above.

<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary
     Source="ms-appx:///InstanceFactory_ResourceLib/Assets/StandardStyles.xaml"/>
  </ResourceDictionary.MergedDictionaries>

Please notice that this is only the case when ApplicationStyles.xaml of a library is used by App.exe. In case you have all styles defined inside of the exe itself, referencing works without URI syntax.

Checklist

To avoid exceptions in loading an external ResourceDictionary, especially those telling “Failed to assign to property ‘Windows.UI.Xaml.ResourceDictionary.Source’“, you have to comply with these preconditions:

Check Use the URI syntax having this format “ms-appx:///LibraryName/Directory/FileName.xaml

Check Use underscore to separate parts of the name of the assembly that contains the ResourceDictionary

Check Referencing inside the lib assembly also requires the URI syntax