मुझे 'असेंबली' क्यों मिल रही है * .dll 'को पूर्व शर्त के रूप में चिह्नित करने के लिए मजबूत हस्ताक्षर होना चाहिए?'

266

मैं सी # 4.0 का उपयोग करके अपने एक्सेल एडिन को संकलित करने की कोशिश कर रहा हूं, और विजुअल स्टूडियो में अपनी परियोजना का निर्माण करते समय इस समस्या को प्राप्त करना शुरू कर दिया। आपको यह बताना महत्वपूर्ण है कि मुझे पहले यह समस्या नहीं हुई थी। ऐसा होने का क्या कारण हो सकता है?

c#  visual-studio  .net-4.0 
— सर्गेई कुचर
स्रोत
72
एक त्वरित प्रयास के रूप में, अपनी परियोजना के दोनों binऔर objफ़ोल्डरों को हटा दें , और फिर से परियोजना का निर्माण करें। कभी-कभी यह काम करता है।
— जेसन इवांस
क्या आप विधानसभा पर हस्ताक्षर कर रहे हैं?
— फेलिस पोलानो
3
@ जेसन, इस परियोजना की सफाई और पुनर्निर्माण ने मेरे लिए काम किया। मैंने हाल ही में विधानसभाओं पर हस्ताक्षर किए थे और परियोजना का निर्माण होगा, लेकिन प्रकाशित नहीं होगा।
— क्रेट्ज
1
@ क्रेट्ज़ - खुशी है कि इस टिप ने आपके लिए काम किया :) यह आपके कंप्यूटर को रिबूट करके इसे ठीक करने जैसा है!
— जेसन इवांस
यह मेरे साथ तब हुआ जब कॉन्फ़िगरेशन मैनेजर ने मेरी कई परियोजनाओं पर निर्माण सेटिंग्स को रीसेट कर दिया (यानी वे "रीबिल्ड ऑल" पर निर्माण करने के लिए सेट नहीं थे), उन प्रोजेक्ट्स को फिर से बनाने और त्रुटि के पुनर्निर्माण के बाद।
— एलन नोव

जवाबों:

239

मेरा अनुमान है कि आप दृढ़ता से नामित विधानसभाओं के साथ काम नहीं कर रहे हैं। जब दो प्रोजेक्ट्स एक ही असेंबली के थोड़े अलग संस्करण और एक अधिक आश्रित प्रोजेक्ट रेफरेंस इन प्रोजेक्ट्स को रेफर करते हैं, तो मुझे यह त्रुटि आई है। मेरे मामले में रिज़ॉल्यूशन असेंबली के नाम और संस्करण की जानकारी को .csproj फ़ाइलों (यह वैसे भी कोई फर्क नहीं पड़ता) को हटाने के लिए था, और फिर एक क्लीन बिल्ड करें।

अलग-अलग असेंबली संस्करणों के बीच परिवर्तन उन्हें संदर्भित करने वाले समाधान के कुछ हिस्सों के साथ संगत थे। यदि आपके साथ ऐसा नहीं है, तो आपको समस्या को हल करने के लिए कुछ और काम करने पड़ सकते हैं।

NuGet

NuGet के साथ इस स्थिति में आना आसान है अगर:

  1. आप अपने समाधान में एक परियोजना के लिए एक पैकेज स्थापित करते हैं।
  2. उस पैकेज का एक नया संस्करण पैकेज स्रोत पर तैनात किया गया है।
  3. आप इसे उसी समाधान में किसी अन्य प्रोजेक्ट पर स्थापित करते हैं।

इससे आपके समाधान में दो परियोजनाओं का परिणाम उस पैकेज की असेंबली के विभिन्न संस्करणों को संदर्भित करता है। यदि उनमें से एक दूसरे को संदर्भित करता है और एक क्लिकऑन ऐप है, तो आप इस समस्या को देखेंगे।

इसे ठीक करने के लिए, update-package [package name]Nuget Package Manager कंसोल पर कमांड को एक स्तर के खेल मैदान तक लाने के लिए, जिस पर समस्या दूर हो, उसे जारी करें।

