As I understand it a web published game can not use DLLIMPORT, which makes sense to me.
However, if I create my own sync/async socket code using System.Net, will there be any sandbox-ish issues with connectivity? For example, any limitations enforcing that I connect back only to the server which vended the page?
I guess another way to pose this is:
Will there be any differences in what I can and can’t do with sockets for a web published game vs. standalone game?
On a related note, how do I use a 3rd party .net library assembly from my C# game code and have that assembly be automatically downloaded and available when web publishing? Is it even possible?
Have you tried with your client to make connections to a server other than what vended the web page? I know this works in Fusion Fall.
That’s great to hear that simply dropping in any old C# assembly into the assets folder is automatically downloaded and used. Very powerful.
This does make we wonder…under what security context is this referenced assembly executing? For example, can it directly access the local hard-drive, write/delete files, etc. assuming the user has appropriate permissions? Or is the plugin enforcing a particular AppDomain security context to prevent malicious code from executing?
If it runs outside the sandbox, then there’s no reason to not allow DLLIMPORT. The same abuses are allowable either way from a security standpoint!
Also, will executuable assemblies work as well in the assets folder, not just dll’s? As you may know, with .Net and mono, you can Reference and use public classes from either assembly type, it doesn’t have to be a library assembly (ie .dll).
Can you point me to where in the docs you found this?
I’m curious to see if they are simply embedding the other assembly as a resource, or actually disassembling it and merging the IL. The later would be tricky, but quite slick. The former would be cake; done it many times myself.
Yes, it would be nice if somebody officially responds to this. I’m very curious what the security constraints are if any, and the mechanisms that are in place.
From the docs it sounds like the IL is merged. Pretty cool, avoids needing a second app domain and security context at runtime. I can imagine problems though when using 3rd party assemblies; some of them really don’t disassemble well due to protection mechanisms. It would be great if somebody from Unity could confirm that this indeed is what happens (ie disassembly and IL merge) at publish time.
I do assume that the compiled game itself does run in somewhat of a locked down context when in the web player…can’t wait to hear what constraints there are if any.
If anybody knows any details on that I’d really like to hear…
basically webplayers can not access files, registry or processes on the machine. Also native plugins don’t exist on webplayers (but thats self explaining I guess)
Not all browser plugins and web players are restricted to this, but if Unity’s is that’s fine.
In particular, how do you save local files for game saving? Or are game saves only supported back over the network?
Is there no piece of documentation anywhere which explicitly states which Unity features won’t work when published for web player. I have been unable to find it…
you can not save anything on the system other than PlayerPrefs
If you want to store them on a webspace, then this is up to you how you do it WWW and System.Net with the tcpsocket might be good starting points
its really only the system security related things that are disallowed, thats fileIO, registry and process access