Otrzymanie „nie można znaleźć nazwy typu lub przestrzeni nazw”, ale wszystko wydaje się w porządku?

Dostaję:

Nie można znaleźć typu lub nazwy przestrzeni nazw

błąd aplikacji C # WPF w VS2010. Ten obszar kodu kompilował się dobrze, ale nagle pojawia się ten błąd. Próbowałem usunąć odwołanie do projektu i usinginstrukcję, zamknąć VS2010 i uruchomić ponownie, ale nadal mam ten problem.

Wszelkie pomysły, dlaczego tak się dzieje, gdy wydaje się, że robię właściwą rzecz w odniesieniu do referencji i usingoświadczeń?

Zauważyłem również w VS2010, że inteligencja dla tej przestrzeni nazw działa dobrze, więc wygląda na to, że VS2010 ma odwołanie do projektu i widzi przestrzeń nazw z jednej strony, ale podczas kompilacji nie widzisz?

Może to wynikać z niezgodności wersji .Net Framework między dwoma projektami.

Może się to zdarzyć na dwa sposoby:

1. projekt profilu klienta odwołujący się do projektu pełnego frameworka; lub
2. starsza wersja frameworka skierowana na nowszą wersję frameworka

Stanie się tak na przykład, gdy aplikacja jest ustawiona na ramę .NET 4 Client Profile, a projekt, do którego się odwołuje, jest ukierunkowany na pełną ramę.

Aby to wyjaśnić:

• Projekt A jest ukierunkowany na strukturę profilu klienta
• Projekt A odnosi się do Projektu B
• Projekt B jest ukierunkowany na pełne ramy

Rozwiązaniem w tym przypadku jest albo uaktualnienie docelowego szkieletu aplikacji (Projekt A), albo obniżenie docelowego zestawu referencyjnego (Projekt B). Aplikacja z pełnym szkieletem może odwoływać się do zestawu szkieletu profilu klienta lub z niego korzystać, ale nie odwrotnie (profil klienta nie może odwoływać się do zestawu docelowego pełnego szkieletu).

Zauważ, że ten błąd można również uzyskać podczas tworzenia nowego projektu w VS2012 lub VS2013 (który używa .Net 4.5 jako domyślnej struktury) i:

• projekty referencyjne używają .Net 4.0 (jest to powszechne, gdy migrujesz z VS2010 do VS2012 lub VS2013, a następnie dodajesz nowy projekt)

• projekty, do których istnieją odniesienia, używają wyższej wersji, tj. 4.5.1 lub 4.5.3 (przekierowałeś istniejące projekty do najnowszej wersji, ale VS nadal tworzy nowe projekty skierowane do wersji 4.5, a następnie odwołujesz się do starszych projektów z nowy projekt)

Ponowna instalacja pakietów nuget załatwiła sprawę. Po tym, jak zmieniłem wersje .NET Framework, aby były zsynchronizowane dla wszystkich projektów, niektóre pakiety nuget (szczególnie Entity Framework) były nadal instalowane dla poprzednich wersji. To polecenie w konsoli Menedżera pakietów ponownie instaluje pakiety dla całego rozwiązania:

Update-Package –reinstall

Nie mam pojęcia, dlaczego to zadziałało, ale usunąłem odniesienie do projektu, które VS2015 mówiło mi, że nie może znaleźć, i dodałem je ponownie. Rozwiązać problem. Próbowałem wyczyścić, zbudować i ponownie uruchomić VS bezskutecznie.

Podczas budowania rozwiązania pojawiał się ten sam błąd (nie można znaleźć typu lub przestrzeni nazw ''). Pod nim zobaczyłem ostrzeżenie , że „nie można rozwiązać problemu” i upewnić się, że „zespół istnieje na dysku”.

Byłem bardzo zdezorientowany, ponieważ moja biblioteka DLL była bardzo wyraźnie w miejscu, do którego wskazywało odwołanie. VS chyba nie podkreślał żadnych błędów, dopóki nie próbowałem zbudować rozwiązania.

W końcu zrozumiałem problem (a przynajmniej podejrzewam, że był to problem). Budowałem plik biblioteki w tym samym rozwiązaniu. Więc mimo że istniał na dysku, był odbudowywany w tej lokalizacji (w jakiś sposób w trakcie przebudowy biblioteki mój inny projekt - w tym samym rozwiązaniu - który odwoływał się do biblioteki, musiał zdecydować, że biblioteka nie istnieje)

