Installation von SynEdit unter Delphi 11.3?

[gpl]

Ich versuche verzweifelt, SynEdit in D11 zu installieren, was weder über GetIt noch per manueller Installation funktioniert.
In beiden Fällen kommt beim Installieren die Meldung, dass ein Prozedureinsprungpunkt nicht gefunden wurde.

Ich habe die SynEditDD280.bpl auch mal manuell aus dem BPL-Verzeichnis entfernt und sie wird beim Kompilieren wieder tadellos erzeugt. Der Fehler bleibt allerdings.

Hat jemand eine Idee, was die Ursache sein könnte?

[Delphi.Narium]

Kompiliere bitte mal nicht sondern erzeuge alles neu, ggfls. vorher alle DCUs entfernen, verschieben ... für den Compiler unerreichbar machen. SynEdit und SynSpellCheck scheinen nicht zusammenzupassen, wobei ich den Fehler dann eher in SynSpellCheck suchen würde.

[gpl]

Danke für die schnelle Antwort!
Erzeugen statt Kompilieren hatte ich natürlich schon versucht. Jetzt habe ich die DCUs entfernt und neu erzeugt. Die DCUs werden auch tabellos angelegt.
Leider kommt der Fehler weiterhin bei der Installation...

Ich habe SynEdit jetzt mal per GetIt unter D12.2 installiert und da funktioniert es... seltsam. Demnach stimmt irgendetwas in D11 nicht. Das habe ich aber erst vor ein paar Tagen installiert...

[dummzeuch]

Ich hatte ein ähnliches Problem und bei mir lag es daran, dass im Suchpfad die .BPL-Datei einer anderen Delphi-Version lag (kann aber auch einfach eine veraltete .BPL-Datei im Suchpfad sein).
Was auch noch sein könnte, ist eine veraltete .DCP-Datei irgendwo.

[Delphi.Narium]

Vor dem Neuerzeugen muss darauf geachtet werden, das nichts von den zu SynEdit gehörenden DCUs, BPLs, ... mehr vom Compiler zu finden ist.

Der Fehler tritt für gewöhnlich auf, wenn Compilate unterschiedlicher Delphiversionen irgendwie durcheinander geraten.

[gpl]

Vielen, vielen Dank! Die Tipps waren Gold wert.

Es lag tatsächlich daran, dass eine SynEditDD280.bpl im BPL-Pfad der Delphi12-Installation lag. Und dieser BPL-Pfad war auch in der Path-Variable... Darauf muss man erstmal kommen.

[MyRealName]

Wenn man mehrere Delphi Installationen von Delphi hat, hat man auch in der PATH Variable beide Pfade, die erste von beiden gewinnt immer gern :)

[dummzeuch]

Zitat:

Zitat von gpl (Beitrag 1544431)

Vielen, vielen Dank! Die Tipps waren Gold wert.

Es lag tatsächlich daran, dass eine SynEditDD280.bpl im BPL-Pfad der Delphi12-Installation lag. Und dieser BPL-Pfad war auch in der Path-Variable... Darauf muss man erstmal kommen.

Ein solcher Fehler hat mich letzte Woche mehr als einen Arbeitstag gekostet. Ich hatte diverse 3rd-Party Bibliotheken für Delphi 12 eingerichtet und bei einigen Packages vergessen, den Ausgabepfad zu korrigieren (bzw. zu löschen, denn wenn nichts drin steht, macht der Compiler eigentlich alles richtig.) Ich habe ewig nach dem Fehler gesucht. Und dann war ich noch auf dem falschen Dampfer, dass Delphi mit Packagenamen, die eine Unterstrich enthalten, ein Problem hat, denn sobald ich den entfernte, funktionierte alles. Es lag aber nicht am Unterstrich sondern daran, dass sich der Package-Name dadurch änderte. Dann wurde die falsche .BPL-Datei nicht mehr gefunden. Zwischendurch hatte ich auch Delphi deinstalliert und neu installiert, was natürlich nichts brachte, da die bpl-Dateien ja in einer anderen Delphi-Installation lagen.
Was war ich froh, als ich endlich den Fehler gefunden hatte.

Deshalb hatte ich das noch ziemlich frisch in Erinnerung.

[jaenicke]

Deshalb verwende ich eigene Buildskripte, die den Ausgabepfad überschreiben... ;-)
Dann muss ich in den Drittanbieter-Packages nichts anpassen, sondern kann diese im Originalzustand lassen, was Updates deutlich erleichtert.

[dummzeuch]

Zitat:

Zitat von jaenicke (Beitrag 1544443)

Deshalb verwende ich eigene Buildskripte, die den Ausgabepfad überschreiben... ;-)
Dann muss ich in den Drittanbieter-Packages nichts anpassen, sondern kann diese im Originalzustand lassen, was Updates deutlich erleichtert.

Mache ich eigentlich auch so, aber wenn man gleichzeitig auf eine neue Delphi-Version und auf eine neue Library-Version updated, weil die alte die neue Delphi-Version nicht unterstützt, wird es dann doch wieder fehlerträchtig.

[Rolf Frei]

Da hat doch einfach einer die D11 DPK mit D12 kompiliert ohne den Namen der DPK auf 290 zu ändern. 280 im Namen ist die D11 Version. Wenn man das sauber macht, wenn man eine D11 DPK in D12 installierern will, gibt es keine solchen Probleme, weil so die unterschiedlichen Delphi Versionen jeweils einen anderen Namen haben.

Wann immer man eine alte Delphi Package Version selber in einem neuen Delphi installieren will, muss man die alte DPK im neuen Delphi laden und sofort mit der neuen Nummerierung im Dateinamen speichern (D11 SynEditDD280.dpk -> D12 SynEditDD290.dpk) und alle Bezüge in der DPK (für Runtime + Desingtime Papckage) entsprechend anpassen.

[himitsu]

Die PackageVersion kommt garnicht erst in den Projektnamen rein.

• MyPackage.dpk (ohne Version im Namen)
• in den Projektoptionen der DPK die Package-Version auf $(Auto) stellen
  oder manuell in der DPK, also nicht
  Delphi-Quellcode:

  {$LIBSUFFIX 290}

  , sondern
  Delphi-Quellcode:

  {$LIBSUFFIX AUTO}

  (gibt es seit Delphi 10.4.1)
• und raus kommt eine MyPackage290.bpl,
  aber im nächsten Delphi eben automatisch eine MyPackage300.bpl
• Außerdem ist die DCP ohne Version und somit kann man als Ruquires überall "MyPackage" angeben und passt das dann auch weiterhin.

Vom Packagenamen her geht SynEdit (https://github.com/SynEdit/SynEdit) schonmal in eine gute Richtung, auch wenn die Verzeichnisnamen echt blöd sind (der Buchstabe lässt sich nicht automatisch bestimmen)