DryIoc | DryIoc is fast , small , full-featured IoC Container for .NET | Dependency Injection library

public HomeViewModel(InboxService inboxService)

This injects a concrete InboxService instance, which is independent of the registration of interfaces that it might implement. If you want your singleton, request an IInboxService:

public HomeViewModel(IInboxService inboxService)

I try to give a service implementing a certain interface a meaningful name that's more than just interface's name minus I, like DummyInboxService, TestInboxService, ImapInboxService, Pop3InboxService, RemoteInboxService... thus making clearer what the respective implementation actually does and helping finding these errors (most likely a typo anyway) early.

If you specifically want to use 'Dryloc', you could try to use one of these Nuget packages:

• Prism.Container.Extensions
• Prism.DryIoc.Extensions

They should both be of general use and not target a specific UI technology.

If you install 'Prism.DryIoc.Extensions' using the Nuget-Package manager, dependent packages should be installed automatically.

See Github - Prism.Container.Extensions

Note there is also a package 'Prism.Core' that does not target a specific UI framework either. If contains features like an event aggregator.

Is there a way to find the list of currently registered views for navigation directly from Prism or the Container ?

Not using the IContainerRegistry interface but using the DryIoc implementation:

The DryIocServiceProviderFactory will override the existing container rules to conform to MS.DI container. Here is the code: https://github.com/dadhi/DryIoc/blob/5e3f1f7edfe237f69ba33c9166d17e284ca4781a/src/DryIoc.Microsoft.DependencyInjection/DryIocAdapter.cs#L97

Here how the rules are overriden in detail:

Or is it mandatory that a module has a screen?

No, of course not, modules have nothing to do with views or view models. They are just a set of registrations with the container.

what would be the best way to create the instance?

Let the container do the work. Normally, you have (at least) one assembly that only contains public interfaces (and the associated enums), but no modules. You reference that from the module and register the module's implementations of the relevant interfaces withing the module's Initialize method. Some other module (or the main app) can then have classes that get the interfaces as constructor parameters, and the container will resolve (i.e. create) the concrete types registered in the module, although they are internal or even private and completely unknown outside the module.

This is as loose a coupling as it gets if you don't want to sacrifice strong typing.

is there a way to get rid of that var searcher = containerProvider.Resolve(); and a better way to achieve this?

You can skip the var searcher = part :-) But if the HotfixSearcher is never injected anywhere, it won't be created unless you do it yourself. OnInitialized is the perfect spot for this, because it runs after all modules had their chance to RegisterTypes so all dependencies should be registered.

If HotfixSearcher is not meant to be injected, you can also drop IHotfixSearcher and resolve HotfixSearcher directly:

We ended up removing ActionForm from the site and the API started working as expected. So it was related to dependency injection conflicts. I could have done a paid upgrade to ActionForm to get a more recent version that fixed it (we were using v5.1.54), but instead there was only 1 contact form, so we replaced it with something else, removed AF and the issue vanished.

First, you may reuse the same MEF code with the DryIoc.MefAttributedModel.dll extension.

With the DryIoc alone, you need to specify the mapping between the parameter name (or Type, or position) and the servicKey:

The simplest type-safe way to do so is to resolve the function of item:

first, you are not using SetBinding correctly