[Mono-list] System.Runtime.Serialization missing

Sat Feb 26 19:24:30 EST 2011

Hmm ... according to the JSON.Net versions.text file you should be
running net35 on the server.  Although I suspect 4.0 will work with
the latest Mono versions.  The problem might be that you simply need
to upgrade your server's Mono install.  Is that possible?

versions.txt:

Versions:

Json.NET comes in different versions for the various .NET frameworks.

-DotNet:
  .NET latest (4.0)

-DotNet35:
  .NET 3.5 SP1, Mono

-DotNet20:
  .NET 2.0

-Silverlight:
  Silverlight 4.0

-WindowsPhone:
  Windows Phone 7

Microsoft stopped support for the Compact Framework in Visual Studio 2010.
For a Compact Framework 3.5 build download Json.NET 3.5.

For a Silverlight 3.0 build down download Json.NET 3.5.

On Sat, Feb 26, 2011 at 7:21 PM, Abe Gillespie <abe.gillespie at gmail.com> wrote:
> What's "mono -V" reporting on the server?  Does using JSON.Net net2 work on it?
>
> -Abe
>
> On Sat, Feb 26, 2011 at 5:13 PM, David Auzinger
> <david.auzinger at gmail.com> wrote:
>> ok, an update:
>>
>> I uploaded a version of my program using JSON.Net net35, after it complained
>> about the missin sys.runtime.serialization.dll i uploaded the one i found on
>> my local machine --> runtime crash
>> My guess is, that the runtime crashes because my local mono version is newer
>> (2.10) than the one on the server (is there any way to find out the
>> installed mono version?)
>> here the stacktrace (if that helps anything):
>> **
>> ** ERROR:(object.c:2205):mono_object_get_virtual_method: assertion failed:
>> (res)
>> Stacktrace:
>>
>> at (wrapper managed-to-native)
>> System.Object.__icall_wrapper_compile_generic_method
>> (object,intptr,intptr,intptr) <0x0004e>
>> at (wrapper managed-to-native)
>> System.Object.__icall_wrapper_compile_generic_method
>> (object,intptr,intptr,intptr) <0xffffffff>
>> at Newtonsoft.Json.Serialization.DefaultContractResolver.GetDefaultCreator
>> (System.Type) <0x0003f>
>> at Newtonsoft.Json.Serialization.DefaultContractResolver.InitializeContract
>> (Newtonsoft.Json.Serialization.JsonContract) <0x0026b>
>> at
>> Newtonsoft.Json.Serialization.DefaultContractResolver.CreateObjectContract
>> (System.Type) <0x00054>
>> at Newtonsoft.Json.Serialization.DefaultContractResolver.CreateContract
>> (System.Type) <0x001e9>
>> at Newtonsoft.Json.Serialization.DefaultContractResolver.ResolveContract
>> (System.Type) <0x0013f>
>> at
>> Newtonsoft.Json.Serialization.JsonSerializerInternalReader.GetContractSafe
>> (System.Type) <0x00055>
>> at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadForType
>> (Newtonsoft.Json.JsonReader,System.Type,Newtonsoft.Json.JsonConverter)
>> <0x0003a>
>> at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize
>> (Newtonsoft.Json.JsonReader,System.Type) <0x00053>
>> at Newtonsoft.Json.JsonSerializer.DeserializeInternal
>> (Newtonsoft.Json.JsonReader,System.Type) <0x00062>
>> at Newtonsoft.Json.JsonSerializer.Deserialize
>> (Newtonsoft.Json.JsonReader,System.Type) <0x0002b>
>> at Newtonsoft.Json.JsonConvert.DeserializeObject
>> (string,System.Type,Newtonsoft.Json.JsonSerializerSettings) <0x00087>
>> at Newtonsoft.Json.JsonConvert.DeserializeObject
>> (string,Newtonsoft.Json.JsonSerializerSettings) <0x00021>
>> at Newtonsoft.Json.JsonConvert.DeserializeObject (string) <0x0000f>
>> at Crawler.MainClass.Main (string[]) <0x00c13>
>> at (wrapper runtime-invoke) Crawler.MainClass.runtime_invoke_void_string[]
>> (object,intptr,intptr,intptr) <0xffffffff>
>>
>> Native stacktrace:
>>
>> mono [0x536e71]
>> /lib/libpthread.so.0 [0x7f79114ada80]
>> /lib/libc.so.6(gsignal+0x35) [0x7f7910efaed5]
>> /lib/libc.so.6(abort+0x183) [0x7f7910efc3f3]
>> /usr/lib/libglib-2.0.so.0(g_assertion_message+0x104) [0x7f791191e004]
>> /usr/lib/libglib-2.0.so.0 [0x7f791191e4a2]
>> mono [0x45c0fc]
>> mono [0x523750]
>> [0x41bd3e3e]
>>
>> Debug info from gdb:
>>
>> [Thread debugging using libthread_db enabled]
>> [New Thread 0x7f791219f710 (LWP 4988)]
>> [New Thread 0x40655950 (LWP 4994)]
>> [New Thread 0x41176950 (LWP 4993)]
>> [New Thread 0x40f75950 (LWP 4992)]
>> [New Thread 0x40d74950 (LWP 4991)]
>> [New Thread 0x40893950 (LWP 4990)]
>> [New Thread 0x40b73950 (LWP 4989)]
>> 0x00007f79114ac7db in read () from /lib/libpthread.so.0
>> 7 Thread 0x40b73950 (LWP 4989) 0x00007f79114ad0e1 in nanosleep ()
>> from /lib/libpthread.so.0
>> 6 Thread 0x40893950 (LWP 4990) 0x00007f79114a9d29 in
>> pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
>> 5 Thread 0x40d74950 (LWP 4991) 0x00007f79114a9fad in
>> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
>> 4 Thread 0x40f75950 (LWP 4992) 0x00007f7910f98c18 in epoll_wait ()
>> from /lib/libc.so.6
>> 3 Thread 0x41176950 (LWP 4993) 0x00007f79114a9fad in
>> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
>> 2 Thread 0x40655950 (LWP 4994) 0x00007f79114a9fad in
>> pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
>> 1 Thread 0x7f791219f710 (LWP 4988) 0x00007f79114ac7db in read ()
>> from /lib/libpthread.so.0
>>
>> Thread 7 (Thread 0x40b73950 (LWP 4989)):
>> #0 0x00007f79114ad0e1 in nanosleep () from /lib/libpthread.so.0
>> #1 0x00000000004d5532 in collection_thread (unused=<value optimized out>)
>> at collection.c:34
>> #2 0x00007f79114a5fc7 in start_thread () from /lib/libpthread.so.0
>> #3 0x00007f7910f9864d in clone () from /lib/libc.so.6
>> #4 0x0000000000000000 in ?? ()
>>
>> Thread 6 (Thread 0x40893950 (LWP 4990)):
>> #0 0x00007f79114a9d29 in pthread_cond_wait@@GLIBC_2.3.2 ()
>> from /lib/libpthread.so.0
>> #1 0x00000000004dad55 in timedwait_signal_poll_cond (cond=0x7f79120f3268,
>> mutex=0x7f79120f3240, timeout=0x3, alertable=-1) at handles.c:1443
>> #2 0x00000000004dcfbb in _wapi_handle_timedwait_signal_handle (
>> handle=<value optimized out>, timeout=0x0, alertable=302985792)
>> at handles.c:1523
>> #3 0x00000000004e705e in WaitForSingleObjectEx (handle=0x404,
>> timeout=4294967295, alertable=0) at wait.c:200
>> #4 0x000000000053ccf3 in finalizer_thread (unused=<value optimized out>)
>> at gc.c:894
>> #5 0x00000000004c6d5b in start_wrapper (data=<value optimized out>)
>> at threads.c:589
>> #6 0x00000000004eaab3 in thread_start_routine (args=0x7f790fe50020)
>> at threads.c:282
>> #7 0x00000000004fe702 in GC_start_routine (arg=<value optimized out>)
>> at pthread_support.c:1374
>> #8 0x00007f79114a5fc7 in start_thread () from /lib/libpthread.so.0
>> #9 0x00007f7910f9864d in clone () from /lib/libc.so.6
>> #10 0x0000000000000000 in ?? ()
>>
>> Thread 5 (Thread 0x40d74950 (LWP 4991)):
>> #0 0x00007f79114a9fad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
>> from /lib/libpthread.so.0
>> #1 0x00000000004dad30 in timedwait_signal_poll_cond (cond=0x7f79120f3048,
>> mutex=0x7f79120f3020, timeout=0x40d73f60, alertable=<value optimized out>)
>> at handles.c:1453
>> #2 0x00000000004dcfbb in _wapi_handle_timedwait_signal_handle (
>> handle=<value optimized out>, timeout=0xffffffffffffff92,
>> alertable=302985248) at handles.c:1523
>> #3 0x00000000004e6e9a in WaitForSingleObjectEx (handle=0x400, timeout=10000,
>> alertable=1) at wait.c:202
>> #4 0x00000000004cd511 in async_invoke_thread (data=0x0) at threadpool.c:1226
>> #5 0x00000000004c6d5b in start_wrapper (data=<value optimized out>)
>> at threads.c:589
>> #6 0x00000000004eaab3 in thread_start_routine (args=0x7f790fe50168)
>> at threads.c:282
>> #7 0x00000000004fe702 in GC_start_routine (arg=<value optimized out>)
>> at pthread_support.c:1374
>> #8 0x00007f79114a5fc7 in start_thread () from /lib/libpthread.so.0
>> #9 0x00007f7910f9864d in clone () from /lib/libc.so.6
>> #10 0x0000000000000000 in ?? ()
>>
>> Thread 4 (Thread 0x40f75950 (LWP 4992)):
>> #0 0x00007f7910f98c18 in epoll_wait () from /lib/libc.so.6
>> #1 0x00000000004ccb47 in socket_io_epoll_main (p=<value optimized out>)
>> at threadpool.c:552
>> #2 0x00000000004c6d5b in start_wrapper (data=<value optimized out>)
>> at threads.c:589
>> #3 0x00000000004eaab3 in thread_start_routine (args=0x7f790fe502b0)
>> at threads.c:282
>> #4 0x00000000004fe702 in GC_start_routine (arg=<value optimized out>)
>> at pthread_support.c:1374
>> #5 0x00007f79114a5fc7 in start_thread () from /lib/libpthread.so.0
>> #6 0x00007f7910f9864d in clone () from /lib/libc.so.6
>> #7 0x0000000000000000 in ?? ()
>>
>> Thread 3 (Thread 0x41176950 (LWP 4993)):
>> #0 0x00007f79114a9fad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
>> from /lib/libpthread.so.0
>> #1 0x00000000004dad30 in timedwait_signal_poll_cond (cond=0x7f79120f3620,
>> mutex=0x7f79120f35f8, timeout=0x41175f60, alertable=<value optimized out>)
>> at handles.c:1453
>> #2 0x00000000004dcfbb in _wapi_handle_timedwait_signal_handle (
>> handle=<value optimized out>, timeout=0xffffffffffffff92,
>> alertable=302986744) at handles.c:1523
>> #3 0x00000000004e6e9a in WaitForSingleObjectEx (handle=0x40b, timeout=10000,
>> alertable=1) at wait.c:202
>> #4 0x00000000004cd3a0 in async_invoke_io_thread (data=0xfffffffffffffdfc)
>> at threadpool.c:284
>> #5 0x00000000004c6d5b in start_wrapper (data=<value optimized out>)
>> at threads.c:589
>> #6 0x00000000004eaab3 in thread_start_routine (args=0x7f790fe503f8)
>> at threads.c:282
>> #7 0x00000000004fe702 in GC_start_routine (arg=<value optimized out>)
>> at pthread_support.c:1374
>> #8 0x00007f79114a5fc7 in start_thread () from /lib/libpthread.so.0
>> #9 0x00007f7910f9864d in clone () from /lib/libc.so.6
>> #10 0x0000000000000000 in ?? ()
>>
>> Thread 2 (Thread 0x40655950 (LWP 4994)):
>> #0 0x00007f79114a9fad in pthread_cond_timedwait@@GLIBC_2.3.2 ()
>> from /lib/libpthread.so.0
>> #1 0x00000000004dad30 in timedwait_signal_poll_cond (cond=0x7f79120f3620,
>> mutex=0x7f79120f35f8, timeout=0x40654f60, alertable=<value optimized out>)
>> at handles.c:1453
>> #2 0x00000000004dcfbb in _wapi_handle_timedwait_signal_handle (
>> handle=<value optimized out>, timeout=0xffffffffffffff92,
>> alertable=302986744) at handles.c:1523
>> #3 0x00000000004e6e9a in WaitForSingleObjectEx (handle=0x40b, timeout=10000,
>> alertable=1) at wait.c:202
>> #4 0x00000000004cd3a0 in async_invoke_io_thread (data=0xfffffffffffffdfc)
>> at threadpool.c:284
>> #5 0x00000000004c6d5b in start_wrapper (data=<value optimized out>)
>> at threads.c:589
>> #6 0x00000000004eaab3 in thread_start_routine (args=0x7f790fe50540)
>> at threads.c:282
>> #7 0x00000000004fe702 in GC_start_routine (arg=<value optimized out>)
>> at pthread_support.c:1374
>> #8 0x00007f79114a5fc7 in start_thread () from /lib/libpthread.so.0
>> #9 0x00007f7910f9864d in clone () from /lib/libc.so.6
>> #10 0x0000000000000000 in ?? ()
>>
>> Thread 1 (Thread 0x7f791219f710 (LWP 4988)):
>> #0 0x00007f79114ac7db in read () from /lib/libpthread.so.0
>> #1 0x00007f791192e5fe in ?? () from /usr/lib/libglib-2.0.so.0
>> #2 0x00007f791192eae6 in ?? () from /usr/lib/libglib-2.0.so.0
>> #3 0x00007f791192f53b in g_spawn_sync () from /usr/lib/libglib-2.0.so.0
>> #4 0x00007f791192f9f8 in g_spawn_command_line_sync ()
>> from /usr/lib/libglib-2.0.so.0
>> #5 0x0000000000536f09 in mono_handle_native_sigsegv (
>> signal=<value optimized out>, ctx=<value optimized out>)
>> at mini-exceptions.c:1044
>> #6 <signal handler called>
>> #7 0x00007f7910efaed5 in raise () from /lib/libc.so.6
>> #8 0x00007f7910efc3f3 in abort () from /lib/libc.so.6
>> #9 0x00007f791191e004 in g_assertion_message () from
>> /usr/lib/libglib-2.0.so.0
>> #10 0x00007f791191e4a2 in g_assertion_message_expr ()
>> from /usr/lib/libglib-2.0.so.0
>> #11 0x000000000045c0fc in mono_object_get_virtual_method (
>> obj=<value optimized out>, method=0x7f790815c020) at object.c:2205
>> #12 0x0000000000523750 in mono_helper_compile_generic_method (
>> obj=0x7f7912064220, method=0x7f790815c020, context=0x7f790815c068,
>> this_arg=0x7fff4c807250) at jit-icalls.c:793
>> #13 0x0000000041bd3e3e in ?? ()
>> #14 0x0000000001561ee0 in ?? ()
>> #15 0x0000000041bd1aa9 in ?? ()
>> #16 0x0000000000000000 in ?? ()
>> #0 0x00007f79114ac7db in read () from /lib/libpthread.so.0
>>
>>
>> =================================================================
>> Got a SIGABRT while executing native code. This usually indicates
>> a fatal error in the mono runtime or one of the native libraries
>> used by your application.
>> =================================================================
>>
>> Aborted
>>
>> Regards
>> David Auzinger
>> 2011/2/26 David Auzinger <david.auzinger at gmail.com>
>>>
>>> On the local machine it runs just fine with net35, on the server i used
>>> the same version, but - as i said - i'm looking into it and will report back
>>> here.
>>>
>>> Regards
>>> David Auzinger
>>> 2011/2/26 Abe Gillespie <abe.gillespie at gmail.com>
>>>>
>>>> JSON.Net is packaged with three versions not counting SL: net, net20,
>>>> net35 (where "net" is the latest version of .Net - 4.0).  You might
>>>> need one version on the client and another version on the server.  If
>>>> this *is* the problem I would guess that the server is needing net35
>>>> where the client needs net.
>>>>
>>>> -Abe
>>>>
>>>> On Sat, Feb 26, 2011 at 4:45 PM, David Auzinger
>>>> <david.auzinger at gmail.com> wrote:
>>>> > I'm not using Silverlight, the program is just a simple console-app.
>>>> > But now
>>>> > I'm quite sure the problem is not faulted by mono but by the
>>>> > differences in
>>>> > versions. The mono version on the server is as far as i know an older
>>>> > one.
>>>> > Another option is that the mono-installation on the server is
>>>> > incomplete,
>>>> > because it is a Debian-box an the way of installing mono that is
>>>> > described
>>>> > on the mono project page didn't work for me (for whatever reason) and i
>>>> > fiddled around with it for a while until i got it going.
>>>> > So - I'm pretty sure it's not the fault of mono ;)
>>>> > Anyways I'll look into it again.
>>>> > Regards
>>>> > David Auzinger
>>>> > 2011/2/26 Abe Gillespie <abe.gillespie at gmail.com>
>>>> >>
>>>> >> You've found a work-around, but for the health of the Mono project in
>>>> >> general this should be tracked down.  Also, Newtonsoft's JSON
>>>> >> serializer is so incredibly well baked that I hope I can urge you back
>>>> >> to using it.  In fact I've recently run into some WCF serialization
>>>> >> bugs (MS.Net, not Mono) that I categorically replaced all
>>>> >> runtime-provided serialization with JSON.Net.  It works a treat.
>>>> >>
>>>> >> Now, about your issues, one thing I've run into with getting the
>>>> >> correct version of Sys.Run.Serialization linked in is Silverlight
>>>> >> assemblies (2.0.5.*) vs. the full runtime assemblies (3.x and 4.x).
>>>> >> Make sure your environments match the correct assembly versions on
>>>> >> both sides - for example, if you are in fact using Silverlight then
>>>> >> you need to drop in the Newtonsoft.Json.Silverlight.dll assembly and
>>>> >> not the Newtonsoft.Json.dll assembly.
>>>> >>
>>>> >> A possible other issue is a bug in Mono that's currently affecting at
>>>> >> least some of the serialization infrastructure
>>>> >> https://bugzilla.novell.com/show_bug.cgi?id=669786 ... though for your
>>>> >> specific case I doubt this is the issue.  But, like I said, for the
>>>> >> health of Mono you'll hopefully investigate further.
>>>> >>
>>>> >> -Abe
>>>> >>
>>>> >> On Sat, Feb 26, 2011 at 3:54 PM, David Auzinger
>>>> >> <david.auzinger at gmail.com> wrote:
>>>> >> > Ok I solved my Problem by switching to a different JSON serializer
>>>> >> >
>>>> >> > Regards
>>>> >> > David Auzinger
>>>> >> > 2011/2/26 David Auzinger <david.auzinger at gmail.com>
>>>> >> >>
>>>> >> >> Some Additional Information:
>>>> >> >> When i upload the System.Runtime.Serialization.dll i get the same
>>>> >> >> error
>>>> >> >> again but with System.Data, when i upload the System.Data.dll the
>>>> >> >> runtime
>>>> >> >> crashes ;)
>>>> >> >> But I'm not sure of the mono Verison installed on the sever, so
>>>> >> >> this
>>>> >> >> may
>>>> >> >> be faulted by a version mismatch.
>>>> >> >> Regards
>>>> >> >> David Auzinger
>>>> >> >> 2011/2/26 David Auzinger <david.auzinger at gmail.com>
>>>> >> >>>
>>>> >> >>> Hi
>>>> >> >>>
>>>> >> >>> (I hope I'm right here. I would have posted this in the mini
>>>> >> >>> forums
>>>> >> >>> but I
>>>> >> >>> can't access them)
>>>> >> >>> I'm developing on a windows machine with Visual Studio Express
>>>> >> >>> 2010 (i
>>>> >> >>> started with monodevelop, but then it kept greying out the
>>>> >> >>> Run/Debug
>>>> >> >>> options
>>>> >> >>> in the menu and i had to switch). As for my knowledge: I'm quite
>>>> >> >>> used
>>>> >> >>> to C#,
>>>> >> >>> though no pro, same with linux in general and this is my first
>>>> >> >>> mono-project.
>>>> >> >>> A part of the program I'm writing is a deserialization of JSON
>>>> >> >>> data.
>>>> >> >>> This
>>>> >> >>> is don using JSON.Net. When compiling and running the code on the
>>>> >> >>> windows
>>>> >> >>> machine, everything works just fine, on the target machine (a
>>>> >> >>> debian
>>>> >> >>> server)
>>>> >> >>> however it crashes when i try to use JSON.Net and gives me a
>>>> >> >>> message
>>>> >> >>> about
>>>> >> >>> System.Runtime.Serialization Assembly could not be found
>>>> >> >>> (Assembly:
>>>> >> >>> System.Runtime.Serialization (assemblyref_index=5), Version =
>>>> >> >>> 3.0.0.0
>>>> >> >>> Public
>>>> >> >>> Key: b77a5c561934e089)
>>>> >> >>> I would appreciate any help!
>>>> >> >>> Regards
>>>> >> >>> David Auzinger
>>>> >> >
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > Mono-list maillist  -  Mono-list at lists.ximian.com
>>>> >> > http://lists.ximian.com/mailman/listinfo/mono-list
>>>> >> >
>>>> >> >
>>>> >
>>>> >
>>>
>>
>>
>