Delphi 11 alte Projekte lassen sich nicht öffnen

[atari1040]

Ich habe immer noch das Problem, dass sich einige ältere Projekte mit Delphi 11 (Patch 1 installiert!) unter Windows 10 nicht mehr öffnen lassen. Nach vielen Monaten wollte ich noch mal nachfragen, ob jemand das Problem lösen konnte (dsk Datei habe ich bereits gelöscht).
Ergänzung: Es sind VCL Projekte, die sich mit Delphi 10.x einwandfrei öffnen lassen.
Ist es ein Problem, welches nur ich habe oder ist Delphi 11 überhaupt benutzbar?

[himitsu]

DPROJ löschen oder umbenennen
und dann die DPR öffnen (über Zuletzt-Verwendet oder Favoriten geht das natürlich nicht)

Get es dann?

Falls damals in den Projektoptionen was geändert wurde, muß das neu gemacht werden.

[atari1040]

Zitat von himitsu:

DPROJ löschen oder umbenennen
und dann die DPR öffnen (über Zuletzt-Verwendet oder Favoriten geht das natürlich nicht)

Get es dann?

Falls damals in den Projektoptionen was geändert wurde, muß das neu gemacht werden.

Es ist noch viel besser. Wenn man einen Doppelklick auf die *.dproj macht funktioniert es jetzt zumindest bei einem Projekt. Über Datei/Projekt Öffnen oder die Willkommensseite hing Delphi über Stunden bis zum Task-Kill.
Ich verstehe dieses Delphi nicht mehr.

[himitsu]

• Delphi starten
• [optional] ein neues VCL-Projekt erstellen oder irgendein Projekt ledan
  • mit geöffnetem Projekt wird es einfacher, wenn man RTL/VCL-Units im Quellcode debuggen möchte
    und auch sowas wie "Springe zu Deklaration" funktioniert dann meistent
  • besonders nötig, wenn man eigene DesignTime-Packages debuggen will (hier natürlich das Projekt dafür laden)
• Start > Prozess laden > $(BDS)\bin\bds.exe als Host-Anwendung
• beim Start ein paar Exceptions ignorieren (Paar mal der Raubkopierschutz und eventuell noch einige dutzend Exceptions von Fremdkomponenten ala DevExpress und Co.)
• dann DORT das machen, was knallt
• sich freuen, wenn man sieht wo es knallt und eventuell auch warum
  und dann hat man auch paar mehr Infos für seinen Bugreport

[atari1040]

Zitat von himitsu:

• Delphi starten
• [optional] ein neues VCL-Projekt erstellen oder irgendein Projekt ledan
  • mit geöffnetem Projekt wird es einfacher, wenn man RTL/VCL-Units im Quellcode debuggen möchte
    und auch sowas wie "Springe zu Deklaration" funktioniert dann meistent
  • besonders nötig, wenn man eigene DesignTime-Packages debuggen will (hier natürlich das Projekt dafür laden)
• Start > Prozess laden > $(BDS)\bin\bds.exe als Host-Anwendung
• beim Start ein paar Exceptions ignorieren (Paar mal der Raubkopierschutz und eventuell noch einige dutzend Exceptions von Fremdkomponenten ala DevExpress und Co.)
• dann DORT das machen, was knallt
• sich freuen, wenn man sieht wo es knallt und eventuell auch warum
  und dann hat man auch paar mehr Infos für seinen Bugreport

Erstmal Vielen Dank für Deine Anleitung. Das werde ich mal ausprobieren. Mit neu erstellten Projekten passierte das nicht. Es sind immer nur die alten Projekte.

Was mich allerdings nervt: Das was hier an Aufwand nötig ist erwarte ich eigentlich vom Hersteller bevor er das Produkt auf den Markt bringt oder zumindest in den 6 Monaten nach Release. Ich kann Delphi in unserem Projektteam nicht mehr einsetzen weil jede neue Version zu viele Fehler enthält. Die Stunden, die unsere Entwickler unnötig Fehler des Herstellers suchen sind nicht mehr zu akzeptieren und damit meine ich nicht dieses Problem sondern die Summe der Probleme! Open Source IDE's/Editoren funktionieren nach einem Update zu 99%. Delphi funktioniert nach einem großen Update zu 99% nicht wie erwartet. Für uns bedeutet das konsequent die alten Projekte auf andere Sprachen umzustellen. Es ist so Schade, was aus dem einst besten Windows Entwicklungswerkzeug der 90er Jahre geworden ist. Es ist maximal ein Nischenprodukt für Hobby-Programmierer geworden.

[Uwe Raabe]

Ich weiß nicht, was bei euren Projekten anders ist, aber ich hatte bisher keine Probleme auf neue Delphi-Versionen umzustellen. Sicher kommt es bei manchen (besonders bei Kunden-)Projekten zu Nacharbeite, wenn man (manchmal auch die Bibliothekshersteller) früher nicht ganz regelkonform programmiert hat, aber sonst kann ich eigentlich nichts dergleichen bemängeln. Im Gegenteil, mit den neuen Versionen kann man häufig auf alte Fremdkomponenten und -bibliotheken verzichten. Auch High-DPI und/oder Styles sind mit entsprechendem Einsatz durchaus realisierbar.

