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


276

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 działać, aby zamknąć i ponownie uruchomić program Visual Studio. Czasami wydaje się, że utknęło
Ris Adams,

2
Wskazówka: 1) zestaw załadowany ?, 2) zestaw załadowany pasuje do zestawu źródłowego ?, 3) „za pomocą” dyrektyw wskazujących na stare lub brak ważnych referencji ?, 4). Manifestspc .csproj zawiera niepoprawne źródło ?, 5) narzędzie wyszukiwania szukające wyrażenia regularnego w całym rozwiązaniu (każda biblioteka klas i projekt). 5) sprawdź ustawienia projektu dla opcji kompilacji wersji frameworka sieci (współpracuj w zespołach przynosząc tego rodzaju problen, musisz uzgodnić framew sieci. Wersja kompilacji po obu stronach) 6) Następnie wyczyść i skompiluj każdą osobno i na końcu dołącz wszystkie referencje do docelowej biblioteki projektu / klasy. Powinienem pracować!
Felix Aballi

Sprawdź, czy odwoływałeś się do biblioteki dll. Dll znajduje się w folderze bin katalogu rozwiązania.
Abhishek Poojary

Odpowiedzi:


470

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)


2
doskonałe - to zadziałało - musiałem zaktualizować mojego klienta aplikacji WPF, aby móc korzystać z pełnej wersji .NET Framework 4. Nie wiesz, jaki to wpłynie na powierzchnię klienta? Próbowałem obniżyć bibliotekę do profilu klienta .Net 4, jednak kiedy to zrobiłem, wystąpiły podobne problemy z najnowszą biblioteką zewnętrzną Quartz.net, z której właśnie zacząłem korzystać. Wygląda więc na to, że użycie Quartz.net w moim projekcie biblioteki ostatecznie zmusza mnie do korzystania z pełnego frameworku .Net 4 w mojej aplikacji WPF w interfejsie użytkownika.
Greg

3
Dzięki - to pomogło właśnie teraz. Niedawno przeniosłem rozwiązanie do VS2012 z VS2010 i stworzyłem jedną nową bibliotekę klas w VS2012. Nagle otrzymałem ten błąd i oczywiście dlatego, że nowa biblioteka klas była ukierunkowana na .NET 4.5, podczas gdy projekt, do którego się ona odnosiła, była ukierunkowana na .NET 4.0. Naprawiono obniżenie poziomu nowej biblioteki do wersji 4.0.
Richard

22
Naprawdę byłoby miło, gdyby Visual Studio dał ci jakąś wskazówkę na ten temat!
Jason Coyne

3
Chociaż ta odpowiedź zawiera doskonały opis tego, co należy zrobić ... nie ma sugestii, jak to zrobić, co byłoby miłym dodatkiem
Jon Story,

1
Nawet najlepsi z nas czasami po prostu nigdy nie musieli wykonywać niektórych zadań. Nie jestem pewien, jak nigdy nie musiałem zmieniać frameworka i chociaż go znalazłem, nie przyszło mi to do głowy wcześniej. Nie jest to przełom dla odpowiedzi, po prostu uważam, że najlepsze odpowiedzi działają jak punkt kompleksowej obsługi dla „opisz problem, podaj rozwiązanie, pokaż, jak go naprawić”
Jon Story

50

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

Problem, z którym się spotkałem, polegał na tym, że stworzyłem nowe rozwiązanie, dodałem inną wersję pakietu Nuget, niż inne są używane. Potem, kiedy uruchomiłem Update-Package -reinstall, miałem kilka błędów we wszystkich rozwiązaniach, które obejmowały inną wersję tego pakietu. Zaktualizowałem we wszystkich, a potem w końcu to przeszło. Naprawiono także odwołania w plikach package.json z 45 do 452, ponieważ wcześniej zmieniłem też wersję docelową.
Ádám Kovács,

Pracowałem dla mnie i musiałem usunąć Sytems.Net.Http z referencji podczas obniżania
Binil Anto

1
To też działało dla mnie. Wykonałem polecenie, a następnie cofnąłem wynikowe oczekujące zmiany, a mój sln powrócił do normy
foremaro

To działało dla mnie, pokazało mi referencję, która nie była obsługiwana przez mój obecny framework
Adleri

to zadziałało dla mnie, a błąd, który zniknął, był całkowicie niezwiązany z żadnym zainstalowanym pakietem nuget.
CAD CAD

31

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.


Zdecydowanie polecam tę sztuczkę za każdym razem, gdy znajdziesz jakiś problem z odniesieniem w rozwiązaniu VS. Rozwiązał mój problem w VS2017 po dodaniu w nowym projekcie ukierunkowanym na wyższą wersję środowiska .NET. Założę się, że pewne buforowanie zostało wyczyszczone.
themefield,

