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 <rtilleryw...@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" <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
