LiteCore (System.DllNotFoundException) in Release build iOS

Working through a .Net Maui application testing Couchbase as a MongoDB replacement, everything is working great while debugging but release builds (on iOS) throw the following error:

at XXXXX.Program.Main(String[] args) in /XXXXX/Platforms/iOS/Program.cs:line 12 LiteCore (System.DllNotFoundException) at Couchbase.Lite.Logging.FileLogger.SetupDomainObjects() at Couchbase.Lite.Logging.FileLogger..ctor() at Couchbase.Lite.Logging.Log..ctor() at Couchbase.Lite.Database..cctor()

I have not tried Android yet as i am still validating this switch.

I’m not a CB Lite developer. There is a closed ticket for Maui that is marked fixed in 3.1.0. I don’t know if it is public. Log in with Atlassian account

It is not public, thanks though.

I am using:

  • Maui 8.0.82
  • CB Lite 3.2

I develop this SDK but I can’t come up with a reason why this should only happen in release mode. It means that it cannot find LiteCore.framework (which is packaged in the Couchbase.Lite.Support.iOS package in the runtimes folder).

Brutal, well if you somehow can think of anything let me know.

Thanks

Have you checked your csproj file to see what you have set for the linker? Release mode usually has extremely aggressive linking settings and my guess is the linker isn’t including the DLL.

An example of aggressive linking:

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <MauiLinkMode>Link All</MauiLinkMode> <!-- Link All Assemblies -->
  </PropertyGroup>

That would cause issues. You should probably have this set to Link SDK assemblies or you would have to manually add the DLLs and tell them to PreserveNewest.

You can find more out from the .NET documentation:

Also since you mentioned Android - it can be even more rough than iOS due to R8 and how it tries to achieve the smallest possible build. Examples of this are here:

Usually to fight this you have to create a proguard.cfg file to tell the shinker what to keep.

All this is because again the App Stores require really small files so the tools for building releases are aggressive about throwing out code it thinks you aren’t using.

Here is a brand new default Maui project app, I am using a Mac, that still crashes regardless of linker settings with the same error.

I only added CouchBaseLite and I just added one line of code to the boilerplate:

private void OnCounterClicked(object sender, EventArgs e)
	{
		var db = new Database("TestDatabase");

		count++;

		if (count == 1)
			CounterBtn.Text = $"Clicked {count} time";
		else
			CounterBtn.Text = $"Clicked {count} times";

		SemanticScreenReader.Announce(CounterBtn.Text);
	}

Regardless of my linker settings when this line of code get’s called, it crashes.
Archive.zip (223.6 KB)

Give me a few minutes to debug this.

So I downgraded to 3.1.x and the problem went away. We need to file a bug on this. I’ll talk with @borrrden about it.
Archive.zip (328.5 KB)

@engineering for now unfortunately my only work around I have for you is to downgrade to the last 3.1.x release.

Confirmed a downgrade fixed the issue for me as well.

Just started investigating Couchbase last week, would have never thought to downgrade.

Thanks!

Let us know if you run into any other issues. More than happy to try and help out as much as possible. For now we’ll open up a ticket and see if we can get this fixed and a patch out. Thanks for trying out Couchbase Lite!

Can you share with me more on how you created your app and sample project as in what IDE did you use or did you use the command line?

The sample app was created using VS Code:

I’ll let you know if I run into any other hiccups.

Thanks!

1 Like

I don’t see anything on our end that would cause this. So far the investigation has only turned up that it’s possible for the dotnet CLI to choose the entirely wrong moniker to restore, which of course will not work. Using 8.0.401 I am able to build a mac catalyst app in release mode and run it without any problem.

I suspect the issue is with the dependencies. 3.1.x has .NET 6 across the board, while 3.2.x has .NET 6 for desktop and .NET 8 for MAUI targets. So far from what I’ve been shown, the MAUI project is mistakenly restoring .NET 6 instead of the proper .NET 8 MAUI target.

So after a lot of work fixing my dotnet 8 install - I was able to upgrade properly to dotnet 8.0.401. This has resolved the issue on my mac.

Prior to this I was was running dotnet 8.0.100 with Maui workload 8.0.82. At this point I’m recommending anyone seeing this problem to get on the latest service releases of dotnet 8 and Maui.

1 Like