The curse of the Project.res file
We’ve switched to #10Seattle for our production code, and we had a lot of “fun” figuring out why our FinalBuilder produced .exe files did not run, but stopped with “The application has failed to start because its side-by-side configuration is incorrect.” It turned out that FB8 used a default manifest from RS which looked looked like this
So – we tinkered with the settings and asked FB8 to load the manifest from the resource file. Nada. Zip. Zilch. It was not there. It turned out that you had to compile locally, then commit the .res file to make the manifest appear.
The Project.res files are always a bit of an annoyance, and we are perhaps a bit inconsequent how we resolve a conflict on SVN update – use local, or use theirs. This means that it is a bit iffy what actually survives in the .res file. In the end, we’ve ended up making individual .manifest.xml files for each app – and explicitly include it in the FinalBuilder configs. This means that if we make modifications to the manifest somehow, we need to upload that file separately.
The .res file conflicts are a worse problem than two people making changes to a .dfm – as the .dfm is text and can be resolved – while the .res file in binary and not human readable.
It really is beyond me why there is no Project.rc file which includes
and so forth.
That way, the .res file would be a compile-time thing (or even a thing of the past) – and the resource linker would assemble the various bits from their individual sources.
It would probably make it way easier for Finalbuilder to dig into the resources and/or override where needed and it would certainly make the VCS .res file conflicts a thing of the past.