Dies ist eine (eigentlich mehrere) Folgefragen zu meiner vorherigen Frage zu F # -Typ Provider und kontinuierliche Integration .
Mir scheint, dass es eine gute Idee wäre, den Provider " SqlDataConnection " als Kompilierzeitprüfung zu verwenden, um sicherzustellen, dass die Code / Datenbank-Integrität in der Feature-Branch-driven-Entwicklung intakt bleibt. Sie würden bei jedem Commit / Build wissen, dass an dem Code, der noch nicht auf die Datenbank angewendet wurde, keine Änderungen vorgenommen wurden, vorausgesetzt, dass das Erstellen der Datenbank ebenfalls Teil Ihres CI-Prozesses ist.
Allerdings ergeben sich einige Fragen:
Der Name (sowie der Ort) der Konfigurationsdatei ist zur Kompilierzeit nicht derselbe wie zur Laufzeit, z. app.config - & gt; MyApp.exe.config, was zu einem Laufzeitfehler führen wird, wenn Sie versuchen,
zu verwenden %Vor% (Tatsächlich ist die Angabe von ConfigFile="app.config" nicht notwendig, da dies der Standardwert ist.)
Der Laufzeitfehler kann vermieden werden, indem die Datei app.config in das Ausgabeverzeichnis kopiert wird (dafür gibt es eine Einstellung), aber das würde dazu führen, dass sowohl eine app.config- als auch eine MyApp.exe.config-Datei in der Ausgabe enthalten wäre Verzeichnis. Nicht sehr hübsch. Es wäre eine andere Lösung, eine separate Konfigurationsdatei für Typ-Provider hinzuzufügen, aber das ist auch nicht sehr hübsch.
Frage: Hat jemand eine elegantere Lösung für dieses Problem gefunden?
Das nächste Problem tritt auf, wenn Sie zum Build-Server kommen. Es ist sehr wahrscheinlich, dass Sie nicht während der Entwicklung gegen die gleiche Datenbank kompilieren möchten, was eine andere Verbindungszeichenfolge erfordert. Und ja, in der Produktion braucht man noch einen.
Frage: Wie gehen Sie vor, dies auf die bequemste Art und Weise zu lösen? Denken Sie daran, dass die Lösung ein Arbeitsteil eines CI-Prozesses sein muss!
Diese Strategie würde erfordern, dass die Datenbank bei jedem Build auf dem Build-Server generiert wird, wahrscheinlich aus einem Basisskript mit einigen Feature / Sprint-Update-Skripten.
Frage: Hat jemand das versucht und wie hat es die Bauzeiten beeinflusst? Wenn ja, wie haben Sie diesen Schritt erstellt?
Zur Laufzeit können Sie die GetDataContext -Überladung verwenden, die eine Verbindungszeichenfolge akzeptiert. Siehe hier: Verbindungszeichenfolge zu Linq-To bereitstellen -Sql Datenanbieter
Ich bin mit der Lösung vertraut, die @ Gustavo vorschlägt, aber ich habe immer gespürt, dass da etwas faul ist. Etwas, dass ich die Verbindungszeichenfolge zweimal angeben muss ... Als ich jedoch wieder die gleiche Antwort bekam, wurde mir langsam klar, dass die Antwort richtig sein muss und dass ich es bin, die falsch denkt. Dies sind meine Schlussfolgerungen: Die Antwort besagt, dass Sie die GetDataContext-Überladung verwenden können, die eine Verbindungszeichenfolge akzeptiert. Wenn Sie dies zu sollten ändern, werden die Dinge zumindest für mich klarer.
Die Sache ist, dass ich an die Klassendefinition sowohl als eine Kompilierungszeitrichtlinie als auch als eine Laufzeitvariable gedacht habe, aber obwohl dies möglich ist, ist es kaum eine gute Idee. Der Standardwert des ConfigFile-Arguments ist, wie wir bereits gesehen haben "app.config", aber diese Datei existiert nicht (mit diesem Namen) zur Laufzeit, so dass es keinen Sinn macht, es zu versuchen, Somit bleibt GetDataContext die einzig sinnvolle Option. Ich schlage vor, dass Sie das tun:
Behalten Sie Ihre Kompilierungseinstellungen in einer Datei mit dem Namen compilation.config (oder was immer Sie bevorzugen) und geben Sie diese Datei zur Verwendung in der Klassendefinition an.
Verwenden Sie die GetDataContext-Überladung, die eine Verbindungszeichenfolge für die Laufzeitauflösung akzeptiert, und geben Sie diese Verbindungszeichenfolge in der app.config-Datei an.
Sie werden mit etwas enden, das wie folgt aussieht:
%Vor%Heck, das unterstützt sogar die SRP; Kompilierzeiteinstellungen in einer Datei und Laufzeiteinstellungen in einer anderen!
Was den Rest meiner Fragen anbelangt, gehe ich davon aus, dass die Antwort in einigen Skripten in der Continuous Deployment-Pipeline liegt. Immer noch an anderen Lösungen interessiert.
Tags und Links f# continuous-integration type-providers app-config