Microsoft'un .NET Core'da AppDomains'i desteklememesinin güçlü bir nedeni var mı?

AppDomains, sunucu tarafından yüklenen derlemeleri, sunucuyu kapatmadan zarif bir şekilde güncellemek isteyebileceğimiz uzun çalışan sunucu uygulamaları oluştururken özellikle yararlıdır.

AppDomains olmadan, uzun süren bir sunucu sürecinde montajlarımızı nasıl değiştireceğiz?

AppDomains ayrıca bize sunucu kodunun farklı bölümlerini izole etmenin bir yolunu sunar. Örneğin, özel bir websocket sunucusu birincil uygulama alanında soket koduna sahipken, hizmetlerimiz ikincil uygulama alanında çalışır.

AppDomains olmadan yukarıdaki senaryo mümkün değildir.

Montaj değişikliklerini ele almak ve AppDomains'in ek yüküne maruz kalmak zorunda kalmamak için VM'lerin Cloud kavramını kullanma hakkında konuşabilecek bir argüman görebiliyorum. Ancak Microsoft'un düşündüğü veya söylediği bu mu? veya yukarıdaki senaryolar için belirli bir nedenleri ve alternatifleri var mı?

.NETCore alt kümesinin amacı, .NET kurulumunu küçük tutmaktı. . Ve taşınması kolay. Bu nedenle, diyelim ki hem Windows hem de OSX'te bir Silverlight uygulaması çalıştırabilir ve web sayfasını ziyaret ettiğinizde çok uzun süre beklemeyebilirsiniz. Tam çalışma zamanını ve çerçeveyi indirmek ve kurmak birkaç saniye sürer, ister verin ister alın.

Küçük tutmak, kaçınılmaz olarak özelliklerin kesilmesini gerektirir. Remoting bu listede çok yüksekti, oldukça pahalı. Aksi takdirde iyi gizlenir, ancak örneğin temsilcilerin artık işlevsel bir BeginInvoke () yöntemine sahip olmadığını görebilirsiniz. Bu, AppDomain'i de kesim listesine koydu, uzaktan destek olmadan bir uygulama alanında kod çalıştıramazsınız. Yani bu tamamen tasarım gereğidir.

.NET Standard 2 ve .NET Core 2 için güncelleştirme

.NET Standart 2'de AppDomainsınıf olduğunu içeride. Ancak, bu API'nin birçok parçası birPlatformNotSupportedException for .NET Core .

Hala orada olmasının ana nedeni , işe yarayacak bir işlenmemiş istisna işleyicisini kaydetmek gibi temel şeyler içindir .

.NET Standard SSS'de şu açıklama bulunur :

AppDomain, .NET Standard'ın bir parçası mı?

AppDomain türü .NET Standard'ın bir parçasıdır. Tüm platformlar yeni uygulama etki alanlarının oluşturulmasını desteklemez; örneğin, .NET Core desteklemez, bu nedenle .NET Standard'da kullanılabilirken AppDomain.CreateDomain yöntemi PlatformNotSupportedException oluşturabilir.

Bu türü .NET Standard'da göstermemizin birincil nedeni, kullanımın oldukça yüksek olması ve genellikle yeni uygulama etki alanları oluşturmakla ilişkili olmaması, ancak işlenmemiş bir istisna işleyicisinin kaydedilmesi veya uygulamanın temel dizinini istemek gibi mevcut uygulama etki alanıyla etkileşimde bulunmaktır. .

Bunun dışında, en iyi cevap ve diğer cevaplar, AppDomain'in büyük kısmının neden hala kesildiğini de güzel bir şekilde açıklıyor (örneğin, desteklenmeyen bir istisna atıyor).

Uygulama Alanları

Neden durduruldu? AppDomains, çalışma zamanı desteği gerektirir ve genellikle oldukça pahalıdır. Hala CoreCLR tarafından uygulanmasına rağmen, .NET Native'de mevcut değildir ve bu özelliği oraya eklemeyi planlamıyoruz.

Onun yerine ne kullanmalıyım? AppDomains farklı amaçlar için kullanıldı. Kod izolasyonu için süreçleri ve / veya kapsayıcıları öneriyoruz. Derlemelerin dinamik yüklenmesi için, yeni AssemblyLoadContext sınıfını öneririz.

MSDN Blogundan Kaynak

Bir noktada, boşaltma montajlarının etki alanları kullanılmadan etkinleştirileceğini duydum. System.Runtime.Loader.AssemblyLoadContextSystem.Runtime.Loader.dll'deki türün bu işle ilgili olduğunu düşünüyorum , ancak henüz boşaltmayı sağlayan hiçbir şey görmüyorum.

Artık AppDomains'e ihtiyacınız yok, artık LoadContexts'e sahipsiniz:

public class CollectibleAssemblyLoadContext 
    : AssemblyLoadContext
{
    public CollectibleAssemblyLoadContext() : base(isCollectible: true)
    { }
 
    protected override Assembly Load(AssemblyName assemblyName)
    {
        return null;
    }
}

byte[] result = null; // Assembly Emit-result from roslyn
System.Runtime.Loader.AssemblyLoadContext context = new CollectibleAssemblyLoadContext();
System.IO.Stream ms = new System.IO.MemoryStream(result);
System.Reflection.Assembly assembly = context.LoadFromStream(ms);


System.Type programType = assembly.GetType("RsEval");
MyAbstractClass eval = (MyAbstractClass )System.Activator.CreateInstance(programType);
eval.LoadContext = context;
eval.Stream = ms;
// do something here with the dynamically created class "eval"

ve sonra söyleyebilirsin

eval.LoadContext.Unload();
eval.Stream.Dispose();

Bonus, eğer bunu soyut sınıfın IDisposable arayüzüne koyarsanız, o zaman isterseniz kullanabilirsiniz.

Not:
Bu, ortak bir derlemede sabit bir soyut sınıf olduğunu varsayar

public abstract class MyAbstractClass 
{

     public virtual void foo()
     {}
}

ve dinamik olarak çalışma zamanında oluşturulmuş bir sınıf (Roslyn kullanarak), ortak derlemedeki soyut sınıfa atıfta bulunarak, örneğin:

public class RsEval: MyAbstractClass 
{

     public override void foo()
     {}
}

Bir topluluk standup'ında veya Microsoft'tan bazı konuşmalarda, AppDomains'in yalıtım özelliğinin süreçler tarafından daha iyi ele alındığını (ve aslında diğer platformlardaki ortak model) ve boşaltmanın gerçekten de AppDomains ile ilgisi olmayan normal bir özellik olarak planlandığını duydum.