C:\Program Files (x86)\Microsoft SDKs\Surface\v1.0 and
C:\Program Files (x86)\Microsoft Surface\v1.0

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");


Of course you are right, but this is generally the case with all “thread safe” classes. We can attempt to guarantee all of our public methods are safe to call concurrently from separate threads, but there’s no way to ensure that *multiple calls* from one thread happen before calls from another. In this scenario you will require an external lock.

The reason I generally use “thread safe” in quotes is partly for this reason. We can do our best to make our internals safe, but you still need to make sure that your calling code isn’t doing anything inherently unsafe.

The code you pasted won’t error, you just might not end up with quite the value you expect, but even with your locks in place another thread may overwrite your new value immediately, so the lock in your example seems to add little value.

Thanks,

Steve

What happens if somebody call the below code from multiple threads

if(safeDictionaryObj["MyKey"] == “SomeValue”)
{
safeDictionaryObj["MyKey"] = “NewValue”;
}

It won’t be working as expected, so we may have to lock the entire if statement again to make it thread safe.

lock(__alockobj)
{
if(safeDictionaryObj["MyKey"] == “SomeValue”)
{
safeDictionaryObj["MyKey"] = “NewValue”;
}
}

So the composition class you have created may not holds good for this scenario.