[Mono-dev] mkbundle & Assembly.GetEntryAssembly()

Rick Tillery rtillerywork at gmail.com
Tue May 16 12:11:57 UTC 2017

An empty path would be interesting, but still not provide a path to the
actual entry point file. (I'll be trying the suggestion this morning, so
that may be the key to getting that).

But you mentioned that there is already a built-in way to access the
mkbundle'd EXE? I tried looking at the Modules returned by GetModules(),
but these similarly report nonexistent filenames. How would I go about
accessing the EXE within the bundle?


On May 15, 2017 10:31 PM, "Robert Jordan" <robertj at gmx.net> wrote:

On 16.05.2017 01:48, Rick Tillery wrote:

> Thanks! That looks like it might work in C# (we don't really have any C in
> this project). I'll give it a try.
> However, I respectfully disagree that the path to the assembly is a good
> choice. I understand that the Linux binary isn't the same as the .Net
> assembly, but the EXE file is not there at all.

>From the point of view of .NET Assembly APIs the EXE file *is* there.

You can access it by System.Reflection, you can load it (once more ;)
as it's already loaded). You can load resources from it, you can check its
meta data, assembly name, public key, etc.

Indeed, System.IO APIs won't see this file, but you don't
really expect that mkbundle's infrastructure is going to redirect
file access into the bundle, do you?

The only bug I can sense is how the mono runtime is reporting
the Assembly.Location of bundled assemblies. I'd rather
expect an empty string for Location as this is usually an
indicator that the assembly was loaded from a byte blob
rather than from a file.


Mono-devel-list mailing list
Mono-devel-list at lists.dot.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20170516/dc617c7c/attachment.html>

More information about the Mono-devel-list mailing list