जब तक कि कोई सम्मोहक कारण न हो, आपको प्रोजेक्ट स्तर के बजाय समाधान स्तर पर NuGet संकुल का प्रबंधन करना चाहिए। समाधान स्तर पैकेज प्रबंधन निर्भरता के कई संस्करणों की क्षमता से बचा जाता है। यूआई प्रबंधन का उपयोग करते समय, यदि समेकित टैब दिखाता है कि 1 या अधिक पैकेज में कई संस्करण हैं, तो उन्हें एक पर समेकित करने पर विचार करें।

— किट
स्रोत
7
यहाँ कुछ और जानकारी दी गई है: social.msdn.microsoft.com/Forums/en/csharplanguage/thread/… । इसके अलावा, बिन और obj को साफ़ करना और (यदि आपके नियंत्रण में) असेंबली संस्करण को एक ही मान पर सेट करना (जैसे बिल्ड नंबर शून्य छोड़ना) मदद करता है।
— किट
3
मैंने आज अपने स्वयं के अनुभव को प्रतिबिंबित करने के लिए NuGet और इस समान त्रुटि के साथ अपने जवाब के अंत में थोड़ा सा समझौता किया है। आशा है कि यह किसी को कुछ समय में मदद करता है (संभवतः कुछ महीनों में खुद को भी!)।
— नील बर्नवेल
2
यह त्रुटि मेरे लिए पॉपिंग रहती है और .csproj फ़ाइल से असेंबली का नाम हटाती है, फिर सफाई ने लगातार मेरे लिए इसे निर्धारित किया है। धन्यवाद!
— स्कूबा सेतेव
1
आप इस उत्तर को देखना चाह सकते हैं यदि उपरोक्त उत्तर काम नहीं करता है और आपको लगता है कि आपने Intellisense / ReSharper का उपयोग करके अपनी किसी एक परियोजना में NuGet संदर्भ जोड़ा है।
— डेविड मर्डोक
समाधान में 4 परियोजनाएं हैं। एक प्रोजेक्ट बी क्लास लाइब्रेरी है। बाकी तीनों में B के dll को संदर्भित किया जा रहा था। अन्य दो परियोजना ( C और D ) निष्पादन योग्य ए में संदर्भित किए जा रहे हैं । इसलिए मैंने ए का निर्माण किया और बहुत ही समस्या आई। ठीक पहले दो परियोजनाओं के बाकी के पुनर्निर्माण के लिए किया गया था। और फिर एक निश्चित मुद्दे पर परियोजना के पुनर्निर्माण ।
— विक्रम सिंह सैनी
268

जब मुझे यह समस्या हुई तो मैंने 'ClickOnce सुरक्षा सेटिंग्स सक्षम करें' को बंद करके इसे ठीक कर दिया।

मेनू: प्रोजेक्ट | 'प्रोजेक्ट नाम' गुण ... | सुरक्षा टैब | 'ClickOnce सुरक्षा सेटिंग्स सक्षम करें' चेक बॉक्स।

— CharleZ
स्रोत
2
VS2012 में मेरे लिए काम नहीं किया (चेकबॉक्स प्रकाशित के दौरान स्वचालित रूप से पुन: जांच की जाती है)। मैंने इस उत्तर का उपयोग किया, क्योंकि DLL को केवल बिल्ड प्रक्रिया के लिए आवश्यक था। stackoverflow.com/a/8123074/17713
— 10th पर Matthias Meid
3
क्लिकऑन का उपयोग करते समय, यह चेक बॉक्स स्वचालित रूप से हर बार चयनित होता है जब एप्लिकेशन प्रकाशित विज़ार्ड के साथ प्रकाशित होता है। अधिक जानकारी के लिए msdn.microsoft.com/en-us/library/1sfbfyk0.aspx देखें ।
— डेविड मर्डोक
8
मेरे पास एमएसवीएस 2015 है और मैं प्रोजेक्ट संपत्तियों के तहत सुरक्षा टैब नहीं देखता
— जेटा
70

इस जवाब को देखें ।

प्रकाशित पृष्ठ पर जाएं और "एप्लिकेशन फ़ाइलें" पर क्लिक करें। वहां से आपको अपने DLL की सूची देखनी चाहिए। सुनिश्चित करें कि जो आपको परेशान कर रहे हैं, उनकी प्रकाशन स्थिति को "पूर्वापेक्षा" के बजाय "शामिल करें" के रूप में चिह्नित किया गया है।

