"मेटाडेटा फ़ाइल 'त्रुटि ... \ रिलीज़ \ project.dll' दृश्य स्टूडियो में नहीं मिल सका"


135

हाल ही में मैंने इस संदेश को यादृच्छिक रूप से प्राप्त करना शुरू किया:

मेटाडेटा फ़ाइल '... \ Release \ project.dll' Visual Studio में नहीं मिली

मेरे पास इसमें कई परियोजनाओं के साथ एक समाधान है। वर्तमान बिल्ड मोड डीबग है और सभी प्रोजेक्ट्स के कॉन्फ़िगरेशन डीबग पर सेट हैं। लेकिन जब मैं मुख्य परियोजना को चलाने की कोशिश करता हूं - कभी-कभी यह मुझे कुछ त्रुटियां देता है, जिनमें से सभी "मेटाडेटा फ़ाइल 'हैं ... \ रिलीज़ \ ProjectX.dll' नहीं मिल सका" - और, देखो, यह RELEASE के बारे में कहता है फ़ोल्डर, हालांकि वर्तमान मोड डीबग है। क्यों? मैंने सभी समाधान फ़ाइलों के अंदर "रिलीज़ \ projectX.dll" के संदर्भ में खोज करने की कोशिश की, और मुझे एक ResolveAssemblyReference.cache फ़ाइल मिली।

मैंने इंटरनेट पर एक अच्छी खोज की और कुछ लोगों को इसी तरह की समस्या के साथ मिला, लेकिन कोई समाधान नहीं था, या कम से कम काम करने वाला समाधान नहीं था।

मैंने उन परियोजनाओं के संदर्भों को हटाने और उन्हें पढ़ने की कोशिश की, लेकिन कुछ समय में मुझे फिर से ये त्रुटियां होने लगती हैं।

यह एक बग की तरह लगता है। जब मैं हमेशा डिबग मोड का उपयोग करता हूं, तो यह रिलीज फ़ोल्डर्स में संदर्भित परियोजनाओं की खोज क्यों करता है?

