ied206 / joveler.filemagician Goto Github PK

This issue can be demonstrated by analyzing a .NET 8.0-targeted version of the Joveler.FileMagician.Cli executable itself.

Steps to reproduce:

1. Clone Joveler.FileMagician
2. Port the solution to .NET 8.0 by updating TargetFrameworks in each of the solution's 3 .csproj files:

<TargetFrameworks>net8.0</TargetFrameworks>

3. For some reason, this may change the "Copy to Output Directory" property of Joveler.FileMagician's bundled runtimes to "None". In this case, select each bundled runtime under this project's runtimes/ directory (all libmagic.so files, libmagic.dylib, lingnurx-0.dll, etc..), and change their "Copy to Output Directory" property to "Copy if newer".
4. Replace Program.cs in Joveler.FileMagician.Cli with the following code intended to illustrate the issue:

using Joveler.FileMagician.Samples;
using System.Diagnostics;

namespace Joveler.FileMagician.Cli
{
    public class Program
    {
        public static void Main(string[] args)
        {
            using (var bd = new BinaryDetector())
            {
                using (var process = Process.GetCurrentProcess())
                {
                    var result = bd.InspectBinary(process.MainModule.FileName);
                }
            }
        }
    }
}

5. F5 Joveler.FileMagician.Cli
6. Observe the following debug assertion failing on BinaryDetector line 408:

                if (typeStr.Contains("Mono/.Net assembly", StringComparison.Ordinal))
                    formatFlags |= PEFormatFlags.NetAssembly;
                Debug.Assert(formatFlags.HasFlag(PEFormatFlags.NetAssembly) &&
                             binFlags.HasFlag(BinFlags.Bit32));

I may be misreading, but looks like it's assuming all .NET assemblies should be 32-bit?

Separately -- I wonder if this assert is meant to be included in the if statement above it?

In this age of modern .NET miracles, I wonder if support for Android and iOS has been considered?

Happy 2024! I started taking a look at requirements for #2, and it seems that a (seemingly) small enhancement could open the door to achieving it.

In .NET MAUI, the modern mobile development framework for .NET, "Content" is not a valid build action for magic.mgc and magic.src.

Instead, in this case it's necessary to use the new "MauiAsset" build action to include these files in the build.

Following this, you'd access magic.mgc like so:

async Task LoadMauiAsset()
{
	using var stream = await FileSystem.OpenAppPackageFileAsync("magic.mgc");
	using var reader = new StreamReader(stream);
	
	var contents = reader.ReadToEnd();
}

This has to do with how MAUI manages assets and abstracts away details of the device's underlying file system.

So, if overrides for Magic.Open() and Magic.GlobalInit() were added that could accept a stream like this as the parameter, then native binaries for iOS and Android could be added, and voila!

I hope you'll consider making this enhancement. I'm at your disposal to assist in any way.

• Feel free to close this and move the request into #2 if more appropriate