What he means there is that the IoC just wraps a container, so it would be possible to wrap multiple containers, given the ability to discriminate among them.
If a single container (or container instance) is/must be used, the same 'context' concept still holds: components should be registered and retrieved using keys that are module-dependant.
Now, if your goal is finding a way to don't touch existing application (module), I fear you're almost out of luck. Otherwise, you need to carefully design a context-aware mechanism for both registration and retrieval of components, so that every object that deals with the IoC is able to provide a unique key.
It is quite hard to help you at this point, since I have no clear idea of what kind of objects are 'conflicting', how are they registered, if they can actually be shared among modules or not... etc. Moreover, as stated above, if you can't touch the module code (you never said you can't, tho) there is probably no way to achieve what you need in a single AppDomain.
If a single container (or container instance) is/must be used, the same 'context' concept still holds: components should be registered and retrieved using keys that are module-dependant.
Now, if your goal is finding a way to don't touch existing application (module), I fear you're almost out of luck. Otherwise, you need to carefully design a context-aware mechanism for both registration and retrieval of components, so that every object that deals with the IoC is able to provide a unique key.
It is quite hard to help you at this point, since I have no clear idea of what kind of objects are 'conflicting', how are they registered, if they can actually be shared among modules or not... etc. Moreover, as stated above, if you can't touch the module code (you never said you can't, tho) there is probably no way to achieve what you need in a single AppDomain.