पुनश्च। इस समस्या को पूरा करने वालों के लिए: मैं इसे आसान तरीके से हल नहीं कर सका। मेरे द्वारा Windows पुनर्स्थापित करने के बाद ही यह गायब हो गया :(


इस तरह के मुद्दों के लिए पहली चीज .suo फ़ाइल को हटाना और पुनर्निर्माण करना है।
वेंट

यह समस्या तब हो सकती है यदि एक संदर्भित dll .net फ्रेमवर्क के अलग (निचले) संस्करण का उपयोग कर रहा है
m4ngl3r

मुझे यह समस्या लगातार हो रही थी जब तक कि मैं समानांतर बिल्ड को बंद नहीं कर देता। मुझे लगता है कि समानांतर बिल्ड निर्भरता जाँच में एक बग है, संभवतः कैशिंग बासी जानकारी से संबंधित है। (रिकॉर्ड के लिए, मैं अब समानांतर बिल्ड का उपयोग करता हूं, और मैं समस्या के होने पर फिर से निर्माण करता हूं, जो आमतौर पर काम करता है।)
योयो


जवाबों:


138

हर कोई सही है ... सब कुछ आज़माएं ... (थोड़ा समय बर्बाद करने के लिए)

  1. क्या आपके पास बुरा कोड है? पहले ठीक करो।
  2. क्लीन सोल्यूशन एंड रिस्टार्ट विजुअल स्टूडियो
  3. निकालें / संदर्भ जोड़ें
  4. अपने बिल्ड ऑर्डर w / बड़ी परियोजनाओं की जाँच करें और सत्यापित करें
  5. मैन्युअल रूप से उप-परियोजनाओं का पुनर्निर्माण करें
  6. संबंधित बिन फ़ोल्डर में प्रोजेक्ट्स के बीच मैन्युअल रूप से dlls कॉपी करें
  7. जाओ कुछ कॉफ़ी लाओ, कुछ पिनबॉल खेलो और कल वापस आओ ... इस बीच आप कुछ और सोच सकते हैं।

17
आपको सभी त्रुटियों को साफ करने और समाधान / परियोजना को स्थिर करने की आवश्यकता है।
रवि राम

फ़ोल्डर नाम और नाम स्थान नाम में अंतर के कारण ऐसा होता है। यदि आप एक निश्चित नाम में एक नाम स्थान बनाते हैं, और बाद में आप इसका नाम बदल देते हैं तो पुराने नाम का ही नाम होगा। और संकलन पुराने फ़ाइल .dllऔर .exeफ़ाइल को खोजने के लिए ले जाएगा । इससे बचने .csprojके लिए प्रत्येक नेमस्पेस की फाइल को टेक्स्ट फाइल के साथ खोलें , और फाइल में पुराना रास्ता खोजें। इसे हटाएं, समाधान को साफ और पुनर्निर्माण करें। इसने मेरे लिए काम किया। मैंने पूरा दिन इस समस्या पर काम करने में बिताया।
सोरज

यदि आपके पास सफलता नहीं है और समय लग रहा है, तो पहले कुछ बुनियादी चीजों को फिर से आजमाएं। मैंने उप-परियोजनाएं बनाना शुरू कर दिया, फिर भी त्रुटियां हुईं, लेकिन फिर बंद हो गई और वीएस को फिर से खोला, समाधान को फिर से बनाया, सभी ने काम किया।
क्रिस हैलक्रो

6
मैं एक नाम से संदर्भित घर और नाम परियोजनाओं में बेमेल था dll संदर्भित। साथ ही, इसे 4.5 के बजाय .NET 4.5.2 के साथ बनाया गया था। आदमी!
जेस

1
.Suo फ़ाइल को हटाने का प्रयास करें। यह भ्रष्ट हो जाना अपेक्षाकृत आम है।
टिम्बो

21

मेरे साथ भी ठीक यही समस्या थी। 50+ परियोजनाओं के साथ बिग विजुअल स्टूडियो समाधान।

सभी संदर्भों को परियोजनाओं के रूप में जोड़ा गया था। प्रोजेक्ट बिल्ड ऑर्डर सही था (प्रोजेक्ट पर राइट क्लिक करें और बिल्ड ऑर्डर चुनें)।

हालांकि जब कुछ उच्च स्तर की परियोजनाओं का निर्माण किया जाता है, तो "रूट" परियोजना जो उन पर निर्भर होती है, निर्मित नहीं होती थी।

समस्या यह थी कि इन परियोजनाओं को वर्तमान कॉन्फ़िगरेशन के तहत बनाने के लिए नहीं चुना गया था (पता नहीं यह कैसे हुआ)।

यदि समस्याग्रस्त परियोजनाओं को बनाने के लिए सेट किया गया है, तो यह "कॉन्फ़िगरेशन मैनेजर" (बिल्ड मेनू) ई चुनें।


धन्यवाद! इसने मेरे लिए बहुत अच्छा काम किया, जब किसी कारण से, मेरे रिलीज कॉन्फ़िगरेशन ने मेरी एक परियोजना का निर्माण नहीं किया।
वेक्टोवॉक्स

तुमने मेरी जान बचाई!
चेतन शेट्टी

16

जब आप कहते हैं कि आपने उन परियोजनाओं के संदर्भ हटा दिए हैं और उन्हें फिर से जोड़ दिया है, तो आपने उन्हें फिर से कैसे जोड़ा? क्या आपने Visual Studio में "संदर्भ जोड़ें" संवाद में "ब्राउज़ करें" टैब का उपयोग किया था? या, क्या आपने "प्रोजेक्ट्स" टैब का उपयोग किया था (जो आपके समाधान में पड़ोसी परियोजनाओं को सूचीबद्ध करता है)?

संपादित करें : यदि आप "ब्राउज़ करें" टैब का उपयोग करते हैं, और मैन्युअल रूप से आपके। वर्तमान में (डीबग या रिलीज़)।

यदि आपने रिलीज़ फ़ोल्डर से वास्तविक .dll फ़ाइल को हटा दिया है (या तो मैन्युअल रूप से या "क्लीन सोल्यूशन" करके), तो आपका संदर्भ टूट जाएगा क्योंकि .dll मौजूद नहीं है।

मेरा सुझाव है कि ProjectX.dll के संदर्भ को हटा दें, और इसे फिर से जोड़ें - लेकिन इस बार, "संदर्भ जोड़ें" संवाद में "प्रोजेक्ट" टैब का उपयोग करें। जब आप इस तरह से एक संदर्भ जोड़ते हैं, तो Visual Studio जानता है कि कहां उपयुक्त है। dll। यदि आप डिबग मोड में हैं, तो इसे / डीबग फ़ोल्डर से मिलेगा। यदि रिलीज़ मोड में, / रिलीज़ फ़ोल्डर। आपकी बिल्ड त्रुटि दूर होनी चाहिए, और आप भी अब (अनुचित तरीके से) डिबग मोड में एक रिलीज .dll का संदर्भ देते हुए नहीं होंगे।


मैंने "संदर्भ जोड़ें" संवाद में "ब्राउज़ करें" टैब का उपयोग किया
रात का खाना

1
मेरे लिए Visual Studio ने "Visual Studio Solution उपयोगकर्ता विकल्प" प्रकार का एक प्रोजेक्ट नाम.v11 बनाया था। मैंने इस फ़ाइल को हटा दिया और पुनः आरंभ किया और सब कुछ ठीक था।
वेस ग्रांट

15

खैर, मेरा जवाब सिर्फ सभी समाधानों का सारांश नहीं है, बल्कि यह इससे कहीं अधिक है।

अनुभाग एक):

