Verwendete Unit 'System.ImageList' kann nicht compiliert werden

[Graf Gustav]

hi,
damit bin ich völlig ratlos.
Die Umstellung von 10.1 auf 10.4. hat für alle Projekte geklappt bis auf eines.
Inzwischen habe ich die Situation: Rechner 1 - Delphi 10.1 und 10.4 (jeweils community version), Rechner 2 - Delphi 10.4
Dieses eine Projekt erzeugt beim Öffnen auf beiden Systemen bei 10.4 diese Meldung (in der .dpr), in 10.1 funktioniert alles.
Die Sourcen sind für alle dieselben auf einem Netzlaufwerk.

Ich habe einiges rumprobiert, aber ohne jeden Erfolg.
Hat jemand eine Idee?

Danke schonmal

[jaenicke]

Zitat:

Zitat von Graf Gustav (Beitrag 1521298)

Die Sourcen sind für alle dieselben auf einem Netzlaufwerk.

Davon abgesehen, dass da ein Versionskontrollsystem sinnvoller wäre (dann wären die lokal erzeugten Dateien jedes Mal sauber von den absichtlich eingecheckten Daten getrennt und du hättest das Problem bei einem sauberen Auschecken vermutlich nicht), dürfte das Problem daran liegen, dass da irgendwelche .dcu Dateien oder so herumliegen, die nicht passen. Da bleibt nur, das Verzeichnis manuell zu säubern.

Du kannst ansonsten nur mit dem Process Monitor sehen, worauf da zugegriffen wird.

[Graf Gustav]

Hallo Sebastian,
danke für die schnelle Antwort, es hat erstaunlicherweise geholfen.
In dem Verzeichnis mit den Sourcen lag tatsächlich eine 'System.ImageList.dcu' von 2016.
Bis 10.1 hat das keine Delphi-Version interessiert, erst 10.4 hat darin einen Sinn gesucht.

Mit dem Hinweis auf ein Versionskontrollsystem hast du die zäheste Lücke meines
Delphi-Entwickler-Lebens getroffen. X mal angegangen, immer wieder versandet.
Als ich noch im Team programmiert habe, gab's so etwas noch nicht, und für einen singulären
Privatentwickler sieht das immer so aufwendig aus.

Also vielen Dank nochmnal
Reinhold

[hoika]

Hallo,
hatte früher auch gedacht (als Single-Entwickler).
Aber allein das "Diff" ist Gold wert ..

[jaenicke]

Zitat:

Zitat von Graf Gustav (Beitrag 1521302)

und für einen singulären Privatentwickler sieht das immer so aufwendig aus.

Das Gegenteil ist der Fall. Alleine schon manuelle Backups und der Alptraum unterschiedlicher Versionsstände, wenn etwas nicht mehr geht...
Ein höherer Aufwand ist es, wenn man kein Versionskontrollsystem nutzt. Denn mit SVN sind das wirklich nur ganz wenige Schritte. Das lässt sich in Minuten einrichten und ist sehr einfach nutzbar:
https://entwickler-ecke.de/topic_Kur..._112612,0.html
Da habe ich wirklich den ganzen Weg mit Screenshots gepflastert. Da kann wirklich nichts schief gehen, wenn du das ausprobieren möchtest. ;-)

[haentschman]

Besser gleich GIT. Das mergen ist besser...8-)
https://entwickler-ecke.de/topic_Kur...it_115462.html

[jaenicke]

Zitat:

Zitat von haentschman (Beitrag 1521322)

Besser gleich GIT. Das mergen ist besser...8-)

Dass Git besser ist, ist schon richtig. Zuerst hatte ich auch überlegt, nur die Anleitung für Git zu schreiben. Allerdings kann bei Git viel leichter etwas schief gehen und viele brauchen die Funktionsvielfalt gar nicht. Deshalb rate ich in Fällen wie diesen, wo es möglichst einfach sein soll und insbesondere nur einer am Quelltext arbeitet, zu SVN.

Da kann man nicht viel falsch machen, muss auch nicht viel dafür lernen, und wenn etwas falsch war, kann man dabei nicht gleich alles kaputt machen. Das ist bei Git leider anders.

