dependency injection oddity with AddDapperCX ext method

[adamfoneil]

I'm working on making Dapper.CX more service-friendly, moving away from extension method access. To make this easy to setup during Startup, I want to provide some extension methods that configure the necessary services to make user profile integration really nice, as this part is a little bit tricky -- involving a custom claims factory, and converter class that can convert Claims into TUser and back. (This is needed so that a strong-typed TUser profile class can be used without a database round trip with every page view.) I have a couple of methods already. The first one works, but is not ideal because it doesn't let you use a more derived type of SqlCrudService.

The issue here is to get the second overload of this shown below to work. I want the ability to inject a more derived type of TService that must inherit from SqlServerCrudService. In the repo sample app, that type is DataAccess. The reason for this is that your data access service typically has app-specific functionality and helpers that you need access to anywhere in an application. If you're stuck with the built-in SqlServerCrudService class, then there's nowhere to put your custom methods. (Well, you could add an additional service, but I'm trying to avoid that for the sake of keeping constructors across an app as simple as possible.)

This overload works, and used here though is currently commented out:

• void AddDapperCX (this IServiceCollection services, string connectionString, Func<object, TIdentity> convertIdentity, Func<DbUserClaimsConverter> claimsConverterFactory)

The problem with this overload (the one I really want to work) is that the AddScoped line is being skipped for some reason by the runtime.

• void AddDapperCX (this IServiceCollection services, Func<DbUserClaimsConverter> claimsConverterFactory, Func<IServiceProvider, TService> serviceFactory)

You can see this behavior in the repo's sample app Startup.

[adamfoneil]

not sure I'll continue with this. The only reason to support a more derived service type is to add your own methods relevant to your application. (For example SqlChartify has a CopyReport method or something.) After some thought, I realize that extension methods would work for this case. I think I will fall back to what's currently working