Laden...

Initiales Deployment einer CodeFirst Datenbank

Erstellt von Telefisch vor 5 Jahren Letzter Beitrag vor 5 Jahren 3.376 Views
T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren
Initiales Deployment einer CodeFirst Datenbank

Hallo Forum,
mit meiner App möchte ich jetzt erste Veröffentlichungsversuche machen.
Dazu gehört unter Anderem ja auch das Veröffentlichen der Datenbank.

Dazu habe ich zwei Fragen:

  1. Wird im SQL Server ein eigener User angelegt damit sich die App dort verbinden kann? Den sa zu nehmen ist wohl nicht so ganz klug.
    Falls ja, welche rechte muss der User, sprich die App bekommen?
    Ich weiß, dass es sich dabei nicht um den Benutzer der App handelt.

  2. ich wollte die Datenbank per CodeFirst Script erstellen, stoße aber auf das Problem, dass zwar meine benötigten Tabellen im Script angelegt werden, die Tabelle MigrationHistory, sowie alle AspNet-Tabellen aber nicht und somit schon diese Anweisung fehlschlägt:

INSERT [dbo].[__MigrationHistory]([MigrationId], [ContextKey], [Model], [ProductVersion])

Hab ich da die falsche Reihenfolge?
Ich habe im SQL-Manager eine Datenbank angelegt und dann ganz optimistisch mittels einer neuen Abfrage die ersten SQL-Befehle ausgeführt. Das sollte doch stimmen oder?
Vielleicht kennt ja jemand ein gutes Tutorial zum Deployment auf MS-Server mit SQL Server.

Danke und Gruß
Carsten

T
2.219 Beiträge seit 2008
vor 5 Jahren

1.Darum musst du dich kümmern. Die Zugangsdaten für die DB musst du auch im Connection String mitliefern. Welche Rechte du brauchst, hängt davon ab was der DB User machen sollen/darf. Hier musst du dich informieren und einlesen, dass nimmt dir kein OR Mapper o.ä. ab.

2.Bei Code First Ansatz brauchst du doch keine extra Skripte? Hier kannst du mit den Migration die Entität direkt als Tabelle mappen lassen. Dazu nutzt EF Core Migrations.

3.Wenn deine App bei X Benutzer verwendet wird, also kein Task sondern z.B. eine mobile App ist, dann solltest du vor deine DB einen Webservice schalten. Über WebAPI sollte keine App dann mit dem Service und dieser wiederum mit der DB kommunizieren. Sonst legst du deine DB nach außen offen, was eine Katastrophe wäre.

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 5 Jahren

ASP.NET Tabellen (sofern Du von Identity sprichst, Du erläuterst es ja nicht) haben nichts mit EF Core zutun. Das sind zwei verschiedene paar Stiefel.

Und von welchem Script Du redest; keine Ahnung.

T
2.219 Beiträge seit 2008
vor 5 Jahren

@Abt
Falls du micht meinst, der Teil mit EF bezog sich lediglich auf die Migrations in EF Core.
Ob er für Code First EF nutzt oder andere Lösungen, ist dabei erst einmal unwichtig.

Bei dem Skript beziehe ich mich auf sein Coe First Script, was auch immer dies seiin soll.
Hier wäre die Migration der richtige Ansatz, wenn es den eine saubere Code First Umsetzung ist.

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.

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

Also, wenn ich zum Beispiel die Migrations Tabelle sehen oder die Identitäten-Tabellen muss ich die doch irgendwie auf den SQL-Server bekommen.

Um eine App zu veröffentlichen kann ich mittels Azure sicherlich alles automatisch machen, auch das Entsorgen meines Geldes im Microsoft Schlund.
Habe ich aber einen eigenen Server, weiß ich bisher nur, dass ich die Website als Datei-Sammlung erstelle und dann die Datenbank mittels Script erstelle.
Das Script erstellt "update-database -script -Migrationname" dafür automatisch.
Es scheint sich dabei allerdings nur um die Tabellen zu handeln, die ich selbst angelegt habe, nicht die, die mit der ASP.NET MVC App angelegt werden 😦

...oder bin ich auf dem völlig falschen Pfad?

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

