ploeh blog : Services

Faking The Windows Azure Table Service

ploeh — Sat, 24 Jan 2009 13:21:36 GMT

When presented with a new technology, one of my primary evaluation criteria is its testability, so it should come as no surprise to the regular reader of this blog that this was also foremost in my mind when Windows Azure was presented at PDC. Much of the Azure Services Platform is just .NET, so testability is really up to you, just like with all other .NET code.

However, when it comes to the Windows Azure storage, the developer story is different. The Windows Azure Table Service is essentially a REST-based service, and to use it, you'll need to install the Azure Visual Studio SDK.

That's not a problem in itself, but it seems to be implemented as a REST service on top of SQL Server Express. While that may be good enough for casual development, that's quite heavyweight for unit testing. Imagine having to somehow deal with populating and cleaning this database between each test case. That will likely involve a fair amount of complex and undocumented Back Door Manipulation. As the service is out of process in relation to the test, this is brittle and slow, so a better approach is warranted.

Fortunately, I've already demonstrated how to Fake a REST-based Data Service, so faking the Windows Azure Table Service turns out to be fairly easy, and generally follows the same steps as previously outlined.

In the following example, I'm working with a simple service that echoes messages back to the caller. The Delay method saves the input message in table storage and returns the previous message from storage. This test verifies that the input message is being correctly saved:

[TestMethod]

public void DelayWillSaveMessage()

    // Fixture setup

    string expectedMessage = "Anonymous text";

    Uri address = new Uri("http://localhost/EchoService");

    FakeDataService<MessageContainer> service =

        new FakeDataService<MessageContainer>(

            new MessageContainer());

    using (WebServiceHost host =

        new WebServiceHost(service, new[] { address }))

        host.Open();

        StorageAccountInfo account =

            EchoFacadeTest.GetAccount();

        EchoFacade sut = new EchoFacade(() => account);

        // Exercise system

        sut.Delay(expectedMessage);

        // Verify outcome

        Assert.AreEqual<string>(expectedMessage,

            service.Container.GetStore<FakeMessage>().

            First().Message, "Delay");

        // Teardown

In the EchoFacade service, I've used the SDK sample StorageClient library that extents the ADO.NET Data Services Client API to deal with the particulars of Windows Azure Table Storage. One difference from regular ADO.NET Data Services lies in how StorageClient deals with the base URIs of the REST interface. This is a challenge, because a URI like http://localhost/EchoService is interpreted as a service at the address localhost belonging to the account EchoService.

This has the implication that I can't just pass the complete address directly to the client API (i.e. EchoFacade), since it would need to decompose it before it can make proper use of it. Fortunately, such a decomposition already exists in the form of the StorageAccountInfo class, so I just need to pass a properly configured instance to my SUT to make it work.

The test accomplishes this task like this:

private static StorageAccountInfo GetAccount()

    Uri address = new Uri("http://localhost/");

    return new StorageAccountInfo(address, true,

        "EchoService", EchoFacadeTest.TableKey);

When the service is hosted in the full system (whether in the Development Fabric or on Azure proper), the StorageAccountInfo instance is instead initialized using the static StorageAccountInfo.GetDefaultTableStorageAccountFromConfiguration method.

If you are using the StorageClient library for your data access code, you might as well also take advantage of it when defining the fake service. First of all, you can derive the entities exposed from the Fake service from TableStorageEntity, as this gives you the key properties for free.

public class FakeMessage : TableStorageEntity

    public FakeMessage()

        this.CreationTime = DateTime.Now;

    public DateTime CreationTime { get; set; }

    public string Message { get; set; }

The DataContainer then becomes equally simple:

public class MessageContainer : DataContainer

    public IQueryable<FakeMessage> Messages

get

            return this.GetStore<FakeMessage>().

                AsQueryable();

Using a Fake ADO.NET Data Service enables you unit test clients of the Windows Azure Table Service in a light-weight manner.

In this Fake, I have chosen not to deal with the Windows Azure Table Service's particular way of partitioning and sorting data according to PartitionKey and RowKey. Instead, I just rely on the Fixture of each test to insert the data entities in the expected order.

A General-Purpose Fake ADO.NET Data Service

ploeh — Tue, 20 Jan 2009 10:10:00 GMT

In my previous post, I discussed how to implement a Fake ADO.NET Data Service for use with unit testing, showing how you can develop a one-off service that addresses specific needs, such as querying parents and children in the example.

As I hinted in that post, it's possible to create a reusable Fake ADO.NET Data Service that takes care of implementing IUpdatable based on in-memory data storage. To save you the trouble of doing that, I've created one that you can use, if you should so desire.

Following the standard ADO.NET Data Service coding idiom, the Fake ADO.NET Data Service consists of two classes:

FakeDataService<T>, which derives from DataService<T>. This is simply the counterpart of MyDataService from the previous example. You can use this class as is.
DataContainer, which implements IUpdatable. Although I haven't made this class abstract, it only becomes useful when you derive from it and define your own queries.

Let's say that I want to use these two classes to unit test the same service client as in the previous example. Instead of MyService (where I manually had to implement IUpdatable), I can now define my data container as simply as this:

public partial class ParentChildContainer : DataContainer

    public IQueryable<Child> Children

get

            return this.GetStore<Child>().AsQueryable();

    public IQueryable<Parent> Parents

get

            return this.GetStore<Parent>().AsQueryable();

The only thing you have to do is just derive from DataContainer and specify your queries.

Although you don't have to use FakeDataService<T> to host your Fake DataContainer, it makes it easy to set up the Fake service in a unit test:

[TestMethod]

public void TestCanSetupFakeService()

    // Fixture setup

    Uri address = new Uri("http://localhost/MyDataService");

    FakeDataService<ParentChildContainer> service =

        new FakeDataService<ParentChildContainer>(

            new ParentChildContainer());

    using (WebServiceHost host =

        new WebServiceHost(service, new[] { address }))

        host.Open();

        // Exercise system

        // ...

        // Verify outcome

        // ...

        // Teardown

How does this work? DataContainer stores each 'table' in a List<T>, and each list is again stored in a dictionary that maps the list to the type. Here's the part of DataContainer that doesn't contain the IUpdatable implementation:

public partial class DataContainer

    private readonly Dictionary<Type, IList> stores;

    public DataContainer()

        this.stores = new Dictionary<Type, IList>();

    public IList<T> GetStore<T>()

        if (!this.stores.ContainsKey(typeof(T)))

            this.AddStore<T>();

        return (IList<T>)this.stores[typeof(T)];

    private void AddStore<T>()

        this.stores.Add(typeof(T), new List<T>());

When you call GetStore<T>, DataContainer implicitly creates the list for the give type if it doesn't already exist.

The rest of DataContainer deals with implementing IUpdatable:

#region IUpdatable Members

public void AddReferenceToCollection(object targetResource,

    string propertyName, object resourceToBeAdded)

    IList list = (IList)targetResource.GetType().

        GetProperty(propertyName).

        GetValue(targetResource, null);

    list.Add(resourceToBeAdded);

public void ClearChanges()

public object CreateResource(string containerName,

    string fullTypeName)

    Type t = this.ResolveType(fullTypeName);

    object resource = Activator.CreateInstance(t);

    this.stores[t].Add(resource);

    return resource;

public void DeleteResource(object targetResource)

    foreach (IList list in this.stores.Values)

        list.Remove(targetResource);

public object GetResource(IQueryable query,

    string fullTypeName)

    return query.Cast<object>().AsEnumerable().

        FirstOrDefault();

public object GetValue(object targetResource,

    string propertyName)

    return targetResource.GetType().

        GetProperty(propertyName).

        GetValue(targetResource, null);

public void RemoveReferenceFromCollection(

    object targetResource,

    string propertyName,

    object resourceToBeRemoved)

    IList list = (IList)targetResource.GetType().

        GetProperty(propertyName).

        GetValue(targetResource, null);

    list.Remove(resourceToBeRemoved);

public object ResetResource(object resource)

    return resource;

public object ResolveResource(object resource)

    return resource;

public void SaveChanges()

public void SetReference(object targetResource,

    string propertyName, object propertyValue)

    targetResource.GetType().GetProperty(propertyName).

        SetValue(targetResource, propertyValue, null);

public void SetValue(object targetResource,

    string propertyName, object propertyValue)

    targetResource.GetType().GetProperty(propertyName).

        SetValue(targetResource, propertyValue, null);

#endregion

private Type ResolveType(string fullTypeName)

    return (from t in this.stores.Keys

            where t.FullName == fullTypeName

            select t).First();

If you find this useful, I've attached the code to this post for your downloading pleasure. As always, the standard disclaimers apply.

Creating A Fake ADO.NET Data Service

ploeh — Mon, 19 Jan 2009 11:00:00 GMT

Previously, I discussed unit testing ADO.NET Data Service clients using a Fake ADO.NET Data Service, and I promised to demonstrate how to create such a service. In this article I will continue the previous example and implement the Fake MyService class.

The basics of MyService is pretty simple:

public partial class MyService

    public MyService()

        this.ParentStore = new List<Parent>();

        this.ChildStore = new List<Child>();

    public IQueryable<Child> Children

        get { return this.ChildStore.AsQueryable(); }

    public IQueryable<Parent> Parents

        get { return this.ParentStore.AsQueryable(); }

    public IList<Child> ChildStore { get; private set; }

    public IList<Parent> ParentStore { get; private set; }

This service supports two 'tables': Parents and Children (Parents can have Children). Since this is a Fake, it only needs to store its data in memory, so I use two List<T> instances for that. To provide direct access to the service's data, MyService exposes both lists as public properties (you can make those properties internal if your Fake service is defined in the same assembly as your tests).

This is all you need if you only need to support read-only scenarios. If the client you want to test only queries its service, you don't need to do anything else. On the other hand, if you also need to test Create, Update and Delete (CUD) operations, you will need to implement IUpdatable:

public partial class MyService : IUpdatable

Implementing this interface enables you to support CUD operations. Since it contains twelve members, I'm not going to walk you through each and every one of them, but rather present some highlights. If you are interested in more details on the methods of this interface, I'll recommend this post on the Project Astoria Team Blog.

To support each of the simple CUD operations, multiple methods must be implemented, although there's an overlap.

To create a new item, the first method to implement is CreateResource.

public object CreateResource(string containerName,

    string fullTypeName)

    switch (containerName)

        case "Parents":

            Parent p = new Parent();

            this.ParentStore.Add(p);

            return p;

        case "Children":

            Child c = new Child();

            this.ChildStore.Add(c);

            return c;

        default:

            throw new ArgumentException(

                "Unknown container name.");

This implementation simply creates a new instance of the requested item type and adds it to the in-memory list. Here, I was just being a bit lazy and simply switched on the containerName, but it's perfectly possible to create a more generic implementation using a bit of Reflection, since the fullTypeName parameter specifies which type of object to create.

The CreateResource method's responsibility is to create a default instance of the requested type and add it to the underlying data store (in this case just an in-memory list). However, it doesn't assign values to the item's properties, since this is the duty of the SetValue method.

public void SetValue(object targetResource,

    string propertyName, object propertyValue)

    Type t = targetResource.GetType();

    t.GetProperty(propertyName).SetValue(

        targetResource, propertyValue, null);

At this point, I found it easier to implement the method using Reflection than explicitly switching on both the targetResource and propertyName parameters.

The last method that must be implemented to support the Create scenario is ResolveResource.

public object ResolveResource(object resource)

    return resource;

Since the Fake service is already working with in-memory objects, it can just return the object itself.

With these methods implemented, updating an item is not quite as involved, since it reuses the SetValue and ResolveResource methods, so I only need to implement the GetResource method.

public object GetResource(IQueryable query,

    string fullTypeName)

    return query.Cast<object>().AsEnumerable().

        FirstOrDefault();

This implementation requires a bit of explanation. The query argument that the method receives is actually an expression over the service's exposed queries (i.e. Parents and Children). Since the service operates on in-memory objects, it doesn't need to transform the expression, but can simply evaluate it directly, which is what the AsEnumerable extension method does. However, IQueryable doesn't have an AsEnumerable extension method, whereas IQueryable<T> does - hence the cast to object.

Deleting an item reuses GetResource and ResolveResource, so to support this scenario, the DeleteResource method is the only extra method that must be implemented.

