nazwa <…> nie istnieje w przestrzeni nazw clr-namespace <…>

Mam małą aplikację WPF, która kiedyś dobrze się kompilowała, ale już nie jest. Nie mogę powiedzieć, w którym momencie przestał się budować. Po prostu działało dobrze jednego dnia, a następnego nie.

Oto struktura projektu:

Nie ma innych projektów ani odniesień zewnętrznych poza standardowymi bibliotekami dll .net.

Oto kontrola użytkownika, z której pochodzi problem:

<UserControl x:Class="TimeRecorder.HistoryUserControl"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
         xmlns:local="clr-namespace:TimeRecorder.ViewModel"
         xmlns:framework="clr-namespace:TimeRecorder.Framework"
         mc:Ignorable="d" Height="Auto" Width="Auto" Padding="5">
<UserControl.Resources>
    <local:HistoryViewModel x:Key="ViewModel"/>
    <framework:BoolToColorConverter x:Key="ColorConverter"/>
</UserControl.Resources>
<StackPanel DataContext="{StaticResource ViewModel}">

A oto błąd, który otrzymuję:

Zwróć uwagę, że nie jest to tylko jeden plik na zrzucie ekranu, ale wszystkie odniesienia, które dodaję w podobny sposób w xaml we wszystkich plikach kontroli użytkownika / okien w tym projekcie.

Więc plik tam jest, przestrzeń nazw w pliku jest poprawna, przestrzeń nazw / nazwa klasy w pliku xaml jest (w moim rozumieniu) poprawna. Dostaję intelisense, kiedy piszę xaml, więc znajduje pliki w porządku, ale nie podczas kompilacji.

Najpopularniejszym rozwiązaniem tego problemu w innych postach była wersja platformy .net. Obecnie jest ustawiony na .Net Framework 4 zarówno dla mojego projektu głównego, jak i testowego. Pełna wersja, a nie profil klienta.

Oto, co myślę, że zawiodłem: w menedżerze konfiguracji oba projekty mają platformę ustawioną na Dowolny procesor, ale w pewnym momencie, próbując rozwiązać ten problem, zauważyłem, że główny projekt był ustawiony na x86, a projekt testowy na Any PROCESOR. Więc dodałem ręcznie Any CPU dla głównego projektu w menedżerze konfiguracji. Jednak szczerze mówiąc nie wiem, czy zrobiłem to poprawnie, czy nawet powinienem to zrobić. Więc jako dodatkowe pytanie, czy jest sposób, aby zresetować menedżera konfiguracji do jego domyślnego stanu? Czy będzie to miało coś do powiedzenia na temat głównego problemu? Nie wiem, czy główny projekt był zawsze ustawiony na x86, czy nie, czy też w jakiś sposób zmieniłem go na x86, a potem się zepsuł. Jak wspomniano, ten projekt przez chwilę dobrze się kompilował.

Za każdym razem, gdy mi się to przytrafiło, po prostu ponownie uruchamiałem Visual Studio, przebudowywałem rozwiązanie i działało dobrze ... nie mogę powiedzieć dlaczego

Oprócz komunikatu „nie istnieje w przestrzeni nazw” otrzymałem również komunikat od projektanta, że ​​nie może wyświetlić okna dla obiektów docelowych x64 i ARM.

Właśnie odkryłem, że przełączenie kompilacji na tryb x86, wykonanie przebudowy, a następnie przełączenie z powrotem do trybu x64 i ponowne kompilowanie rozwiązuje [oba] problemy.

Zwykłe przebudowanie rozwiązania x64 nic nie dało.

Zauważyłem, że pomogło (zwłaszcza jeśli ten błąd występuje w App.xaml), to skomentowanie odniesienia (a), które sprawiają kłopoty, odbudowanie, a następnie odkomentowanie. Myślę, że to pozwala całemu projektowi na rzeczywistą kompilację zamiast zatrzymywania kompilacji w przypadku błędu.

Z tego, co wiem, aplikacja próbuje zbudować pliki w określonej kolejności, więc jeśli App.xamllub przypuszczalnie jakiekolwiek inne błędy pliku klasy w odwołaniu, plik, który powoduje błąd, nie został poprawnie skompilowany, stąd dlaczego tak się nie dzieje Nie znajduję pliku w tej przestrzeni nazw.

To właśnie zadziałało w przypadku mnie w programie Visual Studio 2012 (aktualizacja 3).

• Uruchom ponownie program Visual Studio
• Dodaj bieżący zestaw do deklaracji przestrzeni nazw xmlns:framework="clr-namespace:TimeRecorder.Framework;assembly=MyAssembly
• Build -> Build Solution

Przebuduj swoje rozwiązanie (czasami wyczyść, a potem kompilacja działa lepiej). Następnie spójrz na swoją listę błędów, przewiń na sam dół i najprawdopodobniej wskaże błąd, który nie pozwala na kompilację zestawu, a kompilator XAML najprawdopodobniej używa buforowanej wersji zestawu, a nie nowej, którą znaczy budować.

