Hello There,
I have been trying to write a C# server which streams preprepared GameObjects via UDP connection.
For some reason the WWW class can only stream assetbundles from my file system but not from my apache web server so I picked this path. Besides I believe a reliable UDP connection would probably act faster than TCP(WWW) connection for large scale MMOs.
Therefore I have tried copying the UnityEngine.dll from the Unity SDK directory and put it to my new C# console application folder. I have added it to my application as a resource and now IDE can auto-complete class names right inside editor. Also the code compiles fine without a problem(it just instantiates an empty game object). The problem occurs at run time however. That it throws a security exception which says:
“ECall methods must be packaged into a System Module.”
I have done a quick search of this topic in MSDN forums and on Google however I could not find a satisfactory answer yet. I know this may not be a proper topic to bring to these forums but still I am hoping for an answer.
Have any of you experienced such a problem before? Can anyone help me??? And also is the path I have picked is doable from an expert viewpoint?
Thanks.
I think you may have a tough road ahead of you on this one.
That error is thrown from Native calls from Unity, all of which have the Attribute [MethodImpl(MethodImplOptions.InternalCall)] which on MSDN specifies:
Specifies an internal call. An internal call is a call to a method that is implemented within the common language runtime itself.
Unity embeds Mono into it’s engine. This means the C++ code runs the .Net/Mono code and not the other way around. You can’t run the UnityEngine DLL (Although you can reflect against it, and make a file format that will create the objects once back in Unity), because you can’t call it’s functions without intializing the .Net/Mono environment from the Unity Engine itself.
Or at least this is what I’ve extrapolated so far from my tinkering and working with Unity and trying to implement features of the Mono.Framework.
Don’t copy the Unity’s dlls to other projects. They won’t work.
Besides: They don’t contain anything you need on the server-side. If you want to develop a server and go as low as socket-usage, you can start a new project in MD or VS and reference System.Net. That’s a dll that exists in the DotNet framework and is independent of Unity.
Alternatively, start on a different level of complexity. There is a reason why others offer their networking solutions. Lidgren (e.g.) saves you the time to implement sockets and make them work effectively. On top of that, there are solutions which include a server framework. Check out this list: http://forum.unity3d.com/threads/95277-Networking-Server-Comparison-Chart
That’s not true at all. TransportLayer has a lof functionality that is used in servers for listening, QoS, message sending and receiving that is above the bare sockets level.
Your suggestion to use .Net’s sockets would mean you’d have to replicate a lot of functionality already present in TransportLayer
I know that was an old post from 2011, but it still needs to be clarified for anyone looking in 2016.
1 Like