From memory, Microsoft took AppDomain away, and this mechanism has been shut down.
Now I suddenly find AppDomain has come back:
Assembly System.Runtime.Extensions, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a\dotnet\packs\Microsoft.NETCore.App.Ref\3.0.0\ref\netcoreapp3.0\System.Runtime.Extensions.dll
the assembly contains the AppDomain class.
Here is my question: why?
Why was it discontinued? AppDomains require runtime support and are generally quite expensive. While still implemented by CoreCLR, it’s not available in .NET Native and we don’t plan on adding this capability there.
What should I use instead? AppDomains were used for different purposes. For code isolation, we recommend processes and/or containers. For dynamic loading of assemblies, we recommend the new AssemblyLoadContext class.
Furthermore
Of course, just because something isn’t available in .NET Core today doesn’t mean we discontinued it. In most cases, it simply means we haven’t had the time to investigate whether porting would make sense or didn’t think it was relevant to the application models .NET Core currently offers. Thus, this is an area we’re highly interested in getting your feedback.
So what is actually supported?
On .NET Core, the AppDomain implementation is limited by design and does not provide isolation, unloading, or security boundaries. For .NET Core, there is exactly one AppDomain. Isolation and unloading are provided through AssemblyLoadContext. Security boundaries should be provided by process boundaries and appropriate remoting techniques.
It's there for certain tasks, however it's not supported in a lot of ways.
Applies to
.NET Core
- 3.0 2.2 2.1 2.0
.NET Framework
- 4.8 4.7.2 4.7.1 4.7 4.6.2 4.6.1 4.6 4.5.2 4.5.1 4.5 4.0 3.5 3.0 2.0 1.1
.NET Standard
- 2.1 2.0
So what happens if you use something that is not supported?
It's either not there, or you get a big nasty evident throw new NotSupportedException or PlatformNotSupportedException depending on the when where and whys
Further reading