Miałem podobny problem. W moim przypadku musiałem wykonać następujące czynności

• usuń znaczniki odwołujące się z XAML (w tym przykładzie <local:HistoryViewModel x:Key="ViewModel"/> )
• zbuduj klasę (w tym przykładowym pliku, który zawiera HistoryViewModel klasę)
• Po skompilowaniu dodaj znaczniki odwołujące się do xaml
• zbuduj ponownie

Powyższa metoda zadziałała dla mnie.

Co mi pomogło: - Przełącz konfigurację rozwiązania z debugowania na wydanie - Przełącz konfigurację z powrotem z wersji na debugowanie

Dziś napotkaliśmy ten problem dzięki Visual Studio 2017 Community Edition. Wypróbowałem wszystkie sugestie tutaj (zresetuj VS 2017, zmieniono z x64 na x32 iz powrotem itp.) I z innych źródeł bezskutecznie. Intellisense wie, że wszystko tam jest, ale za każdym razem otrzymywałem ten sam błąd.

W każdym razie moja poprawka okazała się bardzo prosta ... czyż nie zawsze, gdy spędzasz kilka godzin nad problemem!

Zasadniczo zrobiłem następujące ...

1. Usuń szkodliwy kod z pliku XAML (tylko 3 linie w moim przypadku)
2. Utwórz projekt, aby uzyskać pomyślną kompilację
3. W tym momencie układ magicznie pojawił się w oknie projektanta, co było dobrym znakiem!
4. Ponownie wstawiłem kod, który usunąłem w punkcie 1., w tym xmlns: entry
5. W tym momencie nie powinieneś dostać żadnych niebieskich zawijasów ... miejmy nadzieję
6. Zbuduj projekt ponownie

Wygląda na to, że po pomyślnej kompilacji musi zresetować „coś” w VS i / lub w zestawie. Po udanej kompilacji spróbuj ponownie wstawić kod.

Żadne z rozwiązań nie zadziałało. Naprawiłem to w ten sposób:

• Usuń bibliotekę dll z referencji
• Pobierz kod źródłowy biblioteki (zamiast tylko pliku dll)
• Zbuduj projekt biblioteki, aby uzyskać nowy plik dll
• Dodaj nowy plik dll do referencji głównego projektu

Czy ten problem kręcił się w kółko i tracił kilka godzin. Przeniosłem osobną bibliotekę dll kontroli użytkownika do projektu, więc została skompilowana w projekcie, a nie dll, do którego istnieją odwołania. To zepsuło cały projekt, więc przeszedłem przez skrupulatne sprawdzenie wszystkich przestrzeni nazw, ścieżek i nazw plików. Próbowano usunąć pliki obj, przełączać między wydaniem a debugowaniem, między x86 i AnyCPU. Otwieranie, zapisywanie wszystkiego, rekompilacja nadal nie sprawia radości

Pamiętaj, że wcześniej miałem podobny problem, błąd oznaczony w VS2013 nie był bezpośrednio związany z miejscem, w którym musiałem zmodyfikować XAML, ale używając

x:Name="myControl"

na wszystkich kontrolkach zamiast

Name="myControl"

naprawione.

Zmieniłem Target Framework Moja aplikacja z „.Net Framework 4.5” na „.Net Framework 4.6” i zadziałało!

Oto dziwny przykład podobnej rzeczy:

<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
         xmlns:controls="clr-namespace:Gtl.Ui.Controls"
         mc:Ignorable="d" 
         d:DesignHeight="120" d:DesignWidth="120"             
         Background="Transparent">
...
</UserControl>

będzie się kompilować (VS2013).

<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
         xmlns:controls="clr-namespace:Gtl.Ui.Controls"
         mc:Ignorable="d" 
         d:DesignHeight="120" d:DesignWidth="120"             
         Background="Transparent"
         IsVisibleChanged=onIsVisibleChanged>
...
</UserControl>

generuje błąd „nie znaleziono typu Ui w Gtl.Ui.Gtl” (i zapewniam, że metoda obsługi istnieje w kodzie). Sposób obejścia problemu polega na dodaniu procedury obsługi w konstruktorze klasy, ale daj spokój Microsoft, wtf się dzieje?

Napotkałem ten sam problem, gdy próbowałem wywołać przestrzeń nazw w XAML. pokazywał, że klasa nie jest dostępna w przestrzeni nazw. Szukałem dużo. Wreszcie stwierdziłem, że ten problem dotyczy VS. Używam VS 2013. Próbowałem wykonać poniższe kroki:

1. Kompiluj -> Menedżer konfiguracji -> Platforma aktywnych rozwiązań -> Zmieniono na x64 i x86 oraz dowolny procesor.
2. Zamknąłem VS i otworzyłem ponownie.

