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
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
DynamicTypeLookupService)DynamicTypeLookupService)StaticTypeLookupService,TypeCollection)DynamicTypeLookupServiceand its subclassesDynamicTopicLookupServiceDynamicTopicViewModelLookupServiceDynamicTopicBindingModelLookupServiceAssemblyDiscoveryhelper (new class inOnTopic.AspNetCore.Mvc) that unions loaded assemblies with the host's dependencies viaDependencyContext_ = new PageTopicViewModel()force-load hack, in favor ofAssemblyDiscovery(SampleActivator,OnTopic.AspNetCore.Mvc.Host)AssemblyDiscovery.GetReferencedAssemblies()returns a superset of the loaded-assemblies list without throwing an exceptionEditorViewModelLookupService,AttributeBindingModelBinder