Issues with Mono 4.6 on Centos

I kinda get the impression that you guys aren’t planning on supporting LiteDB on Linux. This would be a pity because the Portability Analyzer you can get for VS IDE suggests that LiteDB should, in theory, already be compatible with Mono 4.5 and the upcoming .NET Core 2.0.

I’ve been testing it on Centos with Mono 4.6. Most of my unit tests pass, although critically, the multi-process ones fail.

To give an example, I have an external writer which adds one doc. A unit test then attempts to read it, but generates the error below (I’ve not had much luck finding the cause as yet).

In another example, an external writer is writing documents while a unit test reader is reading them. The external writer dumps this message below to console:

Unknown errno: Text file busy

But raises no exception. (I’m guessing the message is being output by Mono which is a crap way of error handling).

Anyway, there you go. Let me know if you are interested in this one and I can do some more testing.

Otherwise my options appear to be a. stick with Windows (not my plan), b. wait for .NET Core 2.0 and hope for the best, or c. write my own portable DB from scratch. Why is it whenever I try not to re-invent the wheel, I end up being forced to do so anyway? 😦

1. Error : TictocDB.Test.LiteSeriesDatasetConcurrencyTest.LiteSeriesDatasetConcurrency_OneDoc System.InvalidCastException : Specified cast is not valid. at (wrapper castclass) System.Object:__castclass_with_cache (object,intptr,intptr) at LiteDB.PageService.GetPage[T] (System.UInt32 pageID) [0x00056] in <b85603d5f20d445f81a388a66cabd5f4>:0 at LiteDB.DataService.GetBlock (LiteDB.PageAddress blockAddress) [0x00000] in <b85603d5f20d445f81a388a66cabd5f4>:0 at LiteDB.DataService.Read (LiteDB.PageAddress blockAddress) [0x00000] in <b85603d5f20d445f81a388a66cabd5f4>:0 at LiteDB.LiteEngine+<Find>d__49.MoveNext () [0x00151] in <b85603d5f20d445f81a388a66cabd5f4>:0 at LiteDB.LiteCollection1+<Find>d__17[T].MoveNext () [0x0010b] in <b85603d5f20d445f81a388a66cabd5f4>:0 at System.Linq.Enumerable.SingleOrDefault[TSource] (System.Collections.Generic.IEnumerable1[T] source) [0x00055] in <63992662b765477a898ef49cdcc99ee2>:0 at LiteDB.LiteCollection1[T].FindById (LiteDB.BsonValue id) [0x00033] in <b85603d5f20d445f81a388a66cabd5f4>:0 at TictocDB.Internal.LiteSeriesCollection1[T].ReadQuery (TictocDB.SeriesQuery query, System.Int64 id) [0x001c4] in <4990a153cd7c4a8392f178b203d762b4>:0 at TictocDB.Internal.LiteSeriesCollection`1[T].Read (System.Int64 id) [0x00001] in <4990a153cd7c4a8392f178b203d762b4>:0 at TictocDB.Test.LiteSeriesDatasetConcurrencyTest.LiteSeriesDatasetConcurrency_OneDoc () [0x0008c] in <b99f24cb19404ffebfcefcfd72d02491>:0 at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&) at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00038] in <8f2c484307284b51944a1a13a14c0266>:0

[xied75]

If any of you are still interested, LiteDB now got a Travis CI build: https://travis-ci.org/mbdavid/LiteDB This means it works fine on Ubuntu 14.04 + dotnet core 1.0.1. There is no need to wait netstandard 2.0.

[mklinke]

FWIW, I am running a .Net Core 1.1 project with LiteDB 3.0.1 in a Docker container (i.e. on Linux). For sure, I have only used basic features yet. But for now, it’s working without problems. Though, it would be good to have the LiteDB shell in a .Net Core compatible version that would run cross-platform. Any plans in this regard? As the shell is just a console app, that should not be too hard. Looking forward to working with this great piece of software in our new .Net world beyond Windows.