CoreResolution

If every single option which affects resolution is disabled and the container is reduced to its simplest form then the process is as follows. Throughout this page, a "resolution request" can mean either a direct call to IResolvesServices.Resolve (or related method) or it might mean the recursive resolution of a parameter (step 3). Please note that the selected options influence how this resolution process is extended.

Where a call to a Resolve method specifies a name, that name is part of the resolution request. When resursively resolving parameters the System.Reflection.ParameterInfo.Name is added to the resolution request as a requested name, in the same manner.

1. The container checks that the type to be resolved is valid
   • Only reference types may be resolved, not value types
   • Strings may not be resolved
   • If either of the above are not satisfied then an exception is raised
2. The container gets a registration which matches the resolution request
   • If no matching registration can be found then resolution fails
   • A failed resolution at this stage does not necessarily mean that an exception is raised
   • An exception may or may not be raised by a subsequent stage in the complete resolution process
3. The container resolves any parameters which are required to fulfil the registration
   • For a factory registration the parameters which are resolved are those to the factory delegate
   • For a type registration the parameters are those for the constructor which the type registration selects
   • This resolution of parameters occurs recursively until either the dependency graph is fully resolved or resolution fails/an exception occurs
4. The container 'executes' the chosen registration, using the resolved parameters as appropriate
   • For a factory registration, quite literally the factory delegate is executed
   • For a type registration, the chosen constructor is invoked
   • For an instance registration the associated object instance is returned (no 'execution' occurs)
5. The resulting object instance is returned as the result of the resolution

Matching a resolution request to a registration

Choosing a registration which matches a given resolution request works as follows. Multiple registrations may be considered for a single request and the "best" one is selected for actual use.

1. A collection of registrations to consider is built from the registrations available in the current container
   • If a registration exists for the exact same service type and name as the resolution request then this is considered for use
   • Any other registrations which are for determinate implementation types and for which their implementation type implements the requested service type (and which are registered under a matching name to the request) are also considered
2. If any of the registrations to be considered are instance registrations then these are chosen in favour of other kinds of registrations, otherwise the first registration found is chosen (preferring an exact match on the service type)
3. If no registrations are found and the resolution request included a name then this same process is attempted a second time, but with the name omitted.
   • Thus an unnamed registration may be used to satisfy a request for a named service
   • A named registration will never be used to satisfy a request which does not match its name