We Keep Coding

Inject an IEnumerable of interface in controller using Dependency Injection

I want to resolve the dependency for the IEnumerable collections of the multiple class inheriting the Interface on the controller.
I want to resolve the following dependency during the application startup:
var notificationStrategy = new NotificationStrategy(
new INotificationService[]
{
new TextNotificationService(), // <-- inject any dependencies here
new EmailNotificationService() // <-- inject any dependencies here
});
NotificationStragey
public class NotificationStrategy : INotificatonStrategy
{
private readonly IEnumerable<INotificationService> notificationServices;
public NotificationStrategy(IEnumerable<INotificationService> notificationServices)
{
this.notificationServices = notificationServices ?? throw new ArgumentNullException(nameof(notificationServices));
}
}
What is the best way of dependency injection of IEnumerable types of objects in the asp.net core without using any external dependency or library?

Register all the types with the service collection at the composite root
//...
services.AddScoped<INotificationService, TextNotificationService>();
services.AddScoped<INotificationService, EmailNotificationService>();
services.AddScoped<INotificatonStrategy, NotificationStrategy>();
//...
and all dependencies should be injected when resolving the desired type since the constructor already has IEnumerable<INotificationService> as a constructor parameter
Reference Dependency injection in ASP.NET Core

How to access instance by two different types when using dependency injection

I have the following class:
public class CustomDatabase : DbContext
{
public void Function1(){..}
}
public class CustomerDb : CustomDatabase
{
public void GetCustomerById(guid id){..}
}
This is created by calling
services.AddDbContext<CustomerDb>();
and is used all around the code as CustomerDb.
I now want to use a middleware from a nuget that does not know about my project, but knows about the CustomDatabase implementation. But when I try to refer to CustomDatabase I get an run-time error saying that the DI framework can not find CustomDatabase.
How can I make it so I can refer to this instance as both CustomDatabase and CustomerDb?

You cannot achieve this with the default DI container (aka. Microsoft.Extensions.DependencyInjection) because it does not support registering a service as multiple resolving interfaces. Even if you register one type as factory function that resolves and return another one, the service would be duplicately disposed (This could even be a possible solution if the service implementation type does not implement IDisposable or its Dispose method could be called for multiple times without unexpected behaviors). eg.
Given the types:
interface I1 { }
interface I2 { }
class C : I1, I2 { }
If the service implementation type does not implement IDisposable or its Dispose method could be called for multiple times without unexpected behaviors:
var services = new ServiceCollection();
services.AddSingleton<I1, C>();
services.AddSingleton<I2>(p => (I2)p.GetService<I1>()); //Must be exactly the same lifetime scope
var provider = services.BuildServiceProvider();
var i1 = provider.GetRequiredService<I1>();
var i2 = provider.GetRequiredService<I2>();
Console.WriteLine(i1 == i2); //True
But you can use Autofac to replace the default service provider that can easily do it.
var builder = new ContainerBuilder();
builder.RegisterType<C>().AsImplementedInterfaces().SingleInstance();
var container = builder.Build();
var i1 = container.Resolve<I1>();
var i2 = container.Resolve<I2>();
Console.WriteLine(i1 == i2); //true
As for your DbContext classes, you could register it manually:
builder
.RegisterType<CustomerDb>()
.AsSelf() //So that it could be resolved as CustomerDb
.As<CustomDatabase>() //So that it could be resolved as CustomDatabase
.InstancePerLifetimeScope() //Note that EF Core's DbContext is designed to be scoped services
.OwnedByLifetimeScope(); //Dispose when the scope (the request lifetime) is disposed as the default service provider does

Register the context as you have done originally and also include a registration for the derived type using the same lifetime with the factory delegate
services.AddDbContext<CustomerDb>();
services.AddScoped<CustomDatabase>(sp => sp.GetRequiredService<CustomerDb>());

C# Dependency Injection Runtime (dynamic) registration