सामान्य समाधानों में:

मेरे पास इस तरह की 4 त्रुटियां थीं ('मेटाडेटा फ़ाइल नहीं मिल सकी') साथ में 1 त्रुटि यह कहते हुए कि 'स्रोत फ़ाइल नहीं खोली जा सकती (' अनिर्दिष्ट त्रुटि ')'।

मैंने 'मेटाडेटा फ़ाइल नहीं मिल पाई' त्रुटि से छुटकारा पाने की कोशिश की। उसके लिए, मैंने कई पोस्ट, ब्लॉग आदि पढ़े और पाया कि ये समाधान प्रभावी हो सकते हैं (इन्हें यहाँ संक्षेप में प्रस्तुत करना):

  1. VS को पुनरारंभ करें और फिर से निर्माण का प्रयास करें।

  2. पर जाएं 'समाधान एक्सप्लोरर' । समाधान पर राइट क्लिक करें। गुणों पर जाएं । पर जाएं 'विन्यास प्रबंधक' । जांचें कि 'बिल्ड' के तहत चेकबॉक्स चेक किए गए हैं या नहीं। यदि उनमें से कोई भी या सभी अनियंत्रित हैं, तो उन्हें जांचें और फिर से निर्माण करने का प्रयास करें।

  3. यदि उपरोक्त समाधान काम नहीं करता है, तो उपरोक्त चरण 2 में उल्लिखित अनुक्रम का पालन करें, और यहां तक ​​कि यदि सभी चेकबॉक्स चेक किए गए हैं, तो उन्हें अनचेक करें, फिर से जांचें और फिर से निर्माण करने का प्रयास करें।

  4. आदेश और परियोजना निर्भरता बनाएँ:

    पर जाएं 'समाधान एक्सप्लोरर' । समाधान पर राइट क्लिक करें। पर जाएं 'परियोजना निर्भरता ...' । आपको 2 टैब दिखाई देंगे: 'डिपेंडेंसी' और 'बिल्ड ऑर्डर' । यह बिल्ड ऑर्डर वह है जिसमें समाधान बनता है। प्रोजेक्ट की निर्भरता और बिल्ड ऑर्डर की जाँच करें कि अगर कुछ प्रोजेक्ट ('प्रोजेक्ट 1') जो अन्य पर निर्भर है ('प्रोजेक्ट 2') उस एक (प्रोजेक्ट 2) से पहले बनाने की कोशिश कर रहा है। यह त्रुटि का कारण हो सकता है।

  5. लापता .dll का पथ जांचें:

    लापता .dll का पथ जांचें। यदि पथ में स्थान या कोई अन्य अमान्य पथ वर्ण है, तो उसे निकालें और पुन: निर्माण का प्रयास करें।

    यदि यह कारण है, तो बिल्ड ऑर्डर को समायोजित करें।


धारा 2):

मेरा विशेष मामला:

मैंने विभिन्न चरणों और संयोजनों के साथ उपरोक्त सभी चरणों को वी.एस. को फिर से शुरू करने की कोशिश की। लेकिन, इससे मुझे कोई फायदा नहीं हुआ।