Ach und T-Virus,
ich habe jetzt dieses Identity-Gedöns mit durchgängiger Rechtevergabe implementiert, was Visual Studio beim Erstellen des Projektes ja schon mit einbaut.
Was muss denn jetzt noch davor gebastelt werden?

16.806 Beiträge seit 2008
vor 5 Jahren

Die Identity Tabellen (wieso nutzt Du überhaupt noch bei einem neuen Projekt die ASP.NET Identity und nicht zB. den IdentityServer?) werden automatisch von der Idenity Middleware angelegt, nicht durch Deine Migrations.

Das sind wie gesagt zwei paar Stiefel.
Deine Migrations kennt Deine ASP.NET Tabellen nicht - nicht mal, dass sie benötigt werden.

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

Tja, wieso nutze ich die überhaupt noch?
Andere Frage, woher soll ich wissen, dass man die nicht mehr nutzt?
Und vor allem, was ist falsch daran?

Aber egal, wie bekomme ich die denn jetzt angelegt? Von Hand?
Da gehören ja sicher auch ein paar Einträge zu.

5.657 Beiträge seit 2006
vor 5 Jahren

schon diese Anweisung fehlschlägt:

INSERT [dbo].[__MigrationHistory]([MigrationId], [ContextKey], [Model], [ProductVersion])  

Gibt es eine Fehlermeldung?

Hab ich da die falsche Reihenfolge?

Welche Reihenfolge meinst du?

Ich habe im SQL-Manager eine Datenbank angelegt und dann ganz optimistisch mittels einer neuen Abfrage die ersten SQL-Befehle ausgeführt. Das sollte doch stimmen oder?

Was sollte daran stimmen? Hat der Benutzer, den der EF in seinem ConnectionString verwendet, die erforderlichen Rechte oder nicht?

Aber egal, wie bekomme ich die denn jetzt angelegt? Von Hand?

Das hat doch Abt bereits erklärt.

Weeks of programming can save you hours of planning

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

schon diese Anweisung fehlschlägt:

INSERT [dbo].[__MigrationHistory]([MigrationId], [ContextKey], [Model], [ProductVersion])  

Gibt es eine Fehlermeldung?

Ich weiß die Meldung nicht mehr auswendig aber es gibt genau diese Tabelle [dbo].[__MigrationHistory] nicht.
Nochmal: das Skript zum Erzeugen der Tabellen wird vom VS erzeugt und enthält nicht die Tabellen, die es offensichtlich benötigt.
Der propagierte Workflow ist u.a., dass man alle notwendigen Dateien in ein Verzeichnis "erzeugen" lässt und für die Code-First Datenbank ein Skript generiert, mittels "update-database -script…"
Meine tollkühne Annahme war, dass dieses Wunderwerk Migrations dann bei einer neuen Datenbank allein auf die Idee kommt die Tabellen anzulegen, in die es rein schreiben will.

Hab ich da die falsche Reihenfolge?

Welche Reihenfolge meinst du?

na die Reihenfolge in der man die Veröffentlichung vornimmt.

Ich habe im SQL-Manager eine Datenbank angelegt und dann ganz optimistisch mittels einer neuen Abfrage die ersten SQL-Befehle ausgeführt. Das sollte doch stimmen oder?

Was sollte daran stimmen? Hat der Benutzer, den der EF in seinem ConnectionString verwendet, die erforderlichen Rechte oder nicht?

es geht doch noch gar nicht um Rechte. Auf was soll ich Rechte vergeben? Erst muss mal ne Datenbank da sein. Dann kommt die Website und die bekommt dann einen User im Connectionstring. Und ja, der braucht dann Rechte.
Aber so weit bin ich noch nicht. Ich habe lediglich gefragt, ob es der Richtige Weg ist die Datenbank mittels der SQL-Abfragen zu erstellen.

Aber egal, wie bekomme ich die denn jetzt angelegt? Von Hand?

Das hat doch Abt bereits erklärt.

Ach ja? hab ich was überlesen?
Ich hab nur gelesen dass Migrations offensichtlich nichts damit zu tun hat.
Gibt es denn jetzt einen anderen Weg oder mache ich alles zu Fuß?

5.657 Beiträge seit 2006
vor 5 Jahren

Ich weiß die Meldung nicht mehr auswendig aber es gibt genau diese Tabelle [dbo].[__MigrationHistory] nicht.

Bitte tue dir den Gefallen, und gib uns die Infos, die es braucht, um dir helfen zu können.
[Hinweis] Wie poste ich richtig?, hier insbesondere Punkt 5.

Meine tollkühne Annahme war, dass dieses Wunderwerk

Wenn du schon selbst merkst, daß solche Annahmen tollkühn sind, und sie dann auch offensichtlich nicht eintreffen, dann solltest du halt mal nachlesen. Du bist tatsächlich nicht der erste, der eine Code-First-Migration machen möchte.

Die Vorgehensweise ist:

  • Datenbank erstellen
  • ConnectionString einrichten und testen
  • Migrations aktivieren
  • Initiale Migration erstellen
  • Update-Database

Fertig.

Wenn es dabei Probleme gibt, dann sag uns, was genau du gemacht hast, welche Fehlermeldungen passieren, und was nicht funktioniert wie erwartet.

Wenn du Probleme mit dem Identity(Server) hast, dann erstelle halt erst einmal ein neues Projekt ohne.

Weeks of programming can save you hours of planning

16.806 Beiträge seit 2008
vor 5 Jahren

Ach ja? hab ich was überlesen?
Ich hab nur gelesen dass Migrations offensichtlich nichts damit zu tun hat.

Dann les bitte langsamer.

ASP.NET Identity (...) werden automatisch von der Idenity Middleware angelegt, nicht durch Deine Migrations.

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

Ok...
also entweder habe ich mich undeutlich ausgedrückt oder ich bin einfach zu blöd.

Ich habe eine WebApp mittels Visual Studio, basierend auf ASP.NET MVC erstellt.
Dabei habe ich vom VS die Identites mit erstellen lassen.
Jetzt mal angenommen ich habe einen Windows Server und einen SQL-Server und möchte meine Seite dort hochladen... wie mache ich das?

Bisher habe ich einen Workflow gefunden bei dem ich die Site als File-Sortiment in ein lokales Verzeichnis erstellen lasse und dann diese auf den Server hochlade.
Um die SQL-Datenbank zu erstellen hat Migrations mir dafür ein SQL-Script generiert.
Jetzt nochmal die Frage, wann wird wo das Tabellensortiment erstellt, was Migrations offensichtlich nicht kennt (ASP-Identity-Tabellen und die _Migrationshistory-Tabelle).

Hab die Seite auf einen Azure MAPS-Account hochgeladen und soweit zumindest schonmal behaupten, dass sie fehlerfrei läuft.
Jetzt ist halt nur noch die Frage nach dem "normalen" Server.

Kann mir bitte jemand mit nem Link zu nem Tutorial helfen?

Das kann doch nciht so ein seltener vorgang sein.

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

Hab es selbst gelöst bekommen.
Statt die erste Migration anzugeben musste 0 angegeben werden damit die "System" Tabellen mit generiert werden.

PM> Update-Database -Script -SourceMigration:0

Das erzeugt ein SQL Script, dass alle benötigten Tabellen, inklusive der Identity-Tabellen und der Migrations-Tabelle aufbaut.

Dann bleibt jetzt nochmal die Frage nach Identity.
Hier wurde in den Raum geworfen, dass das wohl nicht mehr gemacht würde.
Warum ist das so?
Ist das zu unsicher?

16.806 Beiträge seit 2008
vor 5 Jahren

Weil die ganze Identity Sache (ProfileManager, MemberShip-Manager) einfach auf die wenigsten Anwendungen passt - und vergleichsweise komplex ist.
Dazu kommt, dass man eine sehr starke Bindung mit wenig Anpassungsmöglichkeiten hat.

Daher benutzt das so gut wie niemand, und auch Microsoft gibt dem ganzen nicht mehr so viel Liebe - will halt einfach auch so gut wie keiner.
Ne eigene Implementierung ist i.d.R. schneller und einfacher umgesetzt (eigene Tabelle und Services).

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

Also bei mir funktioniert das recht flüssig.
Ich habe die Registrierung neuer User den Administratorkonten vorenthalten.
Diese können dann über ein Dropdown die verfügbare Usergruppe auswählen.
Für meine Anwendung ist das in Ordnung.

Ne eigene Implementierung wäre dann mit dem erwähnten IdentityServer?
Gibt's da Lesestoff oder einen "best way" um gleich in die richtige Richtung zu laufen?

W
955 Beiträge seit 2010
vor 5 Jahren

Gibt's da Lesestoff oder einen "best way" um gleich in die richtige Richtung zu laufen? Warum gehst du nicht auf die Homepage des Produktes und schaust dir die dortigen Dokumente an?

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

Die hier?

http://identityserver.io/

...ok, dann schaue ich da mal...

W
955 Beiträge seit 2010
vor 5 Jahren
16.806 Beiträge seit 2008
vor 5 Jahren

Nein, der IdentityServer ist was anderes, der ist für AuthZ und AuthN.
Er übernimmt aber nicht die Profilinformationen etc.

Ich empfehle Dir jedenfalls die ASP.NET Identity Provider nicht.
Du kannst sie natürlich trotzdem nehmen, wenn Dir das ausreicht..

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

Ich muss das Thema nochmal rauskramen.
Nachdem ich ja meine initiale Datenbank veröffenlicht habe, soll nun ein Update in der Produktivdatenbank erfolgen.
Optimistisch wie ich bin habe ich in der Paket-Manager-Konsole folgendes eingegeben:

update-database -script -SourceMigration:<Erste neue Migration>

Da ich dieses Update auf die lokale Datenbank natürlich schon angewendet habe bekomme ich die Meldung:

Keine ausstehenden expliziten Migrationen.

Womit sage ich dem update denn dass es sich um eine Migration für eine andere db handelt, damit es mir den SQL-Code generiert?

1.029 Beiträge seit 2010
vor 5 Jahren

Hi,

ohne mich mit CodeFirst auszukennen:

Rein logisch betrachtet - würde ich den Parameter "SourceMigration" anders verstehen wie du es offensichtlich tust - denn Source ist der Ausgangspunkt (also die "Versionsnummer" der aktuellen Produktivdatenbank). Du behandelst den Parameter als würde er "TargetMigration" heissen...

In anderen Worten: Gib mal ne niedrige Versionsnummer als Parameter mit.

LG

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

Ich weiß, was Du schreibst klingt logisch, sourceMigration sollte aber dennoch korrekt sein.
targetMigration sollte für Downgrades sein.
Ein Test mit Target, zeigt aber auch genauso wenig Erfolg.

update-database -script -TargetMigration:ListPositionAddedToProperties

Die Zieldatenbank weist bereits die Version 201812040833504_ListPositionAddedToProperties auf.

VS orientiert sich halt immer an der vorhandenen Datenbank sprich am entsprechenden Eintrag in der MigrationsHistory

1.029 Beiträge seit 2010
vor 5 Jahren

Hi,

nein - du hast mich falsch verstanden -SourceMigration ist richtig. Der Parameter den du an SourceMigration gibst ist falsch.

Basiert auf folgendem Thread:
https://stackoverflow.com/questions/13939404/generate-full-sql-script-from-ef-5-code-first-migrations
führt der Parameter "0" (also noch keine Migration ausgeführt) dazu, dass alles generiert wird. Als Parameter für SourceMigration müsstest du demnach die aktuelle Version der Produktiv-Datenbank angeben um das richtige Script zu erzeugen...

LG

Nachtrag: Falls du dann überhaupt eine TargetMigration angibst (Standard ist sicher die höchste Version) - wäre das in deinem Fall um Änderungen auszuschließen, die der Kunde noch nicht haben darf, weil z.B. unfertig...

T
Telefisch Themenstarter:in
372 Beiträge seit 2008
vor 5 Jahren

Ah jau verstanden...
Ich gebe die letzte, in der Produktiv-db veröffentlichte Migration an.

...wiederspricht zwar einem Tutorial, was ich dazu gefunden habe aber es klappt.
Das SQL-Script sieht zumindest gut aus.

Danke für den Tipp!