— Otiel
स्रोत
2
एक्सल एडिन प्रोजेक्ट में एप्लिकेशन फाइल बटन नहीं है। stackoverflow.com/questions/6378801/…
— सेर्गेई कुचेर
@SergeyKucher: मुझे नहीं पता था कि। अद्यतन के लिए धन्यवाद। जैसा कि आपका प्रश्न एक्सेल एडिन के लिए सटीक नहीं है, मुझे लगता है कि मेरा जवाब अभी भी यहाँ मान्य है (मैं एक winforms परियोजना पर एक ही त्रुटि संदेश था और इसे इस तरह हल किया था)।
— ओटियल
मेरे पास एक winforms प्रोजेक्ट है जो तब तक ठीक रहता है जब तक कि मैं प्रकाशित विज़ार्ड का उपयोग नहीं करता जिसके बाद मुझे ओपी की त्रुटियां मिलीं। प्रकाशन स्थिति बदलने से समस्या ठीक हो गई। साभार
— क्रिस्टियन
7
मेरे मामले में, इस मुद्दे को INCLUDE (ऑटो) से प्रकाशित स्थिति को केवल INCLUDE में बदलकर हल किया गया था। वैसे भी, आपके उत्तर ने दिखाए गए मूल्यों पर जोर नहीं देने में मदद की। बहुत बहुत धन्यवाद
— जूलियो नोब्रे
22

मुझे यह समस्या हुई है। यह इसलिए हुआ क्योंकि मेरे पास एक ही विधानसभा की ओर इशारा करने वाले कई प्रोजेक्ट थे लेकिन विभिन्न संस्करणों से। मैं इसे अपने समाधान में सभी परियोजनाओं के लिए एक ही संस्करण का चयन करके हल करता हूं।

— डैनियल
स्रोत
13

यदि आपने अपना असेंबली संस्करण बदल दिया है या त्रुटि में बताए गए प्रबंधित लाइब्रेरी के किसी भिन्न संस्करण की प्रतिलिपि बनाई है, तो हो सकता है कि आपके पास पहले से गलत फ़ाइल को संदर्भित करने वाली फाइलें संकलित हों। एक '' सभी का पुनर्निर्माण करें '' (या 'पूर्व की टिप्पणी में बताए गए' फ़ोल्डर और 'obj' फ़ोल्डर को हटाते हुए) इस मामले को ठीक करना चाहिए।

— Sogger
स्रोत
1
या सिर्फ 'क्लीन सॉल्यूशन'
— बिना लाइसेंस के
A 'Rebuild All' पहले एक साफ-सुथरा प्रदर्शन करता है, और 'स्वच्छ' और फिर 'बिल्ड' के बराबर है। हालाँकि, यह नोट करना अच्छा है कि कभी-कभी जब फ़ाइलों को अलग-अलग टाइमस्टैम्प के साथ मैन्युअल रूप से कॉपी या कॉपी किया जाता है, तो 'क्लीन' / 'पुनर्निर्माण' कार्यक्षमता समस्या का समाधान नहीं करती है और मैन्युअल रूप से 'बिन' और 'obj' फ़ोल्डरों को हटाना आवश्यक है।
— Sogger
एक्सेल से संबंधित इस समस्या के लिए, मेरे लिए काम किए गए बिन / obj फ़ोल्डर्स को हटाना, अन्य दृष्टिकोण नहीं थे।
— विलियम मेलानी
6

आपको एक कुंजी के साथ विधानसभा पर हस्ताक्षर करने की आवश्यकता है। टैब साइनिंग के तहत प्रोजेक्ट प्रॉपर्टीज में जाएं: यहां छवि विवरण दर्ज करें

— फेलिस पोलानो
स्रोत
6

किसी के लिए भी इस समस्या के लिए मेरे समाधान को जोड़ना मदद कर सकता है।