[freimatz]

Man muss sich bei git schon anstrengen etwas kaputt zu machen.
Ich halte SVN inzwischen für einen Saurier.
Die Bedienung mit TortoiseSVN/TortoiseGit ist eh nahezu identisch.
Und ja: arbeiten ohne VCS ist ... wie Autofahren ohne Ölwechsel, oder ... geht einfach gar nicht.

[Uwe Raabe]

Ich war ja lange Jahre überzeugter Mercurial-Nutzer und ich betrachte es immer noch als das ideale System für Einsteiger und Dummies (nicht abwertend gemeint), die ein einfach zu bedienendes und unkaputtbares System suchen. Durch die schiere Übermacht von Git kommt man da allerdings nicht mehr drum herum. Es hat eine Weile gebraucht, bis ich einen würdigen Nachfolger für die TortoiseHG Workbench gefunden hatte, der mir den Umstieg auf Git deutlich erleichtert hat: Fork. Mittlerweile arbeite ich nur noch mit Git.

[jaenicke]

Zitat:

Zitat von freimatz (Beitrag 1521326)

Man muss sich bei git schon anstrengen etwas kaputt zu machen.

Das geht sogar sehr einfach:
Vergiss vor dem Pull, dass noch lokale Änderungen da waren, dann bekommst du ggf. einen Konflikt. Wenn du den löst, zeigt dir TortoiseGit einen "Special Commit" an. Wenn du dann denkst, dass du doch die Änderungen gar nicht gemacht hast und welche rausnimmst, machst du leider die vorhergehenden Änderungen kaputt.

Klar, wenn man weiß, was man tut, passiert so etwas nicht, aber ich habe das schon erlebt (einige Wochen nach der Einführung von Git) und habe das dann im Repository korrigiert (es war auch niemand sonst da, der das hätte machen können).

Die Arbeitsanweisung, die ich mir dann überlegt habe, lautete, dass jeder zuerst das Staging nutzt, um lokale Änderungen wegzunehmen, dann pullt und dann die lokalen Änderungen wieder zurück holt. Dann gibt es ggf. auch Konflikte, aber die entstehen dann nur lokal und beim Committen sieht man wirklich nur die eigenen Änderungen, so dass das alles unproblematisch ist.

Zitat:

Zitat von Uwe Raabe (Beitrag 1521329)

Ich war ja lange Jahre überzeugter Mercurial-Nutzer und ich betrachte es immer noch als das ideale System für Einsteiger und Dummies (nicht abwertend gemeint), die ein einfach zu bedienendes und unkaputtbares System suchen.

Ja, das ist es. Ich persönlich mag Git lieber, aber ich weiß auch, dass es nicht narrensicher ist und man schon aufpassen muss, ob man das tut, was man meinte.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1521330)

Vergiss vor dem Pull, dass noch lokale Änderungen da waren

Oder vor dem Commit den Pull vergessen, dann sieht das Log auch schnell pervers aus (wenn man GIT aus Standard stehen hatt, was die Mergemethode betrifft)

Noch schlimmer wird es bei einem Merg und ganz besonders, wenn es da beim Merge zu Konflikten kam.
Da dann die Änderungen wieder auseinander zu bekommen :wall:
oder nicht ausversehn das Lokale mit dem Merge vermischt zu committen.

Zitat:

Zitat von freimatz (Beitrag 1521326)

Man muss sich bei git schon anstrengen etwas kaputt zu machen.

Bei SVN bekommt man nichts kaputt. (pull und push kann man auch nicht vergessen ... das ist quasi automatisch immer implizit dabei)
Im GIT geht es leichter, als man denkt ... samt löschen/überschreiben der kompletten Historie.

Ist aber immernoch besser, als gar keine Versionierung,
vor allem im Vergleich mit NICHTS, ZIPs oder Verzeichniskopien.

[Graf Gustav]

Der Motivation eurer Beiträge kann ich mich nicht entziehen, danke :-)
Beim Versuch gestern, testweise SVN (und auch Git) zu installieren, bin ich bei beiden wieder an dieselbe Mauer gerannt -
diese Systeme mögen nicht die locker verbundenen Windows-Netzlaufwerke.
Gibt es da eine Lösung?

