Jenkins configuration

The first thing is to install the MsBuild Jenkins plugin. After that, it is a quick pointing to the msbuild executable and we’re off to a good start…

Project configuration

Next, configure the project to use the MsBuild version we setup. Point it to your build file and we are ready to build…

The fairy tale

In theory, of course, that is how simple it should have been. At least, that’s how the fairy tale goes. Having a look at the console output and bam, back to the cruel world where I find myself with a couple of challenges:

1. warning MSB3644: The reference assemblies for framework “.NETFramework,Version=v4.0″ were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
2. error MSB4019: The imported project “C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets” was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
3. error CS0234: The type or namespace name ‘Mvc’ does not exist in the namespace ‘System.Web’ (are you missing an assembly reference?)

The fixing

The  first issue is relatively simple to fix. It requires that you download and install the small (~500MB) Windows SDK for Windows 7 and .NET Framework 4. You don’t need all of it. Only select the .NET Development components in the installation options. Install this on the server and the warnings be gone!

The second, yeah, the second issue is where the Caption Hook catches something unmentionable. To fix this; you’ll feel the hook… Two choices; either create the folders and copy the missing file from your development machine or install Visual Studio on the build server. The purist rants and raves. Go with the lesser of the two evils, create the folder structure and copy the file. That wasn’t that painful; I feel dirty.

The third issue is that ASP.NET MVC 3 is not found anywhere on the server. Easy fix, download and install ASP.NET MVC 3.

Finally, the project builds and all is well. For now.

by Sydney du Plooy

Source Control

Since everyone, OK, almost everyone, raves about Git, I suppose I’ll have to succumb. But, this is where the fun starts. I want Git, I want Windows. Pushing, cloning and so on is what really I want. What a painful story… This requires the installation of MSysGit or Cygwin and some SSH server, blah blah, whatever. It was simply too much.

I decided to run VisualSVN on the server and then use git-svn to bridge that little dilemma. Well, that kinda sucked. After formatting and configuring and formatting and configuring, I finally found this post by Jeremy Skinner. It explains how to setup Git on Windows using IIS 7.0, without any other fancy installations and configurations. He calls it git-dot-aspx (GitAspx). To my surprise, this worked elegantly, the first time. Push, pull and clone without any issues. Great.

Continuous Integration

What a mental battle this turned out to be! What should I use, what do I need to use? There is from CruiseControl.NET to Hudson. A colleague mentioned Hudson and, being quite popular, I decided to investigate. This turned out to be a fantastic piece of software. It is a Java application, but I decided that it is well worth it. One click and it installs as a Windows service. One command line and it uninstalls cleanly. Unbelievable! Such a polished product. Also, it has many plugins from MsBuild to Git to Twitter. Talk about pressure, having your build status published to Twitter!

For a good Windows alternative, these two products turned out to be highly effective and user friendly.

public class ClassToBeAutoMocked
{
	private IConstructorDependency _ConstructorInjectedDependency;

	public ClassToBeAutoMocked(IConstructorDependency dep)
	{
		_ConstructorInjectedDependency = dep;
	}

	private IPropertyDependency PropertyDependency
	{
		get;
		set;
	}

	public string PrintConstructorDependency()
	{
		return _ConstructorInjectedDependency.Print();
	}

	public string PrintPropertyDependency()
	{
		return PropertyDependency.Print();
	}
}

The one dependency is provided in the constructor and the other is injected via the private property. Out-of-the-box, StructureMap AutoMocker provides the ability to mock and inject the constructor dependency. Private properties, however, are not supported. This can be solved by means of an extension method applied to the RhinoAutoMocker type, for example:

public static class RhinoAutoMockerExtensions
{
	public static void RegisterPropertyDependency<TARGETCLASS>(this RhinoAutoMocker autoMocker, string propertyName) where TARGETCLASS : class
	{
		var propertyInfo = typeof(TARGETCLASS).GetProperty(propertyName,
			BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);

		if (propertyInfo == null)
		{
			throw new ArgumentException(string.Format("Property {0} was not found on the type {1}",
				propertyName, typeof(TARGETCLASS).Name));
		}

		var propertyType = propertyInfo.PropertyType;
		var mockDependency = MockRepository.GenerateMock(propertyType, null);
		autoMocker.Inject(propertyType, mockDependency);
		propertyInfo.SetValue(autoMocker.ClassUnderTest, mockDependency, null);
	}
}

