I Like Languages That Expect Me To Be a Great Programmer

A co-worker of mine recently turned me on to Uncle Bob’s blog. Yup, that’s Uncle Bob Martin.

Here’s one of his latest posts that sparked a thought in me: The Dark Path.

Make sure to read his follow-up post too: Types and Tests.

When I got done reading those posts, this was my simple thought: I like programming languages that expect me to be a great programmer.

Think of anyone you know who is great at something. Is it an artist? A politician? A teacher? I just watched American Sniper so I’m thinking of someone like Chris Kyle. He was a great sniper. His skill with a rifle was amazing.

Now, think of why that person is considered great at what they do. Is it because what they do is easy? Probably not. It’s probably because what they do is extremely difficult, but they still do it well. Or, it may be something that’s easy to do, but very difficult to do really well. Think of shooting a rifle. It’s very easy to shoot a rifle. Make sure it’s loaded. Aim it somewhere (safe). Pull the trigger. That’s it. But how about hitting a target 100 yards away? How about 1000 yards? Yeah, that gets really hard. Only a great marksman could do that.

The reason it’s hard to be a great marksman is because of the flexibility of a rifle. It’s relatively simple design lets you take it almost anywhere and lets you aim it at almost anything. The only way to make a rifle that even a novice could use to hit targets 1000 yards away would be to mount it on some kind of stand, add advanced aiming software somehow and let it pull the trigger. But, that makes it hard to use, doesn’t it? You now at the least have a bulky tripod to lug around a need for a power source for the computer to aim the thing.

That’s how overly restrictive programming languages have become for the sake of safety. They’re getting unwieldy. I want a flexible language that may be harder to use when I’m a novice, but once I’m an expert, it lets me do amazing things.

Castle.Windsor TypedFactoryFacility and Unexpected Property Injection Behavior

I finally got to the bottom of an issue today that came down to the way Castle.Windsor does property injection (injecting dependencies into public properties) when you are also using their TypedFactoryFacility. It was a tough one to track down, so I thought I’d put the solution out there for everyone else’s benefit.

The Problem

Here’s what the problem looked like.

The Error Message

First things first, this is what the symptom looked like:

[ComponentNotFoundException: No component for supporting the service System.Threading.Tasks.Task was found]
   Castle.MicroKernel.DefaultKernel.Castle.MicroKernel.IKernelInternal.Resolve(Type service, IDictionary arguments, IReleasePolicy policy) +120
   Castle.Facilities.TypedFactory.Internal.TypedFactoryInterceptor.Resolve(IInvocation invocation) +147
   Castle.Facilities.TypedFactory.Internal.TypedFactoryInterceptor.Intercept(IInvocation invocation) +123
   Castle.DynamicProxy.AbstractInvocation.Proceed() +448
   Castle.Proxies.Func`2Proxy.Invoke(OAuthMatchEndpointContext arg) +168

   ...

This is actually a pretty standard error when you’re using Castle.Windsor. It usually means Windsor tried to resolve some dependency but discovered that it was missing a registration. Translation: you forgot to register a component or type in your Windsor setup. Usually it’s an easy fix; just register your dependency properly.

In this case, however, as you can see, the missing registration was of type System.Threading.Tasks.Task. I didn’t have any dependencies on the Task class and so I didn’t want to “fix” any Windsor setup to register it. This wasn’t making sense.

Step One: TypedFactoryInterceptor?

The first oddity I noticed was that this error was happening somewhere in the flow of the TypedFactoryInterceptor. I could tell where the error was coming from in my code (from the rest of the stack trace that I didn’t include above). The problem was that it had nothing to do with any TypedFactoryFacility.

So, I inspected my registrations a little closer. I basically had a setup like this.

public class ChildClass : ParentClass
{
  public override Task DoSomething(Options options)
  {
    ...
  }
}

public class ParentClass : IInterface
{
  public Func<Options, Task> OnDoSomething { get; set; }
  public Func<Options, Task> OnDoSomethingElse { get; set; }

  public virtual Task DoSomething(Options options)
  {
    return OnDoSomething(options);
  }

  public virtual Task DoSomethingElse(Options options)
  {
    return OnDoSomethingElse.Invoke(options);
  }
}

Notice a couple of things.

1. ParentClass has several virtual methods. I’m only overriding one.
2. ParentClass is setup to allow you to override the virtual methods or to just supply it with Funcs.
3. The implementation of the virtual methods is to simply call the corresponding Funcs.

Finding the Location of the Problem

After lots of testing and debugging, I finally figured out that somehow a FuncProxy (see line 6 in the error stack trace above) was being injected into all of the public Func<,> properties on ParentClass. Then, when methods were called that I did not override in my ChildClass, the Func would be called in the ParentClass and that’s where Windsor was hooking in and eventually causing an error when it eventually tried to resolve a dependency on Task.

One More Clue

As I mentioned above, the presence of a TypedFactoryInterceptor in the stack trace was strange to me. I wasn’t using Windor’s TypedFactoryFacility to register my ChildClass. So, why was it sticking its nose into my class somehow?

I did some simple debugging and turned off the TypedFactoryFacility in my Windsor setup. Just like magic, the error I was seeing went away. So, my conclusion: somehow TypedFactoryFacility was inserting itself into my ChildClass registration and injecting FuncProxys into the ParentClass public Func<,> properties.

The Solution

This looked an aweful lot like property injection to me. I started searching related to TypedFactoryFacility and property injection. I pretty quickly came upon this documentation: https://github.com/castleproject/Windsor/blob/master/docs/how-properties-are-injected.md.

That page describes how Windsor does property injection, which I actually thought was an opt-in feature of Windsor. In fact, Windsor does it by default, as describe on that page.

Combining this revelation (to me) with the fact that TypedFactoryFacility also allows you to take a dependency on a simple Func and turn it into a factory call into your Windsor container, I concluded that, by turning on the TypedFactoryFacility in Windsor, I was opening up public properties that had Func<> types to property injection by Windsor.

Now, I hate property injection, so I was fine with just turning it off completely. Luckily, the documentation link above also included instructions how to do it. I’ve included that code here.

var propInjector = Kernel.ComponentModelBuilder
                         .Contributors
                         .OfType<PropertiesDependenciesModelInspector>()
                         .Single();
Kernel.ComponentModelBuilder.RemoveContributor(propInjector);

I added this code into my Windsor container setup and tried again. Everything worked just as expected.

Lessons Learned

A couple of quick takeaways:

1. Windsor does property injection by default. Check out the documentation link above for the criteria it uses to determine when it should or not.
2. Using TypedFactoryFacility is fantastic, but turn off property injection if you have public Func<> properties anywhere.

OWIN Integration Testing with OAuth Bearer Tokens

Situation

The situation is pretty simple. We have a project written with Web API 2.2 that we have running with OWIN. The API requires user authorization. To accomplish that, we use the OWIN OAuth libraries.

Upon until recently, the OAuth authorization server (the thing that takes in the user credentials and issues the token) and the API (the resource server) were hosted in the same site and web project.

Integration testing was pretty easy at this point. For the authorized calls, we simply wrote helper methods that logged a test user in through the authorization server (hosted along with the API in the OWIN test server), got a bearer token and then made the integration test calls.

Problem

When we recently decided to split the authorization server and resource server code up into two separate code bases (so that they could be hosted separately) we ran into issues with the authorization and API calls no longer being possible within a single integration test. The code to generate the bearer token was now no longer accessible in the test server for the API integration tests because the authorization server was now designed to be hosted separately. We’d have to somehow generate the bearer token without making a call with the OWIN test server.

Solution

The solution is to generate a valid bearer token in your test code and send it along with your test API call as you would have previous. How to generate that valid bearer token though?? It turns out to be easier than I thought.

How you use OWIN’s test server is beyond the scope of this blog post, but eventually you’ll have some code resembling this:

var server = TestServer.Create();

You’ll have to use a overload of the Create() method to capture a reference to the server’s IDataProtector. This interface defines what OWIN OAuth will use to encrypt a ClaimsIdentity into a valid bearer token.

Update your server creation code like this:

  var dataProtector;
  var server = TestServer.Create(app =>
  {
    var s = new Startup();
    s.Configuration(app);

    dataProtector = app.CreateDataProtector(
      typeof(OAuthBearerAuthenticationMiddleware).Namespace,
      "Access_Token", "v1");
  });

You have to get the dataProtector this way because it’s the same way that the OWIN OAuth libraries get it before trying to decrypt the bearer token. See the source for the OWIN OAuth code here: OAuthBearerAuthenticationMiddleware.cs

Once you’ve “captured” the dataProtector, in your integration test (or in some helper code, probably) you can generate your ClaimsIdentity and then your bearer token with the dataProtector.

  // inside an integration test
  using (server)
  {
    // create your valid identity any way you need to here
    ClaimsIdentity identity = new ClaimsIdentity(new GenericIdentity("username"));

    // these classes are defined in the OWIN OAuth libraries.
    var properties = new AuthenticationProperties();
    var ticket = new AuthenticationTicket(identity, properties);
    var format = new TicketDataFormat(dataProtector);

    string bearerToken = format.Protect(ticket);

    // ... call your API through the test server with the bearer token...
    var response = server.CreateRequest("/api/someendpoint")
        .AddHeader("Authorization", "Bearer " + bearerToken)
        .GetAsync()
        .Result;
  }

Using NuGetPackager 0.5.5 with GitVersionTask 3.4.1

I’m using both NuGetPackager with GitVersionTask on my project that provides EntityFramework persisters for NServiceBus: GoodlyFere.NServiceBus.EntityFramework.

NuGetPackager seems to work seamlessly with GitVersionTask 2.0.0. However, GitVersionTask is up to version 3.4.1 and I just hate sitting at a version that far behind!

So, I updated my NuGet package to the latest version of GitVersionTask. That’s 3.4.1 right now. Too bad, so sad! That caused this error:

The "CreatePackages" task was not given a value for the required parameter "Version".	1

The Problem

The problem turns out that NuGetPackager 0.5.5 is looking for a MSBuild property called “GfvNuGetVersion”. See the code in the .targets file here.

GitVersionTask 3.4.1 (somewhere in a release since 2.0.0) changed that property name to “GitVersion_NuGetVersion”. See the code here.

The Solution

So, how to fix this? NuGetPackager will probably be updated some day, but for now you can just translate the property in your .csproj file before the CreatePackage task is called in NuGetPackager.

Open up your .csproj file directly in some text editor like Notepad++. Find these two lines at the bottom of the file:

<Import Project="..\packages\GitVersionTask.3.4.1\Build\dotnet\GitVersionTask.targets"
        Condition="Exists('..\packages\GitVersionTask.3.4.1\Build\dotnet\GitVersionTask.targets')" />
<Import Project="..\packages\NuGetPackager.0.5.5\build\NuGetPackager.targets"
        Condition="Exists('..\packages\NuGetPackager.0.5.5\build\NuGetPackager.targets')" />

Before those two lines, add a target and a property group. The target will create a task that translates the new property to the new property. The property group wil define a BuildDependsOn to call that target before the CreatePackages target is called.

<Target Name="TranslateNugetVersion"
        Condition="'$(Configuration)' == 'Release'">
    <CreateProperty
        Value="$(GitVersion_NuGetVersion)">
        <Output
            TaskParameter="Value"
            PropertyName="GfvNuGetVersion" />
    </CreateProperty>
</Target>
<PropertyGroup>
    <BuildDependsOn>
        $(BuildDependsOn);
        TranslateNugetVersion
    </BuildDependsOn>
</PropertyGroup>
<Import Project="..\packages\GitVersionTask.3.4.1\Build\dotnet\GitVersionTask.targets"
        Condition="Exists('..\packages\GitVersionTask.3.4.1\Build\dotnet\GitVersionTask.targets')" />
<Import Project="..\packages\NuGetPackager.0.5.5\build\NuGetPackager.targets"
        Condition="Exists('..\packages\NuGetPackager.0.5.5\build\NuGetPackager.targets')" />

Now, when you build your project, everything should work great!

You Can't Subscribe to IEvent with NServiceBus

The reason you might want to subscribe to IEvent is pretty straightforward. I wanted to do it for the simple reason of wanting to be able to choose (based on configuration) whether I wanted to notify anyone of any event that could be published on my bus.

In other words, whenever an event of any type was published, I wanted one particular endpoint to subscribe to that event and then decide whether it should do anything with it.

I thought the code to do that should be pretty simple. Since all published events should implement the IEvent interface and NServiceBus supports polymorphism in its message handling, creating a message handler that implemented IHandleMessages<IEvent> should be all I should have needed!

I was testing this with only partial success and so I thought it was working.

public class EventHandler : IHandleMessages<IEvent>
{
   public void Handle(IEvent message)
   {
     ...
   }
}

My Partial Success

The reason I had partial success was because I was also explicitly handling other events in the same endpoint on a special saga I had setup. So, when the endpoint started up, it would subscribe to these events. At first, I only wanted to send notifications for these events anyway, so it all seemed to be working. My special IEvent would work because the Saga subscribed this same endpoint to those few events explicitly.

My Full Failure

I realized I had only partially succeeded when I started wanting to send notifications for other events that were not in that Saga. I dug into the issue for a few hours and finally began to wonder if NServiceBus (or maybe the RabbitMQ transport) was explicitly ignoring IEvent when it setup subscriptions.

Sure enough, it does.

To build a list of types to subscribe to, NServiceBus uses the Conventions class in the NServiceBus.Core namespace. One of the checks that code does is to filter the list of potential types with the IsEventType method. This method checks if the Type is in a Particular (NServiceBus) DLL. See the code here: IsEventType

My Solution

The solution is simple enough. Instead of listening to IEvent, listen to a custom interface that you implement on all of your events. This is probably more close to what you are trying to do anyway–listen to all events that your system produces.

So, I simply created a marker interface called ICustomEvent.

public interface ICustomEvent : IEvent { }

Then, on all of my bus event classes, instead of implementing IEvent directly, I implemented ICustomEvent.

My handler then looked like this.

public class EventHandler : IHandleMessages<ICustomEvent>
{
   public void Handle(ICustomEvent message)
   {
     ...
   }
}

Now, the right subscriptions are all set up and my single handler gets every single event published by my entire bus.