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.
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.
ParentClass has several virtual methods. I’m only overriding one.
ParentClass is setup to allow you to override the virtual methods or to just supply
it with Funcs.
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.
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.
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.
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 testusing(server){// create your valid identity any way you need to hereClaimsIdentityidentity=newClaimsIdentity(newGenericIdentity("username"));// these classes are defined in the OWIN OAuth libraries.varproperties=newAuthenticationProperties();varticket=newAuthenticationTicket(identity,properties);varformat=newTicketDataFormat(dataProtector);stringbearerToken=format.Protect(ticket);// ... call your API through the test server with the bearer token...varresponse=server.CreateRequest("/api/someendpoint").AddHeader("Authorization","Bearer "+bearerToken).GetAsync().Result;}
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:
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.
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.