Does this work with `AutoMapper.Extensions.Microsoft.DependencyInjection`?

[ChristopherHaws]

Hi Jimmy,

Is there a way to setup the GenerateEntityFrameworkCorePrimaryKeyPropertyMaps when using AutoMapper.Extensions.Microsoft.DependencyInjection? From what I can see, GenerateEntityFrameworkCorePrimaryKeyPropertyMaps needs an IServiceProvider, which is not available in ConfigureServices without registering the service using the implementation factory overload of one of the Add calls on IServiceCollection.

Ideally, I would like to be able to do something along the lines of:

services.AddAutoMapper(mapper =>
{
	mapper.AddCollectionMappers();
	mapper.SetGeneratePropertyMaps<GenerateEntityFrameworkCorePrimaryKeyPropertyMaps<MyContext>>();
});

but there appears to be a chicken and egg problem here. From what I can tell, SetGeneratePropertyMaps immediately creates an instance of the property map generator and attempts to build the mappings rather than doing it after the container has been built or when IMapper is resolved.

Thanks! :)

[TylerCarlson1]

If the MyContext has a default constructor you can pass null in the IServiceProvider and it will generate a new object using Activator.

@jbogard
Need new repo AutoMapper.Extensions.Collection.Core.Microsoft.DependencyInjection or something?

[jbogard]

Isn't the collection stuff just an extension off the configuration interface? If so then you don't need to do anything special.

But if you need to do something after initialization, you'll want to do something like services.UseCollectionMappers(); like the other post-configuration stuff.

[ChristopherHaws]

@jbogard Is there a way to call SetGeneratePropertyMaps after building the IServiceProvider? The only way that I know of is by using static initialization (Mapper.Initialize) but I am using AddAutoMapper.

As @TylerCarlson1 mentioned, I could create a parameterless constructor on my DbContext, but that would require me to do one of two things:

1. Hard code my connection string into my EF Context in OnConfiguring(DbContextOptionsBuilder optionsBuilder)
2. Hard code my EF Context to use an in memory database in OnConfiguring(DbContextOptionsBuilder optionsBuilder), requiring me to take a dependency on Microsoft.EntityFrameworkCore.InMemory in my application which is not ideal.

The prefered approach would be to pass IServiceProvider into GenerateEntityFrameworkCorePrimaryKeyPropertyMaps, but I don't see a way to do this when using AutoMapper.Extensions.Microsoft.DependencyInjection.

[jbogard]

First, you could enforce that you must call services.AddAutoMapper() after calling services.AddDbContext or AddEntityFramework.

Then, you can make the GenerateEntityFrameworkCorePrimaryKeyPropertyMaps force you to take a DbContext instance:

services.AddDbContext<MyContext>();


services.AddAutoMapper(typeof(Startup), cfg => {
    cfg.AddCollectionMappers();
    var sp = services.BuildServiceProvider();
    var dbContext = sp.GetService<MyContext>();
    cfg.SetGeneratePropertyMaps<GenerateEntityFrameworkCorePrimaryKeyPropertyMaps(dbContext);
});

[ChristopherHaws]

I suppose that would work. I would need to make sure I dispose of the service scope and context once I am done with it. How hard would it be to make it so that AutoMapper.Collections didn't try to build the cache during service registration but rather on the first resolve of IMapper? Are there any specific reasons why the mapping configuration must be done at registration time?

Another way this could work (albeit not my favorite approach) would be to not rely on the DbContext implementing OnModelCreating(ModelBuilder builder). When calling services.AddDbContext, you can specify UseModel so that EF Core doesn't need to create a context to get the model (since that is really all that GenerateEntityFrameworkCorePrimaryKeyPropertyMaps needs.

With very minor changes to this library, something like this would work:

var modelBuilder = new ModelBuilder(new ConventionSet());
modelBuilder.Entity<Blog>().HasKey(x => x.BlogId);
modelBuilder.Entity<Post>().HasKey(x => x.PostId);

services.AddDbContext<BlogContext>(options =>
{
	options.UseSqlServer("Server=.; Database=Blog; Integrated Security=True; MultipleActiveResultSets=True;");
	options.UseModel(modelBuilder.Model);
});

services.AddAutoMapper<BlogContext>(mapper =>
{
	mapper.SetGeneratePropertyMaps<GenerateEntityFrameworkCorePrimaryKeyPropertyMaps<MyContext>>(modelBuilder.Model);
});

