Auto-bootstrap design time provider services through Attribute

As described in #5617, EF Core tooling currently scans the startup assembly for a class that implements IDesignTimeServices, then invokes ConfigureDesignTimeServices. This allows for registering implementations of EF Core interfaces in order to customize behavior. However, the ability to customize the EF Core toolchain could be improved, so that the requirement for the developer to add a IDesignTimeServices implementation class can be removed.

If EF tooling can scan referenced assemblies for a IDesignTimeServices implementation, then services can be configured by a class library or NuGet package rather than the developer who is consuming an extension to the EF tooling. This helps reduce the amount of friction so that the only thing a developer as to do is add a package that is self-configuring. EF tooling can scan the startup assembly first and use an IDesignTimeServices if one exists, so the developer can still control the process. But if the startup assembly does not contain an IDesignTimeServices, then EF tooling can scan referenced assemblies for an IDesignTimeServices and use it if it finds one.

In addition to bringing in IDesignTimeServices from referenced assemblies, I would suggest adding an argument to dotnet ef dbcontext scaffold for the name of a NuGet package containing an IDesignTimeServices implementation. That way, a project can reference multiple packages containing IDesignTimeServices implementations and the developer can select the one to use when executing the scaffolding command. So for example, a .NET Core library can reference a package that generates C# class as well as one that generates TypeScript classes, then he or she can pass the name of one package or the other to dotnet ef dbcontext scaffold in order to generate either C# or TypeScript classes.

[bricelam]

@tonysneed I’ve ported the EF6 pluralizer and packaged it appropriately in bricelam/EFCore.Pluralizer.

[bricelam]

My brain has been churning on this, and I think --design-time-services is too coarse-grained for what we want. It should be fine to add lots of design-time services (e.g. a pluralizer, a Migrations code generator, a Reverse Engineer code generator, etc.). The problem comes when two of those things conflict (i.e. there ends up being more than one of the same service). We mitigate this a bit by flowing in the project language (e.g. we won’t pick an F# scaffolder on a C# project), but you could still have two flavors of scaffolding for the same project language.

I wonder, however, if this problem is specific to your tool. If you added a new command (as discussed in #10156), you could replace the scaffolding factory (drafted in bricelam:lang) with one that selects based on user-input on the command line.

If it’s otherwise a problem, conflicts could be resolved by either uninstalling one package, or by adding an IDesignTimeServices implementation the the app that picks which one to use. It’s not dynamic, but I can’t see why (outside of your tool) you’d want to change it between runs.