New limitations on DatabaseConfiguration Directory in 2.8.0?

All,

I’ve upgraded from 2.7.1 -> 2.8.0 to hopefully improve network drop detection
(Delays in noticing network dropouts)

As soon as I did that this line:

        var options = new DatabaseConfiguration
        {
            Directory = path
        };

started to generate a TypeInitializationException
with the message: “The type initializer for ‘Couchbase.Lite.Sync.HTTPLogic’ threw an exception.”

Is there some new restriction on the paths?
If I revert the library to 2.7.1, OR remove the path, it works.

The path is retrieved using
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
so it points to the local container for my sandboxed application. In my case its:
/Users/Paul/Library/Containers/<bundle>/Data/.local/share

Any ideas?
Many thanks.
Paul.

Ok. A little more detail.

The line above that creates a DatabaseConfiguration has always generated an exception that is raised and caught within the DatabaseConfiguration constructor. You only saw it if you had “stop on all exceptions” configured in Visual Studio, and you could happily ignore the exception.

One possibility is that the exception is now being surfaced rather than handled internally?

Just a thought.
Cheers.
Paul

You really need to give the inner exception in this case because TypeInitializationException only basically says “the static constructor threw an exception” and nothing else. This is a common thing to happen if LiteCore is unable to be loaded properly though. Removing the path is strange because I wouldn’t expect that to have any effect on the static constructor of an unrelated class.

@borrrden Does this help? Looks pretty messed up to me.

Looks to me like you possibly have a stale support lib in there. You can’t mix and match CBL and CBL support nuget packages since we don’t guarantee stable API for LiteCore between releases.

Possibly. NetDesktop and the main Couchbase.Lite are at 2.8.0, and the other requirements:

  • Newtonsoft.Json
  • SimpleInjector
  • Microsoft.Win32.Registry

are all up do date and beyond the required version.
Having said that… I’ll start doing some purge and readds and see where I get.
Thx.
Paul.

Just an update… cleaned everything out that I could.
This has not changed :-(. I’ll stick with 2.7.1 for the moment.

I had a quick look and for sure the symbol _FL_Buf_Release is not present in 2.7.1 but was added for 2.8.0. The logs should show what version of things are being loaded as its first message. Is the LiteCore binary mistakenly in your path somewhere? Is it being cached in the package? Are you able to see that particular symbol in the export list of the binary that is being bundled (I’m assuming here that this is still the experimental Xamarin Mac build?). It points to a stale libLiteCore being loaded.