![]() |
compilteroptionen getIt
Moin,
meine Frage betrifft Delphi 10.4.2 Professional with Mobile unte W8.1. Ich habe auf der Willkommensseite der IDE drei Bevorzugte Projekte. Zwei funktionieren, das erste gibt beim Versuch zu kompilieren folgenden Fehler heraus: Abhängigkeiten des Projekts werden überprüft... Compilieren von GFN.dproj (Release, Win64) [Warning Warnung] Checking GetIt package dependencies [MSBuild Fehler] Unerwarteter Fehler bei der GetItCmd-Aufgabe. System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. bei Borland.Build.Tasks.Common.CommandLineTask.Execute () bei Borland.Build.Tasks.Shared.GetItCmd.Execute() bei Microsoft.Build.BuildEngine.TaskEngine.ExecuteInst antiatedTask(EngineProxy engineProxy, ItemBucket bucket, TaskExecutionMode howToExecuteTask, ITask task, Boolean& taskResult) Misslungen Verstrichene Zeit: 00:00:00.0 Ich habe beim Bearbeiten der Build-Konfiguration (Release, Zielplattform Windows 64 Bit) einen Fehler gemacht. Danach kam obige Fehlermeldung. Wie komme ich für dieses Projekt wieder zu Standarteinstellungen? Ich habe in dem Menue rumgefuscht, das beim Rechtsklick auf BuildKonfiguration, und dann 'Bearbeiten erscheint'. Für Lösungshinweise oder sogar Lösungen wäre ich sehr dankbar. Googeln nach dem Reset der IDE gab nur Vorgehensweisen bei denen sehr viel verloren geht. Da aber bei mir zwei Projekte funktionieren, habe ich Hoffnung das es einen Weg gibt. Mit besten Grüßen Rolf |
AW: compilteroptionen getIt
Natürlich hast du ein VCS im Einsatz,
also geht doch garnichts verloren, selbst wenn du die DPROJ löschst und neu generieren lässt. :stupid: Ansonsten kann man natürlich auch ein neues Projekt erstellen und dessen Projektoptionen mit Denen des alten Projektes vergleichen. Aber ich würde wohl zuerst nach den Abhängigkeiten schauen, wenn es das ist, was am Auffälligsten knallt. [ADD] Delphi 11 : gibt auch diesen Fehler. Lösung : alle Abhängigeiten entfernen :freak: Und man mag es nicht glauben, aber der Fehler ist bekannt. ![]() ![]() |
AW: compilteroptionen getIt
Hallo Himitsu,
ersteinmal danke für Dein Bemühen. >Natürlich hast du ein VCS im Einsatz, Nein, habe ich natürlich nicht. >also geht doch garnichts verloren, selbst wenn du die DPROJ löschst und neu generieren lässt. In den von Google vorgeschlagenen Lösungen war sogar die Rede von gelöschten Projectordnern und mehr. Natürlich habe ich Backup. Aber wie weit will man gehen um ein lokales Problem zu lösen. >Ansonsten kann man natürlich auch ein neues Projekt erstellen >und dessen Projektoptionen mit Denen des alten Projektes vergleichen. Das habe ich gemacht, und soweit ich Änderungen erkennen konnte, auch zurückgenommen. Aber die IDE ist in diesem Punkt recht unübersichtlich. Kurz, ich habe es nicht hinbekommen. Aber ich würde wohl zuerst nach den Abhängigkeiten schauen, wenn es das ist, was am Auffälligsten knallt. Welche Abhängigkeiten meinst Du? >Und man mag es nicht glauben, aber der Fehler ist bekannt. > ![]() > ![]() Deine Links führen zu Seiten die weder zugänglich für mich sind, noch hilfreich. Also noch einmal danke für Dein Bemühen, aber es hat mir leider nicht wirklich geholfen. Mit besten Grüßen Rolf |
AW: compilteroptionen getIt
Hallo,
ja, das ist bekannt, dass definierte GetIt abhängigkeiten zur Zeit zu Abstürzen führen. Wäre natürlich nütlich wenn das richtig funktionieren würde... Nutzung einer Quellcodeverwaltung, z. B. SVN (leicht zu nutzen und mittels VisualSVN Server auch kostenlos nutzbar) oder Git wäre aber sicherlich auch sinnvoll... Grüße TurboMagic |
AW: compilteroptionen getIt
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,
evtl. sind die GetIt- Abhängigkeiten angewählt. siehe Anhang Gruß |
AW: compilteroptionen getIt
Moin mmv,
Deine Antwort war sehr hilfreich. Danke. Es funktioniert nach Abwahl aller Getit-Abhängigkeiten wieder. Ich werde jetzt versuchen herauszufinden, welche Abhängigkeit die Ursache war. Mit den besten Wünschen Rolf |
AW: compilteroptionen getIt
Zitat:
|
AW: compilteroptionen getIt
Moin TurboMagic,
danke für Deine Anregung, bislang schreckte ich vor Git und seiner Komplexität zurück, aber ich werde es noch mal mit einem der beiden Versuchen. MgG Rolf Zitat:
|
AW: compilteroptionen getIt
Zitat:
Es knallt sofort, wenn "irgendwas" dort gewählt ist. Es gibt auch ein TortoiseGit. (und TortoiseHG) Für echte Git-Freaks ist das zwar pervers, weil man dort versucht hat die Git-Terminologie auf SVN umzubiegen, aber dafür ist die Grundfunktion von Git nutzbar und aus Sicht von TortoiseSvn leicht verständlich. Nur dass man nicht den Push vergessen sollte, vergisst man manchmal. Commits sind erstmal nur Lokal und spiegeln sich nicht ungedingt sofort auf dem Server wieder (falls/wenn man Einen nutz). Und ja, auch SVN kann man lokal nutzen, also ein lokales Verzeichnis genauso nutzen, wie einen SVN-Server. Und dann könnte man zwischen auch zwei "Servern" die Daten synchronisieren/austauschen. |
AW: compilteroptionen getIt
Zitat:
Ist ganz einfach, ist ja ein GUI Installer. Dann mit dem Verwaltungstool ein Repository und einen benutzer anlegen. Danach Tortoise SVN installieren, integriert sich ins Explorer Kontext Menü und starten. Die Doku von Tortoise SVN ist recht gut! Grüße TurboMagic |
AW: compilteroptionen getIt
Explorer > leeres Verzeichnis erstellen > TortoiseSvn > create repository here
das Selbe geht auch mit TortoiseGit (als Bare-Repo erstellen) ... bei uns mal genutzt, um auf einem Share ein lokales Repo für Alle zu haben, weil es zu groß für GitHub war und dann in anderem Verzeichnis den file://-Pfad (welchen man beim Erstellen angezeigt bekommt) beim Checkout benutzen Bei GitHub kann man auch mit SVN auschecken (GitHub hat bei sich was eingebaut) oder andersrum kann man auch mit GIT bei einem SVN-Server auschecken/clonen (GIT hat da was eingebaut) und dann lokal mit dem Anderen arbeiten, als wie der Server ist. (pervers wird es nur, wenn man mit Git bei der Svn-Bridge von GitHub sich einen runterholt) |
AW: compilteroptionen getIt
Zitat:
Da man sich gerade als Anfänger mit der Konsole manchmal etwas schwer tut, hängt die Akzeptanz in hohem Maße von der verwendeten GUI ab. Mein persönlicher Favorit ist da schon seit einer Weile (und vielen Fehlversuchen mit Alternativen): ![]() |
AW: compilteroptionen getIt
Beim Merge geht Einiges mit Git besser, aber Anderes wird schlimmer.
Aber gerade wenn im Git mal was quer steht, dann wird es schlimm, weil Git einfach so viel kann, dass das nichtmal die Profis mit 200 Jahren Erfahrung sich noch auskennen. Außerdem ist es bei SVN unmöglich die Historie zu zerstören. Was einmal eingecheckt ist, dass bleibt auch drin, während man in GIT ALLES vernichten kann, wenn man will oder zu doof rumklickt. Also ja, SVN ist einfacher, auch wenn Git schon ein paar Vorteile hat. |
AW: compilteroptionen getIt
Zitat:
Zitat:
|
AW: compilteroptionen getIt
Zumindestens hatten wir es mehrmals geschafft, dass garnichts mehr ging und brauchten dann 'ne Weile, um eine passende Lösung zu googlen.
Teilweise bestand die Lösung dann darin das lokale Repo zu löschen und neu zu clonen. Natürlich kann man sowohl in SVN, als auch Git viel mist bauen, aber standardmäßig gibt es keinen Weg, um einmal committetes zu löschen, also lässt sich immer Alles wiederherstellen (außer Backup, die Historie umschreiben und Restore des Servers) In Git kannst mit einem Force-Push alles auf dem Server löschen/überschreiben. (wobei im TortoiseGit die Checkbox für Force fehlt und man es über die Console machen muß ... z.B. wenn man den/die letzten Commits löschen will) Das Einzige, was man bei SVN standardmäßig nachträglich ändern kann, ist die Commit-Message. Aber ja, genauso wie im SVN, kann man im Git durch Hooks so Einiges verbieten. |
AW: compilteroptionen getIt
Moin Himitsu,
>Es knallt sofort, wenn "irgendwas" dort gewählt ist. Du hast vollkommen recht. Das war auch das Resultat meiner Versuche. Vielleicht kannst Du mir zu folgende Fragen etwas sagen. Wofür besteht diese Seite mit den Getit-Optionen? Was ist ihr Vorteil wenn sie angekreuzt sind.? Was sind die Konsequenzen für mich wenn ich alle abgewählt habe? Hat das zum Beispiel Einfluß auf meine Benutzung von JEDI Komponenten? Danke Rolf Zitat:
|
AW: compilteroptionen getIt
Genau getestet hatte ich es nicht, aber im Prinzip, wird hier beim Öffnen des Projektes entweder ein automatischer Download angestoßen (hoffe/glaube ich nicht), oder zumindestens eine Warnung ausgegeben, dass für dieses Projekt die Instalation von gewissen GetIt-Packages nötig sei, eventuell/vermutlich mit dem direkten Angebot sie zu installieren.
(da man nur installierte Packages dort auswählen kann, würde ich es so vermuten) Was ich mich eher noch frage ist, wie es bei Updates/Upgrades aussieht * ist die Versionnummer im Namen enthalten? (knallt es, wenn diese Version/Name nicht mehr existiert und eine andere Version/Name ist installiert oder noch nicht) * und wie sieht es aus, wenn man auf die nächste Delphi-Version upgradet, bzw. das Projekt dort öffnet * und wie sieht es z.B. mit JEDI, Indy und Co. aus, was man alternativ zu GetIt auch selber installiert haben könnte |
AW: compilteroptionen getIt
Hallo,
wenn man z.B. ein Project von 10.3.3 in 10.4.2 öffnet, kommt ein Dialog mit der Frage ob die fehlende Abhängigkeit installiert werden soll oder nicht. Wenn man auf installieren klickt, würde man ja vermuten das es installiert wird, wird's aber nicht. Als Status erscheint dann 'unavaible' bei den GetIt - Abhängigkeiten. Man muss es dann manuell über GetIt installieren Unter GetIt -Abhängigkeiten werden nur die über GetIt -installierten Sachen angezeigt. Gruß |
AW: compilteroptionen getIt
Also scheinbar genauso krank, wie im GetItCmd.
neues Delphi -> neues GetIt -> neue Package-Versionen ... blöd nur, dass die Versionsnummer im Namen steht und es dann knallt, wenn diese Version nicht mehr verfügbar ist. |
AW: compilteroptionen getIt
Wie schon geschrieben ist das buggy. Wenn es funktionieren würde
könnte man beim öffnen eines Projektes ggf. fehlende GetIt Pakete nachinstallieren... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:26 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz