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? Thanks! Rick On May 15, 2017 10:31 PM, "Robert Jordan" <robe...@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. Robert _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.dot.net http://lists.dot.net/mailman/listinfo/mono-devel-list
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.dot.net http://lists.dot.net/mailman/listinfo/mono-devel-list