We now have the necessary pieces to get an auto mocked instance of ClassToBeAutoMocked.

Next, create an instance of the RhinoAutoMocker class with the concrete type, which will then create the constructor dependency mock and inject it. Because the private property dependency injection is not supported we have to tell the AutoMocker that we want the private property mocked and injected as well. We accomplish this by calling the extension method RegisterPropertyDependency with the name of the property that must be mocked. To obtain a reference to the generated mock we can call the Get method with the dependency type which will return the mock instance. We are then free to stub or set expectations on that dependency as required by our unit tests.

For example:

static void Main(string[] args)
{
	var mocks = new RhinoAutoMocker(MockMode.AAA);
	mocks.RegisterPropertyDependency("PropertyDependency");

	mocks.Get<IConstructorDependency>().Stub(x => x.Print()).Return("On fire with the constructor dependency!");
	mocks.Get<IPropertyDependency>().Stub(x => x.Print()).Return("On fire with the property dependency!");

	Console.WriteLine("Constructor dependency output: {0}", mocks.ClassUnderTest.PrintConstructorDependency());
	Console.WriteLine("Property dependency output: {0}", mocks.ClassUnderTest.PrintPropertyDependency());

	Console.ReadLine();
}

IConstructorDependency

A multi-mock is created like so:

var mocker = new MockRepository();
var mock = mocker.CreateMultiMock<IPrimaryInterface>(typeof(IFoo), typeof(IBar));
mock.Expect(x => x.AnswerToUniverse()).Return(42);
mocker.ReplayAll();

In order to have the hints available in Visual Studio 2008 copy the files into C:\Program Files\Microsoft Visual Studio 9.0\XML\Schemas and restart Visual Studio.

The first building block in our aspect proxy framework is the Dynamic Type Factory. As you might have guessed, this is the component that we will use to define a dynamic assembly that will hold our in-memory assembly with the dynamically created types. In other words, we have an assembly that is created in-memory as a container for the proxy classes that we will create and instantiate.

A couple of static variables and constants are needed for the DynamicTypeFactory class which are:

private const string ASSEMBLY_NAME = "AspectProxies";

private static ModuleBuilder _ModuleBuilder;
private static AssemblyBuilder _AssemblyBuilder;

private static string _FileName = 
  string.Format("{0}.dll", ASSEMBLY_NAME);

private static AssemblyName _AssemblyName = 
  new AssemblyName(ASSEMBLY_NAME);

For simplicity we will only have one dynamic assembly in the current AppDomain. Hence, the DynamicTypeFactory class will have a static constructor that creates a new dynamic assembly and module, like so:

static DynamicTypeFactory()
{
  _AssemblyBuilder = Thread.GetDomain().DefineDynamicAssembly(
    _AssemblyName, AssemblyBuilderAccess.RunAndSave);

  _ModuleBuilder = _AssemblyBuilder.DefineDynamicModule(
    ASSEMBLY_NAME, _FileName);
}

public static string FileName
{
  get { return _FileName; }
}

public static TypeBuilder Create<T>(T instance, string identifier)
{
  if (!typeof(T).IsInterface)
    throw new ArgumentException("Type T must be an interface.");

  if (instance == null)
    throw new ArgumentNullException("instance"));

  if (string.IsNullOrEmpty(identifier))
    identifier = Guid.NewGuid().ToString("N");

  return _ModuleBuilder.DefineType(
    string.Format("{0}_Proxy", identifier),
    TypeAttributes.Public | TypeAttributes.Class | TypeAttributes.Sealed,
    typeof(object),
    Resolver.GetInterfaces(instance.GetType()));
}

Obviously, every type that we define must have a unique name and this is where the identifier comes in. Sometimes we would want a name that we can recognize such as the type the proxy is for and maybe some of the interfaces. Using reflector to examine our types can become rather painful to examine if we have a thousand types and no way to identify them. Just for safety we check if we an identifier, if not then we will just assign it a GUID value. This identifier is later on post-pended with “_Proxy”.

The next bit actually defines the type in the dynamic module. We supply a couple of attributes that says that our type must be a public sealed class which derives from object. The next parameter resolves or gets all of the interfaces on our instance and supplies them for the type definition. Now we defined a type in the meta data but still need to give this type a body.

When debugging, it is useful to have the ability to save the proxy type to the disk. For that we need to have a method like so:

public static void Save()
{
  _AssemblyBuilder.Save(_FileName);
}

public interface IVehicle
{
  string Make{get;set;}
  void Start();
  void Stop();
}

But before the call is made to the target instance, it should first call our aspect class. Assume, for now, that our aspect just logs an entry whenever a call is made to one of the members.

That means that we would expect our proxy class to look something like this:

[Proxy]
public sealed class IVehicle_LogAspect_Proxy : IVehicle
{
  private IVehicle _TargetInstance;
  private ILoggerAspect _LoggerAspect;

  public IVehicle_LogAspect_Proxy(
    IVehicle targetInstance, ILoggerAspect loggerAspect)
  {
    _TargetInstance = targetInstance;
    _LoggerAspect = loggerAspect;
  }

  public string Make
  {
    get
    {
      _LoggerAspect.Log("Make.Get");
      return _TargetInstance.Make;
    }
    set
    {
      _LoggerAspect.Log("Make.Set");
      _TargetInstance.Make = value;
    }
  }

  public void Start()
  {
    _LoggerAspect.Log("Start");
    _TargetInstance.Start();
  }

  public void Stop()
  {
    _LoggerAspect.Log("Stop");
    _TargetInstance.Stop();
  }
}

First, there is a Proxy attribute applied to the proxy class. This is just to identify the class as a proxy type. Sometimes it might be necessary for calling code to know whether it is dealing with a real object or a proxy. The attribute facilitates this quite nicely.

Naming the type is a matter of concatenating the interface names, separated by underscores together with the aspect that is injected. Finally, we simply just add the word Proxy to the type name to help with identification.

After all that the constructor is next. The constructor plays a vital role in the proxy as it receives the reference to the target instance as well as the reference to the aspect instance. Both these references are assigned to private variables by the constructor.

As you can see, the aspect method is directly injected into the member, before the call is passed to the target instance.

The advantages of doing it this way are that all the heavy aspect code is outside of the proxy class, which makes it a lot simpler to write and maintain.

Now that we have an idea of what the proxy class should look like we will next look at the framework building blocks.

A business software package has cross-cutting functionality across its domain objects. This leads to duplicated code and needs to be generalised.

Solution:

Produce a general proxy aspect framework for applying aspects to domain objects.

Note: The framework that we are going to construct is for a specific scenario and is not intended to compete with other aspect oriented frameworks out there. It is intended to demonstrate the principles and considerations that need to be taken into account when applying aspects to domain objects.

Prerequisite:

Every domain object must be defined by an interface.

Requirements:

At a high level our requirements for the proxy aspect framework are as follows:

• Support multiple aspects per domain object;
• Generated proxy must at least implement the domain objects interface;
• Support aspects that need to implement their own interfaces on the proxy;
• Collections must be applied the same aspects as the domain object it is defined on;
• Proxy types must be cached;
• Support the ability to place intercepting calls before and/or after the call to the target instance;
• Must be able to save the assembly containing all proxy types;
• Must be able to intercept methods, events and properties.

Next, we will discuss the framework design.

Let’s say you want to check the permissions of a user before executing a method (this is the type of aspect that we want to apply to our object). You can appreciate that when a system is beyond “Hello World!” that this can turn out to be quite a thing to remember and apply on every method.

To solve this problem we would need to inject this call into the methods where this security check needs to be done. This can be done in various ways, such as creating a proxy at runtime that performs the check or alter the assemblies with another tool after compilation.

Over the next couple of weeks, I will walk you through the requirements, design and construction of one of these approaches that I call; you guessed it; the proxy aspect approach.

At a high level, the idea is to create a proxy for every object that needs to have certain functionality executed as soon as, for example, a method is entered or a property is changed. In effect, the object will have multiple layers or proxies to which all calls; that are intended for the target instance; are directed.

One proxy is created for each aspect that is applied, and every proxy object carries a reference to the instance of the target instance. This target instance can either be another proxy object or the final domain object, say.

When the call is made to the proxy object it will execute the aspect code and then forward the call to the target instance. If the target instance is a proxy, the same process will happen again until it reaches the inner most target instance where the call is finally handled. If there are results that need to be returned, it passes back up through every proxy until it reaches the original caller.

Next, we’ll have a look at the requirements.

]]> http://thirdshelf.com/2008/03/27/proxy-aspect-oriented-approach/feed/ 0 Sydney Target instance with Proxy object