Instance behaviour ignores dependent objects in ctor

[DublinDel]

Hi again

I was having an issue using the Autofac container whereby InstancePerLifeTime scopes were being resolved during bootstrapping causing the bootstrap to fail (nhibernate sessions and other such per call behaviour).

These container scopes work correctly in standard Core applications for Autofac so I decided to switch to the Core 3.1 DI infrastructure for the CoreWCF based application which worked up to a point.

The issue I found is with dependent objects being injected into the service constructor is not handled by the CoreWCF InstanceBehavior implementation.

My question is: does the CoreWCF only handle parameter-less constructors in the service?

Here is my services configuration for the service and the dependent object

services.AddScoped<IHelloWorldBusinessService, HelloWorldBusinessService>();
services.AddScoped<IHelloWorld, HelloWorldService>();

My service is defined so that is Per Call e.g.:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
public class HelloWorldService : IHelloWorld

And my ctor:

public HelloWorldService(IHelloWorldBusinessService helloWorldBusinessService)
{   
    _helloWorldBusinessService = helloWorldBusinessService;         
}

The instance behaviour in CoreWCF checks the following and returns null since the ctor has a parameter:

private static ConstructorInfo GetConstructor(Type type)
{
    foreach (ConstructorInfo constructor in type.GetConstructors(DefaultBindingFlags))
    {
      if (constructor.GetParameters().Length == 0)
      {
            return constructor;
       }
    }
    return null;
}

If I add a parameter-less ctor the service bootstraps but the dependent object is never injected. Am I missing something in the service configuration or does the underlying instance behaviour ignore ctors with parameters altogether.

Is this why Autofac is confusing instance per life time scopes on service bootstrapping ? - (apologies for the 2 for 1 question)

Any help is most welcome.

[alesandrino]

This works by implementing your own instance provider. It is discussed in #56.
Basically you need to implement IServiceBehavior:

    public class InstanceProviderBehavior<TContract> : IServiceBehavior
    {
        private readonly IServiceProvider _serviceProvider;

        public InstanceProviderBehavior(IServiceProvider serviceProvider)
        {
            _serviceProvider = serviceProvider;
        }

        public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters)
        {
        }

        public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
        {
            var provider = new InstanceProvider<TContract>(_serviceProvider);
            foreach (var channelDispatcher in serviceHostBase.ChannelDispatchers.OfType<ChannelDispatcher>())
            {
                foreach (var ed in channelDispatcher.Endpoints.Where(p => !p.IsSystemEndpoint))
                {
                    ed.DispatchRuntime.InstanceProvider = provider;
                }
            }
        }

        public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
        {
        }
    }

    public class InstanceProvider<TContract> : IInstanceProvider
    {
        private readonly IServiceProvider _serviceProvider;

        public InstanceProvider(IServiceProvider serviceProvider)
        {
            _serviceProvider = serviceProvider;
        }

        public object GetInstance(InstanceContext instanceContext, Message message) => _serviceProvider.GetService<TContract>();
        public object GetInstance(InstanceContext instanceContext) => _serviceProvider.GetService<TContract>();
        public void ReleaseInstance(InstanceContext instanceContext, object instance) { }
    }

and use it when you configure your service:

    app.UseServiceModel(builder =>
    {
        builder
            .AddService<EchoService>()
            .AddServiceEndpoint<EchoService, Contract.IEchoService>(new BasicHttpBinding(), "/basichttp")
            .AddServiceEndpoint<EchoService, Contract.IEchoService>(new NetTcpBinding(), "/nettcp")
            .ConfigureServiceHostBase<EchoService>(serviceHost =>
            {
                serviceHost.Description.Behaviors.Add(new InstanceProviderBehavior<Contract.IEchoService>(app.ApplicationServices));
            });
    });

Also InstanceContextMode cannot be InstanceContextMode.Single.

[DublinDel]

Thanks for the replies guys.

The issue I am having with Autofac is being caused by that Create Service Description during service bootstrap where you get the instance from DI:

TService instance = _serviceProvider.GetService<TService>();

This goes and resolves our Autofac registrations on bootstrapping when they are supposed to be resolved at runtime during an actual HTTP request i.e. using the InstancePerLifetimeScope scope. This causes exceptions where the scope requires an HTTP Context to dig out "per request" details.
If I hack away and get the service bootstrapped then the actual HTTP Request never hooks into the InstancePerLifetimeScope scope - it appears the dependants act as singletons.

Autofac lifetimes works 100% in our Web API upgrades into Core 3.1 applications, its just not happening quite so well with the WCF porting.

We are pretty much tied to Autofac (at the moment) as our system was designed with the Autofac Named Service capability plus other Autofac functionality - some of which I have redone in extensions but others are a bit more troublesome. The MS container is just a little too lightweight for us, or is designed specifically to not use named services which I can understand.

So basically the

TService instance = _serviceProvider.GetService();

call is causing exceptions and service failure due to there being no HTTP Context as we are not expecting certain services to be resolved until everything is running and a request comes in.

I could wrap up a dummy project using Autofac to outline the issue and send it on if you are interested?
It may well be something daft on my part.

Many thanks for your assistance.

[mconnew]

I understand the problem you're having. Unfortunately using the default behavior CoreWCF needs to request it from DI at bootstrap to know if it's available via DI so that it will use the DependencyInjectionInstanceProvider. The problem you're hitting I believe is that constructor arguments are treated as required dependencies so there's no soft failure. I did a bit of research on how to deal with this situation and the answer is the concept of null objects. It's an instance of the type which represents no object, but is a concrete instance. I think something like the following would work:

public void ConfigureServices(IServiceCollection services)
{
    services.AddHttpContextAccessor();
    services.AddScoped<IHelloWorldBusinessService, HelloWorldBusinessService>();
    services.AddScoped<HelloWorldServiceFactory>();
    services.AddTransient<HelloWorldService>(HelloWorldServiceFactory.Factory);
}

public class HelloWorldServiceFactory
{
    public HelloWorldServiceFactory(IHttpContextAccessor httpContextAccessor, IHelloWorldBusinessService helloWorldBusinessService)
    {
        if (httpContextAccessor.HttpContext == null) 
        {
            Instance = HelloWorldService.Empty;
        }
        else
        {
            Instance = new HelloWorldService(httpContextAccessor.HttpContext, helloWorldBusinessService);
        }
    }
    public HelloWorldService Instance { get; }
    public static HelloWorldService Factory(IServiceProvider serviceProvider)
    {
        var factory = serviceProvider.GetService<HelloWorldServiceFactory>();
        return factory.Instance;
    }
}

public class HelloWorldService
{
    private HelloWorldService() { } // Private constructor can only be called by this
    public HelloWorldService(HttpContext httpContext, IHelloWorldBusinessService helloWorldBusinessService) 
    {
         //// Your regular implementation
    }
    public static HelloWorldService Empty { get; } = new HelloWorldService();
}

This is to demonstrate the concept. If HttpContext is your only issue, you might be able to just get away just switching to using IHttpContextAccessor in your constructor instead. Another alternative would be to modify the factory constructor to take an IServiceProvider and support the missing dependency problem by asking for it from DI in a non required way and reacting to it being missing instead:

    public HelloWorldServiceFactory(IServiceProvider serviceProvider, IHelloWorldBusinessService helloWorldBusinessService)
    {
        var httpContext = serviceProvider.GetService<HttpContext>();
        IFoo foo = serviceProvider.GetService<IFoo>(); // IFoo is another dependency which might not be available
        IBar bar = null;
        try
        {
            bar = serviceProvider.GetService<IBar>(); // IBar is a dependency which would throw trying to get it
        }
        catch() { } // Ignore any exceptions
        if (httpContext == null || foo == null || bar == null) 
        {
            Instance = HelloWorldService.Empty;
        }
        else
        {
            Instance = new HelloWorldService(httpContextAccessor.HttpContext, helloWorldBusinessService);
        }
    }

I know it's not the cleanest of approaches as you have an extra allocation of HelloWorldServiceFactory. You could eliminate that by just having the static factory method get every dependency via serviceProvider.GetService<>, but that's a tradeoff between writing and maintaining more code vs allocations.

I also noticed that you are adding IHelloWorld to DI instead of HelloWorldService. CoreWCF is retrieve the concrete service type and not the interface. Although that is definitely an interesting potential future feature, not having to define your service implementation.

[Kralizek]

I also noticed that you are adding IHelloWorld to DI instead of HelloWorldService. CoreWCF is retrieve the concrete service type and not the interface. Although that is definitely an interesting potential future feature, not having to define your service implementation.

This would make testing much easier, wouldn't it?

[mconnew]

First I want to make sure I unblocked you with my response?

Using the interface in DI would mean skipping adding the service type to CoreWCF. So your config code would look more like this:

    app.UseServiceModel(builder =>
    {
        builder
            .AddServiceEndpoint<Contract.IEchoService>(new BasicHttpBinding(), "/basichttp")
            .AddServiceEndpoint<Contract.IEchoService>(new NetTcpBinding(), "/nettcp")
    });

You couldn't use ConfigureServiceHostBase as you would be removing the concept of a ServiceHost for a service implementation type. This brings up an interesting problem which would need to be resolved. If you had 2 service intefaces, IFoo and IBar listening on 2 different addresses, and you are using ConcurrencyMode.Singleton, and you have a single type which implements both interfaces, should 2 different service instances be used or should just one? It might be difficult to document simply what would happen in different scenarios. So I don't think this approach will make things easier, and would probably cause more confusion.

I think an easier solution might be to relax constraints on AddService to allow an interface to be provided to AddService, then if it's an interface, expect it to be available via DI and to also have the interface declared as implementing the service interfaces. I don't think we could skip the probing check in DI as we also check the concrete implementation for attributes to affect behavior. Maybe we could treat it as an error if the concrete implementation ends up having any behavior attributes as we can't apply them, but I don't know how we could easily expose this is the problem.

I don't think the current design holds you back from being able to change the type for testing. For example, you can do something like this:

public class Startup<TService> where TService : class, IFoo, IBar
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddServiceModelServices();
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseServiceModel(builder =>
        {
            builder.AddService<TService>()
                .AddServiceEndpoint<TService, IFoo>(new BasicHttpBinding(), "/basichttp")
                .AddServiceEndpoint<TService, IBar>(new NetTcpBinding(), "/nettcp")
        });
    }
}

Then in your real app you use .UseStartup<Startup<RealService>>(); and in your tests you use .UseStartup<Startup<TestService>>();. Another alternative is to define an abstract class and provide that to AddService, and have your real service and test implementation derive from that. Then add to DI the concrete type.

[DublinDel]

Apologies for not replying earlier but I got around to implementing your suggestion just recently i.e. I used the factory approach you suggested using the private constructor and the "Empty" returned service.

This worked out fine using the Microsoft Core DI once I refactored how our NHibernate session factories and open sessions are injected in our business services (removing some unwanted service locators and use of named services).

I will try and get the autofac container working with this approach as I would still like to be able to use that container.

May thanks everyone.