includeAssembliesForScan not included in allAssemblies?

[IvanLieckens]

When using External DI the "allAssemblies" that are scanned according to the common conventions do not include the "includeAssembliesForScan".

Does this have a specific design reason?

[NightOwl888]

Yes.

includeAssembliesForScan controls the assemblies where the ReflectionSiteMapNodeProvider scans for MVC controllers/actions with MvcSiteMapNodeAttribute, and works the same way whether using internal or external DI. This concept was carried over from v3, and is analogous to the "MvcSiteMapProvider_IncludeAssembliesForScan" configuration setting when using internal DI. The scan happens repeatedly during the application lifecycle each time the cache expires, so it is important only the assemblies that have controllers with MvcSiteMapNodeAttribute are listed.

The allAssemblies variable is where the external DI module (using CommonConventions as a helper) scans for custom implementations of interfaces using the default conventions. The conventions make it possible for us to add new interfaces to the design without you having to update the DI module code, while also allowing custom implementations to be injected if needed by specifying them explicitly. If you intend to implement MvcSiteMapProvider interfaces in an assembly that is not listed, you can add that assembly type here. This scan happens only once during application startup (and each time the app pool is recycled).

The primary reason these are separate is because they evolved individually with different purposes. CommonConventions (and the associated currentAssembly, siteMapProviderAssembly, and allAssemblies variables) came very late in the design after the realization that using each DI container's conventions would lead to several inconsistencies in behavior and code that is difficult to maintain (because each DI container did things in a different way). These 2 variables could be merged, I suppose, but not without a performance penalty for those people who keep their controllers and business classes in separate assemblies. It would be wasteful to scan MvcSiteMapProvider.dll for controllers with MvcSiteMapNodeAttribute, for example, but it is absolutely necessary to scan it for interface implementations.

[IvanLieckens]

Thank you for the explanation, it makes a lot more sense now. I believe it is indeed better to keep these separate but their naming could be more clear and/or have some added comment to explain this process.