7

Is it possible to retain the logical layout of the project file?

If I have 2 embedded resources laid out like the following

Embedded Resources

When I call Assembly.GetManifestResourceNames(), the two of them get named:

  • MyLibrary._MyItems.SubItems.SubItem1.xml
  • MyLibrary._MyItems.SubItems.SubItem2.xml

However, this gives me no real insight into how they're logically ordered in my project. For all I know, they could both be in the same directory.

I worry that this may not be possible, because if I name the files like so, my app will not even compile:

Embedded Resources

I want to be able to distinguish between

  • MyLibrary._MyItems\SubItems\SubItem1.xml
    • and
  • MyLibrary._MyItems\SubItems.SubItem2.xml

Similar question, but less detail than I am looking for

Exact duplicate, no traction

Community
  • 1
  • 1
Michael
  • 3,099
  • 4
  • 31
  • 40
  • 1
    Your screenshot only shows where the original resource files are stored on *disk*. Which has nothing to do where they are stored inside the *assembly* after you build your program. There is no directory structure inside the assembly. – Hans Passant Jan 18 '13 at 21:43
  • 1
    While it may not have anything to do with _where_ they're stored in the assembly, it obviously has some impact on _how_ they're stored. Do you have a reference for your assertion that I can read more about? – Michael Jan 18 '13 at 21:53
  • The first `MyLibrary` is the default namespace of the project, the rest are normally folders. As long as you know the default namespace or are able to find it you should be able to tell the folder structure... unless someone decided to build their assembly with a custom build process and not VS – Sten Petrov Jan 18 '13 at 21:56
  • Google always does a better job than me finding references. I'd recommend ".net embedded resource name" – Hans Passant Jan 18 '13 at 21:57
  • 1
    @StenPetrov But as soon as you have a file with a period in the name (assuming all files have a period for an extension), folder structure and file name are indistinguishable. – Michael Jan 18 '13 at 22:00
  • ic... the problem is there is no "file" any more, let alone "folder structure" - it's all become some data inside another file and with that there was some related information that was lost and you can't recover – Sten Petrov Jan 18 '13 at 22:12
  • 1
    It's frustrating, because it seems like MSBuild and csc could have somehow retained this information when embedding the resources (it's clear they're already looking at it). Oh well. – Michael Jan 18 '13 at 22:29

1 Answers1

0

One simple solution would be to come up with a convention to indicate where a file name starts. You could then "safely" assume the rest of the name indicates the folder structure.

However, since these are embedded resources you could create a T4 script (or some similar piece of code) that runs prior to compilation that examines the folder structure and builds a class detailing that structure.

Here is an example of what the generated class could look like.

public static class MyResources
{
    private readonly Dictionary<String, String> ResourceNameToDirPathMappingSetSource = new Dictionary<String, String>();

    static MyResources()
    {
        ResourceNameToPathMappingSetSource.Add("MyLibrary._MyItems.SubItems.SubItem1.xml", @"MyLibrary._MyItems\SubItems");
        ResourceNameToPathMappingSetSource.Add("MyLibrary._MyItems.SubItems.SubItem2.xml", @"MyLibrary._MyItems");
    }

    public static IReadOnlyDictionary<String, String> ResourceNameToDirPathMappingSet
    {
        get
        {
            return ResourceNameToDirPathMappingSetSource;
        }
    }
}

My assumption being that you want to take the resource name and determine the folder path it was originally in. The dictionary of course could contain whatever values (read: custom class) you need to map to.

Sacrilege
  • 795
  • 9
  • 25