I can see that AppDomain and its members are now part of .NET Standard 2.0 but when I look at its .NET Core impl, its CreateDomain method throws PlatformNotSupportedException.
I am confused as to understand why this API is part of .NET Standard 2.0 at the first place.
One would think that compile time failure would be a better user experience here rather than a runtime one for this.
I am totally in favour of not relying on AppDomains for isolation and instead, using process isolation. So, I am not looking for an answer around implementing this as part of .NET Core. However, it would be nice if someone can explain the rationale behind including that API as part of .NET Standrard and how .NET Core 2.0 is seen as .NET Standard 2.0 compliant.
I just tested this on Windows, just in case someone tries to point out that the code could be a reference implementation.
It throws the PlatformNotSupportedException on Windows 10, with the latest RTM bits of .NET Core 2.0 and Visual Studio 2017 installed (and used to compile and test this):
Unhandled Exception: System.PlatformNotSupportedException: Secondary AppDomains are not supported on this platform.
at System.AppDomain.CreateDomain(String friendlyName)
at ConsoleApp3.Program.Main(String[] args) in D:\Dev\VS.NET\ConsoleApp3\ConsoleApp3\Program.cs:line 12
This makes me wonder how many other API's part of .NET standard will throw the same type of undocumented exception.
These FAQ entries might be helpful:
From a .NET Core point of view it is covered here https://docs.microsoft.com/en-us/dotnet/core/porting/libraries
@mairaw @karelz is there a plan to update .NET Core docs using data in https://github.com/dotnet/corefx/wiki/ApiCompat ?
No such plan yet, but it would make sense. We should finalize the info first though.
@akoeplinger pointers are exactly the reason.
Most helpful comment
These FAQ entries might be helpful: