Test Driven Development with ASP.Net MVC (Part 5)

The series in full:

In Part 4 of the series we implemented the first controller action of for the Event Controller in a Test Driven manner. As we are working from the outside-in it means that although the Controller action has been implemented, the layers beneath the Controller (the service layer and the repository in our case) are not yet implemented beyond creating anything needed by the layers above.

As the controller needed to call the service it was implemented in part 4, but is far from complete.

public class EventService : IEventService
{   
    public GetAllRegionsResponse GetAllRegions()
    {
        throw new NotImplementedException();
    }
}

The next step in the outside-in process is to build up the implementation of the service method guided by tests. The functionality for this service method is really simple so it shouldn’t take long to get it up and running. First we should Create a new Test Class to hold out service tests. I have separated out the service test into a separate namespace to aid navigation and readability of the test. I have also named the test class in such a way that when read in conjunction with the test name it gives a meaningful description of the intent of the test.

So what is the intent of the test for the GetAllRegions() service method? We would expect the service method to get all the regions so that they can be presented to the user in by the Event Controller. In this example we are going to have a repositories for data persistence. So this method is going to simply ask the repository for a list of regions, and then package them up to be returned to the Controller. Lets write the test.

public class EventServiceShould
{
    private EventService eventService;
    private Mock<IEventRepository> eventRepository;

    [TestMethod]
    public void ReturnAListOfAllTheRegions()
    {
        //Arrange
        eventRepository = new Mock<IEventRepository>();
        eventService = new EventService(eventRepository.Object);

        var regions = new List<Region>
                            {
                                new Region {Id = 1, Name = "North"},
                                new Region {Id = 2, Name = "South"},
                                new Region {Id = 3, Name = "London"}
                            };

        eventRepository.Setup(x => x.GetAllRegions()).Returns(regions);

        //Act
        var result = eventService.GetAllRegions();

        //Assert
        Assert.AreEqual(3,result.Regions.Count);
        Assert.AreEqual("South", result.Regions[1].Name);
    }
}

As before Resharper is telling us that there is a lot of implementation missing. Lets start with the Repository Interface. I have created another project for the repositories:

namespace CrazyEvents.Repositories
{
    public interface IEventRepository
    {
        List<Region> GetAllRegions();
    }
}

The Repository should always work with domain entities, and ours is no exception. Next up is the Region domain entity. Again I have created a new project to hold the domain items.

namespace CrazyEvents.Domain
{
    public class Region
    {
        public int Id { getset; }
        public string Name { getset; }
    }
}

And finally the service method implementation. This method has no logic, as we simply want to return all the regions. The only thing we need to do is to to take the regions returned from the repository and build the DTO’s for the Controller.

public class EventService : IEventService
{
    private readonly IEventRepository eventRepositoty;

    public EventService(IEventRepository eventRepositoty)
    {
        this.eventRepositoty = eventRepositoty;
    }

    public GetAllRegionsResponse GetAllRegions()
    {
        var regions = eventRepositoty.GetAllRegions();

        var regionDtos = regions.Select(region => new RegionDto {Id = region.Id, Name = region.Name}).ToList();

        return new GetAllRegionsResponse {Regions = regionDtos};
    }
}

Now the implementation is complete lets run the tests and make sure everything is okay.

All the tests are green which means that everything is going well. The implementation for the scenario is almost complete. Working from the outside in means that the only thing left to do at this point is the repository implementation.

As the repository will need to perform the data persistence (usually by talking to a database) it is not possible to isolate the implementation for unit testing in the same way as the controller or the service and is not generally part of an outside-in TDD approach. That is not to say it should not be tested. It would be prudent to create an integration test for the scenario including talking to a real database. Better yet, would be to use the scenario to create a BDD style test with a framework such as SpecFlow.

Once the repository method is complete, it is time to move onto the next slice of functionality and follow the same outside-in process.

The series in full:

Advertisements

Windows Communication Foundation – Resolving MVC client WCF ChannelFactory dependencies with Unity

This series of posts will talk about Windows Communication Foundation, starting with an introduction into the technology and how to use it in you project, moving onto more advanced topics such as using an IOC container to satisfy dependencies in your services.
Posts in this series:

In the previous post we looked at how it was possible to use ChannelFactory to consume a WCF service from an MVC controller without using a proxy generated from the service WSDL.

The View action of the ProductController looked like this:

public ActionResult View(int productId)
{
    var factory = new ChannelFactory<IProductService>("WSHttpBinding_IProductService");
    var wcfClientChannel = factory.CreateChannel();
    var result = wcfClientChannel.GetProductById(productId);

    var model = new ViewProductModel 
        { 
            Id = result.Id, 
            Name = result.Name, 
            Description = result.Description 
        };

    return View(model);
}

This approach is less than ideal. The ChannelFactory creation is a little awkward and would be littered throughout the controller code creating duplication.

It would be better if we could just use Unity to inject a dependency to the WCF service in the Controller constructor like this;

private readonly IProductService productService;

public ProductController(IProductService productService)
{
    this.productService = productService;
}

public ActionResult View(int productId)
{
    var result = productService.GetProductById(productId);

    var model = new ViewProductModel 
        { 
            Id = result.Id, 
            Name = result.Name, 
            Description = result.Description 
        };

    return View(model);
}

If we tried to run this MVC would not be able to create the controller as there is no longer a parameterless constructor. Since version 3 MVC has introduced a mechanism for using IoC dependency resolution to resolve Controller dependencies through IDependencyResolver. Simply implement the interface and register using DependencyResolver.SetResolver.

If your needs are simple, then there are very simple implementations that will serve you well, however if you want to resolve dependencies that implement IDisposable then you need to be a bit more careful, as simple implementations often do not cater for IDisposable at all.

