An Experiment in Scotch

The project I’m cur­rently work­ing on is a Sil­verlight app and I’m in the throes of con­vert­ing it to use the Com­pos­ite Appli­ca­tion Guid­ance frame­work from Microsoft. It’s been a rea­son­ably mind-bending expe­ri­ence but also fairly straight­for­ward if that’s pos­si­ble. How­ever, some­thing popped up today that war­rants mentioning.

I’m using the Unity Appli­ca­tion Block as a Depen­dency Injec­tion frame­work, also from Microsoft. I made a cou­ple of changes to my app and started get­ting “Unable to resolve depen­dency” excep­tions for a con­struc­tor of an object. The catch was, I was def­i­nitely reg­is­ter­ing all my depen­den­cies and they were being cre­ated cor­rectly. Turns out, I had just added the Even­tAg­gre­ga­tor por­tion of the frame­work and had sub­scribed one of my events to a pri­vate event han­dler while I wasn’t pay­ing atten­tion which obvi­ously won’t work since the event han­dler has to be public.

The prob­lem occurred when the Metho­d­Ac­ces­sEx­cep­tion did not get bub­bled up cor­rectly to my Mod­ule. Instead, it’s get­ting swal­lowed some­where down in the Mod­uleIni­tial­izer and the excep­tion get­ting tossed out is an “Unable to resolve depen­dency” excep­tion which might con­fuse the hell out of you if you were pos­i­tive you had all your depen­den­cies resolved. I haven’t dug deep enough yet to fig­ure out where the orig­i­nal excep­tion is get­ting swal­lowed but I fig­ured all this out when I wrapped a try-catch around the ini­tial­iza­tion code of the object that the frame­work was com­plain­ing about. Change the event han­dler to pub­lic and woohoo, we’re back in business.

As an aside, I’ve been pretty happy with the Com­pos­ite Appli­ca­tion Guid­ance frame­work. It’s a BIG chunk of func­tion­al­ity but it seems to be all things you really need in WPF and Sil­verlight apps. I’m hop­ing to have a few more posts about hap­pier times with it soon but for now, I rec­om­mend check­ing it out if you’re work­ing with WPF or Silverlight.