Raloth, have you actually tried and profiled the multi-AppDomain solution? I would always give it a try because AppDomains are *the* solution to have parts of an app run under more restrictive security settings. Furthermore you will be able to unload the script dll by unloading the AppDomain. Always keep in mind that most games are not CPU limited.

There are several things you can do to minimize boundary crossing. Most of the time the client-code is called at only one place of the gameloop. Load some kind of proxy dll into the second AppDomain which will provide an interface to most of the datamanipulation necessary for the game. Then, when the script requires some data, let the proxy pull it over the boundary and cache it. The next time it is accessed get it from the cache. When the script is done flush all data changes back to the main AppDomain. This can minimize the number of cross-AppDomain calls.


Regards,
Andre

I have found a solution more elegant than I could have hoped for:

[SecurityPermissionAttribute(SecurityAction.PermitOnly, Flags = SecurityPermissionFlag.Execution)]

By putting this in front of any method calls (or objects) involved with the actual scripting, I can change the security for just that call (or object).

[smile]

I may still have to look into AppDomains in order to unload the custom scripts, but there is no reason I can't simply shove all of the game data in the same AppDomain so there is no overhead. It's not needed while the user is in the lobby anyway, so it has the added benefit of saving (a minute amount of) memory.

Quote:Original post by SOS
I have a feeling that if the called code creates a new thread, that thread will not have the restritced permissions. You might want to check it out.

Ah...but the called code does not have the permission to create the thread in the first place. =)