Nachdem es immer wieder verschiedene Fragen zu der Installation von Custom Components gibt, möchte ich in diesem Blogeintrag noch einmal kurz erklären wo SSIS Komponenten installiert werden und was die wesentlichen Unterschiede zwischen x86 und x64 sowie dem Business Intelligence Development Studio (BIDS) und den SQL Server Data Tools (SSDT) sind und was beim GAC beachtet werden muss.

Die Verzeichnisse

Die Integration Services greifen auf Tasks und Komponenten über oder an zwei verschiedenen Stellen zu. Zum einen während der Entwicklung über das BIDS bzw. die SSDT, zum anderen während des Debugging bzw. während Betriebs.

Während der Entwicklung wird auf das DTS Verzeichnis innerhalb des Microsoft SQL Server Installationsverzeichnis zugegriffen, welches standardmäßig hier zu finden ist:

SQL Server 2008 – x86-System
C:\Program Files\Microsoft SQL Server\100\DTS

SQL Server 2008 – x64-System:
C:\Program Files (x86)\Microsoft SQL Server\100\DTS

SQL Server 2012 – x86-System
C:\Program Files\Microsoft SQL Server\110\DTS

SQL Server 2012 – x64-System
C:\Program Files (x86)\Microsoft SQL Server\110\DTS

In diesem Verzeichnis befinden sich die jeweiligen verschiedenen Unterverzechnisse für Tasks, PipelineComponents usw. Da sowohl das BIDS wie auch die SSDT nur als 32-Bit Applikation zur Verfügung steht, wird hier auch immer auf das x86 Installationsverzeichnis des SQL Server zugegriffen. Das bedeutet auch, das während der Entwicklung alle Tasks und Komponenten grundsätzlich im 32-Bit-Modus verwendet werden.

Während des Debugging wird auf die jeweilige Komponente oder den Task über den GAC (Global Assembly Cache) zugegriffen. Der GAC ist je .NET Framework an zwei unterschiedlichen Stellen zu finden:

Bis .NET Framework 3.5:
C:\Windows\assembly

Ab .NET Framework 4.0:
C:\Windows\Microsoft.NET\assembly

Da erst mit dem SQL Server 2012 auch Komponenten und Tasks verwendet werden können die das .NET Framework 4.0 verwenden, spielt die zweite Pfadangabe auch nur dort eine Rolle.

Installation im BIDS

Im BIDS müssen Custom Components manuell hinzugefügt werden. Hierfür muss man mit der rechten Maustaste in die Toolbox klicken und aus dem Kontextmenü den Punkt Choose Items auswählen. Im folgenden Dialog können die Tasks dann über die Registerkarte SSIS Control Flow Items bzw. die Komponenten über die Registerkarte SSIS Data Flow Items ausgewählt werden. Tasks und Komponenten werden danach automatisch der Toolbox hinzugefügt und können dann manuell in die einzelnen Kategorien verschoben werden.

Installation in SSDT

Mit SQL Server 2012 wurde die neue SSIS Toolbox eingeführt, die Komponenten und Tasks in dem Microsoft Installationsverzeichnis automatisch erkennt. Verwirrend hier ist manchmal, dass neue Komponenten nach der Installation nicht immer in der richtigen Untergruppe wie z.B. Other Sources oder Other Destinations landen; in den meisten Fällen sind neue Komponenten in der Untergruppe Other Transformations zu finden. Über das Kontextmenü können die Komponenten aber mit dem Menüpunkt Move to Other … in die richtige Gruppe verschoben werden. Ein manuelles Verschieben von Tasks und Komponenten per Drag and Drop ist in der SSIS Toolbox nicht mehr möglich.

Unterschiede x86 und x64