I am going to recommend a NuGet package to save us from implementing IDependencyResolver as I want to focus on how we can resolve WCF service dependencies. Unity.MVC3  is a nice little package that makes setting up Unity with MVC very easy. Although it was built for MVC3, version 4 uses the same mechanism and the package continues to function in the correct manner. You can read more about how the package functions here.

Install the package and open Bootstrapper.cs. Inside there is a BuildUnityContainer() section, this is where we need to register the dependencies with Unity. But when we ask for an IProductService what should we return? We need a new WCF channel for the IProductService based on the endpoint settings we defined in the web.config in the previous post. The code to do this is:

private static IUnityContainer BuildUnityContainer()
{
    var container = new UnityContainer();

    container.RegisterType<IProductService>(
        new ContainerControlledLifetimeManager(),
        new InjectionFactory(
            (c) => new ChannelFactory<IProductService>("WSHttpBinding_IProductService").CreateChannel()));          

    return container;
}

So what does this actually do? The first parameter is the type of lifetime manager we require. A Unity lifetime manager describes how dependencies are created and destroyed and the lifetime those dependencies have. In this case a ContainerControlledLifeTimeManager means that the same instance is returned for each call (also known as Singleton instance). This is desirable for creating WCF channels  as it is a comparatively expensive operation so we only want to create the channel once for the lifetime of the Unity container. There are several other Unity Lifetime Managers that are useful in different circumstances.

The next parameter introduces a factory function that tells Unity how to create the required concrete type. In our case we are going to create a new WCF Channel using ChannelFactory for the named client endpoint we set up in the web.config.

The only thing we need to do is to call Bootstrapper.Initialise() from Application_Start() in Global.asax and we are good to go. The controller is now completely decoupled from the WCF ChannelFactory, leaving a much cleaner implementation.

Posts in this series:

Windows Communication Foundation – Resolving WCF service dependencies with Unity

This series of posts will talk about Windows Communication Foundation, starting with an introduction into the technology and how to use it in you project, moving onto more advanced topics such as using an IOC container to satisfy dependencies in your services.
Posts in this series:

In this post I am going to use Microsoft Unity Inversion of Control container to resolve the dependencies for the ProductService implementation.

Most developers will already be familiar with the concept of Dependency Injection and will probably have used an IOC container such as Unity or Castle.Windsor at some point. In order to use Unity to resolve the dependencies in a service implementation a few steps must be taken to wire up Unity with WCF. This post will walk throught the steps to do this.

Adding Unity and creating the DI Wrapper

I have created a new project to hold all the DI related stuff. You may wish to put it somewhere else, which is fine. Into that project I have a added Unity via NuGet. The fisrt thing to do is to create a static wrapper for the Unity Container so we can be sure we are getting the same Unity container whenever we need to use it.

using Microsoft.Practices.Unity;

namespace WcfServiceApplication.DependencyInjection
{
    public static class DIWrapper
    {
        private static readonly IUnityContainer _container;

        static DIWrapper()
        {
           _container = new UnityContainer();   
        }

        public static IUnityContainer Container
        {
            get { return _container; }
        }
    }
}

The DIWrapper provided a static getter returning the UnityContainer. As it is a static class the constructor is guaranteed to run only once and ensures that a new UnityContainer is created. This same container will be returned whenever a call to DIWrapper.Container is made.

UnityServiceHostFactory

A service host does exactly as the name would suggest. A service such as the currect Prodcut Service can be hosted on the standard service host without any issues. Once we want to use Unity (or any other IOC container) we need to extend the ServiceHost functionality in order to resolve the dependencies in the service implementation. WCF uses a factory pattern to provide a layer of indirection between the hosting environment and the concrete type of the service required. If you don’t specify which ServiceHostFactory to use, you will get the default factory that returns an instance of the default ServiceHost.

To specify a ServiceHostFactory for a service it needs to be specified in the service .svc file like so:

<%@ ServiceHost 
    Language="C#" Debug="true" 
    Service="WcfServiceApplication.Implementation.ProductService" 
    Factory="WcfServiceApplication.DependencyInjection.WCF.UnityServiceHostFactory"
%>

If you do not specify a factory in the .svc file you will encounter the following error when trying to use the service.

“InvalidOperationException: The service type provided could not be loaded as a service because it does not have a default (parameter-less) constructor. To fix the problem, add a default constructor to the type, or pass an instance of the type to the host.”

This is because the default behavior for WCF is to call the parameteless constructor, but if you are using constructor injection for the dependency the service implementation will not have one, so WCF does not know how to instantiate the service.

Obviously this factory does not exist so we had better create it. To do so we extend System.ServiceModel.Activation.ServiceHostFactory.

using System;
using System.ServiceModel;
using System.ServiceModel.Activation;

namespace WcfServiceApplication.DependencyInjection.WCF
{
    public class UnityServiceHostFactory : ServiceHostFactory
    {
        protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
        {
            return new UnityServiceHost(serviceType, baseAddresses);
        }
    }
}

All the factory needs to do is return a new instance of ServiceHost, so we just override CreateServiceHost to return our yet to be created new ServiceHost

UnityServiceHost

The new ServiceHost functionality is again very straight forward. System.ServiceModel is extended and a single method is overridden.

using System;
using System.ServiceModel;
using Microsoft.Practices.Unity;

namespace WcfServiceApplication.DependencyInjection.WCF
{
    public class UnityServiceHost : ServiceHost
    {
        public UnityServiceHost(Type serviceType, Uri[] baseAddresses)
            : base(serviceType, baseAddresses) { }

        public IUnityContainer Container
        {
            get { return DIWrapper.Container; }
        }

        protected override void OnOpening()
        {
            new UnityServiceBehavior(Container).AddToHost(this);
            base.OnOpening();
        }
    }
}

Inside the overridden OnOpening method a new UnityServiceBehavior is created (which we will create next) and added to the UnityServiceHost before the OnOpening method on the base ServiceHost is called.

UnityServiceBehavior

The System.ServiceModel.Description.IServiceBehavior interface provides a mechanism to extend or modify some aspect of an entire service. To use Unity with WCF we need to add some custom endpoint behaviour.

using System.Collections.ObjectModel;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using Microsoft.Practices.Unity;

namespace WcfServiceApplication.DependencyInjection.WCF
{
    public class UnityServiceBehavior : IServiceBehavior
    {
        private ServiceHost serviceHost;

        public UnityServiceBehavior()
        {
            InstanceProvider = new UnityInstanceProvider();
        }

        public UnityServiceBehavior(IUnityContainer unity)
        {
            InstanceProvider = new UnityInstanceProvider();
            InstanceProvider.Container = unity;
        }

        public UnityInstanceProvider InstanceProvider { getset; }

        public void AddBindingParameters(
                ServiceDescription serviceDescription,
                ServiceHostBase serviceHostBase,
                Collection<ServiceEndpoint> endpoints,
                BindingParameterCollection bindingParameters) { }

        public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
        {
            foreach (var cdb in serviceHostBase.ChannelDispatchers)
            {
                var cd = cdb as ChannelDispatcher;
                if (cd != null)
                {
                    foreach (var ed in cd.Endpoints)
                    {
                        InstanceProvider.ServiceType = serviceDescription.ServiceType;
                        ed.DispatchRuntime.InstanceProvider = InstanceProvider;
                    }
                }
            }
        }

        public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase) { }

        public void AddToHost(ServiceHost host)
        {
            if (serviceHost != null)
            {
                return;
            }

            host.Description.Behaviors.Add(this);
            serviceHost = host;
        }
    }
}

ApplyDispatchBehavior can be used to change run-time property values or insert custom extension objects such as error handlers, message or parameter interceptors, security extensions, and other custom extension objects. In the UnityServiceBehavior class ApplyDispatchBehavior is used to assign a custom InstanceProvider to the service endpoints.The InstanceProvider in this case is our own UnityInstanceProvider (the implementation of which is shown below).It is the InstanceProvider that will actually use Unity’s funcitonality to resolve the dependencies in the service impementation.

The behaviour of the Validate and AddBindingParameters methods does not need to change and so have empty implementations.

UnityInstanceProvider

This implementation of IInstanceProvider allow control over the instantiation of the service class. Our aim is for Unity to resolve the service type (ProductService in this example) and its dependencies.

using System;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Dispatcher;
using Microsoft.Practices.Unity;

namespace WcfServiceApplication.DependencyInjection.WCF
{
    public class UnityInstanceProvider : IInstanceProvider
    {
        public UnityInstanceProvider()
            : this(null) { }

        public UnityInstanceProvider(Type type)
        {
            ServiceType = type;
            Container = new UnityContainer();
        }

        public IUnityContainer Container { getset; }

        public Type ServiceType { getset; }

        public object GetInstance(InstanceContext instanceContext, Message message)
        {
            return Container.Resolve(ServiceType);
        }

        public object GetInstance(InstanceContext instanceContext)
        {
            return GetInstance(instanceContext, null);
        }

        public void ReleaseInstance(InstanceContext instanceContext, object instance) { }
    }
}

In the UnityServiceBehavior constructor a new UnityInstanceProvider is created and the Unity Container from DIWrapper.Container is assigned as the Container. The GetInstance method then calles Container.Resolve(ServiceType) to resolve an instance of the required type. This is where Unity resolves the dependencies and returns an instance of the Service type with the dependencies satisfied. WCF can now happily use this instance for the service.

Add the dependency to the service

At present the ProductService does not have any dependencies so I will add one to a product repository from where we will return some data. The Prodcut service not looks like this:

using System.ServiceModel.Activation;
using WcfServiceApplication.Contract;
using WcfServiceApplication.Domain;
using WcfServiceApplication.Repository.Interface;

namespace WcfServiceApplication.Implementation
{
    public class ProductService : IProductService
    {
        private readonly IProductRepository productRepository;

        public ProductService(IProductRepository productRepository)
        {
            this.productRepository = productRepository;
        }

        public Product GetProductById(int productId)
        {
            return productRepository.GetProductById(productId);
        }
    }
}

Note that there is no paramaterless constructor, so this service can no longer be resolved via the standard WCF ServiceHost. I have kept the service implementation simple and just moved the logic that was there to the new repository.

using WcfServiceApplication.Domain;
using WcfServiceApplication.Repository.Interface;

namespace WcfServiceApplication.Repository
{
    public class ProductRepository : IProductRepository
    {
        public Product GetProductById(int productId)
        {
            return new Product
            {
                Id = productId,
                Name = "Product " + productId,
                Description = "A nice product"
            };
        }
    }
}

Configure Unity in Global.asax

Finally we need to configure Unity in the Global.asax of the ServiceHost. We are going to tell Unity to give us back a ProductRepository instance whenever a constructor is expecting an IProductRepository.

using System;
using Microsoft.Practices.ServiceLocation;
using Microsoft.Practices.Unity;
using WcfServiceApplication.DependencyInjection;
using WcfServiceApplication.Repository;
using WcfServiceApplication.Repository.Interface;

namespace WcfServiceApplication
{
    public class Global : System.Web.HttpApplication
    {
        protected void Application_Start(object sender, EventArgs e)
        {
            ConfigureUnity();
        }

        protected void Session_Start(object sender, EventArgs e){}

        protected void Application_BeginRequest(object sender, EventArgs e){}     

        protected void Application_AuthenticateRequest(object sender, EventArgs e){}

        protected void Application_Error(object sender, EventArgs e){}

        protected void Session_End(object sender, EventArgs e){}

        protected void Application_End(object sender, EventArgs e){}

        private void ConfigureUnity()
        {
            // Configure common service locator to use Unity
            ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(DIWrapper.Container));

            // Register the repository
            DIWrapper.Container.RegisterType<IProductRepositoryProductRepository>();           
        }
    }
}

Now we are all ready to run the service. In the next post I will look at using Unity to resolve Channels for the MVC client so we can just inject the service interfaces into the MVC controller, removing the need to call the Channel factory code from the previous post each time we want a new Channel to consume a service.

Posts in this series:

Windows Communication Foundation – Consuming a WCF service with ChannelFactory

This series of posts will talk about Windows Communication Foundation, starting with an introduction into the technology and how to use it in you project, moving onto more advanced topics such as using an IOC container to satisfy dependencies in your services.
Posts in this series:

In An Introduction to WCF I talked a little about what WCF is and how it can be used, as well as creating a simple WCF service. In this post I want talk about how to consume WCF services in the most common situations.

There are two common scenarios when consuming WCF services; consuming a WCF service from a non WCF client via a proxy, and consuming a WCF service from a WCF client via a shared contract with ChannelFactory.

Consuming a WCF service from a non WCF client via a service proxy

A service proxy acts as an interface between the client and the service. It means that the client does not need to know anything about the implementation of the service other than the operations that are exposed. A downside to using a proxy is that if the interface of the service changes then the proxy will need to be regenerated. Using a service proxy will be necessary if you do not control the service you wish to consume.

To add a service proxy you can either use svcutil.exe or let Visual Studio generate the proxies for you (which uses svcutil.exe underneath) by right clicking on a project and selecting Add Service Reference.

I don’t really want to dwell on service proxies too much, as there is lots of information available already and it is not really very interesting. There is another way to consume a WCF service if you have more control over the service and are using WCF services to provide some separation of concerns in your application.

Consuming a WCF service from a WCF client using ChannelFactory

A real world example is probably the easiest way to describe the type of situation in which this approach is useful. Lets say I am creating an ASP.Net MVC application and I want to have some separation in the layers. Along side the MVC client I want to have a repository to take care of the persistence side of things and a service layer to take care of the business logic so that I can call a service method in the Controller of the client that will perform some operation and maybe talk to the repositories.

It is of course possible to have the services in-process, and for a small application it may be a sensible solution. When moving to a larger application it may be prudent make the service layer true services that can be deployed on a separate server (or server farm) to aid scalability and security. WCF is a ideal technology for these services. In this instance the WCF services are only to be used by this particular application and so we can use some more WCF functionality to remove the need to keep generating service proxies. You will definitely appreciate this as you develop your application. Regenerating proxies gets a little tiresome after the hundredth time.

To use ChannelFactory it is necessary that both client and service host share the same operation and data contracts. Usually this means that the service interfaces (operation contracts) and data contracts are separated into separate assemblies so they can be shared between projects.

What is ChannelFactory anyway?

According to MSDN it is “A factory that creates channels of different types that are used by clients to send messages to variously configured service endpoints”. WCF uses a Channel Model layered communication stack to communicate between endpoints. As with other stacks such as TCP/IP the Channel stack provides an abstraction of the communication between the corresponding layer for the sending and receiving stack.

The stack provides an abstraction for how the message is delivered, the protocol to be used and other features such as reliability and security. Messages flow through the Channel stack and are transformed by a particular Channel, for example the transport channel transforms the message into the required communication format. Above that the protocol channels might encrypt the message or add headers. It is the ChannelFactory that is used to create the channel stack for a particular binding. For more information on the Channel Model see this MSDN article.

Using ChannelFactory to call a service

In the previous post I created a simple Product service with a single operation. I am going to extend that example to add an MVC client that uses ChannelFactory to consume the service. I will break the process into a number of steps to make it easy to follow.

1) Reorganise the solution to separate the interface and data contracts

I have moved the service interface and the data contracts into separate assemblies so they can be shared with the client. As mentioned briefly in the previous post, the data contracts would usually be Data Transfer Objects and not domain entities. For this example I have used domain entities an data contracts for ease. I have also added an Asp.Net MVC 4 project that will act as the client and consume the WCF service.

2) Add the WCF service model configuration to the client Web.config

Just as we added some configuration to the Web.config of the service project to let WCF know how we want the service to work, we also need to add some similar configuration to the client Web.config.

<system.serviceModel>
    <client>
        <endpoint 
            address="http://localhost:53313/ProductService.svc" 
            binding="wsHttpBinding" 
            contract="WcfServiceApplication.Contract.IProductService" 
            name="WSHttpBinding_IProductService"/>          
    </client>
</system.serviceModel>

We can once again see the ABC of WCF. The address is the URL of the service which I have set this to the URL of the Service when it is running0 from Visual Studio. When the client is deployed the address needs to be changed accordingly. The binding needs to be the same as the binding of the service you want to consume. The contract is the service contract from the shared assembly. Finally a name is used so ChannelFactory can get the configuration details by name.

3) Use ChannelFactory to call the service

As this is an MVC application, a service would generally be called from a controller. I have created a ProductController and a couple of views. The simple application works like this: a user enters a Product Id and selects to search. The product details are then displayed. The controller action that call the service looks like this:

public ActionResult View(int productId)
{
    var factory = new ChannelFactory<IProductService>("WSHttpBinding_IProductService");
    var wcfClientChannel = factory.CreateChannel();
    var result = wcfClientChannel.GetProductById(productId);

    var model = new ViewProductModel 
        { 
            Id = result.Id, 
            Name = result.Name, 
            Description = result.Description 
        };

    return View(model);
}

Firstly, create a new factory for the service contract required. The constructor takes the name of an endpoint from the configuration. A channel is then created based on the service contract and the named endpoint configuration. It is then possible to call an operation on the channel and return some results. I have then used the results in the model for the view.

Lets have a look at the MVC client application in action. I am not going to win any awards for design…

Lets search for a product:

And view the results:

Conclusion and next steps

As you can see from the above example, using ChannelFactory is a very easy way of calling a service when you have access to the service and data contracts. However if you were calling multiple services from a controller it would be better to get some reuse and not have to keep creating the factory and channel over and over again. It is possible to create a helper method to control the creation and use of factories but there is a better way.

You are probably already using Dependency Injection in your application via an Inversion of Control container such as Castle Windsor or Unity. It turns out that is it very easy to inject dependencies into service and also to inject a channel directly to where it is needed in your application. In the next post I will look at injecting dependencies into the service implementation.

Posts in this series:

Creating a NuGet Package from a TeamCity build

Posts in this series:

In a previous post I talked about how it was possible to set up .Net dependency management in TeamCity using NuGet. In this post I will cover the steps required to create a NuGet package as part of a TeamCity build, and publish it to TeamCity’s own NuGet package source server.

It is not uncommon to want to reuse a .Net project in another solution, maybe some common data access code. This would mean a bit of a maintenance headache when trying to keep things up to date and versioned correctly. NuGet and TeamCity have now made things very easy. Create a Nuget package for the project when it is built in TeamCity and publish it to TeamCity’s own Nuget package server. This package can then be picked up and used in any other project as a dependency like you would use an external package from the NuGet official package source.

Turn on TeamCity’s NuGet server

Since version 7, TeamCity has been able to host its own Nuget package feed. To enable it, head over to TeamCity’s Administration page and select NuGet Settings.

You will be presented with the URL’s for the NuGet feed. The feed URL will be added in Visual Studio and TeamCity as a package source to allow you to use the packages you create. If you want to turn on the public feed you will need to enable Guest login for TeamCity.

Create a package from a .csproj file

It is possible to create a NuGet package directly from a .csproj file in TeamCity. However if the project from which you wish to create the package has NuGet packages itself you will encounter a couple of errors after setting up a build step and attempting to run the build.

The first will probably be this one:

The imported project "C:\Program Files (x86)\TeamCity\buildAgent\work\c4ce4cf3674f70b0\ExampleProject\ExampleProject\.nuget\nuget.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk. C:\Program Files (x86)\TeamCity\buildAgent\work\c4ce4cf3674f70b0\ExampleProject\trunk\DataAccess\DataAccess.csproj

This problem is caused by some changes made by NuGet to the .csproj file resulting in TeamCity’s build agent not being able to resolve the path correctly.  A solution to this problem is outlined here. However once the fix has been applied you may well find that you encounter another error:

nuget pack: Specifying SolutionDir in properties gives Exception: An item with the same key has already been added.

This looks like it is a Nuget error. An issue has been raised here but at the  time of writing it has not been actioned. If anyone has a solution I would be very interested to hear it.

Don’t despair at this setback. Even if this approach worked correctly it is a bit of a blunt tool. Much better is to use a .nuspec manifest to describe the package we want to build.

Create a package from a .nuspec manifest

A .nuspec manifest is an XML document that defines the content of a NuGet package. A lot of effort has gone into the NuGet documentation on .nuspec files so I am not going to recreate all of it here. Instead I will just show you .nuspec file I used and talk about a few interesting parts. First of all, create a file next to the .csproj of the project you want to package. I want to package my DataAccess project so I created a file called DataAccess.nuspec.  Here is the content:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd">
  <metadata>
    <version>0.00</version>
    <authors>James Heppinstall</authors>
    <owners>James Heppinstall</owners>
    <id>DataAccess</id>
    <title>DataAccess</title>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Description</description>
    <copyright>Copyright James Heppinstall 2012</copyright>
    <dependencies>
        <dependency id="PetaPoco.Core" version="4.0.3" />
      </dependencies>
  </metadata>
  <files>
    <file src="ExampleProject\trunk\DataAccess\bin\Release\DataAccess.dll" target="lib\DataAccess.dll" />
  </files>
</package>

Most of it is straight forward and is covered in the NuGet documentation. It doesn’t matter what the version number you put in. It will be replaced by the build number from the TeamCity build. The dependencies section should contain a list of the NuGet packages for the project. If you are unsure which packages your project uses the best thing to do is to look in the project’s packages.config for the correct name and version.

The files section is where you list the files to be included. I have just included the single .dll as an example. You can also target specific framework versions in the same package using a convention. If I wanted to target only .Net4.0 I would have used

<file src="ExampleProject\trunk\DataAccess\bin\Release\DataAccess.dll" target="lib\net40\DataAccess.dll" />

Remember that a  NuGet package is not just limited to dependencies. It is possible to create a package that contains an entire project structure with code and configuration, including scripts to perform data transformations along the way. So you could create a template package for your organisation’s web site development.

Now we have the .nuspec file the next step is to create a new build step for the TeamCity Project.

Simply select a Runner Type of NuGet Pack, add the path to your .nuspec file and you are good to go. I have selected to publish the package to the build artifacts. This can be useful for audit-ability.

Run the build and check that the Package is created in the build artifacts. If all is good the package is ready to be used in Visual Studio. From Tools | Library Package Manager | Package Manager Settings and select package sources. Add the TeamCity feed URL you wish to use, either authenticated or guest (I have added both for illustration purposes). Of course you should use the correct server name as you will probably not be running TeamCity on your development machine.

