Introduction
When you code a C# application - let's say a Windows Forms application - you usually use a bunch of different resources, like icons, bitmaps, strings and so on. However, .NET in general uses a different approach to store resource data than it used to be in a plain Win32 environment. Win32 resources are held in a special section of the PE (portable executable) file format. .NET on the other side follows the concept of assemblies that are responsible of storing (and finding) their resources. For example a .NET resource can be stored in a different file in a multifile assembly. It does not have to be in the same file. The resource manager takes care of this. (I should note here that it is of course possible in Win32 to use special resource DLLs, but you have to deal with this manually in your code).
The big benefit of the new .NET approach is the easy - or easier - internationalization of applications. The big drawback is that all tools and procedures that rely on Win32 resources do not work anymore. Now you say: Why should I bother? I'm using C# only...?
A scenario
Some might already have heard about the res:// protocol. It's a protocol extension of the Internet Explorer and let's you access any type of resoures within a DLL or an EXE file. This usually makes sense for embedded HTML pages like user documentation or a fancy HTML credits page, that can be displayed with the WebBrowser control The URL looks like this:
res://resource file[/resource type]/resource id
If the resource type is omitted, a type of 23 (for HTML) is used. The resource file is the full path of the EXE or DLL. The resource id is the name of the resource.
Embedding resources
As we heard already, .NET resources are different from Win32 resources, so the res:// protocol does not work with them. VS.NET does not offer us to add Win32 resources in a C# or VB.NET project (it does in a Managed C++ project).
A .NET executable (or DLL) however, complies to the earlier mentioned PE file format, so it does support standard Win32 resources. And indeed csc.exe and al.exe - the command line compiler and linker - offer a /win32res switch. But we want to use VS.NET, so compiling the whole project with csc.exe does not make too much sense here.
What about linking the Win32 resources with al.exe and use VS.NET for the compilation? Not supported by VS.NET either.
The solution to this dilemma (at least until VS.NET supports this at some point) is to use a little freeware tool called Resource Hacker. This useful tool helped me out at some other occasions already (e.g. customizing your Windows XP boot screen), and is of use here as well.
You can compile and build your application with VS.NET as you have always done. Then you have to add the HTML pages, the images and all the other stuff you need as follows:
The sample
The sample program provided with this article has already two embedded HTML pages and shows them in a WebBrowser control. You can use all HTML features you could use in a normal web environment. This is especially useful for little JavaScript or DHTML hacks to show fancy UIs or credits dialogs. The benefit of embedding those files vs. providing them as separate files is obviously the protection from being deleted or moved and (to a little extent) being altered.