Kiedy kliknąłem projekt prawym przyciskiem myszy i zbudowałem tylko to, zamiast całego rozwiązania, nie dostałem błędu.

Aby rozwiązać ten problem, dodałem bibliotekę jako zależność do projektu, który z niej korzystał.

Aby to zrobić:

1. Kliknąłem prawym przyciskiem myszy moje Rozwiązanie w Eksploratorze rozwiązań i wybrałem „Właściwości”
2. Następnie w „Wspólnych właściwościach” wybrałem „Zależności projektu”.
3. Następnie w menu rozwijanym Projekty wybrałem projekt oparty na bibliotece i
4. Zaznaczone pole obok biblioteki znajdującej się w sekcji „Zależy od”

To gwarantuje, że projekt biblioteki zostanie najpierw zbudowany.

Najpierw sprawdzę, czy informacje wygenerowane przez twój projekt nie są uszkodzone. Wykonaj czyszczenie i przebuduj swoje rozwiązanie.

Jeśli to nie pomoże, jedną z rzeczy, które widziałem w przeszłości w projektowaniu, jest otwarcie projektu formularzy Windows, a następnie zamknięcie go ponownie. Jest to jednak trochę wnętrzności z kurczaka, więc nie wstrzymuj oddechu.

Trudniejsza sytuacja, z którą się zetknąłem to: Projekt pierwszy jest ukierunkowany na pełną wersję 4.0 z Microsoft.Bcl.Asynczainstalowanym pakietem. Projekt drugi jest ukierunkowany na pełną strukturę 4.0, ale nie skompiluje się, gdy odniesie się do klasy Project jeden.

Po zainstalowaniu pakietu Async NuGet w drugim projekcie kompilacja przebiegła poprawnie.

W moim przypadku odnośnik w VisualStudio ma trójkąt i wykrzyknik jako ten obraz,

następnie, kliknij prawym przyciskiem myszy, aby go usunąć i ponownie dodać odwołanie do biblioteki DLL poprawnie, problem został rozwiązany.

Ten działał dla mnie. W klasie, w której zdefiniowano nazwę klasy, np .: ABC klasy publicznej, usuń jeden znak i poczekaj chwilę. Twoja lista błędów wzrośnie, ponieważ zmieniłeś nazwę. Teraz odłóż wpisaną postać. To zadziałało dla mnie, mam nadzieję, że zadziała również dla ciebie. Powodzenia!!!

Miałem podobny problem: kompilator nie był w stanie wykryć folderu w tym samym projekcie , więc użycie dyrektywy łączącej z tym folderem spowodowało błąd. W moim przypadku problem powstał w wyniku zmiany nazwy folderu . Mimo że zaktualizowałem przestrzeń nazw wszystkich klas w tym folderze, informacje o projekcie jakoś się nie zaktualizowały. Próbowałem wszystkiego: usuwanie pliku .suo i folderów bin i obj, czyszczenie rozwiązania, ponowne ładowanie projektu - nic nie pomogło. Rozwiązałem problem, usuwając folder i znajdujące się w nim klasy, tworząc nowy folder i tworząc nowe klasy w tym nowym folderze (zwykłe przeniesienie klas do nowego folderu nie pomogło).

PS: W moim przypadku pracowałem nad aplikacją internetową, ale ten problem może wystąpić w różnych typach projektów.

[Facepalm] Mój problem polegał na tym, że dodałem zależność w sposobie działania C ++.

Przejdź do projektu, który się nie zbuduje, otwórz folder „References” w Eksploratorze rozwiązań i sprawdź, czy na liście znajduje się twoja zależność.

Jeśli nie, możesz „Dodaj odniesienie” i wybrać zależność na karcie Projekty.

Boom Shankar.

Mieliśmy dziwny przypadek, który właśnie rozwiązałem. Przed instrukcją „using” w głównym projekcie znajdował się ukryty / biały znak. Ten projekt byłby dobrze zbudowany, a strona działała dobrze, ale nie można zbudować projektu testu jednostkowego, który się do niego odwoływał.

Napotkałem ten problem podczas aktualizacji istniejących projektów z VS2008 do VS2012. Odkryłem, że dwa projekty (jedyne dwa, które stworzyłem) były ukierunkowane na różne .NET Framework (3.5 i 4.0). Rozwiązałem to na karcie Aplikacja projektów, upewniając się, że oba projekty mają „.NET Framework 4” w polu Target Framework.

Miałem te same błędy, moja historia była następująca: po złym scaleniu (przez git) jeden z moich plików .csproj zduplikował compilewpisy, takie jak:

<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" />        //it's a duplicate

Jeśli masz duże rozwiązanie i ponad 300 komunikatów w oknie błędów, trudno jest wykryć ten problem. Więc otworzyłem uszkodzony plik .csproj za pomocą notatnika i usunąłem zduplikowane wpisy. W moim przypadku zadziałało.

Miałem ten sam problem, co omówiony: VS 2017 podkreśla klasę w odnośnym projekcie jako błąd, ale rozwiązanie buduje się dobrze, a nawet działa intellisense.

Oto jak udało mi się rozwiązać ten problem:

1. Zwolnij odnośny projekt
2. Otwórz plik .proj w VS (szukałem duplikatów, jak ktoś tutaj sugerował)
3. Ponownie załaduj projekt (nie zmieniłem ani nawet nie zapisałem pliku proj, ponieważ nie miałem żadnych duplikatów)

Możesz także spróbować wyeliminować kod , z którym masz problemy, i sprawdzić, czy kompiluje się bez odwołań do tego kodu. Jeśli nie, napraw rzeczy, dopóki nie skompiluje się ponownie, a następnie uruchom ponownie podejrzany kod problemu. Czasami pojawiają się dziwne błędy dotyczące klas lub metod, które, jak wiem, są poprawne, gdy kompilator nie lubi czegoś innego. Gdy naprawię problem, na którym naprawdę się rozłącza, te błędy „fantomowe” znikają.

Wiem, że to kopanie martwego konia, ale miałem ten błąd i ramy były w porządku. Mój problem polegał w zasadzie na stwierdzeniu, że interfejs nie został znaleziony, a jednak zbudował się i był dostępny. Więc zacząłem myśleć: „Dlaczego właśnie ten interfejs, kiedy inni działają dobrze?”

Okazało się, że faktycznie uzyskiwałem dostęp do usługi za pomocą WCF z interfejsem punktu końcowego, który korzystał z wersji Entity 6, a reszta projektów korzystała z wersji 5. Zamiast NuGet po prostu skopiowałem pakiety nuget do lokalnego repozytorium w celu ponownego użycia i wymieniłem je inaczej.

np. EntityFramework6.dll kontra EntityFramework.dll .

Następnie dodałem odniesienia do projektu klienta i puf, mój błąd zniknął. Zdaję sobie sprawę, że jest to przypadek skrajny, ponieważ większość ludzi nie będzie mieszać wersji Entity Framework.

Dodanie mojego rozwiązania do miksu, ponieważ było trochę inne i zajęło mi trochę czasu, aby się domyślić.

W moim przypadku dodałem nową klasę do jednego projektu, ale ponieważ moje powiązania kontroli wersji nie były ustawione, musiałem umożliwić zapisywanie pliku poza Visual Studio (przez VC). Anulowałem zapisywanie w programie Visual Studio, ale po utworzeniu pliku do zapisu poza VS ponownie włączyłem Zapisz wszystko w VS. To nieumyślnie spowodowało, że nowy plik klasy nie został zapisany w projekcie. Jednak .. Intelisense nadal pokazywał go jako niebieski i poprawny w projektach odwołujących się, mimo że podczas próby rekompilacji plik nie został znaleziony i otrzymałem błąd typu nie znaleziono. Zamykanie i otwieranie Visual Studio nadal pokazywało problem (ale gdybym zauważył, że plik klasy nie był dostępny po ponownym otwarciu).

Kiedy zdałem sobie z tego sprawę, poprawka była prosta: przy ustawieniu pliku projektu na zapis, wczytywałem brakujący plik do projektu. Wszystkie kompilacje są teraz w porządku.

Miałem ten sam problem. Pewnej nocy mój projekt skompiluje następnego ranka BŁĘDY !.

W końcu dowiedziałem się, że studio wizualne postanowiło „ulepszyć” niektóre z moich referencji i wskazać je gdzie indziej. na przykład:

System.ComponentModel.ISupportInitialize jakoś stał się „blahblah.System.ComponentModel.ISupportInitialize”

Zupełnie niegrzeczna rzecz dla vs do zrobienia, jeśli jesteś mną

To wydarzenie miało miejsce w Visual Studio 2017.

1. Uruchom ponownie Visual Studio
2. Czysty projekt, którego nie udało się zbudować.
3. Odbuduj projekt.

Mój przypadek był taki sam, jak tutaj omówiony, ale nic nie rozwiązało go, dopóki nie usunąłem System.Corereferencji z listy referencji (bez tego wszystko działało dobrze)

