DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report
  1. DZone
  2. Coding
  3. Languages
  4. Using Dependency Injection in Multiple .NET Core Projects

Using Dependency Injection in Multiple .NET Core Projects

In this post we take a look at answering the question of how to setup and use dependency injection in multiple projects within the same solution.

Juergen Gutsch user avatar by
Juergen Gutsch
·
Mar. 08, 17 · Tutorial
Like (1)
Save
Tweet
Share
23.45K Views

Join the DZone community and get the full member experience.

Join For Free

one of my last posts was about dependency injection (di) in .net core console applications . some days after that post was published, i got a question about how to use the iservicecollection in multiple projects. in this post, i'm going to try to explain just that.

setup

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.

Dependency injection .NET app Library

Published at DZone with permission of Juergen Gutsch, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Solving the Kubernetes Security Puzzle
  • A Gentle Introduction to Kubernetes
  • 11 Observability Tools You Should Know
  • Top 5 Data Streaming Trends for 2023

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: