The project I’m currently working on is a Silverlight app and I’m in the throes of converting it to use the Composite Application Guidance framework from Microsoft. It’s been a reasonably mind-bending experience but also fairly straightforward if that’s possible. However, something popped up today that warrants mentioning.
I’m using the Unity Application Block as a Dependency Injection framework, also from Microsoft. I made a couple of changes to my app and started getting “Unable to resolve dependency” exceptions for a constructor of an object. The catch was, I was definitely registering all my dependencies and they were being created correctly. Turns out, I had just added the EventAggregator portion of the framework and had subscribed one of my events to a private event handler while I wasn’t paying attention which obviously won’t work since the event handler has to be public.
The problem occurred when the MethodAccessException did not get bubbled up correctly to my Module. Instead, it’s getting swallowed somewhere down in the ModuleInitializer and the exception getting tossed out is an “Unable to resolve dependency” exception which might confuse the hell out of you if you were positive you had all your dependencies resolved. I haven’t dug deep enough yet to figure out where the original exception is getting swallowed but I figured all this out when I wrapped a try-catch around the initialization code of the object that the framework was complaining about. Change the event handler to public and woohoo, we’re back in business.
As an aside, I’ve been pretty happy with the Composite Application Guidance framework. It’s a BIG chunk of functionality but it seems to be all things you really need in WPF and Silverlight apps. I’m hoping to have a few more posts about happier times with it soon but for now, I recommend checking it out if you’re working with WPF or Silverlight.