इसलिए, मैंने उस दूसरी त्रुटि से छुटकारा पाने का फैसला किया, जो मुझे आ रही थी ('सोर्स फाइल नॉट बी ओपन' ('अनिर्दिष्ट त्रुटि') ')।

मुझे एक ब्लॉग मिला: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539

मैंने उस ब्लॉग में वर्णित चरणों की कोशिश की और मुझे त्रुटि से छुटकारा मिल गया 'सोर्स फाइल नॉट बी ओपन (' अनिर्दिष्ट त्रुटि ')' और आश्चर्यजनक रूप से मुझे अन्य त्रुटियों से छुटकारा मिला ('मेटाडेटा फ़ाइल नहीं मिली') भी।


धारा 3):

कहानी का नैतिक:

त्रुटि से छुटकारा पाने के लिए ऊपर (और किसी भी अन्य समाधान) खंड (1) में वर्णित सभी समाधानों का प्रयास करें। यदि कुछ भी काम नहीं करता है, तो ऊपर दिए गए अनुभाग (2) में उल्लिखित ब्लॉग के अनुसार, उन सभी स्रोत फ़ाइलों की प्रविष्टियों को हटा दें जो अब स्रोत नियंत्रण में मौजूद नहीं हैं और आपकी .csproj फ़ाइल से फ़ाइल सिस्टम



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

अच्छा ... मुझे खुशी है कि मेरा जवाब आपके लिए कुछ मदद का था।
विक्रम

11

मुझे यह समस्या पहले आई है और इसे हल करने का एकमात्र तरीका क्लीन सॉल्यूशन चलाना है और फिर Visual Studio को पुनरारंभ करना है।


1
यह मेरी स्थिति में मदद नहीं करता है, कम समय के बाद समस्या फिर से दिखाई देती है।
नाईटकोर

यही मेरे लिए तय है।
14

3
यह सिर्फ मेरे लिए भी काम किया। कई सफाई की और कुछ भी काम नहीं किया। एक बार जब मैंने साफ किया और फिर से शुरू किया, तो यह फिर से काम करना शुरू कर दिया। कैसा कष्टकर।
रिकी

8

मेरे लिए यह आमतौर पर लक्ष्य ढाँचा बंद हो रहा है (4.6 के बजाय 4.5.2) यदि आप समाधान और निर्माण के लक्ष्य ढांचे से मेल खाने के लिए परियोजना के लक्ष्य ढांचे को ठीक करते हैं, तो एक नया .dll बनाया जाएगा।


मेरे पास एक प्रोजेक्ट के लिए एक ही मुद्दा था जो विज़ुअल स्टूडियो के पुराने संस्करण के साथ बनाया गया था। VS को अपडेट करने के बाद, .NET के नए संस्करण के साथ प्रोजेक्ट बनाए गए और DLL-not-found समस्या का कारण बना। (.NET संस्करण को देखने / संपादित करने के लिए प्रोजेक्ट के लिए गुण फलक पर जाएँ।) धन्यवाद!
टोनी एस यू

लाख बार धन्यवाद (कि मेरे द्वारा किए गए अन्य समाधानों की संख्या)। यह काम किया। किसी कारण से मैं जो पुस्तकालय जोड़ रहा हूं वह अन्य सभी परियोजनाओं की तुलना में अलग-अलग .NET फ्रेमवर्क संस्करण को लक्षित कर रहा था
नूर लाबीबिदी

1
मैंने एक नया क्लास लाइब्रेरी प्रोजेक्ट (dll) जोड़ा, जिसे कई अन्य परियोजनाओं में संदर्भित किया गया था। नया dll .NET फ्रेमवर्क 4.8 था जबकि अन्य सभी प्रोजेक्ट्स 4.7.2 थे। टारगेट फ्रेमवर्क (प्रोजेक्ट प्रॉपर्टी में) को 4.7.2 में बदलना मेरे लिए यह तय किया गया। धन्यवाद एडम!
आईकोड


3

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


3

क्या आपने कॉन्फ़िगरेशन प्रबंधक सेटिंग्स की जांच की? प्रोजेक्ट सेटिंग्स डायलॉग टॉप राइट कॉर्नर में।

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


मैंने इसे जाँचा था। सभी परियोजनाओं का विन्यास समान है।
रात्रि

2

