3 ms·
Remoting/app domains/Code access security were ripped out of the .NET Core codebase, and there is really not much of a chance of them returning. The CoreFX code
by jsmith45 7y ago
Remoting/app domains/Code access security were ripped out of the .NET Core codebase, and there is really not much of a chance of them returning. The CoreFX codebase has systematically removed all the code needed for things to safely work with those features, and re-implementing them would be unfeasible.
As for webforms. Well, the whole hosting model for IIS worker processes was based on appdomains. Further, w3wp.exe has special code for loading and integrating with the Framework, enabling managed modules. This is the whole System.Web.dll concept. Microsoft really does not seem to want to put in much effort to fix that.
Since Microsoft always recomended hosting WCF services in IIS, which therefore relied on the whole System.Web.dll mess which I think is a large part of the reason thy don't want to port that.
That said, other than replacing XML configuration, self-hosted WCF services should be pretty easy for them to port.
- merb 7y agoapp domains basically now have a better alternative with Application Parts or for the heavy lifting AssemblyLoadContext (https://docs.microsoft.com/de-de/dotnet/core/tutorials/creating-app-with-plugin-support https://docs.microsoft.com/de-de/dotnet/core/tutorials/creat...)
- jsmith45 7y agoAssemblyLoadContext with assembly unloading is not at all compatible with .NET Framework 4.X, which can be a pain if you want to gradually migrate stuff. Also it does not have anywhere near the same level of isolation, which is part of what System.Web.dll was using them for. Would it be possible to it in a system.Web.dll port? Certainly, but you would be changing the semantics enough that some applications would notice the difference, and probably not in a good way.
- merb 7y agoyeah I mean unloading is not even that good without a .net core 3.0 preview. I think that in 5-10 years new stuff will emerge based on AssemblyLoadContext, maybe even some kind of OSGi just a little bit easier. Some examples are really promising and AssemblyLoadContext does not have the same problems as Java solutions. (duplicate Class Files, etc...) the only thing that is missing is some kind of security related stuff.
- wvenable 7y ago> As for webforms. Well, the whole hosting model for IIS worker processes was based on appdomains. But I wonder if you could just stub that out with a mock AppDomain object in C# to keep the API the same. Is there actually anything that's truly dependent on it being an actual "AppDomain"?