Automatisierte Bereitstellung von gemischten SSIS/DLL-Lösung

Question

Wir haben derzeit eine Lösung mit SSIS/C# entwickelt. Das SSIS-Paket hat (unter anderem) eine Skriptaufgabe, die Logik verwendet, die in den Klassenbibliotheken entwickelt wurde. Diese Funktionalität muss getrennt vom SSIS-Paket bleiben.

Da wir ein SSIS-Paket verwenden, verstehe ich, dass die kompilierten DLLs im GAC bereitgestellt und dann von der Skriptaufgabe referenziert werden müssen. Dies führt jedoch zu einem Bereitstellungsproblem für uns.

Unser automatisiertes Deployment-Tool erhöht (zu Recht) automatisch die Versionsnummern der DLLs, die dann im GAC veröffentlicht werden. Dies bricht jedoch das SSIS-Paket, da es versuchen wird, auf die DLLs zuzugreifen, die auf der Versionsnummer basieren, auf der sie auf dem Entwicklungscomputer GAC veröffentlicht wurden.

Die einzige Lösung, die wir haben, ist, die kompilierten DLLs zu erhalten, den SSIS-Paket-Skript-Task manuell zu ändern und dann das Paket zu veröffentlichen.

Es scheint so, als müsste es einen besseren Weg geben - ist jemand auf dieses Problem gestoßen und hat eine bessere Lösung gefunden? Oder gibt es etwas Grundlegendes in unserem Ansatz, das wir ändern müssen (abgesehen davon, dass die DLLs nicht mehr benötigt werden)?

Danke!

Answer 1

Nun, nach vielen Recherchen habe ich nie wirklich eine zufriedenstellende Lösung dafür gefunden. Am Ende könnte die nächste, die ich eine Lösung erhalten war, wo ich meine Referenzen dynamisch geladen:

Dim rsAssembly As Assembly = Assembly.LoadFile("path from config file") 
    Dim rsType As Type = rsAssembly.GetType("class name from config file") 
    Dim obj As Object = Activator.CreateInstance(rsType) 

Das erlaubte mir, das Objekt zu erstellen I erforderlich (obwohl erwähnenswert, dass andere oder dynamisch laden auch abhängig Referenzen müssen durch Teil des GAC, obwohl zumindest ohne die Abhängigkeit von der Versionsnummer).

Geschrieben hier für zukünftige Suchende, aber wenn jemand mit etwas kommt, besser würde ich immer noch sehr gespannt sein, zu wissen, wie Sie es gelöst - Post hier, und ich werde Sie die Antwort zu :)

Answer 2

Sind Sie absolut sicher, dass die freigegebenen DLLs im GAC bereitgestellt werden müssen? Wenn sie sich im selben Ordner wie das SSIS-Paket befinden, sollten sie für das Framework erkennbar sein, ohne dass sie dem GAC hinzugefügt werden müssen.

Gibt es keine Möglichkeit, Ihr Build-System zu aktualisieren, um die Änderung der Versionsnummer zu vermeiden? Wenn sich der Code dieser Assemblys nicht ändert, muss die Versionsnummer nicht aktualisiert werden. Wenn Sie das Versionsinkrement nicht vermeiden können, besteht die andere Alternative darin, eine Richtliniendatei zusammen mit den freigegebenen Assemblys zu erstellen und diese zu verwenden, um das SSIS-Paket bei jedem Build an die neue Version "umzuleiten".

Answer 3

ich bemerkt habe ähnliche Probleme mit unserem SSIS/C# -Mix. Wir sind auch auf eine externe (zu SSIS) DLL angewiesen. In unserem Fall musste die DLL in das Verzeichnis 100/DTS/Binn kopiert werden, damit das SSIS-Paket in Visual Studio funktioniert. Wenn wir jedoch versuchen, das Paket mit dem SQL Package Execution Utility auszuführen, erhalten wir einen Fehler Die Datei konnte nicht gefunden werden. Es scheint nicht so sehr auf ein Versions-Problem hinzuweisen, als auf einen Unterschied in PATH zwischen Visual Studio und dem Paket-Ausführungsprogramm. Sogar das Ausführen des Pakets ohne Debug von Visual Studio funktioniert. Ich werde in das Versions-Problem schauen, um zu sehen, ob das vielleicht die Hauptbeschwerde auf unserem System ist, aber aus dem Speicher denke ich, dass es ein Datei-nicht-gefunden-Typ-Fehler war, der uns beeinflusst hat. Wir verwenden MSSQL 2008, wenn das einen Unterschied macht.