SVN findet das Laufwerk nicht, auch nicht \\Server\...

Der Git-Vorschlag erinnert mich an Unix-Zeiten, die sehr lange zurückliegen

Error in startup script

fatal: detected dubious qwnership in repository at
'//Buck1/homes/DEV10/'
'//Buck1/homes/DEV10/' is owned by:
'S-1-5-21-4101908947-260157542-1980192655-3054'
but the current user is:
'S-1-5-21-222117141 -13130269-41 4274037250-1001'
To add an exception for this directory, call:

git config --global --add safe.directory
‘%(prefix}///Buck1/homes/DEV10/'
while executing
'close Sfd'
(procedure 'git' line 5)
invoked from within
'git rev-parse --show-toplevel'
(file “C:/Program
Files/Git/mingw64/libexec/git-core/git-gui.tcl” line 1348)
invoked from within
'source [file join [file dirname[info script]] git-gui.tcl]'
(file “C:\Program Files\Git\mingw64\libexec\git-core\git-gui”
line 25)

Ich habe keine Probleme mit batch-Systemen, meine ersten Programme
habe ich in 360-Assembler geschrieben, aber das muss ja nicht mehr sein ...

[himitsu]

Wenn du eh alleine arbeitest:

Für den Anfang braucht du (noch) garkeinen Server.
* GIT und vielleicht noch eine GIT-GUI (VisialStudioCode, GitHubDesktop, Tortoise oder so) installieren
* und dann in deinem Codeverzeichnis auf "create repository here" bzw.

Delphi-Quellcode:

git init

* PULL und PUSH hier einfach (erstmal) vergessen
* aber schon hast du COMMIT und das Log zur Verfügung ... und optional auch Branches


Mit

Delphi-Quellcode:

git remote add origin //MyWorkPCName/dev/myrepo

kann man später immernoch optional in Ruhe ein "lokales" Remote-Repo anhängen
oder eben einen Sever ala

Delphi-Quellcode:

git remote add origin [e-mail]:myname/myrepo.git

.


Für den Share und auch einen Server ... Den muß man vorher erstellen.

Delphi-Quellcode:

git init --bare

bzw.

Delphi-Quellcode:

git init --bare deinverzeichnisodersharefolder

und dann kann man davon runterladen (

Delphi-Quellcode:

git clone

) oder es dem Lokalen Repo hinzufügen (

Delphi-Quellcode:

git remote add

).

Auch für SVN braucht es keinen Server (gut, denn kann man auch einfach nur lokal installiert haben),
aber da kann man ebenfalls direkt mit einem lokalen Verzeichnis oder einem Share arbeiten.

[Graf Gustav]

Genau das dachte ich ja auch.
Die Git-Meldung kommt beim Versuch, mit Git-GUI ein Repository anzulegen.
Es sind diese merkwürdigen Benutzerkennungen, die da zuschlagen....

[himitsu]

Ach mist ... sekunde ... die hatten da vor Kurzem eine Kranke Nutzerprüfung eingebaut, wo die den Namen, anstatt der Rechte prüfen ... die kann man aber abschalten.

Code:

git config --global --add core.symlinks false
git config --global --add safe.directory "*"

Eventuell auch mal über sowas nachdenken, wie z.B.:

Code:

git config --global --add core.hideDotFiles false
git config --global --add core.ignoreCase true
git config --global --add core.protectNTFS true

https://git-scm.com/docs/git-config

[jaenicke]

Zitat:

Zitat von Graf Gustav (Beitrag 1521332)

diese Systeme mögen nicht die locker verbundenen Windows-Netzlaufwerke.
Gibt es da eine Lösung?

Keine Netzlaufwerke verwenden. ;-)
Ein Rechner stellt den Server zur Verfügung, alle anderen greifen auf diesen Server zu. Die SVN-/Git-Daten auf dem Server-PC werden (z.B. mit Veeam) regelmäßig automatisch gesichert, z.B. auf ein Netzlaufwerk.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1521339)

Keine Netzlaufwerke verwenden. ;-)