Now when you go to Manage Nuget Packages for a project you will be able to select the TeamCity package feed and see the Package you have just created, ready to be added to a new project.

And that’s all there is to it. NuGet and TeamCity make dependency management for your .Net code base very simple.

An Introduction to Windows Communication Foundation – Creating a basic service

This series of posts will talk about Windows Communication Foundation, starting with an introduction into the technology and how to use it in you project, moving onto more advanced topics such as using an IOC container to satisfy dependencies in your services.
Posts in this series:

Before the introduction of Windows Communication Foundation (WCF) in 2006 there were lots of different Microsoft technologies for building distributed systems. ASP.NET Web Services (ASMX), Web Service Enhancements (WSE) extensions, Microsoft Message Queue (MSMQ), the Enterprise Services/COM+ runtime environment and .NET Remoting to name the key ones. Microsoft were keen to point out that there was nothing wrong with these technologies, simply that there are too many of them. Building a distributed system required you to pick one of them as a fundemental technology which would send you down a specific technology strategy.

WCF is a single programming model that unifies all of the above approaches and more, and allows for a single technology choice to be used to support many different distributed systems scenarios.

Microsoft  describes WCF as

“a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. An endpoint can be a client of a service that requests data from a service endpoint. The messages can be as simple as a single character or word sent as XML, or as complex as a stream of binary data.”

Don’t be put off by the reference to the often over hyped service orientation. WCF services can be used in many situations. It is often thought of as being too”enterprisy” for small applications. This is not the case at all. Services can be hosted in applications (Console, Winforms, WPF) as well as IIS and even a Windows Service. This opens up lots of possibilities for developing distributed applications. Many message formats are supported, including SOAP, plain XML and JSON. New formats are added as they gain traction within the industry.

If you have been reading about WCF you may have seen the ABC mnemonic when talking about endpoints;

  • A – Address: Where is the service?
  • B – Binding: How do I talk to the service?
  • C – Contract: What can the service do for me?
In WCF all communication occurs through an Endpoint. The ABC of WCF translates to some concrete steps that are followed when creating a WCF service:
  • You define a contract and implement it on a service – The language may be new but the concepts will be familiar. A WCF contract is an interface that defines service operations. The service implementation is simply an implementation of that interface.
  • You define a service binding that selects a transport along with quality of service, security and other options – This is usually done in configuration, but can be done in code if required.
  • You deploy an endpoint for the contract by binding it to a network address.  Configuration again. Tell WCF which contract interface should be associated with a particular endpoint.

Don’t worry if some of the terminology or concepts are new to you, we will cover these in more detail in the next section.

Creating you first WCF Service

Lets go ahead and create a new WCF Service Application project in Visual Studio, either in a new solution or an existing one, it doesn’t really matter for the purposes of this example. Be sure to target .Net3.5. There is a reason for this as .Net4.0 has lots of features to simplify configuration, but it is not that helpful to have lots of things defaulted behind the scenes when we are trying to understand how things work.

Visual Studio helpfully(?!) creates a service for us named Service1. A quick rename and we are done, right? Not quite. Although this service would work correctly, the way it has been created would not really be of any practical use in any but for the smallest of applications. The service implementation is in a code-behind on the .svc file and the interface is in the same file as the data contracts (the service model).

Lets just delete the files we don’t want and start again. Start with the code-behind file Service1.svs.cs and IService1.cs. Lets leave the Web.config for now as we can reuse the configuration already in there. If you were writing a full size application you may well want to structure your solution into several different projects for the different parts of the application. For this introduction I am going to use folders.

The first thing I am going to do is create a service contract. Remember that a service contract is just an Interface. Create a folder called Contract and an Interface within it, IProductService seems like a sensible name. Add a ServiceContract attribute to the interface. You will need a using statement for System.ServiceModel. Now we can add a service operation; called GetProductById(int productId). Each operation needs to have an OperationContract attribute. If this attribute is missing the operation will not be visible to WCF. The IProductService interface looks like this:

using System.ServiceModel;
using WcfServiceApplication.Domain;

namespace WcfServiceApplication.Contract
{
    [ServiceContract]
    public interface IProductService {

        [OperationContract]
        Product GetProductById(int productId);
    }
}

You will notice that the service operation returns a Product. I have defined this in the Domain folder. If an object is to be sent over the wire by WCF it needs to be attributed at the class level with DataContract and at the method level with DataMember (you will need to add a using statement for System.Runtime.Serialization) to indicate that the object can be serialised. I do not really want to get into the debate about returning Domain objects versus returning Data Transfer Objects from services at this stage as it doesn’t add much to the topic at hand. I will just say that for the purposes of this walk through I will use Domain objects, but for a non trivial application I would use DTO’s. The Product class looks like this:

using System.Runtime.Serialization;

namespace WcfServiceApplication.Domain
{
    [DataContract]
    public class Product
    {
        [DataMember]
        public int Id { getset; }

        [DataMember]
        public string Name { getset; }

        [DataMember]
        public string Description { getset; }
    }
}

Now we can implement the interface so the service can do something. I have given it a trivial implementation. In a real application the service would be responsible for doing something interesting such as performing some calculations or getting some data from somewhere.

using WcfServiceApplication.Contract;
using WcfServiceApplication.Domain;

namespace WcfServiceApplication.Implementation
{
    public class ProductService : IProductService
    {
        public Product GetProductById(int productId) {
            return new Product {
                                       Id = productId, 
                                       Name = "Product" + productId, 
                                       Description = "A nice product"
                               };
        }
    }
}

