Unknown Assembly - FLMutableArray_New on Xamarin Forms iOS

Hello all,

Running Xamarin iOS app and when saving a document getting the following error:
FLMutableArray_New assembly: type: member:(null)

This happens when simply calling .SetArray on a new document, i.e.
var mutableDocument = new MutableDocument();
var cbArray = new MutableArrayObject();
cbArray.InsertString(0, “string 0”);
cbArray.InsertString(1, “string 1”);
mutableDocument.SetArray(“somearray”, cbArray);

(Just some dummy code created trying to debug.)

Installed: Couchbase Lite 2.7, and Couchbase Lite Support for iOS, Xamarin Form 4+

Might be missing something obvious but the CBL docs don’t exactly go into depth on saving documents. Any insights greatly appreciated.


I don’t see an actual error message there. Could you confirm that you actually typed what you meant to?

I’m seeing the same problem on Xamarin.Mac. I (perhaps unwisely) upgraded CouchbaseLite to 2.7.0 and Visual Studio and .Net all at the same time, so I’ve been hesitant to point to any particular culprit.

Here’s some detail:

The channels object is a List<string>, and I’ve confirmed its valid.

The first thing that screams out to me is can you confirm that the support library has also been upgraded? The native API changed and if for some reason the 2.6.x support library is being used then this exact thing will happen. I know that especially with packages.config and with multi project solutions that it is easy to get all these versions mixed up.


Yeah - a version mismatch sounds very likely.

I’ve a screen shot of the packages (versions match):
Screen Shot 2020-01-24 at 4.56.52 PM

Plus a couple of shots of the Native Reference:
Screen Shot 2020-01-24 at 5.02.47 PM
Screen Shot 2020-01-24 at 5.05.15 PM

I’m scanning the HDD now for any extra copies of libLiteCore that might be interfering.
I’m crossing my fingers its that simple.


Ok… have a culprit. As you can see above, I am definately copying the 2.7 version of libLiteCore.dylib into my app. But when I open the .app file, here is what I found for Contents/MonoBundle/libLiteCore.dylib:
Screen Shot 2020-01-24 at 5.13.33 PM
Look at the create time. Even though I have 2.7 in the references, VS is still copying the 2.6 version of libLiteCore.


That’s odd. This is not one of our supported platforms so I can’t say that I’ve tried it myself, but verbose build logs should help you track down if that is happening, and perhaps even it’s just not copying it over because it thinks that the one in there is newer for whatever reason (I assume you’ve tried deleting the app package though, and all the bin obj stuff?). Lastly as a wild guess, did you ever write a script to copy it for some reason and could it be executing? If so you wouldn’t have noticed it while you were on 2.6.

Yeah… did clean builds and manually deleted bin/.
I think that because I manually modified the path of the native reference, it showed me the new path, but kept using the old one. I removed and re-added the native reference, and it works.

Smells like a stinky VC bug to me.

This might not be a supported platform for you guys… but it sure does work well. I’m on .Net 4.8 now too!

I’m happy to hear that it works well. There is not any reason technically why it should not work, I was referring to “paid Couchbase support” supported (which brings other requirements beyond the development team with it).

Fixed this yesterday but first chance I have had to come back here and comment… on a hunch uninstall CBL from all projects and cleaned as was pretty certain all code was working before the Christmas break. Re-installed CBL 2.7 and all worked fine again.

So, @paulr, think this supports your conclusion though did not delve into the files.

PS. Had matching support library installed etc, although not sure that is needed anyway as listed as obsolete.

The support library is definitely needed, it’s just that the call to Activate() is no longer needed (except on Android). NuGet dependency resolution should be automatically taking care of the install (which is one reason I dislike the packages.config system so much, because it just takes all the transitive dependencies and adds them as immediate dependencies which you then have to monitor in case they fail to update when you updated the original package with the transitive dependency).