10

Der Versuch, Migrationen zu einem EF7-Modell hinzuzufügen, das in einer ASP.NET 5-Klassenbibliothek lebt. Wenn dnx . ef migration add mymigration ausgeführt wird, schlägt das mit unterschiedlichen Ergebnissen fehl, je nachdem, auf welchem ​​Projekt ich es ausführe.Entity Framework 7 Migrationsgerüst in der Klassenbibliothek mit Konfiguration

Wenn ich es im Ordner des Hauptprojekts ausführen, kann es DbContext nicht finden, dies macht Sinn, weil die DbContext im freigegebenen Projekt ist und ef-Befehle wahrscheinlich kümmern sich nicht um Abhängigkeiten.

Wenn ich es im Ordner des freigegebenen Projekts ausgeführt habe, hat es keinen Zugriff auf die in startup.cs angegebene Verbindungszeichenfolge. Ich habe aus Fragen wie this gelernt, dass es aus dem freigegebenen Projekt funktioniert, wenn Sie die Verbindungszeichenfolge in der OnConfiguring Methode der DbContext angeben, aber ich möchte diesen Code wirklich von der Konfiguration getrennt halten.

Ich bin im EF7-Repository auf einige issue logs gestoßen, die erwähnen, dass sie Befehlszeilenoptionen für die Angabe eines Projekts und eines Kontexts implementiert haben, aber es gibt keine Beispiele und ich konnte nicht herausfinden, wie man den Quellcode in verwendet die Commit-Historie.

+0

Wo speichern Sie Ihre Verbindungszeichenfolge? Ist es in Startup.cs fest codiert? –

+0

Es ist in config.json und geladen mit Konfiguration in AddDbContext CuddleBunny

Antwort

9

Hier ist ein Ansatz, der für Sie arbeiten könnte.

Wenn ich es in den Ordner des gemeinsamen Projekt ausführen, es hat keinen Zugriff auf die Verbindungszeichenfolge in den startup.cs angegeben.

Startup.cs

ich, dass in Ihrem Startup.cs vorausgesetzt, du spezifizieren Sie die Verbindungszeichenfolge von Configuration anstatt durch schwer es Codierung erreichbar. Außerdem nehme ich an, dass Sie im Konstruktor Ihrer Startup.cs-Datei die Konfiguration aus ein paar Quellen einrichten. Mit anderen Worten, Ihr Startup.cs könnte wie folgt aussehen:

public class Startup 
{ 
    public IConfiguration Config { get; set; } 

    public Startup(IHostingEnvironment env) 
    { 
     var config = new Configuration() 
      .AddJsonFile("config.json") 
      .AddUserSecrets() 
      .AddEnvironmentVariables(); 

     Config = config; 
    } 

    public void ConfigureServices(IServiceCollection services) 
    { 
     services.AddEntityFramework() 
      .AddSqlServer() 
      .AddDbContext<MyDbContext>(options => 
      { 
       options.UseSqlServer(Config["ConnectionStrings:MyDbContext"]); 
      }); 
    } 

    public void Configure(IApplicationBuilder app, IServiceProvider serviceProvider) 
    { 
     var db = serviceProvider.GetRequiredService<MyDbContext>(); 
     db.Database.AsSqlServer().EnsureCreated(); 

     app.Run(async (context) => 
     { 
      await context.Response.WriteAsync("Hello World!"); 
     }); 
    } 
} 

config.json

Außerdem gehe ich davon aus, dass Sie die Verbindungszeichenfolge an einen config.json in der Wurzel sind das Hinzufügen Ihres Projekts (oder dass Sie es über die Benutzergeheimnisse oder Umgebungsvariablen hinzufügen.) Ihr config.json etwas könnte wie folgt aussehen:

{ 
    "ConnectionStrings": { 
    "MyDbContext": "Some-Connection-String" 
    } 
} 

Wenn Sie nicht, dass es so zu tun, könnte es sich lohnen, versuchen .

Ich habe von Fragen wie diese zu entnehmen, dass es Arbeit aus dem gemeinsamen Projekt funktioniert, wenn Sie die Verbindungszeichenfolge in der OnConfiguring Methode des DbContext angeben, aber ich mag wirklich diesen Code halten, unabhängig von der Konfiguration.

DbContext

Wenn über meine Annahmen richtig sind, dann können Sie die Verbindungszeichenfolge in der DbContext zugreifen, indem das gleiche Muster, die Sie in der Startup-Klasse verwendet. Das heißt, im DbContext Konstruktor, richten Sie die IConfiguration. Rufen Sie dann in OnConfiguring die Verbindungszeichenfolge auf.Es könnte wie folgt aussehen:

public class MyDbContext : DbContext 
{ 
    protected override void OnModelCreating(ModelBuilder builder) 
    { 
     builder.Entity<SomeModel>().Key(e => e.Id); 
     base.OnModelCreating(builder); 
    } 

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) 
    { 
     var connString = Config["ConnectionStrings:MyDbContext"]; 
     optionsBuilder.UseSqlServer(connString); 
    } 

    public IConfiguration Config { get; set; } 

    public MyDbContext() 
    { 
     var config = new Configuration() 
      .AddJsonFile("config.json") 
      .AddEnvironmentVariables(); 

     Config = config; 
    } 
} 

Projektstruktur

Sie werden natürlich brauchen eine config.json-Datei im Stammverzeichnis der gemeinsamen Projekte zu Ordnern haben. So könnte Ihre Projekte Struktur wie folgt aussehen:

SharedDataContext 
    Migrations 
    config.json 
    project.json 

WebApp 
    config.json 
    project.json 
    Startup.cs 

Im obigen beide config.json Dateien enthalten eine Verbindungszeichenfolge für die DbContext Einstellung.

Einige Gedanken

Wenn Sie die config.json Verbindungszeichenfolge Sachen nicht mag duplizieren, dann können Sie stattdessen Umgebungsvariablen oder Benutzer Geheimnisse verwenden.

+0

Dies ist eine viel akzeptablere Problemumgehung als Verschieben des gesamten Namespace in das Hauptprojekt. Migration add funktionierte perfekt, traf einen Schlag mit apply: Da ich ein benutzerdefiniertes 'DataDirectory' verwendet hatte, musste ich einige Kontexterkennung durchführen. Wenn es von der Befehlszeile 'Path.GetFullPath (" .. \\ MainProject ") ausgeführt wird, gibt' mir "C: \ Pfad \ To \ My \ Project \ src \ MainProject", aber wenn ich das eigentliche Projekt ausführe, bekomme ich "C: \ Programme (x86) \ MainProject "stattdessen! Also habe ich einen Check hinzugefügt, um zu sehen, ob der Pfad den Text "src" enthält und jetzt funktioniert. Dies sollte auch zur Produktion portiert werden, da die Umgebungsvariablen alles überschreiben. – CuddleBunny

+0

Ich akzeptiere dies als die Antwort, bis etwas weniger Hacky kommt. – CuddleBunny

+0

@CuddleBunny Ich bin froh, dass es geklappt hat und freue mich darauf, etwas weniger hacky zu sehen. Vielleicht wird jemand vom EF-Team eine Antwort geben. –

Verwandte Themen