Datenbankentwicklung: Einführung in neue Features in VSTS Database Edition GDR

Artikel
10/14/2015

Datenbankentwicklung

Einführung in neue Features in VSTS Database Edition GDR

Jamie Laflen und Barclay Hill

Themen in diesem Artikel:

Offlineschemaentwicklung
Änderungen der Produktstruktur
Einführung in Serverprojekte
SQL CLR-Projektunterstützung

In diesem Artikel werden folgende Technologien verwendet:
VSTS 2008 Database Edition GDR

Inhalt

Offlineschemaentwicklung
Datenbankverwaltung
Änderungen der Produktstruktur
Einführung in Serverprojekte
Serverprojektverweise
Erstellen von Verweisen für freigegebene Objekte auf Serverebene
Erstellen von Verweisen für Systemobjekte
Projektaktualisierung
Erstellen und Bereitstellen eines neuen Datenbankprojektbuilds
Befehlszeilenfunktion – VSDBCmd
SQL CLR-Projektunterstützung
Verbesserungen der statischen Codeanalyse
Tipps und Tricks

Im November 2008 wurde die allgemeine Vertriebsversion (General Distribution Release, GDR) für Microsoft Visual Studio Team System 2008 (VSTS) Database Edition veröffentlicht. Die GDR wird zusätzlich zur anfänglichen Version von VSTS 2008 Database Edition installiert, ist aber mehr als ein kleines Versionsupgrade. In der GDR wurde die Unterstützung für SQL Server 2008 hinzugefügt, es wurden Verbesserungen vorhandener Features, viele neue Features und Erweiterbarkeitspunkte sowie bereits als Power Tools veröffentlichte Features integriert.

In diesem Artikel geht es speziell um die neuen Features in der GDR, einschließlich der darin enthaltenen Unterstützung für die Offlineschemaentwicklung, der Tools zur Unterstützung neuer Prozesse, die Sie beim Entwickeln eines Datenbankschemas verwenden können, sowie der Features, die diese Datenbankverwaltung unterstützen.

Zusätzlich zu diesen Prozessverbesserungen bietet VSTS Database Edition GDR außerdem die folgenden Funktionen:

Interpretation und Evaluierung des Schemas Ihres Projekts und der gegenseitigen Abhängigkeiten. Die Offlineverarbeitung ermöglicht Entwicklern, vor der Bereitstellung Syntax- und Verweisfehler zu erkennen.
Umgestaltung – Mithilfe von VSTS Database Edition können Sie den Namen eines Objekts (wie z. B. einer Tabelle oder Spalte) ändern. Durch diese Änderung werden alle Verweise auf den neuen Namen aktualisiert.
Automatisiertes differenzierendes Modul – Wenn Sie ein Projekt bereitstellen, generiert es ein T-SQL-Skript (Transact-SQL), das nur die Änderungen enthält, die für eine Übereinstimmung der Zieldatenbank mit der Quelle notwendig sind.
Datenbankkomponententests – Sie können einen Designer verwenden, der die Entwicklung T-SQL-orientierter Tests ermöglicht, sodass Ihr Schema angewendet und überprüft werden kann, bevor Sie Ihren Code einchecken.
Testdatengenerierung – Mit diesem Tool können Sie realistische Pseudozufallstestdaten generieren, die beim Ausführen von Komponententests verwendet werden können.

Neben den Beschreibungen der Funktionen, die diese Features bieten, erhalten Sie einige praktische Beispiele, die zeigen, wie diese Features angewendet werden.

Offlineschemaentwicklung

Historisch gesehen, erforderte die Datenbankschemaentwicklung das Erstellen von Code mithilfe eines freigegebenen Entwicklungsservers und das anschließende Erstellen von Aktualisierungsskripts, um die Änderungen von einer Umgebung in eine andere zu übertragen. Dieser Ansatz bietet keine Möglichkeit, die Änderungen an Datenbankobjekten nachzuverfolgen und zusammenzuführen. Dadurch wird das Übertragen der Änderungen von einer Umgebung in eine andere ein sehr manueller Prozess.

In VSTS Database Edition werden die Objekte (wie z. B. Tabellen, gespeicherte Prozeduren und Ansichten), aus denen ein Schema besteht, in einem Visual Studio-Datenbankprojekt als CREATE-Skripts verwaltet. Das Speichern dieser Objekte als Skripts bedeutet, dass Sie die Skripts über ein Quellcodeverwaltungssystem verwalten können, und es ermöglicht, dass die Skripts gleichzeitig von mehr als einem Datenbankentwickler bearbeitet und beim Einchecken der Änderungen nach Bedarf zusammengeführt werden können. Der Prozess, bei dem Skriptdateien ohne eine Verbindung mit einer Datenbank bearbeitet werden, wird Offlineschemaentwicklung genannt. Nachdem die Definition Ihrer Datenbank von einer Livedatenbank in eine Offline- bzw. modellierte Umgebung verlagert worden ist, können Datenbankentwickler agile oder iterative Entwicklungsmethoden anwenden, die dazu beigetragen haben, dass die Anwendungsentwicklung schlanker und kostengünstiger geworden ist.

Ein Datenbankentwickler kann die Offlineentwicklung beginnen, indem er bzw. sie ein Datenbankprojekt in Visual Studio erstellt und dann die aktuelle Entwicklungsdatenbank in das Projekt importiert. Das importierte Projekt kann gegebenenfalls einige Warnungen auslösen, aber nachdem Sie die Warnungen und Projektbuilds erfolgreich bereinigt haben, können Sie es in Ihr Quellcodeverwaltungssystem einchecken.

Nachdem das Projekt und der Quellcode eingecheckt worden sind, können die Entwickler in Ihrem Team das Projekt und den Quellcode abrufen und sie für die Arbeit auf ihren lokalen Computern verwenden. Änderungen können jetzt für eine lokale Sandboxdatenbank bereitgestellt und manuell getestet werden. Bei diesem Ansatz kann ein Entwickler isoliert arbeiten, ohne die Stabilität einer freigegebenen Datenbankumgebung zu gefährden. Sie können diesen Ansatz verbessern, indem Sie einen oder mehrere Datenbankkomponententests erstellen, um eine Änderung zu überprüfen. Nachdem eine Änderung überprüft worden ist, führen Sie alle Komponententests mithilfe der Sandboxdatenbank aus, die nicht nur den geänderten Code überprüft, sondern auch sicherstellt, dass durch die Änderung kein anderer Code unterbrochen wurde. Checken Sie nach bestandenen Tests die Änderungen in das Quellcodeverwaltungssystem ein.

Sobald die Änderungen eingecheckt worden sind und das Team bereit ist, kann ein Build durch Abrufen der Quelle vom Quellcodeverwaltungssystem durchgeführt werden. Nach ihrer Erstellung kann die Datenbank zusammen mit dem Anwendungscode für eine Umgebung bereitgestellt werden, in der die Benutzer anfangen können, mit dem neu entwickelten Produkt zu arbeiten.

Datenbankverwaltung

VSTS Database Edition bietet mehrere Tools für häufige Aufgaben, die beim Verwalten einer Datenbank anfallen. Ein solches Tool ist der Schemavergleich, bei dem die Aufgabe des Vergleichs und der Aktualisierung des Schemas automatisiert wird. Sie können den Schemavergleich verwenden, um zwei Datenbanken zu vergleichen und dann ein Aktualisierungsskript zu generieren, um Objekte zu erstellen, zu verändern oder in der Zieldatenbank abzulegen. Wenn Änderungen direkt in einer Livedatenbank außerhalb des normalen Bereitstellungsprozesses vorgenommen werden müssen, können Sie den Schemavergleich verwenden, um eine Datenbank mit einem Offlinedatenbankprojekt zu vergleichen und dann alle Aktualisierungen wieder in das Datenbankprojekt zu importieren, damit sie in die Quellcodeverwaltung eingecheckt werden.

