none
Warum muss die Componente in den x(86) Verzeichnis-Baum kopiert werden?

    Frage

  • wohin die neue Library kopieren?

    Hallo Zusammen...

    Bei der Installation von SSMS 2017 und der Installation von SSDT  BI 2015 verstehe ich die Welt nicht mehr.

    Lerne gerade wie Komponente für den SSIS erstellt werden , was eigentlich nicht schwer sein sollte. Komme da noch etwas durcheinander, bei der Ordnerauswahl, wohin die neue Library kopiert werden sollte..

    Folgendes ist zum Testen installiert:

    - win 10 (64)

    - SQL-Server 2016 (64bit)

    - VisualStudio 2015 mit SSDT BI

    - SSMS 2017

    Nach der Installation ist der Microsoft SQL Server kram unter

    • C:\Program Files (x86)\Microsoft SQL Server sowie unter
    • C:\Program Files\Microsoft SQL Server diesem Verzeichnis gespeichert.

    Die SQL-Server-Instanze ist natürlich unter C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\DATA
    zu finden.

    Habe eine neue Datasource-Componente entwickelt und in das Verzeichnis
    C:\Program Files\Microsoft SQL Server\130\DTS\PipelineComponents kopiert.

    Die Datasource-Componente mit gacutil entsprechen bereitgestellt.... also alles so wie es in der Dokumentation steht.....

    Leider wurde es mir im SSIS Projekt nicht angezeigt obwohl die Eigenschaft TargetServerVersion = SQL Server 2016 eingestellt wurde!.

    Nach einigen verzweifelten Versuchen habe ich die Datasource -Componente in das Verzeichnis C:\Program Files (x86)\Microsoft SQL Server\130\DTS\PipelineComponents kopiert und dann wurde mir auch die Componente im SSIS Projekt angezeigt.

    Jetzt kann frage ich mich; warum ? Ich arbeite doch mit eine 64bit Version! Und genau das ist mir nicht klar warum diese Componente in den x(86) Verzeichnis-Baum kopiert werden muss?

    Ach eins noch, bevor ich schließ, ja, die Componente funktioniert und speichert auch die Daten in die Datenbank.

    Also nochmals meine Frage: Warum muss diese Componente in den x(86) Verzeichnis-Baum kopiert werden?

    Einer weitere Frage: gibt es eine Dokumentation von Microsoft für die jeweilige Verzeinisstruktur

    • C:\Program Files (x86)\Microsoft SQL Server\
    • C:\Program Files \Microsoft SQL Server\

    die bei der Installation von SSIS2017, "Sql-Server 2016 mit SSIS" und für "VS 2015 SSDT BI "?

    Was mich interessiert ist wer(Installationmedium) was in welchen Ordner installiert!

    Freue mich über jeder Rückmeldung

    DerFrank

    P.S. habe diesen Thread auch in mcseboard gestellt.


    • Bearbeitet SoyFrank_Kress Dienstag, 26. Dezember 2017 12:33 verweis hinzugefügt
    Montag, 25. Dezember 2017 14:24

Antworten

  • Was mich gerade stuzig macht ist das Ergebniss nach dem Aufruf von "DTExec":

    Hallo,

    DTExec.exe liegt nicht im System32 Ordner, also werden die Suchpfad der Reihe nach verwendet, um die Exe zu finden. Bei mir ist als erstes die 64 Bit Version eingetragen und erst als zweites der 32 Bit Ordner, dadurch startet bei mir bei ohne weiteren Angaben die 64 Bit Version von DTExec; bei Dir steht wahrscheinlich als erstes der 32 Bit Ordern; aber das kann man ja ändern.

    Und nochmal, Visual Studio gibt nur als 32 Bit Applikation, es gibt davon keine 64 Bit Variante.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Mittwoch, 27. Dezember 2017 06:31

