Unterschied "Erzeugen" und "Compilieren" - Einstellungen

[QuickAndDirty]

Wir hatten manchmal pakages und DCUs im Windows ordner...wenn man die gelöscht hat und dann "erzeugen" durchgeführt hat ging es wieder. Aber ich weiß nicht ob das etwas mit deinem Fall zu tun hat.
Manchmal pakt Delphi auch einfach mal so von sich aus beim speichern ein {$R *.dfm} in units die keine forms sind...vielleicht ist das so ein effekt?

[himitsu]

Zitat:

zur Runtime

im Debugger oder ohne?

Ich hab eher nur das Problem, dass die beschissene IDE einen beschissenen Unit/Debuginfo-Cache hat und ich daher die IDE ab und an neu starten muß, weil sonst beim Debuggen garnichts stimmt. (egal ob Build oder Compile)


Und nach Build, sollte sich auch bei Compile nicht mehr viel ändern, selbst wenn irgendwo eine alte DCU noch rumgammelt. (es wird da ja nur noch die DPR neu verarbeitet und der Rest ändert sich nicht)
Du kannst ja mal Clean versuchen, auch wenn ich immernoch nicht weiß oder wieder vergessen hab, was das eigentlich alles macht.


* DCU-Verzeichnis löschen (Standardmäßig der Win32-Unterordner)
* Projektoptionen > Erzeugen > Delphi-Compiler > Compilieren > Weitere Optionen > Unit-Abhängigkeitsinformationen: JA (Ziel = Alle Configs)
* und nach dem Build im Ausgabeverzeichnis, neben der EXE nach einer exename.d-Datei suchen
Da drin sollte nun stehen, welche DCU wirklich verwendet wurden. (ob die vorher aus einer PAS erzeug wurden, sagt es zwar nicht, aber das sieht man ja am Änderungsdatum)

[himitsu]

Zitat von QuickAndDirty:

Wir hatten manchmal pakages und DCUs im Windows ordner

Die Packages (alte Delphi und scheiß Fremdkomponenten machen sowas immernoch gern da hin) sind eigentlich kein Problem.
Beim Build/Compile werden die .DCP genutzt, nicht die .BPL, also wenn, dann die entfernen.
BPL wird erst zur Laufzeit genutzut/geladen. Da kann es eigentlich keinen Unterschied zwischen Build und Compiler gegen, aber Debug und Nicht-Debug, jenachdem welches Environment von der IDE oder vom Windows an die Instanz übergeben wird.

PS: In der .d (DependencyInfo) steht auch, welche DCP verwendet wurde.
(wenn eine DCP nicht da drin steht, aber du sie im Requires hast, dann war sie unnötig und es wurde von ihr nichts gelinkt)

[Uwe Raabe]

Kannst du das Projekt mal so weit runter strippen (alles außer System.SysUtils raus), dass nur noch der Code in der DPR übrig bleibt und lediglich die Zeilen StartServer und StopServer auskommentiert werden müssen damit es compiliert?
Wenn es damit immer noch passiert, dann könntest du die DPR und die DPROJ hier hochladen. Andernfalls liegt es vermutlich in den nun entfernten Units.

[haentschman]

Danke...

Ich habe eure Infos ausprobiert. Letztendlich bin ich am Datenmodul(DataModuleServer) hängengeblieben und dann tiefer gegraben.

Der Fehler tritt auf (Debugging über die IDE oder standalone):

Delphi-Quellcode:

  System.SysUtils,
  DataModuleServer in 'Datamodule\DataModuleServer.pas' {XDataConnection: TDataModule}, // auskommentiert = ok
//  DatabaseEntity.Employees in 'Database\DatabaseEntity.Employees.pas',
//  DatabaseEntity.Appointment in 'Database\DatabaseEntity.Appointment.pas',
//  Assignment.Service in 'Service\Assignment.Service.pas',
//  Assignment.ServiceImplementation in 'Service\Assignment.ServiceImplementation.pas',
  XData.Server in 'Common\XData.Server.pas';
//  XData.Logic in 'Common\XData.Logic.pas',
//  XData.Preferences in 'Common\XData.Preferences.pas',
//  XData.TextConstants in 'Common\XData.TextConstants.pas',
//  XData.Constants in 'Common\XData.Constants.pas';

var
  InputText : string;

begin
  try
    {$IFDEF DEBUG}
    Write('Debug Version:80'); // Fehler 105 hier -> Wenn es funktioniert, dann ist an diesem Punkt schon das Konsolenfenster sichtbar...
    {$ELSE}
      {$IFDEF LIVE}
      Write('Release Version Live:80');
      {$ENDIF}
      {$IFDEF HAE}
      Write('Release Version HAE:81');

Delphi-Quellcode:

uses
  System.SysUtils, System.Classes,
  FireDAC.Stan.Intf, FireDAC.Stan.Option, FireDAC.Stan.Error, FireDAC.UI.Intf, FireDAC.Phys.Intf,
  FireDAC.Stan.Def, FireDAC.Stan.Pool, FireDAC.Stan.Async, FireDAC.Phys, FireDAC.ConsoleUI.Wait, Data.DB, FireDAC.Comp.Client, FireDAC.Phys.MSSQLDef,
  FireDAC.Phys.ODBCBase, FireDAC.Phys.MSSQL,
  Aurelius.Drivers.Interfaces,
  Aurelius.Drivers.MSSQL,
  Aurelius.Comp.Connection, Aurelius.Drivers.FireDac, Aurelius.Sql.MSSQL, Aurelius.Schema.MSSQL;
  xxx.Preferences; //xxx.Database.Base, xxx.Database; // auskommentiert = ok... drin = 105 - es reicht eine der Units :-(
type

PS: Jede andere Unit, die XData.yyy oben auskommentiert waren und die xxx.Preferences, xxx.Database.Base, xxx.Database in den Uses hatten, auch 105. In das Projekt zu integrieren brachte auch 105.
PS: Die xxx Units sind Units, die allgemeingültig im System Windows verwendet werden können.

Hinweis:
Der XData soll dann im richtigen Release ein Dienst sein. Da hilft es auch nicht, wenn der XData auch als VCL Anwendung möglich wäre.

...was soll ich nun machen? Trotzdem verstehe ich den Unterschied in der EXE nicht.

Zitat:

Andernfalls liegt es vermutlich in den nun entfernten Units

Mit "Compilieren" funktioniert es aber mit allen dieser Units...

[Uwe Raabe]

Es wäre jetzt wohl nötig die Sourcen der betreffenden Units zu sehen.

[jaenicke]

Und du startest die auf den beiden Wegen erzeugten Exe jeweils komplett identisch und kannst reproduzieren, dass die eine den Fehler ohne sichtbare Konsole wirft und die andere die Ausgaben in einer Konsole anzeigt?

Ich habe mal ChatGPT gebeten, eine Routine zu erstellen, die prüft, ob eine Konsole da ist und diese ansonsten erstellt. Testen kann ich das am Handy gerade nicht.

Delphi-Quellcode:

program ConsoleCheck;

{$APPTYPE CONSOLE}

uses
  Windows, SysUtils;

procedure EnsureConsole;
begin
  // Prüfen, ob eine Konsole vorhanden ist:
  if GetConsoleWindow = 0 then
  begin
    if AllocConsole then
    begin
      // Standard-Handles neu zuordnen
      AssignFile(Input, 'CONIN$');
      Reset(Input);
      AssignFile(Output, 'CONOUT$');
      Rewrite(Output);
      AssignFile(ErrOutput, 'CONOUT$');
      Rewrite(ErrOutput);
    end
    else
      RaiseLastOSError;
  end;
end;

begin
  EnsureConsole;
  Writeln('Hallo, Welt! Die Konsole existiert.');
  Readln;
end.

Damit sollte das zumindest umgehbar sein.

Hier kommen wir glaube ich am ehesten weiter, wenn du das Projekt so weit abspecken kannst, ohne dass der Fehler verschwindet, dass du es jemandem zeigen kannst (ggf. auch per PN).

[haentschman]

Danke für die Anteilnahme...

Zitat:

Und du startest die auf den beiden Wegen erzeugten Exe jeweils komplett identisch und kannst reproduzieren, dass die eine den Fehler ohne sichtbare Konsole wirft und die andere die Ausgaben in einer Konsole anzeigt?

Ja kann ich reproduzieren im Debugger. (Debug + Erzeugen) Mit den auskommentierten Units...kein Fehler, Console visible. Einkommentiert...105 ohne Fenster. (erste Zeile nach begin)

Zitat:

Es wäre jetzt wohl nötig die Sourcen der betreffenden Units zu sehen.

...ich mache mache was fertig. Aber erst am Wochenende...

Aber nochmal:
Wenn ich das Projekt schließe und wieder lade (mit allen Units!), dann "Compilieren" drücke...läuft. Danach, ohne Änderungen, "Erzeugen"...105. Da kann es ja nicht am eigentlichen Projekt liegen...eher an einer "Einstellung" im Delphi. Oder?

[Cypheros]

Bei "Compilieren" werden nur die Units neu kompiliert, die verändert wurden oder nicht in kompilierter Form vorliegen.

Versuch mal nach dem Neustart von Delphi und Öffnen des Projekts auf "Bereinigen" zu klicken. Wenn du nun "Compilieren" klicks, tritt dann der Fehler auf, wie bei "Erzeugen"?

[haentschman]

Zitat:

Versuch mal nach dem Neustart von Delphi und Öffnen des Projekts auf "Bereinigen" zu klicken. Wenn du nun "Compilieren" klicks, tritt dann der Fehler auf, wie bei "Erzeugen"?

Habe ich schon probiert, nach dem Neustart + "Compilieren", auch nach "Erzeugen" mit 105, ist alles schick.