मेरे पास इस त्रुटि को फेंकने वाला ClickOnce समाधान था। एप्लिकेशन ने एक सामान्य "Libs" फ़ोल्डर को संदर्भित किया और इसमें एक प्रोजेक्ट का संदर्भ दिया Foo.dll। जबकि समाधान में मौजूद किसी भी परियोजना Foo.dllने "Libs" फ़ोल्डर में स्थिर प्रतिलिपि का संदर्भ नहीं दिया, उस फ़ोल्डर के कुछ संदर्भों ने किया (यानी: मेरे समाधान ने Libs\Bar.dllजिस संदर्भ को संदर्भित किया था Foo.dll।) चूंकि CO ऐप ने सभी निर्भरताएं खींच ली थीं ।Libs साथ ही उनकी निर्भरता, दोनों प्रतियाँ परियोजना में जा रही थीं। यह ऊपर त्रुटि उत्पन्न कर रहा था।

मैंने अपने Libs\Foo.dllस्थैतिक संस्करण को सबफ़ोल्डर में स्थानांतरित करके समस्या को ठीक किया Libs\Fix\Foo.dll,। इस परिवर्तन ने क्लिकऑन ऐप को केवल DLL के प्रोजेक्ट संस्करण का उपयोग किया और त्रुटि गायब हो गई।

— निक गोच
स्रोत
6

यदि आपने इस प्रश्न के अन्य सभी उत्तर दिए हैं और आप:

  • आपके समाधान में कई परियोजनाएँ हैं
  • एक प्रोजेक्ट (प्रोजेक्ट ए) है जो किसी अन्य प्रोजेक्ट (प्रोजेक्ट बी) का संदर्भ देता है, जिसका प्रोजेक्ट एक न्यूगेट पैकेज का संदर्भ देता है।
  • प्रोजेक्ट A में, आपने प्रोजेक्ट B में संदर्भित NuGet पैकेज के संदर्भ में लाने के लिए Intellisense / ReSharper का उपयोग किया (यह तब हो सकता है जब Project B में कोई विधि NuGet पैकेज द्वारा प्रदान किया गया प्रकार लौटाता है और प्रोजेक्ट A में उपयोग की जाने वाली विधि)
  • NuGet पैकेज प्रबंधक (या CLI) के माध्यम से NuGet पैकेज को अपडेट किया गया।

... आपके पास अपनी परियोजनाओं के संदर्भों में NuGet संकुल DLL के अलग-अलग संस्करण हो सकते हैं, क्योंकि Intellisense / ReSharper द्वारा बनाया गया संदर्भ एक "सामान्य" संदर्भ होगा, और उम्मीद के मुताबिक NuGet संदर्भ नहीं होगा, इसलिए Nuetet अद्यतन प्रक्रिया जीती ' t इसे खोजें या अपडेट करें!

इसे ठीक करने के लिए, प्रोजेक्ट ए में संदर्भ को हटा दें, फिर इसे स्थापित करने के लिए नुगेट का उपयोग करें, और सुनिश्चित करें कि सभी परियोजनाओं में नुगेट पैकेज एक ही संस्करण हैं। ( इस उत्तर में व्याख्या करें )

जीवन प्रो टिप:

जब भी ReSharper / Intellisense अपनी परियोजना के लिए एक संदर्भ जोड़ने का सुझाव देता है तो यह मुद्दा सामने आ सकता है। यह ऊपर दिए गए उदाहरण की तुलना में बहुत अधिक गहराई से समझा जा सकता है, जिसमें कई इंटरव्यूइंग प्रोजेक्ट्स और निर्भरताएं होती हैं, जिससे इसे ट्रैक करना मुश्किल होता है। यदि ReSharper / Intellisense द्वारा सुझाया जा रहा संदर्भ वास्तव में एक NuGet पैकेज से है, तो इसे स्थापित करने के लिए NuGet का उपयोग करें।

— डेविड मर्डोक
स्रोत
हाँ, संदर्भ जोड़ने के लिए Resharper का उपयोग करने से बचें। Resharper डिबग से संदर्भ dll लेगा (या यदि आप रिलीज़ मोड में हैं) फ़ोल्डर। यह बहुत सारे मुद्दों का कारण होगा, विशेष रूप से विशाल परियोजनाओं में।
— cepriego
5

जब मैंने इसे अपडेट करने के बाद WindowsAPICodePack के साथ मेरे साथ हुआ, तो मैंने समाधान को फिर से बनाया।

