Cannot decompile self-contained executables (PublishSingleFile)

[dgrunwald]

See https://stackoverflow.com/questions/60026667/can-net-core-3-self-contained-single-executable-be-decompiled

It would be useful if ILSpy could open these, e.g. similar to how we open .nupkg files.

[dgrunwald]

See also dotnet/runtime#36590 for an overview of the different types of executables.

See https://github.com/dotnet/designs/tree/master/accepted/2020/single-file for more details -- note there are different designs for .NET Core 3 and .NET 5.

[christophwille]

@cshung do you happen to have any additional pointers for us? Thanks.

[dgrunwald]

Reopened: the first approach using Microsoft.NET.HostModel.dll had problems (including a security vulnerability) and had to be reverted. See #2022.

[christophwille]

Over the past few months we had a couple of private discussions that touched this topic. I will try to summarize beginning with the current status (as well as partial implementations that we had):

• nupkg decompilation was bolted on after the fact. Basically, ILSpy auto-detects the file format, opens a dialog to select which of the assemblies contained in the package you want, and then adds this specific assembly to the visual assembly list. But in the shadows the nupkg file was lurking (containing addtl information that might be interesting, not to speak of the gymnastics to re-load the assembly on Start).
• sfx in its initial implementation showed the entire contents, and the root node in the visual assembly list was the sfx executable.

You can see already that the visual assembly list is not really an assembly list (how it would be used by the decompiler). Actually, it contains a list of files that contain assemblies. That tripped me off badly when discussing the code with Siegi because we kept going from one type of assembly list (the visual one) to the actual one used by the decompiler.

Thus I was proposing to add a disambiguation to the code by splitting the classes - one for the visual UI, one for the decompiler. My proposal was NamedBrowsableFilesCollection for the visual tree, and keeping the other names for the decompiler (because as in the case of sfx we'd have a self-contained assembly list) .

Next I stumbled across async-Task-starting ctors (related because in LoadedAssembly). My proposal was to make the ctor private, and add a factory method static (type, Task) CreateAndStartTask(). That way you can choose to await (or not, as is the case today). Totally related: Do NOT provide a sync wrapper around an async API at the lowest level (poster child example is GetPEFileOrNull()).

nupkg & sfx: no fancy class hierarchies, stick with something simple like LoadNuGetPackage and LoadSfx.

[GF-Huang]

So does it supports decompile PublishSingleFile app (target .net 5)? I had try 6.2.1.6137-6.2, but it seems does not work.

[dgrunwald]

It's supported since in ILSpy 7.0 Preview 1.