Trouble with Mono

Sep 29, 2013 at 10:06 PM
I'm having some trouble using this library on Mono 2.10. I'm not sure why you provide your own System.Threading dll but it calls a Windows specific function "SwitchToThread" which throws the following error on Mono:

[ERROR] FATAL UNHANDLED EXCEPTION: System.EntryPointNotFoundException: SwitchToThread
at (wrapper managed-to-native) System.Threading.Platform:SwitchToThread ()
at System.Threading.Platform.Yield () [0x00000] in <filename unknown>:0
at System.Threading.SpinWait.SpinOnce () [0x00000] in <filename unknown>:0

What is the solution here? Thanks in advance.

Derek
Sep 30, 2013 at 3:27 AM
In Mono, please use .NET 4.0 version of SuperSocket, which doesn't have the assembly System.Threading.dll
Sep 30, 2013 at 3:33 AM
Edited Sep 30, 2013 at 3:34 AM
Crap... unfortunately all of the other projects in the solution are built against version 3.5. This is because some of these projects are used on the client side which happens to run inside the Unity3d engine. The Unity3d engine is still running Mono 2.6 :( Do you have any other ideas? Otherwise, I might have to modify your code to work using the 3.5 System.Threading assembly. How hard do you think that would be?

EDIT: Correction, It's actually Mono 2.6!
Sep 30, 2013 at 3:39 AM
One idea would be to maintain two solutions, one client solution that is version 3.5 and does not include your library, and a server solution that is version 4.0 and contains your library. It would be a pain to maintain two separate solutions using two different framework versions but it would work as a last resort.
Sep 30, 2013 at 3:45 AM
No, you cannot.

I feel very strange the server side environment depends on your client side environment.

I think you can run your server application in Mono/.Net 4.0 but your client can run in any version of mono/.net, even the client can be a non-dotnet client like Java or iOS. The only one you want to keep consistent is the protocol which is used for communication between each other.
Sep 30, 2013 at 3:56 AM
I think you should use two projects instead of two solutions. One solution has many projects in different .NET runtime. And if you have some code should be shared between projects, you can use adding source code as link.