Das ist auch unabhängig von der Versionskontrolle zu empfehlen. Vor sehr langer Zeit, als SVN noch richtig neu war, haben wir unsere gemeinsam genutzten Libraries vom Netzlaufwerk auf den lokalen PC verschoben und die Turnaround-Zeiten (Compile, Build) in der IDE um mindestens den Faktor 10 verbessert. Seitdem sind Netzlaufwerke in der Entwicklungsumgebung tabu. Mittlerweile geht die Synchronisierung über Git auch deutlich schneller als früher das manuelle Kopieren ganzer Verzeichnisstrukturen.

[freimatz]

Jetzt bin ich irritiert. Graf Gustav, du bist doch Einzelentwickler. Wieso hast Du dann lose Netzlaufwerke? Arbeitest Du nicht lokal?
Bei meiner Antwort bin ich davon ausgegangen. Und bei git brauchst du keinen Server, kein pull, kein push. Du brauchst zuerst nicht mal branches und merges. Eine reine Versionierung in einem branch wäre schon mal ein Fortschritt zu keiner VCS.
@jaenicke: wenn ich mit TortoiseGit pull und habe noch nicht committete Dateien, dann fragt es ob ich die stashen will. Lokal Dateien bekommt man natürlich schon kaputt. Ich meinte: was mal in git committet ist, bekommt man so einfach nicht kaputt.

[jaenicke]

Zitat:

Zitat von freimatz (Beitrag 1521355)

wenn ich mit TortoiseGit pull und habe noch nicht committete Dateien, dann fragt es ob ich die stashen will.

Das ist gut, war damals aber nur bei SVN so. Und ich habe es nie wieder ausprobiert. :)

[himitsu]

Ich hab es so noch nie erlebt.

Pull geht immer und sagt nichts "Schlimmes", egal ob Dateien lokal geändert sind oder nicht.
OK, es sagt schon was, denn die Modified Dateien werden anschließend aufgelistet.

NUR wenn eine Datei geändert ist, welche beim Pull/Checkout ebenfalls sich ändert, dann gibt es einen Konflikt, da die zu doof sind einen automatischen Merge der Datei hinzubekommen, selbst wenn die Änderungen in den Dateizeilen sich nicht überschneiden.

Entweder der Pull/Checkout bricht mit Fehler sofort ab und man kann noch in Ruhe stashen oder committen
oder der Pull/Checkout steht halb da und man darf mergen.
Hier gibt es noch kein Problem, aber passierte das bei einem Merge, dann hatte ich immer den halben Merge mit den lokal geänderten Dateien und beim anschließenden MergeCommitt passiert es schnell, dass man ausversehn seine lokalen Änderungen mit im Merge drin hat, wo sie logisch aber nicht rein gehören.

[Graf Gustav]

naja, Geschichten von vor sehr langer Zeit hab ich auch :wink:
da hatten wir z.B. die Dateigrößen in unsrer Projekt-Infobox beschränkt, weil das Herunterladen mit den 1200/50-Verbindungen so lange gedauert hat.

Also ich habe einen Großteil meiner Daten, auch Delphi-Projekte, in einer NAS liegen und greife darauf über Netzlaufwerke zu.
In der NAS laufen 2 RAID-1 Platten, deren wesentliche Inhalte nachts in die Synology-Cloud gesichert werden.
Ist das eine für einen Einzelentwickler ungewöhnliche Konfiguration? Für mich ist der Durchsatz völlig ok.

Aber vielen Dank euch allen für die Versionskontroll-Motivation und die Informationen.
Ich habe mir auf dem (oder der?) NAS GIT als App installiert, die mir dort die remote-Repositories bearbeitet.
In GIT arbeite ich mich aktuell ein. Es kommt halt aus der Unix-Ecke, also muss man wieder eine neue Sprache lernen (oben hätte ich fast 'gebackupt' geschrieben).

Schönes WE noch
Reinhold

[himitsu]

Hatte ich auch mal, aber ist nur nötig, wenn man von unterwegs mit Git spielen will.
Alternativ kann man sich aber auch GitLab installieren ... ähnlich wie ein abgespecktes GitHub, nur bei sich selber.

Bei mir ist der Git-Server nur noch der Faulheit wegen installiert, aber das Packet deaktiviert (GIT installiert, aber der Dienst nicht gestartet),
damit ich innerhalb der Syno GIT als Backup benutzen kann, also

Delphi-Quellcode:

git fetch

bzw.

Delphi-Quellcode:

git commit

über die Aufgabenplanung. (DSM 6 ... mal sehn ob es in der 7 noch so geht)
z.B. regelmäßig die Webseite via FTP runterladen und den aktuellen Stand in ein GitRepo speichern.


Von unterwegs via VPN oder nur im lokalen Netz, ist die Verwaltung des GitServers unnötig kompliziert.

Einfach via SMB in ein Verzeichnis und dort ein Bare-Repo erstellen

Delphi-Quellcode:

git init

zeigt dir die "URL" für das

Delphi-Quellcode:

git clone

an:
//MeinNAS/Develop/TestRepo/.git/
C:/TestRepo/.git/

Aber im Windows funktioniert es auch mit \ statt /
also einfach den Pfad aus dem Explorer kopiert. :angle:
\\MeinNAS\Develop\TestRepo\.git
C:\TestRepo\.git

[Graf Gustav]

SMB - meine Güte, das ist ja einfach :shock: warum hab ich das nicht gewusst?
Ich arbeite nicht mehr von unterwegs - das langt alles 100%.
Und mit Git Bash geht das ja alles mit noch weniger Tipperei :-D
Danke Dir vielmals

[freimatz]

Zitat:

Zitat von Graf Gustav (Beitrag 1521435)

SMB - meine Güte, das ist ja einfach :shock: warum hab ich das nicht gewusst?

Weil Du meinen Beitrag nicht gelesen oder verstanden hast. :wink:
Die Dinge sind meistens am einfachsten wenn man sie nicht benutzt. Also kein SMB, kein GitServer, kein git clone, ...
Da wo die Sourcen sind auf oberere Ebene ein "git init" und schon ist ein Repository da. Wenn man neu mit git anfängt ist das am einfachsten.
(Ich sage ja nicht dass diese Dinge nicht Ihren Sinn haben. Es geht mir darun dass man als Entwickler sagt man verwendet git nicht weil es so kompliziert sei.)

[himitsu]

Zitat:

Zitat von freimatz (Beitrag 1521453)

Weil Du meinen Beitrag nicht gelesen oder verstanden hast. :wink:

Auch siehe #13, der erste Absatz.

[freimatz]

:thumb:

[Graf Gustav]

freimatz: du darfst anderen ruhig mehr zutrauen als dir selbst. Wenn Du ein Fan lokaler Laufwerke und eindimensionaler Strukturen bist - ich nicht.
Ich bin ein paar Jahrzehnte zu lange im Geschäft, um nicht mit jedem Crash zu rechnen. Deshalb NAS mit professioneller Sicherung.
Die Vorschläge 'kein Netzlaufwerk - kein remote Repository' sind nicht meine Welt.
Was ich tatsächlich nicht kannte, war der SMB-Zugriff auf das NAS. (danke Himitsu :))
Ich kann jetzt sehr einfach auf //NAS/... ein bare-Repo erzeugen, das lokal clonen und dann mit den üblichen add/commit und push - Funktionen die Versionskontrolle durchführen.
Dass ich als Einzelentwickler kein remote Repo bräuchte, ist schon klar, aber so hab ich es halt gesichert.
Was also hab ich denn nicht gelesen oder verstanden?

[himitsu]

Falsch ist es natürlich ist. :D



Nja, auch ein lokales Repo hat eine zusätzliche Sicherung.

Oder hast du etwa kein Backup deines Computers? :stupid:




PS: Auf Github kann man schon seit 'ner Weile auch "private" Repos in kostenlosen Accounts benutzen.
Aber hier kann man sich natürlich steiten, ob irgendwo bei einem Ami, oder lieber doch nur auf dem eigenen NAS.

