C# .Net Core dependency injection, inject multiple parameters to constructor

I think that storing the Dictionary inside your strategy is quite a code smeel, as it looks like an anti-pattern Service Locator. You probably need to introduce the factory for your authentication providers based on key. This is a desired approach in .Core dependency injection, however you can use other IoC containers with similar features (named dependencies, for example).

So, your code could be like this:

public enum AuthType
{
    Internal,
    External,
}

public interface IAuthenticationProviderResolver
{
    IAuthenticationProvider GetAuthByType(AuthType type);
}

public class ProviderResolver : IAuthenticationProviderResolver
{
    private readonly IServiceProvider _serviceProvider;

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

    public IAuthenticationProvider GetAuthByName(AuthType type)
    {
         switch (type) 
         {
             case AuthType.Internal:
                 return _serviceProvider.GetService<InternalAuthenticationProvider>();
             case AuthType.External:
                 return _serviceProvider.GetService<ExternalAuthenticationProvider>();
             default:
                 throw new ArgumentException("Unknown type for authentication", nameof(type))
         }
    }
}

Now all you need is to register your classes as usual:

services.AddSingleton<IAuthenticationProviderResolver, ProviderResolver>();
services.AddScoped<InternalAuthenticationProvider>();
services.AddScoped<ExternalAuthenticationProvider>();
services.AddScoped<AuthenticationStrategy>();

And usage inside the strategy:

public class AuthenticationStrategy
{
    private readonly IAuthenticationProviderResolver _resolver;

    public AuthenticationStrategy(IAuthenticationProviderResolver resolver)
    {
        if (resolver== null)
        {
            throw new ArgumentNullException("Provider Resolver");
        }

        _resolver = resolver;
    }

    public void MakeDecision()
    {
        _resolver.GetAuthByType(authType).Authenticate();
    }
}

One option would be to make AuthenticationStrategy generic. Then you could differ with type

config.Scan(assembly =>
{
    assembly.AssemblyContainingType(typeof(AuthenticationProvider));
    assembly.ConnectImplementationsToTypesClosing(typeof(IAuthenticationProvider<>));
});

Code above scans the dll so you also don't have to register each and every one.

If you're sticking with the OOTB dependency injection setup i.e. not using a third party container then one option would be to be explicit in your constructor args like this:

public class AuthenticationStrategy
{
    public AuthenticationStrategy(
        IInternalAuthenticationProvider internal,
        IExternalAuthenticationProvider external)
    {
        ...
    }
}

IInternalAuthenticationProvider and IExternalAuthenticationProvider interfaces are nothing more than marker interfaces like so:

public interface IInternalAuthenticationProvider : IAuthenticationProvider { }
public interface IExternalAuthenticationProvider : IAuthenticationProvider { }

So your DI setup will now look like this:

services.AddScoped<IInternalAuthenticationProvider , InternalAuthenticationProvider>();
services.AddScoped<IExternalAuthenticationProvider , ExternalAuthenticationProvider>();
services.AddScoped<AuthenticationStrategy>();

Assuming you are using Asp.Net Core project type with Visual Studio 2017

Lets say you have the following defination of an interface:

   public interface IAuthenticationProvider 
    {
    }

with implementing classes like so:

public class WindowsAuthentication : IAuthenticationProvider { }


public class NTMLAuthentication : IAuthenticationProvider { }


public class KerberosAuthentication : IAuthenticationProvider { }


public class CustomAuthentication : IAuthenticationProvider { }

So far so good. Now to resolve the dependencies for the types implementing the same interface I would use the custom resolver class with its interface:

public interface IAuthenticationResolver
{
    IAuthenticationProvider GetProvider(Type type);
}

and its implementation:

public class AuthenticationResolver : IAuthenticationResolver
    {
        private readonly IServiceProvider services;
        public AuthenticationResolver(IServiceProvider services)
        {
            this.services = services;
        }

        public IAuthenticationProvider GetProvider(Type type)
        {            
            return this.services.GetService(type) as IAuthenticationProvider;
        }
    }

In your Startup class, under ConfigureServices register these types

 services.AddTransient<IAuthenticationResolver, AuthenticationResolver>();
            services.AddTransient<WindowsAuthentication>();
            services.AddTransient<KerberosAuthentication>();
            services.AddTransient<NTMLAuthentication>();
            services.AddTransient<CustomAuthentication>();

Of course you can use Scopped if thats what you need.

Once this is all set, go back to your controller / client class where the dependencies are injected:

 public class HomeController : Controller
 {
        private readonly Dictionary<string, IAuthenticationProvider> authProvidersDictionary;

        public HomeController(IAuthenticationResolver resolver)
        {
            System.Reflection.Assembly ass = System.Reflection.Assembly.GetEntryAssembly();
            this.authProvidersDictionary = new Dictionary<string, IAuthenticationProvider>();

            foreach (System.Reflection.TypeInfo ti in ass.DefinedTypes)
            {
                if (ti.ImplementedInterfaces.Contains(typeof(IAuthenticationProvider)))
                {                   

                    this.authProvidersDictionary.Add(ti.Name, resolver.GetProvider(ti.UnderlyingSystemType));
                }
            }            
        }
}

Hope this helps!

The question is in itself an anti-pattern example of dependency injection being the "Golden Hammer" tool of choice for .net core.

Your class should be able to access the two authentication providers without the disjoint code of dependency injection.

Disjoint code in .net dependency injection:

• Registering the injected object in the application's startup
• Object construction of injected object separated from that object's implementation in an anonymous method
• Object construction never directly called by the rest of the .net core's application code. The .net core framework calls the constructor.

A junior fresh out of school developer should be able to look at any line in any method and quickly find how that method is called, where the method is called and why the method is called -without having to know dozens (hundreds?) of small micro-features of the .net core framework.

Unit testing with mocked classes is easily achievable in ways other than using dependency injection.