Even so, I would prefer it if AutoMapper.Collections had the ability to defer configuration until IMapper is first resolved and thus IServerProvider is accessible, or as you mentioned app.UseCollectionMappers().

[TylerCarlson1]

I think @jbogard is close but more like this.

services.AddDbContext<MyContext>();

services.AddAutoMapper(cfg => {
    cfg.AddCollectionMappers();
    cfg.SetGeneratePropertyMaps<GenerateEntityFrameworkCorePrimaryKeyPropertyMaps<MyContext>>(services);
});

The internals will create the context and then dispose of it after it's done finding primary key maps.

The EF core logic was taken from EF6, which requires the DbContext to ascertain the Primary Keys for comparison.
@Tasteful translated this over, so I'm sure he would know better than I how you can obtain the PK's for a given class, and also for it's intended configuration.

[jbogard]

Ah yeah that makes way more sense!

…

On Thu, Aug 9, 2018 at 7:05 PM Tyler Carlson ***@***.***> wrote: I think @jbogard <https://github.com/jbogard> is close but more like this. services.AddDbContext<MyContext>(); services.AddAutoMapper(cfg => { cfg.AddCollectionMappers(); cfg.SetGeneratePropertyMaps<GenerateEntityFrameworkCorePrimaryKeyPropertyMaps<MyContext>>(services); }); The internals will create the context and then dispose of it after it's done finding primary key maps. The EF core logic was taken from EF6, which requires the DbContext to ascertain the Primary Keys for comparison. @Tasteful <https://github.com/Tasteful> translated this over, so I'm sure he would know better than I how you can obtain the PK's for a given class, and also for it's intended configuration. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGYMpvus_D2zvotQrBt6wdoWa0EpiIdks5uPM5EgaJpZM4V0Zk2> .

[Tasteful]

Did you look at the test that using the DI and how them are setup? https://github.com/AutoMapper/AutoMapper.Collection.EFCore/blob/development/src/AutoMapper.Collection.EntityFrameworkCore.Tests/EntityFramworkCoreUsingDITests.cs

In the init of automapper I set the method that we should use to construct object to use the helper methods from the DI library, not sure how/If this is set when using the AddAutoMapper extension.

[jbogard]

Yeah, I think those tests shouldn't use the static version, AddAutoMapper does not use the static registration. And it doesn't use ConstructServicesUsing, it instead creates a Mapper object with the correct factory method (see the overloaded constructors).

…

On Thu, Aug 9, 2018 at 11:41 PM Patric Forsgard ***@***.***> wrote: Did you look at the test that using the DI and how them are setup? https://github.com/AutoMapper/AutoMapper.Collection.EFCore/blob/development/src/AutoMapper.Collection.EntityFrameworkCore.Tests/EntityFramworkCoreUsingDITests.cs In the init of automapper I set the method that we should use to construct object to use the helper methods from the DI library, not sure how/If this is set when using the AddAutoMapper extension. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGYMsNfe2D28SZukrNEuWf-oMcelrzPks5uPQ7rgaJpZM4V0Zk2> .

[Tasteful]

One option is to pass the IServiceProvider when the AddAutoMapper is building it's config.

If we add an overload to the existing

public static IServiceCollection AddAutoMapper(this IServiceCollection services, Action<IMapperConfigurationExpression> additionalInitAction)

that also will send in the IServiceProvider in the config method like this

public static IServiceCollection AddAutoMapper(this IServiceCollection services, Action<IServiceProvider, IMapperConfigurationExpression> additionalInitAction)

then we will have the IServiceProvider directly and can use that when register the EFCore mappings direcly

services.AddAutoMapper((serviceProvider, cfg) => {
    cfg.AddCollectionMappers();
    cfg.SetGeneratePropertyMaps<GenerateEntityFrameworkCorePrimaryKeyPropertyMaps<MyContext>>(serviceProvider);
});

MS is doing this for configuring EFCore itself https://github.com/aspnet/EntityFrameworkCore/blob/c07c2cef92a30e1f8272db0395756e836e47d864/src/EFCore/EntityFrameworkServiceCollectionExtensions.cs#L216

[Tasteful]

Blocking AutoMapper/AutoMapper.Extensions.Microsoft.DependencyInjection#77