public void DeleteResource(object targetResource)

    ((IList)this.ParentStore).Remove(targetResource);

    ((IList)this.ChildStore).Remove(targetResource);

Once again, I decided to keep things simple and simply hard-code knowledge of ParentStore and ChildStore into the method, but it would be easy to generalize this approach.

The rest of the methods of IUpdatable address more advanced scenarios concerning references between items, and I'm not going to cover them in this post, since it's already becoming quite long. If you are interested, I've provided the entire sample code as an attachment to this post, so download and peruse it at your leisure (obviously, the usual disclaimers apply).

Update: I've now posted a general-purpose Fake ADO.NET Data Service that should hopefully address most of your needs.

Unit Testing ADO.NET Data Service Clients

ploeh — Wed, 14 Jan 2009 18:51:13 GMT

In my previous post, I discussed unit testing ADO.NET Data Services and how you can host and test the service itself. In this post, I'll take a look at the opposite scenario: You have a client of an ADO.NET Data Service, and you want to unit test the client without relying on the real, production service.

In other words, you want to test the real client against a Test Double service. Presently, I'll show you how to create and host a Fake ADO.NET Data Service that the client code can invoke. Obviously, the client in this example uses the ADO.NET Data Services Client API, so I'll demonstrate how you can use that to invoke the fake service from within the same test.

Before we dive into the specifics of the implementation, here's a simple test that verifies that the client can retrieve all Parent instances from the service:

As you can see from the figure, the test combines two logical tiers into one test: The service and the client.

The service tier is simply part of the test's Fixture, and while I'm not concerned with testing it in this context, I still need to set it up. This part uses the ADO.NET Data Services API to define and host the service.

The client part uses the ADO.NET Data Services Client API to query the service via its REST interface and verify the result.

Notice that I use an instance of MyDataService to configure the host. While not strictly necessary in this test, when hosting a Fake service, it's desirable to have a reference to the fake instance itself, since that allows you to configure and query it through its Back Door. Here's a test that uses the MyDataService instance to verify that a Parent instance was deleted from the service:

[TestMethod]

public void ClientCanDeleteInstance()

    // Fixture setup

    Uri address = new Uri("http://localhost/MyDataService");

    MyDataService service = new MyDataService();

    using (WebServiceHost host =

        new WebServiceHost(service, new[] { address }))

        host.Open();

        MyDataServiceContext ctx =

            new MyDataServiceContext(address);

        var victim = (from p in ctx.Parents

                      where p.Id == 3

                      select p).Single();

        // Exercise system

        ctx.DeleteObject(victim);

        ctx.SaveChanges();

        // Verify outcome

        Assert.IsFalse(service.Data.Parents.Any(

            p => p.Id == victim.Id), "Deleted");

        // Teardown

As in the previous example, all Fixture Setup before the declaration of the MyDataServiceContext instance is part of the logical service tier, while the remaining Fixture Setup code, as well as the execution of the SUT is part of the logical client tier. However, notice that the verification now takes place on the logical service tier, since I'm using the fake service instance as a Back Door, instead of relying on the REST interface to query the service.

Since DataServiceHost doesn't include a constructor that takes a single instance as a parameter, I use its base class WebServiceHost instead. Reflector shows that DataServiceHost really adds no behavior to its base class, so using WebServiceHost as a host should be safe - for now (let's hope it stays that way, or even better, that it gets a constructor overload that accepts a service instance).

In normal cases, I consider it best practice to explicitly load data into the fake service as part of the Fixture Setup phase, but to keep these examples simple, I decided to implicitly load some test data as part of creating the MyDataService instance. That is why, in the above example, I can successfully retrieve a Parent instance with an Id of 3. Please be aware that this is not a strategy I endorse - I only did it to keep the example a bit less complex.

Here's the MyDataService class in its entirety:

[ServiceBehavior(IncludeExceptionDetailInFaults = true,

    InstanceContextMode = InstanceContextMode.Single)]

public class MyDataService : DataService<MyService>

    private readonly MyService service_;

    public MyDataService()

        this.service_ = new MyService();

        IList<Parent> ps = this.service_.ParentStore;

        ps.Add(new Parent() { Id = 1, Text = "Ploeh" });

        ps.Add(new Parent() { Id = 2, Text = "Fnaah" });

        ps.Add(new Parent() { Id = 3, Text = "Ndøh" });

        ps.Add(new Parent() { Id = 4, Text = "Foo" });

        ps.Add(new Parent() { Id = 5, Text = "Bar" });

        IList<Child> cs = this.service_.ChildStore;

        cs.Add(new Child() { Id = 1, Text = "Child 1" });

        cs.Add(new Child() { Id = 2, Text = "Child 2" });

        cs.Add(new Child() { Id = 3, Text = "Child 3" });

    public MyService Data

        get { return this.service_; }

    public static void InitializeService(

        IDataServiceConfiguration config)

        config.SetEntitySetAccessRule("*",

            EntitySetRights.All);

        config.UseVerboseErrors = true;

    protected override MyService CreateDataSource()

        return this.service_;

As I described, I use the constructor to set up some implicit test data. While I want to reiterate that this is not something I would recommend, I chose to include this code to make it clear what I was talking about.

The service is decorated with the ServiceBehavior attribute, which sets its InstanceContextMode to Single to allow it to be hosted as a Singleton service by WebServiceHost. This, again, is what allows me to query the fake service's data via its Back Door.

Since MyService simply stores data in memory, MyDataService needs to keep the same instance around for each request, so it overrides CreateDataSource to ensure that the same data container instance is always being referenced for the lifetime of the instance.

In a later post, I will describe how to create the fake data service, MyService.

Unit Testing ADO.NET Data Services

ploeh — Tue, 13 Jan 2009 15:05:00 GMT

ADO.NET Data Services enables you to expose data (including, but not limited to, relational data) as REST services. Since it's built on top of WCF, it can be tested utilizing similar techniques, but allow me to elaborate a bit on the subject.

As with WCF, you might be interested in testing one or both tiers:

The service
The client

Testing the service is the simplest undertaking, so I'll start with that and return to testing the client in a later post.

Why would you want to unit test an ADO.NET Data Service?

The mainstream scenario for ADO.NET Data Services is to expose a relational database using an ADO.NET Entity Model. Is it relevant to unit test such a service? Perhaps not. It depends on the amount of code you inject into the generated (partial) classes. If the amount of custom code is minimal, it may not make much sense to test simple CRUD operations.

