Configuring Drill versus Configuring DrillBits

When learning the Drill configuration system, it is important to understand the difference between configuring Drill, which usually means configuring a dependency resolver, compared to configuring a DrillBit component. There's a subtle difference that can be a bit confusing.

Dependency Resolver

A dependency resolver is a class that is used to resolve object instances and usually refers to the actual component implementing the Drill.IDependencyResolver interface from which methods are called to obtain object instances. In many cases, this will be the default dependency resolver (but it does not have to be), implemented by the Drill.Core.DrillChuckDependencyResolver class.

The DrillChuckDependencyResolver class requires one or more DrillBits to be configured in order to work properly.


A DrillBit is a pluggable component that implements the Drill.Extensibility.IDrillBit interface which inherits from Drill.IDependencyResolver, which means that every DrillBit is a dependency resolver. But not every dependency resolver is a DrillBit. A DrillBit component provides the actual object resolution behavior, possibly by wrapping an existing DI container or service locator framework. When this is true for a DrillBit implementation, the DrillBit will need to configure or setup its wrapped infrastructure. How it does this is a matter of the DrillBit implementation, but Drill standardizes this is a fixed set of supported configuration methods defined by the Drill.Extensibility.DrillBitConfigMethod enumeration which is configured via each config source for a DrillBit.

Drill Configuration Leads To DrillBit Configuration

When a dependency resolver instance is created, the Drill configuration for that dependency resolver is used by factory and builder classes to create the actual objects that provide the implementation. When an underlying DrillBit object instance is created, it may need to configure its underlying implementation (like always but not explicitly enforced). Each DrillBit may have one or more config sources and they are all processed sequentially in order that they are configured. Usually there is a single config source. When the config source has a method of ConfigFile, ConfigFileWithCustomLocation or XmlFile, the appropriate or specified file must be located before it can be used to configure the DrillBit. When the method is DrillBitSetup, a user-defined Drill.Extensibility.IDrillBitSetup instance is created and executed. A DrillBitSetup class can perform the necessary configuration and type registration programmatically.

Locating Config Files

Drill has some tools at its disposal to properly locate config files used to configure DrillBits. When the configuration method of a DrillBit is ConfigFile, the default .NET config file is used (e.g. App.config or Web.config). When the method is ConfigFileWithCustomLocation or XmlFile, a file with a custom location is configured and the value of the config source's value attribute comes into play.

The config source value attribute defines the filename of the config file to load. This value may be a full absolute path to a file, but it is not very practical in most situations to ever use an absolute path. The value is usually just the filename portion of a path or it may be a relative path part including the filename, such as the parent directory name and filename (e.g. config/MyCustomConfigFile.config).

The next problem to solve is to "root" the filename; make a full absolute path from the configured filename. There are two other optional features that are used: root path providers and search paths.

A root path provider is a pluggable component that is used to obtain one or more absolute paths to a directory that, when combined with the config source value attribute, will be a valid path to the file. When root path providers are not configured for a dependency resolver, the default root path provider is used, implemented by the Drill.Core.ExecutingDirectoryRootPathProvider. A dependency resolver may have more than root path provider configured.

A search path is a relative path part that may be searched for the config file and is sandwiched between any available root paths obtained by the configured root path providers and the config source value attribute. A search path may also be an absolute path to a directory as well, although it is usually better in a production environment to use a root path provider to intelligently determine the proper root path(s) used in an application.

More Root Path Providers

  • ExecutingDirectoryRootPathProvider - The Drill.Core.ExecutingDirectoryRootPathProvider provides the absolute path to the directory in which the executing assembly resides, usually where an App.config file is located. This is the default root path provider that is used when none are explicitly configured.
  • AspNetRootPathProvider - The Drill.Integration.Web.AspNetRootPathProvider root path provider implementation provides the absolute path to the ASP.NET application's root directory where the Web.config is usually located. This class is found in the Drill.Integration.Web assembly which is installed using the NuGet package of the same name.
  • Custom Root Path Provider - It is very easy to create a custom root path provider from scratch or by subclassing an existing implementation. The basic requirement is to create a class that implements Drill.Core.IRootPathProvider which has a single method: IList<string> GetRootPaths();. If you simply wanted to add a custom direcotry to your ASP.NET MVC web app, you can simply create a new class that inherits from Drill.Integration.Web.AspNetRootPathProvider, overrides the GetRootPaths method, calls the base implementation and modifies the IList<string> result to include the appropriate absolute directory before returning it.

Last edited Nov 21, 2012 at 6:40 AM by wreynolds, version 1


No comments yet.