มีเหตุผลที่ชัดเจนว่าทำไม Microsoft จึงเลือกที่จะไม่สนับสนุน AppDomains ใน. NET Core?

AppDomains มีประโยชน์อย่างยิ่งเมื่อสร้างแอปเซิร์ฟเวอร์ที่ใช้งานมานานซึ่งเราอาจต้องการอัปเดตแอสเซมบลีที่เซิร์ฟเวอร์โหลดเป็นวิธีที่ดีโดยไม่ต้องปิดเซิร์ฟเวอร์

หากไม่มี AppDomains เราจะเปลี่ยนแอสเซมบลีของเราในกระบวนการเซิร์ฟเวอร์ที่ใช้งานยาวนานได้อย่างไร

AppDomains ยังให้เราแยกส่วนต่างๆของรหัสเซิร์ฟเวอร์ เช่นเดียวกับเซิร์ฟเวอร์ websocket ที่กำหนดเองสามารถมีรหัสซ็อกเก็ตใน appdomain หลักในขณะที่บริการของเราทำงานใน appdomain รอง

หากไม่มี AppDomains สถานการณ์ข้างต้นจะเป็นไปไม่ได้

ฉันเห็นข้อโต้แย้งที่อาจพูดถึงการใช้แนวคิด VMs ของ Cloud สำหรับจัดการการเปลี่ยนแปลงแอสเซมบลีและไม่ต้องเสียค่าใช้จ่ายของ AppDomains แต่นี่คือสิ่งที่ Microsoft คิดหรือพูด? หรือมีเหตุผลและทางเลือกเฉพาะสำหรับสถานการณ์ข้างต้น?

จุดย่อย .NETCore คือการเก็บ .NET ติดตั้งขนาดเล็ก และง่ายต่อการพอร์ต นั่นคือเหตุผลที่คุณสามารถพูดเรียกใช้แอป Silverlight ทั้งบน Windows และ OSX และไม่ต้องรอนานมากเมื่อคุณเยี่ยมชมหน้าเว็บ การดาวน์โหลดและติดตั้งรันไทม์และเฟรมเวิร์กที่สมบูรณ์ใช้เวลาไม่กี่วินาทีให้หรือใช้เวลา

การทำให้เล็กต้องตัดคุณสมบัติอย่างหลีกเลี่ยงไม่ได้ ระยะไกลสูงมากในรายการนั้นค่อนข้างแพง มิฉะนั้นจะถูกซ่อนไว้อย่างดี แต่ตัวอย่างเช่นคุณจะเห็นว่าผู้รับมอบสิทธิ์ไม่มีเมธอด BeginInvoke () ที่ใช้งานได้อีกต่อไป ซึ่งทำให้ AppDomain อยู่ในรายการที่ถูกตัดเช่นกันคุณไม่สามารถเรียกใช้รหัสในโดเมนของแอปโดยไม่ได้รับการสนับสนุนจากระยะไกล นี่คือการออกแบบทั้งหมด

อัพเดตสำหรับ. NET Standard 2 และ. NET Core 2

ใน. NET Standard 2 มีAppDomainคลาสอยู่ในนั้น อย่างไรก็ตามหลาย ๆ ส่วนของ API นั้นจะใช้PlatformNotSupportedExceptionสำหรับ. NET Core

เหตุผลหลักที่ยังคงมีอยู่สำหรับสิ่งพื้นฐานเช่นการลงทะเบียนตัวจัดการข้อยกเว้นที่ไม่สามารถจัดการได้ซึ่งจะใช้งานได้

คำถามที่พบบ่อย. NET Standard มีคำอธิบายนี้ :

AppDomain เป็นส่วนหนึ่งของ. NET Standard หรือไม่

ประเภท AppDomain เป็นส่วนหนึ่งของ. NET Standard ไม่ใช่ทุกแพลตฟอร์มที่จะรองรับการสร้างโดเมนแอปใหม่เช่น. NET Core จะไม่ดังนั้นวิธีการ AppDomain.CreateDomain ในขณะที่มีอยู่ใน. NET Standard อาจทำให้ PlatformNotSupportedException

เหตุผลหลักที่เราเปิดเผยประเภทนี้ใน. NET Standard เนื่องจากการใช้งานค่อนข้างสูงและโดยปกติแล้วจะไม่เกี่ยวข้องกับการสร้างโดเมนแอปใหม่ แต่สำหรับการโต้ตอบกับโดเมนแอปปัจจุบันเช่นการลงทะเบียนตัวจัดการข้อยกเว้นที่ไม่ได้จัดการหรือขอไดเรกทอรีฐานของแอปพลิเคชัน .

นอกเหนือจากนั้นคำตอบยอดนิยมและคำตอบอื่น ๆ ยังอธิบายได้เป็นอย่างดีว่าเหตุใด AppDomain จำนวนมากจึงยังคงถูกตัดออก (เช่นโยนข้อยกเว้นที่ไม่รองรับ)

App Domains

ทำไมถึงถูกยกเลิก? AppDomains ต้องการการสนับสนุนรันไทม์และโดยทั่วไปมีราคาค่อนข้างแพง แม้ว่าจะยังคงใช้งานโดย CoreCLR แต่ก็ไม่สามารถใช้ได้ใน. NET Native และเราไม่ได้วางแผนที่จะเพิ่มความสามารถนี้ที่นั่น

ฉันควรใช้อะไรแทน? AppDomains ถูกใช้เพื่อวัตถุประสงค์ที่แตกต่างกัน สำหรับการแยกรหัสเราขอแนะนำกระบวนการและ / หรือคอนเทนเนอร์ สำหรับการโหลดแอสเซมบลีแบบไดนามิกเราขอแนะนำคลาส AssemblyLoadContext ใหม่

ที่มาจาก MSDN Blog

จนถึงจุดหนึ่งฉันได้ยินมาว่าการยกเลิกการโหลดแอสเซมบลีจะเปิดใช้งานโดยไม่ต้องใช้โดเมน ฉันคิดว่าSystem.Runtime.Loader.AssemblyLoadContextประเภทใน System.Runtime.Loader.dll เกี่ยวข้องกับงานนี้ แต่ฉันไม่เห็นสิ่งใดที่ทำให้สามารถยกเลิกการโหลดได้

คุณไม่ต้องการ AppDomains อีกต่อไปตอนนี้คุณมี LoadContexts:

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"

แล้วคุณสามารถพูด

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

โบนัสหากคุณใส่สิ่งนั้นลงในอินเทอร์เฟซ IDisposable ของคลาสนามธรรมคุณสามารถใช้โดยใช้ถ้าคุณต้องการ

หมายเหตุ:
ถือว่าคลาสนามธรรมคงที่ในแอสเซมบลีทั่วไป

public abstract class MyAbstractClass 
{

     public virtual void foo()
     {}
}

และคลาสที่สร้างรันไทม์แบบไดนามิก (โดยใช้ Roslyn) โดยอ้างถึงคลาสนามธรรมในแอสเซมบลีทั่วไปซึ่งดำเนินการเช่น:

public class RsEval: MyAbstractClass 
{

     public override void foo()
     {}
}

ฉันเคยได้ยินในชุมชน standup หรือบางคนพูดถึง Microsoft ว่าคุณลักษณะการแยกของ AppDomains ได้รับการจัดการที่ดีกว่าโดยกระบวนการ (และเป็นรูปแบบทั่วไปในแพลตฟอร์มอื่น ๆ ) และการยกเลิกการโหลดนั้นมีการวางแผนไว้เป็นคุณลักษณะปกติที่ไม่เกี่ยวข้องกับ AppDomains