Webplayer limited support of .Net?

I sent an email to support and filed a bug but I got no official response so I thought I’d try here and see if anyone new the official word on this topic.

It seems that the webplayer offers a limited subset of .Net functionality? Is this intentional? I understand that web servers have different ‘functionality’ to that of a desktop machine however the two I need don’t seem to be something a webserver machine couldn’t translate appropriately.

‘System.File’ doesn’t function.
‘DateTime’ isn’t supported.

If it’s a ‘desired’ outcome that these aren’t supported then is there a list somewhere of what I can’t use on a webplayer build of the game? :face_with_spiral_eyes:

Thanks for any help in this area.

DateTime is certainly supported. As far as I know, the only thing that’s not is file I/O, for obvious reasons.

–Eric

Yes this is intentional.

Any access to the system is cut, means no system.environment, system.file and alike
thats intend.
also system.security and the whole webrequests framework are cut

If you want to store files locally you must license the cache addon license for UT, only available upon request to sales@unity3d.com with per project costs.

There is no list of what all is gone, but you can assume that System, System.Text, System.Collections and System.Collections.Generic is present

System.Environment stuff does work in the webplayer. So does System.Security. (At least any of the functions I’ve used.)

–Eric

The relevant parts though used by other frameworks and 3rd party libraries do not work.
System.Security fails on things like the security describer and alike, required for various thing and environment fails at hw data required for encrypting connections securly for ssl and similar.

but yes, some of the things are working actually. but “some do, some don’t” is more painfull than “none do” as it becomes a total hit and miss game.

would be easier if webplayer = moonlight / silverlight level of functionality and point.
but the full not the part that UT feels like it handing out. This way the environment would be standardized and cleanly defined and it would also resolve other problems and feature requests that got closed although not implemented (limited write access to a cache folder with user exposed size restriction as flash etc have it, full http requests, not just WWW, …)

Alright thanks for the info.

I guess people who want to make stand alone (offline) / webplayer versions of their apps need to make a file wrapper and interchange file access with WWW as needed?

if interchange file access with WWW means against a webserver then yes, because file:// does not work either

Just one recommendation: design your game to be a webplayer and ensure that that works. cause if that does, the standalone will commonly too.
The vice versa doesn’t hold

Yeah I didn’t mean direct file access I meant querying / writing data from SQL servers or something similar.

Anyway thanks again. Shame this information isn’t in the help docs and/or produce build errors :S