Modules in indirect NuGet dependency are loaded but not recognized.

[sarahelsaig]

Describe the bug

Suppose you have two C# projects: A and B. A depends on B, uses services declared by B, etc. Both are marked as modules using the OrchardCore.Module.Targets PackageReference. In your web project you import module A using ProjectReference. In module A you import module B using ProjectReference as well. This works as expected, when you go to Admin > Configuration > Features the features for both modules A and B show up without having to explicitly reference B from the web project.

But this breaks if you publish A and B as NuGet packages, and only import module A in your web project using PackageReference. In this scenario B is loaded as an indirect reference and the classes in it are available in the web project. But OC won't recognize B as a module, won't load its Startup file, B's features won't show up in the admin feature list. As a consequence when trying to use A you will get "Unable to resolve service" exceptions because services from B are not registered.

If you explicitly add B as PackageReference too, then it works again. But this is impractical and goes against NuGet's design.

Multiple users ran into this problem in OrchardCore.Commerce: only importing the main OrchardCore.Commerce package breaks, because none of the sub modules (Inventory, Payment, Promotion, Tax, etc) are treated as modules.

Orchard Core version

Tested it on 2.1.4 and 1.8.

To Reproduce

1. Create a new OC CMS solution.
2. Add <PackageReference Include="OrchardCore.Commerce" /> to the web project.
3. Set up site.
4. Go to Admin > Configuration > Features.
5. Enter "Commerce" in the search field.
6. Observe that there are less features listed than expected (e.g. missing Payment features).

Expected behavior

Features should show up even for indirectly referenced NuGet packages.

Workarounds / Possible Solutions

• Consumer: Explicitly reference all dependency packages. This is tedious and error-prone during updates.
• Package author: Add a custom Package.Build.props file to project which has OC module dependencies, which contains all the dependency modules in addition to its own assembly name. (example in OCC) Maybe this could be automated somehow in OrchardCore.Module.Targets?
• OC: Write a new IModuleNamesProvider implementation that's recursive.

[Piedone]

Related: OrchardCMS/OrchardCore.Commerce#456.

[github-actions]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.

[sebastienros]

In case someone tries to implement IModuleNamesProvider then it should only look in the assemblies that are themselves modules. So we don't start looking in dotnet packages for instance. Also obviously cyclic references.

[gvkries]

I think the solution with using a Package.Build.props like you've done in OCC is reasonable. OC requires all the modules being registered with an ModuleNameAttribute in the startup assembly, so currently the only way to do it must be done at build time. Otherwise we are talking about adding dynamic loading for modules, kind of similar to Orchard 1.