Delphi XE2 version resource issue

FinalBuilder Discussion
1

It appears that Embarcadero have made some unhelpful decisions about version resources in XE2.   Leaving aside FB for a moment, I found that XE version resources, on conversion of a project to XE2, are moved into a new place in the DPROJ file, in a position logically above the 'platform' at the 'configurations' level.  From here they are NOT inherited by the individual platforms, so if you simply build your project in the XE2 IDE it ends up with missing resource strings (eg no company, copyright etc.).  At the same time the original XE2 resources are 'parked' where they always used to be in the DPROJ (in the Project Extensions / Borland Personality), but I find that they are no longer updated there by the IDE.

For users who do not have FB, and who use IDE builds, it seems that you have to manually copy each resource string from the 'configurations' level into the platform level in order ro get them to appear in the executable.  This is extremely tedious, but in theory I could write a program to fix up all my DPROJ files and replicate the 'all configurations' items in the separate platform levels (we will only need 32-bit platform for a while).

The bigger problem with this solution is that it appears that FinalBuilder is still picking the version resources from the 'old' location in the DPROJ, or perhaps from the project itself via the ToolsAPI, which still returns these same values.  But these will soon get out of step with those visible in the XE2 IDE, since the IDE no longer maintains them in the old location.

I thought that I could work around the Embarcadero change by switching to maintain the version resources in FB.  This is great as far as my executable is concerned: I can keep the version resources in FB as the master copy, and no manual work is needed on upgrading from XE to XE2, and the resources are correct in the EXE.  But if I tell FB to update the resources in the project, it updates the 'old' VERSIONINFO resources in the DPROJ, not those that are visible in the XE2 IDE. So when working in the IDE, I cannot check the real version resources without referring to the master copies in FB.

Do you agree with my analysis of the situation, and do you have a solution?   One approach would be to switch FB to use the 'all configurations' version resources and ignore the ones it has used up to now in the Borland area of the DPROJ.  This would solve most of the problems for most people, unless they have separate version resources for different platforms.  Handling this properly in FB would need the same base/configuration/platform hierarchy in FB to maintain separate version resources there.  If you decided to do this, I assume you would implement sensible inheritance, unlike the IDE which appears to need the resources replicated at every level.

For our own purposes, we would also like to have program control over the resource strings (we currently use ToolsAPI for this, prior to an IDE build) and I have not yet found a way to access from the ToolsAPI the new resource strings that are maintained in the XE2 IDE. You may know of a way to do this (or do you currently work directly with the XML in the project file?).

 

2

Hi Tim

I can’t tell you how many issues we had with XE2 without violating their NDA… but needless to say the version info changes were not pleasant to deal with.

For XE2 we load the version info from the platform+configuration level, however configurations use inheritance, so we we have to walk the inheritance tree up to the base configuration because not all values are stored at the configuration level, only those overridden in the configuration. You need to specify the correct Platform and Configuration in the FinalBuilder Delphi Action.

We don’t use the Tools API, we just read the dproj file as an xml document. You would probably be surprised at the amount of code we have in FinalBuilder to deal with version information in Delphi projects, just about every version of Delphi changes the format, and sometimes in subtle ways that we only discover down the track though our customers - the dof/bdsproj (mulitple versions of, with no real way to tell)/dproj file format, and how they work has never been documented. BTW, the ‘parked’ version info is never used by XE2, it’s put there for compatibility with older versions of delphi, it never gets updated either.

If you have a project (dproj) where we are failing to load the version information then send it in to support so I can test with it here and see what is happening.

As for updating the values… it should be doing it at the platform_configuration level, I will have to check our code. I would not be suprised to see that something has changed in the release build of XE2, it’s been a moving target from day -365.

I’ll add my usual answer with regards to version information and IDE builds. It really shouldn’t matter, your automated build environment should be where version information is maintained, builds made with the IDE should never be escaping the developers workstation anyway.

3

Thanks for your response. It looks to me as if FB is correctly picking up the XE2 version resources. The problem is that when FB is told to update the resources in the project, it seems to update the old resources in the Borland area of the DPROJ, which are ignored by and invisible in the IDE. Let me know if you cannot reproduce this and I will try to create an example. The second issue, that the XE2 IDE is not using resource inheritance (down to the platform) when compiling and creating an EXE or DLL is of course not your problem!

I agree with you about IDE builds not escaping, and they do not escape here. The principal reason we have historically wanted to tie the version numbers to the IDE is to make it easier to record and document changes in the source code. We also need to record the dates of last change and version numbers inside the source code, for licence control purposes, hence our use of the ToolsAPI in the IDE. Up to now we have been using a separate version number for each product subsystem and in some cases individual Delphi projects, but we are planning to change this to use a universal version and build number maintained by FB. Until we do this, we will continue to despair every time Embarcadero change the rules, as it seems you do also.

4

Hi Tim

I’ll take a look at this first thing tomorrow when I get into the office, we were planning on an official update tomorrow but we’ll hold off and make sure this is sorted first.


5

Hi Tim

Today’s update build includes a couple of fixes for the Delphi XE2 version info, I found that the IDE does not create a node in the dproj for config/platform combinations unless you modify the settings for the config, FinalBuilder was failing to write the version info if this node was not found, the update now creates the node if needed.