मैंने इस त्रुटि को उन समाधानों में भी देखा है जहां मेरे पास कई परियोजनाएं हैं (आमतौर पर नेटटियर्स परियोजनाएं जहां मैंने 4.0 ढांचे को लक्षित करने के लिए एक या एक से अधिक उप-परियोजनाओं को अपडेट किया है)। इसे हटाने में समस्या हो सकती है। अक्सर, इसे हल किया जा सकता है, हालांकि, उप-परियोजनाओं में अन्य सभी त्रुटियों को पहले से ठीक करके (जैसे, किसी भी लापता संदर्भ), व्यक्तिगत रूप से उन उप-परियोजनाओं का पुनर्निर्माण करना, फिर विजुअल स्टूडियो में उन उप-परियोजनाओं के किसी भी संदर्भ को वापस जोड़ना / जोड़ना। व्यक्तिगत रूप से, मैंने अकेले समाधान की सफाई करके इस त्रुटि को हल करने का सौभाग्य प्राप्त किया है।


1
अन्य प्रोजेक्ट्स (मेरे UI और टेस्ट प्रोजेक्ट्स, उदाहरण के लिए) से संदर्भों को हटाते हुए, त्रुटियों को ठीक करना (कोर प्रोजेक्ट में), बिल्डिंग, और फिर उन संदर्भों को फिर से जोड़ना मेरे लिए चाल चली।
केन पेसिसा

2

हम हाल ही में Office 2007 से Office 2010 में अपग्रेड करने के बाद इस समस्या में भाग गए - हमें कुछ प्रोजेक्ट्स में उपयोग किए जाने वाले Office Interops के संस्करण 14 में मैन्युअल रूप से अपनी परियोजना में संदर्भ बदलने पड़े।

आशा है कि मदद करता है - यह पता लगाने के लिए हमें कुछ दिन लग गए।


2

मेरे मामले में यह दो चीजों (VS.2012) के कारण हुआ:

1) परियोजनाओं में से एक को x86 के बजाय AnyCPU के लिए कॉन्फ़िगर किया गया था

2) एक परियोजना जिसे संदर्भित किया गया था, किसी भी तरह "बिल्ड" चेकबॉक्स अनियंत्रित था।

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


2

मेरे मामले में, मेरे कोड में कुछ त्रुटियां थीं। विज़ुअल स्टूडियो ने वास्तविक त्रुटियों के बजाय आपके द्वारा की गई त्रुटि को दिखाया, जैसे वाक्यविन्यास त्रुटियां या अज्ञात वर्ग के नाम। प्रोजेक्ट के बाद समाधान और निर्माण परियोजना की सफाई की कोशिश करें। इस तरह आप वास्तविक त्रुटियों की खोज करेंगे।

फिर, यह सिर्फ मेरे लिए त्रुटि का कारण है


2

मुझे यह समस्या थी और इसका पता लगाने में मुझे लंबा समय लगा। समस्या तब आई जब मैंने समाधान से परियोजनाओं को हटा दिया और उन लोगों को नगेट पैकेज के साथ बदल दिया।

समाधान ठीक लग रहा था, लेकिन .csproj फ़ाइल में अभी भी संदर्भ के रूप में कई बार उन प्रोजेक्ट्स शामिल हैं।

लगता है कि वी.एस. उस फ़ाइल को उचित रूप से साफ नहीं करता है। यह अभी भी हुड के तहत हटाए गए परियोजनाओं का संदर्भ दे रहा था। जब csproj फ़ाइल से संदर्भों को मैन्युअल रूप से हटा दिया जाता है तो सभी काम करता है! wohoo


2

यह समस्या pdb फ़ाइलों या CodeContracts के कारण होती है।

इसे हल करने के लिए:

  1. अपने आउटपुट फ़ोल्डर को साफ़ करें और समाधान का पुनर्निर्माण करें।

  2. कोडकॉन्ट्रैक्ट्स को फिर से कॉन्फ़िगर करें या इसे अस्थायी निर्माण के लिए अक्षम करें।


2

हमारे पास वह समस्या अक्सर है, लेकिन केवल C # परियोजनाओं से C ++ / CLI परियोजनाओं के संदर्भ में। यह स्पष्ट रूप से दृश्य स्टूडियो में एक बग गहरा है जिसे Microsoft ने ठीक नहीं करने का फैसला किया, क्योंकि यह 'बहुत जटिल' है और उन्होंने C ++ बिल्ड सिस्टम के ओवरहाल का वादा किया था जो अब विज़ुअल स्टूडियो 2010 के लिए लक्षित है।

यह कुछ समय पहले था, और शायद फिक्स भी विजुअल स्टूडियो 2008 में चला गया; मैं उस पर किसी भी अधिक का पालन नहीं किया। हालाँकि, हमारा सामान्य वर्कअराउंड था

  • कॉन्फ़िगरेशन स्विच करें
  • Visual Studio को पुनरारंभ करें
  • समाधान का निर्माण करें

इस समस्या के बाद हमेशा के लिए गायब हो जाता है या सिर्फ अस्थायी रूप से? और "स्विच कॉन्फ़िगरेशन" से आपका क्या मतलब है? उदाहरण के लिए मैं हमेशा डिबग कॉन्फ़िगरेशन का उपयोग करता हूं। मुझे क्या करना चाहिए?
रात्रि 12:30 बजे

यह अस्थायी रूप से गायब हो जाता है। वास्तव में, यह आपके लिए समाधान नहीं हो सकता है यदि आप डिबग और रिलीज़ के बीच कॉन्फ़िगरेशन को कभी भी स्विच नहीं करते हैं। या फिर रिलीज़ करने के लिए स्विच करना और फिर डिबग इसे ठीक कर सकता है, जो जानता है;)
आउटऑफ़मेरी

खैर, कुछ दिनों पहले मैंने रिलीज़ करने के लिए स्विच किया, समाधान बनाया, और फिर डिबग पर वापस आ गया। इसके बाद समस्या उत्परिवर्तित :): अब मुझे कुछ के बजाय केवल 1 ऐसी त्रुटि मिलती है - यह अन्य परियोजनाओं की तरह "निश्चित" हो गया है :)
नाइटकार्ड

2

मुझे खुद भी यही समस्या थी।

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

इसलिए मैंने सब कुछ संस्करण 4.5 में बदल दिया, और इसने फिर से काम किया।


यह वही संकल्प था जो मुझे इस समस्या के होते हुए आया था। कुछ संदर्भों ने मेरे आधार अनुप्रयोग से अधिक एक फ्रेमवर्क का उपयोग किया, जब मैंने आधार अनुप्रयोग में फ्रेमवर्क को 4.5.2 में बदल दिया (अन्य संदर्भों के समान), तो समस्या दूर हो गई। हालांकि, VS ने विभिन्न फ्रेमवर्क संस्करणों के बारे में कुछ नहीं कहा।
NoLifeKing

1

मुझे कुछ महीने पहले इसी तरह की समस्या याद आ रही है। मैंने इसे संदर्भित DLL को रिलीज़ फ़ोल्डर में कॉपी करके अस्थायी रूप से हल किया, इस प्रकार विजुअल स्टूडियो की अपेक्षाओं को पूरा किया। बाद में, मैंने अपने वास्तविक कोड में रिलीज़ DLL के संदर्भ की खोज की। आपको संपूर्ण प्रोजेक्ट के लिए \ release \ project.dll के माध्यम से खोज करने का प्रयास करना चाहिए।

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


1

मुझे यह समस्या थी और यह आपत्तिजनक पुस्तकालय (dll) में एक अमान्य पद्धति के कारण था जिसने मान वापस नहीं किया, उदाहरण के लिए

public bool DoSomething()
{
   //I never bothered putting code here....

}

जब मैंने यह सब कुछ संकलित किया :)


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

1

कभी-कभी VS2010 मेरे कॉन्फ़िगरेशन को किसी भी सीपीयू से मिश्रित प्लेटफार्मों पर स्विच करता है। जब ऐसा होता है तो मुझे यह त्रुटि संदेश मिलता है।

इसे हल करने के लिए मैं किसी भी सीपीयू पर वापस स्विच करता हूं:
1. समाधान पर राइट क्लिक करें और गुणों का चयन करें।
2. कॉन्फ़िगरेशन गुण और फिर कॉन्फ़िगरेशन प्रबंधक ... बटन पर क्लिक करें।
3. एक्टिव सॉल्यूशन प्लेटफॉर्म के तहत कोई भी सीपीयू चुनें


1

मुझे लगता है कि यह आमतौर पर मेरे लिए तब होता है जब मेरे पास अभी भी एक इंटरफ़ेस में एक विधि की घोषणा होती है, जो एक वर्ग को लागू करता है, लेकिन यह कि मैंने बाद में हटा दिया था और इसे इंटरफ़ेस से भी निकालना भूल गया था। मैं आमतौर पर हर 30mins n के बाद पूरे समाधान को सहेजता हूं, अगर मैं त्रुटि पाता हूं तो बस एक पुराने संस्करण पर वापस लौटें।