I am using VS 2017 and .NET Core.
Using Dependency Injection, I would like to register my service at runtime, dynamically. My goal is to write instances of my service that implement the service interface inside of separate assemblies. The servicename/assembly name will then be added to some sort of configuration file (or db table).
My registration code would do something like this:
var ServiceTypeName = LoadServiceAssembly(AssemblyName);
var serviceProvider = new ServiceCollection()
.AddTransient<IDILogger, "ConsoleDILogger">() // <--- Goal
.BuildServiceProvider();
var logger = serviceProvider.GetService(IDILogger);
Clearly, the AddTransient line will not work as such a method does not exist. It does, however, depict the idea. I want to register the type by a string name so that the loader application need not be recompiled everytime I add a new service type.
I cannot seem to find how to do this. Any suggestions would be welcome.
TIA

You could read configured type from the settings, load the required type via reflection and register it in service collection:
// Read from config
var assemblyPath = "...";
var typeName = "...";
var assembly = Assembly.LoadFrom(assemblyPath);
var loggerType = assembly.GetType(typeName);
var serviceProvider = new ServiceCollection()
.AddTransient(typeof(IDILogger), loggerType)
.BuildServiceProvider();
var logger = serviceProvider.GetService<IDILogger>();
Such dynamic approach will not require any recompilation if you add or reconfigure new logger.

That's obviously not possible as is, however, I used something similar to this in a project to avoid having to add each new type to the container:
var assembly = typeof(YourClass).Assembly; // I actually use Assembly.LoadFile with well-known names
var types = assembly.ExportedTypes
// filter types that are unrelated
.Where(x => x.IsClass && x.IsPublic);
foreach (var type in types)
{
// assume that we want to inject any class that implements an interface
// whose name is the type's name prefixed with I
services.AddScoped(type.GetInterface($"I{type.Name}"), type);
}
For your specific case, you could even make this shorter:
var type = assembly.ExportedTypes.First(x => x.Name == runtimeName);
services.AddScoped(typeof(IDILogger), type);

A very genuine question and with references to different answers by users, here's how I have solved in .NET 6
In program.cs added the following
//Register Service Modules to DI
builder.Services.IncludeServiceModule(builder.Configuration);
The called static function contains something like this
public static class ServiceModule
{
public static IServiceCollection IncludeServiceModule(this IServiceCollection services,
IConfiguration configuration)
{
var appServices = System.Reflection.Assembly.Load("FMDeBill.Service").GetTypes().Where(s => s.Name.EndsWith("Service") && s.IsInterface == false).ToList();
foreach (var appService in appServices)
//services.AddTransient(appService.GetInterface($"I{appService.Name}"), appService);
services.Add(new ServiceDescriptor(appService, appService, ServiceLifetime.Scoped));
return services;
}
}
The assembly name is the name of the project/assembly with services. Any service that is not an interface and ends with "Service" such as "CategoryService" is registered dynamically.

