When I was writing this question, I was kind of lost in the details while introducing Dependency Injection in an existing code base. The question wasn't too well written, I was aware of that at the time, but I didn't know how to improve my explanation of the problem.
That being said, here's how I solved my issue.
As I've said, I have an application that compares multiple products. These products can be thought of as multiple implementations of the same interface. So I need to use these multiple implementations concurrently. All these products are actually complex objects, with multiple dependencies, and many of those objects are constructed with runtime data and therefore are not created by construction injection.
My problem was with the objects that weren't created by constructor injection. By the time they needed to be constructed, I had lost the context of the current product, and couldn't create the appropriate types for that product.
I created child containers for every product to define which implementations were needed for specific interfaces per product.
At some point, I'm creating a product instance. This is the only place in the code where I ask for the appropriate container (like: give me the child container for product X). All I needed to do then (at product creation), was to create a factory object (that has a reference to the appropriate container), and pass it along to every object that needed to resolve components dynamically, i.e. not by constructor injection.
That was the missing link. I'm still wondering if the factory really needs to know the container, but I can live with that.
I hope this helps someone.