Das Schemavergleichstool hat einige neue Features in der GDR. Besonders beachtenswert ist die Möglichkeit, Vergleichseinstellungen und -optionen zwischen Verwendungssitzungen beizubehalten. (Vergleichsergebnisse werden nicht gespeichert, sondern nur die Optionen und Einstellungen.)

Die Fähigkeit, Einstellungen und Optionen beizubehalten, führt im Projektsystem einen neuen Dateityp ein, und zwar die .scmp-Datei, die standardmäßig im Schemavergleichsordner des Projektsystems gespeichert wird. Mehrere Schemavergleichsdateien können im Projekt erstellt oder verglichen werden. Sie können außerdem Ihre Schemavergleichseinstellungen speichern, ohne dass ein Datenbankprojekt die für die Problembehandlung oder aus anderen Gründen des Betriebs häufig verwendeten Vergleichseinstellungen beibehält.

Der Schemavergleich bietet jetzt auch Einstellungen für die Sitzungsebenenoption, auf die Sie von der Symbolleiste des Schemavergleichs zugreifen können (siehe Abbildung 1). Sie können Objekte filtern, um spezifische Objekttypen aus Vergleichen auszuschließen. Die in Ihren Projekten definierten SQLCMD-Variablen können durch Vergleiche ersetzt werden, und es können Skripterstellungsoptionen definiert werden, durch die gesteuert wird, wie das Aktualisierungsskript erstellt wird. Alle diese Optionen können in einer .scmp-Datei gespeichert werden.

Abbildung 1 Schemavergleichsoptionen

Die Symbolleiste des Schemavergleichs bietet eine einfache Navigation zwischen den einzelnen Schemadifferenzen in einem Vergleich. Sie können nach dem Typ der Differenzen filtern, um neue, fehlende, unterschiedliche, gleiche oder eine Kombination dieser Typen anzuzeigen. Der Schemavergleich unterstützt außerdem den Vergleich von .dbschema-Dateien. Sie können jetzt jede Kombination aus Projekt, Datenbank und .dbschema-Datei vergleichen. Das Erstellen von Updates ist in dieser Veröffentlichung nicht möglich, wenn das Ziel eine .dbschema-Datei ist, aber alle anderen Kombinationen unterstützen sowohl den Vergleich als auch das Erstellen von Updates für ein Ziel.

VSTS Database Edition bietet zudem ein Tool, das den Vergleich von Daten in zwei Datenbanksystemen vereinfacht. Mit dem Datenvergleich kann ein Administrator Tabellen vergleichen, die primäre/eindeutige Schlüssel enthalten, und erkennen, wo in den zwei Systemen Daten fehlen oder zusätzliche oder andere Daten vorhanden sind. Wie der Schemavergleich kann der Datenvergleich ein Skript generieren, das Updates direkt in das Zielsystem schreibt, um seine Daten mit denen des Quellsystems abzustimmen.

Änderungen der Produktstruktur

In der GDR werden eine Reihe wichtiger struktureller Änderungen eingeführt. Eine der wichtigsten Änderungen ist eine realistische Modellrepräsentation von SQL Server-Datenbanken.

In früheren Versionen von VSTS Database Edition war eine Entwurfsinstanz von SQL Server 2005 erforderlich. Das Projektsystem verwendete den Entwurf als abschließenden Prüfungsschritt für die Skripts der Datendefinitionssprache (Data Definition Language, DDL) im Datenbankprojekt. Dafür musste jeder Entwickler eine Instanz von SQL Server lokal auf dem Desktop- oder Buildcomputer ausführen, um eine Offlinerepräsentation der Datenbank bereitzustellen.

Mit der GDR ist die Entwurfsinstanz nicht mehr erforderlich, und das Projektsystem wird von einer vollständig modellierten Repräsentation des Datenbankschemas unterstützt. Die GDR erstellt das Modell, das die SQL Server-Datenbank repräsentiert, aus DDL-Skripts in Ihrem Datenbankprojekt und stellt das Modell für alle Datenbanktools bereit, die in Visual Studio verfügbar sind. Beim Erstellen des Datenbankprojekts wird eine .dbschema-Datei erstellt, die eine serialisierte XML-Repräsentation des Modells ist. Bei der Bereitstellung eines Datenbankprojekts wird ein Bereitstellungsskript generiert, das auf einem Vergleich der Buildausgabe des Projekts mit dem Modell, das von der Zieldatenbank erstellt wird, basiert.

Zwischen Verwendungssitzungen des Projekts wird das Modell des Datenbankprojekts in einer .dbml-Datei im Stammverzeichnis des Projekts beibehalten. Die .dbml-Datei stellt einen Cache des Modells bereit, um das Öffnen und Erstellen vorhandener Datenbankprojekten, die größere Schemas enthalten, zu beschleunigen.

Modelle werden von Datenbankschemaanbietern (database schema providers, DSPs) implementiert. Die GDR enthält drei DSPs, einen für jede unterstützte Version von SQL Server – SQL Server 2008 sowie SQL Server 2000 und SQL Server 2005, wie in früheren Versionen. Mit einem anbieterbasierten Modell sind Veröffentlichungen von VSTS Database Edition jetzt von SQL Server-Veröffentlichungen abgekoppelt. Wenn eine neue Version von SQL Server veröffentlicht wird oder ein Service Pack eine vorhandene Version mit einer neuen Funktionalität oder Syntax aktualisiert, kann ein neuer oder aktualisierter DSP veröffentlicht werden, um diese Änderungen in der SQL Server-Funktionalität zu unterstützen. In zukünftigen Veröffentlichungen von Visual Studio Team System wird dieses anbieterbasierte Modell Drittanbietern ermöglichen, die Unterstützung der Projektumgebung durch VSTS Database Edition auf andere Datenbankplattformen zu erweitern.

Einführung in Serverprojekte

Serverprojekte (ein neues Feature in der GDR) ermöglichen einem Team, eine Konfiguration auf Serverebene für SQL Server-Datenbanken in einem eigenständigen Projekt zu definieren. Der Hauptzweck eines Serverprojekts besteht darin, eine erwartete Konfiguration und Objekte für Datenbankprojekte freizugeben. Auf ein Serverprojekt kann durch mehrere Datenbankprojekte verwiesen werden, ohne Serverobjektdefinitionen zu duplizieren. Zum Beispiel kann es sein, dass Sie über drei Datenbankprojekte verfügen, die jeweils eine Benutzerdatenbank auf Ihrem Zielserver repräsentieren. Jedes dieser Datenbankprojekte sollte einen Verweis auf das gleiche Serverprojekt besitzen, um sicherzustellen, dass die Konfiguration des Zieldatenbankservers konsistent ist.

Die Serverkonfigurationseinstellungen, die in einem Serverprojekt definiert werden, werden für Überprüfungszwecke während der Bereitstellung verwendet, auch wenn an der Serverkonfiguration zum Zeitpunkt der Bereitstellung keine tatsächlichen Änderungen vorgenommen werden. Während der Bereitstellung wird die Konfiguration des Servers überprüft, damit sie der erwarteten Konfiguration entspricht, die im Serverprojekt beschrieben wird. Wenn die Konfigurationsüberprüfung so wie im Serverprojekt angegeben fehlschlägt, schlägt die Bereitstellung fehl, und an freigegebenen Objekten auf Serverebene oder Benutzerdatenbanken werden keine Änderungen vorgenommen.

Zum Konfigurieren der Servereinstellungen in einem Serverprojekt nehmen Sie Änderungen an der Server.sqlsettings-Datei im Eigenschaftenordner des Serverprojekts vor. (In der SQL Server-Onlinedokumentation für die Version von SQL Server, die Sie verwenden, können Sie die Beschreibung der Funktionsweise der einzelnen Servereinstellungen finden.) Ein Beispiel für Servereinstellungen wird in Abbildung 2 gezeigt.

Abbildung 2 Beispiele für Servereinstellungen für ein Serverprojekt

Standardmäßig werden während der Bereitstellung keine Servereinstellungen überprüft. Aktivieren Sie zum Überprüfen einer Einstellung während der Bereitstellung das Kontrollkästchen „Verify“ (Überprüfen), und konfigurieren Sie den erwarteten Wert in der Spalte „Value“ (Wert).

Serverprojektverweise

Objekte in Datenbankprojekten, die auf Objekte auf Serverebene verweisen, erfordern, dass die Objekte auf Serverebene definiert werden. Die Objekte auf Serverebene in einem Serverprojekt zu modellieren, ermöglicht Ihnen, von Ihren Datenbankprojekten auf diese Objekte zu verweisen. Wenn zum Beispiel in einem Datenbankprojekt ein Benutzer mit einem Anmeldenamen definiert ist, müssen Sie ein Serverprojekt erstellen, um den Anmeldenamen auf Serverebene zu modellieren, der vom Benutzer in Ihrem Datenbankprojekt benötigt wird. Wenn Sie zum Beispiel nur Systemobjekte verwenden und keine freigegebenen Objekte auf Serverebene vorhanden sind, können Sie der master.dbschema-Datei, die mit der GDR installiert wird, einen Verweis hinzufügen.

Erstellen von Verweisen für freigegebene Objekte auf Serverebene

Serverprojekte bieten Unterstützung für das Modellieren freigegebener Objekte auf Serverebene, die im Vergleich zu Objekten auf Benutzerdatenbank-Ebene ein anderes Verhalten und einen anderen Umfang haben. Ungültige Verweise auf Objekte auf Serverebene, die durch Objekte in Datenbankprojekten erfolgen, werden gekennzeichnet und auf das Serverprojekt zurückgeführt, wobei jeder nicht aufgelöste Verweis durch Fehlermeldungen oder Warnungen angezeigt wird.

Ein häufiges Beispiel für ein freigegebenes Objekt auf Serverebene ist ein Anmeldename. Mehrere Benutzerdatenbanken können beim Definieren von Benutzerobjekten in Datenbankprojekten denselben Anmeldenamen verwenden, indem sie auf das Anmeldeobjekt in einem Serverprojekt verweisen. Wenn in Ihren Datenbankprojekten Benutzerobjekte definiert wurden, die auf einen Anmeldenamen verweisen, müssen Sie einen Datenbankverweis auf ein Serverprojekt einrichten, bei dem das Vorhandensein des Anmeldenamens dazu dient, Ihr Benutzerobjekt in Ihrem Datenbankprojekt vollständig aufzulösen. Wenn Sie dies unterlassen, erhalten Sie einen Überprüfungsfehler, der etwa so aussieht, wie in Abbildung 3 dargestellt.

Abbildung 3 Beispiel für einen Überprüfungsfehler

Zum Erstellen von Verweisen auf Objekte in einem Serverprojekt müssen Sie zuerst ein Serverprojekt erstellen, das Ihre Masterdatenbank repräsentiert. Das Serverprojekt wird von einer Serverprojektvorlage erstellt, die sich unter dem Datenbankprojektknoten des Dialogfelds „New Project“ (Neues Projekt) befindet. Es gibt drei Serverprojektvorlagen, eine für jede unterstützte Version von SQL Server. Wenn der Zielserver bereits existiert, können Sie die Masterdatenbank des Zielservers in ein neues Serverprojekt importieren. Alle benutzerdefinierten Objekte im Server werden importiert. Erstellen Sie als Nächstes das Serverprojekt, um sich zu vergewissern, dass keine Probleme vorhanden sind, und erstellen Sie eine .dbschema-Datei, die den Server modelliert.

Verweisen Sie in Ihrem Datenbankprojekt auf das Serverprojekt, indem Sie einen neuen Datenbankverweis einrichten. Das folgende Beispiel enthält ein Serverprojekt (MyServer) und ein Datenbankprojekt (MyDatabase) in der gleichen Lösung. Erstellen Sie einen Datenbankverweis, indem Sie mit der rechten Maustaste auf den Ordner „Datenbankverweise“ des MyDatabase-Projekts im Projektmappen-Explorer und dann auf „Datenbankverweis hinzufügen“ klicken. Das Dialogfeld wird in Abbildung 4 gezeigt.

Abbildung 4 Dialogfeld „Datenbankverweis hinzufügen“

Für diesen Verweistyp sollten Sie die Standardeinstellungen akzeptieren, die im Dialogfeld „Datenbankverweis hinzufügen“ angezeigt werden. Das Verwenden des Literals „master“ ermöglicht Ihren Datenbankobjekten (wie z. B. einer gespeicherten Prozedur), auf Objekte (wie z. B. eine Tabelle) zu verweisen, die in der Masterdatenbank vorhanden sind, indem das master-Literal als Teil des dreiteiligen Komponentennamens verwendet wird. Wenn Sie nicht aufgelöste Verweisfehler in Bezug auf Objekte auf Serverebene haben, sollten diese vom neuen Verweis korrigiert werden. Abbildung 5 zeigt die Datenbankverweise für das MyDatabase-Projekt im Projektmappen-Explorer, nachdem der Verweis erstellt worden ist.

Abbildung 5 MyDatabase-Verweise

Erstellen von Verweisen für Systemobjekte

Ein Verweis auf eine Masterdatenbank ist auch erforderlich, wenn im Datenbankprojekt Systemobjekte verwendet werden. Ein Beispiel für ein Systemobjekt ist eine gespeicherte Systemprozedur, eine Systemtabelle, eine Systemansicht oder ein Systemkatalog. Ein Systemobjekt, das in Benutzerdatenbanken häufig verwendet wird, ist die sysobjects-Ansicht. Sehen Sie sich zum Beispiel die gespeicherte Prozedur in Abbildung 6 an, in der die sys.sysobjects- und sys.schemas-Systemansichten verwendet werden. Ohne einen Verweis auf eine Masterdatenbank, die die Definitionen dieser Objekte enthält, werden zahlreiche Warnungen generiert, die anzeigen, dass die in der gespeicherten Prozedur verwendeten Systemobjekte nicht aufgelöst werden können. Weil gespeicherte Prozeduren eine zurückgestellte Namensauflösung ermöglichen, handelt es sich um nicht aufgelöste Verweiswarnungen. Die gleiche SELECT-Anweisung in einer VIEW-Definition würde Fehler generieren.

Abbildung 6 Warnungen und Fehler erfolgen ohne einen Verweis auf eine Masterdatenbank

Um diese Warnungen zu entfernen, müssen Sie einen Verweis auf eine Masterdatenbank erstellen, die die Definitionen dieser Objekte enthält. Das Verweisen auf Systemobjekte erfordert jedoch kein Serverprojekt. Denken Sie daran, dass Serverprojekte die Objekte und Einstellungen enthalten, die Sie definiert haben. Um auf eine Masterdatenbank zu verweisen, die Systemobjekte enthält, müssen Sie auf eine master.dbschema-Datei verweisen, um die Verweise auf Systemobjekte aufzulösen. Um einen Verweis auf die master.dbschema-Datei zu erstellen, müssen Sie einen Datenbankverweis in der oben beschriebenen Weise definieren, aber statt auf ein Projekt zu verweisen, verweisen Sie auf eine .dbschema-Datei. Die master.dbschema-Dateien sind in den folgenden Verzeichnissen zu finden:

"%programfiles%\Microsoft Visual Studio 9.0\VSTSDB\Extensions\SqlServer\
<SQL Version>\DBSchemas"

Mit der GDR werden sieben .dbschema-Dateien installiert: zwei für jede unterstützte Version von SQL Server und eine zusätzliche .dbschema-Datei für die neuen SQL-Typen, die in SQL Server 2008 verfügbar sind. Beachten Sie, dass jede unterstützte Version von SQL Server entsprechende master.dbschema- und msdb.dbschema-Dateien enthält. Außerdem ist Folgendes zu beachten: Wenn Sie Verweise auf master.dbschema-Dateien erstellen, kann es etwas dauern, bis das Modell Ihres Projekts aktualisiert ist, weil diese .dbschema-Dateien alle Objekte enthalten, die in der Masterdatenbank der SQL Server-Version definiert werden, auf die Sie abzielen. Schließlich ist es auch möglich, dass sowohl ein Verweis auf ein Serverprojekt als auch auf eine statische master.dbschema-Datei vorhanden ist, weil sie unterschiedlichen Zwecken dienen. Beide Verweise verwenden in der Regel das master-Literal.

Projektaktualisierung

Wenn Sie an einem Projekt arbeiten, das in einer Version von VSTS Database Edition vor der GDR erstellt wurde, müssen Sie alle Objekte auf Serverebene, die Sie in den Skripts vor und nach der Bereitstellung erstellt haben, in ein neues Serverprojekt verschieben. Während des Prozesses der Projektaktualisierung werden alle Serverobjekte, die in den Skripts vor und nach der Bereitstellung definiert wurden, in eine Skriptdatei namens „Upgraded.AllServerObjects.sql“ verschoben, die in einem Unterordner des Stammprojektordners namens „Upgrade“ gespeichert ist. Sie können diese Skriptdatei mithilfe des Befehls „Skript importieren“ in ein neu erstelltes Serverprojekt importieren. Um Verweisfehler oder Warnungen aufzulösen, erstellen Sie von Ihrem Datenbankprojekt einen Verweis auf Ihr neues Serverprojekt.

Erstellen und Bereitstellen eines neuen Datenbankprojektbuilds

Beim Thema Datenbankbereitstellung sind sofort einige Szenarios denkbar:

Die meisten IT-Gruppen haben mehrere Umgebungen, die der Build einer Abteilungsanwendung durchlaufen muss, bevor er die Produktionsumgebung und die Endbenutzer erreicht.
Softwarehersteller denken an ein Zieldatenbankschema, wenn sie ein Update veröffentlichen, aber sie möchten in der Lage sein, das Schema eines Kunden, das mit dem Schema der älteren Version nicht übereinstimmt, problemlos zu aktualisieren.

Es war schwierig, diese Szenarios in früheren Versionen von VSTS Database Edition zu verwalten, weil beim Erstellen eines Datenbankprojekts ein T-SQL-Bereitstellungsskript ausgegeben wurde. Die Buildausgabe wurde generiert, indem das Datenbankprojekt und die Datenbank auf der Zielinstanz (oder der Entwurfsdatenbankinstanz) differenziert wurden und anschließend ein Skript erstellt wurde, um die Zielinstanz so zu aktualisieren, dass sie aussieht wie die Quelle des Projekts. Weil das Skript während der Builderstellung generiert wurde, gab es keine Möglichkeit, die Ausgabe eines „Builds“ mehrfach in verschiedenen Umgebungen (mit möglicherweise verschiedenen Schemas) auszuführen.

In der GDR wurden die während der Builderstellung und -bereitstellung ausgeführten Aktionen geändert, um die beschriebenen Szenarios zu unterstützen. Im Wesentlichen aggregiert ein Build die Inhalte des Projekts und generiert einen Satz von Dateien, der logisch ein Bereitstellungspaket repräsentiert. Die Bereitstellung nutzt die „Bereitstellungspaket“-Dateien, generiert einen Bereitstellungsplan und führt dann diesen Plan aus, indem sie ein T-SQL-Skript ausführt. Sie können die Bereitstellung auch so konfigurieren, dass dieses Skript in Bezug auf die Zieldatenbank angewendet wird. Wie in früheren Versionen sind sowohl der Build als auch die Bereitstellung als MSBuild-Aufgaben verfügbar und können auf dem Buildserver eines Teams verwendet werden.

Um die Bereitstellung eines Builds für mehrere Umgebungen zu unterstützen, werden in verschiedenen Dateien bereitstellungsorientierte Konfigurationsinformationen einbezogen. Obwohl die Komplexität durch die Verwendung mehrerer Dateien zunimmt, können Sie dadurch die Konfigurationen, die Sie beim Bereitstellen für verschiedene Umgebungen verwenden, unter die Quellcodeverwaltung stellen. Zur Veranschaulichung dient das Beispiel in Abbildung 7, bei dem ein Build des Datenbankprojekts für vier verschiedene Umgebungen bereitgestellt werden soll.

Abbildung 7 Beispielumgebungen

Umgebung	Bereitstellungskonfiguration
Entwicklung	Bereitstellungen für diese Umgebung erstellen die Datenbank immer neu. Dies ist die Debug-Projektkonfiguration. Angepasste SqlCmd-Variable.
Integration	Bereitstellungen sind differenzierend, wobei ALTER-Anweisungen und DROPs für Objekte generiert werden, die im Projekt nicht existieren. Dies ist die Release-Projektkonfiguration. Angepasste SqlCmd-Variable.
Benutzertest	Vorbereitung auf die Produktbereitstellung. Bereitstellungen sind differenzierend. Angepasste SqlCmd-Variable.
Produktion	Bereitstellungen sind differenzierend. Angepasste SqlCmd-Variable.

Basierend auf diesen vier Umgebungen können vier angepasste Bereitstellungskonfigurationsdateien und SqlCmd-Dateien definiert werden, die jeweils die Konfiguration für die spezifische Umgebung speichern, auf die sie abzielen. Nach dem Einrichten dieser Dateien sehen die Eigenschaften des Projekts wie in Abbildung 8 aus.

Abbildung 8 Einrichtung der Projekteigenschaften für eine benutzerdefinierte Bereitstellung

Zusätzlich zu den Dateien können Sie sehen, dass die development.sqldeployment-Datei als Standardkonfiguration für die Debug-Projektkonfiguration festgelegt wurde. Die development.sqlcmdvars-Datei ist die Standarddefinition für SqlCmd-Variable und -Werte.

Nachdem ein Projekt erfolgreich erstellt worden ist, kann die Buildausgabe für die Bereitstellung für mehrere Datenbankinstanzen verwendet werden. Die gleiche Buildausgabe kann verwendet werden, um eine neue Datenbank bereitzustellen oder eine vorhandene Datenbank zu aktualisieren. Wie Sie weiter oben bereits gesehen haben, verwendet eine Bereitstellung standardmäßig die Konfiguration des Projekts zum Zeitpunkt der Projekterstellung. Sie können jedoch alle .deploymanifest-Eigenschaften über die Befehlszeile außer Kraft setzen. Um zum Beispiel eine Bereitstellung für alle Umgebungen vorzunehmen, die in Abbildung 8 aufgelistet werden, müssen Sie die folgenden Befehlszeilenargumente verwenden:

Entwicklung:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\Development.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\Development.sqlcmdvars /p:TargetConnectionString=
   "DataSource=DEV\sql2008;Integrated Security=true;Pooling=false"

Integration:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\Integration.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\Integration.sqlcmdvars /p:TargetConnectionString=
    "DataSource=INT\sql2008;Integrated Security=true;Pooling=false"

Benutzertest:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\UserTest.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\UserTest.sqlcmdvars /p:TargetConnectionString=
   "DataSource=USERTEST\sql2008;Integrated Security=true;Pooling=false"

Produktion:

msbuild EnterpriseDB.dbproj /t:Deploy
/p:DeploymentConfigurationFile=sql\debug\Production.sqldeployment
/p:SqlCommandVariablesFile=sql\debug\Production.sqlcmdvars /p:TargetConnectionString=
   "DataSource=PRODUCTION\sql2008;Integrated Security=true;Pooling=false"

In diesen Beispielen wird die Deploy MSBuild-Aufgabe verwendet, um einen einzelnen Build von EnterpriseDB.dbproj für mehrere Umgebungen mit verschiedenen Konfigurationen bereitzustellen. Sie können die gleiche Art von Bereitstellung durchführen, indem Sie ein neues Befehlszeilentool namens „VSDBCmd“ verwenden, das in GDR enthalten ist.

Befehlszeilenfunktion – VSDBCmd

Die GDR umfasst ein Befehlszeilentool namens „VSDBCmd“ (vsdbcmd.exe). Dieses Tool kann eine .dbschema-Datei aus einer vorhandenen Datenbank erstellen und eine Buildausgabe oder nur eine .dbschema-Datei für eine Zielinstanz bereitstellen. VSDBCmd kann außerdem auf einem Computer verwendet werden, auf dem Visual Studio nicht installiert ist. Um das Befehlszeilentool von einem Computer zu einem anderen zu verschieben, kopieren Sie die ausführbare Datei und ihre Komponenten aus dem deploy-Verzeichnis unter dem VSTSDB-Verzeichnis. In einer Visual Studio-Standardinstallation ist dies „%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\“. Das deploy-Verzeichnis kann auf einen USB-Stick kopiert und dann auf einem anderen Computer gespeichert werden.

Zur Einführung in VSDBCmd wird das Tool im Folgenden über die Befehlszeile ausgeführt. Abbildung 9 zeigt die Ergebnisse. Obwohl diese Optionen auf den ersten Blick vielleicht kompliziert erscheinen, gibt es mehrere Punkte, die beachtet werden müssen und die verständlich machen, wie diese Optionen gruppiert sind:

VSDBCmd wurde für die Verwendung mit mehreren Datenbankplattformen entworfen. Heute unterstützt VSTS Database Edition nur SQL Server, aber dies wird sich in zukünftigen Veröffentlichungen wahrscheinlich ändern.
Um ein Datenbankschema zu importieren oder eine Bereitstellung für eine Datenbank vorzunehmen, müssen Sie eine Verbindungszeichenfolge bereitstellen. Diese Verbindungszeichenfolge ist eine standardmäßige ADO.NET-Verbindungszeichenfolge für den Datenbankanbieter.
Weil das Tool von spezifischen Datenbankanbietern unabhängig ist, müssen Sie einen Hinweis dazu geben, welcher Anbieter mit der Verbindungszeichenfolge verwendet werden soll, und es muss eine Verbindungszeichenfolge definiert werden, um die Datenbankversion zu bestimmen, auf die Sie abzielen. Zum Beispiel sind einige Optionen für die SQL Server-Bereitstellung nur für SQL 2005 und höher verfügbar.

Abbildung 9 VSDBCmd-Ausgabe

>"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" /?
Help for dynamic property usage
/help[+|-]                        (short form /?)
/Action:{Import|Deploy}           (short form /a)
/ConnectionString:<string>        (short form /cs)
/DatabaseSchemaProvider:<string>  (short form /dsp)
@<file>                           Read response file for more options

Help for command actions
/Action:{Import|Deploy}           (short form /a)
/Quiet[+|-]                       (short form /q)
/ConnectionString:<string>        (short form /cs)
/DeployToDatabase[+|-]            (short form /dd)
/ModelFile:<string>               (short form /model)
/ManifestFile:<string>            (short form /manifest)
/DeploymentScriptFile:<string>    (short form /script)
/DatabaseSchemaProvider:<string>  (short form /dsp)
/Properties:<string>              (short form /p)
@<file>                           Read response file for more options

Um ein Modell aus der Northwind-Datenbank zu erstellen, kann Folgendes ausgeführt werden:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Import 
/cs:"Data Source=(local)\sql2008;Integrated Security=true;Initial Catalog=Northwind08" 
/dsp:sql 
/model:northwind.dbschema

Hier wird angegeben, dass aus der in der Verbindungszeichenfolge angegebenen Datenbank eine .dbschema-Datei namens „northwind.dbschema“ erstellt werden soll. Weil VSDBCmd mehrere Anbieter unterstützt, muss außerdem der Anbieter angegeben werden, der beim Erstellen der .dbschema-Datei verwendet werden soll. In diesem Fall ist es der „sql“-Anbieter. Wie Sie sehen können, sind die Optionen für das Importieren einer Datenbank in ein Modell recht einfach. Es gibt einige zusätzliche Importoptionen, die SQL Server-spezifisch sind. Um diese Optionen zu sehen, können Sie den folgenden Hilfebefehl für dynamische Eigenschaften verwenden:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Import 
/cs:"Data Source=(local)\sql2008;Integrated Security=true"
/dsp:sql 
/?

Jetzt kann das Modell, das in eine neue Datenbank importiert wurde, bereitgestellt werden. Verwenden Sie zum Bereitstellen des Modells den folgenden Befehl:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/cs:"Data Source=(local)\sql2008;Integrated Security=true" 
/model:northwind.dbschema 
/dd:+  
/p:TargetDatabase=NewNorthwind

Dieser Befehl stellt das Modell, das in northwind.dbschema enthalten ist, für die Instanz „(local)\sql2008“ bereit und platziert es in einer neuen Datenbank namens „NewNorthwind“. Wenn VSDBCmd ohne die Option zur Bereitstellung in einer Datenbank (/dd:+) ausgeführt wird, wird nur ein Bereitstellungsskript generiert, das dem Skript sehr ähnlich ist, das durch das Bereitstellen eines Projekts oder durch Verwenden des Schemavergleichs generiert wird. Im vorigen Beispiel würde in dem Fall, dass (/dd:+) nicht angegeben ist, ein Unterschiedsskript ausgegeben werden (weil kein Name angegeben wurde, würde der Dateiname „northwind.txt“ lauten). Dies kann eine gute Möglichkeit darstellen, ein Skript zur Überprüfung zu generieren, bevor das Skript anhand der Zielinstanz ausgeführt wird.

Die Option „/p:TargetDatabase=NewNorthwind“ unterscheidet sich von den anderen Optionen. Sie ist ein Beispiel für die vielen Optionen, die durch das Toolerweiterbarkeitsframework verfügbar gemacht werden. Um alle Optionen zu sehen, über die SQL Server verfügt, verwenden Sie den folgenden Befehl bei einer SQL Server 2008-Datenbank:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/cs:"Data Source=(local)\sql2008;Integrated Security=true" 
/dsp:sql 
/?

Dies sind die gleichen Optionen, die auf verschiedenen Bereitstellungs- und Schemavergleichs-Konfigurationsseiten verfügbar sind.

Zusätzlich zum Bereitstellen einer .dbschema-Datei kann VSDBCmd auch für die Nutzung und Bereitstellung der Ausgabe eines Datenbankprojektbuilds verwendet werden. Sie können VSDBCmd verwenden, um die gleiche Bereitstellung für mehrere Umgebungen durchzuführen, die weiter oben mit MSBuild vorgenommen wurde. Bei VSDBCmd benötigen Sie jedoch nicht die .dbproj-Datei, um die Deploy-Aufgabe auszuführen oder VSTS Database Edition zu installieren. In den folgenden Beispielen wird VSDBCmd innerhalb des Buildausgabeverzeichnisses ausgeführt:

Entwicklung:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=Development.sqldeployment 
/p:SqlCommandVariablesFile=Development.sqlcmdvars 
/cs:"Data Source=DEV\sql2008;Integrated Security=true"

Integration:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=Integration.sqldeployment 
/p:SqlCommandVariablesFile=Integration.sqlcmdvars 
/cs:"Data Source=INT\sql2008;Integrated Security=true"

Benutzertest:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=UserTest.sqldeployment 
/p:SqlCommandVariablesFile=UserTest.sqlcmdvars 
/cs:"Data Source=USERTEST\sql2008;Integrated Security=true"

Produktion:

"%programfiles%\microsoft visual studio 9.0\vstsdb\deploy\vsdbcmd" 
/a:Deploy 
/manifest:EnterpriseDB.deploymanifest 
/p:DeploymentConfigurationFile=Production.sqldeployment 
/p:SqlCommandVariablesFile=Production.sqlcmdvars 
/cs:"Data Source=PRODUCTION\sql2008;Integrated Security=true"

In diesen Beispielen können Sie sehen, dass VSDBCmd verwendet werden kann, um einen Build Ihres Datenbankprojekts mit verschiedenen Konfigurationen für mehrere Umgebungen bereitzustellen.

SQL CLR-Projektunterstützung

Seit SQL Server 2005 verfügen Entwickler über die Möglichkeit, Typen, Verfahren, Funktionen und Trigger als CLR-Typen zu implementieren. Vor der GDR war es schwierig, diese Typen als Teil des Schemas eines Datenbankprojekts zu verwenden, weil die Assemblyausgabe durch das C#- oder Visual Basic-Projekt als Skript mit Base64-codiertem Text hinzugefügt werden musste. Mit der GDR wurde die Unterstützung für SQL CLR-Projekte erheblich verbessert. Diese können jetzt aktiv als Teil Ihres Datenbankschemas während des Entwurfs verwendet und während der Projektbereitstellung auf einer Instanz verwaltet werden. Im folgenden Beispiel wird untersucht, wie dies funktioniert.

Erstellen Sie zuerst eine Lösung, und fügen Sie ein SQL Server 2008-Datenbankprojekt hinzu. Fügen Sie als Nächstes ein SQL CLR-C#-Projekt namens „CustomTypes“ hinzu (siehe Abbildung 10). Nachdem Sie dieses C#-Projekt hinzugefügt haben, werden Sie aufgefordert, ein Bereitstellungsziel anzugeben. Da die Bereitstellung der Assembly vom Datenbankprojekt verwaltet wird, brechen Sie dieses Dialogfeld ab.

Abbildung 10 Hinzufügen eines SQL CLR-Projekts

Fügen Sie jetzt einen Verweis vom Datenbankprojekt zum C#-Projekt hinzu. So wie C#-Projektverweise zeigt dieser Verweis an, dass die Inhalte des Projekts, auf das verwiesen wird, vom verweisenden Projekt verwendet werden. Fügen Sie den Verweis hinzu, indem Sie mit der rechten Maustaste auf den Verweisknoten im Datenbankprojekt und dann auf „Verweis hinzufügen“ klicken. Wählen Sie im Dialogfeld „Verweis hinzufügen“ das CustomTypes-Projekt aus.

Obwohl der Verweis hinzugefügt worden ist, müssen Sie seine Konfiguration noch anpassen, damit er korrekt bereitgestellt wird. Um die Konfiguration der Assembly zu ändern, wählen Sie den Verweis aus, und drücken Sie dann die F4-Taste. Abbildung 11 zeigt, was Sie im Eigenschaftenbrowser sehen.

Abbildung 11 Festlegen der Eigenschaften für CustomTypes

Für dieses Beispiel wurde der Assemblyname so geändert, dass er dem Namen des Projekts entspricht, und der Assemblybesitzer wurde so geändert, dass er explizit „dbo“ lautet. Standardmäßig ist die Berechtigungsebene der Assembly auf „Sicher“ gesetzt. Sie können diese Einstellung jedoch ändern, wenn Sie unsicheren Code für Ihre SQL Server-Instanz bereitstellen müssen.

Jetzt können Sie die Assembly bereitstellen, die vom CustomTypes-CLR-Projekt durch Auswählen von „Bereitstellen“ in den Projekteigenschaften von Database1 erstellt wurde. Weil hier keine Verbindungszeichenfolge für das Projekt konfiguriert wurde, wird ein CREATE-Bereitstellungsskript generiert. Im Ausgabefenster wird die Ausgabe angezeigt (siehe Abbildung 12).

Abbildung 12 Bereitstellen der CustomTypes-Assembly

------ Build started: Project: CustomTypes, Configuration: Debug Any CPU ------
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Csc.exe /noconfig 
/nowarn:1701,1702 /warn:4 /define:DEBUG;TRACE /reference:C:\WINDOWS\
Microsoft.NET\Framework\v2.0.50727\System.Data.dll /reference:C:\WINDOWS\
Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\WINDOWS\
Microsoft.NET\Framework\v2.0.50727\System.XML.dll /debug+ /debug:full 
/optimize- /out:obj\Debug\SqlClassLibrary.dll /target:library Properties\AssemblyInfo.cs

Compile complete -- 0 errors, 0 warnings
CustomTypes -> D:\Demos\Database1\CustomTypes\bin\Debug\SqlClassLibrary.dll
------ Build started: Project: Database1, Configuration: Debug Any CPU ------
    Loading project references...
    Loading project files...
    Building the project model and resolving object interdependencies...
    Validating the project model...
    Writing model to Database1.dbschema...
  Database1 -> D:\Demos\Database1\Database1\sql\debug\Database1.dbschema
------ Deploy started: Project: CustomTypes, Configuration: Debug Any CPU ------
Error: Cannot deploy. There is no database connection specified. To 
correct this error, add a database connection using the project properties.
Error: The operation could not be completed 
------ Deploy started: Project: Database1, Configuration: Debug Any CPU ------
    Deployment script generated to:
D:\Demos\Database1\Database1\sql\debug\Database1.sql

    The deployment script was generated, but was not deployed. You can 
    change the deploy action on the Deploy tab of the project properties.
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 1 succeeded, 1 failed, 0 skipped ==========

Auf das CustomTypes-Projekt wird durch Database1 verwiesen. Deshalb hat Visual Studio versucht, das Projekt vor der Bereitstellung von Database1 bereitzustellen. Weil keine Verbindungszeichenfolge für das CustomTypes-Projekt angegeben wurde, konnte es nicht bereitgestellt werden, was zu einem Fehler führte. Dieser Fehler kann ignoriert werden, weil die Assembly als Teil des Database1-Bereitstellungsskripts bereitgestellt wird. Sie können diesen Fehler verhindern, indem Sie die Bereitstellung von CustomTypes über den Konfigurations-Manager deaktivieren.

Nach dem Erstellen und Bereitstellen des Projekts können Sie das Database1-Bereitstellungsskript öffnen und sehen, dass die Assembly gegen Ende des Skripts erstellt wird:

GO
PRINT N'Creating CustomTypes...';