Conversely, if you have a greater degree of custom code, or if you implement an ADO.NET Data Service using non-relational data, it makes a lot of sense.

My loyal readers will probably (correctly) suspect that I would tend to expose a Façade over a Domain Model as a data service, which implies going the non-relational route (even if the underlying data store is, in fact, relational). That is also the context for the rest of this post.

First of all, you should keep in mind that the data service is just a normal class, so you can test much of its functionality by just creating it and start using it:

[TestMethod]

public void ServiceCanReturnRequestedItem()

    // Fixture setup

    int anonymousId = 3;

    string expectedText = "Ploeh";

    Parent anonymousParent = new Parent();

    anonymousParent.Id = anonymousId;

    anonymousParent.Text = expectedText;

    MyService sut = new MyService();

    sut.ParentStore.Add(anonymousParent);

    // Exercise system

    Parent result = (from p in sut.Parents

                    where p.Id == anonymousId

                    select p).Single();

    // Verify outcome

    Assert.AreEqual<string>(expectedText, result.Text,

        "Text");

    // Teardown

Notice how most of the test just contains code setting up the Fixture by adding the relevant data to the service's underlying data store, while execution and verification is quickly accomplished.

At some point, however, you will probably want to test the service through its REST interface. To do this, you must host the service within the test and then invoke it.

Hosting the service in a test is easy:

[TestMethod]

public void TestCanHostService()

    // Fixture setup

    Uri address = new Uri("http://localhost/MyDataService");

    using (DataServiceHost host =

        new DataServiceHost(typeof(MyDataService),

            new[] { address }))

        host.Open();

        // Exercise system

        // ...

        // Verify outcome

        // ...

        // Teardown

Since the service is exposed through a REST interface, you can use more than one technology to invoke it. The ADO.NET Data Services client API is a natural fit, and I'll cover this in a later post. For now, just imagine that the test above contains client code that invokes the service and verifies the result.

As it turns out, unit testing an ADO.NET Data Service isn't particularly difficult. Unit testing ADO.NET Data Service Clients is a bit more involved, so I'll cover that topic in a separate post. Update: This post is now available here.

Creating Azure Tables From Script

ploeh — Thu, 04 Dec 2008 15:04:00 GMT

When working with the Windows Azure Storage service, you must create the tables before you can use them; in essence, defining the 'schema' of your Azure storage service.

On his blog, Steve Marx writes:

"Probably the best solution is to have separate initialization code that creates your tables. This is analogous to the pattern of having CREATE TABLE commands scripted in T-SQL which you run once to set up the database."

I can only agree, but if you are relying on the CreateTablesFromModel method from the StorageClient data access API (from the Azure SDK), how can you do that?

The first thing to realize is that since you can connect to your Azure Storage Service from anywhere, the script does not need to execute in the cloud. You can just as well run this script from your local development machine, as long as you can connect to your storage account.

You could obviously write a little utility that references StorageClient and your custom TableStorageDataServiceContext.

Another, in my opinion, better option for such a one-off script is a PowerShell script. Here's my first take on such a script:

$address = "http://table.core.windows.net"

$account = <accountName>

$accessKey = <accessKey>

$storageClientPath = <storageClientPath>

$contextPath = <contextPath>

[System.Reflection.Assembly]::LoadFrom($storageClientPath)

[System.Reflection.Assembly]::LoadFrom($contextPath)

$ai = New-Object Microsoft.Samples.ServiceHosting.StorageClient.StorageAccountInfo($address, $null, $account, $accessKey)

$dataContext = New-Object <customContext>($ai)

$t = $dataContext.GetType()

$ts = [Microsoft.Samples.ServiceHosting.StorageClient.TableStorage]::Create($ai)

$ts.ListTables() | % { $ts.DeleteTable($_) }

[Microsoft.Samples.ServiceHosting.StorageClient.TableStorage]::CreateTablesFromModel($t, $ai)

First of all, you will need to fill in the values that I've enclosed in angle brackets (remember quotes):

accountName is the name of your Windows Azure Storage account
accessKey is your Windows Azure Storage access key
storageClientPath is the full path to the StorageClient assembly, e.g. "C:\Program Files\Windows Azure SDK\v1.0\Samples\StorageClient\Lib\bin\Debug\StorageClient.dll"
contextPath is the full path to the assembly that contains your custom TableStorageDataServiceContext
customContext is the fully qualified type name of your custom context (see the update comment below)

This script does the following:

It loads the StorageClient and your custom assembly into memory so types from those assemblies can be consumed by the script.
It loops through all the tables currently in storage and deletes them (delete the penultimate line if you don't want it to do this)!
It creates the tables from your data model.

Currently, the script has one limitation: Deleting a table using the StorageClient API only marks the table for deletion, so the operation returns much to soon. This means that if you are trying to recreate a table by the same name, a conflict will occur, and the table will not be created. You can work around this limitation by waiting a little while and then run the script again.

Update: In the original version of this post, I accidentally forgot to remove the specific type name of the custom context class that I'd used to create the script. Since you will not have access to that class, it doesn't make sense, so I replaced it with the customContext placeholder.

In case you were wondering, the original line of code was:

$dataContext = New-Object Microsoft.Dynamics.Mobile.Server.AzureDataAccess.MobileServerDataServiceContext($ai)

UAC Privileges Flow Across WCF Boundaries

ploeh — Sat, 25 Oct 2008 01:05:16 GMT

Today, I just spent an entire afternoon troubleshooting a problem in one of my WCF services. When the solution finally dawned on me, it was so simple that I wanted to kick myself, so I thought that by sharing my experience, I might spare you the agony.

In short, the setup was this: I had just developed a custom ServiceAuthorizationManager that basically just used WindowsPrincipal.IsInRole to test whether the caller (authenticated with Windows Authentication) was a member of .\Administrators.

I had already set it up on three of my four services, and it just worked as it should. On the fourth, however, it didn't.

It was the same code running on all four services, and using the debugger, I could tell that in all four cases, the WindowsPrincipal in question represented my own account. However, in the first three services, IsInRole(".\Administrators") returned true as expected, whereas it returned false in the fourth service.

Even more strange, the fourth service exhibited expected behavior if IsInRole was called against Domain Users, or similar groups.

As far as I could tell, there was no significant differences in the WCF bindings and behaviors for the four services, but since WCF is pretty complex, I spent a lot of time comparing these without finding the reason.

It finally occurred to me that I was running my little test application for the fourth service in non-elevated mode, and since I was running on Windows Server 2008, the process didn't have administrator privileges because of UAC. That I knew, but it had never crossed my mind that this non-elevated mode flows across WCF boundaries, so even though the service wasn't impacted by UAC itself, the Windows credentials that represented my account was.

When I restarted my test tool in elevated mode, everything worked as expected.

It was my luck that I already had three working services when I ran into this issue; had I hit it on the first service, I might have concluded that my entire approach was unsound.

N-Tier Synchronization With The Sync Framework And WCF ChannelFactory (Part 2)

ploeh — Wed, 27 Aug 2008 21:23:17 GMT

In my previous post, I discussed using ServerSyncProviderProxy with ChannelFactory<T>, and explained how you can get up and running with that combination. While the described modification is definitely necessary, there's at least one other caveat that I've encountered so far.

ChannelFactory<T> implements both ICommunicationObject and IDisposable, and it's necessary to properly close an instance. A ChannelFactory<T> instance and any proxies that it creates are connected, and closing the ChannelFactory<T> instance will also close the proxies. However, that's not true the other way around.

ServerSyncProviderProxy itself implements IDisposable, and it properly disposes of the proxy passed to it, but since it has no knowledge of the ChannelFactory used to create the proxy, it's not going to dispose of that.

This causes the ServerSyncProviderProxy to hang (and ultimately time out) when you try to dispose of it.

Lesson #2

When using proxies created by ChannelFactory<T>.CreateChannel, you must manually ensure that the ChannelFactory is properly disposed when the SyncAgent disposes. Fortunately, that's not very hard to do; it just requires you to hold a reference to it in your derived SyncAgent and create it like this:

this.syncServiceFactory =

    new ChannelFactory<ISyncService>(binding, serviceAddress.ToString());

ISyncService proxy = this.syncServiceFactory.CreateChannel();

this.RemoteProvider = new ServerSyncProviderProxy(proxy);

Subsequently, you need to ensure that it's being properly disposed together with the SyncAgent itself:

protected override void Dispose(bool disposing)

    base.Dispose(disposing);

    if (disposing)

        this.syncServiceFactory.Close();

This will allow the SyncAgent and, implicitly, the ServerSyncProviderProxy to close immediately.

N-Tier Synchronization With The Sync Framework And WCF ChannelFactory (Part 1)

ploeh — Tue, 26 Aug 2008 22:01:00 GMT

Sync Services for ADO.NET 2.0 allows a proper n-tier architecture where you can synchronize a client with a back-end data store via a web service. To do this, your web service must expose a simple interface consisting of four operations. As described in the documentation, one of these operations must have the following signature:

[OperationContract]

SyncSchema GetSchema(Collection<string> tableNames, SyncSession syncSession);

When used in a SyncAgent, a proxy is used with ServerSyncProviderProxy like this:

this.RemoteProvider = new ServerSyncProviderProxy(proxy);

One thing to notice about the ServerSyncProviderProxy constructor is that it takes as input any object (that is, an instance of System.Object). Obviously, you can't just pass in any object and expect it to work at run-time, so there's actually a sort of duck typing in play here.

As far as I can tell, ServerSyncProviderProxy uses Reflection to invoke the expected methods, such as the GetSchema method shown above.

That probably works well for a WCF proxy generated by Visual Studio (I don't know, because I haven't tried), but fails if you try to reference the service interface (let's call it ISyncService) directly and create a proxy using ChannelFactory<T>.CreateChannel.

ChannelFactory<ISyncService> cf =

    new ChannelFactory<ISyncService>(binding, serviceAddress.ToString());

ISyncService proxy = cf.CreateChannel();

this.RemoteProvider = new ServerSyncProviderProxy(proxy);

If you do that, you will get a run-time exception. What happens is that ServerSyncProviderProxy expects the GetSchema method to take a string[], not a Collection<string>. Although I have no authoritative explanation for this, it's not that surprising, since the default proxy code generator for WCF (svcutil, Visual Studio) will create proxies with lists of elements represented by arrays - you have to explicitly state that you want collections instead, if that's the case.

Lesson #1

If you want to create a proxy instance using ChannelFactory<T>, you will have to change the signature of the GetSchema method to

[OperationContract]

SyncSchema GetSchema(string[] tableNames, SyncSession syncSession);

That will enable you to use a proxy created by ChannelFactory<T>, but will obviously break for proxies generated by svcutil or Visual Studio. If you must support both scenarios, you will need to derive from ServerSyncProviderProxy and override the GetSchema method to do something more intelligent.

Update (2008-08-27): Part 2 is now available here.

An Overview of Unit Testing Duplex WCF Services and Clients

ploeh — Sat, 12 Jul 2008 08:50:00 GMT

In the last couple of posts, I've demonstrated how to isolate implementation from WCF contract definition and behavior in a duplex communication scenario. These posts have been rather detailed, so it occurred to me that you might benefit from an overview.

The main goal was to ensure testability of implementations of both service and client. While the contracts reference WCF (System.ServiceModel), the implementations themselves only reference the contracts, and not WCF.

This diagram illustrates dependencies between the various libraries. The left side contains server-side components, while the right side contains client-side components. The only shared components are WCF and the Contract library.

Note that neither StuffServer nor StuffAgent has any dependency on System.ServiceModel, although they have a dependency on Contract. The same is true for both unit test projects.

The top boxes on both sides (MyServer and MyClient) are hypothetical top-level executables such as I've discussed before, although never shown any code from. These Humble Executables tie everything together by referencing all relevant libraries, but if you prefer, you can just as well use a configurable Dependency Injection container - Oran Dennison explains how to do this on Spring.NET, while Ayende has a Windsor ServiceHostFactory.

Here are the main posts on the subject:

If you would like to take a closer look at my sample code, I've attached it to this post. As usual, the standard disclaimers apply.

Unit Testing Duplex WCF Clients

ploeh — Wed, 09 Jul 2008 00:06:00 GMT

In my previous post, I explained how to unit test a WCF service with callbacks. Since the scenario involves duplex communication, the service is also a client, and vice versa, so it's only reasonable to look at the 'client' as well, to examine how to best approach unit testing such a beast.

Since both ends both act as sender and receiver, they are each both client and service. None the less, there's still a clear distinction, since the client is the party that initiates and terminates a session, whereas the service is always ready and available for whatever client that may come along.

Ensuring proper isolation and testability is most difficult for the service, which was why I decided to tackle that issue first. Making the client testable is much easier, and I'll describe how to do that here by continuing the example from my former post.

When writing the client, the only thing I really need to abstract away is the creation of the WCF proxy and its callback instance.

When you look at the standard WCF documentation for duplex clients, a duplex proxy can be created by a DuplexChannelFactory<TChannel> like this:

DuplexChannelFactory<IStuffService> cf =

    new DuplexChannelFactory<IStuffService>(callbackService,

        binding, remoteAddress);

You can then invoke CreateChannel on the cf instance to get an instance of an IStuffService proxy.

However, now that you have decided to implement your client without any reference to WCF, the use of DuplexChannelFactory<TChannel> and its ilk from within that library is not permitted (and should indeed be impossible, since you don't have a reference to System.ServiceModel).

What the client really needs is something that can create an instance of an IStuffService proxy, while itself receiving an instance of IStuffCallbackService (which is the type of the callbackService parameter above). In other words, I'll need to define an abstraction that takes IStuffCallbackService as input and returns IStuffService.

In a move very similar to the approach described previously, a Func<IStuffCallbackService, IStuffService> is just what we need. Hence, a rudimentary implementation of StuffClient would be similar to this:

public class StuffClient : IStuffCallbackService

    private readonly Func<IStuffCallbackService, IStuffService> createProxy_;

    public StuffClient(Func<IStuffCallbackService, IStuffService> proxyCreator)

        if (proxyCreator == null)

            throw new ArgumentNullException("proxyCreator");

        this.createProxy_ = proxyCreator;

    public void DoStuff(string stuff)

        IStuffService proxy = this.createProxy_(this);

        proxy.DoStuff(stuff);

        // Remeber to safely dispose of proxy

    // Other members, including IStuffCallbackService Members...

The abstract proxy creator is required by way of Constructor Injection, and is used in the DoStuff method to create an IStuffService proxy instance, which may or may not be a WCF proxy.

If the proxy instance is a real WCF proxy, it will implement IDisposable and should be properly closed. There are several strategies for dealing with this situation, but to keep the example as simple as possible, I've chosen to omit this particular aspect, and leave it as an exercise for the interested reader :)

Although I have yet to show the actual implementation, note that StuffClient implements IStuffCallbackService, so it can return itself to the createProxy_ delegate instance as the callback service. Obviously, if you use the same object as both sender and receiver, you need to do so in a thread-safe manner, but since I can, in this particular context, bask in the luxury of writing sample code, I choose to ignore thread-safety completely :)

#region IStuffCallbackService Members

public void StuffWasDone(string result)

    this.stuffResults_.Add(result);

#endregion

where stuffResults_ is a List<string>.

Unit testing StuffClient is now fairly simple. We'll need an implementation of IStuffService to act as a Test Double, so I've created a simple SpyStuffService class that records all the stuff strings in a List<string> called Stuffs.

First of all, we need to ensure that the proxyCreator delegate instance receives a proper instance of IStuffCallbackService as input:

[TestMethod]

public void DoStuffWillCreateProxyByPassingNonNullCallback()

    // Fixture setup

    string anonymousStuff = "ploeh";

    SpyStuffService dummy = new SpyStuffService();

    StuffClient sut = new StuffClient(callbackService =>

            Assert.IsNotNull(callbackService,

                "Callback service");

            return dummy;

});

    // Exercise system

    sut.DoStuff(anonymousStuff);

    // Verify outcome (done by inline mock);

    // Teardown

A bit unusually, test verification happens inside the delegate defined by the lambda expression passed to the constructor of StuffClient - a technique I call an Inline Mock. Since C# is strongly typed, I can be assured that if callbackService is not null, it will be an instance of IStuffCallbackService.

Next, we may want to verify that when DoStuff is invoked, data will be transferred to the service:

[TestMethod]

public void DoStuffWillSendStuffToService()

    // Fixture setup

    string expectedStuff = "ploeh";

    SpyStuffService spy = new SpyStuffService();

    StuffClient sut =

        new StuffClient(callbackService => spy);

    // Exercise system

    sut.DoStuff(expectedStuff);

    // Verify outcome

    Assert.AreEqual<string>(expectedStuff,

        spy.Stuffs.First(), "Stuff");

    // Teardown

The Spy is passed to the SUT in the constructor, and later inspected in the verification phase. Pretty classic four-phase unit test setup...

Finally, we may want to test the SUT's implementation of IStuffCallbackService:

[TestMethod]

public void StuffWasDoneWillAddResultToStuffResultList()

    // Fixture setup

    string expectedStuff = "ploeh";

    SpyStuffService dummy = new SpyStuffService();

    StuffClient sut =

        new StuffClient(callbackService => dummy);

    // Exercise system

    sut.StuffWasDone(expectedStuff);

    // Verify outcome

    Assert.AreEqual<string>(expectedStuff,

        sut.StuffResults.First(), "Stuff result");

    // Teardown

At this point, the SpyStuffService instance is not used by the SUT, but we need it for the Func<IStuffCallbackService, IStuffService> instance used in the StuffClient constructor, so it's a classic example of a Test Dummy.

The test invokes the StuffWasDone method and subsequently verifies that the string passed to it becomes available in the StuffResults list, so again, it's really just a standard four-phase unit test.

If you've managed to read this far, I owe it to you to show how to set up StuffClient with a real WCF proxy. Remember, this must be done in another library that can reference System.ServiceModel, since the library where StuffClient is implemented must not reference WCF. The most natural place to do this is in a Humble Object, such as a top-level executable, as described here.

StuffClient client = new StuffClient(callbackService =>

        DuplexChannelFactory<IStuffService> cf =

            new DuplexChannelFactory<IStuffService>(callbackService,

                binding, remoteAddress);

        return cf.CreateChannel();

});