[TurboMagic]

Auch ich habe kaum bis keine Probleme mit alten Projekten beim Update.
=> wir sollten zusammen evtl. mal in der Tat erforschen was bei den betreffenden Projekten so anders ist.

z. B. Projektumfang (d.h. wie viele Unterprojekte in der Projektgruppe), benutzte Drittanbieter Komponenten...

[atari1040]

Zitat von Uwe Raabe:

Ich weiß nicht, was bei euren Projekten anders ist, aber ich hatte bisher keine Probleme auf neue Delphi-Versionen umzustellen. ...

Das ist ein langer Prozess über mehr als 25 Jahre und ich kann mich noch gut daran erinnern, wie man bei den XE Versionen noch alles deinstallieren und neu einrichten musste, wenn ein Update kam. Wir haben gar nicht die Probleme in unserem Code, denn der läuft ja unter 10.4 auch und mit einigen Tricks kann man ihn jetzt auch wieder in D11 laden. Man konnte ihn zuerst nicht mal öffnen und bekam keine Fehlermeldung von der IDE. Das Problem ist die Zeit, die dabei ins Land geht. Delphi 11 war wieder so eine Version, an der wir besonders viel Zeit verschwendet habe, was uns auch andere Firmen bestätigen. Durch die vielen Bugs fängt man natürlich an, Delphi mehrmals zu installieren, was zur Folge hat, dass wir uns wie Raubkopierer behandelt fühlen weil der Hersteller meint, wir haben das jetzt zu oft installiert. Wir zahlen viel Geld und müssen uns dann noch rechtfertigen, warum ein Entwickler das Produkt in mehreren VM's oder zur Fehlersuche mehrmals installieren musste. Das ist gleich das nächste Problem: über die Jahre haben sich unendlich viele VM's angesammelt. Das Konzept mit den Komponenten ist aus der Steinzeit. Ich muss entweder eine VM benutzen, für alle Projekte die Komponenten neu kaufen und updaten. Das ist doch nicht mehr zeitgemäß. Ich möchte ein Delphi installieren und dann sagen: nutze für Projekt1 DevExpress v.x und für Projekt 2 nutze DevExpress v.y. Ich muss für jede Konstellation ein neues Delphi installieren und das bei einer Projektanzahl, die sich über mehr als 25 Jahre angesammelt hat. Damit ist Schluss!

Fakt ist: in der Open Source Welt sind wir wesentlich effektiver und wirtschaftlich besser unterwegs und am Ende zählt das bei 30 Entwicklern.

[himitsu]

Nja, beim Laden/Aktivieren von Projekten kann Delphi auch Komponenten/Packages laden/entladen,
wenn im Projekt z.B. eine entsprechende Liste gespeichert ist.
z.B. <Excluded_Packages> siehe DPROJ irgendwo unter <ProjectExtensions>

Auch wenn man in der Projektverwaltung, in einer Projektgruppe, zwischen den Projekten wechselt, passiert das.

Und manchme Packages haben einfach Bugs und vertragen es nicht, wenn sie mehrmals entladen/geladen werden ... also knallt es dann.
Seit "Kurzem" entlädt nun Delphi auch Forms, wenn Packages entladen werden ... z.B. im XE knallte dir noch alles weg, wenn man das Package, oder davon Requiredete Packages, einer Komponente entlädt, bzw. kompiliert.

Komponenten > Packages installieren speichert in der IDE (Registry), wenn beim Ändern keine Projekte geladen sind, ansonsten wird das in dem aktiven Projekt (DPROJ) gespeichert.




Beim Upgrade einer DPROJ auf ein neues Delphi, können "Fehler" passieren, womit die DPROJ danach nicht mehr richtig funktioniert.
Die DPROJ ist keine doofe Konfigurationsdatei, sondern eigentlich ein MSBuild-Script, welches quasi wie eine ScriptSprache ala Python/JavaScript/VBScript/... durchlaufen wird.

Auch das neue Feature für GetIt-Abhängigkeiten ist per se bestimmt gut, wenn es beim Kompilieren aktuell nicht knallen würde.
So oder so gibt es eben manchmal Dinge darin, welche größere Auswirkungen haben können, als wenn nur eine einfache INI/XML in eine dummes Options-Set geladen würde.

[venice2]

Zitat:

für alle Projekte die Komponenten neu kaufen und updaten.

Deshalb ist Delphi auch nicht für Professionelle Anwendungen anwendbar.
So wie du sagst.

Es ist nun mal so das alte Komponenten immer hinterherhinken erschwerend dazu kommt noch das fast jede kompilierte Anwendung angeblich mit einem Virus infiziert ist.
Das ist nicht akzeptabel. Unter C#, VB.Net, C++ habe ich ein solches verhalten noch nie beobachten können.
Ein Witz wenn man jede Anwendung über Virus-Total als Entwickler jedesmal Ausnahmen (Fake-Alarme ) melden\beantragen muß.
Traurig wie sich das alles Entwickelt hat..
Persönliche Meinung!

Zitat:

Es ist maximal ein Nischenprodukt für Hobby-Programmierer geworden.

Dito.