Laden...

EF Core in .NET Standard Bibliothek: Migration kann nicht hinzugefügt werden

Erstellt von pinki vor 6 Jahren Letzter Beitrag vor 6 Jahren 2.976 Views
pinki Themenstarter:in
709 Beiträge seit 2008
vor 6 Jahren
EF Core in .NET Standard Bibliothek: Migration kann nicht hinzugefügt werden

Hallo zusammen,
ich beginne gerade mit der Entwicklung einer Webanwendung.
Diese ist ein ASP.NET Core WebAPI mit Angular-Frontend.

Folgende Projekte habe ich (inkl. Referenzen):

  • Frontend
  • Backend.API
    -- Backend.DataLayer.Abstraction
    -- Backend.DataLayer.Models
    -- Backend.DataLayer.MSSQL
  • Backend.DataLayer.Abstraction
    --Backend.DataLayer.Models
  • Backend.DataLayer.Models
    -- System.ComponentModel.Annotations
  • Backend.DataLayer.MSSQL
    -- Backend.DataLayer.Abstraction
    -- Microsoft.EntityFrameworkCore.SqlServer (2.0.1)

Alle Projekte im DataLayer sind .NET Standard (2.0) Bibliotheken.

Wenn ich nun versuche via Package Manager Console eine Migration zu erstellen, sagt mir diese einfach stumpf ":::

Einmal bekam ich die Meldung> Fehlermeldung:

Entity type 'Artikel' has composite primary key defined with data annotations. To set composite primary key, use fluent API.

Daraufhin habe ich die entsprechende Änderung vorgenommen und es kommt wieder ":::

Habt ihr einen Tipp für mich, wie ich an genauere Fehlermeldungen kommen kann?
Oder ist .NET Standard hier der falsche Weg und ich sollte direkt .NET Core nehmen?

Gruß, pinki

16.806 Beiträge seit 2008
vor 6 Jahren

(Whew.. interessante Projektstruktur. =)){gray}

  1. Das Tooling von .NET Core in VS hat durchaus noch Potential.
    Verwende die CLI, um mit .NET Core hier besser umzugehen und mehr Details zu bekommen.

  2. ich rate Dir aktuell wirklich ab EF Core in der 2.0 oder früher für die produktive Verwendung in Betracht zu ziehen.
    Da gibt es einfach viel zu viele offene Baustellen, als dass man das mit gutem Gewissen ignorieren könnte.

  3. Migrations (zumindest vor 2.0) müssen in einer app liegen und nicht in einem .NET Standard project.
    Das ist ein sehr bekannter Workaround, der auch in der Dokumentation des EF zu finden ist.
    Siehe auch
    Is EF Core Add Migration Supported from .NET Standard Library?
    Ob sich das tatsächlich mit EF 2.0 verbesser hat, das weiß ich nicht. Ich mache einen sehr großen Bogen um EF.

  4. die Fehlermeldung riecht stark nach einem Konfigurationsfehler im ModelBuilder.
    Siehe auch die Dokumentation dazu.

Von DataAnnotations rate ich sehr ab.

pinki Themenstarter:in
709 Beiträge seit 2008
vor 6 Jahren

Vielen Dank für deine Antwort.

Ich bin für jeden Verbesserungsvorschlag offen. =)
Wie wäre es denn besser?

Wenn du mir von EF Core ab rätst, dann nehme ich lieber etwas anderes.
Noch ist das ja nicht "mit Schmerzen verbunden".
Hier im Forum habe ich schon öfter von Dapper gelesen. Wäre das in diesem Fall das Mittel der Wahl?

Gruß, pinki

T
2.219 Beiträge seit 2008
vor 6 Jahren

@pinki
Auch wenn ich EF Core sehr mag, scheint Dapper der bessere Ansatz zu sein.
Die Performance kommt dabei schon sehr nah an direktes ADO.NET
Du musst wohl nur die SQL Anweisungen selbst schreiben, was aber die Performance bringt.
EF Core und co. lösen dies per Reflection was aber um längen langsamer ist.

Wenn ich ein neues Projekt starte, werde ich mal Dapper probieren.
Scheint auf jeden Fall einen Blick Wert zu sein.
Die Benchmarks auf der GitHub Seite sind schon nicht von schlechten Eltern.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.806 Beiträge seit 2008
vor 6 Jahren

Ich hoffe ja, dass mit EF Core 2.1 vieles besser wird (und es sieht gar nicht so schlecht aus); aber aktuell würde ich deutlich zu Dapper tendieren, ja.

pinki Themenstarter:in
709 Beiträge seit 2008
vor 6 Jahren

Danke für eure Antworten.
Dann werde ich Dapper mal eine Chance geben.

Nochmal kurz zurück zu meiner Projektstruktur: Was kann ich denn da verbessern?

pinki Themenstarter:in
709 Beiträge seit 2008
vor 6 Jahren

So, mittlerweile bin ich etwas weiter.
Mit EF Core habe ich die Migration erzeugen können.

Um mir die Fehler anzeigen zu lassen musste ich das Paket Microsoft.EntityFrameworkCore.Tools.DotNet hinzufügen und konnte dann über die Kommandozeile mit gesetztem verbose-Flag eine genauere Fehlermeldung bekommen.

Die Migration ist allerdings bei weitem nicht das, was ich selbst als Datenbank erstellt hätte, weshalb ich auch schon aus diesem Grund Dapper benutzen werde, weil ich das dann selbst in der Hand habe.

16.806 Beiträge seit 2008
vor 6 Jahren

...da bietet sich dann der FluentMigrator an.
Das ist aktuell aber nicht 100% .NET Core Ready, weshalb ich temporären Fork verwende.
https://www.nuget.org/packages/Serenity.FluentMigrator
https://www.nuget.org/packages/Serenity.FluentMigrator.Runner

pinki Themenstarter:in
709 Beiträge seit 2008
vor 6 Jahren

Danke für den Tipp.
Dann sehe ich mir das direkt mit an. =)

Laut NuGet-Seite läuft das mit .NET Standard 1.6, was bereits durch .NET Core 1.0 abgedeckt wäre.
Oder ist die Info falsch?

Edit: Man sollte den verlinkten Issue auch zu Ende lesen... 😁

16.806 Beiträge seit 2008
vor 6 Jahren

Wie schon beim Gedanken bei Frameworks ist auch bei .NET Standard das Ziel, dass möglichst immer der kleinste gemeinsame Nenner verwendet wird, um eine möglichst hohe Kompatibilität in der Breite zu erreichen.