2017-03-17 6 views
10

मैं एक पुस्तकालय परियोजना पलायन नेट स्टैंडर्ड 1.1 समर्थन करने के लिए दृश्य स्टूडियो का उपयोग कर की प्रक्रिया में हूँ 2017वीएस 2017 में न्यूनतम निर्भरताओं के साथ .NET मानक NuGet पैकेज कैसे बनाएं?

मैं एक एकल NuGet पैकेज के रूप में परियोजना है कि दोनों .नेट फ्रेमवर्क 4.5+ लक्ष्य बना सकते हैं जारी करने के लिए उम्मीद कर रहा था और .NET कोर, यूडब्लूपी, आदि

हालांकि, जब मैं .NET Framework परियोजनाओं में परिणामी पैकेज को स्थापित करने का प्रयास करता हूं, तो पैकेज निर्भरताओं की एक बड़ी सूची उत्पन्न होती है जिसमें .NET मानक (नीचे देखें) में परिभाषित सभी संकुल शामिल होते हैं:

Package dependencies after installation on a .NET 4.5 project.

मैं समझता हूं कि ये सभी असेंबली हैं जो .NET मानक 1.1 विनिर्देश के हिस्से के रूप में परिभाषित हैं। हालांकि, मेरे विशिष्ट प्रोजेक्ट को वास्तव में उनमें से केवल एक छोटे से सबसेट की आवश्यकता होती है, और यह निर्भरता सूची उनकी परियोजनाओं में पैकेज स्थापित करने के लिए बेहद भ्रमित हो जाएगी।

मैंने similar question के उत्तर का पालन करने का प्रयास किया जहां परियोजना प्रोजेक्ट द्वारा आवश्यक सटीक निर्भरताओं को संदर्भित करने के लिए परियोजना विनिर्देश को बदलने की सिफारिश थी।

हालांकि, उत्तर पुराने प्रोजेक्ट.जेसन प्रारूप के संदर्भ में था, जिसे अब वीएस 2017 में नए .csproj प्रारूप द्वारा हटा दिया गया है। मैंने हटाकर .NET मानक 1.1 मेटापैकेज पर निर्भरता को हटाने की कोशिश की <TargetFramework> निर्देश लेकिन मैं केवल निर्माण को तोड़ने में कामयाब रहा और विशेष रूप से केवल निर्भरताओं को जोड़ने के लिए कोई रास्ता नहीं ढूंढ पाया।

अधिकतम प्लेटफार्म संगतता के लिए पुस्तकालयों को .NET मानक में ले जाने का वादा बेहद आकर्षक है, लेकिन "क्लासिक" .NET Framework को लक्षित करने वाली परियोजनाओं को निर्भर करने के लिए अनुशंसित तरीका क्या है, उनकी परियोजनाओं को "प्रदूषित" नहीं मिला इन सभी निर्भरताओं?

+0

आपको अपनी NuGet परिभाषा फ़ाइल में प्रत्येक प्लेटफॉर्म के लिए निर्भरताओं को परिभाषित करने की आवश्यकता है। ओएनटीएलआर 4 रनटाइम जैसे ओपन सोर्स प्रोजेक्ट पढ़ें। –

+0

@LexLi हां, मुझे इस समाधान के बारे में पता है, लेकिन .NET मानक का पूरा बिंदु यह था कि आप पीसीएल के दुःस्वप्न के बिना सभी प्लेटफार्मों में एक एकल डीएलएल वितरित कर सकते थे। – glopes

+0

आप इसे वास्तविक बनाने के लिए आवश्यक प्रयासों को स्पष्ट रूप से कम से कम समझते हैं। मेरा विचार यह है कि सभी प्लेटफार्मों के लिए .NET मूल अंततः इन सभी को हल करेगा, भले ही कितने डीएल हैं, लेकिन यह पर्याप्त तेज़ी से नहीं आएगा। –

उत्तर

7

<TargetFramework> से <TargetFrameworks> बदलें और इसमें ;net45 जोड़ें। आपको अभी भी एक एकल NuGet पैकेज आउटपुट मिलता है लेकिन अब यह केवल अतिरिक्त निर्भरताओं को खींच देगा यदि आप .NET कोर ऐप को लक्षित कर रहे हैं (जिसमें पहले से निर्भरताएं होंगी)।