Auto-Register Dependency Injected Services in .NET Core
I wrote this method to auto-register all your services and consumer interfaces and classes at runtime for Dependency Injection by the IoC Container in .NET. All you have to do is add your interfaces and/or concrete classes to the enums lists below and the RegisterServices() method will add them for dependency injection in your .NET application. You can then add them to constructors or call them for dependency injection by .NET.
I chose to load services from an enum rather than say a JSON or other configuration file for security reasons. It also reduces dependencies and also locks the applications state, as well as forces development to lock the app to compilation. Developers must modify, add, remove service types and keep them closely coupled to the code. Changing a configuration file is too dangerous!
LET'S BEGIN
You will need to create two files then change the Startup.cs file in .NET.
Create a file called ServiceList.cs in .NET. This one is just a couple enums where you can add your list of types you want registered as services or consumers of services. If you have many classes that inherit from an Interface, just add lists of those in services. But it will accept concrete types, as well. But if you add an interface, the RegisterServices method below will locate all the child classes that implement the interface and register those, as well. The RegisterServices() method will grab them and register all your services with the IoC in .NET for you.
// ADD SERVICES YOU WANT REGISTERED
enum ServicesList
{
ISampleService,
IAnotherService,
AConcreteClassService
}
// ADD CONSUMERS YOU WANT REGISTERED
enum ConsumersList
{
MyClass1,
MyClass2,
ISomeConsumerTypes
}
Create a second class file called RegisterServices.cs. Add the following code. This is the main method that registers all the services listed in the enums above. It is called RegisterServices.cs.
// REGISTER SERVICES
// This will pull all the services you added to the ServicesList.cs
// enum and try and register them with the Services Provider in .NET
static class RegisterServices
{
// You can add the Logger here if you like.
internal static void Start(IServiceCollection services, ILogger logger = null)
{
// Extract out all service enum values into a single list.
List<string> allTypesToAdd = new List<string>();
allTypesToAdd.AddRange(Enum.GetNames(typeof(ServicesList)).ToList());
allTypesToAdd.AddRange(Enum.GetNames(typeof(ConsumersList)).ToList());
// For now I am just getting the active running assembly
Assembly assembly = Assembly.GetExecutingAssembly();
IEnumerable<TypeInfo> assemblyTypes = assembly.DefinedTypes;
List<string> missingEnumTypes = new List<string>();
bool isTypeFound = false;
// Loop through all services in the collection.
// If your service type is not listed, add it.
foreach (string typeToAdd in allTypesToAdd)
{
// Verify the enum type to add to the service collection exists in the application.
isTypeFound = false;
foreach (TypeInfo type in assemblyTypes)
{
if (type.Name == typeToAdd)
{
if (type.IsInterface)
{
// Add the Interface and any concrete classes
// that are implementations of the parent interface.
var childOfInterface = assembly.GetTypes().Where(t => type.AsType().IsAssignableFrom(t));
foreach (Type c in childOfInterface)
{
if (typeToAdd != c.Name)
{
// For now this just assumes you need a request
// scoped service lifetime services. Change as needed.
services.TryAddScoped(type.AsType(), c);
logger?.LogInformation(LogEventIDs.Information_General_ID, "INFORMATION: A new Service Class Was Added: services.TryAddScoped(" + typeToAdd + "," + c.Name + ")");
}
}
} else {
// Only add the concrete class
// For now just use scoped service lifetime
services.TryAddScoped(type.AsType());
logger?.LogInformation(LogEventIDs.Information_General_ID, "INFORMATION: A new Service Class Was Added: services.TryAddScoped(" + typeToAdd + ")");
}
isTypeFound = true;
break;
}
}
// If users added types in the enum lists
// thats not found, flag as a warning!
if (!isTypeFound)
{
missingEnumTypes.Add(typeToAdd);
}
}
// If a bad enum service name was added, log that as a warning.
if (missingEnumTypes.Count > 0)
{
string items = string.Empty;
foreach (string s in missingEnumTypes)
{
if (items != string.Empty) items += " | ";
items += s;
}
logger?.LogWarning(LogEventIDs.Warning_General_ID, "WARNING: These Types/Interfaces/Classes added to Services were not found in the application >>> " + items);
}
}
}
Register Services consumes the enum list of Services and Consumers above.
The last step is to call the method above inside your Startup.cs .NET file in Core. Add RegisterServices.Start() static method call with your ConfigureServices class inside Startup.cs in the root of your .NET Core application. I also add the logger as a parameter but this version just use the services parameter. "services" is whatever the parameter is in your
ConfigureServices method in Startup.cs:
RegisterServices.Start(services);
HOW TO USE DEPENDENCY INJECTION
After you run RegisterServices in your .NET application and Startup.cs calls it, all your services (and child classes derived from interfaces) are now registered!
To call a Service and have it auto-implemented when you instantiate a class in .NET appears to be inconsistent. The IoC Container will auto-inject all constructor services in MVC Controllers, for example, but NOT regular classes. To solve that I recommend you try and inject everything into your controllers, then use the IServiceProvider in regular class constructors to help you auto-inject all other classes with the services they need (see below).
If you are in ASP.NET Core, your best strategy is to ALWAYS add each service to your controller's constructor using interfaces. You can then have full access to every service you need or any service a child object inside the controller might need. But there will be times you have classes you call outside the controllers that inject services but are not auto-injected. So below are some examples of how to do that and still honor the dependency injection model.
Note: If you are an expert at this, please suggest below in comments how I can improve on this idea, as this is the best model I have for now that is simple and easy to use.
// HOW TO USE SERVICES?
// CONTROLLERS (Web Applications)
// Always inject the services you need into the controller's constructor.
// The IoC Container in .NET always auto-injects these objects
// for you and are 100% ready to access. If using ASP.NET, always use the
// constructor of the controller to inject services.
public class HomeController : BaseController
{
private readonly ISampleService _myservice;
public HomeController(ISampleService myservice){
_myservice = myservice;
}
// You can now access your "_myservice" in any action method of the controller
}
// NON-CONTROLLERS and NON-INJECTED CONSTRUCTORS
// If you cant inject the service object into an ASP.NET Controller
// but still need to instantiate the object, your best alternative
// is to inject the ServiceProvider into your Controller or Class
// constructor first. IoC auto-injects the service collection
// so you can now access it to create child objects you can
// tell .NET to auto-inject with their own services when created
// using the registered services in your enum as an example.
public MyClass (IServiceProvider myservice) {
// Here are 3 ways to force the IoC to auto-inject your dependencies
var obj1 = myservice.GetService<SampleService>();
var obj2 = myservice.GetService(SampleService) as ISampleService;
var obj3 = myservice.GetRequiredService(SampleService) as ISampleService;
var obj4 = (SampleService)myservice.GetService(typeof(SampleService));
}
Below is one of the Service Interface types in the enum above and the child classes that got registered which are now available to use as services in the code above after running the RegisterServices call:
// SERVICE INTERFACE
public interface ISampleService
{
void Message(string message);
}
// SERVICE CONCRETE CLASS
class SampleService : ISampleService
{
public void Message(string message)
{
Console.WriteLine($"{message}");
}
}
// SERVICE CONCRETE CLASS
class AnotherSampleService : ISampleService
{
public void Message(string message)
{
Console.WriteLine($"{message}");
}
}