बिल्ड -> समाधान का पुनर्निर्माण

— नाथन
स्रोत
4

मेरे समाधान के माध्यम से और व्यक्तिगत रूप से अद्यतन करने के लिए बहुत सी परियोजनाएं थीं इसलिए मैंने इसे ठीक किया:

  • मेरे समाधान पर राइट-क्लिक करें और 'समाधान के लिए NuGet पैकेज प्रबंधित करें ...' का चयन करें
  • अपडेट टैब पर जा रहे हैं
  • प्रभावित पैकेज ढूंढना और अपडेट का चयन करना
  • ओके पर क्लिक किया और इससे पैकेज के सभी उदाहरण आज तक सामने आए
— RagtimeWilly
स्रोत
4

समस्या परियोजना को उतारना और फिर से लोड करना मेरे लिए हल हो गया।

— ChrisO
स्रोत
4

मैं प्रकाशित करने के लिए गया था , आवेदन फ़ाइलें, पाया गया कि त्रुटि को फेंकने ने इसे 'शामिल (ऑटो) से' शामिल 'में बदल दिया । मैं अब प्रकाशित कर सकता हूं।

— सर्व-कुंची
स्रोत
4

मैं एक समस्या को एक्सेल एडिन को package.config से PackageReference में स्थानांतरित करने के बाद इस समस्या का सामना किया। इस मुद्दे से संबंधित लगता है ।

यदि आप ClickOnce का उपयोग नहीं कर रहे हैं, तो यह क्रूड वर्कअरेन्स के रूप में निम्न कार्य करता है (यह .manifestफ़ाइल से सभी निर्भरता जानकारी को छोड़ देगा ):

  1. प्रोजेक्ट को अनलोड करें, संपादित करें .csproj

  2. इस तरह दिखने वाले अनुभाग को खोजें:

    <!-- Include additional build rules for an Office application add-in. -->
<Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />

  3. संदर्भित .targetsफ़ाइल की एक नामांकित प्रतिलिपि को संपादित करें (मेरे मामले में, फ़ाइल को हल किया गया था C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targetsऔर मैंने Microsoft.VisualStudio.Tools.Office_FIX.targetsउसी फ़ोल्डर में एक प्रतिलिपि बनाई थी - यह जांचें कि क्या यह एक अलग फ़ोल्डर से काम करता है)।

  4. GenerateApplicationManifestतत्व का पता लगाएं और इसकी विशेषता Dependencies="@(DependenciesForGam)"को बदल दें Dependencies=""।

  5. 2 में मिली अनुभाग को बदलें। अपनी संपादित .targetsफ़ाइल को संदर्भित करने के लिए।

जब भी .targetsVS के साथ शिप की गई फाइल को अपडेट किया जाता है (या आपको अपडेट्स नहीं मिलेंगे) के संस्करण को दोहराया जाना होगा, लेकिन मुझे उम्मीद है कि यह जल्द ही ठीक हो जाएगा ...

— FunctorSalad
स्रोत
2
इसे जोड़ने के लिए, समस्या को ठीक करने का एक हल्का सा तरीका यह है कि पूरे <लक्ष्य नाम = "VisualStudioForApplicationsBuild"> बिंदु 3 में स्थित फ़ाइल से अनुभाग कॉपी किया जाए (यानी: बस फ़ाइल ढूंढें, इसे कॉपी और नाम बदलें नहीं) अपने स्वयं के प्रोजेक्ट के लिए। ** proj फ़ाइल, और बिंदु 4 में वर्णित के रूप में एक ही परिवर्तन करें। यह आपके प्रोजेक्ट के लिए व्यवहार को ओवरराइड करेगा, और फिर आपकी मशीन पर कुछ और प्रभावित नहीं करेगा। यदि भविष्य के वीएस अपडेट में मूल फ़ाइल में परिवर्तन होते हैं, तो आपको अभी भी प्रक्रिया को दोहराने की आवश्यकता हो सकती है।
— एडम
3

क्या आपकी विधानसभा ठीक से हस्ताक्षरित है?

