.net - चेतावनी: एक ही निर्भर असेंबली के विभिन्न संस्करणों के बीच संघर्ष मिला




warnings (10)

मैं वर्तमान में एक .NET अनुप्रयोग विकसित कर रहा हूं, जिसमें 20 परियोजनाएं शामिल हैं। इनमें से कुछ परियोजनाओं को .NET 3.5 का उपयोग करके संकलित किया गया है, कुछ अन्य अभी भी .NET 2.0 प्रोजेक्ट्स हैं (अभी तक कोई समस्या नहीं है)।

समस्या यह है कि यदि मैं बाहरी घटक शामिल करता हूं तो मुझे हमेशा निम्न चेतावनी मिलती है:

"Found conflicts between different versions of the same dependent assembly".

इस चेतावनी का वास्तव में क्या अर्थ है और क्या इस चेतावनी को बाहर करने की संभावना हो सकती है (जैसे #pragma स्रोत-कोड फ़ाइलों में अक्षम) का उपयोग करना?


  1. "समाधान एक्सप्लोरर" खोलें।
  2. "सभी फाइलें दिखाएं" पर क्लिक करें
  3. विस्तृत करें "संदर्भ"
  4. आप एक (या अधिक) संदर्भ (एस) को बाकी की तुलना में थोड़ा अलग आइकन के साथ देखेंगे। आम तौर पर, यह पीले रंग के बक्से के साथ है जो आपको इसका नोट लेने का सुझाव देता है। बस इसे हटा दें।
  5. संदर्भ वापस जोड़ें और अपना कोड संकलित करें।
  6. बस इतना ही।

मेरे मामले में, MySQL संदर्भ के साथ एक समस्या थी। किसी भी तरह, मैं सभी उपलब्ध संदर्भों की सूची के तहत इसके तीन संस्करणों को सूचीबद्ध कर सकता हूं; .NET 2.0, .NET 4.0 और .NET 4.5 के लिए। मैंने ऊपर 1 से 6 प्रक्रिया का पालन किया और यह मेरे लिए काम किया।


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


असल में ऐसा तब होता है जब आप जिन असेंबली का संदर्भ ले रहे हैं, उनमें "कॉपी स्थानीय" सेट को "ट्रू" पर सेट किया गया है, जिसका अर्थ है कि डीएलएल की एक प्रति आपके एक्सई के साथ बिन फ़ोल्डर में रखी गई है।

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

जिस तरह से मैंने इसे प्राप्त किया है, वह असेंबली परियोजनाओं में संदर्भों के लिए स्थानीय को कॉपी करने के लिए गलत सेट करना है। केवल निष्पादन योग्य / वेब अनुप्रयोगों के लिए ऐसा करें जहां आपको तैयार उत्पाद के लिए असेंबली की आवश्यकता है।

उम्मीद है कि समझ में आता है!


इस चेतावनी का अर्थ है कि दो परियोजनाएं एक ही असेंबली (उदाहरण के System.Windows.Forms ) का संदर्भ देती हैं लेकिन दोनों परियोजनाओं के लिए विभिन्न संस्करणों की आवश्यकता होती है। आपके पास कुछ विकल्प हैं:

  1. सभी परियोजनाओं को एक ही संस्करणों का उपयोग करने के लिए पुन: संकलित करें (उदाहरण के लिए सभी को 3.5 पर ले जाएं)। यह पसंदीदा विकल्प है क्योंकि सभी कोड उन निर्भरताओं के संस्करणों के साथ चल रहे हैं जिनके साथ संकलित किए गए थे।

  2. बाध्यकारी रीडायरेक्ट जोड़ें। यह चेतावनी दबाने जाएगा। हालांकि, आपकी .NET 2.0 प्रोजेक्ट्स (रनटाइम पर) System.Windows.FormsSystem.Windows.Forms जैसे निर्भर असेंबली के .NET 3.5 संस्करणों के लिए बाध्य होंगी। आप विजुअल स्टूडियो में त्रुटि पर डबल-क्लिक करके तुरंत बाध्यकारी रीडायरेक्ट जोड़ सकते हैं।

  3. CopyLocal=true प्रयोग करें। मुझे यकीन नहीं है कि यह चेतावनी को दबाएगा। यह उपरोक्त विकल्प 2 की तरह होगा, इसका मतलब है कि सभी परियोजनाएं System.Windows.Forms के .NET 3.5 संस्करण का उपयोग करेंगी।

आपत्तिजनक संदर्भों की पहचान करने के कुछ तरीके यहां दिए गए हैं:

  • आप https://gist.github.com/1553265 पर पाए गए उपयोगिता का उपयोग कर सकते हैं
  • बिल्ड आउटपुट वर्बोजिटी (टूल्स, ऑप्शन, प्रोजेक्ट्स एंड सॉल्यूशंस, बिल्ड एंड रन, एमएसबिल्ड प्रोजेक्ट बिल्ड आउटपुट वर्बोजिटी, विस्तृत) सेट करने के बाद और चेतावनी के लिए आउटपुट विंडो को ढूंढने के लिए एक और आसान तरीका है, और इसके ऊपर टेक्स्ट को देखें । (हैट टिप टू pauloya जिन्होंने इस उत्तर पर टिप्पणियों में इसका सुझाव दिया)

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

आखिरकार यह पता चला कि समस्या एक परियोजना में मेरे संदर्भों में से एक की घोंसला निर्भरता थी। इस संदर्भ (ए) बदले में (बी) का एक अलग संस्करण आवश्यक था जिसे मेरे समाधान में अन्य सभी परियोजनाओं से सीधे संदर्भित किया गया था। संदर्भित परियोजना में संदर्भ को अद्यतन करने से इसे हल किया गया।

Solution A
+--Project A
   +--Reference A (version 1.1.0.0)
   +--Reference B
+--Project B
   +--Reference A (version 1.1.0.0)
   +--Reference B
   +--Reference C
+--Project C
   +--Reference X (this indirectly references Reference A, but with e.g. version 1.1.1.0)

Solution B
+--Project A
   +--Reference A (version 1.1.1.0)

मुझे आशा है कि उपर्युक्त दिखाता है कि मेरा क्या मतलब है, मुझे पता लगाने के लिए कुछ घंटे लग गए, इसलिए उम्मीद है कि किसी और को भी फायदा होगा।


मेरे पास अभी यह चेतावनी संदेश था और समाधान को साफ किया गया था और फिर से तैयार किया गया था (बिल्ड -> स्वच्छ समाधान) और यह चला गया।


मैं उपरोक्त टिप्पणियों में प्रदान किए गए पाउलोया के समाधान को पोस्ट करना चाहता था। मेरा मानना ​​है कि आपत्तिजनक संदर्भों को ढूंढने का सबसे अच्छा समाधान है।

"अपमानजनक संदर्भ" क्या है, यह जानने का सबसे आसान तरीका बिल्ड आउटपुट वर्बोजिटी (टूल्स, ऑप्शन, प्रोजेक्ट्स एंड सॉल्यूशंस, बिल्ड एंड रन, एमएसबिल्ड प्रोजेक्ट बिल्ड आउटपुट वर्बोजिटी, विस्तृत) सेट करना है और बिल्डिंग के बाद, आउटपुट विंडो खोजें चेतावनी के लिए। बस इसके ऊपर पाठ देखें।

उदाहरण के लिए, जब आप "संघर्ष" के लिए आउटपुट पैनल खोजते हैं तो आपको ऐसा कुछ मिल सकता है:

3>  There was a conflict between "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
3>      "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was not.

जैसा कि आप देख सकते हैं, ईएफ संस्करण 5 और 6 के बीच एक संघर्ष है।


यदि आप अपनी निर्भरताओं को प्रबंधित करने के लिए Nuget का उपयोग कर रहे हैं तो मेरे पास ऐसा करने का दूसरा तरीका है। मैंने पाया है कि कभी-कभी वीएस और नुजेट मेल नहीं खाते हैं और Nuget यह पहचानने में असमर्थ है कि आपकी परियोजनाएं सिंक्रनाइज़ नहीं हैं। Packages.config एक बात कहेंगे लेकिन संदर्भ में दिखाया गया पथ - गुण कुछ और इंगित करेंगे।

यदि आप अपनी निर्भरताओं को अपडेट करने के इच्छुक हैं, तो निम्न कार्य करें:

  1. समाधान एक्सप्लोरर से, प्रोजेक्ट पर राइट क्लिक करें और 'Nuget पैकेज प्रबंधित करें' पर क्लिक करें।

  2. बाएं फलक में 'इंस्टॉल किए गए पैकेज' टैब का चयन करें अपने इंस्टॉल किए गए पैकेज रिकॉर्ड करें आप अपने पैकेज में अपने पैकेज.कॉन्फिग को अपने डेस्कटॉप पर प्रतिलिपि बनाना चाहेंगे, यदि आपके पास बहुत कुछ है, तो आप यह देखने के लिए Google के साथ जांच कर सकते हैं कि Nuget pkgs इंस्टॉल किए गए हैं

  3. अपने पैकेज अनइंस्टॉल करें। ठीक है, हम उन्हें वापस जोड़ने जा रहे हैं।

  4. आपको आवश्यक पैकेजों को तत्काल इंस्टॉल करें। नूजेट क्या करेगा न केवल आपको नवीनतम संस्करण प्राप्त करेगा, बल्कि आपके संदर्भों को बदल देगा, और आपके लिए बाध्यकारी रीडायरेक्ट भी जोड़ देगा।

  5. अपनी सभी परियोजनाओं के लिए यह करो।

  6. समाधान स्तर पर, एक स्वच्छ और पुनर्निर्माण करें।

आप निचली परियोजनाओं से शुरू करना चाहते हैं और उच्च स्तर पर अपना रास्ता काम करना चाहते हैं, और साथ ही साथ प्रत्येक परियोजना को पुनर्निर्माण कर सकते हैं।

यदि आप अपनी निर्भरताओं को अपडेट नहीं करना चाहते हैं, तो आप पैकेज मैनेजर कंसोल का उपयोग कर सकते हैं और सिंटैक्स अपडेट-पैकेज -प्रोजेक्टनाम [yourProjectName] [packageName] -Version [versionNumber] का उपयोग कर सकते हैं।


यह वास्तव में आपके बाहरी घटक पर निर्भर करता है। जब आप .NET अनुप्रयोग में बाहरी घटक का संदर्भ देते हैं तो यह उस घटक की पहचान करने के लिए एक GUID उत्पन्न करता है। यह त्रुटि तब होती है जब आपके किसी एक प्रोजेक्ट द्वारा संदर्भित बाहरी घटक का नाम समान होता है और अन्य संस्करण में अन्य घटक के रूप में अलग-अलग संस्करण होता है।

यह कभी-कभी होता है जब आप संदर्भ ढूंढने के लिए "ब्राउज़ करें" का उपयोग करते हैं और असेंबली के गलत संस्करण को जोड़ते हैं, या आपके पास स्थानीय कोड में इंस्टॉल किए गए कोड के रूप में आपके कोड रिपॉजिटरी में घटक का एक अलग संस्करण होता है।

यह जानने का प्रयास करें कि कौन सी परियोजनाओं में इन विवादों का सामना किया गया है, संदर्भ सूची से घटकों को हटाएं, फिर उन्हें फिर से जोड़ें ताकि आप सुनिश्चित कर सकें कि आप एक ही फ़ाइल पर इंगित कर रहे हैं।


विचार करने और जांचने की एक और बात यह है कि सुनिश्चित करें कि आपके पास उस बिन फ़ोल्डर का उपयोग करने वाली कोई भी सेवा नहीं है। अगर वे सेवा बंद कर देते हैं और समाधान पुनर्निर्माण करते हैं






warnings