XML bearbeiten im VBScript (FinalBuilder)

[himitsu]

[edit]
OK, ich komm um manuelles Speichern nicht drumrum, bei all dem Scheiß, den Emba da baut.

* Emba speichert mit UTF-8 BOM, MS-XMLDOM ohne BOM
* Emba speichert als HTML-Entity, MS-XMLDOM als "
* Emba speichert alles mit CRLF, Emba auch, außer die Zeilenumbrüche innerhalb dieses Nicht-CDATA-PostBuildEvent, welche als CR (nicht LF) gespeichert sind

Aber eine Lösung, wie die

Delphi-Quellcode:

"

unverändert blieben und nicht zu " würden, wäre dennoch toll.
[/edit]


Moin,

also genauer geht es um DPROJs.


Für Delphi XE hatte ich noch mit String-Replace rumgepfuscht,
aber für 11.x wollte ich das nun "richiger" machen.

Die 4 Leerzeichen, welche Microsoft.XMLDOM als Tab speichert, konnte ich nun doch lösen.
preserveWhiteSpace=True vor dem SAVE (nicht nur/schon vor dem Load)

Aber nun noch noch der nächste Schrott, den Delphi verbockt.

in der BASE heißt es noch

Delphi-Quellcode:

<PostBuildEvent><![CDATA["...

aber dann, obwohl es sich "eigentlich" nicht ändert, wird nochmal für jede Config ein

Delphi-Quellcode:

<PostBuildEvent>&quot;...

gespeichert.


OK, abgesehn davon, dass man nun sinnlos redundanten Dreck in der DPROJ hat (wunderschön für einen GIT-Diff),
speichert XMLDOM das

Delphi-Quellcode:

"

als

Delphi-Quellcode:

"

ab.

Im Node.Text ein Replace von

Delphi-Quellcode:

"

zu

Delphi-Quellcode:

"

würde natürlich

Delphi-Quellcode:

"

ergeben. :stupid:

Gibt es da nun irgendeinen Weg dem XML-DOM beizubringen das nicht zu ändern, bzw. die " in Node-Texten als

Delphi-Quellcode:

"

zu speichern? (außer im CDATA)
* der Code an sich funktioniert dennoch
* ich könnte diese Nodes auch einfach löschen und es wäre alles OK
* oder ich muß doch wieder nachträglich in der Datei Replacen
-> die ersten Beiden würden gehen, aber ergeben "beschissene" Änderungen im GIT-Diff, die dann später durch Delphi nochmals geändert wurden (ein krankes hin und her, mit nervigen Änderungen im Commit)


Also ein billiges StringReplace über den kompletten XML-Text .... nja, die meißten " müssen ja " bleiben.
Die kompletten Nodes Replacen, da müsste man aufpassen, wenn zukünftig dort etwas geändert würde-







Diesen PostBuildEvent-Bug gibt es nun schon ewig ... glaub nicht dass Emba das zeitnah repariert bekommt.

Code:

' in der Projektdatei die entsprechende Default-Config aktivieren (Release, Debug oder DebugOhneEurekalog)
function UpdateDefaultConfigInProjectFile(Action)
  File   = ExpandVarQuiet(Action.BuildFile)
  Config = FBVariables.MAKE_CONFIG

  set XML = CreateObject("Microsoft.XMLDOM")
  XML.preserveWhiteSpace = True
  XML.async = False
  if not XML.load(File) then call Err.Raise(1, "FinalBuilder", File + " not loaded : " + CStr(XML.parseError.errorCode) + " " + CStr(XML.parseError.reason))

  set Node = XML.selectSingleNode("//ItemGroup/BuildConfiguration[@Include='" + Config + "']")
  if Node is Nothing then
    Action.Echo "does NOT found Config '" + Config + "' in " + File
  else
    Action.Echo "found Config '" + Config + "' in " + File

    set Node = XML.selectSingleNode("//PropertyGroup/Config")
    Node.text = Config

    XML.preserveWhiteSpace = True
    if XML.save(File) <> 0 then call Err.Raise(1, "FinalBuilder", "write error")
  end if
end function

Ja, beim MSBuild kann ich via Parameter die zu verwendende Config übergeben, aber es soll dann auch im Delphi die entsprechende Config "standardmäßig" aktiv sein, beim Debuggen.

[himitsu]

Wie Uwe es bei seinem Project Magician wohl macht, dass die DPROJ dabei nicht kaputt geht?

effektiv geht es hier ja auf das hinaus
https://learn.microsoft.com/en-us/pr...57828(v=vs.85)

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1525156)

Wie Uwe es bei seinem Project Magician wohl macht, dass die DPROJ dabei nicht kaputt geht?

Ehrlich gesagt, weiß ich gar nicht, ob sie dabei nicht doch kaputt geht. Aber falls es relevant ist: Ich verwende NativeXML zur Bearbeitung.

[himitsu]

OK, vermutete du hattest da vielleicht selber schon damit gekämpft und entsprechend eine Lösung gefunden. :duck:


aktuell sieht es nun so aus

Code:

' in der Projektdatei die entsprechende Default-Config aktivieren (Release, Debug oder DebugOhneEurekalog)
function UpdateDefaultConfigInProjectFile(Action)
  File   = ExpandVarQuiet(Action.BuildFile)
  Config = FBVariables.MAKE_CONFIG

  set XML = CreateObject("Microsoft.XMLDOM")
  XML.preserveWhiteSpace = True
  XML.async = False
  if not XML.load(File) then call Err.Raise(1, "FinalBuilder", File + " not loaded : " + CStr(XML.parseError.errorCode) + " " + CStr(XML.parseError.reason))

  set Node = XML.selectSingleNode("//ItemGroup/BuildConfiguration[@Include='" + Config + "']")
  if Node is Nothing then
    Action.Echo "does NOT found Config '" + Config + "' in " + File
  else
    Action.Echo "found Config '" + Config + "' in " + File

    set Node = XML.selectSingleNode("//PropertyGroup/Config")
    if Node.text <> Config then
      Node.text = Config

      XML.preserveWhiteSpace = True  ' sonst wird aus 4-Leerzeichen ein Tab, bei der Einrückung
      'if XML.save(File) <> 0 then call Err.Raise(1, "FinalBuilder", "write error")
      Text = XML.xml

      ' aus nachfolgenden <PostBuildEvent>&quot;$(root)\... wurde <PostBuildEvent>"$(root)\...
      ' im ersten <PostBuildEvent><![CDATA["$(root)\... ist und bleibt alles OK
      ' es funktioniert zwar dennoch, aber im GIT-Diff/Commit wäre es blöde
      Line = "<PostBuildEvent>&quot;$(root)\Build\dproj__compile_postbuild.cmd&quot; &quot;$(Config)&quot; &quot;$(Platform)&quot; &quot;$(OutputExt)&quot; &quot;$(InputDir)$(InputName)&quot; &quot;$(OutputDir)$(OutputName)&quot;"
      Text = Replace(Text, Replace(Line, "&quot;", """"), Line)
      Line = "<Debugger_Launcher>/usr/bin/xterm -e &quot;%debuggee%&quot;</Debugger_Launcher>"
      Text = Replace(Text, Replace(Line, "&quot;", """"), Line)

      ' innerhalb der Nicht-CDATA-PostBuildEvent wird vom Delphi nur CR gespeichert (nicht LF), aber überall sonst als CRLF
      Text = Replace(Text, vbCrLf + "</PostBuildEvent>", vbCr + "</PostBuildEvent>")

      ' Außerdem speichert Delphi inkl. UTF-8 BOM, aber XML.save tut das nicht
      set fh = CreateObject("ADODB.Stream")
      fh.Charset = "UTF-8"
      fh.Open
      fh.WriteText Text
      fh.SaveToFile File, 2   ' 2=adSaveCreateOverWrite
      fh.Close
    end if
  end if
end function

bzw. im alten XE-Script

Code:

    ' XE hatte alles um einen Tab eingerückt und eine Leerzeile am Ende ... also das für GIT nun wieder rein
    Text = vbTab + Replace(Text, vbLf, vbLf + vbTab)
    if Right(Text, 1) = vbTab then Text = Left(Text, Len(Text) - 1)  ' Trim/RTrim entfernt keine Tabs/Zeilenumbrüche

Wobei ich ja eigentlich "nur" das machen wollte

Code:

' in der Projektdatei die entsprechende Default-Config aktivieren (Release, Debug oder DebugOhneEurekalog)
function UpdateDefaultConfigInProjectFile(Action)
  File   = ExpandVar(Action.BuildFile)
  Config = FBVariables.MAKE_CONFIG

  set XML = CreateObject("Microsoft.XMLDOM")
  if not XML.load(File) then call Err.Raise(1, "FinalBuilder", File + " not loaded : " + CStr(XML.parseError.errorCode) + " " + CStr(XML.parseError.reason))

  set Node = XML.selectSingleNode("//ItemGroup/BuildConfiguration[@Include='" + Config + "']")
  if Node is Nothing then
    Action.Echo "does NOT found Config '" + Config + "' in " + File
  else
    Action.Echo "found Config '" + Config + "' in " + File

    set Node = XML.selectSingleNode("//PropertyGroup/Config")
    if Node.text <> Config then
      Node.text = Config

      if XML.save(File) <> 0 then call Err.Raise(1, "FinalBuilder", "write error")
    end if
  end if
end function

Aber damit sich FinalBuilder, Delphi und Git nicht streiten und dann "Änderungen" zeigen, welche es garnicht gibt, bzw. es nicht sinnlos gegenseitig hin-&herkonvertieren ...........

[himitsu]

Zitat:

NativeXML

Hmmm, so im Groben und Ganzen scheint das gleicht zu arbeiten,

ist aber im VBScript aber so wohl nicht nutzbar.

Bliebe nur noch die Frage, ob man MSXML gleich arbeiten lassen kann. :cry:




ProjectMagicianCmd mit -n , -r , -x , -f , -d und -uwp ausgerufen
und dann das Projekt nochmal in 11.3 geöffnet und neu gespeichert.

Danach ist vom -r das Linux und Android aber wieder drin.

Zusätzlich noch TargetedPlatforms=1 und aus <Platforms> gelöscht, bleiben die dann auch weg.

Hatte mich eh schon immer etwas genervt (schonmal per Hand gelöscht hatte), weil ist ja ein VCL-Programm

Delphi-Quellcode:

<FrameworkType>VCL</FrameworkType>

und unterstützt das eh nicht.

Code:

        <TargetedPlatforms>3</TargetedPlatforms>
...
            <Platforms>
                <Platform value="Android">False</Platform>
                <Platform value="Android64">False</Platform>
                <Platform value="Linux64">False</Platform>
                <Platform value="Win32">True</Platform>
                <Platform value="Win64">True</Platform>
            </Platforms>

Sooooooooooo ... BOM ist vorhanden, auch die &quot; bleiben, nur beim PostBuildEvent ist etwas nicht ganz in Ordnung (für GIT, aber die Funktion geht) und Delphi ändert es wieder zurück.

Original

Code:

        <PostBuildEvent><![CDATA["xxxx.cmd" params
$(PostBuildEvent)]]></PostBuildEvent>

ProjectMagician

Code:

        <PostBuildEvent>
            <![CDATA["xxxx.cmd" params
$(PostBuildEvent)]]>
        </PostBuildEvent>

[add]
Ohhh, man kann auch alle Parameter gemeinsam nutzen.
Die Hilfe laß sich so, als ginge es nur einzeln.
(hatte es dennoch grade mal so probiert)

Delphi-Quellcode:

ProjectMagicianCmd [-v:<version> | -n | -r | -x | -f | -d | -uwp] [<filepath>]<filename> [-l:<logfile>] [-s]

anstatt

Delphi-Quellcode:

ProjectMagicianCmd [-v:<version>] [-n] [-r] [-x] [-f] [-d] [-uwp] [<filepath>]<filename> [-l:<logfile>] [-s]

Im IDE-Package gibt es ein "Clean Line Feads".
Wie gesagt, da muß du etwas aufpassen, da teilweise wirklich CR statt CRLF vorkommen. (genauso, wie ein RichEdit ja intern #13 als LineFead benutzt und die Delphi-Komponente das nur bruchteilhaft im VCL-TRichEdit konvertiert)

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1525202)

Im IDE-Package gibt es ein "Clean Line Feads".
Wie gesagt, da muß du etwas aufpassen, da teilweise wirklich CR statt CRLF vorkommen. (genauso, wie ein RichEdit ja intern #13 als LineFead benutzt und die Delphi-Komponente das nur bruchteilhaft im VCL-TRichEdit konvertiert)

Das betrifft aber nur pas- und dpr/dpk-Dateien beim Öffnen in der IDE. Ist in Delphi 11 ja eh schon eingebaut.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1525202)

nur beim PostBuildEvent ist etwas nicht ganz in Ordnung (für GIT, aber die Funktion geht) und Delphi ändert es wieder zurück.

Original

Code:

        <PostBuildEvent><![CDATA["xxxx.cmd" params
$(PostBuildEvent)]]></PostBuildEvent>

ProjectMagician

Code:

        <PostBuildEvent>
            <![CDATA["xxxx.cmd" params
$(PostBuildEvent)]]>
        </PostBuildEvent>

Ja, das ist bekannt und wird von NativeXML so umgesetzt. Da es faktisch nicht relevant ist und bisher auch nur selten benutzt wurde habe ich das erstmal dabei belassen.

[himitsu]

Zitat:

LineFeed

Ahhh, OK.


Ja, funktional stimmt es ja, da die Daten im CDATA nicht geändert werden.
Ist halt nur bissl blöd unpraktisch in einer Versionierung, wenn sich das Tool und die IDE gegenseitig bekämpfen.


OK, nervend ist es auch, wenn die IDE manchmal bei jedem Speichern die DPROJ bissl umsortiert.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1525210)

OK, nervend ist es auch, wenn die IDE manchmal bei jedem Speichern die DPROJ bissl umsortiert.

Gerade das sollte der Project Magician aber abfangen. Wenn nicht, hätte ich gern einen TestCase...

[himitsu]

Ja, beim Delphi ohne Magican. :zwinker:

Aktuell hab ich keinen Fall, aber im 10.4 und 11.2 hatte ich das paar mal gehabt.



Hatte schomal Emba wer gefragt, warum die nichts sortieren?
Wäre zu praktisch, sie würden eine XLST erstellen, selber nutzen und sie auch teilen.


Und meinen anderen Wunsch, wo ich seit Tagen vor hatte den mal ins QC zu stellen.
-> warum die Configs cfg_<nr> heißen und nicht so wie die Config, vor allem da es schon mehrmals vorgekommen ist, dass z.B. Debug=Cfg_1 und Release=Cfg_2 aber dann auch mal Debug=Cfg_2 und Release=Cfg_1 ... wie soll man da diesen Mist "lesen" können?



Außerdem wird es mal Zeit, dass die ihre abgeleitete Config ordentlich hinbekommen. (schon seit Anfang bis jetzt)
Wie zu Beginn genannt, das <PostBuildEvent> einmal mit CDATA in der Base (oder wo man was in den Projektoptionen einstellt)
und dann nach den <Import Project=....> nochmal viele Ableitungen ohne CDATA, die aber eigentlich unverändert sind und somit garnicht gespeichert werden sollten.

Code:

    <Import Project="$(MSBuildProjectName).deployproj" Condition="Exists('$(MSBuildProjectName).deployproj')"/>
    <PropertyGroup Condition="'$(Config)'=='Debug' And '$(Platform)'=='Win32'">
        <PreBuildEvent/>
        <PreBuildEventIgnoreExitCode>False</PreBuildEventIgnoreExitCode>
        <PreLinkEvent/>
        <PreLinkEventIgnoreExitCode>False</PreLinkEventIgnoreExitCode>
        <PostBuildEvent>&quot;....&quot;
</PostBuildEvent>
        <PostBuildEventIgnoreExitCode>False</PostBuildEventIgnoreExitCode>
    </PropertyGroup>
    ....

PS: Räumt dein Magican auch die <Import> auf?
Beim Upgrade von Projekten tut Delphi diesen Teil leider nicht aktualisieren.
Im Inline-Compiler kompiliert fällt es nicht auf, da Delphi eh das halbe MSBuildScript ignoriert und es wirklich nur als ConfigsSpeicher benutzt.
Aber im MSBuild, oder wenn in den Projektoptionen "mit extern Kompilieren" aktiv ist, dann raucht MSBuild ab, bzw. es fehlt die Hälfte vom Delphi-Zeugs, weil's ja nicht importiert wird.