নেট কোরটিতে কোনও অ্যাপডোমেন নেই! কেন?

Question 1

মাইক্রোসফ্ট .NET কোর এ অ্যাপডোমেনগুলি সমর্থন না করার কেন কোনও দৃ reason় কারণ আছে?

অ্যাপডোমাইনগুলি দীর্ঘকাল ধরে চলমান সার্ভার অ্যাপ্লিকেশনগুলি তৈরি করার সময় দরকারী, যেখানে আমরা সার্ভারটি বন্ধ না করেই সার্ভার দ্বারা লোড করা অ্যাসেম্বলিকে আপডেট করতে পারি want

অ্যাপডোমাইনগুলি ছাড়া, আমরা কীভাবে দীর্ঘ চলমান সার্ভার প্রক্রিয়াতে আমাদের সমাবেশগুলি প্রতিস্থাপন করব?

অ্যাপডোমাইনস আমাদের সার্ভার কোডের বিভিন্ন অংশ বিচ্ছিন্ন করার একটি উপায়ও সরবরাহ করে। যেমন, একটি কাস্টম ওয়েবসকেট সার্ভারের প্রাথমিক অ্যাপডোমেনে সকেট কোড থাকতে পারে, যখন আমাদের পরিষেবাগুলি মাধ্যমিক অ্যাপডোমনে চালিত হয়।

অ্যাপডোমাইনগুলি ছাড়া উপরের দৃশ্যটি সম্ভব নয়।

আমি একটি যুক্তি দেখতে পাচ্ছি যা সমাবেশের পরিবর্তনগুলি পরিচালনা করতে এবং অ্যাপডোমাইনসের ওভারহেড ব্যয় না করার জন্য ক্লাউডের ভিএমএস ধারণাটি ব্যবহার করার বিষয়ে কথা বলতে পারে। তবে মাইক্রোসফ্ট কি এটাই মনে করে বা বলে? বা তাদের উপরের পরিস্থিতিগুলির জন্য একটি নির্দিষ্ট কারণ এবং বিকল্প রয়েছে?

Question 2

.NETCore উপসেট বিন্দু একটি .NET ইনস্টল রাখা ছিল ছোট । এবং পোর্ট করা সহজ। যে কারণে আপনি বলতে পারেন যে, উইন্ডোজ এবং ওএসএক্স উভয়তেই সিলভারলাইট অ্যাপ্লিকেশন চালানো যায় এবং আপনি যখন ওয়েব পৃষ্ঠাতে যান তখন খুব বেশিক্ষণ অপেক্ষা করবেন না। সম্পূর্ণ রানটাইম এবং ফ্রেমওয়ার্ক ডাউনলোড এবং ইনস্টল করতে কয়েক সেকেন্ড সময় লাগে, নিতে বা নেয়।

এটিকে ছোট রাখার জন্য অনিবার্যভাবে বৈশিষ্ট্যগুলি কাটা দরকার। রিমোটিংটি সেই তালিকায় খুব বেশি ছিল, এটি বেশ ব্যয়বহুল। অন্যথায় ভাল লুকানো, তবে আপনি উদাহরণস্বরূপ দেখতে পারেন যে প্রতিনিধিদের আর কার্যকরী বিগিনভোক () পদ্ধতি নেই। যা অ্যাপডোমাইনকেও কাটা তালিকায় ফেলেছে, আপনি কোনও অ্যাপ ডোমেনে কোডটি রিমোটিং সমর্থন ছাড়াই চালাতে পারবেন না। সুতরাং এটি সম্পূর্ণ নকশা দ্বারা by

Question 3

.NET স্ট্যান্ডার্ড 2 এবং। নেট কোর 2 এর জন্য আপডেট

.NET স্ট্যান্ডার্ড 2 AppDomainবর্গ হয় সেখানে। তবে, সেই API এর অনেকগুলি অংশ PlatformNotSupportedException.NET কোরের জন্য নিক্ষেপ করবে ।

প্রধান কারণ এটি এখনও একটি Unhandled ব্যতিক্রম হ্যান্ডলার যা নিবন্ধনের মত মৌলিক সামগ্রী সেখানে হয় হবে কাজ ।

.NET স্ট্যান্ডার্ড FAQ এর এই ব্যাখ্যা রয়েছে :

অ্যাপডোমাইন কি নেট নেট স্ট্যান্ডারের অংশ?

অ্যাপডোমাইন টাইপটি .NET স্ট্যান্ডার্ডের অংশ। সমস্ত প্ল্যাটফর্মগুলি নতুন অ্যাপ্লিকেশন ডোমেনগুলি তৈরি করতে সমর্থন করবে না, উদাহরণস্বরূপ, .NET কোর এটি করবে না, সুতরাং .NET স্ট্যান্ডার্ডে থাকা অবস্থায় AppDomain.CreateDomain পদ্ধতিটি প্ল্যাটফর্ম নটসপোর্টড এক্সসেপশন নিক্ষেপ করতে পারে।

.NET স্ট্যান্ডার্ডে আমরা এই ধরণের উদ্ভাসের প্রাথমিক কারণ হ'ল ব্যবহারটি মোটামুটি বেশি এবং সাধারণত নতুন অ্যাপ্লিকেশন ডোমেন তৈরির সাথে জড়িত নয় তবে বর্তমান অ্যাপ্লিকেশন ডোমেনের সাথে যোগাযোগের জন্য যেমন একটি অবিবাহিত ব্যতিক্রম হ্যান্ডলার নিবন্ধন করা বা অ্যাপ্লিকেশনের বেস ডিরেক্টরি জিজ্ঞাসা করা ।

এগুলি ছাড়াও শীর্ষস্থানীয় উত্তর এবং অন্যান্য উত্তরগুলি খুব সহজেই ব্যাখ্যা করে যে কেন অ্যাপডোমাইনের বাল্ক এখনও কাটা হয়েছিল (যেমন একটি সমর্থিত ব্যতিক্রম নিক্ষেপ করে)।

Question 4

অ্যাপ ডোমেনগুলি

কেন এটি বন্ধ ছিল?অ্যাপডোমাইনগুলি রানটাইম সমর্থন প্রয়োজন এবং সাধারণত বেশ ব্যয়বহুল। যদিও এখনও কোরসিএলআর দ্বারা প্রয়োগ করা হয়েছে, এটি নেট নেট নেভিগেশন উপলব্ধ নয় এবং আমরা এই ক্ষমতা সেখানে যোগ করার পরিকল্পনা করি না।

পরিবর্তে আমার কী ব্যবহার করা উচিত?অ্যাপডোমাইনগুলি বিভিন্ন উদ্দেশ্যে ব্যবহৃত হত। কোড বিচ্ছিন্নতার জন্য, আমরা প্রক্রিয়া এবং / অথবা পাত্রে প্রস্তাব দিই। অ্যাসেম্বলিগুলির গতিশীল লোডিংয়ের জন্য আমরা নতুন এসেম্বলিওডকন্টেক্সট ক্লাসের প্রস্তাব দিই।

এমএসডিএন ব্লগ থেকে উত্স

Question 5

এক পর্যায়ে, আমি শুনেছি যে ডোমেনগুলি ব্যবহার না করে আনলোডিং অ্যাসেমব্লিগুলি সক্ষম করা হবে। আমি মনে করি যে System.Runtime.Loader.AssemblyLoadContextSystem.Runtime.Loader.dll টাইপটি এই কাজের সাথে সম্পর্কিত, তবে আমি সেখানে কিছুই দেখি না যা আনলোডিং সক্ষম করে।

Question 6

আপনার আর অ্যাপডোমেন দরকার নেই, আপনার এখন লোডকন্টেক্সট রয়েছে:

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();

বোনাস যদি আপনি এটি বিমূর্ত শ্রেণির আইডিজিপোজেবল ইন্টারফেসে রাখেন তবে আপনি চাইলে কেবল ব্যবহার করে ব্যবহার করতে পারেন।

দ্রষ্টব্য:
এটি একটি সাধারণ সমাবেশে একটি স্থির বিমূর্ত শ্রেণি গ্রহণ করে

public abstract class MyAbstractClass 
{

     public virtual void foo()
     {}
}

এবং একটি গতিশীল রানটাইম-জেনারেটেড ক্লাস (রোজলিন ব্যবহার করে), সাধারণ সমাবেশে বিমূর্ত শ্রেণিকে উল্লেখ করে, যা প্রয়োগ করে যেমন:

public class RsEval: MyAbstractClass 
{

     public override void foo()
     {}
}

Question 7

আমি একটি সম্প্রদায়ের স্ট্যান্ডআপ বা মাইক্রোসফ্টের কিছু আলোচনায় শুনেছি যে অ্যাপডোমাইনগুলির বিচ্ছিন্নতা বৈশিষ্ট্যগুলি প্রক্রিয়াগুলি (এবং আসলে অন্য প্ল্যাটফর্মগুলির মধ্যে সাধারণ প্যাটার্ন) দ্বারা আরও ভালভাবে পরিচালিত হয় এবং আনডোলিংটি অ্যাপডোমাইনের সাথে সম্পর্কিত না হওয়া একটি সাধারণ বৈশিষ্ট্য হিসাবে সত্যই পরিকল্পনা করা হয়েছিল।