Rayson.DependencyInjection
1.0.8
dotnet add package Rayson.DependencyInjection --version 1.0.8
NuGet\Install-Package Rayson.DependencyInjection -Version 1.0.8
<PackageReference Include="Rayson.DependencyInjection" Version="1.0.8" />
paket add Rayson.DependencyInjection --version 1.0.8
#r "nuget: Rayson.DependencyInjection, 1.0.8"
// Install Rayson.DependencyInjection as a Cake Addin #addin nuget:?package=Rayson.DependencyInjection&version=1.0.8 // Install Rayson.DependencyInjection as a Cake Tool #tool nuget:?package=Rayson.DependencyInjection&version=1.0.8
Rayson.DependencyInjection? Why...?
With absolutely zero setup, you can start writing code that uses dependency injection. There's no need to manually configure a container. I have always felt that having to write a configuration file for DI is so much hassle, and really isn't needed. The API is designed to be as thin and as easy as possible, while still providing some flexibility. Convention over Configuration!!
Get started guide
Using the Container class
The static Container
class contains static methods for instantiating objects and automatically resolving their dependencies. The resolution of the dependencies will store those dependencies in a cache ready for next time.
Getting a New Instance of an object
Interface obj = Container.ResolveInstance<Interface>();
// or
Class obj = Container.ResolveInstance<Class>();
Getting a Singleton
Interface obj = Container.ResolveSingleton<Interface>();
// or
Class obj = Container.ResolveSingleton<Class>();
Getting all possible components
Interface obj = Container.ResolveMany<Interface>();
// or
Class obj = Container.ResolveMany<Class>();
Getting a specific implementation
MySpecificClass obj = Container.ResolveSingleton<Interface>(nameof(MySpecificClass));
Implementing your own container
You may implement the IContainerAdapter
interface in any way you like, and then set the static Container
class's internal instance by calling...
Container.SetCurrent(yourCustomImplementation);
...All calls to Container
methods will then use your custom implemenation. This gives you the freedomt to use any other DI framework under the hood.
Any gotchas?
Maybe... Just Try It! I promise you it'll be faster to start with than any of the major DI frameworks, I've tried most of them...
Why isn't my dependency being found?
You will need to have your dependency assemblies in the same location as the class you're trying to resolve, this is where the DefaultContainer
will search for assemblies and load them in. For example, if you resolve a class from an assembly which is in the "C:/MyLocation/Assemblies/" folder, all of the dependencies of that dll will need to also be in that folder.
Can I load a DotNet type?
YEP! But it's not thoroughly tested, so it may not work for everything. You can certainly get a DotNet Dictionary<T,T2>
but other classes have not been tested. I'm pretty sure String
would fail because it doesn't have a constructor, for example.
Do you have a test suite?
Of course I do! There's a total of 24 sanity tests at the moment, and growing with every new feature I add. There shouldn't ever be something that works in one version that gets broken in a subsequent version, but bad things happen... If you ever find a bug, please report it to danrayson@hotmail.co.uk and I'll let you know when it's fixed.
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net5.0 was computed. 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
- Rayson.Caching (>= 1.0.1)
-
net6.0
- Rayson.Caching (>= 1.0.1)
NuGet packages (3)
Showing the top 3 NuGet packages that depend on Rayson.DependencyInjection:
Package | Downloads |
---|---|
Rayson.ObjectCrawling
Useful Types: MultiAggregateCrawler, Object.Copy (extension), TransposeCrawler, UpdateCrawler |
|
Rayson.Formulae
Useful Types: Formula, FormulaBuilder, NodeFactory Represent a math formula as binary tree, with methods to manipulate the structure of the formula. |
|
Rayson.DependencyInjection.AzureServices
Useful Types: AzureAutoRegistrar |
GitHub repositories
This package is not used by any popular GitHub repositories.
Useful Types: Container, DefaultContainer, IContainer
1.0.8 Fixed a case where assemblies where not properly being loaded into the AppDomain
1.0.7 Updated dotnet versions
1.0.6 Updated a bugged dependency
1.0.5 - Renamed IContainerAdapter to IContainer, because that's what it is. Also began using release version of Rayson.Caching.
1.0.4 - Added a readme into the installation (We'll see how that works)
1.0.3 - Can now resolve from a *.Exe rather than only *.Dll
1.0.2 - Can now resolve via an abstract type
1.0.1 - Added exception handling for System collection interface types
1.0.0 - Released!
0.0.20 - Changed package name to Rayson.DependencyInjection
0.0.18/19-pre
Better exception handling
0.0.17-pre
Added support for creation of System classes that have basic ctors
0.0.16-pre
bio
0.0.15-pre
As 0.0.14-pre
0.0.14-pre
Fix for types that inherit from IEnumerable
0.0.13-pre
BugFix for generic types
0.0.12-pre
Resolve types from assemblies located in the same directory as the mask's assembly
0.0.11-pre
updated .net framework requirements
resolve multiple types via IEnumerable<T> injection
added ResolveMany method to api
0.0.10-pre
init