Sandbox.Reflection Namespace

In the base gamemode’s accesslist.txt, there seems to be a call to Sandbox.Reflection.GetProperties(Object)

Does that mean we’ll get access to a wrapper for System.Reflection?

I’m currently working on an administration framework that makes heavy use of Reflection for things like attributes, and dynamically invoking methods/reflection created delegates for custom commands.

Not being able to use Reflection clientside for this would cut a lot of functionality, and force me to network things from the server such as a list of commands and their arguments, even though that could be built clientside with Reflection. As you could imagine, that’s a bit of a waste of bandwidth, especially if there’s a lot to send.


Source code generators could be a better alternative to reflection in some use cases and dont need any special access


Will we have access to these?

EDIT: Also something that was discussed on the FP server, wouldn’t it be technically possible to make a 1:1 Reflection wrapper, and check which assemblies are being accessed through it? Forbid any non-addon assembly that way.

1 Like

Yeah it’s a wrapper. We still haven’t totally worked out whether it’s better to just allow standard Reflection and blacklist the exploitable stuff or safely wrap it.

Leaning towards safely wrapping stuff right now though.


Thanks a lot!

Something that came up on the Discord server was only allowing Reflection to be used on addon assemblies, checking that via the wrapper. Dunno if it gives you any ideas, or if that’s already the case.

Safely wrapping would be awesome since a lot of code relies heavily on it ^^

EDIT: Looks like I already mentioned that above, oops.

1 Like