Dependency injection is baked in the ASP.Net Core projects (yes, I still call it Core), but it's missing from console app templates. And while it is easy to add, it's not that clear cut on how to do it. I present here three ways to do it:
The fast one: use the Worker Service template and tweak it to act like a console application
The simple one: use the Console Application template and add dependency injection to it
The hybrid: use the Console Application template and use the same system as in the Worker Service template
Tweak the Worker Service template
It makes sense that if you want a console application you would select the Console Application template when creating a new project, but as mentioned above, it's just the default template, as old as console apps are. Yet there is another default template, called Worker Service, which almost does the same thing, only it has all the dependency injection goodness baked in, just like an ASP.Net Core Web App template.
So start your Visual Studio, add a new project and choose Worker Service:
It will create a project containing a Program.cs, a Worker.cs and an appsettings.json file. Program.cs holds the setup and Worker.cs holds the code to be executed.
Worker.cs has an ExecuteAsync method that logs some stuff every second, but even if we remove the while loop and add our own code, the application doesn't stop. This might be a good thing, as sometimes we just want stuff to work until we press Ctrl-C, but it's not a console app per se.
In order to transform it into something that works just like a console application you need to follow these steps:
inject an IHost instance into your worker
specifically instruct the host to stop whenever your code has finished
So, you go from:
public class Worker : BackgroundService
{
private readonly ILogger<Worker> _logger;
public Worker(ILogger<Worker> logger)
{
_logger = logger;
}
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
while (!stoppingToken.IsCancellationRequested)
{
_logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
await Task.Delay(1000, stoppingToken);
}
}
}
Note that I did not "await" the StopAsync method because I don't actually need to. You are telling the host to stop and it will do it whenever it will see fit.
If we look into the Program.cs code we will see this:
public class Program
{
public static void Main(string[] args)
{
CreateHostBuilder(args).Build().Run();
}
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureServices((hostContext, services) =>
{
services.AddHostedService<Worker>();
});
}
I don't know why they bothered with creating a new method and then writing it as an expression body, but that's the template. You see that there is a lambda adding dependencies (by default just the Worker class), but everything starts with Host.CreateDefaultBuilder. In .NET source code, this leads to HostingHostBuilderExtensions.ConfigureDefaults, which adds a lot of stuff:
environment variables to config
command line arguments to config (via CommandLineConfigurationSource)
support for appsettings.json configuration
logging based on operating system
That is why, if you want these things by default, your best bet is to tweak the Worker Service template
Add Dependency Injection to an existing console application
Some people want to have total control over what their code is doing. Or maybe you already have a console application doing stuff and you just want to add Dependency Injection. In that case, these are the steps you want to follow:
create a ServiceCollection instance (needs a dependency to Microsoft.Extensions.DependencyInjection)
register all dependencies you want to use to it
create a starting class that will execute stuff (just like Worker above)
register starting class in the service collection
build a service provider from the collection
get an instance of the starting class and execute its one method
Here is an example:
class Program
{
static void Main(string[] args)
{
var services = new ServiceCollection();
ConfigureServices(services);
services
.AddSingleton<Executor,Executor>()
.BuildServiceProvider()
.GetService<Executor>()
.Execute();
}
private static void ConfigureServices(IServiceCollection services)
{
services
.AddSingleton<ITest, Test>();
}
}
public class Executor
{
private readonly ITest _test;
public Executor(ITest test)
{
_test = test;
}
public void Execute()
{
_test.DoSomething();
}
}
The only reason we register the Executor class is in order to get an instance of it later, complete with constructor injection support. You can even make Execute an async method, so you can get full async/await support. Of course, for this example appsettings.json configuration or logging won't work until you add them.
Mix them up
Of course, one could try to get the best of both worlds. This would work kind of like this:
use Host.CreateDefaultBuilder() anyway (needs a dependency to Microsoft.Extensions.Hosting), but in a normal console app
use the resulting service provider to instantiate a starting class
The Executor class would be just like in the section above, but now you get all the default logging and configuration options from the Worker Service section.
Conclusion
What the quickest and best solution is depends on your situation. One could just as well start with a Worker Service template, then tweak it to never Run the builder and instead configure it as above. One can create a Startup class, complete with Configure and ConfigureServices as in an ASP.Net Core Web App template or even start with such a template, then tweak it to work as a console app/web hybrid. In .NET Core everything is a console app anyway, it's just depends on which packages you load and how you configure them.
A funny feature that I've encountered recently. It's not something most people would find useful, but it helps tremendously with tracing and debugging what is going on. It's easy, just add .TagWith(someString) to your LINQ query and it will generate comments in SQL. More details here: Query tags.
It all started with the source code for NonCapturingTimer, a static factory class that was creating a System.Threading.Timer without capturing the execution context and was described as "A convenience API for interacting with System.Threading.Timer in a way that doesn't capture the ExecutionContext. We should be using this (or equivalent) everywhere we use timers to avoid rooting any values stored in asynclocals.". What did that even mean?
An issue opened by David Fowler sheds some light on this: "Any lazy activation of timers will capture the ExecutionContext. Combining this with a lazy initialization of the HttpClient and the handler graph may end up holding onto AsyncLocals for longer than expected. This could end up looking like a memory leak". This follows a Twitter thread from Fowler declaring AsyncLocal as evil.
And if you look at the ASP.Net sources on GitHub, they do use the class mostly for one time timer calls and periodic cleanup calls. I should mention that Ben Adams from Microsoft calls this way of creating timers ugly.
I don't have the time to go down further on this rabbit hole, but maybe people will find answers here when looking into this and comment on their findings.
The problem described here was slightly false. The issue was that IOptionsSnapshot was registered as Scoped and I was just getting the service from the root IServiceProvider. The solution is to call provider.CreateScope() and with that scope as a provider use ActivatorUtilities. Even better, create a scope, then use it to get an instance of a business class that now would support Scoped services as well as Transient, just like a Controller would.
Warning, though: you need to dispose the scope, but you need to make sure you don't use any service that was created there outside the scope (after disposing).
I guess another solution would be to somehow register IOptionsSnapshot<> as transient, but haven't tried it.
And now for the original post
I was trying to create an instance of an object from a service provider to resolve any dependencies, using ActivatorUtilities.CreateInstance<MyObject>(_serviceProvider) and I was getting the exception:
System.InvalidOperationException HResult=0x80131509 Message=Cannot resolve scoped service 'Microsoft.Extensions.Options.IOptionsSnapshot`1[ExternalConfiguration]' from root provider.
My object was receiving a parameter of type IOptionsSnapshot<ExternalConfiguration> and upon further investigation, my service provider (which came as a resolution from the dependency injection for IServiceProvider) was actually a ServiceProviderEngineScope which just refused to resolve any IOptionsSnapshot! Funny enough, if I replaced IOptionsSnapshot with IOptionsMonitor, which in my mind is a heavier interface, it worked without issues. Further still, the problem appeared only inside an IHostedService (a BackgroundService hooked up with services.AddHostedService<T>); if I wrote the same code in a controller action, for instance, it worked fine.
The .NET 2+ implementation of IOptionsSnapshot<T> is OptionsManager<T>. If I manually resolved an instance of OptionsManager before my object, then added it as a parameter, the code worked:
var optionsSnapshot = ActivatorUtilities.CreateInstance<OptionsManager<TestOptions>>(_serviceProvider); var myObject = ActivatorUtilities.CreateInstance<MyObject>(_serviceProvider, optionsSnapshot);
So, specifically, the issue is that in .NET Core, the service provider implementation cannot resolve IOptionsSnapshot interfaces in worker services. You can still do that manually, but I suspect it is a bug, since there is no problem using an IOptionsMonitor instead of IOptionsSnapshot.
A possible solution is to use an additional service provider only for IOptionsSnapshot. Warning, this will not work in a general situation if the dependencies from the additional service provider also need parameters that would be found in the original service provider:
// initialization code var serviceCollection = new ServiceCollection(); serviceCollection.AddSingleton( typeof(IOptionsSnapshot<>), typeof(OptionsManager<>) ); serviceCollection.AddSingleton( typeof(IOptionsFactory<>), typeof(OptionsFactory<>) ); _additionalServiceProvider = serviceCollection.BuildServiceProvider();
.NET Core comes with its own dependency injection engine, separated in the Microsoft.Extensions.DependencyInjection package, and ASP.Net Core uses it by default. In a very simplistic description, it uses an IServiceCollection to add services to, then it builds an IServiceProvider from that list, an interface which returns an implementation based on a type or null if finding none. Any change in the list of services is not supported. There are situations, though, where you want to add new services. One of them being dynamically resolving new types.
Therefore I set up to create a custom implementation of IServiceProvider that fixes that, using the mechanisms already existing in .NET Core. Note that this is just something I did from frustration, "because I could". Most people choose to replace the entire IServiceProvider with an implementation that uses some other DI container, like StructureMap.
First attempt was proxying a normal ServiceProvider and keeping a reference to the collection. Then I would just change the collection and recreate the service provider. That has two major problems. One is that the previous serviceProvider is not disposed. If you try, you automatically dispose all services already resolved and if you do not, you remain with references to the created services. The second, and more dire, is that recreating the service provider will generate new instances for services, even if registered as singletons. That is not good.
I thought of a solution:
keep a list of service providers, instead of just one
use a custom service collection which will let us know when changes occurred
whenever new services are added, add them to a list of new services
whenever a service is resolved, go through the list of providers
if any provider returns a value, provide it
else if any new service create a new provider from the new services and add it to the list
else return null
when disposing, dispose all providers in the list
This works great except the newly added providers are separate from the existing providers so when you try to resolve a type with a second provider and that type has in its constructor a type that was registered in the first provider, you get nothing.
One solution would be to add all services to the second provider, not only the new ones, but then we get back to the original issue of the singletons, only a bit more subtle:
register type1 as a singleton
get an instance of type1 (1)
build the provider
get an instance of type1 (2)
register type2 which receives a type1 in its constructor
get an instance of type2
now, type1 (1) is the same as type1 (2), because it was resolved by the same provider
type1 is different from type2.type1, though, because that was resolved as a different singleton by the second provider in the list
One solution would be to add all previous services as factories, then. For Itype1, instead of returning typeof(type1), return a factory method that resolves the value with our system. And it works... until it reaches a definition (like IOptions) that was registered as an open generic: services.AddSingleton(typeof(IType3<>),typeof(Type3<>)). In case of open generics, you cannot use a descriptor with a factory, because it returns an object, regardless of the generic type argument used. It would not to do return a Type3<Banana> for a requested type of IType3<int>.
So, final version is this:
keep a list of service providers, instead of just one
keep a dictionary of the last object resolved for a type
use a custom service collection which will let us know when changes occurred
whenever new services are added, add them to a list of new services
whenever a service is resolved, go through the list of providers
if any provider returns a value, return it
if no new services registered return null
create a new provider from all the services like this:
if it's a new registration, use it as is
if it's an open generic definition type:
if singleton, add first all the existing resolutions for types that are defined by it
use the original descriptor afterwards
use a registration that proxies to the advanced resolution mechanism we created
when disposing, dispose all providers in the list
This implementation also has a flaw: if a dependency parameter with a generic type definition descriptor was resolved as a singleton by an additional service provider, then is requested directly and can be resolved by a previous provider, it will return a different instance. Here is the scenario:
the initial provider knows to map I<> to M<>
you add a new singleton mapping from X to Y and Y gets a constructor parameter of type I<Z>
you request an instance of X
the first provider cannot resolve it
the second provider can resolve it, therefore it will also resolve a I<Z> as an M<Z> singleton instance
you request an instance of I<Z>
the first provider can resolve it, therefore it will return a NEW singleton instance of M<Z>
This is an edge case that I don't have the time to solve. So, with the caveat above, here is the final version. Use it like this:
// IAdvancedServiceProvider either injected // or resolved via serviceProvider.GetService<IAdvancedServiceProvider> // or even serviceProvider as IAdvancedServiceProvider advancedServiceProvider.ServiceCollection.AddSingleton...
And this is the source code:
/// <summary> /// Service provider that allows for dynamic adding of new services /// </summary> publicinterface IAdvancedServiceProvider : IServiceProvider { /// <summary> /// Add services to this collection /// </summary> IServiceCollection ServiceCollection { get; } }
/// <summary> /// Service provider that allows for dynamic adding of new services /// </summary> publicclass AdvancedServiceProvider : IAdvancedServiceProvider, IDisposable { private readonly List<ServiceProvider> _serviceProviders; private readonly NotifyChangedServiceCollection _services; private readonly object _servicesLock = new object(); private List<ServiceDescriptor> _newDescriptors; private Dictionary<Type, object> _resolvedObjects;
/// <summary> /// Initializes a new instance of the <see cref="AdvancedServiceProvider"/> class. /// </summary> /// <param name="services">The services.</param> public AdvancedServiceProvider(IServiceCollection services) { // registers itself in the list of services services.AddSingleton<IAdvancedServiceProvider>(this);
_serviceProviders = new List<ServiceProvider>(); _newDescriptors = new List<ServiceDescriptor>(); _resolvedObjects = new Dictionary<Type, object>(); _services = new NotifyChangedServiceCollection(services); _services.ServiceAdded += ServiceAdded; _serviceProviders.Add(services.BuildServiceProvider(true)); }
/// <summary> /// Add services to this collection /// </summary> public IServiceCollection ServiceCollection { get => _services; }
/// <summary> /// Gets the service object of the specified type. /// </summary> /// <param name="serviceType">An object that specifies the type of service object to get.</param> /// <returns>A service object of type serviceType. -or- null if there is no service object of type serviceType.</returns> public object GetService(Type serviceType) { lock (_servicesLock) { // go through the service provider chain and resolve the service var service = GetServiceInternal(serviceType); // if service was not found and we have new registrations if (service == null && _newDescriptors.Count > 0) { // create a new service collection in order to build the next provider in the chain var newCollection = new ServiceCollection(); foreach (var descriptor in _services) { foreach (var descriptorToAdd in GetDerivedServiceDescriptors(descriptor)) { ((IList<ServiceDescriptor>)newCollection).Add(descriptorToAdd); } } var newServiceProvider = newCollection.BuildServiceProvider(true); _serviceProviders.Add(newServiceProvider); _newDescriptors = new List<ServiceDescriptor>(); service = newServiceProvider.GetService(serviceType); } if (service != null) { _resolvedObjects[serviceType] = service; } return service; } }
private IEnumerable<ServiceDescriptor> GetDerivedServiceDescriptors(ServiceDescriptor descriptor) { if (_newDescriptors.Contains(descriptor)) { // if it's a new registration, just add it yieldreturn descriptor; yieldbreak; }
if (!descriptor.ServiceType.IsGenericTypeDefinition) { // for a non open type generic singleton descriptor, register a factory that goes through the service provider yieldreturn ServiceDescriptor.Describe( descriptor.ServiceType, _ => GetServiceInternal(descriptor.ServiceType), descriptor.Lifetime ); yieldbreak; } // if the registered service type for a singleton is an open generic type // we register as factories all the already resolved specific types that fit this definition if (descriptor.Lifetime == ServiceLifetime.Singleton) { foreach (var servType in _resolvedObjects.Keys.Where(t => t.IsGenericType && t.GetGenericTypeDefinition() == descriptor.ServiceType)) {
yieldreturn ServiceDescriptor.Describe( servType, _ => _resolvedObjects[servType], ServiceLifetime.Singleton ); } } // then we add the open type registration for any new types yieldreturn descriptor; }
private object GetServiceInternal(Type serviceType) { foreach (var serviceProvider in _serviceProviders) { var service = serviceProvider.GetService(serviceType); if (service != null) { return service; } } return null; }
/// <summary> /// Dispose the provider and all resolved services /// </summary> publicvoid Dispose() { lock (_servicesLock) { _services.ServiceAdded -= ServiceAdded; foreach (var serviceProvider in _serviceProviders) { try { serviceProvider.Dispose(); } catch { // singleton classes might be disposed twice and throw some exception } } _newDescriptors.Clear(); _resolvedObjects.Clear(); _serviceProviders.Clear(); } }
/// <summary> /// An IServiceCollection implementation that exposes a ServiceAdded event for added service descriptors /// The collection doesn't support removal or inserting of services /// </summary> privateclass NotifyChangedServiceCollection : IServiceCollection { private readonly IServiceCollection _services;
/// <summary> /// Fired when a descriptor is added to the collection /// </summary> publicevent EventHandler<ServiceDescriptor> ServiceAdded;
/// <summary> /// Initializes a new instance of the <see cref="NotifyChangedServiceCollection"/> class. /// </summary> /// <param name="services">The services.</param> public NotifyChangedServiceCollection(IServiceCollection services) { _services = services; }
/// <summary> /// Get the value at index /// Setting is not supported /// </summary> public ServiceDescriptor this[int index] { get => _services[index]; set => thrownew NotSupportedException("Inserting services in collection is not supported"); }
/// <summary> /// Count of services in the collection /// </summary> publicint Count { get => _services.Count; }
/// <summary> /// Obviously not /// </summary> publicbool IsReadOnly { get => false; }
/// <summary> /// Adding a service descriptor will fire the ServiceAdded event /// </summary> /// <param name="item"></param> publicvoid Add(ServiceDescriptor item) { _services.Add(item); ServiceAdded.Invoke(this, item); }
/// <summary> /// Clear the collection is not supported /// </summary> publicvoid Clear() => thrownew NotSupportedException("Removing services from collection is not supported");
/// <summary> /// True is the item exists in the collection /// </summary> publicbool Contains(ServiceDescriptor item) => _services.Contains(item);
/// <summary> /// Copy items to array of service descriptors /// </summary> publicvoid CopyTo(ServiceDescriptor[] array, int arrayIndex) => _services.CopyTo(array, arrayIndex);
/// <summary> /// Enumerator for service descriptors /// </summary> public IEnumerator<ServiceDescriptor> GetEnumerator() => _services.GetEnumerator();
/// <summary> /// Index of item in the list /// </summary> publicint IndexOf(ServiceDescriptor item) => _services.IndexOf(item);
/// <summary> /// Inserting is not supported /// </summary> publicvoid Insert(int index, ServiceDescriptor item) => thrownew NotSupportedException("Inserting services in collection is not supported");
/// <summary> /// Removing items is not supported /// </summary> publicbool Remove(ServiceDescriptor item) => thrownew NotSupportedException("Removing services from collection is not supported");
/// <summary> /// Removing items is not supported /// </summary> publicvoid RemoveAt(int index) => thrownew NotSupportedException("Removing services from collection is not supported");
We already know how to load types in .NET Framework and we know what they say we should use in .NET Core. But what about Standard? Is that a trick question? Sort of. Right now we have two .NET Standard and three .NET Core versions, albeit .NET Core 3 is in preview mode. The signature for AssemblyLoadContext and how it is used has changed dramatically. Core 3 enables context unloading, but Standard 2 does not. So you either are forced to build your library as Core 3 or you have to not use Unloading contexts or use reflection, which is not robust and probably will not be needed with the possible arrival of Standard 3.
But there are subtler issues at work. One of them is that, at least with .NET Core 3 Preview6, when you reference System.Runtime.Loader in a Standard library, so you can access AssemblyLoadContext, you get conflicts between the System.Runtime you are using and the one referenced by System.Runtime.Loader. The only solution is to use the System.Runtime.Loader NuGet package, but that returns you to the Standard 2 version of AssemblyLoadContext, even if the library version is higher!
The setup is this: I have an ITestInterface interface which resides in TestInterfaceLibrary.dll. I also have a TestImplementation class that can be found in TestImplementationLibrary.dll and implements ITestInterface. My program either does not reference any of these libraries or it only references the interface one. The task is to load both these types and then simply convert one instance of TestImplementation to ITestInterface. Simple test would be loading the types and then expecting interfaceType.IsAssignableFrom(implementationType) to be true.
Core 3
Let's first try the Core 3 way:
var context = new AssemblyLoadContext("testContext", true);
var interfaceAssembly = context.LoadFromAssemblyPath(interfaceAssemblyPath); var interfaceType = interfaceAssembly.GetType("TestInterfaceLibrary.ITestInterface"); Console.WriteLine(interfaceType?.ToString()??"interface type not loaded");
var implementationAssembly = context.LoadFromAssemblyPath(implementationAssemblyPath); var implementationType = implementationAssembly.GetType("TestImplementationLibrary.TestImplementation"); Console.WriteLine(implementationType?.ToString() ?? "implementation type not loaded");
It works! But only because the interface assembly is loaded first. If you try to load just the implementation type first, it will come up as empty. There are no exceptions thrown unless you get all the assembly types or specify the throwOnError parameter in GetType. The exception is "System.IO.FileNotFoundException: 'Could not load file or assembly 'TestInterfaceLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.'".
In order to solve this, we need to use the Resolve event of the AssemblyLoadContext class. Let's try this:
var context = new AssemblyLoadContext("testContext", true); context.Resolving += Context_Resolving;
var implementationAssembly = context.LoadFromAssemblyPath(implementationAssemblyPath); var implementationType = implementationAssembly.GetType("TestImplementationLibrary.TestImplementation", true); Console.WriteLine(implementationType?.ToString() ?? "implementation type not loaded");
var interfaceAssembly = context.LoadFromAssemblyPath(interfaceAssemblyPath); var interfaceType = interfaceAssembly.GetType("TestInterfaceLibrary.ITestInterface", true); Console.WriteLine(interfaceType?.ToString() ?? "interface type not loaded");
And now it works again, by assuming the assembly name is the same as the assembly file name and that it is found in the same place.
But... if we try this in different contexts:
var context = new AssemblyLoadContext("testContext", true); context.Resolving += Context_Resolving;
var implementationAssembly = context.LoadFromAssemblyPath(implementationAssemblyPath); var implementationType = implementationAssembly.GetType("TestImplementationLibrary.TestImplementation", true); Console.WriteLine(implementationType?.ToString() ?? "implementation type not loaded");
var interfaceAssembly = context.LoadFromAssemblyPath(interfaceAssemblyPath); var interfaceType = interfaceAssembly.GetType("TestInterfaceLibrary.ITestInterface", true); Console.WriteLine(interfaceType?.ToString() ?? "interface type not loaded");
This means that if we want to encapsulate this in a TypeLoader class or something, we cannot use different contexts for dynamically loading types. Even if we had one context that we would unload in order to refresh all the types, it could still be different from the main context, in case the interface is loaded twice or referenced directly in the project.
For example, if you reference TestInterfaceLibrary directly and you load TestImplementation dynamically it will work as expected, because ITestInterface is resolved automatically from the main context. However, if you load ITestInterface dynamically, too, it will be a different type from the referenced ITestInterface, even if they apparently have the same name and full name and assembly qualified name! So it kind of makes sense to not load a type twice. Is this where the context unloading comes in? Not really. Let's define a method that counts the number of types with a certain name in the current domain as
var context = new AssemblyLoadContext("testContext", true); context.Resolving += Context_Resolving;
var referencedInterfaceType = typeof(ITestInterface); Console.WriteLine(referencedInterfaceType?.ToString() ?? "interface type not loaded");
var interfaceAssembly = context.LoadFromAssemblyPath(interfaceAssemblyPath); var interfaceType = interfaceAssembly.GetType("TestInterfaceLibrary.ITestInterface", true); Console.WriteLine(interfaceType?.ToString() ?? "interface type not loaded");
Console.WriteLine($"Types are the same: {interfaceType==referencedInterfaceType}");
Console.WriteLine($"Number of types with name {interfaceType.FullName}: {CountTypes(interfaceType.FullName)}");
context.Resolving -= Context_Resolving; context.Unload(); Console.WriteLine($"Number of types with name {interfaceType.FullName}: {CountTypes(interfaceType.FullName)}");
There is the referenced type, then we load the type dynamically again, inside a new context. We count the types loaded in the current domain, we unload the context, we count the types again. The result is
TestInterfaceLibrary.ITestInterface TestInterfaceLibrary.ITestInterface Types are the same: False Number of types with name TestInterfaceLibrary.ITestInterface: 2 Number of types with name TestInterfaceLibrary.ITestInterface: 2
The types are always 2!
Bottom line, even when unloading the AssemblyLoadContext, the types used are not unloaded and trying to find a type by name will result in duplicates.
OK, so let's just agree that types with the same name, once loaded, should remain there and no other type with the same name should be loaded. Let's try to incorporate this into a TypeLoader class:
var interfaceAssemblyPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "TestInterfaceLibrary.dll"); var implementationAssemblyPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "TestImplementationLibrary.dll"); var interfaceTypeName = "TestInterfaceLibrary.ITestInterface"; var implementationTypeName = "TestImplementationLibrary.TestImplementation";
using (var loader = new TypeLoader()) { Type referencedType = typeof(TestInterfaceLibrary.ITestInterface); var interfaceType = loader.LoadType(interfaceTypeName, interfaceAssemblyPath); var implementationType = loader.LoadType(implementationTypeName, implementationAssemblyPath); Console.WriteLine($@" referenced type: {referencedType} interface type: {interfaceType} implementation type: {implementationType} referenced and loaded interfaces are the same: {referencedType == interfaceType} interface implemented: {interfaceType.IsAssignableFrom(implementationType)}"); }
and the result is
referenced type: TestInterfaceLibrary.ITestInterface interface type: TestInterfaceLibrary.ITestInterface implementation type: TestImplementationLibrary.TestImplementation referenced and loaded interfaces are the same: True interface implemented: True
But we still use Unload. Maybe it will work some day as I want it to work, but until then, why not get rid of Unload and make TypeLoader a class in a Standard 2 library?
Standard 2
For this I will create a new Standard 2 library project and then reference it in our test Core 3 project. Then I will move the TypeLoader class in the library project.
The errors in the library project are related to not knowing what an AssemblyLoadContext is, therefore the first solution is to reference System.Runtime.Loader from the framework. I get the immediate error "Assembly 'System.Runtime.Loader' with identity 'System.Runtime.Loader, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' uses 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'System.Runtime' with identity 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Solution 2: load the System.Runtime.Loader NuGet package, which at the time of writing this, is version 4.3.0. The error is now gone, but several things are immediately apparent:
the Unload method doesn't exist anymore
the constructor doesn't receive a name and a bool anymore
AssemblyLoadContext is now abstract
In order to solve this I am creating a DynamicAssemblyLoadContext class that inherits from AssemblyLoadContext and just return null from the Load method overload, and I give it an Unload method and a constructor with a string and a bool that don't do anything. And it works again. The updated TypeLoader class is now:
The code above has an issue, though. If the interface type is dynamically loaded before its referenced type is used, this fails again. This is the case when you use dependency injection. You dynamically load the types in order to register the implementation relationship to the interface, but then, when you ask for a resolution for the interface type, now referenced by the main project, you get another type named just the same.
The safe way, considering that we don't really use Unload and we don't count on it every working, why not use the default context, the one where everything loads, and be done with it. When you do that, the code becomes a little uglier, but it works in all situations.
Final version.
publicclass TypeLoader { private readonly object _resolutionLock = new object();
I was under the impression that .NET Framework can only reference .NET Framework assemblies and .NET Core can only reference .NET Core assemblies. After all, that's why .NET Standard appeared, so you can create assemblies that can be referenced from everywhere. However, one can actually reference .NET Framework assemblies from .NET Core (and not the other way around). Moreover, they work! How does that happen?
I chose a particular functionality that works only in Framework: AppDomain.CreateDomain. I've added it to a .NET 4.6 assembly, then referenced the assembly in a .NET Core program. And it compiled!! Does that mean that I can run whatever I want in .NET Core now?
The answer is no. When running the program, I get a PlatformNotSupportedException, meaning that the IL code is executed by .NET Core, but in its own context. It is basically a .NET Standard cheat. Personally, I don't like this, but I guess it's a measure to support adoption of the Core concept.
What goes on behind the scenes is that .NET Core implements .NET Standard, which can reference .NET Framework assemblies. For this to work you need .NET Core 2.0 and Visual Studio 2017 15.3 or higher.
In .NET APIs we usually adorn the action methods with [Http<HTTP method>] attributes, like HttpGetAttribute or AcceptVerbsAttribute, to set the HTTP methods that are accepted. However, there are conventions on the names of the methods that make them work when such attributes are not used. How does ASP.Net determine which methods on a controller are considered "actions"? The documentation explains this, but the information is hidden in one of the paragraphs:
Attributes as described above: AcceptVerbs, HttpDelete, HttpGet, HttpHead, HttpOptions, HttpPatch, HttpPost, or HttpPut.
Through the beginning of the method name: "Get", "Post", "Put", "Delete", "Head", "Options", or "Patch"
You created a library in .NET Core and you want it to be usable for .NET Framework or Xamarin as well, so you want to turn it into a .NET Standard library. You learn that it is simple: a matter of changing the TargetFramework in the .csproj file, so you do this for all projects in the solution.
But .NET Standard is only designed for libraries, so it makes no sense to change the TargetFramework for other types of projects, including some that are in fact libraries, but are not used as such, like unit test projects.
For example if you attempt to run XUnit tests in Visual Studio you will see that the tests are discovered by Test Explorer, but when you try to run them it says "No test is available in [your project]. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.". While this is an issue with XUnit, more likely, it is also a non-issue, since your test project should use the .NET Standard libraries, not be one itself.
I did something and suddenly my API was not run in IIS Express anymore, but in Kestrel. I reviewed code changes, configuration changes, all to now avail. I don't want Kestrel, I want IIS Express!!! Why did Visual Studio suddenly decided to switch the development server?
Solution: it is your Visual Studio. The button you use to start debugging has a little dropdown that allows you to choose which server to use. I had probably pressed the wrong one at some point.
use the authentication in Configure (above app.UseAuthorization();)
app.UseAuthentication();
No need to UseIISIntegration, UseHttpSys or anything.
Original post:
If you get the System.InvalidOperationException "No authenticationScheme was specified, and there was no DefaultChallengeScheme found." it means that ... err... you don't have a default authentication scheme. Solution:
Install NuGet package Microsoft.AspNetCore.Authentication in your project
Update: Note that this is for IIS integration. If you want to use self hosted or Kestrel in debug, you should use HttpSysDefaults.AuthenticationScheme. Funny though, it's the same string value for both constants: "Windows".
Oh, and if you enter the credentials badly when prompted and you can't reenter them, try to restart Chrome (as in this answer)
I was working on this web ASP.Net Core 2.0 project that was spewing a lot of "Application Insights Telemetry (unconfigured): ..." messages in the Debug Output window. At first I thought I should just remove the Microsoft Application Insights NuGet package, but it didn't work. By default, it will still use insights even if you don't have it referenced anywhere in your code.
The solution is to do have installed Microsoft Application Insights NuGet package, but then set
somewhere in Startup.cs (the constructor is fine).
Apparently, in the preview versions of Visual Studio 2017 there is an option under Options → Projects and Solutions → Web Projects → Disable local Application Insights for Asp.net Core web projects, too.
Either of these works, and although I agree with Andrei that the underlying issue for the unwanted telemetry is the automatic loading of hosting assemblies, I feel like the first option, the one that actually contains the word Telemetry in it is better for reasons of readability. But it's good there are three options to choose from.
Started with the idea of a project that would use user configurable queries to do Google searches, store the information in the results and then perform various data analysis on them and display them based on what the user wants. However, I first implemented a Google authentication and then went to write some theoretical posts. Lastly, I've upgraded the project from .NET Core 1.0 to version 1.1.
Well, it took me a while to get here because I was at a crossroads. I like the idea of dependency injectable services to do data access. At the same time there is the entire Entity Framework tutorial path that kind of wants to strongly integrate EF with my projects. I mean, if I have a service that gives me the list of all items in the database and then I want to get only a few items, it would be bad design to filter the entire list. As such, I would have to write a different method that allows me to get the items based on some kind of filters. On the other hand, Entity Framework code looks just like that "give me all you have, filtered by this" which is then translated into an efficient query to the database. One possibility would be to have my service return IQueryable <T>, so I could also use the system to generate the database code on the fly.
The Design
I've decided on the service architecture, against an EF type IQueryable way, because I want to be able to replace that service with anything, including something that doesn't work with a database or something that doesn't know how to dynamically create queries. Also, the idea that the service methods will describe exactly what I want appeals to me more than avoiding a bit of duplicated code.
Another thing to define now is the method through which I will implement the dependency injection. Being the control freak that I am, I would go with installing my own library, something like SimpleInjector, and configure it myself and use it explicitly. However, ASP.Net Core has dependency injection included out of the box, so I will use that.
As defined, the project needs queries to pass on to Google and a storage service for the results. It needs data services to manage these entities, as well as a service to abstract Google itself. The data gathering operation itself cannot be a simple REST call, since it might take a while, it must be a background task. The data analysis as well. So we need a sort of job manager.
As per a good structured design, the data objects will be stored in a separate project, as well as the interfaces for the services we will be using.
Some code, please!
Well, start with the code of the project so far: GitHub and let's get coding.
Before finding a solution to actually run the background code in the context of ASP.Net, let's write it inside a class. I am going to add a folder called Jobs and add a class in it called QueryProcessor with a method ProcessQueries. The code will be self explanatory, I hope.
publicvoid ProcessQueries() { var now = _timeService.Now; var queries = _queryDataService.GetUnprocessed(now); var contentItems = queries.AsParallel().WithDegreeOfParallelism(3) .SelectMany(q => _contentService.Query(q.Text)); _contentDataService.Update(contentItems); }
So we get the time - from a service, of course - and request the unprocessed queries for that time, then we extract the content items for each query, which then are updated in the database. The idea here is that, for the first time a query is defined or when the interval from the last time the query was processed, the query will be sent to the content service from which content items will be received. These items will be stored in the database.
Now, I've kept the code as concise as possible: there is no indication yet of any implementation detail and I've written as little code as I need to express my intention. Yet, what are all these services? What is a time service? what is a content service? Where are they defined? In order to enable dependency injection, we will populate all of these fields from the constructor of the query processor. Here is how the class would look in its entirety:
using ContentAggregator.Interfaces; using System.Linq;
publicvoid ProcessQueries() { var now = _timeService.Now; var queries = _queryDataService.GetUnprocessed(now); var contentItems = queries.AsParallel().WithDegreeOfParallelism(3) .SelectMany(q => _contentService.Query(q.Text)); _contentDataService.Update(contentItems); } } }
Note that the services are only defined as interfaces which we declare in a separate project called ContentAggregator.Interfaces, referred above in the usings block.
Let's ignore the job processor mechanism for a moment and just run ProcessQueries in a test method in the main controller. For this I will have to make dependency injection work and implement the interfaces. For brevity I will do so in the main project, although it would probably be a good idea to do it in a separate ContentAggregator.Implementations project. But let's not get ahead of ourselves. First make the code work, then arrange it all nice, in the refactoring phase.
Implementing the services
I will create mock services first, in order to test the code as it is, so the following implementations just do as little as possible while still following the interface signature.
They are all transient, meaning that for each request of an implementation the system will just create a new instance. Another popular method is AddSingleton.
Using dependency injection
So, now I have to instantiate my query processor and run ProcessQueries.
One way is to set QueryProcessor as a service. I extract an interface, I add a new binding and then I give an interface as a parameter of my controller constructor:
In fact, I don't even have to declare an interface. I can just use services.AddTransient<QueryProcessor>(); in ConfigureServices and it works as a parameter to the controller.
But what if I want to use it directly, resolve it manually, without injecting it in the controller? One can use the injection of a IServiceProvider instead. Here is an example:
Yet you still need to use services.Add... in ConfigureServices and inject the service provider in the constructor of the controller.
There is a way of doing it completely separately like this:
var serviceProvider = new ServiceCollection() .AddTransient<ITimeService, TimeService>() .AddTransient<IContentDataService, ContentDataService>() .AddTransient<IContentService, ContentService>() .AddTransient<IQueryDataService, QueryDataService>() .AddTransient<QueryProcessor>() .BuildServiceProvider(); var queryProcessor = serviceProvider.GetService<QueryProcessor>();
This would be the way to encapsulate the ASP.Net Dependency Injection in another object, maybe in a console application, but clearly it would be pointless in our application.
The complete source code after these modifications can be found here. Test the functionality by going to /test on your local server after you start the app.
It is about time to revisit my series on ASP.Net MVC Core. From the time of my last blog post the .Net Core version has changed to 1.1, so just installing the SDK and running the project was not going to work. This post explains how to upgrade a .Net project to the latest version.
Pressing the batch Update button for NuGet packages corrupted project.json. Here are the steps to successfully migrate a .Net Core project to a higher version.
Change the version of the SDK in global.json - you can find out the SDK version by creating a new .Net Core project and checking what it uses
Change "netcoreapp1.0" to "netcoreapp1.1" in project.json
Change Microsoft.NETCore.App version from "1.0.0" to "1.1.0" in project.json
Add
"runtimes": { "win10-x64": { } },
to project.json
Go to "Manage NuGet packages for the solution", to the Update tab, and update projects one by one. Do not press the batch Update button for selected packages
Some packages will restore, but remain in the list. Skip them for now
Whenever you see a "downgrade" warning when restoring, go to those packages and restore them next
For packages that tell you to upgrade NuGet, ignore them, it's an error that probably happens because you restore a package while the previous package restoring was not completed
For the remaining packages that just won't update, write down their names, uninstall them and reinstall them
That should do it. For detailed steps of what I actually did to get to this concise list, read on.
Long version
Step 0 - I don't care, just load the damn project!
Downloaded the source code from GitHub, loaded the .sln with Visual Studio 2015. Got a nice blocking alert, because this was a .NET Core virgin computer: Of course, I could have tried to install that version, but I wanted to upgrade to the latest Core.
If your application is referencing the .NET Core framework, your should update the references in your project.json file for netcoreapp1.0 or Microsoft.NetCore.App version 1.0 to version 1.1. In the default project.json file for an ASP.NET Core project running on the .NET Core framework, these two updates are located as follows:
Two places to update project.json to .NET Core 1.1
to be continued...
I got to the second step, but still got the alert...
Step 2 - fumble around
... so I commented out the sdk property in global.json. I got another alert:
This answer recommended uninstalling old versions of SDKs, in my case "Microsoft .NET Core 1.0.1 - SDK 1.0.0 Preview 2-003131 (x64)". Don't worry, it didn't work. More below:
TL;DR; version: do not uninstall the Visual Studio .NET Core Tooling
And then... got the same No executable found matching command "dotnet=projectmodel-server" error again.
I created a new .NET core project, just to see the version of SDK it uses: 1.0.0-preview2-003131 and I added it to global.json and reopened the project. It restored packages and didn't throw any errors! Dude, it even compiled and ran! But now I got a System.ArgumentException: The 'ClientId' option must be provided. Probably it had something to do with the Secret Manager. Follow the steps in the link to store your secrets in the app. It then worked.
Step 1.1 (see what I did there?) - continue to read the Microsoft documentation
The third step in the Microsoft instructions was removed by me because it caused some problems to me. So don't do it, yet. It was
Update your ASP.NET Core packages dependencies to use the new 1.1.0 versions. You can do this by navigating to the NuGet package manager window and inspecting the “Updates” tab for the list of packages that you can update.
Updating Packages using the NuGet package manager UI with the last pre-release build of ASP.NET Core 1.1
Since I had not upgraded the packages, as in the Microsoft third step, I decided to do it. 26 updates waited for me, so I optimistically selected them all and clicked Update. Of course, errors! One popped up as more interesting: Package 'Microsoft.Extensions.SecretManager.Tools 1.0.0' uses features that are not supported by the current version of NuGet. To upgrade NuGet, see http://docs.nuget.org/consume/installing-nuget. Another was even more worrisome: Unexpected end of content while loading JObject. Path 'dependencies', line 68, position 0 in project.json. Somehow the updating operation for the packages corrupted project.json! From a 3050 byte file, it now was 1617.
Step 3 - repair what the Microsoft instructions broke
Suspecting it was a problem with the NuGet package manager, I went to the link in the first error. But in Visual Studio 2015 NuGet is included and it was clearly the latest version. So the only solution was to go through each package and see which causes the problem. And I went to 26 packages and pressed Install on each and it worked. Apparently, the batch Update button is causing the issue. Weirdly enough there are two packages that were installed, but remained in the Update tab and also appeared in the Consolidate tab: BundleMinifier.Core and Microsoft.EntityFrameworkCore.Tools, although I can't to anything with them there.
Another package (Microsoft.VisualStudio.Web.CodeGeneration.Tools 1.0.0) caused another confusing error: Package 'Microsoft.VisualStudio.Web.CodeGeneration.Tools 1.0.0' uses features that are not supported by the current version of NuGet. To upgrade NuGet, see http://docs.nuget.org/consume/installing-nuget. Yet restarting Visual Studio led to the disappearance of the CodeGeneration.Tools error.
So I tried to build the project only to be met with yet another project.json corruption error: Can not find runtime target for framework '.NETCoreAPP, Version=v1.0' compatible with one of the target runtimes: 'win10-x64, win81-x64, win8-x64, win7-x64'. Possible causes: [blah blah] The project does not list one of 'win10-x64, win81-x64, win7-x64' in the 'runtimes' [blah blah]. I found the fix here, which was to add
I am mentally preparing for giving a talk about dependency injection and inversion of control and how are they important, so I intend to clarify my thoughts on the blog first. This has been spurred by seeing how so many talented and even experienced programmers don't really understand the concepts and why they should use them. I also intend to briefly explore these concepts in the context of programming languages other than C#.
And yes, I know I've started an ASP.Net MVC exploration series and stopped midway, and I truly intend to continue it, it's just that this is more urgent.
Head on intro
So, instead of going to the definitions, let me give you some examples, instead.
publicclass MyClass { public IEnumerable<string> GetData() { var provider=new StringDataProvider(); var data=provider.GetStringsNewerThan(DateTime.Now-TimeSpan.FromHours(1)); return data; } }
In this piece of code I create a class that has a method that gets some text. That's why I use a StringDataProvider, because I want to be provided with string data. I named my class so that it describes as best as possible what it intends to do, yet that descriptiveness is getting lost up the chain when my method is called just GetData. It is called so because it is the data that I need in the context of MyClass, which may not care, for example, that it is in string format. Maybe MyClass just displays enumerations of objects. Another issue with this is that it hides the date and time parameter that I pass in the method. I am getting string data, but not all of it, just for the last hour. Functionally, this will work fine: task complete, you can move to the next. Yet it has some nagging issues.
Dependency Injection
Let me show you the same piece of code, written with dependency injection in mind:
public IEnumerable<string> GetData() { var oneHourBefore=_dateTimeProvider.Now-TimeSpan.FromHours(1); var data=_dataProvider.GetDataNewerThan(oneHourBefore); return data; } }
A lot more code, but it solves several issues while introducing so many benefits that I wonder why people don't code like this from the get go.
Let's analyse this for a bit. First of all I introduce a constructor to MyClass, one that accepts and caches two parameters. They are not class types, but interfaces, which declare the intention for any class implementing them. The method then does the same thing as in the original example, using the providers it cached. Now, when I write the code of the class I don't actually need to have any provider implementation. I just declare what I need and worry about it later. I also don't need to inject real providers, I can mock them so that I can test my class as standalone. Note that the previous implementation of the class would have returned different data based on the system time and I had no way to control that behavior. The best benefit, for me, is that now the class is really descriptive. It almost reads like English: "Hi, folks, I am a class that needs someone to give me some data and the time of day and I will give you some processed data in return!". The rule of thumb is that for each method, external factors that may influence its behavior must be abstracted away. In our case if the date time provider provides the same time and the data provider the same data, the effect of the method is always the same.
Note that the interface I used was not IStringDataProvider, but IDataProvider. I don't really care, in my class, that the data is a bunch of strings. There is something called the Single Responsibility Principle, which says that a class or a method or some sort of unit of computation should try to only have one responsibility. If you change that code, it should only affect one area. Now, real life is a little different and classes do many things in many directions, yet they can implement any number of interfaces. The interfaces themselves can declare only one responsibility, which is why this is so nice. I don't actually have to have a class that is only a data provider, but in the context of my class, I only need that part and I am clearly declaring my intent in the code.
This here is called dependency injection, which is a fancy expression for saying "my code receives all third party instances as parameters". It is also in line with the Single Responsibility Principle, as now your class doesn't have to carry the responsibility of knowing how to instantiate the classes it needs. It makes the code more modular, easier to test, more legible and more maintainable.
But there is a problem. While before I was using something like new MyClass().GetData(), now I have to push the instantiation of the providers somewhere up the stream and do maybe something like this:
var dataProvider=new StringDataProvider(); var dateTimeProvider=new DateTimeProvider(); var myClass=new MyClass(dataProvider,dateTimeProvider); myClass.GetData();
The apparent gains were all for naught! I just pushed the same ugly code somewhere else. But here is where Inversion of Control comes in. What if you never need to instantiate anything again? What it you never actually had to write any new Something() code?
Inversion of Control
Inversion of Control actually takes over the responsibility of creating instances from you. With it, you might get this code instead:
public IEnumerable<string> GetData() { var oneHourBefore=_dateTimeProvider.Now-TimeSpan.FromHours(1); var data=_dataProvider.GetDataNewerThan(oneHourBefore); return data; } }
Note that I created an interface for MyClass to implement, one that declares my GetData method. Now, to use it, I could write something like this:
var myClass=Dependency.Get<IMyClass>(); myClass.GetData();
Wow! What happened here? I just used a magical class called Dependency that gets me an instance of IMyClass. And I really don't care how it does it. It can discover implementations by itself or maybe I am manually binding interfaces to implementations when the application starts (for example Dependency.Bind<IMyClass,MyClass>();). When it needs to create a new MyClass it automatically sees that it needs two other interfaces as parameters, so it gets implementations for those first and continues up the chain. It is called a dependency chain and the container will go through it all to simply "Get" you what you need. There are many inversion of control frameworks out there, but the concept is so simple that one can make their own easily.
And I get another benefit: if I want to display some other type of data, all I have to do is instruct the dependency container that I want another implementation for the interface. I can even think about versioning: take a class that I know does the job and compare it with a new implementation of the same interface. I can tell it to use different versions based on the client used. And all of this in exactly one place: the dependency container bindings. You may want to plug different implementations provided by third parties and all they have to care about is respecting the contract in your interface.
Solution structure
This way of writing code forces some changes in the structure of your projects. If all you have is written in a single project, you don't care, but if you want to split your work in several libraries, you have to take into account that interfaces need to be referenced by almost everything, including third party modules that you want to plug. That means the interfaces need their own library. Yet in order to declare the interfaces, you need access to all the data objects that their members need, so your Interfaces project needs to reference all the projects with data objects in them. And that means that your logic will be separated from your data objects in order to avoid circular dependencies. The only project that will probably need to go deeper will be the unit and integration test project.
Bottom line: in order to implement this painlessly, you need an Entities library, containing data objects, then an Interfaces library, containing the interfaces you need and, maybe, the dependency container mechanism, if you don't put it in yet another library. All the logic needs to be in other projects. And that brings us to a nice side effect: the only connection between logic modules is done via abstractions like interfaces and simple data containers. You can now substitute one library with another without actually caring about the rest. The unit tests will work just the same, the application will function just the same and functionality can be both encapsulated and programatically described.
There is a drawback to this. Whenever you need to see how some method is implemented and you navigate to definition, you will often reach the interface declaration, which tells you nothing. You then need to find classes that implement the interface or to search for uses of the interface method to find implementations. Even so, I would say that this is an IDE problem, not a dependency injection issue.
Other points of view
Now, the intro above describes what I understand by dependency injection and inversion of control. The official definition of Dependency Injection claims it is a subset of Inversion of Control, not a separate thing.
For example, Martin Fowler says that when he and his fellow software pattern creators thought of it, they called it Inversion of Control, but they decided that it was too broad a term, so they moved to calling it Dependency Injection. That seems strange to me, since I can describe situations where dependencies are injected, or at least passed around, but they are manually instantiated, or situations where the creation of instances is out of the control of the developer, but no dependencies are passed around. He seems to see both as one thing. On the other hand, the pattern where dependencies are injected by constructor, property setters or weird implementation of yet another set of interfaces (which he calls Dependency Injection) is different from Service Locator, where you specifically ask for a type of service.
Wikipedia says that Dependency Injection is a software pattern which implements Inversion of Control to resolve dependencies, while it calls Inversion of Control a design principle (so, not a pattern?) in which custom-written portions of a computer program receive the flow of control from a generic framework. It even goes so far as to say Dependency Injection is a specific type of Inversion of Control. Anyway, the pages there seem to follow the general definitions that Martin Fowler does, which pits Dependency Injection versus Service Locator.
On StackOverflow a very well viewed answer sees dependency injection as "giving an object its instance variables". I tend to agree. I also liked another answer below that said "DI is very much like the classic avoiding of hardcoded constants in the code." It makes one think of a variable as an abstraction for values of a certain type. Same page holds another interesting view: "Dependency Injection and dependency Injection Containers are different things: Dependency Injection is a method for writing better code, a DI Container is a tool to help injecting dependencies. You don't need a container to do dependency injection. However a container can help you."
Another StackOverflow question has tons of answers explaining how Dependency Injection is a particular case of Inversion of Control. They all seem to have read Fowler before answering, though.
A CodeProject article explains how Dependency Injection is just a flavor of Inversion of Control, others being Service Locator, Events, Delegates, etc.
Composition over inheritance, convention over configuration
An interesting side effect of this drastic decoupling of code is that it promotes composition over inheritance. Let's face it: inheritance was supposed to solve all of humanity's problems and it failed. You either have an endless chain of classes inheriting from each other from which you usually use only one or two or you get misguided attempts to allow inheritance from multiple sources which complicates understanding of what does what. Instead interfaces have become more widespread, as declarations of intent, while composition has provided more of what inheritance started off as promising. And what is dependency injection if not a sort of composition? In the intro example we compose a date time provider and a data provider into a time aware data provider, all the time while the actors in this composition need to know nothing else than the contracts each part must abide by. Do that same thing with other implementations and you get a different result. I will go as far as to say that inheritance defines what classes are, while composition defines what classes do, which is what matters in the end.
Another interesting effect is the wider adoption of convention over configuration. For example you can find the default implementation of an interface as the class that implements it and has the same name minus the preceding "I". Rather than explicitly tell the framework that we want to use the Manager class each time someone needs an IManager implementation, it can figure it out for itself by naming alone. This would never work if the responsibility of getting class instances resided with each method using them.
Real life examples
Simple Injector
If you look on the Internet, one of the first dependency injection frameworks you find for .Net is Simple Injector, which works on every flavor of .Net including Mono and Core. It's as easy to use as installing the NuGet package and doing something like this:
// 1. Create a new Simple Injector container var container = new Container();
// 2. Configure the container (register) container.Register<IUserRepository, SqlUserRepository>(Lifestyle.Transient); container.Register<ILogger, MailLogger>(Lifestyle.Singleton);
// 3. Optionally verify the container's configuration. container.Verify();
// 4. Get the implementation by type IUserService service = container.GetInstance<IUserService>();
ASP.Net Core
ASP.Net Core has dependency injection built in. You configure your bindings in ConfigureServices:
then you use any of the registered classes and interfaces as constructor parameters for controllers or even using them as method parameters (see FromServicesAttribute)
Managed Extensibility Framework
MEF is a big beast of a framework, but it can simplify a lot of work you would have to do to glue things together, especially in extensibility scenarios. Typically one would use attributes to declare which interface something "exports" and then use other attributes to "import" implementations in properties and values. All you need to do is put them in the same place. Something like this:
[Export(typeof(ICalculator))] class SimpleCalculator : ICalculator { //... }
class Program {
[Import(typeof(ICalculator))] public ICalculator calculator;
// do something with calculator }
Of course, in order for this to work seamlessly you need stuff like this, as well:
private Program() { //An aggregate catalog that combines multiple catalogs var catalog = new AggregateCatalog(); //Adds all the parts found in the same assembly as the Program class catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly)); catalog.Catalogs.Add(new DirectoryCatalog("C:\\Users\\SomeUser\\Documents\\Visual Studio 2010\\Projects\\SimpleCalculator3\\SimpleCalculator3\\Extensions"));
//Create the CompositionContainer with the parts in the catalog _container = new CompositionContainer(catalog);
//Fill the imports of this object try { this._container.ComposeParts(this); } catch (CompositionException compositionException) { Console.WriteLine(compositionException.ToString()); } }
Dependency Injection in other languages
Admit it, C# is great, but it is not by far the most used computer language. That place is reserved, at least for now, for Javascript. Not only is it untyped and dynamic, but Javascript isn't even a class inheritance language. It uses the so called prototype inheritance, which uses an instance of an object attached to a type to provide default values for the instance of said type. I know, it sounds confusing and it is, but what is important is that it has no concept of interfaces or reflection. So while it is trivial to create a dictionary of instances (or functions that create instances) of objects which you could then use to get what you need by using a string key (something like var manager=Dependency.Get('IManager');, for example) it is difficult to imagine how one could go through the entire chain of dependencies to create objects that need other objects.
And yet this is done, by AngularJs, RequireJs or any number of modern Javascript frameworks. The secret? Using regular expressions to determine the parameters needed for a constructor function after turning it to string. It's complicated and beyond the scope of this blog post, but take a look at this StackOverflow question and its answers to understand how it's done.
In this case the key/type of the service is explicit using an array notation that says "this is the list of parameters that the dependency injector needs to give to the function", but this might be have been written just as the function:
In this case Angular would use the regular expression approach on the function string.
What about other languages? Java is very much like C# and the concepts there are similar. Even if all are flavors of C, C++ is very different, yet Dependency Injection can be achieved. I am not a C++ developer, so I can't tell you much about that, but take a look at this StackOverflow question and answers; it is claimed that there is no one method, but many that can be used to do dependency injection in C++.
In fact, the only languages I can think of that can't do dependency injection are silly ones like SQL. Since you cannot (reasonably) define your own types or pass functions along, the concept makes no sense. Even so, one can imagine creating dummy stored procedures that other stored procedures would use in order to be tested. There is no reason why you wouldn't use dependency injection if the language allows for it.
Testability
I mentioned briefly unit testing. Dependency Injection works hand in hand with automated testing. Given that the practice creates modules of software that give reproducible results for the same inputs and account for all the inputs, testing becomes a breeze. Let me give you some examples using Moq, a mocking library for .Net:
var dateTimeMock=new Mock<IDateTimeProvider>(); dateTimeMock .Setup(m=>m.Now) .Returns(new DateTime(2016,12,03));
var dataMock=new Mock<IDataProvider>(); dataMock .Setup(m=>m.GetDataNewerThan(It.IsAny<DateTime>())) .Returns(new[] { "test","data" });
var testClass=new MyClass(dateTimeMock.Object, dataMock.Object);
var result=testClass.GetData(); AssertDeepEqual(result,new[] { "test","data" });
First of all, I take care of all dependencies. I create a "mock" for each of them and I "set up" the methods or property setters/getters that interest me. I don't really need to set up the date time mock for Now, since the data from the data provider is always the same no matter the parameter, but it's there for you to see how it's done. Second, I instantiate the class I want to test using the Object property of my mocks, which returns an object that implements the type given as a generic parameter in the constructor. Third I assert that the side effects of my call are the ones I expect. The mocks need to be as dumb as possible. If you feel you need to write code to define your mocks you are probably doing something wrong.
The type of the tests, for people who are not familiar with this concept, is usually a fully positive one - that is give full valid data and expect the correct result - followed by many negative ones, where the correct data is made incorrect in all possible ways and it is tested that the method fails. If there are many types of combinations of data that would be considered valid, you need a test for as many of them.
Note that the test is instantiating the test class directly, using the constructor. We are not testing the injector here, but the actual class.
Conclusions
What I appreciate most with Dependency Injection is that it forces you to write code that has clear boundaries defined by interfaces. Once this is achieved, you can go write your own stuff and not care about what other people do with theirs. You can test your modules without even caring if the rest of the project even exists. It allows to refactor code in steps and with a lot more confidence since you are covered by unit tests.
While some people work on fire-and-forget projects, like small games or utilities, and they don't care about maintainability, one of the most touted reasons for using unit tests and dependency injection, these practices bring so many other benefits that are almost impossible to get otherwise.
The entire point of this is reducing the complexity of dependencies, which include not only the modules in your application, but also the support frame for them, like people working on them. While some managers might not see the wisdom of reducing friction between software components, surely they can see the positive value of reducing friction between people.
There was one other topic that I wanted to touch, but it is both vast and I have not enough experience with it, however it feels very attractive to me: refactoring old code in order to use dependency injection. Best practices, how to make it safe enough and fast enough to make managers approve it and so on. Perhaps another post later on. I was thinking of a combination of static analysis and automated methods, like replacing all usages of "new" with a single point of instantiation, warning about static methods and properties, automatically replacing known bad practices like DateTime.Now and so on. It might be interesting, right?
I hope I wasn't too confusing and I appreciate any feedback you have. I will be working on a presentation file with similar content, so any help will go into doing a better job explaining it to others.
