मेरे पास .NetStandard लाइब्रेरी है। मैं इसे .NetFramework और .NetCoreApp ऐप्लिकेशन में इस्तेमाल करने जा रहा हूं।

यह कॉन्फिग फाइलों के साथ काम करने के लिए System.Configuration.ConfigurationManager पैकेज का उपयोग करता है। मुझे अपनी लाइब्रेरी स्थापना के दौरान इन कॉन्फ़िगरेशन फ़ाइलों को बदलने की जरूरत है।

मुझे 2 तरीके मिले:

  1. tools नगेट पैकेज में install.ps1 फ़ाइल के साथ फ़ोल्डर
  2. content फोल्डर जिसमें app.config.install.xdt फाइल है

उनमें से कोई भी काम नहीं करता है - nuget नहीं चलता install.ps1, nuget नहीं बदलता App.config

Csproj से एक कोड है:

<ItemGroup>
  <Content Include="Content\app.config.install.xdt">
    <PackagePath>content</PackagePath>
  </Content>
</ItemGroup>

Nuget पैकेज में यह फ़ाइल है... इसलिए मुझे नहीं पता कि यह काम क्यों नहीं करती है।

क्या यह समस्या .NetStandard से संबंधित है? मैं क्या गलत कर रहा हूँ?

0
Boris Maslennikov 5 पद 2018, 16:33

1 उत्तर

सबसे बढ़िया उत्तर

Ps1 स्क्रिप्ट निष्पादित करना, और XDT ट्रांसफ़ॉर्म दोनों ही ऐसी विशेषताएं हैं जो केवल package.config, लेकिन PackageReference नहीं। .NET कोर (और मुझे लगता है कि .NET मानक) परियोजनाएं केवल एसडीके-शैली परियोजनाओं के साथ काम करती हैं, और एसडीके शैली परियोजनाएं केवल पैकेज संदर्भ का समर्थन करती हैं। Packages.config केवल "पुरानी शैली" परियोजनाओं के साथ काम करता है, जो PackageReference भी हो सकता है।

जिस तरह से Microsoft के ASP.NET कोर पुस्तकालय इस अंतर से निपटते हैं, वह यह है कि वे अब सीधे web.config से सेटिंग्स नहीं पढ़ते हैं। इसके बजाय प्रोग्राम को कॉलबैक फ़ंक्शंस पंजीकृत करना होगा जो मौजूदा इन-मेमोरी विकल्प ऑब्जेक्ट को संशोधित करेगा। उदाहरण के लिए

services.AddMyService(options =>
    {
        options.setting = newValue;
    });

यह आपके उपयोगकर्ताओं के लिए कुछ फायदे हैं।

  1. वे अब कॉन्फ़िगरेशन मान को उस स्थान पर संग्रहीत करने तक सीमित नहीं हैं जहां पुस्तकालय लेखक ने मांग की थी। वे डेटाबेस से कॉन्फ़िगरेशन लोड करना चुन सकते हैं, एक कॉन्फ़िगरेशन सेवा, एक xml फ़ाइल, एक json फ़ाइल, या बस इसे ऐप में हार्ड-कोड कर सकते हैं। लेकिन यह प्रत्येक डेवलपर को यह चुनने देता है कि उनके अपने सिस्टम के लिए सबसे अच्छा क्या है।
  2. यदि उपयोगकर्ता उस सेटिंग को ओवरराइड करता है जिसे पैकेज कॉन्फ़िगरेशन फ़ाइल में रखता है, और पैकेज का प्रत्येक अपडेट उपयोगकर्ता की वरीयता को ओवरराइड करता है, तो उपयोगकर्ता नाराज हो जाता है कि पैकेज डिफ़ॉल्ट को बदलने के लिए उनकी पसंद का सम्मान नहीं करता है।
  3. यदि उपयोगकर्ता किसी सेटिंग को ओवरराइड नहीं करना चाहता है जिसे पैकेज कॉन्फ़िगरेशन फ़ाइल में रखता है, और पैकेज लेखक प्रत्येक अपडेट को कॉन्फ़िगरेशन फ़ाइल को ओवरराइट नहीं करना चाहता है, तो पैकेज लेखक के लिए डिफ़ॉल्ट मान बदलना बहुत मुश्किल है।

ASP.NET Core का नया मॉडल सभी के लिए बेहतर है क्योंकि पैकेज लेखक विकल्प ऑब्जेक्ट बनाता है और इसे डिफ़ॉल्ट मानों के साथ प्री-पॉप्युलेट करता है और फिर उपयोगकर्ता की प्रतिनिधि विधि को कॉल करता है जिससे वे उन सेटिंग्स को बदल सकते हैं जिनकी वे परवाह करते हैं। यदि पैकेज लेखक एक डिफ़ॉल्ट मान बदलना चाहता है, तो वे अपने कोड में ऐसा करते हैं, एक नया पैकेज प्रकाशित करते हैं, और जो उपयोगकर्ता मान नहीं बदलते हैं उन्हें नया डिफ़ॉल्ट मिलता है, और जो उपयोगकर्ता अपने कोड में स्पष्ट रूप से मान सेट करते हैं, वे इसका उपयोग करते रहते हैं वे मूल्य जो वे चाहते हैं, जो भी कॉन्फ़िगरेशन स्टोर वे चाहते हैं।

तो, TL: DR उत्तर यह है कि आप वह नहीं कर सकते जो आपने PackageReference परियोजनाओं के साथ करने के लिए कहा था, लेकिन मुझे आशा है कि मेरे लंबे उत्तर ने आपको यह विचार दिया है कि आप अपनी लाइब्रेरी को कैसे फिर से डिज़ाइन कर सकते हैं जो पैकेज लेखक और पैकेज उपयोगकर्ता दोनों को बेहतर प्रदान करता है। अनुभव।

0
zivkan 7 पद 2018, 07:38