Ich muss für jedes Fenster separate Windows-Dienstkonten erstellen Umgebung (Entwicklung, Akzeptanz und Produktion), dass mein Desktop Anwendung verwendet, um eine Verbindung zu einer unserer internen Datenbanken herzustellen.
Diesen Konten wurde eine globale Gruppe hinzugefügt, um den Zugriff zu ermöglichen Dies erfordert den Zugriff durch die Windows-Authentifizierung mit Identitätswechsel.
Die Daten der Verbindungszeichenfolge werden verschlüsselt und gespeichert in einem Netzwerk, auf das die Klassenbibliothek zur Sicherheit zugreift.
Wenn ich nicht imitieren, und den Basiskonstruktor für die Basisklasse DbContext verwenden, die eine Verbindungszeichenfolge akzeptiert, funktioniert das, weil mein persönliches Konto derselben globalen Gruppe zugewiesen ist. Aber wenn ich die Instanziierung des Objekts DbContext in die Identität verkapsele, schlägt es mit einer internen Ausnahme fehl, die katastrophaler Fehler angibt, während die äußere Ausnahme angibt
Der Anbieter hat keine
ProviderManifest-Instanz zurückgegeben.
Zum Beispiel:
%Vor% Dann habe ich versucht, die Verbindungsinformationen hart zu codieren, indem ich mein eigenes DbConfiguration -Objekt erstelle, aber das führt zu einem Fehler , wo es offenbar mehr versucht, als eine lesbare Verbindung herzustellen. Es wird versucht, stattdessen die Datenbank zu erstellen, für die ich keine Rechte habe.
Beispiel:
%Vor% Dies ist Code-First und ich kann nur sehr einfache Aussagen und Super-High-Level-Beispiele mit DbConfiguration finden. Und in Bezug auf eine Laufzeitdefinition von Verbindungs- / Anbieterinformationen scheint Information immer auf einen modellbasierten Ansatz ausgerichtet zu sein oder den Anbieter vollständig zu vernachlässigen.
Wie programmiere ich programmatisch den EF-Code-First-Ansatz für den Zugriff auf eine Datenbank, wenn ich mich für das Windows-Dienstkonto einer Anwendung ausspreche und diese Fehler nicht erhalte?
Also, ich denke, ich habe es endlich geschafft. Es war ein ziemliches Abenteuer durch und um viele Kaninchenlöcher, die eine Menge MSDN-Artikel und viele einzelne Blogs lesen. Und während ich daran gearbeitet habe, habe ich auch Probleme bei der Gestaltung unserer DB-Zugriffsrollen entdeckt. Dieser Teil zeigt nur, dass es genauso wichtig ist, sicherzustellen, dass Ihre Rollen korrekt eingerichtet sind. Nehmen Sie nicht nur ihr Wort dafür. Wir haben sie jetzt behoben, aber wahrscheinlich haben wir mehr Kontrollen, um sie einzurichten und sicherzustellen, dass sie auf die am besten geeignete Weise verwaltet werden. Ich wollte mein Beispiel geben, um jemand anderem in der gleichen Situation zu helfen, und den Veteranen etwas anbieten, wenn sie Verbesserungsmöglichkeiten sehen. Das folgende Beispiel ist immer noch etwas naiv, da ich wahrscheinlich mehr um SecureString machen könnte, aber ich denke, das ist nicht der Kern des Problems. Also, hier geht ...
Verbraucher:
%Vor%Kontext:
Offensichtlich speichert eine reale Implementierung die Verbindungszeichenfolge nicht in einem statischen Feld.
%Vor%Imitator & amp; unterstützende Klassen / enums:
%Vor%Tags und Links .net sql-server c# entity-framework dbcontext