Note that this is the place where WCF reappears after its long absence. The StuffClient implementation has no dependency on WCF, and testability is ensured.

Update (2008-07-12): I've just posted an overview of the solution, as well as all the sample code.

Unit Testing Duplex WCF Services

ploeh — Sat, 28 Jun 2008 15:44:00 GMT

One of my readers recently asked me about unit testing WCF services when they have callbacks. Given that I strongly believe that you should attempt to implement your services without referencing WCF at all, but duplex WCF services require you to get the callback instance from OperationContext.Current, how can these two forces be reconciled?

Fortunately, it's really not that hard. All you have to do is to replace the call to OperationContext.GetCallbackChannel<T> with something abstract. On .NET 3.5, the easiest abstraction is Func<TResult>, which has the same signature, but if you are on .NET 3.0, you can always define a similar delegate type of your own.

Let's say that your contracts look like this:

[ServiceContract(CallbackContract = typeof(IStuffCallbackService))]

public interface IStuffService

    [OperationContract]

    void DoStuff(string stuff);

public interface IStuffCallbackService

    [OperationContract]

    void StuffWasDone(string result);

Since it would ruin testability of the IStuffService implementation if it was to use OperationContext.GetCallbackChannel<T> to create a new instance of IStuffCallbackService, it needs an instance of Func<IStuffCallbackService> instead. As I favor Constructor Injection, the complete implementation looks like this:

public class StuffService : IStuffService

    private readonly Func<IStuffCallbackService> createCallbackChannel_;

    public StuffService(Func<IStuffCallbackService> callbackCreator)

        if (callbackCreator == null)

            throw new ArgumentNullException("callbackCreator");

        this.createCallbackChannel_ = callbackCreator;

    #region IStuffService Members

    public void DoStuff(string stuff)

        // Implementation goes here...

        string stuffResult =

            new string(stuff.ToCharArray().Reverse().ToArray());

        this.createCallbackChannel_().StuffWasDone(stuffResult);

    #endregion

Such an implementation is imminently testable, as this test demonstrates:

[TestMethod]

public void DoStuffWillInvokeCallbackService()

    // Fixture setup

    string anonymousStuff = "ploeh";

    string expectedResult =

        new string(anonymousStuff.ToCharArray().Reverse().ToArray());

    SpyStuffCallbackService spy = new SpyStuffCallbackService();

    StuffService sut = new StuffService(() => spy);

    // Exercise system

    sut.DoStuff(anonymousStuff);

    // Verify outcome

    Assert.AreEqual<string>(expectedResult,

        spy.StuffResults.First(), "Callback result");

    // Teardown

The SpyStuffCallbackService class is a simple Test Spy that records all the callbacks in the StuffResults collection.

