SQL-Adapter beim Update zerschossen

[Thisoft]

@apollon77 sagte in SQL-Adapter beim Update zerschossen:

Sorry, absoluter Müll! Die Version 1.9.4 ist von Anfang März und 1521 mal installiert ... also liegt es gaaaanz bestimmt an dieser Version und an den Open-Source-Entwicklern ... WTF ... Sorry, aber Bullshit. Solche Kommentare nerven ungemein. ja ich habe gelesen was Du weiter unten geschrieben hast, dennoch ...

Ich weiß selber aus Erfahrung dass solche "Verallgemeinerungen" ungemein nerven können. Sorry wenn ich da schief rüberkam, ich hab aber auch nirgends behauptet dass das an den Entwicklern liegt...

Ich weiß dass die Version von Anfang März ist, eben deshalb fand ich jetzt dass es mal Zeit wäre upzudaten

"npm rebuild" hab ich nach jeder Node-Neuinstallation gemacht. Das Node-Upgrade hab ich übrigens gemacht weil Homoran oben meinte dass die 8er-Version ein Speicherleck hätte...

Mit den Windows-Build-Tools hab ich mich auch schon beschäftigt. Die sind mit Sicherheit hier der Kern des Übels. Ich hab die auch gleich nach dem ersten Fehlschlag mit "npm install --global windows-build-tools" upgedated - dachte ich zumindest. Leider verweist da wohl irgendwo irgendwas irgendwie auf die falsche Version. Zwischendurch stand mal in der Konsole dass er die "V141" sucht und diese aber in einem Pfad namens "...\V140" nicht finden kann - verständlich.
Die V141 sind lt. Google die MSBuildTools 2017, diese waren aber bereits installiert und ich hab das alles auch nochmal neu installiert, zwischendurch die 2015er Version auch mal runtergeworfen...
Hat bis jetzt alles nichts geholfen:-( Von der Warte bin ich eben mittlerweile auch so bisschen an dem Punkt wo ich das nur noch als nervigen Bullshit finde - ich hoffe das ist auch ein wenig verständlich...

Wie auch immer - irgendwie muss ich durch - ich plage mich mal weiter mit den Build-Tools herum...

[apollon77]

Hey,

alles gut.

Naja hättest auf in der 8er Linie updazen können - denke das meinte Homoran eher Alles unter 8.15 hatte nen memory-leak, aber alles danach nicht mehr. Also ein Update auf 8.15 hätte gereicht, aber jetzt bist Du denke einige Schritte weiter.

Das das mit den Build Tools nervt kann ich verstehen, da bin ich dann aber leider kein Windows-User der da viel helfen könnte Vllt mal über Windows-Einstellungen MS VS xx Pakete deinstallieren falls die da drin gelistet sind
Danach dann über die windows-build-tools neu installieren ?!
Drücke die Daumen das Du es hinbekommst

[Jeeper.at]

@Jeeper-at Und wenn es mit einer Version bekannterweise Probleme gibt ... wo ist das GitHub issue?

Was ein GIT Issue bringt sehe ich ja am Plumb. Der ist sei Monaten offen. Ach ja, der ist ja nur auf Platz 246 der Wichtigkeitskala.

Ich kann nur sagen, das nach dem Upgrade der SQL nicht mehr funktioniert hat. Und zwar genauso wie der TE geschrieben hat. Ob du das jetzt Müll findest bleibt dir überlassen.

[apollon77]

@Jeeper-at Habs ja fast geahnt das das Deine Antwort ist. Äpfel und Birnen ...

Fakten zu "nach dem Update tut es nicht mehr" stehen oben, wenn Du dazu etwas neues beizutragen hast dann jederzeit gern. Ich persönlich habe sql unter node 8 und 10 unter Linux laufen ohne Probleme und das automatische Adapter-Testing läuft mit MSVS2015 ebenfalls problemlos mit nodejs 10. Probleme, siehe oben, sind momentan nur bekannt unter Windows und mit nodejs 10 und MSVS <2015.

[Thisoft]

So - mal wieder ein kleines Update - hatte die Feiertage nicht wirklich Zeit für diese Baustelle...

Ich habe:
-erstmal alle (also ALLE) MS C++ Redistributables deinstalliert
-dann mal Reboot und alles nochmal gecheckt ob's weg ist
-dann ein "npm install --global windows-build-Tools"; damit hab ich die 2017er Version bekommen
-wieder ein Reboot
-nochmal zur Sicherheit "npm rebuild" (weiß nicht ob das nötig war - dieses ständige Neukompilierungskonzept von Linux hab ich noch nicht wirklich verstanden...)
-dann neuer Versuch; wieder erfolglos allerdings mit etwas anderen Fehlermeldungen:

C:\ioBroker>iobroker install sql@latest --production

C:\ioBroker>node node_modules/iobroker.js-controller/iobroker.js install sql@latest --production
NPM version: 6.4.1
npm install iobroker.sql@latest --production --save --prefix "C:/ioBroker" (System call)
npm WARN deprecated sprintf@0.1.5: The sprintf package is deprecated in favor of sprintf-js.
npm WARN deprecated core-js@1.2.7: core-js@<2.6.5 is no longer maintained. Please, upgrade to core-js@3 or at least to actual version of core-js@2.
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:189:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Windows_NT 10.0.17134
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\ioBroker\node_modules\iobroker.sql\node_modules\mmmagic
gyp ERR! node -v v10.15.3
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! mmmagic@0.5.2 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the mmmagic@0.5.2 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\Thilo\AppData\Roaming\npm-cache\_logs\2019-04-23T07_25_53_799Z-debug.log
host.Acer2 Adapter directory "null" does not exists
Cannot parse null/io-package.json:Error: ENOENT: no such file or directory, open 'null/io-package.json'``

Kann mir bitte jemand helfen, was ich jetzt gegen diesen node-gyp-Error 1 und ELIFECYCLE tun müsste?

Verzweifelte Grüße
Thilo

[apollon77]

Hey, das ist Mist

Der "Neukompilierungskram von Linux" hat in dem Fall nichts mit Linux zu tun. Es geht simpel um Performance. Einige nodejs Module haben "binäre" teile die nicht in Javascript geschrieben sind sondern in C/C++, meistens wegen performance oder weil man nur so System-Libs nutzen kann. Das kann man zum Teil "vorkompilieren" und laden aber einige hängt auch von anderen lokalen Libraries auf dem Zielsystem ab. Damit bleibt nur der Weg diese binären Teile bei der Installation zu kompilieren. Und das ist das was hier passiert. Also nix Linux Auch Windows ...

Am besten probier das doch mal getrennt von iobroker aus ... Leg ein verzeichnis an egal wo und öffne shell dahin. Dann

"npm install mmmagic@0.5.2 --production"

Dann sollte der gleiche Fehler kommen. Dann aber mal das Logfile was da angegeben wird posten, vllt ist da ja was hilfreiches drin

[Thisoft]

@apollon77
Also --- der Fehler bleibt der Gleiche, egal wohin ich mmmagic versuche zu installieren.
Was lt. Log IMO das Problem sein dürfte:

Der Buildvorgang wurde am 23.04.2019 18:06:37 gestartet.
Projekt "C:\ioBroker\node_modules\mmmagic\build\binding.sln" auf Knoten "1" (Standardziele).
ValidateSolutionConfiguration:
  Die Projektmappenkonfiguration "Release|x64" wird erstellt.
Das Projekt "C:\ioBroker\node_modules\mmmagic\build\binding.sln" (1) erstellt "C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj" (2) auf Knoten "1" (Standardziele).
C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj(20,3): error MSB4019: Das importierte Projekt "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Cpp.Default.props" wurde nicht gefunden. Vergewissern Sie sich, dass der Pfad in der <Import>-Deklaration korrekt und die Datei auf dem Datentr„ger vorhanden ist.
Die Erstellung des Projekts "C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj" ist abgeschlossen (Standardziele) -- FEHLER.
Die Erstellung des Projekts "C:\ioBroker\node_modules\mmmagic\build\binding.sln" ist abgeschlossen (Standardziele) -- FEHLER.

Fehler beim Buildvorgang.

"C:\ioBroker\node_modules\mmmagic\build\binding.sln" (Standardziel) (1) ->
"C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj" (Standardziel) (2) ->
  C:\ioBroker\node_modules\mmmagic\build\deps\libmagic\libmagic.vcxproj(20,3): error MSB4019: Das importierte Projekt "C:\Program Files (x86)\MSBuild\14.0\Microsoft.Cpp.Default.props" wurde nicht gefunden. Vergewissern Sie sich, dass der Pfad in der <Import>-Deklaration korrekt und die Datei auf dem Datentr„ger vorhanden ist.

    0 Warnung(en)
    1 Fehler

Irgendwie kann ich auch nichts finden dass während der Installation überhaupt der Ordner "..\mmmagic" erstellt würde geschweige denn irgendwelcher Inhalt... Schreibrechte hab ich aber, kann den Ordner aus der Konsole heraus anlegen...

Wäre das ein Ansatzpunkt?

[apollon77]

@Thisoft sagte in SQL-Adapter beim Update zerschossen:

"C:\Program Files (x86)\MSBuild\14.0\Microsoft.Cpp.Default.props" wurde nicht gefunden

Ich habe mal etwas gegoogelt, vllt ist ja hier was drin:

https://stackoverflow.com/questions/16092169/why-does-msbuild-look-in-c-for-microsoft-cpp-default-props-instead-of-c-progr
https://stackoverflow.com/questions/49327432/microsoft-cpp-default-props-not-found-when-running-npm-install
https://stackoverflow.com/questions/41695251/c-microsoft-cpp-default-props-was-not-found

[Thisoft]

@apollon77

Hurra - er läuft wieder

Deine Links waren zwar noch nicht die eigentliche Lösung aber der richtige Weg. Die Systemvariable "VCTargetsPath" war falsch. Allerdings waren alle Pfade die in den Links angegeben waren auch falsch. Ich habe dann auf meiner Platte erstmal nach Dateien namens "Microsoft.cpp" gesucht. Die liegen bei mir seltsamerweise in einem völlig anderen Pfad als überall von Dr.Google ausgespuckt wird... Kann sein, dass sich der Pfad mit der 2017er Version geändert hat, dass dann allerdings die entsprechenden Umgebungsvariablen nicht richtig gesetzt werden ist wohl entweder eine unglückliche Konstellation auf meinem Rechner oder ein Bug von Windows.

Jedenfalls habe ich dann die beiden Umgebungsvariablen wie folgt gesetzt:

C:\ioBroker>set VCTargetsPath=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets

C:\ioBroker>set VS140COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\Tools

und dann lief die Installation des Adapters fehlerfrei durch Juhu - nach einer Woche endlich wieder geloggte Daten...

[apollon77]

@Thisoft Cool gratuliere!

@Jeeper-at Vllt willst Du es auch mal so versuchen? Oder hast Du kein Windows und ein anderes Problem?