Im Rahmen unserer kontinuierlichen Integrationsbemühungen haben wir eine benutzerdefinierte Bereitstellungsanwendung für die Migration von Entity Framework 6.0 Code First-Datenbanken erstellt. Wir nehmen unsere Ziel-DLLs und vergleichen diese mit den aktuell bereitgestellten DLLs, um den Migrationspfad zu bestimmen, unabhängig davon, ob der Pfad nach oben oder nach unten verläuft. Um sicherzustellen, dass wir die richtige Version der DLL des Datenkontexts laden, hören wir auf die AppDomain.CurrentDomain.AssemblyResolve (siehe: Abhängige Baugruppen manuell laden ).
%Vor%Dies funktioniert problemlos, wenn Sie einen einfachen Datenkontext (eine einzelne Tabelle mit einer einzelnen Zeile) auf einem Server mit SQL Server 2012 (Windows Server 2012) bereitstellen. Der folgende Fehler tritt jedoch auf, wenn Sie denselben einfachen Datenkontext bereitstellen Server mit SQL Server 2008 R2 (unter Windows Server 2008 Standard):
%Vor% Einige Logging-Ausgaben haben ergeben, dass BuildAssemblyId die NullReferenceException wirft, weil die args.RequestingAssembly , die übergeben wird, null ist. Der Wert in args.Name ist der Name der DLL, die unseren Datenkontext enthält. Dies wird zwischen der Erstellung des Kontexts und der Datenaussaat beim Erstellen der Tabelle ausgelöst, aber leer.
Die Anwendung wurde zunächst auf jeder Maschine unabhängig ausgeführt. Wir haben die .NET Framework-Diskrepanz ausgeschlossen, indem wir jede Maschine auf .NET 4.5.1 aktualisieren. Außerdem haben wir die Deployment-Anwendung auf demselben Computer ausgeführt. Wir haben den Computer verwendet, auf dem SQL Server 2012 installiert war. Schließlich verweisen sowohl die Bereitstellungsanwendung als auch der einfache Datenkontext auf dieselbe Version von EntityFramework.
BEARBEITEN
Es wurde vorgeschlagen, dass das Attribut des Tabellenobjekts die Wurzel des Problems sein könnte.
%Vor% Wir haben TableAttribute entfernt, und während der Fehler in SQL Server 2008 R2 immer noch fehlgeschlagen ist, wurde der Fehler in SQL Server 2012 reproduzierbar.
Der angewendete Klebeverband dient zur Aufhebung der Registrierung unseres ResolveDependentAssembly -Ereignisses nach der Ermittlung der Ziel- und bereitgestellten DLLs und vor der Initialisierung der Datenbank. Dies wird in unserer aktuellen Situation gut funktionieren, da wir immer nur einen Datenkontext in einer Umgebung bereitstellen.
Unser langfristiger Fix besteht darin, separate App-Domains für das Ziel und jede Bereitstellung zu erstellen.
Tags und Links c# sql-server-2008-r2 entity-framework-6 sql-server-2012