The system's automatic scanner for custom view models only looks at assemblies the application has already "touched", so a consumer's view-model assembly may be invisible until something else happens to load it first. Today that's worked around with a fragile one-line hack that force-loads a known type. This closes that gap by asking .NET's dependency model for the full list of referenced assemblies, and retires the hack. This also fixes a couple of potential bugs and tidy's up some of the documentation.

Tasks

• Prevent a single unloadable type crashing the entire lookup (DynamicTypeLookupService)
• Document the class precedence, where consumer types override built-in OnTopic types (DynamicTypeLookupService)
• Document the existing class-name limitation, when two assemblies have the same class name (StaticTypeLookupService, TypeCollection)
• Add an constructor overload that accepts an assembly list to the DynamicTypeLookupService and its subclasses
  • DynamicTopicLookupService
  • DynamicTopicViewModelLookupService
  • DynamicTopicBindingModelLookupService
• Add an AssemblyDiscovery helper (new class in OnTopic.AspNetCore.Mvc) that unions loaded assemblies with the host's dependencies via DependencyContext
• Retire the _ = new PageTopicViewModel() force-load hack, in favor of AssemblyDiscovery (SampleActivator, OnTopic.AspNetCore.Mvc.Host)
  • Document that this degrades back to today's behavior under single-file, trimmed, AOT published package (unexpected for web apps)
• Add an integration test confirming AssemblyDiscovery.GetReferencedAssemblies() returns a superset of the loaded-assemblies list without throwing an exception
• Apply the same pattern to the OnTopic Editor's EditorViewModelLookupService, AttributeBindingModelBinder
• Create unit tests to validate the above logic