1

यदि आप net45 के लिए उन पैकेज संदर्भों को देखते हैं तो आप पाएंगे कि लोड करने के लिए कोई वास्तविक DLL नहीं है। पैकेज वहां है ताकि कोरक्लर जैसे रनटाइम जो बीसीएल के सभी हिस्सों को डीएलएस के रूप में लोड करते हैं उन्हें प्राप्त कर सकते हैं। हालांकि नेट 45 में, आपको वास्तव में उन पैकेजों में कोई भी डीएल नहीं मिलेगा।

संक्षेप में, .NET 4.x, .net में अभी भी उन असेंबली को लोड करने के लिए जीएसी का उपयोग किया जाएगा।

3

पहले, मैं point out है कि यह ज्यादातर एक डिजाइन समय मुद्दा है और जिसके परिणामस्वरूप अनुप्रयोगों और अपने पुस्तकालयों के पोर्टेबिलिटी को प्रभावित नहीं करता चाहते हैं:

अतीत में, हम दे दिया है डेवलपर्स NuGet संकुल से मेटा पैकेज (NETStandard.Library) को संदर्भित करने की अनुशंसा नहीं करते हैं, बल्कि System.Runtime और System.Collections जैसे व्यक्तिगत पैकेजों का संदर्भ देते हैं। तर्क यह था कि हमने मेटा पैकेज को संकुल के समूह के लिए एक शॉर्टेंड के रूप में सोचा था जो .NET मंच के वास्तविक परमाणु भवन ब्लॉक थे। धारणा थी: हम एक और .NET मंच तैयार कर सकते हैं जो केवल इन परमाणु ब्लॉक का समर्थन करता है लेकिन उनमें से सभी नहीं। हमारे टूलिंग बड़े पैकेज ग्राफ के साथ कैसे काम करते हैं, इस बारे में भी चिंताएं थीं।

आगे चल कर, हम इस सरल बना रहे हैं:

  1. नेट स्टैंडर्ड एक परमाणु निर्माण खंड है। दूसरे शब्दों में, नए प्लेटफ़ॉर्म को .NET मानक को सब्सक्राइब करने की अनुमति नहीं है - उन्हें इसे लागू करना होगा।

  2. हम .NET मानक समेत हमारे प्लेटफॉर्म का वर्णन करने के लिए संकुल का उपयोग करने से दूर जा रहे हैं।

इसका मतलब है, आपको अब .NET मानक के लिए किसी भी NuGet पैकेज का संदर्भ नहीं देना पड़ेगा। आपने lib निर्भरता के साथ अपनी निर्भरता व्यक्त की है, यह बिल्कुल ठीक है कि यह अन्य सभी .NET प्लेटफार्मों के लिए कैसे काम करता है, विशेष रूप से .NET Framework।

हालांकि, अभी हमारी टूलिंग NETStandard.Library के संदर्भ में जल जाएगी। उसमें कोई हानि नहीं है, यह सिर्फ अनावश्यक आगे बढ़ेगा।

हालांकि, मैं पूरी तरह से स्वीकार करता हूं कि यह परिणाम शायद ही वांछनीय है।

.NET मानक 1.x और packages.config के साथ, दुर्भाग्य से आपके पास कस्टम निर्भरता समूहों के साथ हस्तलिखित .nuspec उत्पन्न करने के अलावा कोई विकल्प नहीं है। हालांकि, यह समझने की आवश्यकता है कि कौन से पैकेज आवश्यक हैं और नाजुक हो जाते हैं। यदि उपभोक्ता <PackageReference> का उपयोग करता है तो यह सिरदर्द से थोड़ा कम होता है क्योंकि यह प्रत्यक्ष-संक्रमणीय संदर्भों से अलग होता है, और इस प्रकार यह आपके चेहरे में इतना अधिक नहीं होता है।

.NET मानक 2.0 के साथ समस्या पूरी तरह से चली जाएगी।

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