An Experiment In Scotch

I write to discover what I believe

Tag: Silverlight

Configuring IUnityContainer

I’m using the IUnityContainer from the Composite Application Guidance in my current Silverlight project for Dependency Injection and this morning, I came across something that I couldn’t find documented anywhere. Initially, all my registered dependencies were being created using other dependencies that I had registered with the container. For example, I had the CustomerOrderService below and it was created using an IEventAggregator that was already registered in the container.

    public class CustomerOrderService : ICustomerOrderService
    {
        public CustomerOrderService(IEventAggregator evAg)
        {
            this.eventAggregator = evAg;
        }
    }

I was just registering my service with the container and letting it do all the work.

this.container.RegisterType();

However, this morning, I wanted to add a simple string to my constructor so that I could pass in the URI for a web service instead of hard coding it in the service class. After digging around a little in the docs and eventually just playing with the code until it worked, I came up with two ways of doing this.

First, I modified my service to have two constructor arguments:

    public class CustomerOrderService : ICustomerOrderService
    {
        public CustomerOrderService(IEventAggregator evAg, string uri)
        {
            this.eventAggregator = evAg;
            this.baseUri = uri;
        }
    }

Then, I came up with the two ways to register this service in code with the container. First, you can tell the container how to configure your dependency registration.

this.container.Configure().ConfigureInjectionFor(
    new InjectionConstructor(typeof(IEventAggregator), "URI GOES HERE"));

When the container is asked to create a CustomerOrderService object, it is configured to send in an IEventAggregator instance that it resolves internally and the URI string above. Of course, in a real world app, that URI would actually be a URI that I get from configuration.

Alternatively, you can tell the container what to do when you register the type:

this.container.RegisterType(
    new InjectionConstructor(typeof(IEventAggregator), "URI GOES HERE"));

This is a little cleaner because you’re going to have to register the type anyway and it makes sense to configure it at the same time.

By allowing the developer to specify an InjectionConstructor to use, the UnityContainer gives the developer a much more flexible way to register his dependencies.

PS: The Google Syntax highlighter and my new WordPress theme don’t apparently play well together. Or at all. So the code is displaying in a ridiculous way. If you need an actual example, feel free to drop me a line in the comments and I’ll send you one. It may be time to separate my tech blogging out from The Experiment.

Public Service Announcement – Composite Application Guidance

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.

Silverlight White Screen Of Death Debugging

If you’re working in Silverlight and your app suddenly starts giving you the white screen of death, chances are there’s something wrong with the markup. Of course, since the white screen of death results in zero exceptions, sometimes it’s hard to track down what the problem is. Enter the Error Console in Firefox. If you get a WSOD, pop open Tools->Error Console in Firefox, scroll to the bottom of the list and you might be pleasantly surprised to find your problem described there.

Wireshark Rocks

I love Wireshark. It’s a network protocol analyzer that has saved me countless hours over the last year or so in debugging serialization and HTTP issues on a variety of projects. Today’s success story comes courtesy of Silverlight, WCF and the hazards of leaving slashes off the end of a URL.

I’m working on a project developing a Silverlight app and I’m in the process of adding a logging service on the server side. After I added the framework and skeleton yesterday to implement logging, my Silverlight app started throwing up a “This web page is being redirected to a new location. Would you like to resend the form data you have typed to the new location?” informational message. This was late in the day yesterday and having zero brain cells left to figure it out, I left it for today, hoping it would magically go away.

Of course, it didn’t. But having rejuvenated the two brain cells I have with two gin and tonics last night, this morning it was clear that Wireshark would be the answer. Instead of spending hours trying to figure out why in the hell I was getting that message, I just fired Wireshark up and followed the TCP stream going back and forth from my app to the server. That told me that the server was returning a 301 Temporary Redirect because there was no endpoint at “http://my_url/without_an_endingslash” but that there was an endpoint listening at “http://my_url/without_an_endingslash/” and so I was being redirected there.

2 minutes using a great tool and I had the answer. I love days like this, rare though they are.

Silverlight Gotcha Of The Day

If you have an ItemsControl that is throwing an exception telling you the collection is read-only when you call Clear() on the Items property before resetting the data binding, try setting the ItemsSource property to null instead.

Silverlight Security Exceptions With WCF Services

From the public service announcement department, this is an issue I recently struggled with and since I didn’t find much help on the web, I thought I’d contribute. If you’re trying to hit WCF services (ours are RESTful but I’m pretty sure this happens on regular services as well), you may get weird security exceptions like this:

at System.Net.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
   at System.Net.BrowserHttpWebRequest.<>c__DisplayClass5.b__4(Object sendState)
   at System.Net.AsyncHelper.<>c__DisplayClass2.b__0(Object sendState) 

This can happen even if you’re using a clientaccesspolicy.xml file which is supposed to be one of the supported ways to get around cross domain issues in Silverlight according to Microsoft. Problem is, that doesn’t seem to be true. I examined the requests on the wire using Wireshark and what was actually happening was that my Silverlight application was asking for the clientaccesspolicy.xml and the server was responding with a 304 Unchanged status. Silverlight didn’t seem to know what to do with this so it would continue to throw the SecurityException above.

As it turns out, the crossdomain.xml file is the way to go if you want to have your Silverlight application talk to WCF. Put this at the web root and suddenly, everything works like a champ. Funny how the crossdomain.xml file is from Flash, the very application Silverlight is trying to take market share from.

Irony. It’s what’s for breakfast.