इसे जांचने के लिए, Alt + Enter को अपनी परियोजना (या राइट क्लिक, फिर गुण) पर दबाएँ। "साइनिंग" पर जाएं। सत्यापित करें कि चेक बॉक्स "साइन असेंबली" चेक किया गया है और मजबूत नाम कुंजी फ़ाइल का चयन किया गया है और "केवल डिलीट साइन" अनियंत्रित है ।

— आर्सेनी मूरज़ेंको
स्रोत
मैंने * .dll पर हस्ताक्षर किए हैं, लेकिन इससे पहले कोई समस्या नहीं थी (मैं पहले संकलन त्रुटि नहीं है)। प्रकाशित प्रकाशित परियोजनाओं में से एक में संदर्भित dll, मुझे सीधे प्रकाशित परियोजना से dll को संदर्भित करने के लिए बदसूरत समाधान मिला, क्या आप कृपया मुझे बता सकते हैं कि यह अब क्यों काम करता है? या मैं कैसे समस्याओं को हल कर सकता हूँ? धन्यवाद
— सेर्गेई Kucher
1
@ user520535: ठीक है, यदि आपने पहले पुस्तकालय पर हस्ताक्षर नहीं किए हैं, तो आपको करना चाहिए। इस लाइब्रेरी के लिए हस्ताक्षरित असेंबलियों (एक हस्ताक्षरित असेंबली को एक हस्ताक्षरित नहीं कह सकते हैं) द्वारा उपयोग किए जाने का एकमात्र तरीका नहीं है, लेकिन जब आप प्लग-इन / ऐड के साथ सौदा करते हैं, तो हस्ताक्षरित असेंबली के साथ काम करना भी बहुत मुश्किल नहीं है। -INS। अब, क्यों यह अब समस्याओं का कारण बनने लगा और पहले नहीं? मुझे पता नहीं है।
— आर्सेनी मूरज़ेंको
@ user520535: यदि यह मदद करता है, तो आप उत्तर को स्वीकार करने या उभारने के लिए स्वतंत्र हैं।
— आर्सेनी मूरज़ेंको
3

अब यहाँ समस्या के लिए एक अलग तरीका है:

  • प्रोजेक्ट पर राइट क्लिक करें और 'अनलोड प्रोजेक्ट' विकल्प चुनें। आप देखेंगे कि परियोजना अनुपलब्ध है।

  • अनुपलब्ध परियोजना पर राइट क्लिक करें और 'संपादन' विकल्प चुनें।

  • सभी संसाधन टैग वाले '<ItemGroup>' टैग तक नीचे स्क्रॉल करें।

  • अब त्रुटि सूची पर प्रदर्शित संदर्भ पर जाएं, आप इसे एक टैग (यानी < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >) का उपयोग करते हुए देखेंगे ।

  • निम्नानुसार देखने के लिए उसे बदलें:

।

<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
    < Private > True < / Private >
    < HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >
  • अपने परिवर्तन सहेजें, अनुपलब्ध प्रोजेक्ट पर फिर से राइट क्लिक करें और 'पुनः लोड करें प्रोजेक्ट' विकल्प पर क्लिक करें, फिर निर्माण करें।
— टेक
स्रोत
3

जब आप संदर्भित .dll का संस्करण बदलते हैं, तो यह तब होता है। आपको सभी आइटमों को हटाने की आवश्यकता है, या लक्ष्य निर्माण फ़ोल्डर में .dll।

— होआंग हा
स्रोत
2

मुझे समान संकलक त्रुटि मिली। एक बार जब मैं समाधान के लिए dll फ़ाइल की आश्रित परियोजना को जोड़ता हूं, तो समस्या हल हो गई है।

— Minny
स्रोत
2

यदि आपकी मुख्य परियोजना कुछ पुस्तकालय परियोजनाओं का उपयोग कर रही है और उनके संदर्भ हैं, तो आप इस समस्या का कारण बन सकते हैं यदि आपकी परियोजना आपके पुस्तकालय प्रोजेक्ट में कुछ बदलने के दौरान लाइब्रेरी प्रोजेक्ट के बजाय असेंबली dll फ़ाइल का संदर्भ देती है (उदा: एक वर्ग का नाम बदलें)।

