WCF Integration: ServiceBehavior disregards any existing InstanceProviders

Jul 11, 2013 at 3:56 AM
Hi there,

I recently came up against a problem while implementing WS-Discovery in a WCF service that was also using a custom InstanceProvider (not the SI InstanceProvider, but one very similar to it).

The bug was that WS-Discovery creates a few of its own ChannelDispatcher objects with their own implementation of IInstanceProvider inside them. We were just coming along and blindly replacing them with our own InstanceProvider implementation, and it broke the discoverability of the service.

We fixed it by just checking for null before setting the InstanceProvider: if it was not null, we didn't set it.

Looking at the latest code up here, I notice that the SI ServiceBehavior does the same thing - just sets the InstanceProvider. Therefore, SI WCF Integration probably breaks WS-Discovery too.

Cheers
Adrian
Coordinator
Jul 11, 2013 at 6:57 AM
Hi Adrian,

If this the fix you suggest?
// inside the SimpleInjectorServiceBehavior.ApplyDispatchBehavior method:
if (endpoint.DispatchRuntime.InstanceProvider == null)
{
    endpoint.DispatchRuntime.InstanceProvider =
        new SimpleInjectorInstanceProvider(this.container, serviceDescription.ServiceType);
}
I noticed that the WCF integration for Autofac doesn't do this as well (take a look at it's ServiceBehavior class). What it does do however, is filter endpoints on their contract name, but I'm not sure what's the use of that.
Jul 11, 2013 at 10:11 PM

Ah yep, filtering by contract would also fix the issue.

The problem is that WS-Discovery creates new endpoints that implement contracts specifically for discoverability of the service. If Autofac has behaviour to only set an InstanceProvider for endpoints that implement certain contracts, then the endpoints with WS-Discovery contracts will be left alone. Maybe that’s a better solution? I’m not sure.

Coordinator
Jul 12, 2013 at 6:43 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Jul 12, 2013 at 3:44 PM
This issue has been fixed in v2.3.1.
Marked as answer by dot_NET_Junkie on 2/26/2014 at 1:39 PM