Hallo Zusammen,
ich portiere gerade Delphi7 Projekte von XP nach WIN10. Das erste hat gut geklappt, aber jetzt habe ich Probleme mit Indy.
Auf dem WIN 10 Rechner war schon Indy 10.1.5 drauf. Dieses habe ich deinstalliert und die gleiche Version 10.6.2.5459 wie unter XP auf dem WIN10 Rechner installiert.

Die Deinstallation geht ja ganz easy, nur da für die neue Version kein setup existiert, muss man es manuell machen.
Ich habe alles in einen Ordner unter C kopiert, dann die FULL_D7.bat aufgerufen, welches dann das D7 Verzeichnis erzeugt.
Möchte man nun die Komponenten hinzufügen, gibt es Probleme, weil irgendwelche DLL's nicht gefunden werden.
Ich habe nun die BPL files in windows/syswow64 kopiert und nun sind die Indy Komponenten aktiv.

Nun zu meinem Problem.
Obwohl ich die gleiche Version installiert habe, bekomme ich Umwandlungsprobleme, dass manche Funktionen, Prozeduren oder Eigenschaften nicht existieren.
Beispiel: idhttp.IOHandler.InputBuffer.Clear;
Delphi findet InputBuffer nicht. Wenn ich es unter xp aufrufe sind die Prozeduren vorhanden.
Ebenso idhttp.Disconnect(TRUE) kennt er nicht.

Wenn ich mir die Version von der idhhtp Komponente anschaue, ist sie absolut identisch.
Ich habe dann die Statements auskommentiert. Dann lies sich das Projekt kompilieren. Beim Aufruf und Start des Formular, wo die idhttp Komponente drauf liegt, kommt sofort eine exception hoch. Irgendetwas passt nicht, nur was?
--> Fehler beim Lesen vin IDHTTP.Request.ContentRangeInstanceLengths. Eigenschaft existiert nicht.

Ich habe dann auf dem WIN Rechner nach doppelten BPL files gesucht, aber nichts gefunden.

Was kann ich noch tun, damit die Komponenten gleich sind?

Danke.
Klaus

Alle DCU-Dateien der Indys löschen und dann das Projekt neu erstellen.

Es könnte sein, dass zwar die Quelltexte alle neu sind, aber eventuell noch alte DCU-Dateien irgendwo im Suchpfad des Kompileres liegen.

Sicherstellen, dass von den alten Indyquelltexten garantiert nichts mehr im Suchpfad des Kompilers zu finden ist.

Danke, die DCU's sind OK, aber in delphi/lib gab es die gleichen DCU files, vermutlich noch INDY9 Fragmente.
Ich habe die mal belassen, und beim Bibliothekspfad die INDY 10 Files ganz nach oben gesetzt.
Oder wäre es besser die doppelten Files aus Delphi / LIB/debug zu entfernen oder die dcu Files aus dem erzeugten D7 Indy Verzeichnis nach Delphi/lib und delphi/debug zu kopieren?

Gruß Klaus

Zitat von KlausV:

Danke, die DCU's sind OK, aber in delphi/lib gab es die gleichen DCU files, vermutlich noch INDY9 Fragmente.
Ich habe die mal belassen, und beim Bibliothekspfad die INDY 10 Files ganz nach oben gesetzt.
Oder wäre es besser die doppelten Files aus Delphi / LIB/debug zu entfernen oder die dcu Files aus dem erzeugten D7 Indy Verzeichnis nach Delphi/lib und delphi/debug zu kopieren?

Gruß Klaus

Die DCUs von Indy gehören nicht nach delphi/lib und delphi/debug sondern in ein eigenes DCU-Verzeichnis, das dann in den Bibliothekspfad der Projekte aufgenommen wird, die die jeweilige Indy-Version nutzen.

Liegen die DCUs von Indy 9 in einem Verzeichnis und die DCUs von Indy 10 in einem anderen Verzeichnis, so kannst Du die Bibliothekspfade in den einzelen Projekten entsprechend setzen und durchaus Indy 9 und Indy 10 parallel nutzen. So kannst Du sogar problemlos mehrer Indy 10-Versionen nebeneinander nutzen und Deine Programme, je nach Bedarf, umstellen ohne bei der Nutzung einer neuen Indyversion zwingend sofort alle Projekte umstellen zu müssen.

Werden die DCUs "einfach mal so alle" nach delphi/lib und delphi/debug kopiert werden, wirst Du irgendwann an einem Versions-DCU-Durcheinander scheitern.

Bei Delphi 7 ist von Haus aus Indy 9 dabei. Bei mir sind dort die entsprechenden DCUs unter Delphi/lib und delphi/debug nicht mehr zu finden. Da ich alle Komponenten, ... und deren DCU-Datei in einem eigenen Verzeichnis habe, welches in den Projektoptionen unter "Ausgabe für Units" definiert ist, hab' ich noch nie derartige Probleme gehabt.

In delphi/lib und delphi/debug liegen bei mir nur die bei der Installation von Delphi dort abgelegten DCU-Dateien. Eigene Dateien haben dort nichts zu suchen.

