0

I am creating a c++ dll which includes some images in the png format using VS2010. This works fine as long as I keep the dll on my developer machine. When I try to copy the dll to another machine the images are missing. When I compile my project, a file called app.res is placed in the build directory. If I look into that file, it seems to contain some binary encoded pngs. The project settings contain a entry called "Resource File Name" in the "Resources" section. The value is "app.res". Therefor I assume that my resources are added to the dll. However, it apperently doesn't work that way. Does anyone have any ideas what could be wrong here? Does anyone know of any good instructions on how to deals with resource files in VS2010. The Microsoft documents just didn't help much..

st-h
  • 2,444
  • 6
  • 37
  • 60
  • Test it by copying your production environment to a different location on your development machine. If it works correctly then maybe the target machine can't handle png-images. – engf-010 Jan 30 '11 at 00:36
  • 1
    they are both running on win7, so I don't think that the problem lies within the png file format – st-h Jan 30 '11 at 17:04

1 Answers1

2

The linker embeds the .res file in the DLL. Verify this with File + Open + File, select your DLL, you can browse the embedded resources. There is otherwise no mechanism to make embedded resources disappear when you copy the DLL, they are firmly embedded.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • When I open the dll the way you described it I see a "PNG" Filter, which contains all the pngs. If I double click on them, I see the content of the image. This is quite odd since everything works fine on my development machine. However, no I know that it shouldn't be a issue regarding embedding the files into the dll. – st-h Jan 29 '11 at 22:15
  • seems that my problem lies within the FindResourceA() method. On my 32bit machine, the hInstance is null, whereas the hInstance on the 64bit machine is a valid object. – st-h Jan 30 '11 at 17:07
  • it turned out, that there has been a change in the interface specification for the host. So, it wasn't the dll at all – st-h Jan 30 '11 at 23:26
  • Hehe, a bit mysterious how that collapsed. Well, looking in the right place is 80% of the battle. – Hans Passant Jan 30 '11 at 23:30