LightSwitch: Zugriff auf Produktivdaten in Entwicklungsumgebung

Ein kleines HowTo zum Handling gemischter Datenquellen beim Debuggen und Veröffentlichen von Lightswitch-Anwendungen.

Die Problemstellung:

Sie haben vor einiger Zeit eine lokale Lightswitch-Anwendung entwickelt. Mit dem eingebauten Datenbank-Designer hatten Sie damals die Tabellen und Relationen erzeugt (IntrinsicData), zusätzlich wurde eine weitere externe Datenbank eingebunden. Die Lightswitch-Anwendung wurde seit der Auslieferung im Produktiveinsatz rege verwendet, bei der Erstinstallation wurde  damals die neue (leere) Datenbank auf dem Produktivsystem der lokalen Lightswitch-Anwendung erzeugt.

Jetzt soll ein Upgrade programmiert oder ein Fehler behoben werden. Sie haben den Ursprungs-Quellcode für die Lightswitch-Anwendung vorliegen, arbeiten aber auf einem entkoppelten Entwicklungssystem. Der Entwicklungsumgebung ist aktuell weder die externe Datenbank bekannt, noch ist eine Zugriff aus Visual Studio auf das Produktivsystem möglich. 

Im ersten Teil dieses How-To fassen wir zusammen, wie Sie in der Entwicklungsumgebung eine Kopie der Produktivdatenbank einspielen. Teil zwei des How-To zeigt auf, wie Sie nach erfolgreichem Update die Lightswitch-Anwendung wieder ins Produktivsystem deployen können und dabei die IntrinsicData-Datenbank per SQL-Skript updaten.


Teil 1 – Das Kopieren in die Entwicklungsumgebung 

Zunächst kopieren Sie beide Datenbanken vom Produktivsystem in die Entwicklungsumgebung. In unserem Beispiel war die von Lightswitch erzeugte IntrinsicData-Datenbank eine Zeiterfassung und die externe Datenquelle waren SQL-Views auf einer FlowFact-Datenbank (Buchungskonten für  die Zeiten). Ein möglicher Weg ist:

  • Um die mdf-Files vom Produktivsystem zu erhalten, ist es am einfachsten, das SQL Server Management Studio zu verwenden. 
  • Lokalisieren Sie die mdf-Files (Datenbank auswählen -> Rechtsklick -> Eigenschaften -> im modalen Dialog auf den Reiter „Dateien“).
  • Schalten Sie die Datenbank kurz offline. 
  • Erstellen Sie eine Kopie der mdf-Files (inkl. log).
  • Nicht vergessen, nach dem Kopieren die Datenbank wieder online zu schalten.
  • Die mdf-Files transferieren Sie nun in die Entwicklungsumgebung.  

In Visual Studio können Sie die beiden Datenbanken nun in die localdb einspielen. Beth Massi hat dazu ein sehr empfehlenswertes How-to verfasst.

Falls Sie in der Entwicklungsumgebung nun den Lightswitch-Programmcode per F5 ausführen möchten, haben Sie zunächst zwei Probleme:

  • Die Anwendung versucht für die Verbindung zur externen Datenbank im Debug Modus auf das Produktivsystem zuzugreifen, was Sie weder können (da kein Tunnel vorhanden ist) noch wollen (Risikominimierung).
  • Die von Lightswitch erzeugte Datenbank (IntrinsicData) ist leer.

So können Sie diese Probleme umgehen: 

Um die Verbindung zur externen Datenbank aufzubauen, müssen Sie die ConnectionStrings in der web.config XML Datei verändern. Es gibt dazu einige Artikel und Diskussionen bei MSDN im Netz. Achtung: es gibt zwei Versionen der web.config, für den Debug Mode und unter ServerGenerated für die Auslieferung. Wichtig: Sichern Sie die Original ConnectionStrings aus Web.Config, diese benötigen Sie wieder, wenn Sie das Update kompilieren  (veröffentlichen) und ins Produktivsystem einspielen wollen. Den ConnectionString für die externe Datenbank leiten Sie nun einfach auf die Kopie der Datenbank um, die Sie in im ersten Schritt in die localdb integriert hatten.

Die aktuelle Kopie der Produktiv-Datenbank, die von Lightswitch bei der Erstinstallation erstellt wurde, binden Sie ebenfalls in die localdb. Um die IntrinsicData für den Debug Mode mit den Daten aus der Kopie der Produktiv-Datenbank zu befüllen, müssten Sie ein eigenes SQL-Skript schreiben. Wichtig: Das Datenbankschema der zugehörigen ApplicationData.mdf dürfen Sie nicht von außen modifizieren, damit wäre LightSwitch out-of-Sync. Wir haben in unserem Beispiel darauf verzichtet, die Produktivdaten in die Testumgebung zu importieren. Gegebenenfalls reicht es auch, die Produktiv-Daten via SQL Management Studio in die ApplicationData.mdf zu importieren, wir haben das allerdings nicht getestet. Falls Sie das testen, würden wir uns über Feedback freuen.

Falls Sie sich fragen, wozu wir die IntrinsicData eigentlich kopiert haben, wenn wir die Daten nicht übernehmen: Sie benötigen das Datenbankschema beim Veröffentlichen der Lightswitch-Anwendung, um ein SQL-Skript für das Update der Datenbank zu erstellen. Unsere Meinung: Lightswitch verändert von Version zu Version ggf. die Struktur an der IntrinsicData, z.B. RowVersion wurde hinzugefügt. Den Schritt sollte man daher nicht weglassen, auch wenn man keine eigenen (absichtlichen) Änderungen an der Datenstruktur durchgeführt hat. 

Jetzt sollten Sie in Ihrer Entwicklungsumgebung das Programm im Debug Mode starten können und Zugriff auf die externe Datenbank(kopie) haben. Falls Sie wie wir SQL-Views in der externen Datenbank verwenden und eine Umbenennung durchgeführt haben, müssen Sie die SQL-Views anpassen, um die richtige Verarbeitung aus der lokalen Kopie heraus sicher zu stellen. 

Im zweiten Teil des How-To beschreiben wir, wie Sie das Update Lightswitch-Anwendung wieder ins Produktivsystem einspielen können und dabei die IntrinsicData-Datenbank per SQL-Skript updaten.