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

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ć?

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.

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"

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.

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 .

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.

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.

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.

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.

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.

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.

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.

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ął.

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.

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.

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.

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ć.

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

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

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.

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

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”.

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.

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.

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.

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ął.

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

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).

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

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.

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.