Nazwa nie istnieje w błędzie przestrzeni nazw w XAML


126

Korzystanie z VS2012 w pracy z aplikacją VB.NET WPF. Mam prostą aplikację samouczkową MusicPlayer, której używam do nauki WPF. Konwertuję wersję C # samouczka na VB.NET krok po kroku.

Ma 2 klasy w aplikacji, które znajdują się w tej samej przestrzeni nazw. Jestem w stanie odwołać się do przestrzeni nazw w XAML, ale kiedy próbuję odwołać się do obiektu klasy w XAML, pojawia się błąd i nie mogę się skompilować.

Dziwne jest to, że IntelliSense działa dobrze zarówno przy odwoływaniu się do przestrzeni nazw za pośrednictwem tagu xmlns: c =, jak i podczas wpisywania obiektu klasy przy użyciu funkcji <c: Ale obiekt jest podkreślony, a błędy są generowane podczas próby kompilacji lub pracy w projektancie.

Pliki klas .vb znajdują się w folderze o nazwie \ Controls. Główna przestrzeń nazw projektu głównego celowo jest pozostawiona pusta. Klasa jest zakodowana w ten sposób ...

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

Xaml wygląda następująco

(przestrzeń nazw zdefiniowana w <Window >tagu

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

(obiekt zdefiniowany w a <Grid>)

  <c:UpdatingMediaElement Name="MyMediaElement" />

(wyświetlany błąd) Nazwa „UpdatingMediaElement” nie istnieje w przestrzeni nazw „clr-namespace: MusicPlayer.Controls”.

Nie wiesz, co jest nie tak lub jak to naprawić?


13
Ponowne uruchomienie wizualizacji działało dla mnie. (nigdy nie lekceważ siły restartu)
Falaque

1
Mała pomoc dla tych, którzy borykają się z tym: upewnij się, że Twoja klasa jest publiczna.
Borzh

Odpowiedzi:


234

Podczas pisania kodu wpf i VS powiedz, że „Nazwa ABCDE nie istnieje w przestrzeni nazw clr-namespace: ABC”. Ale możesz całkowicie pomyślnie zbudować projekt, jest tylko mała niedogodność, ponieważ nie widzisz projektowania interfejsu użytkownika (lub po prostu chcesz wyczyścić kod).

Spróbuj to zrobić:

  • W VS kliknij prawym przyciskiem myszy swoje rozwiązanie -> Właściwości -> Właściwości konfiguracji

  • Otworzy się nowe okno dialogowe, spróbuj zmienić konfiguracje projektu z Debug na Release lub odwrotnie.

Następnie ponownie zbuduj swoje rozwiązanie. To może rozwiązać twój problem.


4
To nadal się dzieje w Visual Studio 2015 Update 1. Twoje rozwiązanie zadziałało - dzięki!
Simon Smith

4
Być może nie, ale odkryłem, że zwykłe przełączanie między trybem debugowania i wydania na pasku narzędzi działa niezależnie.
ketura,

35
Potwierdzono w wersji 15.2 VS 2017 (26430.15) w lipcu 2017 r. Po prostu zmieniono menu rozwijane z debugowania na wydanie, skompilowano i zniknął błąd, zmieniono z powrotem i skompilowano, a błąd nadal zniknął.
Tedd Hansen

7
Wygląda na to, że VS17 jest szczególnie uparty - próbowałem zmienić Rel / Dbg, zmienić x64 / x86, usunąć foldery ShadowCache, ComponentCache, Bin / Obj, nadal mają "błędy", a projektant nie działa dla tej bardzo małej aplikacji (inne aplikacje z jak 50 widoków WPF działa dobrze). Stało się nagle i nie może odejść. Miałem ten problem wiele razy, ale pierwszy raz na VS17 i ​​nie mogę go teraz naprawić. Mimo to jest to najlepsza odpowiedź, ponieważ działała już wiele razy.
bokibeg

7
Uwielbiam sposób, w jaki wracam do tej odpowiedzi i już za nią zagłosowałem ... 2,5 roku temu.
Mathieu Guindon

51

Jeśli zestaw różni się od przestrzeni nazw, w której znajduje się Twoja klasa, musisz określić to jawnie.

dawny:-

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

1
Chociaż na początku wydawało się, że rozwiązał mój problem, nadal wyświetla ten sam błąd. Jednak teraz nie jestem już nawet w stanie zbudować rozwiązania.
Bouke

6
@bouke Wyczyść rozwiązanie i odbuduj je
Vasanth Sriram

Niesamowite, dzięki. To naprawdę pomogło
Keith

Zrobiło to dla mnie. Dziwne jest to, że konwertery znajdowały się w tym samym zestawie co plik xaml… Ale znajdowały się w innej przestrzeni nazw.
Jonathan Alfaro

Dzięki, brakowało zestawu.
Bagerfahrer

31

Widziałem, jak ten problem zniknął po wyczyszczeniu pamięci podręcznej cienia projektu Xaml. Miałem problem z Visual Studio 2015 Update 1.

W programie Visual Studio 2015 pamięć podręczna znajduje się tutaj:

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

Proces:

  1. Kliknij prawym przyciskiem myszy rozwiązanie w Eksploratorze rozwiązań i wybierz „Czyste rozwiązanie”
  2. Zamknij program Visual Studio
  3. Usuń folder ShadowCache
  4. Ponownie otwarto projekt programu Visual Studio
  5. Odbuduj rozwiązanie

I voila, koniec z błędami przestrzeni nazw.


7
Niestety, dla mnie nic to nie zmieniło. Nadal radzę sobie z tym irytującym po prawie całym roku. : /
Khale_Kitha

3
Dzięki! To zakończyło się dla mnie pracą. To smutne, że te sztuczki są nadal konieczne w VS15
Ocab19

4
Możesz użyć% localappdata% \ Microsoft \ VisualStudio \ 14.0 \ Designer \, aby natychmiast przejść do właściwego folderu
Maxence

1
Posiadanie projektanta, który działa tylko wtedy, gdy tworzysz rozwiązanie, jest okropne. Wyobraź sobie, że mówisz projektantowi samochodu, aby zbudował cały samochód, zanim zobaczysz projekt.
Paul McCarthy

26

W moim przypadku było to spowodowane innymi błędami kompilacji . Po usunięciu innych błędów ten pozornie powiązany błąd został również usunięty z listy. Szczególnie błędy na dole listy błędów i na ostatnio zmienionych stronach.

Nie zwracaj więc uwagi bezpośrednio na ten błąd i skup się na początku na innych błędach .


2
Zauważ, że wykonanie kompilacji / kompilacji rozwiązało ten problem za mnie, mimo że nie miałem żadnych innych niepowiązanych błędów kompilacji. Wygląda na to, że okna XAML nie zawsze są świadome nowych klas, dopóki nie wykonasz kompilacji.
HK1

1
To była najlepsza rada dla mnie, ale jako @ HK1 czasami nie ma innych wpisów na liście błędów kompilatora ... nie ma błędów na liście, ale są inne błędy. Aby je zobaczyć, skomentuj lub usuń linie oznaczone błędem przestrzeni nazw, skompiluj ponownie, a zobaczysz inne błędy kompilatora. Zmodyfikuj je, a wiersze przed zaznaczeniem błędu przestrzeni nazw będą w porządku po ich przywróceniu.
SERWare

Usunąłem metodę w kodzie, która była nadal przywoływana w XAML. Po usunięciu odniesienia ten błąd zniknął.
YarsRevenge 13

23

Spróbuj zmienić platformę docelową kompilacji na x86 i skompilować projekt.

Zauważyłem przez Subversion, że najwyraźniej zmieniłem docelową platformę kompilacji projektu na x64. To była jedyna zmiana, jaką wprowadziłem. Po wprowadzeniu tej zmiany kod działał przez chwilę, zanim zaczął wyświetlać ten sam błąd, który wystąpił. Zmieniłem platformę docelową na x86, aby przetestować i nagle mój projektant znów zaczął pracować. Następnie zmieniłem go z powrotem na x64 i problem całkowicie zniknął. Podejrzewam, że projektant buduje jakiś buforowany kod w x32 i zmiana platformy kompilacji x64 przerywa go, gdy wprowadzasz zmiany w kodzie.


Miałem to ponownie i mogę potwierdzić, że to rozwiązuje problem. Możesz przełączyć się z powrotem na x64 po skompilowaniu go w x86.
teynon

U mnie też to zadziałało w VS 2012 ... po godzinach prób wymyślenia czegoś logicznego. Dzięki, Tom!
Bryan Greenway

Przełączenie na x86 iz powrotem na x64 rozwiązało problem tutaj, więc dziękuję za zainspirowanie mnie do spróbowania. Zamknąłem nawet VS, usunąłem bin i obj i przebudowałem, wraz z innymi sugestiami, i nic nie pomogło aż do tego.
Grault

Tak, zadziałało to również w przypadku VS2015 Update 2. Jednak konieczne było ponowne załadowanie moich zewnętrznych plików DLL i również ich odbudowanie.
SezMe

Z VS2015U2 nadal mam ten problem w x64. Działa świetnie w każdym procesorze. Przełączanie się tam iz powrotem nie działa dla mnie.
DaleyKD

7

Nie wiem, czy to pomoże komukolwiek innemu

Jestem nowy w WPF i nadal jestem nowicjuszem w VB.net - więc założyłem, że otrzymywanie tego błędu jest spowodowane tym, że robię szczyt głupi ... przypuśćmy, że naprawdę! Udało mi się go pozbyć, przenosząc projekt z dysku współdzielonego na jeden z moich dysków lokalnych. Błąd zniknął, projekt kompiluje się doskonale, żadnych dalszych problemów - na razie. Wygląda na to, że VS2015 nadal ma problemy z projektami przechowywanymi na dysku współdzielonym.


2
Tak było w przypadku mnie, przeniosłem go do mojego vm (na którym rozwijam) i bum nie ma problemów. Dzięki!
Mario Tacke

Wydaje się, że tak było w przypadku mnie. Przeniesienie ich na dysk lokalny (zamiast udziału sieciowego - tak jak zostało to skonfigurowane przez Parallels w celu połączenia systemu plików Mac i Windows) rozwiązało problem.
ckittel

7

Może inne rozwiązanie w przypadku kompilacji projektu, ale wyświetlany jest błąd XAML:

  1. W eksploracji rozwiązania w węźle projektu, który zawiera plik XAML
  2. Kliknij prawym przyciskiem myszy projekt i wybierz „Zwolnij projekt”
  3. Kliknij projekt prawym przyciskiem myszy i wybierz opcję „Wczytaj ponownie projekt”. Upewnij się, że projekt jest nadal wybrany jako „projekt startowy”. Jeśli nie :
  4. Kliknij projekt prawym przyciskiem myszy i wybierz „Ustaw jako projekt startowy”

Nie ma potrzeby przebudowywania ani zamykania Visual Studio.


6

Jezu ... To nadal jest problem pięć lat później w Visual Studio 2017. Ponieważ jestem nowy w WPF, byłem pewien, że problem dotyczy mnie, ale nie, wszystko zostało skompilowane i działało poprawnie.

Próbowałem odbudować, wyczyścić i odbudować, przełączać między wyjściem x86 / x64, restartować Windows, czyścić folder ShadowCache, dodawać "; assembly = {nazwa mojego głównego zestawu}" do deklaracji przestrzeni nazw XML, nic nie działało! Jedyna rzecz, która zrobiła:

Umieść moją statyczną klasę poleceń (w moim przypadku chodziło o to, aby projekt odkrył moje polecenia WPF) w osobnym zestawie i zamiast tego zmienić nazwę zestawu na ten.


2

Miałem ten sam problem iw moim przypadku w widoku projektu znaczników poprosiłem mnie o przebudowanie rozwiązania i nie pokazał mi układu formularza z tym komunikatem: Design view is unavailable for x64 and ARM target platformslub Build the Project to update Design view.

Nie można go rozwiązać przez odbudowanie rozwiązania (ani widok projektu, ani błąd „Nazwa nie istnieje w przestrzeni nazw”)

Myślę, że to dlatego, że bawiłem się ustawieniami w Rozwiązanie -> Właściwości> Właściwości konfiguracji

W końcu rozwiązałem problem z 2 zadaniami:

  1. Zaznaczenie wszystkich pól wyboru w kolumnie Kompilacja strony: Rozwiązanie -> Właściwości -> Właściwości konfiguracji
  2. Zmiana konfiguracji rozwiązania z debugowania na wydanie lub odwrotnie.

Myślę, że to błąd w Visual Studio2012 Update 2.


2

Ten sam problem nęka Visual Studios 2013, dodatek Service Pack 4. Wypróbowałem go również z Visual Studios 2015 Preview z tymi samymi wynikami.

To tylko ograniczenie wizualizatora WPF, którego zespół Visual Studios nie naprawił. Jako dowód, budowanie w trybie x86 włącza wizualizator, a budowanie w trybie x64 wyłącza go.

O dziwo, intelisense działa dla Visual Studios 2013, Service Pack 4.


2

Miałem ten problem ostatnio przy użyciu VS 2015 Update 3 dla mojego projektu WPF w .NET 4.6.2. Kopia mojego projektu znajdowała się w folderze sieciowym , przeniosłem ją lokalnie i to rozwiązało problem.

Może to rozwiązać inne problemy, ponieważ wygląda na to, że VS 2015 nie lubi ścieżek sieciowych. Innym problemem, który jest dla nich dużym problemem, jest synchronizacja repozytoriów git, jeśli mój projekt znajduje się na ścieżce sieciowej, również rozwiązany przez przeniesienie go lokalnie.


1

Wygląda na to, że ten problem można rozwiązać różnymi „sztuczkami”.

W moim przypadku budowałem / przebudowywałem / czyściłem całe rozwiązanie, a nie tylko projekt, nad którym pracowałem w ramach rozwiązania. Po kliknięciu „Kompiluj [mój projekt]” komunikat o błędzie zniknął.


1

Spróbuj zweryfikować odwołania do zestawów. Jeśli masz żółty wykrzyknik na referencjach projektu, oznacza to problem i otrzymasz wszelkiego rodzaju błędy.

Jeśli wiesz, że odwołanie do projektu jest poprawne, sprawdź platformę docelową. Na przykład posiadanie projektu wykorzystującego framework 4.5 odwołuje się do projektu z frameworkiem 4.5.2 nie jest dobrym połączeniem.


Innymi słowy, wersja .NET Framework projektu nie może być starsza niż wersja .NET Framework projektu, do którego się odwołuje.
icernos

1

Rozwiązaniem dla mnie było odblokowanie bibliotek DLL zestawu. Otrzymane komunikaty o błędach nie wskazują tego, ale projektant XAML odmawia załadowania tak zwanych zestawów „piaskownicy”. Możesz to zobaczyć w oknie wyników podczas kompilacji. Biblioteki DLL są blokowane, jeśli są pobierane z Internetu. Aby odblokować biblioteki DLL zestawów innych firm:

  1. Kliknij prawym przyciskiem myszy plik DLL w Eksploratorze Windows i wybierz Właściwości.
  2. U dołu karty Ogólne kliknij przycisk lub pole wyboru „Odblokuj”.

Uwaga: Odblokuj biblioteki DLL tylko wtedy, gdy masz pewność, że są bezpieczne.


To zadziałało dla mnie - pobrałem projekt z Dropbox i otrzymywałem błąd. Musiałem też usunąć ShadowCache
geometryczny

1

W moim przypadku kontrola użytkownika została dodana do głównego projektu. Próbowałem różnych rozwiązań powyżej bezskutecznie. Albo dostałbym Invalid Markup, ale rozwiązanie by się skompilowało i działało, albo dodałbym xmlns: c = "clr-namespace: MyProject; assembly = MyProject", a następnie pojawi się znacznik, ale otrzymam błąd kompilacji, że tag nie istnieje w przestrzeni nazw XML.

Na koniec dodałem nowy projekt biblioteki kontroli użytkownika WPF do rozwiązania i przeniosłem kontrolkę użytkownika z projektu głównego do tego. Dodano odniesienie i zmieniono zestaw, aby wskazywał nową bibliotekę, a na koniec znaczniki działały, a projekt został skompilowany bez błędów.


1

Przejrzałem wszystkie odpowiedzi i żadna mi nie pomogła. W końcu udało mi się go rozwiązać samodzielnie, więc przedstawiłem odpowiedź, która mogłaby pomóc innym.

W moim przypadku rozwiązanie miało dwa projekty, jeden zawierający modele (powiedzmy, że nazwa projektu i zespołu to Modele ), a drugi zawierający widoki i modele widoków (zgodnie z naszą konwencją: projekt, nazwa zespołu i domyślna przestrzeń nazw to Modele.Monitor ) . Projekt Models.Monitor w odniesieniu do modeli.

W projekcie Models.Monitor w jednym z xaml umieściłem następującą przestrzeń nazw: xmlns: monitor = "clr-namespace: Models.Monitor"

Podejrzewam, że wtedy MsBuild i Visual Studio zawierały błędy, próbując znaleźć typ „Monitor” w zestawie „Modele” . Aby rozwiązać problem, spróbowałem następujących rozwiązań:

  1. xmlns: monitor = "clr-namespace: Models.Monitor; assembly =" - co jest poprawne, jeśli przestrzeń nazw znajduje się w tym samym zestawie, co https://msdn.microsoft.com/en-us/library/ms747086(v=vs .110) .aspx
  2. wypróbowano również jawną deklarację przestrzeni nazw: xmlns: monitor = "clr-namespace: Models.Monitor; assembly = Models.Monitor"

Żadne z powyższych nie zadziałało.

W końcu się poddałem i jako obejście przeniosłem UserControl, którego próbowałem użyć, do innej przestrzeni nazw: „ModelsMonitor” . Po tym udało mi się dobrze skompilować.


1

W moim przypadku przestrzeń nazw i klasa pisane były dokładnie tak samo, więc na przykład jedna z moich przestrzeni nazw była

firstDepth.secondDepth.Fubar

który zawiera własne klasy (np. firstDepth.secondDepth.Fubar.someclass)

ale miałem też klasę „ Fubar ” w przestrzeni nazw

firstDepth.secondDepth

który tekstowo rozwiązuje to samo, co powyższa przestrzeń nazw Fubar.

Nie rób tego


1

W moim przypadku problem był spowodowany niektórymi plikami phantom w katalogu obj projektu. Następujące rozwiązania rozwiązały problem dla mnie:

  • Czysty projekt
  • Zamknij VS
  • rm -rf / obj / *
  • Wywołaj VS i przebuduj

1

Ja też mam z tym duży problem! Intellisense pomaga mi uzupełnić przestrzeń nazw i wszystko inne, ale kompilator płacze. Próbowałem wszystkiego, co znalazłem w tym i innych wątkach. Jednak w moim przypadku pomogło w końcu napisanie czegoś takiego:

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

Pozostawienie nazwy zestawu pustej. Nie mam pojęcia dlaczego. Ale zostało tutaj wspomniane. Muszę dodać, że opracowuję zespół, więc atrybut zespołu może mieć sens. Ale wpisanie nazwy zespołu nie zadziałało. Bardzo dziwne.


0

VB.NET nie dodaje automatycznie informacji o przestrzeni nazw na podstawie struktury folderów, tak jak ma to miejsce w C #. Myślę, że przechodzę przez ten sam samouczek co Ty (Naucz się WPF w 24 godziny) i robię tę samą konwersję do VB.

Odkryłem, że musisz ręcznie dodać informacje o przestrzeni nazw zarówno do klasy XAML, jak i do kodu XAML.VB, aby móc używać przestrzeni nazw zgodnie z opisem w książce. Nawet wtedy VB nie przypisuje automatycznie przestrzeni nazw do zestawu, tak jak ma to miejsce w VB.

Jest tutaj inny artykuł, który pokazuje, jak uwzględnić to w szablonach projektu, aby automatycznie budować informacje o przestrzeni nazw - Automatycznie dodawaj przestrzeń nazw podczas dodawania nowego elementu


0

Na stronie właściwości rozwiązania sprawdź platformę zestawu zawierającego element „UpdatingMediaElement” oraz zestawy zawierające dowolne nadklasy i interfejsy, z których podklasy lub implementuje element „UpdatingMediaElement”. Wydaje się, że platformą wszystkich tych zespołów musi być „AnyCPU”.


0

Inna możliwa przyczyna: Zdarzenie po kompilacji powoduje usunięcie biblioteki DLL projektu z folderu kompilacji.

Aby wyjaśnić: projektant WPF może zgłosić „Nazwa XXX nie istnieje w przestrzeni nazw ...”, nawet jeśli nazwa istnieje w przestrzeni nazw, a projekt jest kompilowany i działa poprawnie, jeśli zdarzenie po kompilacji usuwa bibliotekę DLL projektu z folder kompilacji (bin \ Debug, bin \ Release itp.). Mam z tym osobiste doświadczenie w programie Visual Studio 2015.


0

Ok, więc niestety żadna z tych wskazówek nie zadziałała. W końcu udało mi się rozwiązać problem. Wygląda na to, że Visual Studio nie radzi sobie dobrze z dyskami sieciowymi. Rozwiązałem ten problem, przenosząc projekt z dysku współdzielonego na mój lokalny i ponownie skompilowałem. Żadnych więcej błędów.


Ta odpowiedź jest udzielona co najmniej dwa razy powyżej.
pdschuller

0

Dodawanie do stosu.

Moja była nazwa zestawu aplikacji WPF była taka sama jak nazwa zestawu dll, do którego się odwołuje. Dlatego upewnij się, że nie masz zduplikowanych nazw zespołów w żadnym ze swoich projektów.


0

Miałem rozwiązanie przechowywane w udziale sieciowym i za każdym razem, gdy je otwierałem, otrzymywałem ostrzeżenie o niezaufanych źródłach. Przeniosłem go na dysk lokalny i błąd „przestrzeni nazw nie istnieje” również zniknął.


0

Spróbuj także kliknąć prawym przyciskiem myszy projekt-> właściwości i zmień platformę docelową na Dowolny procesor i przebuduj, wtedy będzie działać. To zadziałało dla mnie


1
Twoja sugestia jest znaczącą zmianą, która może nawet nie być możliwa dla OP, jeśli są one skierowane do określonego środowiska. Tak czy inaczej, jest bardzo mało prawdopodobne, aby był on przyczyną problemu, a jeśli to rozwiązałoby problem za Ciebie, sugerowałbym, że Twoim rzeczywistym problemem było niedopasowanie konfiguracji projektu, co objawiałoby się na wiele różnych sposobów w przedstawionym tutaj problemie.
LordWilmore

0

Ten problem może być również spowodowany, jeśli zestaw, do którego się odwołujesz, nie jest faktycznie skompilowany. Na przykład, jeśli Xaml znajduje się w Assembly1 i odwołujesz się do klasy również w Assembly1, ale ten zestaw zawiera błędy i nie jest kompilowany, zostanie wyświetlony ten błąd.

Czuję się głupio z tego powodu, ale w moim przypadku rozrywałem kontrolę użytkownika i w rezultacie miałem różnego rodzaju błędy w powiązanych klasach. Kiedy próbowałem je wszystkie naprawić, zacząłem od omawianych błędów, nie zdając sobie sprawy, że xaml polega na wbudowanych zestawach, aby znaleźć te odwołania (w przeciwieństwie do kodu C # / vb, który może to rozwiązać nawet przed budowaniem).


0

Dodałem zestaw jako projekt - najpierw usunąłem plik ddl, który został dodany specjalnie do odniesień do biblioteki dll - to zrobiło to.


0

Cały czas mam ten problem. Moje widoki znajdują się w projekcie biblioteki niestandardowych formantów WPF (wariant w bibliotece klas). Mogę odwoływać się do gotowych zestawów, ale nie mogę odwoływać się do żadnego kodu w innym projekcie tego samego rozwiązania. Gdy tylko przeniosę kod do tego samego projektu co XAML, zostanie on rozpoznany.


0

W moim przypadku ten problem wystąpi, gdy architektura programu wpf nie jest dokładnie taka sama z zależnościami. Załóżmy, że masz jedną zależność x64, a inną jest AnyCPU. Następnie, jeśli wybierzesz x64, typ dll AnyCPU „nie istnieje”, w przeciwnym razie typ dll x64 będzie „nie istnieje”. Po prostu nie możesz emilować ich obu.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.