हालांकि आप एक प्रतिनिधि को कॉल कर सकते हैं जिसे एक अलग ऐपडोमेन द्वारा संभाला जाएगा, मैंने व्यक्तिगत रूप से हमेशा 'CreateInstanceAndUnwrap' विधि का उपयोग किया है जो विदेशी ऐप डोमेन में ऑब्जेक्ट बनाता है और इसके लिए प्रॉक्सी देता है।
इसके लिए काम करने के लिए आपके ऑब्जेक्ट को मार्शलबीरफॉब से उत्तराधिकारी होना है।
यहाँ एक उदाहरण है:
public interface IRuntime
{
bool Run(RuntimesetupInfo setupInfo);
}
// The runtime class derives from MarshalByRefObject, so that a proxy can be returned
// across an AppDomain boundary.
public class Runtime : MarshalByRefObject, IRuntime
{
public bool Run(RuntimeSetupInfo setupInfo)
{
// your code here
}
}
// Sample code follows here to create the appdomain, set startup params
// for the appdomain, create an object in it, and execute a method
try
{
// Construct and initialize settings for a second AppDomain.
AppDomainSetup domainSetup = new AppDomainSetup()
{
ApplicationBase = AppDomain.CurrentDomain.SetupInformation.ApplicationBase,
ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile,
ApplicationName = AppDomain.CurrentDomain.SetupInformation.ApplicationName,
LoaderOptimization = LoaderOptimization.MultiDomainHost
};
// Create the child AppDomain used for the service tool at runtime.
childDomain = AppDomain.CreateDomain(
"Your Child AppDomain", null, domainSetup);
// Create an instance of the runtime in the second AppDomain.
// A proxy to the object is returned.
IRuntime runtime = (IRuntime)childDomain.CreateInstanceAndUnwrap(
typeof(Runtime).Assembly.FullName, typeof(Runtime).FullName);
// start the runtime. call will marshal into the child runtime appdomain
return runtime.Run(setupInfo);
}
finally
{
// runtime has exited, finish off by unloading the runtime appdomain
if(childDomain != null) AppDomain.Unload(childDomain);
}
उपर्युक्त नमूने में, यह कुछ सेटअप जानकारी में एक 'चलाएं' विधि गुजर निष्पादित करने के लिए कोडित है, और भागो विधि के पूरा होने के सभी कोड है कि इंगित करने के लिए निर्धारित किया जाता है बच्चे में AppDomain चलाना पूरा हो गया है, इसलिए हमारे पास आखिरकार ब्लॉक है जो सुनिश्चित करता है कि ऐपडोमेन अनलोड हो गया है।
आप अक्सर सावधान रहना चाहते हैं कि आप किस प्रकार के असेंबली में रहते हैं - आप एक इंटरफेस का उपयोग करना चाहते हैं और इसे एक अलग असेंबली में रखना चाहते हैं जो कॉलर (हमारा कोड जो एपडोमेन सेट करता है, और कॉल करता है) यह) और कार्यान्वयनकर्ता (रनटाइम कक्षा) पर निर्भर हैं। यह आईआईआरसी अभिभावक ऐपडोमेन को केवल उस असेंबली को लोड करने की इजाजत देता है जिसमें इंटरफ़ेस होता है, जबकि बाल एपडोमेन रनटाइम और इसकी निर्भरता (आईरंटिम असेंबली) दोनों विधानसभाओं को लोड करेगा। किसी भी उपयोगकर्ता परिभाषित प्रकार जो आईरंटिम इंटरफ़ेस (उदाहरण के लिए हमारी रनटाइमसेटअपइन्फो क्लास) द्वारा उपयोग किए जाते हैं, उन्हें आमतौर पर आईरंटिम के समान असेंबली में भी रखा जाना चाहिए। साथ ही, सावधान रहें कि आप इन उपयोगकर्ता परिभाषित प्रकारों को कैसे परिभाषित करते हैं - यदि वे डेटा ट्रांसफर ऑब्जेक्ट्स हैं (जैसे कि रनटाइमसेटअप शायद है), तो आपको शायद उन्हें [serializable] विशेषता के साथ चिह्नित करना चाहिए - ताकि ऑब्जेक्ट की एक प्रति पास हो (से क्रमबद्ध बच्चे को पैरेंट एपडोमेन)। आप एक एपडोमेन से दूसरे में मार्शल किए जाने वाले कॉल से बचना चाहते हैं क्योंकि यह बहुत धीमी है। मूल्य (क्रमबद्धता) द्वारा डीटीओ पास करने का मतलब है कि डीटीओ पर मूल्यों तक पहुंचने से क्रॉस-अपार्टमेंट कॉल नहीं होता है (चूंकि बच्चे के एपडोमेन की मूल की अपनी प्रति है)। बेशक, इसका यह भी अर्थ है कि मूल परिवर्तन माता-पिता के मूल डीटीओ में प्रतिबिंबित नहीं होते हैं।
जैसा कि उदाहरण में कोड किया गया है, मूल एपडोमेन वास्तव में आईरंटिम और रनटाइम असेंबली दोनों को लोड करना समाप्त कर देगा, लेकिन ऐसा इसलिए है क्योंकि CreateInstanceAndUnwrap के कॉल में मैं असेंबली नाम और पूरी तरह से योग्य प्रकार प्राप्त करने के लिए टाइपऑफ (रनटाइम) का उपयोग कर रहा हूं नाम। आप इसके बजाय फ़ाइल से इन तारों को हार्डकोड या पुनर्प्राप्त कर सकते हैं - जो निर्भरता को कम कर देगा।
ऐपडोमेन पर 'डॉकबैक' नामक एक विधि भी है जो ऐसा लगता है कि यह एक विदेशी ऐपडोमेन में एक प्रतिनिधि को कॉल करने की अनुमति देता है। हालांकि, प्रतिनिधि प्रकार जो इसे लेता है वह है 'CrossAppDomainDelegate'। इसकी परिभाषा है:
public delegate void CrossAppDomainDelegate()
तो, यह आपको इसमें कोई भी डेटा पास करने की अनुमति नहीं देगा। और, चूंकि मैंने इसका कभी भी उपयोग नहीं किया है, इसलिए मैं आपको नहीं बता सकता कि क्या कोई विशेष गेटचा है।
इसके अलावा, मैं लोडर ऑप्टिमाइज़ेशन संपत्ति में देखने की अनुशंसा करता हूं। जो आपने इसे सेट किया है, उसके प्रदर्शन पर महत्वपूर्ण प्रभाव हो सकता है, क्योंकि इस संपत्ति की कुछ सेटिंग्स नए एपडोमेन को सभी असेंबली (और उन्हें जेआईटी इत्यादि) की अलग प्रतियां लोड करने के लिए मजबूर करती हैं, भले ही (आईआईआरसी) असेंबली जीएसी में है (यानी इसमें सीएलआर असेंबली शामिल है)। यदि आप अपने बच्चे के एपडोमेन से बड़ी संख्या में असेंबली का उपयोग करते हैं तो यह आपको भयानक प्रदर्शन दे सकता है। उदाहरण के लिए, मैंने बाल एपडोमेन से डब्ल्यूपीएफ का उपयोग किया है, जिससे मेरे ऐप के लिए भारी स्टार्टअप देरी हुई है जब तक कि मैं एक और उचित लोड पॉलिसी सेट नहीं करता।
CreateInstanceAndUnwrap विधि एक त्रुटि फेंक रही है जिसमें कहा गया है कि यह असेंबली नहीं ढूंढ सकता है (टाइपोफ (रनटाइम) .ssembly.FullName) । यह मेरे लिए एक वेब सर्वर पर चल रहा है और पूर्ण नाम का प्रारूप "myhostdll, संस्करण = 1.0.0.0, संस्कृति = तटस्थ, PublicKeyToken = null" है। – Triynko
@Triynko, नया ऐपडोमेन सेटअप बनाते समय, उसी डोमेन फ़ोल्डर को मास्टर डोमेन के रूप में निर्दिष्ट करने का प्रयास करें, या कम से कम, उस स्थान का उपयोग करें जहां नया डोमेन असेंबली प्राप्त कर सके। –