DllNoteFoundException after upgrading Dev Mac to Ventura/XCode 14.1


Has something changed between MacOS Monterey (12.x) and the newly released Ventura (13.x) that would cause problems with Couchbase.Lite 3.0.2?

There was an issue with hardened apps (link), where one of the findings of the investigation was that Couchbase.Lite library file “MacProxy.cs” had incorrect hard coded paths. A workaround was found - enable the option “com.apple.security.cs.allow-dyld-environment-variables” (read more about that entitlement here

It appears that this issue has arisen again in Ventura 13.x and Xcode 14.1, but it appears to be more widespread. It is currently impossible (at least for me!) to create a simple test Cocoa app, include Couchbase, and open a database.

System Details

I can replicate this on MacOS Ventura, Xcode 14.1, VS 17.4.1 (stable) and VS 17.5 (preview), Couchbase.Lite 3.0.2.
To replicate, open a new Cocoa App, add Couchbase, add a line to open a DB in the View Controller.

Issue Details

I have a Cocoa app that was working fine on Monterey. I (perhaps foolishly) upgraded to Ventura and Xcode 14.1 when it came out, and things went downhill.

First xamarin.mac 8.12 is not compatible with ventura, and VS will refuse to compile. This has been solved by finding a copy of xamarin.mac (here: MacOS Ventura CHIP.framework dependency missing, Cocoa app crash · Issue #16628 · xamarin/xamarin-macios · GitHub). You also need to change /Library/Frameworks/Xamarin.Mac.framework/Versions/Current to point to 9 rather than 8.12 (and fix it after every update). All References must now be pointed to versions - System, mscorlib, System.Net, System.Numerics etc.

Now the compiler says it cannot find Couchbase.Lite.

Target _CompileToNative:
MMP : warning MM2006: Native library LiteCore was referenced but could not be found.
MMP : warning MM2009: Referenced by LiteCore.Interop.Native.c4base_release
MMP : warning MM2009: Referenced by LiteCore.Interop.Native.c4base_retain
… etc

I have Couchbase added to packages:

Screenshot 2022-12-09 at 3.04.35 PM

and I have libLiteCore added to Native References:

Screenshot 2022-12-09 at 3.05.12 PM

libLiteCore comes from the following folder:


It still successfully compiles with the above error, but then at runtime I get an exception in this code:

    try {
        options = new DatabaseConfiguration
            Directory = path
        database = new Database(config.DBName, options);
    catch (Exception e)
        log.Error("Failed to open database: " + e.Message);

The exception occurs in the new DatabaseConfiguration line, and the exception is:

InnerException {System.TypeInitializationException: The type initializer for 'Couchbase.Lite.Support.MacProxy' threw an exception. ---> System.DllNotFoundException: Unable to find or open library at /System/Library/Frameworks/CoreServices.framework/Frameworks/CFNetwork.framew…} System.TypeInitializationException

CFNetwork? It appears the hardcoded path to CFNetwork, which is incorrect, might be causing problems. Here is a quote from the earlier Couchbase issue report (mentioned above):

According to this website (which lists all of the versions of all MacOS APIs, and sadly seems to have disappeared), it seems that at 10.6, CFNetwork did live underneath CoreServices.framework, but by 10.10 it was not. CFNetwork now appears directly under /System/Library/Frameworks. If this is all true, then the hard coded path should be /System/Library/Frameworks/CFNetwork.framework…

I don’t know how this works when hardened is off… but it does :-).

So it appears that the attempt to load CFNetwork from an incorrect location will no longer work.

But it also appears that, for some reason, the compiler does not like the native library LiteCore I am providing.

Does anyone have any insights to what might be going on here?

Many thanks.


I think you are probably already aware of this, but just to be sure, Xamarin Mac is not one of our supported platforms for .NET (though in .NET 6 the mac catalyst target will be in 3.1.0).

I don’t know a whole lot about this area, but I do know that having naked dylibs in an actual “app” (as opposed to command line) is a hassle and causes these types of problems. The iOS support library was a dylib when 2.0 was in development and fairly late we found that it didn’t work and needed to be converted to a straight up .framework instead in order to satisfy Apple’s rules about apps. That might be a factor here but it seems pretty weak if it was working before. So the ultimate unfortunate answer is that I don’t know. Maybe mac catalyst would work with the iOS framework?