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

[Rick Tillery]

The suggestion from Robert seems to work!  For posterity:

$ cat assytest.cs
using System.Reflection;
using System.Text;
using Mono.Unix.Native;

public class Test
{
    public static void Main()
    {
        Assembly thisassy = Assembly.GetEntryAssembly();
        System.Console.WriteLine("Assembly Type: " + thisassy.GetType());
        System.Console.WriteLine(" CodeBase: " + thisassy.CodeBase);
        System.Console.WriteLine(" FullName: " + thisassy.FullName);
        System.Console.WriteLine(" Location: " + thisassy.Location);
        var builder = new StringBuilder(1024);
        Syscall.readlink("/proc/self/exe", builder);
        System.Console.WriteLine("BundleEnvironment: " +
builder.ToString());
    }
}
$ mcs -r /opt/mono/lib/mono/4.5-api/Mono.Posix.dll assytest.cs
warning CS8029: Compatibility: Use -r:LIBRARY instead of -r library
$ mono assytest.exe
Assembly Type: System.Reflection.MonoAssembly
 CodeBase: file:///home/user/assytest.exe
 FullName: assytest, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
 Location: /home/user/assytest.exe
BundleEnvironment: /opt/mono/bin/mono-sgen
$ mkbundle -L /usr/lib/mono/4.5 -o assytest-staticdeps --static --deps
assytest.exe
$ ./assytest-staticdeps
Assembly Type: System.Reflection.MonoAssembly
 CodeBase: file:///home/user/assytest.exe
 FullName: assytest, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
 Location: assytest.exe
BundleEnvironment: */home/user/assytest-staticdeps*

Of course, if there is a better way of addressing the EXE assembly, it
would be better than directly accessing the Linux binary as a file and
searching for it.  As I mentioned, I looked at the Modules list returned by
GetModules(), but the name of the EXE appeared there.  Now I'm wondering if
that might be a good thing.  If I use the Location name with
Assembly.GetModules("assytest.exe"), can I use the Module to access the EXE?

Additionally, I found this information
<https://blogs.msdn.microsoft.com/shawnfa/2004/06/07/checking-for-a-valid-strong-name-signature/>
about checking signatures.  (I believe our project uses signtool.exe.)

Are either of these leading me in the right direction?

Rick


On Tue, May 16, 2017 at 7:11 AM, Rick Tillery <rtillerywork at gmail.com>
wrote:

> 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" <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.
>
>
> Robert
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.dot.net
> http://lists.dot.net/mailman/listinfo/mono-devel-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20170516/b702b1db/attachment.html>