3. Zmiana

   xmlns:VM="clr-namespace:MyFirstAppViewModel"
   

   do

   xmlns:VM="clr-namespace:MyFirstAppViewModel;assembly=ViewModel"
   

Ten błąd zwykle występuje, gdy projekt nie został pomyślnie skompilowany podczas ostatniej kompilacji.

Krok 1) Najpierw usuń cały błąd powodujący kod z pliku XAML lub .cs i skompiluj i uruchom projekt, naciskając klawisz F5.

Krok 2) Dodaj jeden po drugim dodaj swój błąd powodujący kod w XAML.

• Polecam zmienić nazwę, x:Key="ViewModel"może jest usterka
• a jeśli wpiszesz, local:czy VS ci pokaże HistoryViewModel?
• sprawdź też, czy tak Classjestpublic

Po prostu uruchom analizę kodu z menu Build

Zauważyłem, że uruchomienie polecenia „Uruchom analizę kodu” odbudowuje wszystko i prawie zawsze rozwiązuje problem (kliknij prawym przyciskiem myszy projekt> Analiza> Uruchom analizę kodu). To również generalnie przebudowuje pliki zasobów, aby można było znaleźć łańcuchy itp.

Wypróbowałem wszystkie rozwiązania w tym wątku, ale żadne nie działało. Okazało się, że jest to spowodowane konfiguracją rozwiązania. Moja aplikacja WPF została skonfigurowana do kompilowania dla platformy X64 z powodu niektórych natywnych zależności, które tego wymagają, ale konfiguracja rozwiązania była nadal ustawiona na AnyCPU dla projektu. Utworzenie nowej konfiguracji X64 dla projektu w menedżerze konfiguracji rozwiązania umożliwiło projektantowi XAML wreszcie rozpoznanie mojego typu i przestrzeni nazw.

Przed dodaniem przestrzeni nazw do pliku .xaml upewnij się, że nie występują żadne błędy kompilacji z powodu istniejącego kodu.

Gdy wszystkie testy kompilacji zakończą się pomyślnie, odbuduj rozwiązanie i spróbuj dodać wymaganą przestrzeń nazw, aby użyć jej klasy lub właściwości.

To dla mnie powracający problem. Pewnego razu znalazłem rozwiązanie, patrząc na kartę Ostrzeżenie . Był to problem z wersją platformy .NET i zawierał następujące informacje:

Ostrzeżenie 9 Nie można rozwiązać podstawowego odwołania „myDll”, ponieważ zostało ono utworzone w oparciu o środowisko „.NETFramework, Version = v4.5.2”. To jest nowsza wersja niż aktualnie docelowa platforma „.NETFramework, Version = v4.0”.

Występuje usterka z ich buforowaniem układów obiektów. Jeśli coś zostanie przemianowane lub przeniesione, zostanie utracone. To, co ogólnie działa dla mnie, to utworzenie zupełnie nowej klasy i skopiowanie całego starego kodu, uruchomienie go na nowej klasie, a następnie usunięcie oryginalnej klasy. Czasami po uruchomieniu go z nową nazwą klasy możesz spróbować zmienić nazwę z powrotem na oryginalną nazwę (ale zwykle nie)

Używałem xmlns: local = "using: MyRootNamespace.ChildNamespace" w nagłówku pliku .xaml i zmieniłem go na xmlns: local = "clr-namespace: MyRootNamespace.ChildNamespace" ... cóż, po prostu pozwoliłem inteligencji zrobić praca i zadziałała.

Problem polega na tym, że podczas tworzenia celu x86 ścieżka wyjściowa dla określonego projektu jest ustawiana na bin \ x86 \ Debug. Wygląda na to, że mieszanka Expression w ogóle tego nie lubi. Wydaje się, że interesuje go tylko zawartość bin \ Debug.

Jeśli zmieniłeś ścieżki wyjściowe dla projektu x86 na przykład na bin \ debug, jestem pewien, że okaże się, że będzie działać. Cóż, i tak na mnie działa :)

Struktura docelowa dodawanego pliku .dll powinna być taka sama jak struktura docelowa aplikacji.

Miałem ten sam problem. Otrzymujesz ten błąd, ale nadal możesz pomyślnie zbudować projekt. Niedogodność polega na tym, że nie widzisz projektu interfejsu użytkownika (lub po prostu chcesz wyczyścić kod i usunąć irytujące, kręcone linie). Przeczytaj wiele postów, wypróbowałem kilka rzeczy, ale śledzenie działa jak urok.

Wypróbowano to w programie Visual Studio 2019:

Kliknij prawym przyciskiem myszy rozwiązanie -> Właściwości -> Właściwości konfiguracji, a następnie zmień konfiguracje projektu z debugowania na wydanie lub odwrotnie.

Następnie odbuduj swoje rozwiązanie. Może rozwiązać twój problem.