You can use factory to achieve that.
services.AddScoped(provider =>
{
//Resolve some service at runtime.
var aService = provider.GetService<AServiceType>();
//Any synchronous logic here
return new MyDynamicService();
});

How to get DbContext in nested methods using Simple Injector

I have a doubt since I'm new to Dependency Injection and IoC.
I have a domain layer (with business logic) and a data layer. We do not implement repositories, we use EF Core directly.
It is a Class Library project, we use it in a ASP.NET CCore Web API, WinForms, and inside another framework.
The idea is to use the same context inside a scope.
The problem is that I'm not being able to get the same context in the nested method execution, I'm sure it is because I did not understand the concept completely, can you guys give me a help on that?
Example:
public class MyTest
{
public void TestContainer()
{
var parentContext = MyContainer.Container.GetInstance<MyContext>();
TestParentAndChildContext(parentContext);
}
private void TestParentAndChildContext(MyContext parentContext)
{
var childContext = MyContainer.Container.GetInstance<MyContext>();
Assert.AreEqual(parentContext, childContext);
}
}
public class MyContainer
{
public static Container Container
{
get { return container ?? (container = RegisterAndVerifyContainer()); }
}
private static Container RegisterAndVerifyContainer()
{
var container = new Container();
container.Options.DefaultScopedLifestyle = new ExecutionContextScopeLifestyle();
container.Register<DbContext, MyContext>(Lifestyle.Scoped);
container.Verify();
return container;
}
}