Ein wesentlicher Unterschied, der eigentlich nicht direkt an der Installation einer Komponente hängt, ist das Verhalten zwischen x86 und x64. Wie oben beschrieben, sind BIDS und SSDT reine 32-Bit Produkte und greifen somit auch nur auf die 32-Bit Version einer Komponente zu. Wird nun der Debugmodus gestartet, wird auf die Komponenten aus dem GAC zugegriffen und zwar mit den in den Configuration Properties definierten Einstellungen aus der Seite Debugging. Hier wird bei den Debug Options über den Punkt Run64BitRuntime definiert ob die x64 oder x86 Runtime verwendet werden soll.

Steht nun eine Komponente nur als 32-Bit Version zur Verfüung, wie standardmäßig die Excel Source, so funktioniert zwar die Konfiguration im BIDS/SSDT (x86) einwandfrei, beim Starten des Debugging tauchen jedoch dann die Probleme durch den Wechsel in den 64-Bit Modus auf. Abhilfe schafft man hier indem die Run64BitRuntime Einstellung auf False gesetzt wird.

Auch beim späteren Betrieb können die Pakete auf einem x64 Server im 32-Bit Modus ausgeführt werden. Auch für die Ausführung über die Konsole existiert im Binn Unterverzeichnis des x86 Installationsverzeichnisses von SQL Server eine entsprechende 32-Bit Version des Tools dtexec.

Global Assembly Cache

Die Unterschiede beim GAC liegen im wesentlichen in der Verwendung des jeweiligen .NET Frameworks mit dem die Komponenten kompiliert worden sind.

Nur beim SQL Server 2012 sind mit dem .NET Framework 4.0 kompilierte Komponenten im “neuen” GAC Verzeichnis zu finden. Dies betrifft z.B. meinen ReportGeneratorTask, der für SQL Server 2008 mit dem .NET Framework 3.5 kompiliert wurde und somit unter

c.\Windows\assembly

zu finden ist, für den SQL Server 2012 jedoch mit dem .NET Framework 4.0 kompiliert wurde und somit im Verzeichnis

C:\Windows\Microsoft.NET\assembly\

bzw. genauer im Verzeichnis

C:\Windows\Microsoft.NET\assembly\GAC_MSIL\SSISComponents.DTS.Tasks.ReportGeneratorTask

zu finden ist.

Ein weiterer wichtiger Punkt in Bezug auf den Scripting Task bzw. die Script Komponente ist zusammen mit dem GAC noch zu berücksichtigen. Wird innerhalb des Scripts eine externe Assembly referenziert, so kann man während der Programmierung des Scripts wunderbar auf die Assembly zugreifen. Für das Debugging muss diese Assembly jedoch wieder im GAC zur Verfügung stehen. Assemblies können dem GAC mit

gacutil –i <ASSEMBLYNAME>

hinzugefügt werden. Es empfiehlt sich den Aufruf aus dem Verzeichnis der Assembly zu starten, alternativ muss der vollständige Pfad mit angegeben werden. Enthält dieser Leerzeichen ist der Pfad inkl. Assembly Name in Anführungszeichen zu setzen. Es können jedoch nur Assemblies dem GAC hinzugefügt werden, die über einen Strong Name verfügen.

Worauf ist noch zu achten?

Beim Einsatz von Open Source Projekten innerhalb von Scripts ist besonders auf die Punkte GAC und Strong Name zu achten. Neben der eigentlich über das Script referenzierten Assembly die dem GAC hinzugefügt werden muss, müssen auch alle von dieser Assembly referenzierten Projekte innerhalb des GAC zur Verfügung stehen. Dies kann unter umständen bedeuten, das man sich die Sourcen weiterer Projekte besorgen und mit einem Strong Name kompilieren muss. Normalerweise stellt dies kein größeres Problem dar, jedoch können diese Abhängigkeiten zwischen mehreren Projekten einen größeren Pflegeaufwand für das eigene Paket bedeuten.

Grundsätzlich gilt, die während der Entwicklung verwendeten Komponenten oder Assemblies müssen auch alle auf dem Ziel-Server installiert bzw. dem GAC hinzugefügt werden. Hier muss man sich also bereits während der Entwicklung zwingend Gedanken machen, ob eine Installation von weiteren Produkten auf dem Live-System möglich und erlaubt ist.