[BUG] Emgu.CV.runtime.maui.mini - CvInvokeIOS constructor crashes immediately upon app start

[EFinley]

Describe the bug
I'm just trying to bring Emgu into my project (.net Maui 8.0 for iOS/Android). Baby steps. But including Emgu.CV.runtime.maui.mini (v 4.9.0.5494) throws a fatal error immediately upon app start.

Error appears in the output window as follows:

[0:] An error occurred: '__Internal'. Callstack: ' at Emgu.CV.CvInvokeIOS..cctor()'

** OS / Platform **
iOS v17.4.1

** .Net version **
.net Maui (net8.0-ios; net8.0-android)

** Emgu CV package used**
Emgu.CV.runtime.maui.mini (v 4.9.0.5494) from NuGet

To Reproduce
Fresh C# Maui project using standard template in (current, just-updated) VS 2022.
Add Emgu.CV.runtime.maui.mini to project via NuGet package manager.
Add Emgu.CV.Platform.Maui.MauiInvoke.Init(); to MainPage.xaml.cs, immediately after InitializeComponent();, as per NuGet package's readme.
Deploy onto iOS. (In this case an IPhone 13 running iOS v17.4.1.)

Expected behavior
App loading as normal. Emgu commands available (but none used as yet, aside from the mandatory call to ...MauiInvoke.Init() as mentioned above).

Additional context
Given that most of the EmguCV docs seem to focus on the 4.8 version, I did try rolling the NuGet package back to v4.8.1.5350. Same error.

[EFinley]

Wait - is this me hitting this clause from the wiki?

Emgu CV for iOS is only available under our commercial license. The instructions below applies to the Emgu CV for iOS, Professional or Ultimate commercial release.

Colour me confused. That page doesn't mention Maui at all, and since so many of the clauses on the 'Download and Install' page talk about Xamarin, older versions of .Net, etc., it's very hard to know which portions of the page are current and/or relevant. Since at this time ".net Maui" is largely synonymous with "cross-platform development" - I certainly haven't seen anyone talking about using it extensively to produce desktop products - perhaps a sentence about how "use of Emgu CV's .Net Maui wrappers for cross-platform mobile app development requires the same licensing as for the mobile apps it is supporting [e.g. Commercial License]" might reduce confusion. Also leading to this confusion... if it's just the license problem causing my issue here, then what is the purpose of hosting the Emgu.CV.runtime.maui.mini.XX packages on the public NuGet directory?

I don't especially want to derive a commercial advantage by concealing my source code, nor do I have any particular need for the accelerated commercial-only performance. I absolutely respect you guys' need to pay the bills, but for an open-source project targeting mobile, do I really need to skip NuGet and figure out why CMake is failing me?

[emgucv]

The Emgu.CV.runtime.maui.mini nuget packages is avaiable for Open Source, but only contains the core open cv functions. It should not crash from the MAUI template app as you have configured.

The Emgu.CV.runtime.maui (without "mini") is avaiable from commercial release only.

We are looking into the crashing issue for iOS for 4.9.0 release. We will try to see if we can reproduce it. We have tested 4.8.1 Emgu.CV.runtime.maui.mini nuget pacakage to work on iPhone devices.

[emgucv]

One more question:

Are you building iOS MAUI app using Visual Studio from Windows?

[emgucv]

FYI, Visual Studio on Windows is very buggy when building iOS app with native binding (opencv is written in C++). It will strip off the native binary from the library and the PInvoke error will take place. We never build our iOS app using Visual Studio on Windows connected remotely to a Mac.

Please make sure you build the iOS app directly from a Mac, using Visual Studio for Mac, Visual Studio Code, or directly from command line:

To build the iOS MAUI app and run it on an iOS device, use this command:

dotnet build -t:Run -f net8.0-ios -c Release -r ios-arm64 --self-contained -p:_DeviceName={YOUR_IOS_DEVICE_UUID}

To find the connected iOS device UUID, use this command:

xcrun xctrace list devices

[EFinley]

Thanks for the prompt reply! I wasn't aware that the differences between specific deployment methods were so severe (although I suppose I shouldn't be surprised). I've been developing on a Windows machine using VS for Windows, and (thus far) only using the "hot restart" cheap-and-dirty method - which is presumably not even as reliable as the "connected remotely to a Mac" technique. Still early days here; I'm still just exploring options and trying to figure out which solutions to which problems will be doable and which will be... a wee bit harder. ;)

So your guess as to the issue may well be correct. I'm not in a position to test the hypothesis here, I'm afraid (the only Mac I have ready access to is undergoing severe hardware issues at this time), though when it becomes feasible to do so I'll try the direct-compile method and see if the issue is replicated. You might want to test the "hot restart" method and, if the problem recurs, put a note somewhere about avoiding one or both of the deploy-from-Windows workarounds when compiling for iOS. [I wonder if there's any way to detect which deployment method was used, and provide the correct error message? Murphy's Law says if there is such a way, it would be buggier than what it's error-checking.]

Given that the specific OpenCV components I'll eventually be needing are definitely non-core (Aruco tag recognition), I guess I'll shelve the OpenCV portion for now and focus on other facets of the problem until I can both test the .runtime.mini module, and justify the expense of the Commercial License.