2015-02-13 12 views
8

Mam projekt MVC5, który jest aktualnie ustawiony na "Konfiguracja wydania" i działa w 100%. Jednak, gdy tylko przełączę konfigurację projektu z wersji Release na debugowanie, wszystko pójdzie źle ... nawet jeśli przełączyłem ją z powrotem do trybu Release, wszystko jest nadal zepsute. Jedynym sposobem, aby ponownie uruchomić projekt, jest przywrócenie z kopii zapasowej.MVC5 z VB.NET: "BC30451:" ViewData "nie jest zadeklarowany." przy przełączeniu na konfigurację debugowania

Oto co się dzieje. Po pierwsze, gdy uruchomiony projekt, pojawia się następujący błąd:

BC30451: 'ViewData' is not declared. It may be inaccessible due to its protection level.

Jeśli mogę otworzyć żadnego widoku w projekcie Visual Studio 2013, widzę, że różne rzeczy są oznaczone jako błędy jak ViewData, HTML , Url itp.

Odwołując się do @Html lub @ViewData w widoku, zwykle odnosi się do właściwości .Html i .ViewData klasy widoku widoku (WebViewPage). Jeśli jednak zacznę pisać "@Html". w każdym z widoków widzę w autouzupełnianiu, że odwołuje się do przestrzeni nazw System.Web.Webpages.Html zamiast właściwości WebViewPage.Html. Jest tak - jeśli widok nie dziedziczy z klasy System.Web.Mvc.WebViewPage.

Wszelkie wskazówki, gdzie mogę zacząć szukać, aby to naprawić lub dlaczego tak się dzieje?

Edit: Więc skoro nikt nie odpowiedział mi przeszedł długą drogę. Stworzyłem nowy projekt MVC5, dodałem wszystkie pakiety przez Nuget, a następnie po prostu skopiowałem wszystkie moje pliki ze starego projektu do nowego i teraz to działa.

Czy ktoś ma pojęcia, co może być przyczyną tego? Nie chcę w przyszłości ponownie podejmować tych wszystkich kłopotów, jeśli projekt ponownie nagle zdecyduje się przerwać pracę.

+0

Zdecydowana większość czasu, masz problem web.config, w których nie określono prawidłowy montaż przekierowania lub Twój web.config.release jest zastąpieniem części web.config który zakłóca twój projekt. – Tommy

+0

Zmierzyłem się z tym ostatnim razem. ale pamiętam, że to było tylko ostrzeżenie, a nie błąd? – Baby

Odpowiedz

1

OK, myślę, że znalazłem część przyczyny tutaj. Chodzi o to, że oryginalny kod jest prawidłowy (kompiluje się poprawnie, a intellisense go podnosi) i kod używany do pracy, a potem nagle, dzień po kompilacji, przestaje działać.

W każdym razie w widoku podczas określania Typ modelu, jeśli nie używasz pełnej nazwy, ten błąd może wystąpić lub w końcu wystąpić. Na przykład, używając:

@ModelType Models.SomeNamespace.SomeClass 

spowoduje błąd (chociaż nazw root dla projektu jest „myproject”) i może być ustalona po prostu przez określenie pełnej nazwy przestrzeni nazw i klasy.

@ModelType MyProject.Models.SomeNamespace.SomeClass 
+0

Wpadłem na ten sam problem w projekcie MVC, który przekonwertowałem z VB.NET na C#. Twoja odpowiedź powyżej postawiła mnie na właściwej drodze. Co dziwne, musiałem zrobić odwrotność ... upraszczając deklarację '@ ModelType' z w pełni kwalifikowanej przestrzeni nazw, do samej tylko nazwy klasy. – bkwdesign

+0

Na marginesie, wciąż znajduję ten "stabilny" kod projektu MVC, z biegiem czasu, wydaje się on w magiczny sposób degradować. Sądzę, że zależności NuGet, gdy są przebudowywane od zera, nie są tak "niezawodne", jak czasami reklamowane – bkwdesign

1

Możliwe, że zestaw debugowania jest zablokowany. Można zamknąć Visual Studio, wyszukać i usunąć dla wszystkich folderów bin w katalogu rozwiązania. Następnie otwórz i odbuduj.

Pozostałe opcje to przejście do właściwości projektu MVC i porównanie dwóch konfiguracji kompilacji. Czy kierujesz się do innego środowiska .NET między wersją Release a Debug? 32-bitowy vs 64-bitowy? itp?