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

[EFinley]

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

[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]

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?

[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.