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 von Graf Gustav:

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 von Graf Gustav:

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...
https://entwickler-ecke.de/topic_Kur...it_115462.html

[jaenicke]

Zitat von haentschman:

Besser gleich GIT. Das mergen ist besser...

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 von freimatz:

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 von 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.

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.