Stax.AutoDependencyInjectionRegistration
1.0.0-alpha
See the version list below for details.
dotnet add package Stax.AutoDependencyInjectionRegistration --version 1.0.0-alpha
NuGet\Install-Package Stax.AutoDependencyInjectionRegistration -Version 1.0.0-alpha
<PackageReference Include="Stax.AutoDependencyInjectionRegistration" Version="1.0.0-alpha" />
paket add Stax.AutoDependencyInjectionRegistration --version 1.0.0-alpha
#r "nuget: Stax.AutoDependencyInjectionRegistration, 1.0.0-alpha"
// Install Stax.AutoDependencyInjectionRegistration as a Cake Addin #addin nuget:?package=Stax.AutoDependencyInjectionRegistration&version=1.0.0-alpha&prerelease // Install Stax.AutoDependencyInjectionRegistration as a Cake Tool #tool nuget:?package=Stax.AutoDependencyInjectionRegistration&version=1.0.0-alpha&prerelease
Dotnet Auto Dependency Registration Extension
Version 1.0.0-alpha: This package is currently in an alpha pre-release. Feel free to install and play around with this package on your own project, but I would advise not putting it into a production application until 2.0.0 when it is considered stable.
Summary
This NuGet package helps to easily register classes without having to add a whole bunch of lines such as service.AddScoped<IService, Service>()
. In projects which contain a number of services, this can inflate your code with potentially tens to hundreds of lines.
Dotnet Auto Dependency Registration Extension makes this easy. All you need is to add services.AutoRegisterDependencies();
within your programs ConfigureServices
method and then add attributes above your classes to register them as either Transient, Scoped or Singleton (examples below of how to do this). Dotnet Auto Dependency Registration will take care of the rest without you having to specify assemblies or service name structures for it to pick up.
Why I have written this
While they are a handful of auto DI registration solutions out there, not many of them make it as easy as we were hoping in a project I was working on as we were using a number of projects and didn't want to have to specify a bunch of assemblies and also service name structures to automatically pick up.
I've also been heavily interested in dependency injection and wanted to play around with how it worked and how I could make a lightweight solution to reduce the need to specify in your Program.cs
file a whole bunch of services to register. I love the ability to reduce code and believe auto DI registration extension methods are of great use.
How to use
Current solution
Usually your Program.cs
file will look something like this:
services.AddScoped<IService, Service>();
services.AddTransient<IService2, Service2>();
services.AddSingleton<IService3, Service3>();
services.AddScoped<IService4, Service4>();
services.AddTransient<IService5, Service5>();
services.AddSingleton<IService6, Service6>();
services.AddScoped<IService7, Service7>();
services.AddTransient<IService8, Service8>();
services.AddSingleton<IService9, Service9>();
etc
How this extension method helps
Using this extension simplifies this greatly.
Within your Program.cs
simply add:
services.AutoRegisterDependencies();
Depending on your version of .NET, the containing method example may be:
.NET 5:
public void ConfigureServices(IServiceCollection services)
{
services.AutoRegisterDependencies();
}
.NET 6:
builder.services.AutoRegisterDependencies();
From there, on top of your classes you have three attribute options:
[RegisterClassAsScoped] - Register as scoped
[RegisterClassAsTransient] - Register as transient
[RegisterClassAsSingleton] - Register as singleton
Classes which you use these attributes must implement an interface, but if the class you use this attribute on does not contain an interface an error will be logged to the console on startup and no attempt will be made to register the class. Be sure to check the logs on startup to ensure that your classes are being registered correctly and that no errors are returning
On startup you will see Information logs showing you what classes have been registered and with which ServiceLifetime, in the format of: "ClassName
, InterfaceName
has been registered as ServiceLifetime
."
Practical example
Class.cs
[RegisterClassAsSingleton]
public class Class1 : IClass1
{
public string DemoService()
{
return "Hi!";
}
}
Class2.cs
[RegisterClassAsTransient]
public class Class2 : IClass2
{
public string DemoService()
{
return "Hi!";
}
}
Program.cs
public void ConfigureServices(IServiceCollection services)
{
services.AutoRegisterDependencies();
}
This will cause two log entries in console on startup:
Class1, IClass1 has been registered as Singleton
Class2, IClass2 has been registered as Transient
I also try to circumvent potential mistakes such as:
Class1.cs
[RegisterClassAsTransient]
[RegisterClassAsSingleton]
public class Class1 : IClass1
{
public string DemoService()
{
return "Hi!";
}
}
In this situation the first attribute will always be used, so the class in this example will be registered as Transient.
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net5.0 is compatible. net5.0-windows was computed. net6.0 is compatible. net6.0-android was computed. net6.0-ios was computed. net6.0-maccatalyst was computed. net6.0-macos was computed. net6.0-tvos was computed. net6.0-windows was computed. net7.0 was computed. net7.0-android was computed. net7.0-ios was computed. net7.0-maccatalyst was computed. net7.0-macos was computed. net7.0-tvos was computed. net7.0-windows was computed. net8.0 was computed. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. |
.NET Core | netcoreapp3.1 is compatible. |
-
.NETCoreApp 3.1
- Microsoft.Extensions.DependencyInjection (>= 5.0.0)
- Serilog.AspNetCore (>= 5.0.0)
- Serilog.Sinks.Console (>= 4.0.1)
-
net5.0
- Microsoft.Extensions.DependencyInjection (>= 5.0.0)
- Serilog.AspNetCore (>= 5.0.0)
- Serilog.Sinks.Console (>= 4.0.1)
-
net6.0
- Microsoft.Extensions.DependencyInjection (>= 5.0.0)
- Serilog.AspNetCore (>= 5.0.0)
- Serilog.Sinks.Console (>= 4.0.1)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
Version | Downloads | Last updated |
---|---|---|
3.1.1 | 3,008 | 9/17/2023 |
3.1.0 | 2,207 | 4/16/2023 |
3.0.0 | 1,670 | 4/6/2023 |
2.1.0 | 8,497 | 5/26/2022 |
2.0.1 | 607 | 5/1/2022 |
2.0.0 | 459 | 4/26/2022 |
1.1.0-alpha | 208 | 4/25/2022 |
1.0.0-alpha | 186 | 4/25/2022 |