Visual Studio Application Resources: 'Icon and manifest' vs 'Resource file' issues

Question

In Visual Studio 2010, there are two options on the Application properties page regarding Resources:

• Icon and manifest
• Resource file

I have been using the Resource file approach, because it is the only way to achieve one of my build requirements.

But, I've recently noticed a problem.

When you right click on an EXE file in Windows Explorer, click properties, and go to the details tab, it shows several pieces of information (file description, product name, product version, etc.)

When I build my app using Icon and manifest, all the assembly information that I enter in Visual Studio is used to populate these information fields.

But when I build using Resource file (as I am doing), these fields are NOT populated. They are blank.

Can anyone help?

• Is there something I'm doing wrong? Should this information be added to my custom resource file? (I've been searching this possibility with no luck)
• Is there another way to populate this information?
• Must I just go back to the Icon and manifest method? (In which case I'll have to re-think some other issues)

Answer 1

I just had the same question and found this information helpful.

By selecting a .res file you've basically said that you are going to handle all win32 resources yourself. That means that you have to include a manifest resource and a Version resource in your .res file. The standard AssemblyVersion, AssemblyProductVersion attributes have no effect if you've selected that you'll add win32 resources yourself.

I found this at Einar Egilsson's blog where he discusses some of the pros and cons of the Icon and Manifest versus Resource approach.

Basically, if you choose to use the Resource approach, you must provide your own VERSIONINFO in your .rc resource source file. After compiling the .rc file into a .res file and linking your application, you will see the executable's properties now show the Version information supplied by the .rc file.

This might be a little late for @Ross, but hopefully this helps someone else.