Project Options -> Version Info aka. dproj madness

[Attila Kovacs 617]

Just found out that if I uncheck the "Include version information in project" under Project Options -> Version Info, it will add the "<VerInfo_IncludeVerInfo>false</VerInfo_IncludeVerInfo>" to the dproj file and it stops inheriting the version info settings....

Is that still the case in the current IDE?

 

[Uwe Raabe 1891]

Can you elaborate on what do you expect instead?

[Attila Kovacs 617]

1 hour ago, Uwe Raabe said:

Can you elaborate on what do you expect instead?

Of course. The state as if it were never checked, without explicit "false" in the dproj, inherinting the settings from above.

[Pat Foley 50]

To view the dproj file more readily, I used treeview's save to file to remove some of the nesting of xml files. 

Output << Memo << Treeview.save << TreeView from xml file.  

 

// Only 64 release information checked. DCC still shows//

...

PropertyGroup
    DCC_DcuOutput
        .\$(Platform)\$(Config)
        
        ...    
        
        VerInfo_Locale
        1033
    VerInfo_Keys
        CompanyName=;// DCC still outputs regardless of switch //


...

PropertyGroup
    AppDPIAwarenessMode
        PerMonitorV2
    VerInfo_MajorVer
        2\
    VerInfo_Keys
        CompanyName=Pat set memo to word wrap;//
        ...
    VerInfo_IncludeVerInfo
        true

 

[Uwe Raabe 1891]

8 hours ago, Attila Kovacs said:

inherinting the settings from above.

Unfortunately, changing any version information values at least once will break inheritance and the values in that build configuration have their own life. There is no built-in way to establish inheritance - unless the entries are removed from the dproj with some exterenal tool.

 

That is the reason why Project Magician has this option 

Quote

Clear Settings in Child Configurations

Sometimes the inheritance of settings implemented the project files is not wanted and leads to a lot of work or unexpected results. For instance having different version info values for each build configuration is rarely required. Changes made to one configuration are not visible in others. In addition inheritance doesn't work well with these either. Changes in the base configuration have no effect if values in depending configurations exist.

 

This functionality removes all child settings reverting back to the base settings. Only the base settings are used and changes to depending settings are ignored!

 

Version Info

All version info settings in child configurations are removed and the base settings put in charge again. The only exception are the Module attributes, allowing different attributes per build configuration. For pure Windows projects the settings in the base configuration will be kept, while for mixed OS projects the settings in the platform base configuration will serve as a basis.

 

Application Settings

All application settings in child configurations are removed and the base settings put in charge again. This effects the Icons, Manifest File, Output Settings and Appearance. Application settings are always platform based and thus the settings in the platform base configuration are the ones to be kept.

 

Package Settings

All package settings in child configurations are removed and the base settings put in charge again. This effects the Prefix, Suffix and Version as well as the Description and Never Build option.

 

[Attila Kovacs 617]

16 minutes ago, Uwe Raabe said:

That is the reason why Project Magician has this option 

Quote

Great, but this should be working in the IDE. Before I report this misimplementation, I wanted to know if it's still the same in the current IDE.

 

[timfrost 73]

In my experience the bugs in the project settings hierarchy have varied from version to version, but never gone away entirely.

[Uwe Raabe 1891]

10 hours ago, Attila Kovacs said:

Before I report this misimplementation

I guess you already did: https://quality.embarcadero.com/browse/RSP-33469

[Attila Kovacs 617]

oh. now that's interesting 😄

[stijnsanders 35]

What I typically do to get it right, is open the dproj in a text editor, and remove all of the `<Ver`* elements that are not inside of the <PropertyGroup Condition="'$(Base)'!=''">` element, then only change the version info in the IDE with 'Target' set to 'All Configurations'

[mvanrijnen 121]

Yes, i always have to set the version multiple times also in the IDE, 

Would be nice if there was an apply to child configs (All->Win32->Release/Debug) etc.

Or better a checkbox with a Single Version option, which then makes sure the version is applied to all configs. 
 

[Uwe Raabe 1891]

Project Magician follows a different scheme: It has an option to remove all child entries so that only the base values are effective. Unfortunately it doesn't force you to change base values only nor does it warn if you don't.

[dummzeuch 1397]

Since the version info stuff never really worked very well since at least Delphi 2005, I don't use the IDE to manage the version info but create a version info resource externally and link it to the executable. As as side effect, I have no more annoying changes in the dproj file that show up in SCM with every build.

[Attila Kovacs 617]

15 minutes ago, dummzeuch said:

Since the version info stuff never really worked very well since at least Delphi 2005, I don't use the IDE to manage the version info but create a version info resource externally and link it to the executable. As as side effect, I have no more annoying changes in the dproj file that show up in SCM with every build.

I also need it in the IDE because I store essential information in it. Perhaps it's not the best practice, but that's how it currently is.

Uwe's solution to remove child entries seems to be the best option, as it usually is when he comes up with something. However, this issue should also be addressed in the IDE itself. At the very least, they should consider hiring that expert and incorporating their solution into the IDE.

[Tom Chamberlain 45]

We use a set of shared resource files,  one for the EXE's and another for the DLL's (the filetype changes) and leave the IDE out of it.  We have our own mass build process for production (the only time we care about the version numbers and things) with the option to update the version number, it changes and rebuilds the resource files before starting any compiles so we always have the correct versions for production.

[Uwe Raabe 1891]

21 minutes ago, dummzeuch said:

create a version info resource externally and link it to the executable

That is actually what my build server (resp. FinalBuilder) does here. That is only one reason, why I avoid creating any exe on my development system and send it to a customer.

 

Just now, Attila Kovacs said:

However, this issue should also be addressed in the IDE itself. At the very least, they should consider hiring that expert and incorporating their solution into the IDE.

I would love to see a reliable solution in the IDE itself. For compatibility reasons I suggest to add a special entry to the configuration combo which handles the storage in the base configuration and clear all child configurations.

 

One has to remember that the version info dialog for Win32/Win64 only projects differs from those targeting other platforms, too. The former can handle that in the base configuration, while the latter has to do it in the platform bases. The reason is that different platforms follow different rules.

[Attila Kovacs 617]

I also have a build server where I generate the resource from a template, but I still need it in the IDE.

Just saying. 😉

[dummzeuch 1397]

54 minutes ago, Attila Kovacs said:

I also have a build server where I generate the resource from a template, but I still need it in the IDE.

Just saying. 😉

I haven't got a build server, but use the post build event in the IDE (and in command line builds) instead.

[mvanrijnen 121]

1 hour ago, dummzeuch said:

Since the version info stuff never really worked very well since at least Delphi 2005, I don't use the IDE to manage the version info but create a version info resource externally and link it to the executable. As as side effect, I have no more annoying changes in the dproj file that show up in SCM with every build.

quick howto? 

 

[dummzeuch 1397]

20 minutes ago, mvanrijnen said:

quick howto? 

https://blog.dummzeuch.de/2015/09/26/using-my-buildtools/

 

Actually, it's even older:

 

http://www.dummzeuch.de/delphi/dzprepbuild/englisch.html

Edited August 4, 2023 by dummzeuch

[Vincent Parrett 657]

Of course I am biased, but everyone should have a build server 😉

 

FinalBuilder makes setting version info trivial 

https://www.finalbuilder.com/resources/blogs/managing-delphi-version-info-with-finalbuilder

 

[mvanrijnen 121]

On 8/5/2023 at 4:17 AM, Vincent Parrett said:

Of course I am biased, but everyone should have a build server 😉

 

FinalBuilder makes setting version info trivial 

https://www.finalbuilder.com/resources/blogs/managing-delphi-version-info-with-finalbuilder

 

yes, we are working on that also.

 

[Terry Peterson 0]

On 8/3/2023 at 1:48 AM, Uwe Raabe said:

Unfortunately, changing any version information values at least once will break inheritance and the values in that build configuration have their own life. There is no built-in way to establish inheritance - unless the entries are removed from the dproj with some exterenal tool.

 

That is the reason why Project Magician has this option 

 

Thanks, Ewe!  I've just stumbled upon your long-standing solution to the problem that has vexed me through several generations of Delphi.