GO
CREATE ASSEMBLY [CustomTypes]
    AUTHORIZATION [dbo]
    FROM 0x4D5A90000300000004[snip…]    
    WITH PERMISSION_SET = SAFE;

GO

Die Inhalte der Assembly werden zudem verwendet, um Typverweise während der Builderstellung zu überprüfen. Um dies zu sehen, fügen Sie dem CustomTypes-Projekt einen benutzerdefinierten Typ (user-defined type, UDT) hinzu, indem Sie die Standardvorlage verwenden. Nennen Sie diese Datei „Type1.cs“. Um diesen Typ in der Datenbank zu verwenden, muss er im Datenbankprojekt deklariert werden. Um den benutzerdefinierten Typ hinzuzufügen, klicken Sie mit der rechten Maustaste auf Database1, klicken Sie auf „Element hinzufügen“, und verwenden Sie dann die Vorlage „Benutzerdefinierter Typ (CLR)“. Standardmäßig wird durch die Vorlage folgende Datei erstellt:

CREATE TYPE [dbo].[Type1]
  EXTERNAL NAME [assembly_name].[type_name]

Ändern Sie jetzt dieses T-SQL, um auf Type1 in CustomTypes zu verweisen, etwa so:

CREATE TYPE [dbo].[Type1]
  EXTERNAL NAME [CustomTypes].[Type1]

Speichern Sie diese Datei, und sehen Sie sich dann die Fehlerliste an. Darin werden Sie einen Fehler ähnlich dem folgenden feststellen:

TSD04117: The referenced type with the required Clr attribute was not found in the loaded 
assembly.

Dieser Fehler wird angezeigt, weil das CustomTypes-Projekt nicht erstellt worden ist, nachdem Type1.cs hinzugefügt wurde. Der Fehler wird behoben, sobald das CustomTypes-Projekt neu erstellt wird. Sie können diesen benutzerdefinierten Typ als Spaltentyp verwenden, indem Sie dem Projekt die folgende Tabelle hinzufügen:

CREATE TABLE [dbo].[Table1]
(
  column_1 int NOT NULL, 
  column_2 dbo.Type1 NULL
)

Wenn die Tabelle dem Projekt hinzugefügt wird, wird der Verweis auf dbo.Type1 vom Projektsystem evaluiert. Ein Fehler tritt auf, wenn dbo.Type1 nicht existiert.

Zusätzlich zum Erstellen eines Bereitstellungsskripts kann das Projekt auch für eine SQL 2008-Instanz bereitgestellt werden (siehe Abbildung 13). Wenn das Projekt für die Zielinstanz bereitgestellt wird, erkennt das Bereitstellungsmodul, dass die Datenbank erstellt werden muss, und die Inhalte des Projekts werden in der richtigen Abhängigkeitsreihenfolge erstellt.

Abbildung 13 Bereitstellen des CustomTypes-Projekts

------ Build started: Project: CustomTypes, Configuration: Debug Any CPU ------
CustomTypes -> D:\Demos\Database1\CustomTypes\bin\Debug\SqlClassLibrary.dll
------ Build started: Project: Database1, Configuration: Debug Any CPU ------
    Loading project references...
    Loading project files...
    Building the project model and resolving object interdependencies...
    Validating the project model...
    Writing model to Database1.dbschema...
  Database1 -> D:\Demos\Database1\Database1\sql\debug\Database1.dbschema
------ Skipped Deploy: Project: CustomTypes, Configuration: Debug Any CPU ------
Project not selected to build for this solution configuration 
------ Deploy started: Project: Database1, Configuration: Debug Any CPU ------
    Deployment script generated to:
D:\Demos\Database1\Database1\sql\debug\Database1.sql

    Creating Database1...
    Creating CustomTypes...
    Creating dbo.Type1...
    Creating dbo.Table1...
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Deploy: 1 succeeded, 0 failed, 1 skipped ==========

Verbesserungen der statischen Codeanalyse

Vor der Veröffentlichung der GDR war die statische Codeanalyse über ein Power Tool verfügbar. Die GDR hat die statische Codeanalyse integriert und bietet eine Reihe von Veränderungen am SCA-Modul (Static Code Analysis), die eine flexiblere Ausführung des Tools ermöglichen.

SCA kann jetzt als Teil eines Builds oder über die Befehlszeile mittels MSBuild ausgeführt werden. Um durchzusetzen, dass SCA mit jedem Build ausgeführt wird, aktivieren Sie die Option „Codeanalyse aktivieren“ im Abschnitt „Codeanalyse“ der Projekteigenschaften. Jede Regel oder Regelgruppe kann als Warnung (Standardeinstellung) oder Fehler behandelt werden. SCA-Regeln, die Fehler in Ihrem Projekt feststellen, können dazu führen, dass der Build fehlschlägt und die Bereitstellung unterbrochen wird. SCA-Warnungen und -Fehler können jetzt auch auf der Regel- und Dateiebene unterdrückt werden.

Um eine Regel zu unterdrücken, klicken Sie mit der rechten Maustaste auf eine SCA-Warnung oder einen SCA-Fehler in der Fehlerliste, und wählen Sie die Option „Suppress Static Code Analysis Message(s)“ (SCA-Meldungen unterdrücken) aus. Regeln, die unterdrückt wurden, werden der Datei „StaticCodeAnalysis.SupressMessages.xml“ im Stamm des Projektsystems hinzugefügt. Um unterdrückte Regeln einzubeziehen, löschen Sie die Datei aus dem Projekt, oder entfernen Sie spezifische Regel- und Dateikombinationen aus der Datei. Abbildung 14 zeigt den Abschnitt „Codeanalyse“ des Projekteigenschaftenfensters mit den neuen Optionen.

Abbildung 14 Optionen für die statische Codeanalyse

SCA kann als Teil des Builds eines Datenbankprojekts aktiviert werden. Wenn SCA aktiviert wurde, wird es als Teil jedes Projektbuilds ausgeführt und könnte dazu führen, dass der Build fehlschlägt, wenn SCA Fehler erkennt. Dies gilt auch für Builds, die mittels MSBuild über die Befehlszeile gestartet werden. Die GDR bietet außerdem ein SCA-MSBuild-Ziel (StaticCodeAnalysis), das ermöglicht, dass SCA unabhängig von der Option „Enable SCA For Build“ (SCA für Builderstellung aktivieren) ausgeführt wird.

SCA kann pro Projekt konfiguriert werden, d. h., dass für jede Konfiguration oder Umgebung ein anderer Satz von Regel- und Fehleroptionen definiert werden kann. Wird SCA über die Befehlszeile ausgeführt, wird eine Ergebnisdatei namens „StaticCodeAnalysis.Results.xml“ erstellt. Diese Datei wird in das Verzeichnis geschrieben, von dem MSBuild aufgerufen wird. Der Dateiname und Speicherort der Ergebnisse können durch ein Überschreiben der ResultsFile-Eigenschaft außer Kraft gesetzt werden.

Um SCA mittels MSBuild über die Befehlszeile auszuführen, verwenden Sie den folgenden Befehl:

msbuild MyDatabase.dbproj /t:StaticCodeAnalysis

Abbildung 15 zeigt ein Beispiel für die erstellte SCA-Ergebnisdatei.

Abbildung 15 Beispiel für eine SCA-Ergebnisdatei

<?xml version="1.0" encoding="utf-8" ?> 
<Problems>
<Problems>
      <Rule>Microsoft.Design#SR0001</Rule> 
    <ProblemDescription>The shape of the result set produced by a SELECT 
    * statement will change if the underlying table or view structure 
    changes.</ProblemDescription> 
<SourceFile>C:\USERS\XXXX\DOCUMENTS\VISUAL STUDIO 2008\PROJECTS\ \
MYDATABASE\MYDATABASE\SCHEMA OBJECTS\SCHEMAS\DBO\PROGRAMMABILITY\STORED 
PROCEDURES\MYSTOREDPROC.PROC.SQL</SourceFile> 
  <Line>6</Line> 
  <Column>8</Column> 
  <Severity>Warning</Severity> 
  </Problems>
</Problems>

Tipps und Tricks

Es gibt einige andere Änderungen, die GDR mit sich bringt, auf die abschließend noch hingewiesen werden soll.

Mit der GDR können Sie jetzt ein Objekt von einem Schema zu einem anderem verschieben. Außerdem bietet GDR die Möglichkeit, Umgestaltungsänderungen beizubehalten und das geeignete T-SQL auszusenden, um diese Änderungen während der Bereitstellung in Bezug auf den Zielserver vorzunehmen. Wenn Sie zum Beispiel eine Tabelle umbenennen, wird während der nächsten Bereitstellung ein sp_rename ausgegeben, statt die Tabelle wegzulassen und neu zu erstellen.

Die Dateitypen, auf die verwiesen werden kann, sind durch ein Datenbankprojekt erweitert worden. In der GDR kann ein Verweis auf die folgenden Dateitypen erstellt werden:

Projekte
.dbschema-Dateien
.dll (SQL CLR-Unterstützung)
.xsd (XSD)

Bei einem Datenbankprojekt oder einem .dbschema-Dateiverweis verweist das Projekt logisch auf eine andere Datenbank. Wenn der Verweis keinen drei- oder vierteiligen Namen hat, wird er als Verweis auf ein „zusammengesetztes“ Projekt angesehen. Zusammengesetzte Projekte sind ein neues Feature, das ermöglicht, dass eine Datenbank für die Entwicklung logisch in mehrere Projekte aufgeteilt wird (die Absicht war, das Datenbankschema entlang der Sicherheits- oder Organisationsgrenzen aufzuteilen), die dann manuell in der richtigen Reihenfolge bereitgestellt werden. Zusammengesetzte Projekte werden nur für Verweise von Datenbank zu Datenbank, nicht für Verweise von einer Datenbank auf einen Server oder von Server zu Server unterstützt. Im Fall eines Verweises von einer Datenbank auf einen Server enthält der Verweis das Literal „master“.

Wie weiter oben erwähnt, handelt es sich bei Verweisen auf SQL CLR-Projekte sowie .dll- und .xsd-Dateien um Verweise, die das Objekt, auf das verwiesen wird, in die Datenbank einbeziehen, damit es vom übrigen Quellcode verwendet werden kann. Die Objekte, auf die verwiesen wird, werden im Rahmen der Bereitstellung des Datenbankprojekts bereitgestellt.

In der GDR wurde die Seite für die Bereitstellungseigenschaften neu bearbeitet, um eine einfache Angabe dahingehend zu ermöglichen, ob die Einstellungen in der Projektdatei (.dbproj) oder in der Benutzereinstellungsdatei (.user) gespeichert werden sollen. In Abbildung 16 wird ein Beispiel gezeigt.

Abbildung 16 Sandbox-Konfigurationseinstellungen

Mit dieser neuen Eigenschaftenseite können Sie angeben, wo die Einstellungen gespeichert werden. Standardmäßig werden die Verbindungszeichenfolgen und die übrige Bereitstellungskonfiguration in der Projektdatei gespeichert und für alle Teammitglieder freigegeben. Wenn die Einstellung in der Dropdownliste in „My Isolated Development Environment“ (Isolierte Entwicklungsumgebung) geändert wird, werden die Einstellungen unter „Einstellungen für die Zieldatenbank“ in der .user-Datei gespeichert.

Der Datenbankkomponententest wurde für die GDR nur geringfügig geändert. Eine Änderung wurde hinzugefügt, um die testgesteuerte Entwicklung besser zu unterstützten, bei der bei jeder Testausführung ein Datenbankprojekt bereitgestellt wird. Die neue Aufteilung zwischen der Build und Bereitstellung hat zu Leistungseinbußen bei der testgesteuerten Entwicklung geführt, weil das Datenbankprojekt tatsächlich jedes Mal, wenn Tests ausgeführt wurden, bereitgestellt wurde. (Dies war in früheren Veröffentlichungen, bei denen ein Bereitstellungsskript abgebrochen wurde, wenn es bereits ausgeführt worden war, nicht der Fall.)

Da die meisten Entwickler eine Sandboxdatenbank für Komponententests verwenden und diese Sandbox nur über Testläufe aktualisieren, wurde eine Einstellung hinzugefügt, bei der die Bereitstellung des Datenbankprojekts nur ausgeführt wird, wenn die .dbschema-Datei für das Projekt aktueller als das .sql-Skript ist. Um diese Einstellung zu aktivieren, ändern Sie die app.config-Datei des Testprojekts wie folgt:

<DatabaseDeployment 
 DatabaseProjectFileName="..\..\..\Database1\Database1.dbproj"
 Configuration="Debug" ForceDeployment="false"/>

Um zu erkennen, ob die Bereitstellung ausgeführt werden muss, und um sie von der Bereitstellung für andere Computern zu unterscheiden, erhält das Bereitstellungsskript den Namen der Sandboxdatenbank. Zum Beispiel wurde die vorliegende Sandboxdatenbank „Database1Sandbox“ genannt, und das Bereitstellungsskript heißt deshalb „UnitTestDeployment_Database1Sandbox.sql“. Wie zuvor erläutert, sollte diese Einstellung nicht verwendet werden, wenn das Sandbox-Datenbankschema auf andere Weise als durch Komponententestausführung geändert wurde.

Die Erweiterbarkeit wurde in GDR ebenfalls aktualisiert, um eine Möglichkeit für Erweiterungen zu bieten, die auf verschiedene Datenbankanbieter abzielen. Um eine Klasse als Erweiterung zu definieren, die auf einen besonderen Anbieter abzielt, müssen Sie sie mit dem DatabaseSchemaProviderCompatibilityAttribute ausstatten. Für einen Datengenerator, der auf alle SQL-Versionen abzielt, sieht dies folgendermaßen aus:

[DatabaseSchemaProviderCompatibility(typeof(SqlDatabaseSchemaProvider))]

Noch umfassen Komponententests nicht das Konzept eines Zieldatenbankanbieters, und alle vorhandenen Testbedingungen sind anbieterunabhängig. Um eine neue Testbedingung zu definieren, fügen Sie die folgenden Attribute hinzu:

[DatabaseSchemaProviderCompatibility(DspCompatibilityCategory.Any)]
[DatabaseSchemaProviderCompatibility(DspCompatibilityCategory.None)]

Diese Attribute zeigen an, dass diese Testbedingung gültig ist, wenn kein Datenbankschemaanbieter vorhanden ist, und die Testbedingung ist auch für alle Datenbankschemaanbieter gültig.

Jamie Laflen ist ein technischer Leiter im DBPro-Team. Er ist verantwortlich für Komponententests, Datengenerierung sowie Build- und Bereitstellungsfeatures. Bevor Jamie Laflen zum Entwicklungsteams stieß, arbeitete er für Microsoft Services und half Kunden beim Implementieren von .NET-Anwendungen innerhalb von Visual Studio.

Barclay Hill ist Programmmanager und neues Mitglied des DBPro-Teams. Zuvor hat er jahrelang die Bemühungen zur Entwicklung von Unternehmensdatenbankanwendungen in zahlreichen Branchen geleitet.

Freigeben über

Zusätzliche Ressourcen