mam nadzieję, że to komuś pomoże, ponieważ ten problem jest dość frustrujący

Aby rozwiązać ten problem, może również pomóc usunąć i ponownie utworzyć *.sln.DotSettingsplik skojarzonego rozwiązania.

W moim przypadku miałem klasę, która była wymieniona w odpowiednim folderze źródłowym, ale nie rejestrowała się w Eksploratorze rozwiązań. Musiałem zrobić prawym przyciskiem myszy projekt> Dodaj istniejący element i ręcznie wybrać klasę, o której brakowało. Potem wszystko działało dobrze!

W moim przypadku problem polegał na tym, że po zmianie przestrzeni nazw na dokładnie taką samą, jak w innym projekcie (celowo), nazwa zestawu została również zmieniona przez VS, więc były dwa zestawy o tej samej nazwie, jeden nadpisujący drugi

W moim przypadku miałem plik zbudowany przez zewnętrzną zależność (xsd2code) i jakoś jego pliki designer.cs nie zostały poprawnie przetworzone przez VS. Stworzenie nowego pliku w Visual Studio i wklejenie w nim kodu załatwiło sprawę.

Dla każdego, kto pojawia się ten błąd, gdy próbują opublikować swoją witrynę na platformie Azure, żadne z obiecujących rozwiązań powyżej nie pomogło mi. Byłem na tej samej łodzi - moje rozwiązanie zbudowało się samo. Skończyło się na tym, że muszę

1. Usuń wszystkie pakiety nuget z mojego rozwiązania.
2. Zamknij i ponownie otwórz moje rozwiązanie.
3. Ponownie dodaj wszystkie pakiety nuget.

Trochę bolesne, ale był to jedyny sposób, aby moja witryna mogła publikować na platformie Azure.

Wystąpił ten błąd podczas próby kompilacji za pomocą kompilacji Visual Studio Team Services działającej na moim komputerze lokalnym jako agent.

Działa dobrze w moim zwykłym obszarze roboczym i byłem w stanie otworzyć plik SLN w folderze agenta lokalnie i wszystko skompilowane ok.

Biblioteka DLL, o której mowa, była przechowywana w projekcie jako Lib/MyDLL.DLLi zawiera odniesienia do tego w pliku csproj:

<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>Lib\MYDLL.dll</HintPath>
</Reference>

Okazało się, że dosłownie po prostu nie znalazłem pliku pomimo ścieżki podpowiedzi. Myślę, że może msbuild wyglądał względnie w stosunku do pliku SLN zamiast pliku projektu.

W każdym razie, jeśli Could not resolve this reference. Could not locate the assemblypojawi się komunikat, upewnij się, że biblioteka DLL znajduje się w dostępnym miejscu do msbuild.

W pewnym sensie oszukałem i znalazłem wiadomość, która mówi, Considered "Reference\bin\xxx.dll"i po prostu skopiowałem tam dlls.

W moim przypadku dodanie dll jako odwołania spowodowało type or namespace name could not be foundbłąd. Jednak skopiowanie i wklejenie pliku DLL bezpośrednio w folderze bin rozwiązało błąd.

Nie mam pojęcia, dlaczego to zadziałało.

Wiem, że ten wątek jest stary, ale mimo to udostępniam, muszę zainstalować wszystkie zależności trzeciej części importowanego zestawu - ponieważ importowany zestaw nie został uwzględniony jako pakiet Nuget, więc brakowało jego zależności.

Hop tę pomoc :)

W moim przypadku miałem dwa projekty w rozwiązaniu, dodałem pod-przestrzeń nazw do projektu, do którego się odwołujemy, ale podczas budowania nie zauważyłem, że kompilacja projektu, do którego się powiodło, zakończyła się niepowodzeniem i użyła ostatniej pomyślnie zbudowanej wersji, która nie mieć tę nową przestrzeń nazw, więc błąd był poprawny, że nie można go znaleźć, ponieważ nie istniał. Rozwiązaniem było oczywiście naprawienie błędów w odnośnym projekcie.

Pracowałem nad wersją społecznościową VS 2017 i miałem ten sam problem z pakietami nuget CefSharp.

Pakiety zostały pomyślnie pobrane i przywrócone, projekt można było zbudować i uruchomić pomyślnie - tylko znaczniki wskazały, że przestrzenie nazw nie zostały rozpoznane.

Wystarczyło otworzyć Referencessekcję i kliknąć jeden z żółtych znaków wykrzyknika.

Po kilku sekundach błędy znaczników zniknęły.