2016-02-21 11 views
9

जैसा कि मैं वर्तमान में पूर्ण .NET Framework में समझता हूं जब हम मशीन पर ढांचे को स्थापित करते हैं तो यह पूरे बीसीएल को कंप्यूटर के जीएसी पर तैनात करता है। इस तरह जब हम .NET के साथ एक सॉफ्टवेयर विकसित करते हैं और उस कंप्यूटर पर तैनात करते हैं तो यह बीसीएल असेंबली का उपयोग करेगा जो जीएसी में उपलब्ध कराए जाते हैं जब .NET Framework स्वयं स्थापित किया गया था।क्या .NET कोर के लिए कोई GAC समतुल्य है?

अब, जैसा कि मुझे पता है कोरफैक्स नए .NET कोर के लिए बीसीएल के बराबर है। हालांकि, मुख्य अंतर यह है कि हम project.json में निर्दिष्ट कर सकते हैं कि कोरफैक्स के हमें कौन से टुकड़े चाहिए।

मेरा प्रश्न है: जब हम .NET कोर ऐप्स को तैनात करते हैं, तो उत्पादन वातावरण पर कोई जीएसी समतुल्य है? इसलिए, जब हम एप को निष्पादित करने के लिए तैनात करते हैं, तो क्या कंप्यूटर में कोई केंद्रीय स्थान है जहां ऐप देखना होगा कि पूरा कोरफ़ैक्स उपलब्ध है या नहीं?

+0

AOT संकलन (आगे-के-टाइम) परिनियोजन योग्य निष्पादनयोग्य बनाने के लिए प्रमुख रास्ता है, कोई ढांचा सभी आवश्यक होने की संभावना है। ठंड शुरू होने पर मारने के लिए बहुत जरूरी नहीं है। वे कोररेट परियोजना पर काम कर रहे हैं। जब आप उन्हें एक साल से पूछते हैं तो इस तरह के प्रश्न बहुत उपयोगी होते हैं। –

+0

मैंने देखा कि कोरोट यह एओटी संकलन करने के लिए ज़िम्मेदार होगा जो अंत में केवल एक मूल निष्पादन योग्य होगा। लेकिन कोरसीएलआर भी है जो जेआईटी संकलन के साथ काम करता है? उस स्थिति में यदि कोई इसका उपयोग करता है, तो क्या जीएसी की तरह कुछ है जहां कोरएफएक्स की असेंबली की खोज की जाएगी? – user1620696

उत्तर

3

कोई भी नहीं है, जिस तरह से आप जीएसी के बारे में सोचते हैं। कोर ऐप्स एक-दूसरे से अलग होने के लिए हैं, इसलिए आप दूसरों को प्रभावित करने के डर के बिना एक को पैच कर सकते हैं। आप ऐप के साथ आवश्यक सभी पैकेज भेजते हैं।

एक सर्विसिंग निर्देशिका है जिसका उपयोग कोर घटकों के लिए अपडेट भेजने के लिए किया जा सकता है, लेकिन इसे पूरी तरह से स्वैप करना है, साइड वर्जनिंग के साथ-साथ सक्षम नहीं है, और यह केवल माइक्रोसॉफ्ट अपडेट के माध्यम से भेजे गए अपडेट के लिए है।

+0

धन्यवाद @blowdart। मुझे पता था कि .NET कोर के लिए हम ऐप के साथ आवश्यक सभी पैकेज भेज सकते हैं, लेकिन मैंने सोचा कि यह सिर्फ एक विकल्प था। तो जब .NET कोर ऐप्स विकसित करते हैं तो हम हमेशा * ऐप के साथ पैकेज को शिप करने की आवश्यकता रखते हैं? – user1620696

+0

स्थानीय कैश की अवधारणा है, या कम से कम डीएनएक्स के साथ था, लेकिन जब आप स्थानीय रूप से शिप करते हैं तो आप इसे ओवरराइड करते हैं। यह "गायब" पैकेज के लिए और अधिक है। – blowdart

9

संपादित 2017-09-01

GAC के लिए कुछ हद तक समान है, नेट कोर 2.0 का परिचय "Runtime package store":

नेट कोर 2.0 के साथ शुरू, यह पैकेज संभव है और लक्षित वातावरण में मौजूद पैकेजों के ज्ञात सेट के खिलाफ ऐप्स को तैनात करें। फायदे तेजी से तैनाती, कम डिस्क स्थान उपयोग, और कुछ मामलों में बेहतर स्टार्टअप प्रदर्शन हैं।

यह सुविधा रनटाइम पैकेज स्टोर के रूप में कार्यान्वित की गई है, जो डिस्क पर एक निर्देशिका है जहां संकुल संग्रहीत किए जाते हैं (आमतौर पर मैकोज़/लिनक्स और सी:/प्रोग्राम फ़ाइलें/डॉटनेट पर/usr/local/share/dotnet/store पर/विंडोज़ पर स्टोर)।


आप एक "फ्रेमवर्क पर निर्भर तैनाती" के लिए देख रहे हैं। the docs से:

आप नेट कोर अनुप्रयोगों के लिए तैनाती के दो प्रकार बना सकते हैं:

  • फ्रेमवर्क पर निर्भर तैनाती। जैसा कि नाम का तात्पर्य है, फ्रेमवर्क-निर्भर परिनियोजन (एफडीडी) लक्ष्य प्रणाली पर उपस्थित होने के लिए .NET कोर के साझा सिस्टम-व्यापी संस्करण पर निर्भर करता है। चूंकि .NET कोर पहले से मौजूद है, इसलिए आपका ऐप .NET कोर की स्थापनाओं के बीच पोर्टेबल भी है। आपके ऐप में केवल अपना कोड और कोई तृतीय-पक्ष निर्भरता है जो .NET कोर पुस्तकालयों के बाहर हैं। एफडीडी में .dll फ़ाइलें होती हैं जिन्हें कमांड लाइन से डॉटनेट उपयोगिता का उपयोग करके लॉन्च किया जा सकता है। उदाहरण के लिए, dotnet app.dllapp नामक एक एप्लिकेशन चलाता है।

  • स्व-निहित तैनाती। एफडीडी के विपरीत, एक स्व-निहित तैनाती (एससीडी) किसी भी साझा घटक पर लक्षित प्रणाली पर मौजूद नहीं है। .NET कोर पुस्तकालयों और .NET कोर रनटाइम दोनों समेत सभी घटक, एप्लिकेशन के साथ शामिल हैं और अन्य .NET कोर अनुप्रयोगों से अलग हैं।एससीडी में app नामक एप्लिकेशन के लिए विंडोज प्लेटफॉर्म पर app.exe) निष्पादन योग्य (जैसे प्लेटफ़ॉर्म-विशिष्ट .NET कोर होस्ट का एक नामित संस्करण है, और एक .dll फ़ाइल (जैसे app.dll), जो वास्तविक एप्लिकेशन है।

संबंधित मुद्दे