XAML में नाम स्थान त्रुटि में नाम मौजूद नहीं है


126

एक VB.NET WPF आवेदन पर काम कर रहे VS2012 का उपयोग करना। मेरे पास एक सरल MusicPlayer ट्यूटोरियल ऐप है जिसे मैं WPF सीखने के लिए उपयोग कर रहा हूं। मैं ट्यूटोरियल के C # संस्करण को VB.NET के चरण दर चरण परिवर्तित कर रहा हूं।

ऐप में 2 कक्षाएं हैं जो एक ही नामस्थान के तहत दोनों हैं। मैं XAML में नाम स्थान का संदर्भ देने में सक्षम हूं, लेकिन जब मैं XAML में वर्ग ऑब्जेक्ट को संदर्भित करने का प्रयास करता हूं तो मुझे एक त्रुटि मिलती है और मैं संकलन करने में सक्षम नहीं हूं।

अजीब बात यह है कि IntelliSense दोनों xmlns के माध्यम से नामस्थान को संदर्भित करने के साथ ठीक काम करता है: c = टैग और वर्ग वस्तु का उपयोग करते समय टाइप भी करता है <c: लेकिन ऑब्जेक्ट को रेखांकित किया गया है और त्रुटियों को डिज़ाइनर बनाने या काम करने की कोशिश कर रहा है।

.Vb क्लास की फाइलें एक फ़ोल्डर में होती हैं, जिसे \ Controls कहा जाता है। मुख्य परियोजना रूट नेमस्पेस जानबूझकर खाली छोड़ दिया गया है। क्लास को इस तरह कोड किया जाता है ...

Namespace MusicPlayer.Controls
    Public Class UpdatingMediaElement
       .... code here
    End Public
End Namespace

Xaml इस तरह दिखता है

