It should be .Register with two template types Interface and Concrete
.Resolve with one template type of Interface

My last code was not quite sufficient. Should look like this:

var container = TinyIoCContainer.Current;
container.Register();
var v = container.Resolve();

// Infinite recursion in ‘Resolve’ and blows up.

Thoughts?

var container = TinyIoCContainer.Current;
container.Register();
var v = container.Resolve();

// Simulator crashes, no exception, no callstack

Thanks for pointing this out, it’s now been fixed.

Cheers

[TestMethod]
public void Register_NamedInstanceRegistration_CanRegister_And_Dispose()
{
var container = UtilityMethods.GetContainer();
var item = new TestClassDefaultCtor();

container.Register(item, “TestName”);

container.Dispose();
}

is possible enumerate all types of in container… like GetAll()

thx

I have considered adding a predicate overload to dictate whether a type is registered or not, but I’m not entirely sure if it’s overkill or not.

Loving this IoC – works perfect in MT – going to give it a whirl in monodroid too. One thing I can see being an advantage would be to filter the auto reg so that it doesn’t try and register everything. Something like the Windsor API:

container.Register(
AllTypes.Of()
.FromAssembly(Assembly.GetExecutingAssembly())
);

Though that may be a bit much – some way of filtering would be good – unless the overhead for large projects is minimal?

w://

I could take that IEnumerable and pass it into a user specified delegate, but I’m not sure whether that’s taking AutoRegister too far or not – if there’s definite logic you need in your registrations, or if you need named registrations etc., then you might be best either switching to just Register, or mixing AutoRegister with some specific Register commands afterwards?

You can mix and match AutoRegister and Register, and even AutoRegister more than one assembly, so you could AutoRegister your common library first, then do it against your app assembly to copy over any customisations you have in there.

container.AutoRegister().AmbiguousResolutionBehaviour(types => types.First())

container.AutoRegister().AmbiguousResolutionBehaviour(types => throw new AmbiguousResolutionException(types))

container.AutoRegister().AmbiguousResolutionBehaviour(MyCustomMethodForResolvingWhichOneIWant)

It’d be pretty cool if, when faced with multiple implementations, it picked up the one in the launch assembly first. This way you can have a default implementation of a service in a common library, but override it in your different applications.

I’ll also add support for abstract base classes too, in the same way that interfaces get added.

In my mind, if you hit this issue you can either:

a. Get rid of autoregistration and switch to a more “standard” manual approach.
or, my preferred option:
b. Auto-register to get the vast majority of registrations done, then manually register your exceptions:


container.AutoRegister();
container.Register();
container.Register("OtherOne");