1

मैंने अपने संदर्भों को हटाना समाप्त कर दिया (मैंने प्रोजेक्ट टैब का उपयोग करके उन्हें ठीक से जोड़ दिया था, और वे बस ठीक-ठाक निर्माण करते थे), मेरी .csproj फ़ाइलों को संपादित करना और विचित्र प्रविष्टियों को हटाना जो कि नहीं थीं - और डिबग के लिए मेरे आउटपुट सेट करना। रिलीज़, x86 और x64 और सभी के लिए कोई भी सीपीयू "बिन" होना चाहिए - मैंने इसे एक बार बनाया, फिर संदर्भ (फिर से, प्रोजेक्ट टैब का उपयोग करके) जोड़ा, और सब कुछ मेरे लिए फिर से काम करना शुरू कर दिया। दृश्य स्टूडियो को पुनः आरंभ नहीं करना था।


1

मेरे लिए यह डीएलई आउटपुट नहीं करने के लिए फिर से लिखे गए बिल्ड लक्ष्य के कारण हुआ था। डिफ़ॉल्ट बिल्ड लक्ष्य पर वापस गिरने के लिए इसे हटाने से समस्या ठीक हो गई।


1

मेरे मामले में मैं मास्टर की एक शाखा में काम कर रहा था। इसलिए मैंने मास्टर शाखा की जाँच की, एक निर्माण चलाया और फिर मेरी शाखा की जाँच की। इसने मुद्दा तय कर दिया। यदि आप पहले से ही मास्टर हैं, तो मेरा सुझाव है कि आप पिछली प्रतिबद्ध जांच करें और फिर इसका निर्माण करें।


1
वाह! मैंने बहुत सारे विकल्पों की कोशिश की है, कुछ भी काम नहीं किया। लेकिन यह मुद्दा तय हो गया! धन्यवाद दोस्त :)
थारिंडू

0

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


0

विदर्भ द्वारा वर्णित आज भी मेरे साथ ऐसा ही हुआ।

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

क्या इसमें सुधार करने के लिए वीएस में कोई सेटिंग है?


0

मुझे भी यही समस्या थी। मैंने देखा कि मेरे db संदर्भ (EF4) जो कि परियोजना dll में स्थित था, किसी कारण से पहचाना नहीं गया था। मैंने इसे हटा दिया और इसके बजाय एक और एक बनाया। और यह मेरे लिए हल है।


0

आज भी यही समस्या थी।

मेरा आवेदन, एक Windows प्रपत्र अनुप्रयोग, आकस्मिक रूप से स्वयं का संदर्भ था। अजीब।

एक बार हटा देने के बाद, त्रुटि दूर हो गई।

प्रत्येक बार जब मैं Windows प्रपत्र प्रोजेक्ट में स्थित उपयोगकर्ता नियंत्रण को खींचता हूं, तो संदर्भ को प्रपत्र में जोड़ा गया।


0

मुझे भी यही समस्या थी। मैन्युअल रूप से हटाने और dll को जोड़ने से कोई फायदा नहीं हुआ। क्लास लाइब्रेरीज़ ने सभी प्रोजेक्ट्स के लिए संकलन नहीं किया था और प्रोजेक्ट के लिए ... \ bin \ Debug फ़ोल्डर में गायब था [क्योंकि मैंने गलती से समाधान साफ ​​कर दिया था]। चूँकि कक्षा के पुस्तकालय ने यह संकलित नहीं किया था कि इसका अर्थ उन उप परियोजनाओं में से कुछ में कहीं न कहीं त्रुटियां हो सकती हैं

समाधान: चूंकि मेरे dlls ... \ bin \ रिलीज़ फ़ोल्डर के लिए थे, इसलिए मैंने रिलीज़ मोड पर पुनर्निर्माण करने की कोशिश की और सब प्रोजेक्ट्स में से एक में एक लाइन पर एक त्रुटि पाई। त्रुटि को हल करने और समाधान के पुनर्निर्माण से बिल्ड त्रुटि से छुटकारा मिला।


0

मेरे लिए Visual Studio ने "Visual Studio Solution उपयोगकर्ता विकल्प" प्रकार का एक प्रोजेक्ट नाम .v11 बनाया था। मैंने इस फ़ाइल को हटा दिया और पुनः आरंभ किया और सब कुछ ठीक था।

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