Motivation

Currently, embedded resources can be accessed through Assembly.GetManifestResourceNames() and GetManifestResourceStream(), but they behave more like a flat resource collection than a hierarchical file system.

In many scenarios (templates, configuration files, web assets, game resources, etc.), it would be convenient to expose embedded resources through a virtual file system abstraction.

Idea

Introduce an embedded resource file system implementation that:

1. Accepts an Assembly instance.
2. Scans and caches all manifest resource names on initialization.
3. Builds a virtual directory tree from resource names.
4. Supports standard file-system-like APIs for enumeration and lookup.

Example:

var fs = new EmbeddedResourceFileSystem(typeof(Program).Assembly);

fs.Exists("/templates/index.html");
fs.ReadAllText("/templates/index.html");

foreach (var file in fs.EnumerateFiles("/templates"))
{
    ...
}

Logical Path Mapping

One possible approach is to leverage MSBuild's <LogicalName> metadata.

For example:

<ItemGroup>
  <EmbeddedResource Include="Assets\Templates\index.html">
    <LogicalName>/templates/index.html</LogicalName>
  </EmbeddedResource>
</ItemGroup>

This would allow resource paths to be represented naturally:

/templates/index.html
/images/logo.png
/config/default.json

instead of relying on assembly-qualified resource names such as:

MyProject.Assets.Templates.index.html

Benefits

• More intuitive resource organization.
• Virtual folder support for embedded resources.
• Better compatibility with existing file-system abstractions.
• Useful for static web assets, templates, localization resources, and game content.
• Resource name lookup can be optimized through startup caching.

Questions

• Would such an abstraction fit the goals of Zio?
• Is there an existing extension point that could already support this use case?
• Would maintainers prefer this as a separate package rather than part of the core library?

I'd be interested in hearing feedback before starting an implementation.