Microsoft says the answer is “no”. https://devblogs.microsoft.com/dotnet/porting-to-net-core/ https://devblogs.microsoft.com/dotnet/porting-to-net-core/ scroll

Microsoft says the answer is “no”. https://devblogs.microsoft.com/dotnet/porting-to-net-core/ https://devblogs.microsoft.com/dotnet/porting-to-net-core/ scroll to “App Domains” and “Sandboxing” sections. Personally, I would still consider it. For a game, the risks are not that large, it’s not a bank nor a nuclear silo. You can use Mono.Cecil library to reflect assemblies without loading them as code or executing any parts of them. You gonna need to whitelist allowed imports (allow stuff like String/List/Dictionary but not much else), blacklist pointer types everywhere (function arguments, return values, and locals variables, CIL+metadata do have types of things), blacklist DllImportAttribute, and probably a few other things I forgot. The performance should be awesome that way, however security-wise that’s not 100% failsafe. Also easy to DoS your server by consuming too much CPU or using all the memory. You might need workarounds to address these issues. Mono.Cecil can patch code making new assemblies, not just inspect/reflect. Probably for these reasons MS discontinued app domains / code security, and recommends processes, containers or virtual machines instead. You can run another instance of .NET runtime inside these things, the startup/warmup time is not that bad, it's not a Java. P.S. If you only allow to edit code in your editor i.e. don’t need support for visual studio + Microsoft’s compiler, you can make your own language where only safe things are expressible, and compile that one into CIL. Simplifies many things, you only need to worry about CPU time and RAM usage. You don’t need to emit DLLs nor mess with CIL directly, can compile scripts into delegates using System.Linq.Expressions or probably some third-party libraries.