Configuration schema contains the <instances> node like:
<add name="MyInstance1" type="System.String" value="Some value" />
<add name="MyInstance2" type="System.DateTime" value="2008-02-05T17:50:00" />
and it appears that it targets some constant style/pre-cooked instances of the objects avaialble for the container where they appear.
When the instance element configuration is read, it registers the named instance of Type with the value
container.RegisterInstance(Type, valueToRegister, nameToRegister, true);
Currently is supports the string value or requies to specify the TypeConverter.ConvertFromString to convert the value attribute to actual object.
What scenarios is this feature targeting?
Is it designed for handling the configurations that one can find in EntLib app blocks? If the latter is true, what are the configuration extensibilty points to make it more structural?
An interesting scenario will be how it behaves if the container has the specific strategies registerd for the type declared for instance?
Similar to the following:
1) in the Types register the singleton for thr TypeA
2) in the Instances register the element of TypeA with the specific name of NameA and value of ValueA
Will the container end up with a generic singleton for the TypeA and an instance creation each time the client asks for the NameA of TypeA.
In the scenario you describe, if you request TypeA without a name, you'll get a singleton created by the container on first request. If you request TypeA with NameA, you'll get the instance that was created when the configuration was applied to the container.
If you request by any other name, it'll be a transient object.
The Instances feature is primarily for setting up values of primitive types like strings, ints, datetimes, etc. Anything that can be represented by a single string. For larger configuration stuff, we expect that an extensionConfig element would be used separately.
The configuration stuff is still being fleshed out, so please keep the comments and suggestions coming!