Why does a Unity registration break Prism's ability to find my module?

Question

In my subclass of UnityBootstrapper I register a type in the class's ConfigureContainer() method. For this question the interface type and implementation class are irrelevant; they exist and can be resolved. What is relevant is that the interface and type are defined in the same assembly (let's call it C) that contains the module that I want to load.

I have two other modules in assemblies A and B. These modules are found by the DirectoryModuleCatalog used in the bootstrapper's InitializeModules() method; assembly C's module is not.

When I remove the problematic registration, C is found. When I move the interface and target class to another assembly and re-add the registration, C is again found.

When I move the registration from the bootstrapper to inside the constructor of C's module and register it there using the injected IUnityContainer, the module is found, and the registration succeeds.

So, it appears that somehow registration order and location are affecting module loading, and doing so silently with no exceptions. For now I'm living with the "register types from my module's assembly in that module's constructor" approach, but this feels like a workaround.

Is this "the way to do it"? Is this a known limitation or bug?

Answer 1

Not sure as to why this happens, but "register types in the module in the modules Initialize method" is the way to go. That's the job of the module - to register the types that it brings to the application.

Normally, you don't reference modules - because any set of modules can come into the app at runtime - so you cannot register a module's types outside the module anyway. If, for example, you have an interface that you want to use in one module but have the implementation of it in another module, move that interface in a third assembly (that most likely contains no module definitions).