( <Window >टैग में परिभाषित नाम स्थान

xmlns:c="clr-namespace:MusicPlayer.Controls"

(एक में परिभाषित वस्तु <Grid>)

  <c:UpdatingMediaElement Name="MyMediaElement" />

(त्रुटि प्रदर्शित) नाम "UpdatingMediaElement" नामस्थान "clr-namespace: MusicPlayer.Controls" में मौजूद नहीं है।

सुनिश्चित नहीं है कि क्या गलत है या इसे कैसे ठीक किया जाए?


13
दृश्य को पुनः आरंभ करना मेरे लिए काम कर गया। (पुनः आरंभ करने की शक्ति को कभी कम न
समझें

1
जो लोग इससे जूझ रहे हैं उनके लिए थोड़ी मदद: सुनिश्चित करें कि आपकी कक्षा सार्वजनिक है।
बोरझ

जवाबों:


234

जब आप अपना wpf कोड लिख रहे होते हैं और VS यह बताता है कि "ABCDE का नाम नाम स्थान clr-namespace: ABC" में नहीं है। लेकिन आप पूरी तरह से अपनी परियोजना को सफलतापूर्वक बना सकते हैं, केवल एक छोटी सी असुविधा है क्योंकि आप यूआई डिजाइनिंग नहीं देख सकते हैं (या बस कोड को साफ करना चाहते हैं)।

इन्हें करने का प्रयास करें:

  • VS में, अपने समाधान -> गुण -> कॉन्फ़िगरेशन गुणों पर राइट क्लिक करें

  • एक नया संवाद खोला गया है, प्रोजेक्ट कॉन्फ़िगरेशन को डीबग से रिलीज़ या इसके विपरीत बदलने का प्रयास करें।

उसके बाद, अपने समाधान का पुनः निर्माण करें। यह आपकी समस्या को हल कर सकता है।


4
यह अभी भी Visual Studio 2015 अद्यतन 1 में होता है। आपके समाधान ने काम किया - धन्यवाद!
साइमन स्मिथ

4
शायद नहीं, लेकिन मैंने पाया कि टूलबार पर डिबग और रिलीज़ मोड के बीच स्विच करने की परवाह किए बिना काम किया।
ketura

35
जुलाई 2017 में वीएस 2017 संस्करण 15.2 (26430.15) पर पुष्टि की गई। बस डिबग से रिलीज़ होने तक ड्रॉपडाउन में बदल गया, संकलित किया गया और त्रुटि चली गई, वापस बदल गई और संकलित हुई और त्रुटि अभी भी गई थी।
टेड हेन्सन

7
ऐसा लगता है कि वीएस 17 विशेष रूप से जिद्दी है - ट्राइंग चेंजिंग रिले / डीबीजी, एक्स 64 / एक्स 86 को बदलना, शैडोकेच, कॉम्पोनेन्टचैके, बिन / ओबज फोल्डर को डिलीट करना, अभी भी "त्रुटियां" हैं और डिजाइनर इस एक छोटे ऐप (अन्य ऐप्स के साथ काम नहीं करता है) जैसे 50 WPF दृश्य ठीक काम करते हैं)। अचानक हुआ और दूर नहीं जा सकता। कई बार पहले यह संभावना थी लेकिन वीएस 17 पर पहली बार और अब इसे ठीक नहीं कर सकते। फिर भी यह सबसे अच्छा जवाब है क्योंकि यह पहले कई बार काम कर चुका है।
bokibeg

7
मुझे पसंद है कि मैं इस जवाब पर वापस कैसे आऊं, और मैंने पहले ही इसे बढ़ा दिया है, ... 2.5 साल पहले।
मैथ्यू गुइंडन

51

यदि असेंबली नेमस्पेस से भिन्न है जिसमें आपकी कक्षा समाहित है, तो आपको इसे स्पष्ट रूप से निर्दिष्ट करना होगा।

उदाहरण के लिए: -

xmlns:Local="clr-namespace:MusicPlayer.Controls;assembly=MusicPlayer"

1
जबकि यह पहली बार में मेरी समस्या को हल करने के लिए दिखाई दिया, यह अभी भी एक ही त्रुटि फेंकता है। हालाँकि, अब मैं भी समाधान नहीं बना पा रहा हूँ।
बॉके

6
@ बूके समाधान को साफ करें और इसे फिर से बनाएं
वसंत श्रीराम

बहुत बढ़िया, thanx। इससे वास्तव में मदद मिली
कीथ

इसने मेरे लिए यह किया। अजीब बात यह है कि कन्वर्टर्स एक ही असेंबली में xaml फ़ाइल के रूप में थे .... लेकिन वे एक अलग नामस्थान पर थे।
जोनाथन अल्फारो

धन्यवाद, विधानसभा गायब थी।
बागफैहर

31

मैंने देखा है कि इस मुद्दे को Xaml डिज़ाइन छाया कैश को हटाकर चला गया है। मेरे पास विजुअल स्टूडियो 2015 अपडेट 1 के साथ समस्या थी।

विज़ुअल स्टूडियो 2015 में कैश यहां स्थित है:

%localappdata%\Microsoft\VisualStudio\14.0\Designer\ShadowCache

प्रक्रिया:

  1. समाधान एक्सप्लोरर में समाधान पर राइट-क्लिक करें और "क्लीन समाधान" चुनें
  2. शटडाउन विजुअल स्टूडियो
  3. शैडोकेच फ़ोल्डर हटाएं
  4. विजुअल स्टूडियो प्रोजेक्ट को फिर से खोल दिया
  5. समाधान का पुनर्निर्माण करें

और वॉइला कोई और अधिक नाम त्रुटि नहीं है।


7
अफसोस की बात है, मेरे लिए एक चीज़ नहीं बदली। फिर भी लगभग पूरे साल के बाद इस कष्टप्रद स्थिति से निपटना। : /
खाले_किता

3
धन्यवाद! यह मेरे लिए काम कर रहा है। यह ट्रिक अभी भी VS15
Ocab19

4
आप सही फ़ोल्डर में तुरंत जाने के लिए% स्थानीयतापद% \ Microsoft \ VisualStudio \ 14.0 \ Designer \ का उपयोग कर सकते हैं
Maxence

1
एक डिजाइनर होना जो केवल तभी काम करता है जब आप समाधान का निर्माण करते हैं। डिजाइन देखने से पहले पूरी कार बनाने के लिए एक कार डिजाइनर के बारे में सोचें।
पॉल मैकार्थी

26

मेरे मामले में इसकी वजह थी अन्य संकलित त्रुटियों के । जब अन्य त्रुटियों को हल कर दिया गया है तो यह प्रतीत होता है कि संबंधित त्रुटि को भी सूची से हटा दिया गया था। विशेष रूप से त्रुटियों की सूची में सबसे नीचे की त्रुटियां और उन पृष्ठों पर जो आपने हाल ही में बदले हैं।

इसलिए इस त्रुटि पर सीधे ध्यान न दें और पहले अन्य त्रुटियों पर ध्यान केंद्रित करें ।


2
ध्यान दें कि बिल्ड / कंपाइल करने से मेरे लिए यह समस्या हल हो गई, जबकि मेरे पास कोई अन्य असंबंधित कंपाइल एरर नहीं था। XAML विंडो की तरह लगता है जब तक आप एक संकलन किया है हमेशा नई कक्षाओं के बारे में पता नहीं है।
एचके 1

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

मैंने कोड के पीछे एक विधि निकाली थी जो अभी भी XAML में संदर्भित थी। एक बार जब मैंने संदर्भ हटा दिया, तो यह त्रुटि चली गई।
यारसावेज १३

23

X86 में निर्माण लक्ष्य प्लेटफ़ॉर्म को बदलने और प्रोजेक्ट के निर्माण का प्रयास करें।

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


मेरे पास यह फिर से हुआ है और मैं इस बात की पुष्टि कर सकता हूं कि यह समस्या मेरे लिए है। X86 में बनाने के बाद आप x64 पर वापस जा सकते हैं।
तीजन

यह मेरे लिए वीएस 2012 में भी काम किया ... कुछ तार्किक जानने की कोशिश करने के घंटों के बाद। धन्यवाद, टॉम!
ब्रायन ग्रीनवे

X86 और वापस x64 पर स्विच करने से यहाँ समस्या ठीक हो गई, इसलिए मुझे उस प्रयास के लिए प्रेरित करने के लिए धन्यवाद। मैंने वीएस को भी बंद कर दिया था, बिन और ओबज को हटा दिया, और अन्य सुझावों के साथ फिर से बनाया, और इससे पहले तक कुछ भी मदद नहीं की।
अंगूर

हां, इसने मेरे लिए VS2015 अपडेट 2 पर भी काम किया। हालांकि, मेरे लिए मेरी बाहरी dll फ़ाइलों को फिर से लोड करना और इसे फिर से बनाना भी आवश्यक था।
SezMe

VS2015U2 के साथ, मैं अभी भी x64 में इस मुद्दे को प्राप्त करता हूं। किसी भी सीपीयू में महान काम करता है। आगे-पीछे करना मेरे लिए कारगर नहीं है।
DaleyKD

7

अगर यह किसी और की मदद करेगा

मैं WPF के लिए नया हूँ और अभी भी VB.net के साथ एक नौसिखिया हूँ - इसलिए मैं यह मान रहा था कि यह त्रुटि मेरे द्वारा मूर्खतापूर्ण तरीके से किए जाने के कारण हो रही थी ........ मुझे लगता है कि मैं वास्तव में था! मैंने अपने प्रोजेक्ट को एक साझा ड्राइव से मेरी एक स्थानीय ड्राइव पर ले जाकर इससे छुटकारा पा लिया है। त्रुटि गायब हो गई है, परियोजना पूरी तरह से आगे के मुद्दों को संकलित करती है - फिर भी। लगता है कि VS2015 में अभी भी साझा ड्राइव पर रखी गई परियोजनाओं के साथ समस्याएं हैं।


2
यह मेरे लिए मामला था, मैंने इसे अपने वीएम (जिस पर मैं विकसित करता हूं) में ले जाया और कोई समस्या नहीं हुई। धन्यवाद!
मारियो टैक

मेरे लिए भी ऐसा ही था। उन्हें एक स्थानीय ड्राइव पर ले जाने के लिए (एक नेटवर्क शेयर के बजाय - जैसा कि समानताएं मैक और विंडोज दोनों फाइल सिस्टम को एक साथ मिलाने के लिए स्थापित करती हैं), इस मुद्दे को तय किया।
ckittel

7

हो सकता है कि जब परियोजना संकलित हो, लेकिन XAML त्रुटि दिखाई दे रही है, तो एक और समाधान:

  1. समाधान में, xaml वाले प्रोजेक्ट नोड पर अन्वेषण करें
  2. प्रोजेक्ट पर राइट-क्लिक करें और 'अनलोड प्रोजेक्ट' चुनें
  3. प्रोजेक्ट पर राइट-क्लिक करें और 'Reload Project' चुनें, सुनिश्चित करें कि आपका प्रोजेक्ट अभी भी "स्टार्टअप प्रोजेक्ट" के रूप में चुना गया है। अगर नहीं :
  4. परियोजना पर राइट-क्लिक करें और 'स्टार्टअप प्रोजेक्ट के रूप में सेट करें' चुनें

दृश्य स्टूडियो को फिर से बनाने या बंद करने की आवश्यकता नहीं है।


6

जीसस ... विजुअल स्टूडियो 2017 में पांच साल बाद भी यह एक समस्या है। चूंकि मैं WPF में नया हूं, मुझे यकीन था कि समस्या किसी तरह मुझे थी, लेकिन नहीं, सब कुछ संकलित और सही तरीके से चला।

मैंने x86 / x64 आउटपुट के बीच स्विच, पुनर्निर्माण, सफाई और पुनर्निर्माण की कोशिश की, विंडोज को रिबूट करना, शैडोकैच फ़ोल्डर को साफ करना, XML नामस्थान घोषणा के लिए "असेंबली = {मेरा मुख्य विधानसभा नाम}" जोड़कर कुछ भी काम नहीं किया! एकल काम जो किया:

मेरे स्टेट्स ऑफ़ स्टैन्ड्स को रखें (मेरे मामले में यह सौदा अपने WP विधानसभा में डिज़ाइन की खोज करने के बारे में था) अपनी अलग असेंबली में और असेंबली का नाम बदलकर उसी की जगह।


2

मुझे भी यही समस्या थी, और मेरे मामले में मार्कअप डिज़ाइन व्यू ने मुझे समाधान के पुनर्निर्माण के लिए कहा और मुझे इस संदेश के साथ फ़ॉर्म लेआउट नहीं दिखाया: Design view is unavailable for x64 and ARM target platformsया Build the Project to update Design view

यह समाधान के पुनर्निर्माण से हल नहीं होता है (न तो डिज़ाइन दृश्य और न ही "नाम नाम स्थान में मौजूद नहीं है" त्रुटि)

मुझे लगता है कि यह इसलिए था क्योंकि मैंने समाधान पर सेटिंग्स के साथ खेला था -> गुण> कॉन्फ़िगरेशन गुण

मैंने अंततः 2 नौकरियों के साथ समस्या का समाधान किया:

  1. पेज के बिल्ड कॉलम पर सभी चेक बॉक्स की जाँच: समाधान -> गुण -> कॉन्फ़िगरेशन गुण
  2. डीबग से रिलीज़ या इसके विपरीत के समाधान कॉन्फ़िगरेशन को बदलना ।

मुझे लगता है कि यह Visual Studio2012 अपडेट 2 में एक बग है।


2

यही समस्या विजुअल स्टूडियो 2013, सर्विस पैक 4 को भी प्रभावित करती है। मैंने भी इसी नतीजे के साथ विजुअल स्टूडियो 2015 प्रीव्यू की कोशिश की।

यह केवल WPF विज़ुअलाइज़र की एक सीमा है जिसे विज़ुअल स्टूडियो टीम ने तय नहीं किया है। प्रमाण के रूप में, x86 मोड में निर्माण विज़ुअलाइज़र को सक्षम करता है और x64 मोड में निर्माण इसे अक्षम करता है।

विजुअल स्टूडियो 2013, सर्विस पैक 4 के लिए अजीब रूप से पर्याप्त इंटेलीजेंस काम करता है।


2

मुझे हाल ही में .NET 4.6.2 में अपने WPF प्रोजेक्ट के लिए VS 2015 अपडेट 3 का उपयोग करते हुए यह समस्या थी। मेरी परियोजना की प्रतिलिपि एक नेटवर्क फ़ोल्डर में थी , मैंने इसे स्थानीय रूप से स्थानांतरित कर दिया और इससे समस्या हल हो गई।

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


1

लगता है कि इस समस्या को "ट्रिक्स" के माध्यम से हल किया जा सकता है।

मेरे मामले में, मैं समाधान के भीतर जिस परियोजना पर काम कर रहा था, उसके बजाय पूरे समाधान का निर्माण / पुनर्निर्माण / सफाई कर रहा था। एक बार जब मैंने "बिल्ड [माय प्रोजेक्ट]" पर क्लिक किया, तो त्रुटि संदेश चला गया।


1

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

यदि आप जानते हैं कि परियोजना का संदर्भ सही है, तो लक्ष्य रूपरेखा की जाँच करें। उदाहरण के लिए, 4.5 फ्रेमवर्क के संदर्भ में 4.5.2 फ्रेमवर्क वाले प्रोजेक्ट का उपयोग करना एक अच्छा संयोजन नहीं है।


दूसरे शब्दों में, प्रोजेक्ट का .NET फ्रेमवर्क संस्करण संदर्भित प्रोजेक्ट के .NET फ्रेमवर्क संस्करण से अधिक पुराना नहीं हो सकता है।
20

1

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

  1. Windows Explorer में DLL फ़ाइल पर राइट क्लिक करें और गुण चुनें।
  2. जनरल टैब के नीचे "अनब्लॉक" बटन या चेकबॉक्स पर क्लिक करें।

नोट: केवल DLL को अनब्लॉक करें यदि आप सुनिश्चित हैं कि वे सुरक्षित हैं।


यह मेरे लिए काम करता है - मैंने ड्रॉपबॉक्स से एक प्रोजेक्ट डाउनलोड किया था और त्रुटि हो रही थी। मुझे शैडोकेच को भी हटाना था
जियोमेट्रीकल

1

मेरे मामले में, उपयोगकर्ता नियंत्रण मुख्य परियोजना में जोड़ा गया था। मैंने बिना किसी लाभ के ऊपर दिए गए विभिन्न समाधानों की कोशिश की। या तो मुझे अमान्य मार्कअप मिलेगा, लेकिन समाधान संकलन और काम करेगा, या मैं xmlns जोड़ूंगा: c = "clr-namespace: MyProject; विधानसभा = MyProject" और फिर मार्कअप प्रदर्शित होगा, लेकिन मुझे एक संकलन त्रुटि मिलेगी कि XML नामस्थान में टैग मौजूद नहीं है।

अंत में, मैंने समाधान के लिए एक नया WPF उपयोगकर्ता नियंत्रण लाइब्रेरी प्रोजेक्ट जोड़ा और अपने उपयोगकर्ता नियंत्रण को मुख्य प्रोजेक्ट से उस एक में स्थानांतरित कर दिया। संदर्भ जोड़ा और नई लाइब्रेरी को इंगित करने के लिए असेंबली को बदल दिया और अंत में मार्कअप काम किया और त्रुटि के बिना संकलित परियोजना।


1

मैं सभी उत्तरों से गुजरा और किसी ने मेरी मदद नहीं की। अंत में इसे स्वयं द्वारा हल करने में सक्षम था, इसलिए उत्तर प्रस्तुत करना क्योंकि यह दूसरों की मदद कर सकता है।

मेरे मामले में, समाधान में दो परियोजनाएं थीं, जिनमें से एक में मॉडल थे (प्रोजेक्ट और असेंबली का नाम मॉडल था ) और एक अन्य विचार और दृश्य मॉडल (हमारे सम्मेलन के अनुसार: प्रोजेक्ट, असेंबली का नाम और डिफ़ॉल्ट नाम स्थान वाले थे। मॉडल संचालक ) । Model.Monitor ने मॉडल परियोजना को संदर्भित किया।

Model.Monitor प्रोजेक्ट में, xaml में से एक में मैंने निम्नलिखित नामस्थान शामिल किए हैं: xmlns: मॉनिटर = "clr-namespace: Model.Monitor"

मुझे संदेह है कि MsBuild और Visual Studio तब गलत कर रहे थे क्योंकि वे विधानसभा 'मॉडल' में 'मॉनिटर' प्रकार खोजने की कोशिश कर रहे थे । हल करने के लिए मैंने निम्नलिखित कोशिश की:

  1. xmlns: मॉनिटर = "clr-नाम स्थान: Models.Monitor; विधानसभा =" - जो वैध है नाम स्थान में एक ही विधानसभा में प्रति के रूप में है अगर https://msdn.microsoft.com/en-us/library/ms747086(v=vs 0.110) .aspx
  2. यह भी स्पष्ट नाम स्थान की घोषणा की कोशिश की: xmlns: मॉनिटर = "clr-namespace: Model.Monitor; विधानसभा = Model.Monitor"

उपरोक्त में से किसी ने भी काम नहीं किया।

अंत में मैंने हार मान ली, और आसपास के काम के रूप में UserControl को स्थानांतरित करने के लिए मैं एक और नाम स्थान का उपयोग करने की कोशिश कर रहा था: 'मॉडलसम्पिटर' । मैं उसके बाद ठीक संकलन करने में सक्षम था।


1

मेरे मामले में मेरा नाम स्थान और वर्ग बिल्कुल एक जैसा था, इसलिए उदाहरण के लिए, मेरा एक नामस्थान था

firstDepth.secondDepth.Fubar

जिसमें अपने स्वयं के वर्ग होते हैं (उदाहरण के लिए firstDepth.secondDepth.Fubar.someclass)

लेकिन नाम स्थान में मेरा एक ' फ़ुबर ' वर्ग भी था

firstDepth.secondDepth

जो पाठकीय रूप से ऊपर फ़ुबर नामस्थान के समान है।

यह मत करो


1

मेरे मामले में परियोजना के ओब्जेक्ट डायरेक्टरी के तहत कुछ प्रेत फाइलों के कारण समस्या थी। निम्नलिखित ने मेरे लिए समस्या तय की:

  • स्वच्छ परियोजना
  • बाहर निकलें वी.एस.
  • rm -rf / obj / *
  • वीएस को फिर से बनाएं और पुनर्निर्माण करें

1

मुझे भी इससे बहुत परेशानी हो रही है! Intellisense मुझे नाम स्थान और सब कुछ पूरा करने में मदद करता है, लेकिन संकलक रोता है। मैंने वह सब कुछ आज़माया है जो मुझे इस और अन्य धागों में मिला है। हालाँकि मेरे मामले में अंत में जो मदद मिली वह कुछ इस तरह लिख रही थी:

xmlns:util="clr-namespace:LiveSpielTool.Utils;assembly="

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


0

VB.NET स्वचालित रूप से फ़ोल्डर संरचना के आधार पर Namespace जानकारी नहीं जोड़ता है क्योंकि यह C # में करता है। मुझे लगता है कि मैं आपके साथ उसी ट्यूटोरियल से गुजर रहा हूं (24 घंटे में खुद को डब्ल्यूपीएफ सिखाएं), और वीबी में भी यही रूपांतरण कर रहा हूं।

मैंने पाया कि आपको मैन्युअल रूप से NAMpace की जानकारी को XAML क्लास और XAML.VB दोनों कोडों के साथ जोड़ना होगा ताकि किताब में वर्णित नामस्थान का उपयोग करने में सक्षम हो सकें। फिर भी, VB असेंबली में Namespace को स्वचालित रूप से असाइन नहीं करता है जैसा कि VB में होता है।

यहां एक और लेख है जो दिखाता है कि इसे अपने प्रोजेक्ट टेम्प्लेट में कैसे शामिल किया जाए ताकि यह स्वचालित रूप से Namespace जानकारी का निर्माण करे - नया आइटम जोड़ते समय स्वचालित रूप से नाम स्थान जोड़ें


0

समाधान संपत्ति पृष्ठ में, विधानसभा का वह प्लेटफ़ॉर्म देखें जिसमें "UpdateatingMediaElement" हो और ऐसी अस्मिताएं जिनमें कोई भी सुपरक्लेसेस और इंटरफेस हों, जिसमें से "UpdatingMediaElement" उपवर्ग या अनुकरण शामिल हों। ऐसा प्रतीत होता है कि इन सभी विधानसभाओं का मंच "AnyCPU" होना चाहिए।


0

एक अन्य संभावित कारण: पोस्ट-बिल्ड ईवेंट बिल्ड फ़ोल्डर से प्रोजेक्ट DLL को निकाल रहा है।

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


0

ठीक है, इसलिए इनमें से कोई भी सुझाव मेरे लिए काम नहीं करता, दुर्भाग्य से। मैं अंततः इस मुद्दे को हल करने में सक्षम था। ऐसा लगता है कि विज़ुअल स्टूडियो नेटवर्क ड्राइव के साथ अच्छी तरह से नहीं खेलता है। मैंने साझा ड्राइव से प्रोजेक्ट को अपने स्थानीय पर स्थानांतरित करके और फिर से जोड़कर इस मुद्दे को हल किया। और कोई त्रुटि नहीं।


यह उत्तर कम से कम दो बार ऊपर दिया गया है।
pdschuller

0

ढेर में जोड़ना।

मेरा नाम WPF अनुप्रयोग का असेंबली नाम था, रेफर किए गए dll के समान असेंबली का नाम था। इसलिए सुनिश्चित करें कि आपकी किसी भी परियोजना में आपके पास विधानसभा नामों की नकल नहीं है।


0

मेरे पास एक नेटवर्क शेयर पर संग्रहीत समाधान था और हर बार जब मैंने इसे खोला तो मुझे अविश्वासित स्रोतों के बारे में चेतावनी मिलेगी। मैं इसे एक स्थानीय ड्राइव पर ले गया और "नाम स्थान मौजूद नहीं है" त्रुटि दूर भी चली गई।


0

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


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

0

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

मैं इसके बारे में मूर्खतापूर्ण महसूस करता हूं, लेकिन मेरे मामले में मैं उपयोगकर्ता नियंत्रण को तोड़ रहा था और परिणामस्वरूप संबंधित कक्षाओं में सभी प्रकार की त्रुटियां थी। जैसा कि मैं उन सभी को ठीक करने का प्रयास कर रहा था जो मैंने प्रश्न में त्रुटियों के साथ शुरू किए थे, यह एहसास नहीं था कि xaml इन संदर्भों को खोजने के लिए निर्मित असेंबली पर निर्भर करता है (सी # / vb कोड के विपरीत जो आपके निर्माण से पहले भी इसे काम कर सकता है)।


0

मैंने एक परियोजना के रूप में विधानसभा को जोड़ा था - पहले ddl को हटा दिया था जो विशेष रूप से dll के संदर्भों में जोड़ा गया था - जिसने यह किया।


0

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


0

मेरे मामले में, यह समस्या तब होगी जब wpf प्रोग्राम की आर्किटेकचर निर्भरता के साथ बिल्कुल समान नहीं है। मान लीजिए कि आपके पास एक निर्भरता है जो x64 है, और एक अन्य AnyCPU है। फिर यदि आप x64 चुनते हैं, तो AnyCPU dll का प्रकार "मौजूद नहीं है", अन्यथा x64 dll का प्रकार "मौजूद नहीं है"। आप सिर्फ उन दोनों का अनुकरण नहीं कर सकते।

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