Added support for Mono/Linux

This patch allows to use the FoundationDB client on Mono/Linux, tested on ver. 3.7 and CentOS 6.5

Just define MONO and it will compile for Mono/Linux
From http://www.mono-project.com/Interop_with_Native_Libraries

"There are two other issues with classes. First of all, classes by default
use LayoutKind.Auto
<http://docs.go-mono.com/index.aspx?link=F%3ASystem.Runtime.InteropServices.LayoutKind.Auto>
layout. This means that the ordering of class data members is unknown, and
won't be determined until runtime. The runtime can rearrange the order of
members in any way it chooses, to optimize for access time or data layout
space. As such, you *MUST* use the StructLayout
<http://docs.go-mono.com/index.aspx?link=T%3ASystem.Runtime.InteropServices.StructLayoutAttribute>
attribute and specify a LayoutKind
<http://docs.go-mono.com/index.aspx?link=E%3ASystem.Runtime.InteropServices.LayoutKind>
value of LayoutKind.Sequential
<http://docs.go-mono.com/index.aspx?link=F%3ASystem.Runtime.InteropServices.LayoutKind.Sequential>
or LayoutKind.Explicit
<http://docs.go-mono.com/index.aspx?link=F%3ASystem.Runtime.InteropServices.LayoutKind.Explicit>
."

CriticalHandles are clases and the base class is missing the StructLayout
attribute, there is where this error come from.

To ensure there was no mistake from my part I have tested again to add the
StructLayout to all the derived Criticalhandle's and tried again, it gives
the same exact error.

Cheers.


2014-08-11 14:43 GMT+02:00 Christophe Chevalier <notifications@github.com>:

> In FoundationDB.Client/Native/FdbNative.cs:
>
> > @@ -62,6 +68,434 @@ internal static unsafe class FdbNative
> >  		internal static class NativeMethods
> >  		{
> >
> > +#if MONO
> > +
> > +
> > +			private static class RealNativeCalls
>
> Is it still the case though? The page says that it is the case for
> SafeHandle in structs, by we don't have any structs in the native code
> (only passed by args).
>
> In one special case (SafeHandles in sturctures that are passed as
> parameters in P/Invoke functions) we are not calling AddRef/ReleaseRef
> because we would have to keep track of the original handle, but this data
> is currently not available in the release/cleanup code for marshalling.
>
> This blog post talks a bit about this issue as well (at the end)
> http://tirania.org/blog/archive/2006/Dec-16-1.html
>
> If you could do the test to see if SafeHandles passed by value as
> argument, or obtained via a return value are working fine on current
> version Mono, it would simplify the pinvoke code a lot by removing most of
> the #ifdef needed.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/Doxense/foundationdb-dotnet-client/pull/31/files#r16050294>
> .
>