Zumindesten für öffentliche Repos sind Github und Co. im Vorteil, gegenüber einem diesem Git-Server auf dem eigenen NAS. (da würde ich diesen Server dann wenigstens im Docker oder VMM haben wollen, anstatt ihn direkt im Linux des NAS laufen zu haben, wegen eventueller böser Jungs da draußen)

[jaenicke]

Zitat:

Zitat von Graf Gustav (Beitrag 1521479)

Dass ich als Einzelentwickler kein remote Repo bräuchte, ist schon klar, aber so hab ich es halt gesichert.

Ich habe diese rein verzeichnisbasierte Arbeitsweise in meiner Git-Anleitung auch gezeigt und das funktioniert auch gut, egal ob per SMB oder auf einem externen Datenträger oder ähnlichem.

Bei größeren Repositorys finde ich aber einen echten Git-Server besser, weil der die Übertragung komprimiert vornimmt, so dass man nicht so viele Dateioperationen braucht und es deutlich schneller funktioniert. Technisch funktioniert aber beides gut.

Eine Sicherung mache ich auch auf ein NAS, aber ich sichere die Daten als differentielles Backup hinter dem Git-Server und habe so nicht nur einen Stand (mehr könnte mein NAS nicht von sich aus), sondern einen Monat zurück tägliche Datenstände, so dass ich z.B. bei einer Verschlüsselungs-Malware nicht Gefahr laufe, dass ich nur noch einen kompromittierten Datenstand wiederherstellen kann, wenn ich den Befall nicht sofort bemerke.

Letztlich ist aber die Art der Umsetzung egal solange du damit gut arbeiten kannst. Ich persönlich würde empfehlen:
Nutze ein gutes Vergleichs-Tool wie Beyond Compare oder Code Compare (leider für Delphi ohne semantischen Vergleich, für andere Sprachen aber schon) und eine für dich passende GUI für Git (TortoiseGit, ...), dann kann man sehr angenehm damit arbeiten. Die Blame-Ansicht ist z.B. interessant, wenn du herausfinden möchtest, wann (und warum) du eine bestimmte Zeile geändert hast.

[freimatz]

Zitat:

Zitat von Graf Gustav (Beitrag 1521479)

freimatz: du darfst anderen ruhig mehr zutrauen als dir selbst. Wenn Du ein Fan lokaler Laufwerke und eindimensionaler Strukturen bist - ich nicht.
Ich bin ein paar Jahrzehnte zu lange im Geschäft, um nicht mit jedem Crash zu rechnen. Deshalb NAS mit professioneller Sicherung.
Die Vorschläge 'kein Netzlaufwerk - kein remote Repository' sind nicht meine Welt.
Was ich tatsächlich nicht kannte, war der SMB-Zugriff auf das NAS. (danke Himitsu :))
Ich kann jetzt sehr einfach auf //NAS/... ein bare-Repo erzeugen, das lokal clonen und dann mit den üblichen add/commit und push - Funktionen die Versionskontrolle durchführen.
Dass ich als Einzelentwickler kein remote Repo bräuchte, ist schon klar, aber so hab ich es halt gesichert.
Was also hab ich denn nicht gelesen oder verstanden?

Zitat:

Zitat von Graf Gustav (Beitrag 1521302)

Mit dem Hinweis auf ein Versionskontrollsystem hast du die zäheste Lücke meines
Delphi-Entwickler-Lebens getroffen. X mal angegangen, immer wieder versandet.
Als ich noch im Team programmiert habe, gab's so etwas noch nicht, und für einen singulären
Privatentwickler sieht das immer so aufwendig aus.

Irgendwie bin ich irritiert. Für mich passt das jetzt nicht zusammen. Oder ich verstehs halt nicht.
Ich bin nicht generell gegen NAS und professionelle Sicherungen - ganz im Gegenteil. Meine Empfehlung bezog sich nur im Zusammenhang mit git UND wenn man Mühe mit Versionskontrolle hat. Dann ist es einfacher einfach anzufangen.
(Was mich betrifft: in der Firma haben wir einen Gitserver und auch andere Server mit Sicherung. Zuhause habe ich auch ein NAS. Git Repos sind nur lokal und werden mit anderen Daten andersweitig gesichert..)