Access embedded resources in a .NET program by ID using Windows API functions

0
votes

I have added an .ICO icon image to a .NET WinForms program using the Resources page in the projects options. Is it possible to access this resource using Windows API functions like LoadImage, ideally by specifying a resource ID (in native code done using the MAKEINTRESOURCE macro if the icon is referenced in the .RC resource file)? Or is it necessary to load the icon resource using .NET framework methods and to afterwards provide the icon handle to the API function?

1
.netwinformswinapiinteropwinforms-interop
Open the executable with a rc editor, if resources are visible, then the answer is yes. – Michael Chourdakis
You can load the Assembly (Assembly.LoadFile()), then use the Assembly.GetManifestResourceNames() method to extract any the .resource parts and use Assembly.GetManifestResourceStream() to save it (disc or MemoryStream). Finally, use the ResourceReader class to extract any of the resources contained in any of the .resource parts that the loaded Assembly contains. No API required. – Jimi
Well, if the above fits the requirements but you think you need an example, let me know. – Jimi
@Jimi: Thanks for pointing this out, but I am using a Windows API function and P/Invoke; so this is a definite requirement. – Olaf Hess
@Michael: Thanks for pointing this out, but a resource editor does not show the added icon resource in the EXE. – Olaf Hess

1 Answers

0
votes

Here is my Github repository with my latest iteration of my Windows Desktop toolkit, named DataTools.

It is written in VB.NET but at its core there is some pure CIL coding so it's very fast.

The library can be included in either VB or C# projects for use in the Windows Desktop environment.

It includes MemPtr, which is a drop-in replacement for IntPtr.

Since you are very interested in grabbing resources from EXE files, look at the DTInterop project, specifically DataTools.Interop.Desktop.Resources.

I spent a great many years on this entire project. It's clean, it holds together well, and the VB is easily translatable to C#; that the interop methodology is still the same.

I did a lot of homework and listened to a lot of ancient Windows gurus, along the way, most of whom have their home in the straight-C language Win32 API of legend and old.

My code is heavily commented and documented, so you shouldn't have any problem figuring out which way is up.