Resources are designed to be internal to the assembly. However, the problem is solvable. You need to put all resources in one or more special resource-only assemblies and provide a special facade class (or classes) used exclusively to expose the resource to the assemblies referencing your resource assemblies. A typical form of exposure should be a public static property of a static class.
(See
http://en.wikipedia.org/wiki/Facade_pattern[
^].)
For one thing, this will present a certain maintenance hassle: as soon as you change or add a new resource, you will need to change the facade class: add a property or modify the implementation of existing property, usually just a name if internal property. Also, it looks like a functional redundancy. (But do you have a choice without redundancy?)
From the other hand, the facade class is trivial, maintenance is not tricky, and it can give you a layer for additional flexibility, so the interface can be done in a more semantic style from the perspective of the referencing assembly (user assembly). I can explain.
For example, you need to add N images. The best way of doing it through the designer is this: you add the *.res resources using the Designer as separate image files using "Add existing file". The designer will copy the file in the project directory structure (make sure it would not produce double copies, you only need to keep the target copy in the project), add the reference file to the project file with appropriate attributes (instructing the MSBuild: embedded resource, don't copy to the output directory), it will also add the reference to the file to the resource file and — important — will auto-generate the source file. Look at this source file: you will find some static class and some static property with the name close to the name of the image file. The best thing is: if the file type is JPEG or PNG, the type of the static property is
Image. Same thing with many other resource types. You don't have to use resource stream, read or convert anything; you already have a fully-initialize static
Image. Or string in the case of the text file, or something else.
So far so good, but the only problem is when you use many image files, the writer of the code using the resources should use the semantic (hopefully) variable names (very good that not strings as the compiler would not able to check it they are correctly spelled), but what if there are too many? The access to the many resources is not structured.
As you have a facade class(es) in my approach, you can use the extra flexibility to restructure the access. For example, you can group those image variables into some structures by semantic criteria or even present them as a collection indexed by an enumeration type and/or enumerate in a cycle by a enumeration-type index.
(By the way, you can learn how to enumerate by a enumeration type index from my article:
Enumeration Types do not Enumerate! Working around .NET and Language Limitations[
^].)
—SA
Submit an article or tip