OAM-SensorModule: Kompilieren nicht möglich

[willisurf]

Ist das nicht das selbe Skript wie wenn ich den OpenKNXproducer-Task starte? Wenn nicht, welches ist es?

Und völlig unabhängig vom Bauen. Wenn Du nur mal eine knxprod erzeugen möchtest, um die in Deiner ETS6.1 zu testen.
Einfach das Script "Build-knxprod.ps1" aus dem Release ausführen.

[mumpf]

Leider kommt man im ETS-Umfeld nicht einfach mit Try&Error weiter, dazu gibt es zu viele Abhängigkeiten. Deswegen hatte ich versucht, das Ganze in ein Tool (OpenKNXproducer) zu gießen. Das ist der einzige Teil im Tooling bei uns, der ETS abhängig ist (es gibt noch den Kaenx-Creator, der erlaubt die knxprod-Erstellung mit einem UI, aber das ist ein anderer Ansatz).

Also brauchst Du nicht die Entwicklungsumgebung, sondern einen neuen OpenKNXproducer. Und der aktuelle 3.6.2 kann mit der ETS 6.1 umgehen, oder? Ich hab hier keine zum testen, aber das Problem sollte gelöst sein. Wenn Du mit dem aktuellen Sensormodul-Release UND dem aktuellen Producer 3.6.2 keine knxprod bauen kannst, dann schreib mir mal was der Producer meldet, dann muss man da weitersuchen. Dafür brauchst Du nicht das Projekt compilieren.

Unhandled exception. System.IO.IOException: Access to the path '\\?\C:\Users\wolfg\OneDrive\Dokumente\GitHub\Open KNX\OAM-SensorModule\OAM-SensorModule\src\Sensormodul.baggages\A0\11\C0\Ico ns' is denied.

Eine PIO-Entwicklungsumgebung auf OneDrive aufzusetzen kannst Du vergessen. Da werden zig Files generiert, die er versucht im Hintergrund zu syncen. Mit temporären locks. Das ist nur ewig lahm und unzuverlässig. Nimm ein lokales Verzeichnis. Um Stände zu sichern und woanders weiterzuarbeiten gibt es git.

Ich vermute, des Fehler oben war genau so ein temporärer lock. Das Verzeichnis Sensormodul.baggages wird im Gesamtprozess generiert. Da kann es kein Zugriffsproblem geben.

Gruß, Waldemar

[Ing-Dom]

Ich vermute auch OneDrive als Ursache - ich hab zwar nextcloud, aber das macht auch massive Probleme wenn der das versucht zu syncen..

[MAKERWOLF]

Das hab ich auch schon gemutmaßt, und war dann tatsächlich ein wenig enttäuscht, dass das Problem weiterhin besteht.
Ich hab dann aber nochmal einen Schritt zurück gemacht, und mich gewundert, warum das offenbar nur bei mir passiert, und sonst nirgends. Ich hab dann in den Ordnereigenschaften gesehen, dass das hakerl beim Schreibschutz einen strich hat (was auch immer das heisst, bin kein Windows poweruser), das ohne ergebnis entfernt. Letzten Endes hab ich festgestellt, dass der Sensormodul.baggages Ordner im Repo gar nicht existiert, also wohl erst vom Producer erstellt wird. Den nochmal gelöscht und siehe da, jetzt ist das Ding endlich gelaufen

Also lag es wohl tatsächlich am onedrive. Das war beim IP Router noch kein Problem ... der Build ist auch gelaufen!
Danke für eure Hilfe! Hab ich wieder viel dazugelernt!

[traxanos]

der router ist nicht mit normalen oams vergleichbar. da läuft einiges anders, da ein route ebenr keine normale Applikation ist.

[Ing-Dom]

der router ist nicht mit normalen oams vergleichbar.

naja, bzgl der Repostruktur und Producer und Baggages Ordner ist das kein Unterschied..

Aber evtl hat es geholfen dass ich im IP-Router Repo den Ordner Baggages auch gepsuhet hatte..

[MAKERWOLF]

Ach ups, ich hab die zweite Seite übersehen, als ich meinen reply geschrieben hab!

Ja wenn onedrive da temporäre locks reinwirft ergibt das ganze plötzlich sinn. Fun fact: ich hab das nichtmal absichtlich dort hin geschoben, sondern einfach das default verzeichnis vom github desktop verwendet. Das wills in den standard-Dokumente Ordner schieben, und der ist im onedrive.

Na gut, Problem gelöst! Danke euch allen!