When you let WCF host the service, you need to tell WCF to use OperationContext.GetCallbackChannel<IStuffCallbackService> as the delegate instance to the StuffService constructor. In my previous post, I demonstrated how to do that (that's what StuffInstancingBehavior.GetInstance does).

Update (2008-07-12): I've just posted an overvview of the solution, as well as all the sample code.

Modifying Behavior of WCF-Free Service Implementations

ploeh — Fri, 27 Jun 2008 23:55:00 GMT

In my previous post, I explained how to implement a WCF service without referencing WCF. In simple cases, it works as described, but you may soon find yourself in a situation where you need to modify the behavior of the service when it's hosted by WCF.

Perhaps you need to control the service's ConcurrencyMode, or perhaps you need to set UseSynchronizationContext. These options are typically controlled by the ServiceBehaviorAttribute.

You may also want to provide an IInstanceProvider via a custom attribute that implements IContractBehavior.

However, you can't set these attributes on the service implementation itself, since it mustn't have a reference to System.ServiceModel.

In the rest of this post, I'll provide an example of how to achieve such results while still keeping WCF out of the service implementation.

Consider this service implementation:

public class StuffService : IStuffService

    private readonly Func<IStuffCallbackService> createCallbackChannel_;

    public StuffService(Func<IStuffCallbackService> callbackCreator)

        if (callbackCreator == null)

            throw new ArgumentNullException("callbackCreator");

        this.createCallbackChannel_ = callbackCreator;

    // IStuffService members here...

There are many cases (Dependency Injection is a common reason) where a a non-default constructor is desirable, so if you are wondering about this weird-looking Func<IStuffCallbackService> parameter, just consider that it might as well have been some other type of dependency. In a later post (edit 2008.06.29: available here), it will become apparent just why the constructor takes this specific input - for now, the important point is that the service implementation only has one, non-default constructor, and that it will throw if passed a null value.

Since WCF by default manages a service instance's lifetime, and the default behavior is to create a new instance per request, WCF requires the service to have a default constructor; that is, unless an IInstanceProvider is provided.

IInstanceProvider is defined in System.ServiceModel, so I can't implement this interface directly in the service library; instead, I create a new library that defines the WCF hosting behavior for the service. This library references both System.ServiceModel and the service library (the library that contains StuffService), so essentially, it's the library that sits on top of the dependency hierarchy and wires everything together.

In this library, I can implement IInstanceProvider via an IContractBehavior to provide new instances of StuffService:

public class StuffInstancingBehavior :

    IContractBehavior, IInstanceProvider

    #region IInstanceProvider Members

    public object GetInstance(InstanceContext instanceContext,

        Message message)

        return this.GetInstance(instanceContext);

    public object GetInstance(InstanceContext instanceContext)

        return new StuffService(() =>

            OperationContext.Current.

            GetCallbackChannel<IStuffCallbackService>());

    public void ReleaseInstance(InstanceContext instanceContext,

        object instance) { }

    #endregion

    #region IContractBehavior Members

    public void AddBindingParameters(ContractDescription description,

        ServiceEndpoint endpoint,

        BindingParameterCollection bindingParameters) { }

    public void ApplyClientBehavior(ContractDescription description,

        ServiceEndpoint endpoint, ClientRuntime clientRuntime) { }

    public void ApplyDispatchBehavior(ContractDescription description,

        ServiceEndpoint endpoint, DispatchRuntime dispatchRuntime)

        dispatchRuntime.InstanceProvider = this;

    public void Validate(ContractDescription description,

        ServiceEndpoint endpoint) { }

    #endregion

There are really only two lines of code of interest in this code listing: ApplyDispatchBehavior associates this IInstanceProvider implementation with the DispatchRuntime, and the GetInstance method creates the StuffService instance itself.

Notice that while we will not accept the use of OperationContext.Current in the service library, it's perfectly legal to use it here.

Applying an IEndpointBehavior can be done either via configuration or by programmatically adding it to the ServiceHost before opening it.

Since WCF will not be able to create an instance of StuffService without StuffInstancingBehavior, it's not really optional, so making it configurable doesn't make a whole lot of sense. This means that I should add it programmatically.

To support hosting in as wide a range of scenarios as possible, the best way to ensure that the ServiceHost is always created correctly (even when hosted in IIS) is by implementing a dedicated ServiceHostFactory (let's call it StuffServiceHostFactory). The CreateServiceHost method can be implemented as simply as this:

return new StuffServiceHost(baseAddresses);

Obviously, the real behavior configuration takes place in the StuffServiceHost class, which derives from ServiceHost. The entire implementation takes place in the constructor:

public StuffServiceHost(params Uri[] baseAddresses)

    : base(typeof(StuffService), baseAddresses)

    foreach (ContractDescription cd in

        this.ImplementedContracts.Values)

        cd.Behaviors.Add(new StuffInstancingBehavior());

    this.Description.Behaviors.Find<ServiceBehaviorAttribute>().

        ConcurrencyMode = ConcurrencyMode.Reentrant;

It adds StuffInstancingBehavior to all contracts, which will cause WCF to use its implementation of IInstanceProvider each time it wants to create a new instance of the StuffService. It also modifies the service's ConcurrencyMode; again, why it does that will become apparent in a future post, but I just wanted to show how you can programmatically achieve the same result as decorating your service with the ServiceBehaviorAttribute, since you can't do that directly on StuffService because it's being implemented in a library that doesn't reference WCF.

If you want to host StuffService in IIS, you just need to specify StuffServiceHostFactory in the .svc file's Factory attribute; if you want to host StuffService in your own process, you can just create a new instance of StuffServiceHost directly (or use an instance of StuffServiceHostFactory to create it).

All this behavior modification is taking place without StuffService being aware of it at all, and you can concentrate on implementing the service in whatever way you prefer, while keeping it totally testable and WCF runtime services far away from it. That's a very clean separation of concerns in my book.

Update (2008-07-12): Sample code is available here.

Implementing WCF Services Without Referencing WCF

ploeh — Thu, 26 Jun 2008 10:24:00 GMT

More than a year ago, I wrote my first post on unit testing WCF services. One of my points back then was that you have to be careful that the service implementation doesn't use any of the services provided by the WCF runtime environment (if you want to keep the service testable). As soon as you invoke something like OperationContext.Current, your code is not going to work in a unit testing scenario, but only when hosted by WCF.

This point is as true today as it was one and a half year ago.

So how do you ensure that you don't accidentally invoke WCF runtime services in the service code?

By being very, very careful..?

Unless you are very disciplined and work alone on the service, that's probably not a very good solution. While you may be skillful enough to pull it off, Joe Junior Programmer is going to come along during your one week of vacation and mess it all up.

Fortunately, a more robust solution exists: You can actually implement a WCF service without referencing WCF at all. How about that?

Obviously, when declaring the service contract, you will need to reference System.ServiceModel to put the right attributes on the contract:

[ServiceContract]

public interface IStuffService

    [OperationContract]

    void DoStuff(string stuff);

The contract library contains only the contract, but no implementation. The concrete implementation can be placed in a separate library that doesn't reference System.ServiceModel. As long as you have a reference to the contract library, you can still implement the service:

public class StuffService : IStuffService

    #region IStuffService Members

    public void DoStuff(string stuff)

        // Implementation goes here...    }

    #endregion

Since the entire WCF part of the contract is specified using attributes, you don't need a reference to System.ServiceModel in the implementation library even though the contract library requires this reference.

Now you can implement the service without fear of accidentally adding WCF dependencies, since you don't have a reference to WCF at all.

To prevent other developers from accidentally adding a reference to System.ServiceModel while you are away, you can actively enforce that convention, as exemplified in Glenn's post.

In very simple cases, this is all you need to do, but I'll admit that this example is a bit naive; as soon as you need to apply behaviors or other WCF-specific modifications to the service, it becomes more complex. In many cases, this is done by applying attributes to the service implementation (such as ServiceBehaviorAttribute), but this is not possible when you don't have a reference to System.ServiceModel.

In a future post, I'll explain how to get around some of these issues. Update: This post is now available here.

Declarative Use of Custom SecurityTokenParameters

ploeh — Thu, 01 May 2008 23:00:00 GMT

It's not the first time I've stated this, but one of the reasons I love WCF is that it's so wonderfully extensible. You can even implement your own custom security token, as this article explains. The only problem with this article is that it uses imperative code to create a custom Binding, and it doesn't explain how you can implement a custom security token mechanism in a declarative way (i.e. using app.config).

The offending part is the custom SecurityTokenParameters, which you can't specify declaratively, but have to attach to a SecurityBindingElement in some way.

So if you still want to be able to specify the use of your custom security token in app.config, how can you implement that?

A simple solution I've found involves creating a custom BindingElement that contains all the custom security token implementation, including the custom SecurityTokenParameters. This BindingElement additionally acts as a Decorator for whatever SecurityBindingElement you really want to use:

public class CreditCardSecurityBindingElement : BindingElement

    private readonly SymmetricSecurityBindingElement innerBindingElement_;

    public CreditCardSecurityBindingElement()

        this.innerBindingElement_ = new SymmetricSecurityBindingElement();

        this.innerBindingElement_.EndpointSupportingTokenParameters.SignedEncrypted.Add(new CreditCardTokenParameters());

        //..

    //..

To fully implement your custom BindingElement, remember to override all its virtual methods to delegate the functionality to the inner SecurityBindingElement, like this:

public override T GetProperty<T>(BindingContext context)

    return this.innerBindingElement_.GetProperty<T>(context);

To be able to use your custom BindingElement (CreditCardSecurityBindingElement) declaratively as part of a custom binding in app.config, you need to implement a BindingElementExtensionElement that creates it. Once you have done that, you should be good to go.