csproj export emits embedded resources flat instead of restoring folder structure from dotted LogicalName

[SBvn-dev]

Summary

When exporting an assembly as a .csproj (ilspycmd <asm> -p), embedded
resources are written to disk as flat files in the project root with their
full dotted manifest names as the filenames, rather than being restored to a
folder hierarchy that matches what the original source tree probably looked
like. The dotted segments of the resource name encode exactly that hierarchy
(modulo SDK name-mangling rules).

Steps to reproduce

Take any assembly built from a project whose source tree organizes assets
into folders (e.g. images/CopyHS.png, payloads/9.01/payloadName.bin), then:

ilspycmd MyApp.exe -p -o ./out

Actual output

out/
├── MyApp.images.CopyHS.png
├── MyApp.images.CutHS.png
├── MyApp.images.donate_full.png
├── MyApp.payloads._9._01.payloadName.bin
└── MyApp.csproj

with corresponding csproj entries:

<None Remove="MyApp.images.CopyHS.png" />
<EmbeddedResource Include="MyApp.images.CopyHS.png"
                  LogicalName="MyApp.images.CopyHS.png" />

Expected output

out/
├── images/
│   ├── CopyHS.png
│   ├── CutHS.png
│   └── donate_full.png
├── payloads/
│   └── 9.01/
│       └── payloadName.bin
└── MyApp.csproj

with csproj entries that preserve the original logical name even though the
file now lives in a folder, so existing
Assembly.GetManifestResourceStream("MyApp.images.CopyHS.png") calls in the
decompiled code keep working unchanged:

<EmbeddedResource Include="images\CopyHS.png"
                  LogicalName="MyApp.images.CopyHS.png" />

Why this matters

Right now, opening the decompiled csproj in Visual Studio shows a project
root with dozens of dotted-name files all jumbled together at the top level.
Reorganizing them into the original folder layout is a purely mechanical
transform (the dot-separated logical name is the encoding of the original
path) but currently has to be done by hand for every decompiled project.

Proposed approach

For each EmbeddedResource whose logical name begins with the project's
root namespace (typically the assembly name), strip that prefix, split the
remainder on ., treat the last segment as the file extension, the
second-to-last as the filename stem, and the rest as folder segments.
Apply the inverse of the SDK's leading-_ mangling for segments that begin
with _<digit>. Preserve the original LogicalName= attribute on the
emitted item so the resource keys stay byte-identical and existing
reflection-based resource lookups in the decompiled code keep working.

There is one inherent ambiguity (a folder name like 9.01 round-trips to
_9._01 which is indistinguishable from a 9/01/ two-folder hierarchy
without external knowledge), but a heuristic that merges consecutive
underscore-digit segments into a single dotted folder name handles the
common case and is no worse than the current behavior for the others.

Details

• Product in use: ilspycmd
• Version in use: 10.0.0.8330 (latest stable as of 2026-04-13)

[siegfriedpammer]

ai;dr

[SBvn-dev]

English isn't my native language and the enhancement is fairly simply to understand, even by a quick glance at the 2 diagrams.

[siegfriedpammer]

Even if you use AI to generate bug reports, you can always edit the AI-generated text to be less verbose. It's simply a pain to read.

[siegfriedpammer]

I don't want to be rude. You could write the bug report in your native language and include an automatic (non-AI) translation at the end. Also, English isn't my first language either, but I think being able to explain an enhancement or bug in your own words is an important skill. Even if you then use some tool to automatically translate the text.

Also, the cost of AI is measured in "tokens", which could be translated into human terms as "syllables". The more tokens an AI consumes, the more you have to pay in the end (or will have to pay, once the "freeconomy" around AI crashes). Similarly, I have to spend more time and energy if there are more words/syllables for me to read.

Thank you for your understanding!

[SBvn-dev]

ilspycmd <asm> -p currently writes every EmbeddedResource as a flat file in the project root using its full dotted manifest name (MyApp.images.CopyHS.png).
Could it optionally restore the folder hierarchy the dots encode, since that's almost certainly how the original source tree was organized?

Sketch: for each resource whose logical name begins with the assembly's root namespace, strip the prefix, treat the last . segment as the extension, the second-to-last as the filename, and the rest as folder segments (un-mangling the SDK's _<digit> prefix on segments that originally started with a digit). Emit:

  <EmbeddedResource Include="images\CopyHS.png"
                    LogicalName="MyApp.images.CopyHS.png" />

so existing GetManifestResourceStream("MyApp.images.CopyHS.png") calls in the decompiled code keep working byte-identically.

Caveat: folder names containing dots (e.g. 9.01) round-trip ambiguously with two-segment hierarchies (9/01/). Merging consecutive _<digit> segments into a single dotted folder name handles the common case; the rest can stay flat.

Could be a --restore-resource-tree opt-in flag if you want it off by default.

Reproduced on ilspycmd 10.0.0.8330.