Ich frage mich, ob jemand auf das Problem gestoßen ist, das ich beim Versuch habe, mich zu bewegenApplicationUser in Modellprojekt (in dem sich alle anderen Modelle befinden, einschließlich der Modelle, die mit der Benutzertabelle zusammenhängen).

Meine MVC 5-Testlösung besteht aus einem Webprojekt und zwei Klassenbibliotheken: eine für die Datenzugriffsebene (DAL) und eine für Modelle. In allen drei Projekten verweise ich auf AspNet.Identity.EntityFramework. In meiner DAL-Klasse implementiere ich ein Repository-Muster und ein UnitOfWork. UnitOfWork erweitertIdentityDbContext<ApplicationUser>. ApplicationUser: IdentityUser befindet sich in der Klassenbibliothek Models.

In meinem Webprojekt wird UnitOfWork mit Autofac DI instanziiert. Für reguläre Controller habe ich eine Basisklasse definiert, die von Controller erbt und IUnitOfWork als Parameter im Konstruktor verwendet. Alle Controller erben von meinem benutzerdefinierten Basiscontroller. Ich bin auf ein Problem mit gestoßenAccountController. Es hat zwei Konstruktoren: einen ohne Parameter, der zu instanziieren scheintApplicationDbContext, der andere verwendet UserManager als Parameter.

Der parameterlose Konstruktor bereitet mir den größten Kummer. Ich habe viele Dinge ausprobiert: machenaccountcontroller Von meinem benutzerdefinierten Basis-Controller erben. Versuchen Sie dann, ihn von der Controller-Klasse zu erben. Bestenfalls gelingt es mir, meine Lösung kompilieren zu lassen, aber wenn ich die App teste und das Benutzerregistrierungsformular ausfülle, erhalte ich die Meldung "Objekt ist nicht instanziiert". Beim Debuggen sehe ich, dass der zweite Konstruktor inAccountController wird aber gerufenUserManager ist dort null.

Irgendwelche Ideen? Ich würde es wirklich begrüßen, wenn jemand einen schlauen Beitrag dazu leistet.