Skip navigation

So I have a scenario where this guy’s question might apply. He’s looking to pack resources in with a .lib file, but that simply won’t work, as the file format doesn’t allow for it.

Thing is, my .lib is compiled in the same build sequence as the application it’s supposed to be pulled into, so perhaps I have a little more leeway. A couple things I’ve discovered:

  • It doesn’t matter if you completely hose the syntax inside of one of a .rc file’s TEXTINCLUDE sections. Failures in there will not propagate out and indicate a build failure; your app will compile fine, but you won’t have any resources.
  • Similarly, if you mess up the path to a .rc file you’d like to include, again, build errors won’t propagate out; you’ll just be missing the resources from that file.

Both of these mean that Roger Lipscombe’s 3rd solution, and jeff_t’s elucidation of that approach are very error prone. Even if you get it to work, it’ll likely take you a while to get it right, and you won’t know until you inspect the contents of of your resulting .DLL or .EXE module to see if the resources you’re looking for made it in. Maybe you can do that in a post-build step, but now we’re layering on more complexity, so we look somewhere else.

To take a different tact, you could add the path to your .res file to your main project’s linker options’ additional include directories, and then add your .res file to your inputs for that linker instance. In the past, I’ve found that approach to be error prone; if you have a bunch of project configurations, you need to make sure that that’s applied across all of them. That’s an additional step, which is an additional opportunity for error, and that particular error has bit me many times in the past. So we look somewhere else.

Another approach might be to try using #pragma comment(lib, “library.res”) and #pragma comment(linker, “/INCLUDE:path/to/library/”), surrounded by an IFDEF guard, in one of the headers that gets pulled into your main project. Except while the above approach works great with your .lib file, and while you can put .lib and .res files next to each other under inputs in your project’s linker settings, the above approach won’t work with your .res file. You get another silent error.

There’s really no good solution to pulling in .res files; they don’t have semantic parity with the same features and mechanisms that can pull in .lib files, despite some superficial similarities in their linking semantics. And everything that doesn’t work is a silent failure, until your program fails to find a resource at run time.

Advertisements

3 Comments

    • Coderjoe
    • Posted February 4, 2012 at 12:52 am
    • Permalink

    How about creating a project property sheet with the required additions. then, all you need to do is add the property sheet to the projects that need it, which is a bit simpler than manually adding the .res/.rc to the linker options.

    • Tried that before, with DirectX dependencies, but that approach got reverted because it was blamed for breaking something else, and under what circumstances do they conflict? As I recall, we also had to create a property sheet per arch. (I know we had to do them per-config, but that’s because DirectX has redistributable and non-redistributable forms.)

        • Coderjoe
        • Posted February 4, 2012 at 1:25 am
        • Permalink

        Well, that was because, with DirectX, you have four different versions of the libraries to link against: x86 vs x64 and release vs debug. I don’t think you would have quite the same problem with a resource file. Plus, with DirectX, you had to find the proper location elsewhere on the system, while the resource file should be in a known directory within your $(SolutionDir)


Comments are closed.

%d bloggers like this: