Using Dependency Injection in Multiple .NET Core Projects

to demonstrate that, i created solutions with two .net core console apps and two .net standard libraries. one of the console apps uses two of the libraries, and the other one is just using one. each library provides some services which need to be registered to the di container. also, the console apps provide some services to add.

we now have four projects like this:

• didemo.smallclient
  • .net core console app.
  • includes a writesimpledataservice.
  • references didemo.csvfileconnector.
• didemo.bigclient
  • .net core console app.
  • includes a writeextendeddataservice.
  • includes a normalizeddataservice.
  • references didemo.sqldatabaseconnector.
  • references didemo.csvfileconnector.
• didemo.sqldatabaseconnector
  • .net standard library.
  • includes a sqldataservice.
  • includes a sqldataprovider used by the service.
• didemo.csvfileconnector
  • .net standard library.
  • includes a csvdataservice.

btw: since one of the latest updates the "class libraries (.net standard)" project disappeared from the ".net core" node in the "add new project" dialogue and the "class library (.net core)" is back again. the "class libraries (.net standard)" is now in the ".net standard" node under the "visual c#" node.

in the most cases it doesn't really makes sense to create a .net core class library. the difference here is that the class library (.net core) has some .net core related references. they target the netcoreapp1.x instead of the netstandard1.x. this means they have a lot of references, which are not needed in a class library in the most cases, e. g. the libuv and the .net core runtime.

the writeextendeddataservice uses an inormalizeddataservice to get the data and writes it to the console. the normalizeddataservice fetches the data from the csvdataservice and from the sqldataservice and normalizes it, to make it usable in the writeextendeddataservice.

the writesimpledataservice uses only the icsvdataservice and writes the data out to the console.

setup the di container

let's set up the di container for the smallclient app. currently, it looks like this:

var services = new servicecollection();
services.addtransient<iwritesimpledataservice, writesimpledataservice>();
services.addtransient<icsvdataservice, csvdataservice>();

var provider = services.buildserviceprovider();

var writer = provider.getservice<iwritesimpledataservice>();
writer.write();

that doesn't really look wrong, but what happens if the app grows and gets a lot more services to add to the di container? the csvdataservice is not in the app directly, but it is in a separate library. usually, i don't want to map all the services of the external library. i just want to use the library and i don't want to know anything about the internal stuff. this is why we should set up the mapping for the di container in the external library as well.

let's plug things together

the .net standard libraries should reference the microsoft.extensions.dependencyinjection.abstractions to get the iservicecollection interface. now we can create a public static class called iservicecollectionextensions to create an extension method to work in the iservicecollection:

public static class iservicecollectionextension
{
  public static iservicecollection addcsvfileconnector(this iservicecollection services)
  {
    services.addtransient<icsvdataservice, csvdataservice>();
    return services;
  }
}

inside this method, we do all the mappings from the interfaces to the concrete classes or all the other registrations to the di container. let's do the same to encapsulate all the services inside the smallclient app and to keep the program.cs as small as possible:

public static class iservicecollectionextension
{
  public static iservicecollection addinternalservices(this iservicecollection services)
  {
    services.addtransient<iwritesimpledataservice, writesimpledataservice>();
    return services;
  }
}

we can now use this method in the program.cs of the smallclient app to plug all that stuff together:

var services = new servicecollection();
services.addinternalservices();
services.addcsvfileconnector();

var provider = services.buildserviceprovider();

var writer = provider.getservice<iwritesimpledataservice>();
writer.write();

it looks much cleaner now. maybe you remember the addsomething methods? exactly, this is the same way it is done in asp.net core with the services.addmvc() method.

we now need to do the same thing for the bigclient app and the sqldatabaseconnector library. first, let's create the mapping for the sqldatbaseconnector:

public static class iservicecollectionextension
{
  public static iservicecollection addsqldatabaseconnector(this iservicecollection services)
  {
    services.addtransient<isqldataservice, sqldataservice>();
    services.addtransient<isqldataprovider, sqldataprovider>();
    return services;
  }
}

we also need to create an extension method for the internal services:

public static class iservicecollectionextension
{
  public static iservicecollection addinternalservices(this iservicecollection services)
  {
    services.addtransient<iwriteextendeddataservice, writeextendeddataservice>();
    services.addtransient<inormalizeddataservice, normalizeddataservice>();
    return services;
  }
}

now let's plug that stuff together in the bigclient app:

var services = new servicecollection();
services.addinternalservices();
services.addcsvfileconnector();
services.addsqldatabaseconnector();

var provider = services.buildserviceprovider();

var writer = provider.getservice<iwriteextendeddataservice>();
writer.write();

as you can see, the bigclient app uses the already existing services.addcsvfileconnector() method.

does it really work?

it does. start the bigclient app in visual studio to make sure that it will work as expected:

to see the full sources and to try it out by yourself, please visit my github repository .

what do you think? do you have questions or some ideas to add? feel free to drop a comment.