Clone wiki

DryIoc / Home

Wiki Home

Getting Started

Starting from simple interface/implementation setup:

    public interface IService { }
    public class SomeService : IService { }

    public interface IClient { IService Service { get; } }
    public class SomeClient : IClient
        public IService Service { get; private set; }
        public SomeClient(IService service) { Service = service; }

Let's compare creation of SomeClient manually and with DryIoc.

How to instantiate SomeClient with DI principle in mind:

    IClient client = new SomeClient(new SomeService());

That's hard-wired!

How to do that with DryIoc:

    var c = new Container();
    c.Register<IClient, SomeClient>();
    c.Register<IService, SomeService>();

    // somewhere else
    IClient client = c.Resolve<IClient>();

In DryIoc we are declaring/registering mapping between interfaces and implementations. Then in different space and time we are deciding to get/resolve IClient object with its dependencies by providing only client interface.

Hey, it means that I can register different IClient implementations without touching consumer resolution code. And we are not speaking about good singletons yet.

So IoC container helps me to enforce Open-Closed principle and to improve Testability and Extensibility of my software.

Usage Guide




Located in this repo:

External links:

Latest Version

Get from NuGet:

  • DryIoc.dll NuGet Badge
  • DryIoc (source code) NuGet Badge
  • DryIoc.Internal (source code with public types made internal) NuGet Badge

v2.12.6 / 2017-12-20

  • fixed: #544: WithTrackingDisposableTransients may downgrade Singletons to Transients

v3.0.0-preview-03 / 2017-12-05

Release Notes

v3.0.0-preview-03 / 2017-11-15

Release Notes

v2.12.5 / 2017-10-30

  • fixed: #533: Exporting WPF UserControl causes NullReferenceException

v2.12.4 / 2017-10-17

  • fixed: Race condition when creating or storing the scoped service

v2.12.3 / 2017-10-02

  • fixed: #527 Error ResolveMany after Unregister
  • fixed: Bug in ImTools ArrayTools.Append in certain cases

v3.0.0-preview-01 / 2017-10-01

Release Notes

v2.12.2 / 2017-09-17

  • fixed: #519 Dependency of singleton not working when using "child" container
  • fixed: #520 AccessViolationException on some machines
  • fixed: #521 Rule ConcreteTypeDynamicRegistrations: Exception while resolving instance of class with constructor-injected generic instance of not registered class

v2.12.1 / 2017-09-09

  • fixed: #512 InResolutionScopeOf in combination with SelectLastRegisteredFactory
  • changed: Updated to FEC v1.4 - now all DryIoc expressions are covered by FEC. This means perf improvements for asResolutionCall injection

v2.12.0 / 2017-09-01

  • added: #499: Add RegisterPlaceholder to enable delayed registration
  • added: Setup.DecoratorOf{T}(key) and runtime version to simplify specifying condition for matching decoratee type and key
  • added: Missing overload for Made.Of to consider request -> instance factory info.
  • added: Rules.WithDynamicRegistrationsAsFallback
  • changed: Updated FEC to v1.3.0
  • fixed: #492: Lazy imports disguised as non-lazy
  • fixed: #497: ConstructorWithResolvableArguments is not working properly
  • fixed: #500: Rule WithConcreteTypeDynamicRegistrations disables allowDisposableTransient
  • fixed: #506: Cannot resolve string[]
  • fixed: #507: Resolved collection of mixed open and closed generics does not preserve order of registration
  • fixed: #508: SelectLastRegisteredFactory and resolving collection of open-generic is not working as intended

Previous Versions