Es dürfte unschädlich sein, alle Indy-Fragmente aus delphi/lib und delphi/debug in ein Sicherungsverzeichnis zu verschieben.

Zitat von KlausV:

Danke, die DCU's sind OK, aber in delphi/lib gab es die gleichen DCU files, vermutlich noch INDY9 Fragmente.
Ich habe die mal belassen, und beim Bibliothekspfad die INDY 10 Files ganz nach oben gesetzt.
Oder wäre es besser die doppelten Files aus Delphi / LIB/debug zu entfernen oder die dcu Files aus dem erzeugten D7 Indy Verzeichnis nach Delphi/lib und delphi/debug zu kopieren?

Meiner Ansicht nach sollten im Delphi-Verzeichnis generell keine DCUs (oder auch Sourcen) von 3rd-Party Bibliotheken liegen. Die Suchpfade der IDE werden gerne mal angepasst, ohne dass man das mitbekommt und schon hat man plötzlich alte DCUs oder Sourcen im Programm und sucht sich 'nen Wolf, woher plötzlich die Probleme kommen.

Aber Borland/Inprise/Embarcadero sahen/sehen das anscheinend anders, was mir mit jeder neuen Delphi Version erneut auf den Keks geht.

Ich gehe sogar noch weiter: Ich habe keine globalen Installationen von 3rd-Party-Bibliotheken. Die kommen immer in ein Unterverzeichnis des jeweiligen Projekts und die Pfade dorthin sind immer relativ zum Projekt und auch projektspezifisch, nicht in den Library-Pfaden der IDE.

Super, vielen dank für die Hilfe.
Ich habe nun alle doppelten Files aus Delphi/Lib und Delphi/Lib/debug entfernt, und nun kann ich auch debuggen.

Zitat von dummzeuch:

Ich gehe sogar noch weiter: Ich habe keine globalen Installationen von 3rd-Party-Bibliotheken. Die kommen immer in ein Unterverzeichnis des jeweiligen Projekts und die Pfade dorthin sind immer relativ zum Projekt und auch projektspezifisch, nicht in den Library-Pfaden der IDE.

Zwei Fragen dazu:

1. Und die Designtime-Komponenten? Oder erzeugst Du alles zur Laufzeit, auch Datenmodule und Formulare?
2. Hast Du dann nicht x Kopien der 3rd-Party-Bibliotheken?

Das Laden der Designtime-Komponenten ist (zumindest bei Delphi 7) projektabhängig.

Man kann einerseits eine bestimmte Auswahl von zu ladenden Packages als Vorgabe konfigurieren, diese werden dann immer geladen und eine freie Auswahl je Projekt.

Klar, das ist Aufwand und man hat als Folge daraus dann ggfls. x Kopien der 3rd-Party-Bibliotheken und die dann sogar eventuell noch in unterschiedlichen Versionen (was durchaus beabsichtigt sein kann).

Mit 'ner gut gepflegten Versionsverwaltung sollte das aber kein unlösbares Problem sein. Ohne eine Versionsverwaltung hat man dann aber sicherlich schon einiges an Aufwand.

Zitat von Delphi.Narium:

und man hat als Folge daraus dann ggfls. x Kopien der 3rd-Party-Bibliotheken und die dann sogar eventuell noch in unterschiedlichen Versionen.

Aber das ist ja auch genau der Grund für die Trennung. Wenn ich unabhängige Projekte A, B, C habe, die alle drei Komponente K verwenden, und ich möchte Projekt A mit Komponente K Version 2 verwenden, die anderen aber noch nicht, dann muss das getrennt sein.

Dabei kann das natürlich in der Versionsverwaltung bei einem einzigen Repository für K bleiben. Das hat auf die unterschiedlichen Versionen keinen Einfluss.

Das mit den projektabhängigen Design-Packages habe ich mal versucht mit dem Package Magician (nicht zu verwechseln mit Project Magician) in den Griff zu bekommen. Leider reagieren manche Packages nicht so gut auf das Entladen. Daher gibt es Szenarien in denen der Package Magician nicht wie gewünscht funktioniert.

Zitat von Frickler:

Zitat von dummzeuch:

Ich gehe sogar noch weiter: Ich habe keine globalen Installationen von 3rd-Party-Bibliotheken. Die kommen immer in ein Unterverzeichnis des jeweiligen Projekts und die Pfade dorthin sind immer relativ zum Projekt und auch projektspezifisch, nicht in den Library-Pfaden der IDE.

Zwei Fragen dazu:

1. Und die Designtime-Komponenten? Oder erzeugst Du alles zur Laufzeit, auch Datenmodule und Formulare?

Dafür braucht man weder den Sourcecode noch die DCUs sondern nur Runtime- und Designtime Packages.

Zitat von Frickler:

2. Hast Du dann nicht x Kopien der 3rd-Party-Bibliotheken?

Ja, ich habe aktuell über 100 Kopien davon (eine pro Projekt, das sie verwendet). Allerdings sind die per svn:externals in Subversion eingebunden, so dass es einfach ist, sie synchron zu halten, wenn sich was ändert.