The next step is to tell the .svc file to use the new implementation we have created. Rename the file to productService.svc and edit the contents to point to the implementation.

<%@ ServiceHost Language="C#" Debug="true" 
    Service="WcfServiceApplication.Implementation.ProductService" %>

We only have the Web.config to go before we have a working service. Open Web.config and find the system.serviceModel section which contains the configuration for the WCF services.

In the system.serviceModel there are two further sections: services and behaviors.

Services – All services have their own section under services. There is just one right now which is incorrectly configured and we will fix things up as we go. The service has two attributes and one or more endoint elements:

  • name attribute – this should match the service attribute from the ProductService.svc, which is WcfServiceApplication.Implementation.ProductService.
  •  behaviorConfiguration attribute – this should match a service behaviour. We havent encountered one yet (its coming up in the behaviors section) so lets just change the value to WcfServiceApplication.ProductServiceBehavior in anticipation.
  • endpoints – As mentioned earlier, an endpoint is how a WCF service communicates with the outside world. A service can have one or more endpoints. Our example has two. Lets have a closer look at the first one.
    • address = “” – this is a relative address, which means that the address of this service will be relative to the base address. This is the most common address but can be different. It is also possible to add a base address if you want things to work differently. A good introduction can be found here.
    • binding=”wsHttpBinding” – a binding is used to define how to communicate with an endpoint. It has a protocol stack that determines things like security and reliability from messages sent to the endpoint. It describles the transport protocol to use when sending to the endpoint (HTTP, TCP etc). It also describes the encoding of the messages that are sent to the endpoint (text/xml etc). WCF has some binding to choose from that cover a variety of scenarios. We are using wsHttpBinding which offers good support for interoperation with other services that support the WS-* standards. Other bindings can be used depending on whether you need backwards compatibility with old asmx style services, or whether you want high performance when building WCF services that are also to be consumed by a WCF client for example. More information about bindings can be found here.
    • Contract – this should be changed to the location of the contract we created early, which is WcfServiceApplication.Contract.IProductService.

You may have noticed that this is the ABC of WCF I mentioned earlier. There is another endpoint with address=”mex”. This is to allow clients to be able to get the metadata for the service via SOAP calls. We can leave it in as we plan on using the metadata at a later stage. The services section now looks like this:

<services>
    <service name="WcfServiceApplication.Implementation.ProductService" behaviorConfiguration="WcfServiceApplication.ProductServiceBehavior">
      <endpoint address="" binding="wsHttpBinding" contract="WcfServiceApplication.Contract.IProductService">
        <identity>
          <dns value="localhost"/>
        </identity>
      </endpoint>
      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
    </service>
  </services>

Behaviors – This section can have a number of behaviours which can be applied to a service. Remember that we changed the behaviorConfiguration value and we need to change the name of the behavior to be the same to enable our service to find it. The behavior has two elements:

  • serviceMetadata httpGetEnabled=”true” – this enables metadata exchange and also allows the WSDL to be access by a special URL (which is the service url with ?wsdl at the end). You don’t always need metadata exchange, but we will be using it later.
  • serviceDebug includeExceptionDetailInFaults=”false” – do we want to show useful debugging info? The default is false and will keep it that way. This may be useful if you are debugging a service but should not be used in a production environement.

The behavior section now looks like this:

 <behaviors>
      <serviceBehaviors>
        <behavior name="WcfServiceApplication.ProductServiceBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>

Thats it. We are ready to run the service for the first time. The easiest way is using the WCF Test Client. highlight ProductService.svc in SolutionExplorer and hit F5. All being well WCF Test Client should load with the service visble. If you get any errors when you load the service it is very likely that there is a typo somewhere in either the files or the web.config.

Under the service you should be able to see the service along with the single service operation GetProductById(). Select the method to bring up the request and response panels for the method. You should be able to add a product Id (any number will do) and hit invoke to see the outcome.

That’s all there is to it. Of course there are a lot more configuration possibilities for more advanced scenarios, and we will cover some in future posts. In the next post I will cover how to create a client application to consume the WCF service we just created.

Posts in this series:

Dynamic Method Invocation in C# with PetaPoco (Part 2)

In Part 1 I looked at how PetaPoco used Dynamic Method Invocation to return a method that could convert an IDataReader column into a  Dynamic ExpandoObject. Now its time to look at the the other functionality used to return scalars and POCOs.

Scalars

In PetaPoco a scalar value is returned in the following way:

string column = db.ExecuteScalar<string>("SELECT Column FROM Table");

The functionality to create a factory to get the scalar values is part of the same GetFactory method covered in the previous post. I will pick up the method body when we already have the IlGenerator. After a check to see if the required type is a value type, a string or a Byte[] (indicating a scalar value) the method body is built up with IL. As before there is logic to perform some conversion for particular IDataReader implementations, and once again I am going to ignore it for the sake of brevity.

il.Emit(OpCodes.Ldarg_0);		// rdr
il.Emit(OpCodes.Ldc_I4_0);		// rdr,0
il.Emit(OpCodes.Callvirt, fnIsDBNull);	// bool

The first operations are the start of the if-statement to see if the value is null or not. First the IDataReader is pushed onto the stack then Ldc_I4_0 pushes on an int 0. As ExecuteScalar always returns the first column of the first row, this 0 represents column(0).  The Callvirt calls a previously defined MethodInfo for IDataRow.IsDBNull(). These three statements are the equivalent of r.IsDbNull(0). The result of this method call will be left on the top of the stack.

var lblCont = il.DefineLabel();
il.Emit(OpCodes.Brfalse_S, lblCont);
il.Emit(OpCodes.Ldnull);		// null

If the value on the top of the stack is false (indicating that the value returned from the IDataReader is not null the execution is branched to a label further in the execution. If it is true then null is pushed onto the top of the stack.

var lblFin = il.DefineLabel();
il.Emit(OpCodes.Br_S, lblFin);
il.MarkLabel(lblCont);
il.Emit(OpCodes.Ldarg_0);		// rdr
il.Emit(OpCodes.Ldc_I4_0);		// rdr,0
il.Emit(OpCodes.Callvirt, fnGetValue);	// value

After the null has been pushed to the stack a Br_S jumps to the lblFin label, which we will see in a moment. We can now pick up the execution from the lblCont label. Recall that we would branch to this point if the value is not null. Once again the IDataReader is pushed to the stack, followed by 0. We have encountered fnGetValue previously. It is a MethodInfo for IDataRecord.GetValue(i). It will be called on the IDataReader with the paramerter 0. This will leave the value on the top of the stack.

il.MarkLabel(lblFin);
il.Emit(OpCodes.Unbox_Any, type);       // value converted

Finally Unbox_Any is called on the value. This converts the object value to the unboxed type specified. It has the effect of casting the value from the IDataReader to the specified type. If the incorrect type had been specified in the ExecuteScalar method an InvalidCastExcpetion would be called at this point.

As before the value would be returned by il.Emit(OpCodes.Ret).

POCOs

Now its time for the main event, as POCO support is how PetaPoco came to have its name and is one of the key differentiators from similar micro ORMs.  Lets jump straight in.  We have already encountered many of the op codes and MethodInfo’s so we can pick up the pace a little.

// var poco=new T()
il.Emit(OpCodes.Newobj, type.GetConstructor(BindingFlags.Instance 
    | BindingFlags.Public | BindingFlags.NonPublic, nullnew Type[0], null));

// Enumerate all fields generating a set assignment for the column
for (int i = firstColumn; i < firstColumn + countColumns; i++)
{

The first thing is to push an instance of the the POCO type onto the stack with Newobj. Then its time to loop through the columns.

 // Get the PocoColumn for this db column, ignore if not known
 PocoColumn pc; if (!Columns.TryGetValue(r.GetName(i), out pc)) 
 continue;

PetaPoco is only interested in return columns from the IDataReader that are actually part of the POCO. Columns is a Dictionary holding the POCO property information. If there is not an entry in Columns for the current IDataReader column move onto the next.

 // Get the source type for this column
 var srcType = r.GetFieldType(i);
 var dstType = pc.PropertyInfo.PropertyType;

Next, get the source and destination types for the column.

il.Emit(OpCodes.Ldarg_0);		 // poco,rdr
il.Emit(OpCodes.Ldc_I4, i);		 // poco,rdr,i
il.Emit(OpCodes.Callvirt, fnIsDBNull);	 // poco,bool
var lblNext = il.DefineLabel();
il.Emit(OpCodes.Brtrue_S, lblNext);	 // poco

We have seen something very similar to this before, used to check if the IDataReader column is of type DBNull. If it is we branch to lblNext, which is directly before the end of the loop. This means that if the value is null in the database, no mapping to the POCO will take place.

il.Emit(OpCodes.Dup);			// poco,poco

var valuegetter = typeof(IDataRecord)
            .GetMethod("Get" + srcType.Name, new Type[] { typeof(int) });

Get a MethodInfo to call the required GetType method on the IDataReader.

if (valuegetter != null
    && valuegetter.ReturnType == srcType
    && (valuegetter.ReturnType == dstType 
        || valuegetter.ReturnType == Nullable.GetUnderlyingType(dstType)))
		{

Check if the return type from the valuegetter method is the same as the source type from the IDataReader, and that the return type is also the same as the underlying type. Nullable.GetUnderlyingType is used for the case where dstType is a Nullable type.

Once we have asserted that the mapping can take place we can start to build up the IL.

il.Emit(OpCodes.Ldarg_0);		// poco,poco,rdr
il.Emit(OpCodes.Ldc_I4, i);		// poco,poco,rdr,i
il.Emit(OpCodes.Callvirt, valuegetter);	// poco,poco,value

Get the value from the IDataReader using the MethodInfo defined above and put it on the top of the stack.

// Convert to Nullable
if (Nullable.GetUnderlyingType(dstType) != null)
{
    il.Emit(OpCodes.Newobj, 
    dstType.GetConstructor(new Type[] { Nullable.GetUnderlyingType(dstType) }));
}

If the destination type (the POCO column) is a Nullable type, then convert the value from the IDataReader to the nullable version of the type. The code within the if-statement is equivalent to T? x = new T?(value). The stack is now poco, poco, value.

il.Emit(OpCodes.Callvirt, pc.PropertyInfo.GetSetMethod(true));	// poco
il.MarkLabel(lblNext);
}

Finally, the property setter for the poco property is called with the value. The poco with the assigned value is left on the stack and the process is repeated with the next column.

When all the columns has been processed there is one final thing to do before we return the POCO.

var fnOnLoaded = RecurseInheritedTypes<MethodInfo>(type, 
        (x) => x.GetMethod("OnLoaded"BindingFlags.Instance | BindingFlags.Public 
            | BindingFlags.NonPublic, nullnew Type[0], null));

if (fnOnLoaded != null)
{
    il.Emit(OpCodes.Dup);
    il.Emit(OpCodes.Callvirt, fnOnLoaded);
}

Look for an OnLoaded method somwewhere in the POCO type inheritance hierarchy. If the method is present then call it on the POCO to signify that the POCO has been loaded.

il.Emit(OpCodes.Ret);

Finally return the POCO complete with the values from the IDataReader.

I would definately suggest having a look at the PetaPoco source. There are lots of interesting techniques to discover.