आपने कुछ भी गलत नहीं किया है, ऐसा होने की उम्मीद है। यदि आप अपने स्वयं के डीएलएल को किसी नए .NET Framework प्रोजेक्ट में जोड़े जाने से ज्यादा कुछ नहीं चाहते हैं, तो आपको अपनी लाइब्रेरी के लिए .NET Framework संस्करण के लिए .NET मानक 2.0 को लक्षित करना होगा जो एपीआई और असेंबली संस्करणों का मूल रूप से समर्थन करता है - जो जा रहा है 4.7.2 होने के लिए (जबकि .NET Framework 4.7.1 सभी एपीआई का समर्थन करता है, वहां कुछ असेंबली के संस्करण के साथ बग थे और इसलिए टूलिंग (वीएस 2017 15.5+) इसे ठीक करने के लिए अतिरिक्त असेंबली जोड़ देगा)।
जो आप देख रहे हैं वह साइड इफेक्ट्स हैं कि .NET मानक कैसे बनाया गया है और समर्थित ढांचे के लिए समर्थन लागू किया गया है। यह आपके द्वारा लक्षित .NET मानक संस्करण और लाइब्रेरी पैकेज को संदर्भित करने के लिए उपयोग की जाने वाली टूलिंग के आधार पर भी अलग है।
.NET मानक < 2.0 में, आप NETStandard.Library मेटा-पैकेज का संदर्भ देते हैं जो बदले में अतिरिक्त संदर्भ (System.*) संकुल संदर्भित करता है। उन संकुलों में संदर्भ असेंबली होती है जो ".NET मानक अनुबंध" बनाती हैं - एपीआई का एक सेट और असेंबली नाम + संस्करण।
जब आप .NET मानक 1.0-1.6 के लिए बनाए गए NuGet पैकेज को किसी अनुप्रयोग द्वारा संदर्भित किया जाता है, तो ये व्यक्तिगत पैकेज संदर्भ असेंबली नहीं लाते हैं बल्कि आवेदन लक्ष्य को ढांचे के लिए कार्यान्वयन असेंबली नहीं लाते हैं।
.NET कोर के लिए, ये उन असेंबली से मेल खाते हैं जो पहले से ही रनटाइम का हिस्सा हैं, इसलिए डीएलएल फाइलें निर्मित एप्लिकेशन के बगल में समाप्त नहीं होंगी। हालांकि यह बदल गया जब .NET कोर 1.1 (NETStandard.Library संस्करण 1.6.1) के लिए संकुल का एक नया सेट जारी किया गया था। इसके परिणामस्वरूप .NET कोर 1.0 के लिए बनाए गए अनुप्रयोगों को नए कार्यान्वयन असेंबली प्राप्त करने का अंत हो गया जो कि .NET कोर 1.1 में शामिल होने के लिए थे। (सौभाग्य से, 1.1 को तब "दीर्घकालिक समर्थन" संस्करण बनाया गया था, जिसके बाद इस सम्मेलन के बारे में चर्चा हुई थी एलटीएस वादे का हिस्सा हैं)।
इन पुस्तकालयों में .NET Framework पर (System.Net.Http जैसे कुछ अपवादों के साथ) बहुत कुछ नहीं करते - वे बस सिस्टम असेंबली के लिए आगे बढ़ते हैं। तो उदाहरण के लिए "अनुबंध" परिभाषित करता है कि System.Object को System.Runtime.dll असेंबली में परिभाषित किया गया है। तो System.Runtime.dll फ़ाइल जिसे आप .NET Framework अनुप्रयोग में समाप्त करते हैं, में System.Runtime.dll शामिल है जिसमें .NET Framework के mscorlib.dll पर आगे का प्रकार शामिल है। .NET कोर में पहले से ही एक अलग System.Runtime.dll है जो उस प्लेटफॉर्म के लिए कुछ अलग करता है। यह तंत्र दोनों प्लेटफॉर्म पर काम करने के लिए एक एकल डीएलएल फ़ाइल के लिए अनुमति देता है क्योंकि उन प्रकार के आगे और अतिरिक्त कार्यान्वयन दोनों कार्यान्वयन पर काम कर रहे "अनुबंध" (प्रकार + असेंबली + असेंबली संस्करण) को आश्वस्त करते हैं।
.NET मानक 2.0 का उद्देश्य संकुल और डीएलएल की आवश्यकता को कम करने और NETStandard.Library को अपडेट करने के लिए आवश्यक होने पर भी एक नया .NET कोर संस्करण जारी किया गया है।
तो .NET मानक 2.0 और .NET कोर 2.0 के लिए, NETStandard.Library पैकेज केवल एक परियोजना को कोड संकलित करने के लिए संदर्भ असेंबली लाता है, लेकिन परिणामी NuGet पैकेज अब इस पैकेज पर निर्भर नहीं करता है। तो जब आप .NET मानक 2.0 को लक्षित करते हुए लाइब्रेरी बनाते हैं और इसे प्रकाशित करते हैं, तो इसमें कोई NuGet निर्भरता नहीं होगी (जब तक आप अतिरिक्त जोड़ नहीं देते)।
.NET मानक लाइब्रेरी का उपभोग करने के दौरान "समर्थन पुस्तकालयों" को लाने के लिए तर्क के निर्माण के दौरान उपयोग की जाने वाली टूलिंग में स्थानांतरित किया गया था। इसलिए जब एक लाइब्रेरी जिसमें netstandard.dll का संदर्भ शामिल है, तो .NET Framework प्रोजेक्ट में जोड़ा जाता है, तो टूलिंग तब उपयोग किए जा रहे .NET Framework के संस्करण के आधार पर आवश्यक समर्थन DLL जोड़ देगा। यह .NET मानक 2.0 के साथ-साथ .NET मानक 1.5+ के लिए किया गया था क्योंकि .NET Framework 4.6.1 को इस प्रकार की DLL फ़ाइलों के माध्यम से .NET मानक 2.0 (पहले 1.4 था) के साथ संगत रूप से संगत किया गया था। वही टूलींग यह भी सुनिश्चित करती है कि अगर किसी भी एप्लिकेशन प्रोजेक्ट में NuGet पैकेज लाए जाते हैं, तो भी NuGet के माध्यम से लाए गए किसी भी .NET मानक कार्यान्वयन पुस्तकालय को बिल्ड से हटा दिया जाता है। इसलिए यदि आप एक .NET मानक 1.0 NuGet पैकेज का संदर्भ देते हैं जो .NET कोर 1.0 जारी किए जाने पर बनाया गया था, तो इसकी सभी NuGet निर्भरताओं को छंटनी की जाती है और आपको इसके बजाय निर्माण टूलिंग के साथ समर्थित लाइब्रेरी मिलती है।
विचार था कि .नेट फ्रेमवर्क 4.7.1 सभी आवश्यक विधानसभाओं "इनबॉक्स" होते हैं तो एक netstandard.dll, System.Runtime.dll आदि .नेट फ्रेमवर्क का हिस्सा है और किसी भी नेट स्टैंडर्ड 1.0-2.0 DLL फ़ाइल हैं कि होगा "बस काम ", समस्या यह थी कि इन" इनबॉक्स "डीएलएल फाइलों में कुछ असेंबली के लिए बहुत कम संस्करण संख्या थी, इसलिए पुस्तकालय लोड होने में असफल हो जाएंगे - यह टूलिंग को फिर से बदलकर तय किया गया था ताकि डीएलएल फाइलों को उच्च संस्करण संख्याओं के साथ समर्थन पुस्तकालयों के रूप में शामिल किया जा सके। "इनबॉक्स" .NET फ्रेमवर्क असेंबली पर आगे बढ़ें। यह .NET Framework 4.7.2 में तय करने की योजना है।
क्या आपने देखा है कि वास्तव में आउटपुट फ़ोल्डर में कुछ भी जोड़ा गया है, या पैकेज स्थापित करते समय यह केवल निर्भरताओं की एक डरावनी सूची है या नहीं? मेरा अनुभव यह है कि यह उत्तरार्द्ध है, जो अभी भी महान नहीं है, लेकिन चिंताजनक नहीं है। –
@ जोनस्केट मेरे पैकेज फ़ोल्डर में अब फ़ोल्डरों की एक लंबी सूची है, जब मैं वास्तव में केवल एक की उम्मीद कर रहा था। अतिरिक्त रूप से, "NuGet संकुल प्रबंधित करें" स्क्रीन सभी संकुल दिखाती है (जिनमें से कुछ में लंबित अपडेट हैं)। –
सही - लेकिन बिन निर्देशिका में क्या है? (एफडब्ल्यूआईडब्ल्यू, मैं पूरी तरह से सहमत हूं कि यह एक बहुत ही दुर्भाग्यपूर्ण स्थिति है।मुझे नहीं पता कि बाद में रिलीज के लिए इसे बेहतर किया गया है या नहीं। लेकिन यही कारण है कि मैं कुछ पैकेजों के उत्पादन के लिए, मैं नेट 45 लक्ष्य के साथ-साथ netstandard1.x संस्करण भी बना सकता हूं ...) –