1

I recently learned that AppDomain is not fully supported in .NET Core, and they have no plans so far of implementing full support.

What I am trying to do is to make a program that can run a plugin, but I don't want that plugin to be able to access certain assemblies or namespaces (for instance System.IO).

The way I used to solve this problem prior to .NET Core will no longer work due to the lack of support.

Is there any other way I can achieve the same in .NET Core?

More concrete example

Let's say I load an assembly using Assembly.LoadFrom from the file system, which contains a plugin method that I then invoke. But I don't want plugins to be able to erase files, etc. In fact, I only want the plugin to be able to call functions from a specific assembly.

Mathias Lykkegaard Lorenzen
  • 15,031
  • 23
  • 100
  • 187
  • Here's some light reading on `System.AddIn` which also doesn't look like it's going to make it into .NET Core [link](https://github.com/dotnet/corefx/issues/6920) – Adam Vincent Jul 18 '18 at 19:37

1 Answers1

4

Basically they want you to use the platform boundaries for the environment you are developing for.

Sandboxing

Why was it discontinued?

Sandboxing, i.e. relying on the runtime or the framework to constrain which resources a managed application can access, is considered a non-goal for .NET Core. Sandboxing applications and components is also really hard to get right, which is why generally recommend customers not to rely on it. It also makes the implementation more complicated and often negatively affects performance of applications that don’t use sandboxing. Hence, we do not offer sandboxing features in .NET Core.

What should I use instead?

Use operating system provided security boundaries, such as user accounts for running processes with the least set of privileges.

https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

Victor Procure
  • 886
  • 1
  • 6
  • 17