Visual Studio 2010 nagle nie widzi przestrzeni nazw?

83

Moje rozwiązanie C # WinForms ma dwa projekty. Biblioteka DLL, która jest głównym projektem, nad którym pracuję, oraz wykonywalny plik WinForms, który nazywam „Sandbox”, dzięki czemu mogę łatwo skompilować / uruchomić / debugować bibliotekę DLL za jednym razem.

Pracuję w .Net 4.0 dla obu projektów.

Wszystko działało dobrze, dopóki nie dodałem pozornie niewinnego kodu i odniesienia do System.Web w bibliotece DLL. Teraz mój projekt Sandbox nie widzi przestrzeni nazw projektu DLL. Nie zmieniłem niczego, co moim zdaniem powinno wpłynąć na to.

Jeśli usunę odniesienie projektu do biblioteki DLL z odniesień piaskownicy i ponownie je dodam, wówczas czerwone podkreślenia znikną, a kodowanie kolorami powróci dla wszystkich moich klas itp .; ale jak tylko spróbuję zbudować rozwiązanie, wszystko znowu się rozpada.

Kiedy klikam prawym przyciskiem myszy projekt DLL w odniesieniach piaskownicy i przeglądam w przeglądarce obiektów, widzę przestrzeń nazw i wszystko, co się tam znajduje.

Mam przeczucie, że to może być jakiś błąd?

Czy to jakiś błąd w VS2010? Miałem ten sam problem kilka miesięcy temu i mogłem go wtedy naprawić tylko poprzez stworzenie zupełnie nowego projektu i ponowne zaimportowanie moich plików. Tym razem jednak mam bajlion plików i zrobię to tylko w ostateczności!

Edycja: po panicznym przejściu i cofnięciu wszystkich moich zmian, próbując znaleźć przyczynę problemów, wygląda na to, że jest to ta linia:

string url = "http://maps.google.com?q=" + HttpUtility.UrlEncode(address);

Jeśli wykomentuję tę linię, nie otrzymam żadnych błędów przestrzeni nazw, a projekt zostanie poprawnie zbudowany. Nie widzę jednak nic złego w tej linii.

c# winforms namespaces

— Ozzah
źródło

149

Jestem gotowy, aby zadeklarować to jako błąd w VS2010, który ugryzł już zbyt wielu programistów. Rozwiązanie jest łatwe: Projekt + Właściwości, karta Aplikacja, zmień platformę docelową na „.NET Framework 4” zamiast domyślnego profilu klienta.

System.Web nie jest uwzględniony w profilu klienta. Posiadanie tej opcji w pierwszej kolejności jest dość głupie, profil klienta jest tylko 15% mniejszy niż w pełnej wersji .NET 4.0. Ustawienie go domyślnie jest jeszcze głupsze. Ale błądzę.

AKTUALIZACJA: na szczęście wszystko to zostało naprawione w VS2012. Co nie powoduje już, że profil klienta jest domyślnym dla nowego projektu. A profil klienta został całkowicie wycofany w .NET 4.5, dobrze.

— Hans Passant
źródło

1

Dziękuję za to. Moja biblioteka DLL była ustawiona na .Net 4.0, ale piaskownica była ustawiona na .Net 4.0 Client Profile. Po pracy nad tym projektem przez 5 miesięcy, ilość paniki, jaką dostałem, gdy wszystko się rozpadło z pozoru bez powodu ... Przynajmniej będę wiedział na następny raz!

— Ozzah

27

Tego rodzaju odpowiedzi to prawdziwe mięso i ziemniaki tej witryny. Moja wiara w ludzkość została nieco zwiększona i mój projekt w końcu się kompiluje. Dzięki.

— CloudMeta

1

Zmieniłem platformę docelową na 4.0 we wszystkich moich projektach, jednak nadal nie można znaleźć przestrzeni nazw projektów zależnych. Czy jest jeszcze coś, co powinienem zweryfikować?

— Steven Ryssaert,

@UwConcept - nie chodzi o numer wersji. Chodzi o profil pełny kontra klient. Jeśli to nie pomoże, zacznij własne pytanie.

— Hans Passant

@HansPassant Tak, przepraszam, jeśli moje pytanie było niejasne. Korzystałem z wersji klienta 4.0 i zmieniłem ją na 4.0. Mimo to nie można znaleźć przestrzeni nazw w innych projektach w moim rozwiązaniu między projektami.

— Steven Ryssaert,

8

Sprawdź, czy oba projekty używają profilu innego niż klient dla ich platformy docelowej (przejdź do właściwości każdego projektu, aby to zrobić).

— Mark Avenius
źródło

Dzięki Mark. Ty i Hans przybiliście go do głowy, to naprawiło.

— Ozzah

2

Jedną z możliwości jest to, że docelowa wersja biblioteki klas .NET Framework jest wyższa niż wersja projektu. Zmierzyłem się z tym problemem i rozwiązałem go, zamykając Visual Studio, ponownie otwierając Visual Studio, czyszcząc i przebudowując rozwiązanie. To zadziałało dla mnie. W niektórych innych postach przeczytałem odpowiedzi i większość użytkowników rozwiązała problem postępując w ten sposób.

— Muhammad Sohail
źródło

1

Na to pytanie udzielono zadowalającej odpowiedzi już ponad cztery i pół roku temu.

— Ozzah

+ za dodanie pomocnych i przydatnych informacji na temat blisko związanego błędu

— Eric Brown - Cal

@Ozzah jako ktoś, kto zajmuje się tym błędem w 2017 roku, zdecydowanie cieszę się, że mam więcej informacji. +1

— Cowthulhu

1

Spróbuj najpierw niezależnie zbudować tylko projekt z biblioteką DLL Sandbox.

Następnie wskaż projekt wykonywalny na wymaganą bibliotekę dll i upewnij się, że copy localjest ustawiony na true. w ustawieniach referencyjnych.

Następnie skompiluj projekt wykonywalny.

— Robin Maben
źródło

I z miłości do wszystkiego, co święte, upewnij się, że typ docelowy jest ustawiony na Kompiluj, a nie Treść (który z jakiegoś powodu był moim)

— jcolebrand

0

Zmiana docelowego frameworka z „.NET Framweork 4 Client Profile” na „.NET Framework 4” działała u mnie z podobnym problemem. Zgadzam się, że profil klienta nie wydaje się mieć wiele zalet w korzystaniu z niego. Wydaje mi się, że pojawiają się dziwne błędy, na które poluję, dopóki nie pamiętam, że Visual Studio domyślnie korzysta z profilu klienta. Wydaje mi się, że morał tej historii, gdy pojawia się błąd, jest taki: jeśli „Odbuduj rozwiązanie” nie działa, sprawdź framework Target ...

— Andy
źródło

0

Jeśli próbowałeś już dokonać zmiany frameworka i nadal nie działa, mam nadzieję, że to zadziała dla Ciebie (tak jak w przypadku mnie): Po prostu dodaj niezbędne odniesienia z Twoich projektów. Bardzo oczywiste, ale robiłem to źle, dopóki nie znalazłem przyczyny.

— lu1s
źródło

0

Właśnie miałem ten problem i okazało się, że używam wielu przestrzeni nazw o tej samej nazwie obiektu (tj. Obiekty biznesowe mają takie same nazwy jak modele mvc);

Pełne zakwalifikowanie nazw rozwiązało problem.

— Mike Cheel
źródło