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
$(asmv3_application)
$(dependency)
$(trustInfo)
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
Project.version.rc
Project.icon.rc
Project.themes.rc
Project.manifest.xml
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.
“It really is beyond me why there is no Project.rc file which includes… That way, the .res file would be a compile-time thing” Yes. That’s how res files are supposed to work! And the IDE could still provide an editing interface to the special project RC file.
If your solution is to include the manifests in the FB settings, why not add a Project.rc file to your project? I always manually manage my app’s version numbering and details through .rc files – part of the build process is to update the version – and bypass the IDE completely, so perhaps you can do the same for manifests too?
to bad also that DCC32 do not take RC file into account
{$R ‘Version.res’ ‘Version.rc’}
RC files need to be compiled with BRCC32 first.
FB injects our version numbers from the build system, but I could and perhaps should add my own project.rc – but that would only be fixing part of the problem.
The curse part is the intersect between human editable content and computer generated content in RS – and the problem of managing the compile induced changes in the binary .res file – contra manually edited changes in Project Options – and knowing when to “use local” contra “use theirs” on the conflicts.
Paul TOTH FB handles building .RC files before .exe files too.
A more accurate problem description is probably that the .res file contains content configurable from the RS IDE – which is not stored in plain text anywhere – and that hence can not be cleanly merged in a VCS.
Then again – putting stuff in text files doesn’t necessarily fix everything. the new .stat file is a new cause of conflicts – and since it contains accumulating numbers – it too cannot be merged.
In my view there’s no point in letting the IDE get involved in any of this. Script it all up yourself. Crikey, we’re all capable of writing these amazingly complex programs, how hard can it be to script the creation and compilation of a couple of .rc files?
I do not use FB, on my SVN I have the full source of the projects and a CMD file that build the project from a standard Delphi installation.
So to compile the project you just need a SVN client and a fresh Delphi installation. that’s all.
David Heffernan I can do that. It would be better if the IDE didn’t force me to do that – hence the rant.
Then there is the issue with the “new guy” adding something to the .res file because he didn’t know about the .rc regime. What happens with duplicate resources? Workarounds are problems waiting to arise again.
Lars Fosdal No, it’s better that you developers take responsibility for what they build. Leaving it to chance is just sloppy. And the new guy? The guy that you didn’t train properly? The guy whose commits you didn’t review? Again, that’s on you.
If the tool was smarter, it would ensure us sloppy people made less damage. Forgive us for not being perfect.
Lars Fosdal Smarter tools? Easy to say, hard to implement.
It saved us a lot of time to set up a proper process for “external” .rc/.res handling and getting rid of the res files created by the IDE. It avoided problems like proper app icon support starting in XP and Vista, correct handling of version numbers, correct creation of manifest files (supportedOs, requestedPrivileges …) and so on.
The time for getting the resource handling out of the hands of the IDE was well invested.
I couldn’t agree more with what Fred Ahrens said. Having taken control of the process has been very important to us on many different occasions.
Fred Ahrens – And here is the proof in the pudding – we all need to set up workarounds because the current solution is not working.
David Heffernan That is indeed true – both MS and EMBT/Idera are still trying to perfect theirs, and taking their time to do it too…
Lars Fosdal Well, perhaps you should fix your current solution.
David Heffernan I think Lars is referring to the IDE’s functionality as the current solution. (Am I right Lars Fosdal?) So, fixing it would either modify the IDE, or do something else, like RC files.
David Millington The fix is to stop relying on the IDE. It’s not up to the task.
The workaround is to stop relying on the IDE.
The fix is to improve the IDE so that the workarounds no longer are necessary.
Lars Fosdal Not possible in general. You are never going to come up with a general purpose build process that can support all possible users.
Lars Fosdal We have not a single tool that’s perfect or without errors/problems – and I assume this will always be the case. But the combination of the selected tools and processes almost is perfect – almost …
Looking back at all the years where we had to find workarounds for (let’s call it) glitches in our main tool, we always ended up with a nice solution that gave us more flexibility but also stability in the development and release process.
David Heffernan Something as relatively trivial as separating user configurable content from the compile time generated content in the .res file would go a long way though.
Lars Fosdal Even if such a tool was feasible, we don’t have it, so you should just build something that serves your needs and move on.
David Heffernan I did build something that serve my need and move on – as described in the post. That doesn’t stop me from desiring a better solution. By your definition it seems that requesting improvements are a no-no. I am not built that way. Plant an idea – and if it has merit, it will grow – in spite of all the nay-sayers.
Ok, I’ll be the one to write: is there a QP requesting changes here?
I write this all the time, but it’s worthwhile. If you post a QP report, I will vote for it.
I’ll add the QP when they add the promised “Feature/suggestion” category that Marco mentioned the other day. Until that is in place, it will just be closed with “works as designed” – which is technically accurate, but still inaccurate as it doesn’t really work well the way it is designed now.
Lars Fosdal Sure. When they do can you post it here please? I do believe in posting QP links and asking for votes 🙂
David Millington – Roger that.
BTW: For themes – (which we still are not using) – what will I need to do with regards to resources if I want to take them out of the .res file?
Not sure re themes – you’ll need the theme manifest, but I think (?) you can have the Enable theme support checkbox checked while still not including version info, which means your RC file won’t need to include it.
In older versions you set Runtime Themes to None and include link the manifest. You need to do your own manifest anyway to get all the other settings that are important.
In Seattle you set Manifest File to none and again do the rest yourself.
Thanks, David. I’ll be playing around with it for one of the admin tools to see how much work it is to make it play nicely with the variety of controls that we use. Strangely, the visual appearance of an application seems to have a magical effect on some pointy haired boss types.
Lars Fosdal A few years ago (I think one year after Vista came out) we made a survey about what our customers expect from our software. The vast majority voted for a nicer look. Not new features, not better stability and not better usability – nothing we developers would pick first. The most voted item was “modern look”.
Even during the last few years I was able to impress management just by enabling VCL themes.
Uwe Raabe Why do most men prefer sexy women rather than smart women? Because they are better in viewing than thinking! :o)
I’m with Fred Ahrensand David Heffernan on this. Use scripts. Don’t rely on the IDE. Some of The data is in the .dproj files, but it’s incomplete and trashed by IDE version updates too often over many Delphi versions.
From this post (https://plus.google.com/u/0/116430453567926016001/posts/PkNP5VwMJTL?cfem=1), I just add the RC to the project and compile and the iDE will do the rest for me. Of course this won’t work for CI builds but it is a step in the right direction IMO.
Lars Fosdal We build FinalBuilder with FinalBuilder, and have been including a manifest etc for many years. We long ago stopped relying on anything in project res. The only thing it is used for is version info and the mainicon (the IDE gets confused if don’t do that).
Point FinalBuilder at your own res file, and compile any rc files you need. We have those files in version control so developers can compile, but we always compile all resources from .rc files during the build process. We have different rc files for different resources, makes it easier to find which one to edit when adding resources.
As for including the default manifest, FinalBuilder initially (ie when adding the delphi action) get’s it from the dproj file or from the project.res. It looks like D10 (or perhaps an earlier version) has changed the default manifest file to a template file, so that is problematic. We’ll have to look and see what it does with the template and perhaps change FinalBuilder’s behavior for D10 and later when presented with the templated manifest file.
Vincent Parrett Just to be clear, I am not blaming FinalBuilder for these antics! It would probably be nice to handle that default manifest in some way. Still, I do think that the Project.res is way overdue for a redesign, but until that happens, we follow the best practices as outlined by the comments in this thread.
/zilchworks
Vincent Parrett I don’t let the IDE handle anything. No problems here taking over main icon and version resource.
David Heffernan I don’t let the IDE handle resources, but FinalBuilder does use the project res for version info and the main icon, we generate a project.rc file and compile it as part of compiling a delphi project.
/sub