In Simple Injector you register an implementation by its abstraction. In your case you registed an MyContext by its DbContext base type. From this point on Simple Injector will know that it will need to construct a MyContext in case someone asks for a DbContext. This is the whole purpose of
Program to an interface, not an implementation
In your case however, although you do register the MyContext by its abstraction, you request a new instance of MyContext directly, instead of requesting it through its abstraction. This causes Simple Injector to look for the MyContext in its list of registered abstractions. Since there is no registration for MyContext (there is for DbContext though, but that's a totally different type what Simple Injector is concerned), Simple Injector will try to add the missing registration. This succeeds because MyContext is concrete and has single resolvable constructor, while you are using Simple Injector v4.x.
By default the older versions of Simple Injector will resolve unregistered concrete types as Transient. This default changed in v5, where it won't create any unregistered concrete type by default.
So MyContext is resolved as transient when requested directly. You can solve this by changing your test to the following:
public void TestContainer()
{
using (MyContainer.Container.BeginExecutionContextScope()) {
var parentContext = MyContainer.Container.GetInstance<DbContext>();
TestParentAndChildContext(parentContext);
}
}
private void TestParentAndChildContext(MyContext parentContext)
{
var childContext = MyContainer.Container.GetInstance<DbContext>();
Assert.AreEqual(parentContext, childContext);
}
Do note that Simple Injector usually detects these kinds of mistakes. In case you register MyContext by its DbContext base type, but inject MyContext directly in a constructor of a type, Simple Injector will throw a Short-Circuited Dependency error when calling Verify().
The reason you didn't get warned about this, is because you've called Verify() before the resolve action (you should typically not call GetInstance from within your application; instead you should build all object graphs up front). But when you'd call Verify (again) after resolving MyContext you would see the exception popping up:
[TestMethod]
public void TestContainer()
{
var container = MyContainer.Container.GetInstance<DbContext>();
var parentContext = container.GetInstance<MyContext>();
var childContext = container.GetInstance<MyContext>();
// This call will fail
container.Verify();
}

StructureMap not possible to use injected instance for setter injection

I am having a problem with injecting an instance into structuremap for my tests.
My objects graph looks like this
internal class ConfigurationManager : IConfigurationManager : IManager
{
public ISomeManager SomeManager { get; set; }
}
internal class SomeManager : ISomeManager : IManager
{
public IConfigurationManager ConfigurationManager { get; set; }
}
1) first i create the container and add all found registries
_container = new Container(c => c.Scan(s =>
{
s.TheCallingAssembly();
s.LookForRegistries();
}));
one of these scanned assemblies contains the following registration
x.For<IConfigurationManager>().Singleton.Use<ConfigurationManager>();
2) then i want to inject a special mock object for this managers
_configurationManagerStub = MockRepository.GenerateStub<IConfigurationManager>();
_container.Inject(_configurationManagerStub);
3) Then the manager instances are created without setter injection configured (to avoid circular dependencies)
foreach (Type pluginType in AllManagers())
{
managerInstances.Add(_container.GetInstance(pluginType));
}
4) at last I use the BuildUp method to set the Properties of type IManager.
_container.Configure(x => x.SetAllProperties(c =>
{
// configure the property injection for all managers
c.Matching(prop => typeof(IManager).IsAssignableFrom(prop.PropertyType));
}));
// push in dependencies -> EXCEPTION
managerInstances.ForEach(x => _container.BuildUp(x));
Unfortunatly in the last line of code i get the following exception.
StructureMap.StructureMapException : StructureMap Exception Code: 245
Error while trying to create an InstanceBuilder for
IConfigurationManagerProxyd079980359cf491b821a3afb15be8a86,
DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral,
PublicKeyToken=null ----> System.ArgumentException : Expression of
type 'System.Object' cannot be used for parameter of type
'System.String' of method 'Castle.Core.Interceptor.IInterceptor[]
GetIInterceptor[]'
Why does structuremap try to use an InstanceBuilder when I did inject the instance?
Br,
David

The issue is with StructureMap support of Castle DynamicProxy (Rhino Mocks and Moq uses it) generated stubs when used in BuildUp.
Specifically Castle generates a constructor with 2 parameters for requested proxy type and those parameters don't have names. ConstructorFunctionBuilder within StructureMap fails to create proper lambda expression in such case (null is treated as System.Object where System.String is expected). Thats not even needed when you just want to setup property setters, but there is no way to control this.
The "Inject" will work with non-dynamically generated stubs, but you might wanna look for a different solution.