आप ऑब्जेक्ट ब्राउज़र विंडो (मेनू देखें-> ऑब्जेक्ट ब्राउज़र) में दृश्य द्वारा अपने मुख्य प्रोजेक्ट के सभी संदर्भों की जांच कर सकते हैं। एक dll फ़ाइल के संदर्भ में हमेशा एक संस्करण संख्या होती है। Ex: TestLib [1.0.0.0]

समाधान: अपने मुख्य प्रोजेक्ट के वर्तमान संदर्भ को लाइब्रेरी प्रोजेक्ट में हटाएं और उस लाइब्रेरी प्रोजेक्ट के लिए फिर से संदर्भ जोड़ें।

— हुई गुयेन
स्रोत
1

यहां अधिकांश समाधानों की कोशिश करने के बाद, मैंने आखिरकार प्रोजेक्ट से एक बार क्लिक से प्रोजेक्ट के लिए एक संदर्भ जोड़ दिया, इससे इसे शामिल करने से ऑटो (ऑटो) में बदल गया और अंत में यह काम कर गया।

— PatFromCanada
स्रोत
1

मुझे पैकेज मैनेजर सॉल्यूशन पर जाने में क्या मदद मिली और स्थापित पैकेज को देखा जो समस्या पैदा कर रहा था। मैंने देखा कि कई परियोजनाएं एक ही पैकेज लेकिन विभिन्न संस्करणों को संदर्भित कर रही थीं। मैंने उन्हें अपनी आवश्यकताओं के आधार पर संरेखित किया और यह काम किया।

— Artexias
स्रोत
0

मैं एक समाधान w / 6 परियोजनाओं में यह था। मेरी एक परियोजना एक फ़ाइल संदर्भ के रूप में नामित विधानसभा का उल्लेख कर रही थी। अन्य सभी परियोजना के संदर्भ की ओर इशारा कर रहे थे।

मुझे आमतौर पर इन मामलों में एक अलग त्रुटि मिलती है।

मेरा समाधान यह था कि नामित विधानसभा को हटा दिया जाए और इसे वापस जोड़ दिया जाए। एक बार जब मैंने इस परियोजना के माध्यम से काम किया, तो ths समस्या गायब हो गई। ऐसा करने से पहले, मैंने समाधान को साफ करने की कोशिश की और यह भी सुनिश्चित किया कि कोई भी परियोजना पर हस्ताक्षर नहीं किए गए थे।

आशा है कि यह किसी की मदद करता है ...

— ग्रेग
स्रोत
0

यदि इसकी निर्भरता निर्भरता का एक बेमेल है, तो समाधान स्तर पर NuGet पैकेज प्रबंधक पर जाएं और अपडेट और समेकित टैब की जांच करें, यह सब सामंजस्य स्थापित करें।

— ल्यूक पुप्लेट
स्रोत
0

मैंने हाल ही में इस समस्या को मारा। मेरे मामले में, मेरे पास विभिन्न विधानसभाओं पर NuGet पैकेज हैं। मेरे पास एक ही NuGet पैकेज के विभिन्न संस्करण थे जो मेरी अपनी विधानसभाओं से जुड़े थे।
मेरा समाधान समाधान पर NuGet पैकेज मैनेजर का उपयोग करना था, व्यक्तिगत परियोजनाओं के विपरीत। यह एक "समेकन" विकल्प को सक्षम करता है, जहां आप अपने NuGet संकुल को कई परियोजनाओं में अपग्रेड कर सकते हैं, जैसा कि आप चाहते हैं - इसलिए वे सभी विधानसभा के एक ही संस्करण को संदर्भित करते हैं। जब मैंने समेकन किया, तो निर्माण विफलता गायब हो गई।

— साइमन मिलर
स्रोत
0

मैं भी इस तरह की समस्या से टकरा रहा हूं, मुझे सिर्फ इतना करना था कि .dll (संदर्भ में पाया जा सकता है) जो त्रुटि का कारण बनता है और इसे फिर से जोड़ देता है ।

एक जादू की तरह काम करता है।

— FritsJ
स्रोत
0

बस प्रकाशित करने के लिए जाओ -> आवेदन फ़ाइल -> और शामिल करने के लिए शर्त से प्रभावित dll प्रकाशित स्थिति बदल! यह मेरे लिए काम किया!

— SWIK
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.