1
To samo tutaj: to pomogło (nie miałem też innych problemów z wersją). Dostaję komunikaty o błędach dla każdego otwartego pliku, do ponad 400 ... chociaż kompilacja / uruchomienie nie stanowiło problemu. Ponadto: analiza całego rozwiązania ReSharper również wykazała te same błędy.
Mike

Pomógł mi też ten trik. Nie miał nawet żadnych różnic w wersjach docelowych. Budowanie było możliwe, Rider nie wykazywał żadnych problemów, ale VS nalegał, aby nie było wszystkich odniesień do projektu ...
Daniel Lerps

Kompilator kompiluje zgodnie z kolejnością kompilacji projektu, więc jeśli w jednym projekcie wystąpi prawdziwy błąd, można go zgubić w morzu błędów typu „red śledź” lub nie można znaleźć przestrzeni nazw - ponieważ kończy działanie po znalezieniu błąd i nie można zaktualizować referencji. Jeśli na liście nie ma zbyt wielu błędów, powinieneś znaleźć prawdziwy błąd. Niestety było ich dla mnie setki, więc ta sztuczka naprawdę mi pomogła. Myślę, że intelisense nie przejmuje się kolejnością kompilacji i po prostu kompiluje projekty indywidualnie, i dlatego nie dostajesz błędów inteligencji.
Kev

29

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.


2
Dzięki za wskazówkę, aby spojrzeć na ostrzeżenia. Mój problem polegał na tym, że mój projekt testowy musiał zainstalować pakiet NuGet dla Bcl, ponieważ mój główny projekt go odwoływał.
Kim

Dzięki! To skłoniło mnie do znalezienia problemu, który miałem. Okazało się, że miałem dwa odniesienia do projektu zależności, a tym, który miał pierwszeństwo, była wcześniej zbudowana biblioteka DLL w folderze bin. Usunąłem bibliotekę DLL i nieuczciwe odniesienie i wykonałem przebudowę, wszystko wtedy skompilowałem poprawnie.
Chris Davis

7

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.


Próbowałem wyczyścić i przebudować twoje rozwiązanie, ale bez powodzenia. Próbowałem usunąć / dodać / wyczyścić / przebudować tylko projekt aplikacji WPF i nadal nie mam szczęścia. :(
Greg

Naprawiono problem z czyszczeniem, a następnie przebudową. Jednak ten problem pojawia się każdego dnia. Przynajmniej mogę załatwić swoje sprawy, dopóki nie rozwiążę ich całkowicie.
Valamas

5

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.


1
Ach dzięki za to. Mój przenośny projekt kompilował się dobrze w Xamarin Studio, podczas gdy zawiódłby w Visual Studio z tego powodu. Myślę, że XS ma jakąś „magię”, aby umożliwić kompilację, gdy brakuje niejawnych odniesień.
Nicola Iarocci

5

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.


4

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!!!


4

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.


3

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


2

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


2

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.


2

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.


1
Miałem podobny problem ze złym scaleniem w VS 2019. Projekt został skompilowany pomyślnie, ale nie rozwiązanie. Wystąpił błąd w tym projekcie (bardzo dziwne). Wystąpił błąd z powodu odwołania do dodatkowego pliku, który został wcześniej usunięty, ale następnie ponownie dodany ze scalenia. Usunąłem plik, wyczyściłem plik .csproj, przebudowałem i wszystkie odniesienia zaczęły działać ponownie.
Cryptc

2

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)

1

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


1

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.


1

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.


1

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ą


1

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.

1

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


To był dla mnie dokładny problem. Usunąłem System.Core i przebudowałem, błędy natychmiast się rozwiązały. Dzięki milion za zaoszczędzenie mi dużo bólu głowy
1959309

1

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


1

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!


1

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


Gdzie mogę edytować nazwę zestawu, aby zmienić go na właściwą nazwę?
Matt123

1
w pliku projektu (.csproj) ręcznie lub klikając projekt prawym przyciskiem myszy -> Właściwości
user1121956

0

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


0

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.


0

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.


0

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.


0

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


0

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.


0

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.

wprowadź opis zdjęcia tutaj

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

wprowadź opis zdjęcia tutaj


Myślę, że przekonasz się, że działa to tylko wtedy, gdy panel Właściwości jest otwarty (kliknij prawym przyciskiem myszy problematyczne odniesienie i wybierz Właściwości). Czy ktoś może teraz wyjaśnić, dlaczego to działa?
Qwertie,
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.