Hi,
Based on my understanding there is no method to know which instances, classes or type registrations came from each module. This is mainly because the concept of "module" is only valid before it's loaded and initialized. After that, the components exposed by the module become components of the application like all the others and hence, there is no distinction between them that could help you "know" from which "module" they came.
What's more, we could think of a module like simply a "logic abstraction" that groups a collection of types, instances and configurations to be added to the main application. Therefore, a module could be anything from an assembly to a collection of classes in you main application. The only requirement is to have what we could describe as the "definition of the module" which is a class implementing the IModule interface. Without it, we could argue that there would be no difference between an common assembly and a Prism module at all. At most, they could be assemblies with types to add to the container, which is something I believe that can be done using Unity directly without requiring to treat the assembly as a module.
Therefore, to implement the architecture you are describing you could drop the Prism modules and work with common assemblies directly. When you load them manually, you could then analyze it then, include the required configurations, register views in regions etc.
Regards,
Damian Cherubini
http://blogs.southworks.net/dcherubini
Based on my understanding there is no method to know which instances, classes or type registrations came from each module. This is mainly because the concept of "module" is only valid before it's loaded and initialized. After that, the components exposed by the module become components of the application like all the others and hence, there is no distinction between them that could help you "know" from which "module" they came.
What's more, we could think of a module like simply a "logic abstraction" that groups a collection of types, instances and configurations to be added to the main application. Therefore, a module could be anything from an assembly to a collection of classes in you main application. The only requirement is to have what we could describe as the "definition of the module" which is a class implementing the IModule interface. Without it, we could argue that there would be no difference between an common assembly and a Prism module at all. At most, they could be assemblies with types to add to the container, which is something I believe that can be done using Unity directly without requiring to treat the assembly as a module.
Therefore, to implement the architecture you are describing you could drop the Prism modules and work with common assemblies directly. When you load them manually, you could then analyze it then, include the required configurations, register views in regions etc.
Regards,
Damian Cherubini
http://blogs.southworks.net/dcherubini