Entity Framework (code first) falsche Kardinalität

Hallo,

in meiner Anwendung (basierend auf EF6 und NET4.5) verwende ich als Strategie Code-First mit Code-based Migration und MigrateDatabaseToLatestVersion als Initialisierer. Einer meiner Kunden berichtete mir nun kürzlich nach dem Einspielen eines Updates, dass beim Start eine AutomaticMigrationsDisabledException geworfen wird. Merkwürdigerweise aber nur auf 2 Arbeitsstationen. Andere Anwender haben dieses Problem nicht.

Um dem Ganzen auf die Schliche zu kommen, habe ich AutomaticMigrations aktiviert um EF ausführen zu lassen, was auch immer es ausführen möchte. Nachdem dies geschehen ist, habe ich den entsprechenden Eintrag aus der Tabelle "__MigrationHistory" genommen und aus der model-Spalte ein Entity Data Model (EDMX) generiert. Darin habe ich gesehen, dass das Entity Framework aus einer 1:1 - Beziehung (EDMX : Multiplicity="1") eine optionale Beziehung (EDMX : Multiplicity="0..1") machen will. Die Property meiner Klasse, auf welcher diese Beziehung beruht ist eine einfache GUID (nicht nullbar). Somit ergibt eine optionale Beziehung wie sie erstellt werden soll keinen sinn. Das merkwürdigste ist aber, dass das Problem lediglich auf 2 Arbeitsplätzen auftritt. Glücklicherweise sind dies die Arbeitsplätze der beiden Administratoren und werden somit auch nur zu administrativen zwecken genutzt. Dennoch muss das Problem gelöst werden. Hat jemand bereits ein ähnliches Problem gehabt oder eine Idee wo ich noch ansetzen könnte?

MfG Hurby

Automatisches Migrieren war schon immer als riskant markiert und nicht der empfohlene Weg.

Kannst Du prüfen, ob das Schema bei diesen beiden Arbeitsplätzen anders ist als bei den funktionierenden?
Oder ist es schon die Aussage, dass nur bei diesen beiden Arbeitsplätzen das Schema anders ist?

Hast Du die InnerException zur originalen Fehlermeldung?

Hallo Abt,

das Schema ist bei allen identisch. Alle greifen auf dieselbe Datenbank zu. Die Datenbank-Anmeldung ist an eine Active-Directory-Gruppe gekoppelt, in der die entsprechenden Benutzer Mitglied sind. Gegenwärtig verfüge ich nur über den entsprechenden Eintrag des Windows-Ereignisprotokolls. Ich werde mich mal um die InnerException bemühen...

So... Die Exception hat keine InnerException. Der Vollständigkeit halber hier mal die Details der Ausnahme:

Fehlermeldung:
message: Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.

stacktrace: bei System.Data.Entity.Migrations.DbMigrator.Upgrade(IEnumerable1 pendingMigrations, String targetMigrationId, String lastMigrationId) bei System.Data.Entity.Migrations.DbMigrator.UpdateInternal(String targetMigration) bei System.Data.Entity.Migrations.DbMigrator.EnsureDatabaseExists(Action mustSucceedToKeepDatabase) bei System.Data.Entity.Migrations.DbMigrator.Update(String targetMigration) bei System.Data.Entity.MigrateDatabaseToLatestVersion2.InitializeDatabase(TContext context)
bei System.Data.Entity.Internal.InternalContext.PerformInitializationAction(Action action)
bei System.Data.Entity.Internal.InternalContext.PerformDatabaseInitialization()
bei System.Data.Entity.Internal.RetryAction1.PerformAction(TInput input) bei System.Data.Entity.Internal.LazyInternalContext.InitializeDatabaseAction(Action1 action)
bei System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType)
bei System.Data.Entity.Internal.Linq.InternalSet1.Initialize() bei System.Data.Entity.Internal.Linq.InternalSet1.get_InternalContext()
bei System.Data.Entity.Infrastructure.DbQuery1.System.Linq.IQueryable.get_Provider() bei System.Linq.Queryable.Where[TSource](IQueryable1 source, Expression`1 predicate)

source: EntityFramework

Mittlerweile habe ich keine Idee mehr, wo ich noch ansetzen könnte.

Für mich sieht das so aus, dass das Schema nicht aktuell ist.
Kannst Du die Unterschiede in der DB prüfen; dort gibt es eine Schema-Versionverwaltung.