Runtime: Loading a single-file app's assembly for reflection

[asocialraccoon]

Understandably, a self-contained application's published executable is a native host intermediate and not an IL assembly. That said, is there any available or proposed API, or alternative solutions for loading the assembly of a bundled single-file application?

For exercise's sake, my goal is to load an assembly (ideally only for reflection, but that is also not supported in dotnet core) and fetch a custom assembly attribute out of it. The issue is that the target application is published as a single-file executable and as such attempting to Assembly.Load() it results in a bad IL format error.

[swaroop-sridhar]

In .net core 3, you'll be able to open the "app.dll" from the extraction directory (obtained through AppContext.BaseDirectory) and then use it for reflection.

[asocialraccoon]

@swaroop-sridhar how would you acquire that info from outside the target assembly?

While my overarching issue conveniently seems to have been resolved with dotnet/runtime#1260 (thanks @swaroop-sridhar), this does seem like a topic that could use further discussion unless I'm missing something. One should be able to load an assembly even if it has been bundled into a self-contained host application.

[swaroop-sridhar]

I may be missing something in your requirements; But I assumed:

• You are running managed code when you want to load an assembly for reflection
• You know the name of the assembly you want to load.

Right?

So, from your main module, you could open/load the file within AppContext.BaseDirectory directory.

[asocialraccoon]

The scenario is this:

• App A is a published single-file executable
• App B (another published single-file executable) receives the path to the executable app A

How can B load the assembly of A? B doesn't know the AppContext.BaseDirectory of A as it's a separate assembly and process - it only knows the path to the executable host application of assembly A.

[swaroop-sridhar]

There are two options:
1) B receives a path to A's BaseDirectory, instead of A.exe path
2) The HostModel library has an extractor that can process single-file bundles from managed code. This can be enhanced to just read the bundle headers instead of performing extraction. This way, The App B can link with HostModel library, read A.exe, mmap() relevant portions of A.exe, and load it from the byte-stream.

[asocialraccoon]

Some version of option 2 could be folded into the core runtime. I think it's not unreasonable to expect that you can load the assembly regardless if it's been bundled.

Appreciate the help @swaroop-sridhar! As I mentioned the original issue that led me to this issue has been resolved, so feel free to close this unless you feel like it should be followed up on.

[vitek-karas]

@asocialraccoon If possible can you please share a bit more specific description of the scenario you're trying to achieve?

I'm asking because lot of our efforts around single-exe are moving the tech in the opposite direction. Crossgen is working on a large-version bubble which will enable AOT precompiled native code for the entire app - fits really nicely with single-exe. From there it's not that far away to move into solutions which don't event persist the original IL fully (Something which for example .NET Native already does).

It's also anticipated that single-exe will be frequently used together with trimming. The trim process will remove or change parts the IL as well.

Basically this is the first time I'm hearing about a need to run for example ILSpy on a single-exe.

[swaroop-sridhar]

CC: @jkotas
Reg: Considerations for managed APIs to inspect the contents of a single-file bundle.

[davidfowl]

Considerations for managed APIs to inspect the contents of a single-file bundle.

We had some discussions where that would be useful for ASP.NET Core in some scenarios as well.

[swaroop-sridhar]

We had some discussions where that would be useful for ASP.NET Core in some scenarios as well.

@davidfowl Can you please note the scenarios here? or link the discussions? Thanks.