What's new? | Help | Directory | Sign in
Google
autofac
An addictive .NET IoC container
  
  
  
  
    
Search
for
Updated Mar 17, 2008 by nicholas.blumhardt
XmlConfiguration  
XML configuration is useful for components that depend on the deployment environment.

Introduction

Most IoC containers provide a programmatic interface as well as XML configuration support, and Autofac is no exception.

Autofac encourages programmatic configuration through the ContainerBuilder class. Using the programmatic interface is central to the design of the container. XML is recommended only when concrete classes cannot be chosen or configured at compile-time.

Syntax

Autofac can read standard .NET application config files. These are the ones called AppName_.config.

You need to declare a section handler somewhere near the top of your config file - you can give the container configuration section its own unique name ("mycomponents" in this example.)

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<configSections>
		<section name="mycomponents" type="Autofac.Configuration.SectionHandler, Autofac"/>
	</configSections>

Then, provide a section describing your components:

	<mycomponents defaultAssembly="Autofac.Example.Calculator.Api">
		<components>
			<component
				type="Autofac.Example.Calculator.Addition.Add, Autofac.Example.Calculator.Addition"
				service="Autofac.Example.Calculator.Api.IOperation" />

			<component
				type="Autofac.Example.Calculator.Division.Divide, Autofac.Example.Calculator.Division"
				service="Autofac.Example.Calculator.Api.IOperation" >
				<parameters>
					<parameter name="places" value="4" />
				</parameters>
			</component>

Valid 'component' Attributes

The following can be used as attributes on the component element (defaults are the same as for the programmatic API):

Attribute Name Description Valid Values
type The only required attribute. The concrete class of the component (assembly-qualified if in an assembly other than the default.) Any .NET type name that can be created through reflection.
service A service exposed by the component. For more than one service, use the nested services element. As for type.
scope Instance scope - see the InstanceScope enumeration. singleton, factory or container
ownership Container's ownership over the instances - see the InstanceOwnership enumeration. container or external
name A string name for the component. Any non-empty string value.
member-of Use to create multivalued components (see RegisterCollection() The name of another component that implements ICompositeComponent.
inject-properties Enable property (setter) injection for the component. never, all, unset.

Valid 'component' Nested Elements

Element Description
services A list of service elements, whose element content contains the names of types exposed as services by the component (see the service attribute.)
parameters A list of explicit constructor parameters to set on the instances (see example above.)
properties A list of explicit property values to set (syntax as for parameters.)

There are features missing from the XML configuration syntax that are available through the programmatic API - these will be added as needed.

Modules

Configuring the container using components is very fine-grained and can get verbose quickly. Autofac has support for packaging components into Modules in order to encapsulate implementation while providing flexible configuration.

Modules are registered by type:

<modules>
  <module type="MyModule" />

You can add nested parameters and properties to a module registration in the same manner as for components above.

Additional Config Files

You can include additional config files using:

<files>
  <file name="Controllers.config" section="controllers" />

Configuring the Container

To configure the container use a ConfigurationSettingsReader initialised with the name you gave to your XML configuration section.

builder.RegisterModule(new ConfigurationSettingsReader("mycomponents"));

The container settings reader will overwrite the registrations of any components already registered, thus you can write your application so that it will run with sensible defaults and then override only those component registrations necessary for a particular deployment.

Multiple Files or Sections

You can use multiple settings readers in the same container, to read different sections or even different config files if the filename is supplied to the ConfigurationSettingsReader constructor.


Sign in to add a comment