Alle Antworten

  • SQL-Server und SSIS sind zwei verschiedene Produkte. Über den Taskmanager kann man dann sehen, welche Komponente in 64- oder 32-Bit läuft.
    Und da sieht es bei dir so aus, dass der SQL-Server in 64-Bit und SSIS in 32-Bit installiert ist.
    Solange du nicht mehr als ca. 1,4 GB Hauptspeicher benötigst kommst du mit 32-Bit aus.

    Ggf. sind aber auch beide DTExec's installiert:
    https://www.intertech.com/Blog/running-ssis-packages-in-64-bit/


    • Bearbeitet bfuerchau Montag, 25. Dezember 2017 22:33
    Montag, 25. Dezember 2017 22:33
  • Jetzt kann frage ich mich; warum ? Ich arbeite doch mit eine 64bit Version!

    Hallo Frank,

    das liegt einfach daran, das Visual Studio eine 32 Bit Applikation ist und mit der entwickelst Du ja die SSIS Packages. Welche 32/64 Bit Architektur der SQL Server/SSIS hat, ist hier vorerst egal, das kommt erst zur Laufzeit zum tragen.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Dienstag, 26. Dezember 2017 03:52
  • erst einmal Danke "bfuerchau"!

    Der Link hat zumindestens das Bestätigt, was ich mir selbst zusammen gereimt hatte.
    Die Dienste SQLserver ist ein 64bit version und der SSIS scheint auch eine 64bit Version zu sein, da der Dinst "MsDtsSrvr.exe" aus dem Verzeichnis "C:\Program Files\Microsoft SQL Server\130\DTS\Binn" heraus gestartet wird.

    Was mich gerade stuzig macht ist das Ergebniss nach dem Aufruf von "DTExec":



    hmm... jetzt bin ich wieder verwirrt... was denn nun 32bit oder 64bit... grrr..

    Ich denke ich habe bisher wohl wild umher geschossen und mir keine gedanken gemacht welche referenzen ich für die Componenten-Entwicklung aus welchem verzeichnis holen soll/muss..

    Bisher immer aus dem C:\Programme\Microsoft SQLServer\{SQL_Version}\DTS\PipelineComponents also 64Bit...

    Oh man ist das verwirrend.

    Ich möchte es verstehen aber stehe weiterhin auf dem Schlauch :-(

    Freue mich über weitere Rückmeldungen jeder Art :-)

    FG

    DerFrank

    Dienstag, 26. Dezember 2017 13:26
  • Nun, ich nehme mal an, das Scriptfenster selber ist als 32-Bit gestartet (prüfe mal per Taskmanager).
    In diesem Fall verweist das Verzeichnis System32 automatisch auf SysWOW64!
    D.h., diese Shell kommt nicht in Verdrückung, ein 64-Bit-Programm aufrufen zu wollen.

    Evtl. musst du den Developer Commandprompt explizit als 64-Bit aufrufen.

    Wobei: bei mir hat sich Visual Studio ebenso als 32-Bit-Anwendung installiert.
    Im Windowsmenü gibt es bei mir eine "VS x86 Eingabeaufforderung" und ebenso eine "VS x64 Eingabeaufforderung".
    Drücke mal die Windowstaste und gib als Suchbegriff nur "vs" ein.



    • Bearbeitet bfuerchau Dienstag, 26. Dezember 2017 13:47
    Dienstag, 26. Dezember 2017 13:46
  • Was mich gerade stuzig macht ist das Ergebniss nach dem Aufruf von "DTExec":

    Hallo,

    DTExec.exe liegt nicht im System32 Ordner, also werden die Suchpfad der Reihe nach verwendet, um die Exe zu finden. Bei mir ist als erstes die 64 Bit Version eingetragen und erst als zweites der 32 Bit Ordner, dadurch startet bei mir bei ohne weiteren Angaben die 64 Bit Version von DTExec; bei Dir steht wahrscheinlich als erstes der 32 Bit Ordern; aber das kann man ja ändern.

    Und nochmal, Visual Studio gibt nur als 32 Bit Applikation, es gibt davon keine 64 Bit Variante.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Mittwoch, 27. Dezember 2017 06:31
  • Hallo zusammen...DANKE !!! für die Erklärungen in der Xmas-Zeit ;-)

    Man hat ja sonst keine Zeit sich damit zu befassen ;-) grins...

    Ich bedanke mich dafür bei euch und wünsch eine guten Rutsch ins neue Jahr 2018 :-)

    VG

    DerFrank

    Donnerstag, 28. Dezember 2017 16:24
  • Ups... aber bevor das Jahr zur neige geht, habe ich zu dem Thema noch Fragen.

    Habe beide Komponente unterschiedliche Namen vergeben:

    • Componete_x86 und 
    • Componete_x64

    Meine Componete auf x64 umgestellt (alle Verwiese), dann alles neu erstellt, mit gacutil veröffentlicht und zum schluss die Componete_x64.dll dann in den Ordner C:\Program Files\Microsoft SQL Server\130\DTS\PipelineComponents\ kopiert. Hoffe das das so richtig ist?!...

    Also beide Componeten liegen nun in den jeweiligen Ordner. Hier nun meine Fragen:

    • Warum sehe ich nur die Componete_x86 in meinem SSIS Paket?
    • Wie kann ich meine Componete_x86 auf dem SSIS unter x64 ausführen?

    Es lässt mich einfach nicht in Ruhe..... möchte es noch in diesem Jahr lösen.... :-)

    Würde mich freuen eine Rückmeldung zu bekommen.

    VG

    DerFrank


    • Bearbeitet SoyFrank_Kress Samstag, 30. Dezember 2017 23:44 Tipp-Fehler korrigiert
    Samstag, 30. Dezember 2017 23:40
  • Tja, da ist die .NET-Umgebung ein bisschen vor:
    Dll's und Exe's werden in MSIL (Intermediate Language) gespeichert, sind also ert mal nicht speziell für x86 oder x64 konzipiert.
    Wichtig ist der Aufrufer, also die Top-Exe, in welchem Modus die DLL läuft.
    Denn erst beim Aufruf wird tatsächlich Maschinencode generiert, wobei hier der JIT-Compiler (Just-In-Time) nur die Routinen kompliert, die gerade benötiogt werden.
    Anders sieht es im GAC (Global Assembly Cache) aus, von dem es dann 2 gibt, 1x x86 und 1x x64.
    Beim Kopieren (d.h. Installieren) wird die Komponente dann tatsächlich in Maschinencode kompiliert.

    Nun kommt die Aufruflogik der Anwendung ins Spiel:
    Defaultmäßig wird im Verzeichnis der Exe und im GAC gesucht. Wird nichts gefunden, bricht dei Anwendung mit Fehler ab. Dies kann man mit eigenen LoadAssembly's zur Laufzeit dann aber auch selber bestimmen um so das Standardladeverhalten zu umgehen.

    Die Exe entscheidet daher nun, ob sie in 32-/64-Bit läuft und das steht im Manifest der Exe.
    Steht die CPU auf Any, wird auf 64-Bit-Betriebsystemen in 64-Bit ausgeführt, ansonsten in 32-Bit.
    Ist die CPU fixiert auf 32-Bit, gibts nur 32-Bit, ist sie fixiert auf 64-Bit, läuft sie nur auf 64-Bit-Systemen, auf 32-Bit gibts was auf die Finger.

    Benötigt wird die Unterscheidung um auf Systemressourcen wie Windows-DLL's, COM-Registrierung, ODBC/OLEDB usw. zuzugreifen.
    Je nach Modus wird dazu z.B. der SysWOW64 oder System32 oder in der Registry auch der WOW64Node bemüht. Hat sich z.B. ein COM-Objekt nicht für 32-Bit registriert, ist es auch nicht aufrufbar.

    Nun entscheidet also das SSIS, wie es denn gestartet wird, in welchem Modus deine DLL laufen wird und wo sie gesucht wird. Eine Trennung in 2 Versionen ist nicht erforderlich.
    Vielleicht gibt es ja das SSIS nicht als 64-Bit?
    Das hat mit dem SQL-Server überhaupt nichts zu tun, denn der macht ja den Aufruf nicht.

    Da du nun deine Komponenten mit GACUTIL in den Assembly-Cache gestellt hast, ist eine Kopie in den Anwendungsordner nicht mehr erforderlich, denn sie wird ja dort bereits gefunden.
    Wird sie dort nicht gefunden (Signatur fehlerhaft o.ä.), kannst du GACUTIL vergessen und machst die Kopie.

    Gibt es denn einen techischen Grund, warum deine DLL in 64-Bit laufen muss?

    • Bearbeitet bfuerchau Sonntag, 31. Dezember 2017 16:01
    Sonntag, 31. Dezember 2017 15:54
  • Danke "bfuerchau", dass du mir meine Fragen noch kurz vor Schluss beantworten konntest.

    Also, so wie ich verstanden habe kann ich die Komponente auf Any CPU deployen und brauche mir keine Sorgen um 32/64bit machen, da dies die Exe entscheidet bzw. was in dessen Manifest steht.

    Dann ist die Exe bzw. die ausführende Anwendung die DTExec.exe ?!?

    Dann muss bestimmt die Property "Run64BitRuntime = True" in dem DTSX Packet gesetzt werden ! oder?
    Siehe Screesoot nr.1

    Screen Shoot nr.1

    Du schreibst:

    Das hat mit dem SQL-Server überhaupt nichts zu tun, denn der macht ja den Aufruf nicht.

    ...dann verstehe ich nicht warum:

    • ...muss die Property "TargetServerVersion = SQL Server 2016" ausgewählt werden? (Siehe ScreenShoot 2)
    • ...muss die DLL Komponente unbeding in "C:\Program Files (x86)\Microsoft SQL Server\130\DTS\PipelineComponents\" kopiert werden?
    • ...die Verweise, die in der Libray verwendet werden, aus dem Verzeichnis z.b. C:\Windows\Microsoft.NET\assembly\GAC_MSIL\...xyz...\v4.0_13.0.0.0__89845dcd8080cc91\.... verwendet werden müssen? (Siehe ScreenShoot 3)

    Siehe Screesoot 2:

    TargetServerVersion

    (Siehe ScreenShoot 3)

    Hm... oh ha... ich würde dich (euch allen) nicht fragen, wenn ich wüsste nach was ich im WWW suchen könnte.

    Freue mich auf jede Rückmeldung ;-)

    VG

    DerFrank

    p.s.

    Deine Frage:...

    ...Gibt es denn einen techischen Grund, warum deine DLL in 64-Bit laufen muss?...

    Nein nicht wirklich... es ist meine reine neugier das verstehen zu wollen....


    Dienstag, 2. Januar 2018 12:55
  • Zu DTExec hast du Recht:
    http://help.pragmaticworks.com/dtsxchange/scr/faq%20-%20how%20to%20run%20ssis%20packages%20using%2032bit%20drivers%20on%2064bit%20machine.htm

    Was die Zielversion deines Paketes angeht, so definierst du damit die Minimalversion, die dein Paket unterstützt. Wenn du nicht explizit auf Features des SQL-Servers-2016 angewiesen bist, kannst du bestimmt auch niedrigere Versionen angeben (um z.B. AddOn's auch kommerziell zu vertreiben).

    Und was ist nun SSIS?
    https://docs.microsoft.com/de-de/sql/integration-services/integration-services-ssis-packages

    Im Wesentlichen steuerst du damit Abläufe und Aufgaben, die du u.U. auch genauso als Standalone-Exe's und der Aufgabenplanung durchführen könntest.
    Mit dem SSIS stellst du halt nur sicher, dass der SQL-Server auch läuft (nebst anderen Rahmenbedingungen).

    Vielleicht findest du hier ein paar Erklärungen:
    https://technet.microsoft.com/de-de/library/ms141766%28v=sql.105%29.aspx?f=255&MSPPError=-2147217396

    Was den SQL-Server selber angeht, so kann dieser nur Komponenten aufrufen, die die CLR-Integration betreffen. Dazu gehören Trigger, UDF's, UDT's, und was es da sonst noch so an Erweiterungen gibt.
    Für komplexere UDF's kann sich das durchaus lohnen, da dies u.U. schneller ist, als SQL-UDF's die wohl eher nicht in Maschinencode compiliert werden.

    Dienstag, 2. Januar 2018 16:40
  • Danke "bfuerchau" für die Erklärungen und den links.

    Diese Links hatte ich auch bereits gefunden und durchgelesen. Soweit so gut aber denke so langsam komme ich dahinter....

    Das Thema mit den 32Bit/64bit ist noch etwas verwirrend glaube aber verstanden zu haben wie es funktioniert...

    Nun erfolg hatte ich schon mal, die erst Komponente in SSIS entwickelt und in der SSIS Toolbox gefunden !!

    Wenn also meine Komponente, die in x86 entwickelt wurde, unter x64 ausführe, dann brauch ich nur die "Run64BitRuntime = True" setzen und alles ist gut ?!? ...das verwirt mich zwar etwas aber hmm... ich nehm es mal einfach so hin...

    Dennoch vielen Dank für die Gedult....

    VG

    DerFrank

    Nachtrag zu meinen Fragen:

    ...dann verstehe ich nicht warum:

    1. ...muss die Property "TargetServerVersion = SQL Server 2016" ausgewählt werden? (Siehe ScreenShoot 2)
    2. ...muss die DLL Komponente unbeding in "C:\Program Files (x86)\Microsoft SQL Server\130\DTS\PipelineComponents\" kopiert werden?
    3. ...die Verweise, die in der Libray verwendet werden, aus dem Verzeichnis z.b. C:\Windows\Microsoft.NET\assembly\GAC_MSIL\...xyz...\v4.0_13.0.0.0__89845dcd8080cc91\.... verwendet werden müssen? (Siehe ScreenShoot 3)

    Zu 1.:

    Wie ich soeben festgestellt habe, stellt man die Property TargetServerVersion auf die Serverversion, in der die Komponente bereitgestellt wurde.

    Bsp: Die Komponente wurde in dieses Verzeichnis kopiert: "C:\Program Files (x86)\Microsoft SQL Server\130\DTS\PipelineComponents\", dann ist die Property TargetServerVersion auf 2016 einzustellen.

    Im Fall die Property TargetServerVersion steht auf 2014, so sollte die Komponente in dem Verzeichnis "C:\Program Files (x86)\Microsoft SQL Server\120\DTS\PipelineComponents\" vorhanden sein.

    Zu 2.:

    Ja, sonst wird sie nicht in der SSIS Toolbox angezeigt.

    zu 3.:

    Hier mein Verständnis von GAC_MSIL:

    Da .NET nicht spezifisch für eine "Sprache" steht (d. H. C#, VB.net, etc.) können diese Sprachen zum Schreiben von .NET-Anwendungen verwendet werden. Die CLR interpretiert den echten Code, der in der Microsoft Intermediary Language (MSIL) enthalten ist. In der Tat bedeutet dies, dass wir es in c # schreiben, wird es in MSIL kompiliert und dann von der CLR Just in Time (JIT) ausgeführt, wenn es ausgeführt wird. Daher sind dlls in diesem MSIL-Format im .NET GAC.

    Hier das Original in dem es erklärt wurde :https://forums.asp.net/post/2795538.aspx

    Also denke ich, wenn eine Referenz aus diesen Pfad C:\Windows\Microsoft.NET\assembly\GAC_MSIL\...xyz...\v4.0_13.0.0.0__89845dcd8080cc91\.... verwendet wird, wird der Code auch nur für den SQL-Server Version 2016 kompiliert.

    Hoffe das ich das so richtig interpretiere ;-)

    DerFrank



    Mittwoch, 3. Januar 2018 13:46
  • Der GAC hat mit dem SQL-Server gar nichts zu tun sondern dient nur der .NET-Runtime.
    Über Name, Version und GUID wird im Endeffekt der Gesamtname gebildet.

    Neben GAC_MSIL (ab 4.0) gibts ja auch noch GAC_32/GAC_64 (< 4.0).
    https://stackoverflow.com/questions/2660355/net-4-0-has-a-new-gac-why


    • Bearbeitet bfuerchau Mittwoch, 3. Januar 2018 15:03
    Mittwoch, 3. Januar 2018 15:03