So I have an issue with the latest StructureMap (v4.6.1) in a ASP.Net Core Web API application:
Here is what I have:
- Web API Project
- Interface Project
- Assembly A (Implements subset of interfaces from the Interface Project)
- Assembly B (Implements the remainder of the interfaces defined in the Interface Project)
Assembly A uses standard conventions for implementing the interfaces i.e. interface ISomething is implemented in a class called Something.
Assembly B also implements several generic interfaces defined in Interface project. There is no special convention used in naming these implementations.
Both Assembly A and Assembly B are built and deployed in the root folder from which the Web API Project executes. The Web API project does NOT reference any of the underlying assemblies (Interface, Assembly A and Assembly B).
In the Web API project Startup.cs I have the following:
public IServiceProvider ConfigureServices(IServiceCollection services)
{
services.AddMvc();
var container = new Container();
container.Configure(c =>
{
c.Scan(scanner =>
{
scanner.AssembliesFromApplicationBaseDirectory();
scanner.WithDefaultConventions();
});
c.Populate(services);
});
return container.GetInstance<IServiceProvider>();
}
When I check for the registered assemblies the concrete types that are using the default conventions are not picked up by the scanner even thou the assemblies are present at runtime.
What I would like to achieve is the following:
- Have the scanner scan the directory and bind the classes it knows how to bind using standard conventions
- For the rest of the interfaces (especially the generic interfaces not following any specific conventions) to use a registry defined in the assembly where the concrete type is defined
- Essentially, I would like to treat my underlying architecture as a plugin to the executing environment i.e. be able to dynamically add assemblies that implement interfaces and have the DI container register them either by using default conventions or a registry class I have defined in an assembly.
Note: I also tried adding the scanner.LookForRegistries() to the scanner but to no avail.
Note #2: There are also other assemblies containing interfaces which the API references that are implemented elsewhere in another assemblies. Those are being picked up by the scanner but the dependencies of those dependencies are not.