Custom TypeInjectionElement Property Values?

Feb 7, 2009 at 11:22 PM

Within Unity I’m able to define ‘static’ parameter values for types registered within a container. What I really need is a way to assign the values at runtime (the value of these parameters will only be known then) the current configuration for static looks like this:


   <type type="ATO.EN.ApplicationServices.Document.HeaderDocument, ATO.EN.ApplicationServices">

            <typeConfig extensionType="Microsoft.Practices.Unity.Configuration.TypeInjectionElement, Microsoft.Practices.Unity.Configuration">

              <property name="ApplicationId" propertyType="System.Int32">

                <value type="System.Int32" value="19" />


              <property name="QualityOfService" propertyType="System.String">

                <value value="100" />




Is it possible to provide the values at runtime but to define thems within configuration (value="CallMeForIt") – I’d like to not have to write a custom strategy as it extends the whole container rather than the individual type but to extend (if possible) the current support i.e., the value. Container Etensions - it would be good to register extensions against types within the container rather than the whole container...



Feb 9, 2009 at 9:24 PM
It is possible to provide custom configuration for the values of properties or parameters. We had a discussion of this in the now (incredibly irritatingly) lost Unity extensibility webcast. However, the code samples are available for download here. Take a look at the OptionalDependency stuff in there. You can write your own resolver object to do whatever you want, including call whatever methods you want to derive a value.

You won't be able to pass in a parameter at runtime through the Resolve method, though - that'sa whole different feature request.

Feb 12, 2009 at 3:48 AM
I'm wondering if you could give me an idea of how one might implement a method to pass parameters to the Resolve method?

I'm assuming this would be done through a container extension but am a little fuzzy on how exactly that would happen.
Feb 12, 2009 at 9:02 AM
It requires fundamental surgery on the container, you can't just use an extension. In order to do that, you'd need to change the logic on how values are looked up for dependencies. You'd need to update every Resolver object to look in whatever store you put the Resolve parameters in first. It could be done, but you also have to figure out how to line up constructor parameters vs. property values, which values go in which overloads, and other such things. It's not just a simple extension.

Personally, I'm not convinced that resolve with arguments really makes sense given how the container should be used. If you're passing arguments, you're making assumptions about the dependencies that the object you're building up has - should you even be making that assumption? Of course, the number of people who've asked for it is pretty high, so I'm seriously evaluating how to add it to the next version of the container.

Feb 12, 2009 at 2:20 PM
Thanks for the explanation Chris.

I'm not sure I'm knowledgable enough about IoC and DI to make the call whether having a container that takes parameters on a Resolve call is a good thing or not.  The reason I'm pursuing this is that one of the libraries I'm working with is built to be "container aware" but requires the container adapter to support resolving with parameters.

Recently I've been surveying the available containers out there and I thought that AutoFac's method of supporting parameters is really neat.  They use delegates that represent a factory for a given dependency.  The cool thing is that if your "service" that fulfills a dependancy has additional parameters the container will attempt to autowire them in.  In this way the client can still use the known factory delegate and pass in some known parameters and defer the rest of the dependencies to the container.  In my opinion this is much nicer than the key/value property bag approach that Castle Windsor (and other containers, I think) uses.  

Anyways, I may dig into it a bit, but thanks again for the explanation.