Widok oparty na Razor nie widzi zestawów, do których istnieją odwołania

101

Próbuję utworzyć silnie wpisany widok na podstawie klasy z innego zestawu. Z jakiegoś powodu mój widok Razor nie wydaje się mieć żadnej widoczności innych zestawów, do których odwołuje się mój projekt. na przykład

@model MyClasses.MyModel

powoduje błąd w programie Visual Studio 2010, „ MyClassesNie można znaleźć typu lub nazwy przestrzeni nazw (czy brakuje dyrektywy using lub odwołania do zestawu?)”.

Ta sama klasa, do której odwołuje się silnik widoku standardowego, działa dobrze. Mam ten sam problem, próbując odwołać się do klasy w treści mojego widoku.

Czy brakuje mi czegoś na temat Razor, czy muszę odwoływać się do zestawu w inny sposób?

asp.net-mvc  asp.net-mvc-3  razor 
— nickwesselman
źródło
Czy używasz całej przestrzeni nazw? @model przestrzeń nazw.myclasses.mymodel, może?
— Brettski

Odpowiedzi:

107

Istnieje nowa sekcja konfiguracji, która jest używana do odwoływania się do przestrzeni nazw dla widoków Razor.

Otwórz web.configplik w swoim Viewsfolderze i upewnij się, że zawiera:

<configuration>
    <configSections>
        <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
            <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
            <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
        </sectionGroup>
    </configSections>

    <system.web.webPages.razor>
        <host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <pages pageBaseType="System.Web.Mvc.WebViewPage">
            <namespaces>
                <add namespace="System.Web.Mvc" />
                <add namespace="System.Web.Mvc.Ajax" />
                <add namespace="System.Web.Mvc.Html" />
                <add namespace="System.Web.Routing" />
                <add namespace="SquishIt.Framework" />
                <add namespace="Your.Namespace.Etc" />
            </namespaces>
        </pages>
    </system.web.webPages.razor>
</configuration>

Alternatywnie możesz dodać instrukcje using do udostępnionego układu:

@using Your.Namespace.Etc;
<!DOCTYPE html>
<head>
....

Po zmodyfikowaniu pliku Web.config uruchom ponownie program Visual Studio, aby zastosować zmiany.

— quentin-starin
źródło
18
To działa, jednak upewnij się, że istnieją odwołania do zestawów Copy Local = true. W przeciwnym razie zespoły zewnętrzne mogą nie działać.
— Terry
1
Należy tutaj zauważyć, że jeśli używasz widoków z „wirtualnego” źródła (takiego jak DB) zamiast rzeczywistych plików widoków, musisz umieścić to w pliku ROOT web.config, aby kod w widokach działał.
— NightOwl888
2
@Terry, wygląda na to, że Copy local = true jest konieczne nawet w przypadku niektórych zestawów w przestrzeni nazw katalogu głównego systemu.
— Dan Esparza
2
Moje zestawy są ładowane w czasie wykonywania, więc nie mogę ich dodać za pomocą pliku web.config. Czy jest coś jeszcze, co mogę spróbować? Czy istnieje sposób na zaimportowanie moich zewnętrznych widoków z ich własnymi plikami web.config? Jest to raczej dziwne, ponieważ odwołuję się do przestrzeni nazw w tym samym zestawie co moje widoki.
— Maksim Vi.
Ponowne uruchomienie programu Visual Studio nie jest potrzebne. Wystarczy zamknąć i ponownie otworzyć Widok.
— user247702
58

Miałem ten sam problem: projekt MVC3 MyCore.Web odwoływał się do przestrzeni nazw MyCore.DBLayer z innego projektu w tym samym rozwiązaniu (z nazwą zestawu MyCoreDBLayer). Wszystkie obiekty z MyCore.DBLayer działało idealnie w sterownikach i modeli, ale nie powiodło się w maszynce z widokiem błędu „typu lub obszaru nazw«DBLayer»nie istnieje w obszarze nazw«MyCore»(czy brakuje odwołania do zestawu?)” , Który został oczywiście nie.

  • Opcja Copy Local została ustawiona na true.
  • Dodawanie instrukcji „using ...” w widokach Razor było bezużyteczne
  • Dodawanie przestrzeni nazw do sekcji system.web.webPages.razor również było bezużyteczne

Dodanie odwołania zestawu do sekcji system.web / compilation / assemblies w głównym pliku web.config rozwiązało problem. Sekcja wygląda teraz następująco:

<system.web>
    <compilation debug="true" targetFramework="4.0">
      <assemblies>
        <add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        <add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
        **<add assembly="MyCoreDBLayer" />**
      </assemblies>
    </compilation>
...
</system.web>

Pominięcie wersji, kultury i tokena było na razie w porządku, ale powinno zostać naprawione w przyszłości.

— VB
źródło
To rozwiązanie działa, ale to zły pomysł. Kiedy uczyniłem wszystkie moje klasy wewnętrznymi i uczyniłem asembler sieciowy przyjacielem MyCoreDBLayer, przestał działać. Skończyło się na napisaniu publicznych klas jako modelu MVC, który zawijał się wokół moich klas z zestawów znajomych. Uważam, że nie należy używać klas innych niż z przestrzeni nazw modeli MVC w widokach Razor - zawsze można napisać opakowanie
— VB
To zadziałało dla mnie, próbowałem dodać go do Views/web.configi działało, gdy został tam umieszczony.
— guanome
18

W moim przypadku oddzielnym projektem, który zawierał przestrzeń nazw, była aplikacja konsoli. Zmiana na bibliotekę klas rozwiązała problem.

— Sam
źródło
1
To rozwiązało to dla mnie. Najpierw próbowałem utworzyć bibliotekę klas (pakiet), ale napotkałem problemy z odwołaniem się do pakietu nuget, którego potrzebowałem. Najlepiej się nie
— wymyślać
15

Żadne z powyższych również nie działało dla mnie;

  • Biblioteki DLL zostały ustawione na Kopiuj lokalnie
  • Dodanie przestrzeni nazw do obu plików web.config nic nie dało
  • Dodanie odniesień do zestawów do system.web \ compilation \ assemblies również nie pomogło (chociaż nie usunąłem tych odniesień, więc może być tak, że są potrzebne)

Ale w końcu znalazłem coś, co dla mnie zadziałało:

To dlatego, że moje dane wyjściowe kompilacji trafiały do ​​bin \ Debug \ do konfiguracji debugowania i bin \ Release \ do konfiguracji wydania. Jak tylko zmieniłem konfigurację kompilacji na "bin \" dla wszystkich konfiguracji (jak na obrazku poniżej), wszystko zaczęło działać tak, jak powinno !!!

Konfiguracja kompilacji

Nie mam pojęcia, dlaczego rozdzielenie twoich kompilacji na foldery Release i Debug powinno spowodować uszkodzenie składni Razor, ale wydaje się, że coś nie może znaleźć zestawów. Dla mnie projekty, w których występowały problemy ze składnią maszynki do golenia, są w rzeczywistości projektami „biblioteki maszynki do golenia”. Są one ustawione jako projekty aplikacji, ale używam ich jako bibliotek klas z RazorGenerator do kompilowania moich widoków. Kiedy faktycznie próbowałem uruchomić jeden z tych projektów bezpośrednio, spowodowało to następujący błąd konfiguracji:

Nie można załadować pliku lub zestawu „System.Web.Helpers, Version = 3.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35” lub jednej z jego zależności. System nie może odnaleźć określonego pliku.

To doprowadziło mnie do próby zmiany wyjścia kompilacji, ponieważ zauważyłem, że dla wszystkich projektów internetowych wynik kompilacji wydaje się zawsze znajdować się bezpośrednio w folderze bin, w przeciwieństwie do domyślnego dla bibliotek klas, które mają zarówno foldery wydania, jak i debugowania.

— Sylvia
źródło
1
Potwierdziłem przy okazji, że nie musisz mieć sekcji system.web \ compilation \ assemblies, gdy biblioteki DLL znajdują się bezpośrednio w folderze bin. To może wrócić do bycia <compilation debug = "true" targetFramework = "4.5.1" />
— Sylvia
2
Święta krowa! Po długich poszukiwaniach rozwiązania ostatecznie rozwiązało to moje widoki Razor w projekcie biblioteki klas !! Dziękuję bardzo.
— Hullah
2
Nie do wiary! Budowałem bibliotekę widoków mojej klasy w katalogu innego projektu i miałem ten problem. Aby to zadziałało, ścieżka kompilacji musi być bin \. Teraz zamiast tego używam post build xcopy.
— GlacialSpoon
1
Używam Razor Engine w projekcie biblioteki klas i napotkałem ten sam problem. Ustawienie ścieżki wyjściowej na „bin \” rozwiązało również ten problem. Podobnie jak GlacialSpoon, kopiuję zestaw w kroku po kompilacji do odpowiedniego folderu wyjściowego. Nie jest to najlepszy sposób, ale przynajmniej Intellisense, odwoływanie się do zestawów i podświetlanie składni działa.
— Octoate
Warto zauważyć, że pierwotny problem pojawia się, jeśli niestandardowy katalog wyjściowy wskazuje na katalog nadrzędny ala '.. \ some \ dir \'. Ale jeśli zmienisz katalog wyjściowy, aby powiedzieć „jakiś \ katalog \”, wszystko działa dobrze. To na pewno diaboliczna usterka w matrixie.
— XDS
7

Wydaje się, że szukasz tej odpowiedzi: https://stackoverflow.com/a/4136773/176877

Oznacza to, że otwórz wewnętrzny Views \ Web.Config (NIE główny) i dodaj przestrzeń nazw pod znacznikiem Pages:

<system.web.webPages.razor>
  <host factoryType="System.Web.Mvc.MvcWebRazorHostFactory.../>
  <pages pageBaseType="System.Web.Mvc.WebViewPage">
    <namespaces>
      <add namespace="System.Web.Mvc" />
      ...
      <add namespace="System.Web.Routing" />
      <!-- Your namespace here -->
    </namespaces>

Zapisz to, a następnie zamknij i ponownie otwórz plik Razor.

Jeśli używasz obszarów, musisz to zrobić dla każdego Web.Config w każdym obszarze.

Program Visual Studio stał się bardziej błędny przez lata, więc może wymagać zamknięcia pliku Razor z uruchomioną kompilacją debugowania, a następnie ponownego otwarcia pliku Razor lub w najgorszym przypadku może wymagać ponownego uruchomienia programu Visual Studio. Ale ostatecznie przedstawi ci plik Razor tak, jakby wszystko na tej liście przestrzeni nazw znajdowało się w instrukcjach @using u góry wszystkich twoich widoków.

— Chris Moschini
źródło
4

W ASP.NET Core MVC rozwiązaniem jest dodanie usingw _ViewImports.cshtml zamiast umieszczania go web.config w folderze widoku podczas pracy z ASP.NET MVC 5.

_ViewImports.cshtml

@using mySolution
@using mySolution.ViewModels // <-- Add this, and place your ViewModel (e.g. LoginViewModel) in here.
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

Widok

@model LoginViewModel // Add to _ViewImports to make this line work
<div>This is the View for the login screen.</div>
— radbyx
źródło
3

Dla mnie odwoływałem się do projektu, który był aplikacją konsolową. Został ustawiony do kompilacji jako exe (aplikacja konsoli) zamiast biblioteki klas (DLL). Kiedy to zmieniłem, bez problemu mogłem zobaczyć modele z tego oddzielnego projektu.

— user1619480
źródło
Dzięki @ user1619480, miałem ten sam problem iw moim przypadku z biblioteki klas .Net Framework dodałem za pomocą VS 2017 iz jakiegoś powodu typem wyjściowym była aplikacja konsolowa.
— danfer
1

Otrzymałem ten sam błąd podczas próby użycia obiektów Smo w widoku Razor. Najwyraźniej dzieje się tak, ponieważ Razor nie może znaleźć bibliotek DLL, do których odwołuje się projekt. Rozwiązałem ten problem ustawiając „Kopiuj lokalnie” na true dla wszystkich bibliotek Smo, jednak może być lepsze rozwiązanie (patrz link Czechdude powyżej) Edycje @using i web.config są bezużyteczne, ponieważ są potrzebne tylko wtedy, gdy chcesz pominąć przestrzeń nazw część z nazw typów (na przykład Server zamiast Microsoft.SqlServer.Management.Smo.Server)

— Zar Shardan
źródło
1

Otrzymałem podobny błąd po przeniesieniu mojej maszyny deweloperskiej z Win7 32bit na Win7 64bit. Komunikat o błędzie:

...\Web\Views\Login.cshtml: ASP.net runtime error: [A]System.Web.WebPages.Razor.Configuration.HostSection cannot be cast to [B]System.Web.WebPages.Razor.Configuration.HostSection. Type A originates from System.Web.WebPages.Razor, Version=1.0.0.0 ... Type B originates from ... Version=2.0.0.0

Okazuje się, że miałem obie wersje w GAC-u. Widok web.configodwoływał się do wersji 1, ale aplikacja odwoływała się do wersji 2. Usunięto zestawy, do których istnieją odwołania, i ponownie dodano wersję 1. z System.Web.WebPages.Razoritp.

— Tim
źródło
+1 thx to był mój ostatni punkt, teraz mogę debugować asp.net mvc 4 hohoho!
— citykid
1

cóż, dla mnie było inaczej. Brakowało mi złożenia projektu aplikacji konsoli z projektem MVC. Tak więc dodanie referencji nie wystarczyło.

cóż, może to pomóc komuś innemu. przejdź do głównego pliku web.config system.web-> compilation-> dodaj odniesienie do projektu w ten sposób.

<assemblies> <add assembly="Your.Namespace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/> </assemblies>

— Jawand Singh
źródło
1

Miałem też ten sam problem, ale problem dotyczył ramy docelowej zespołu .

Przywoływany zestaw znajdował się w programie .NET Framework 4.6, w którym projekt został ustawiony na platformę .NET Framework 4.5.

Mam nadzieję, że pomoże to komuś, kto pomylił się z frameworkami.

— Geeganage
źródło
1

Twoja nazwa FOLDERU projektu musi być taka sama. Jeśli nazwa Twojego projektu lub rozwiązania jest inna, MVC cię skrzywdzi.

Przykład: Jeśli utworzysz nową aplikację i otrzyma ona domyślną nazwę Webapplicaiton1, zostanie utworzona ta przestrzeń nazw. Więc powiedzmy, że nie chcesz mieć tej przestrzeni nazw, więc z VS zmieniasz się wszędzie, gdzie widzisz, na „MyNamespace”. Wyszukujesz i zamieniasz cały kod z „Webapplication1” i zastępujesz go „MyNamespace”. Spowoduje to również zmianę pliku web.config, tak aby zawierał plik

Teraz wszystko będzie działać, z wyjątkiem widoków Razor.

RazorViews nie może go znaleźć, ponieważ istnieje jakaś dziwna zależność od FOLDERNAME projektu. To okropny projekt.

Przetestowałem to częściowo dokładnie, kopiując moje pliki do nowego rozwiązania, a jedyną różnicą jest nazwa folderu.

— Jens Tandstad
źródło
Niesamowite, jakie to śmieszne! Zmieniłem nazwę folderu projektu na właściwą, otworzyłem rozwiązanie w pliku tekstowym i poprawiłem opis folderu! Zadziałało! Używam Visual Studio 2019
— Daniel,
0

Spróbuj dodać przestrzeń nazw, w której się MyClassesznajdujesz, do pliku web.config w

<pages> <namespaces></namespaces> </pages>

— amurra
źródło
0

obejmują całą przestrzeń nazw

@model namespace.myclasses.mymodel
— Brettski
źródło
0

Żaden z tych https://stackoverflow.com/a/7597360/808128 nie działa dla mnie. Nawet „dodawanie odwołania do zestawu do sekcji system.web / compilation / assemblies w głównym pliku web.config”. Pozostają więc dla mnie dwa sposoby: 1) dodanie publicznej klasy zawijania dla mojego zestawu, do której kod Razor może uzyskać dostęp do tego zestawu za pośrednictwem tego zawijania; 2) po prostu dodaj logikę zestawu do klasy publicznej w tym samym zestawie, w którym znajduje się kod Razor.

— user808128
źródło
0

Oprócz wprowadzania zmian w pliku web.config dla <assemblies>i<namespaces> , odkryłem, że GAC-owanie zestawu spowodowało dużą różnicę. Możesz zastosować token klucza publicznego i kultury, tak jak każdy podstawowy zestaw .NET zarejestrowany globalnie.

Niektórzy mogą wzdrygnąć się na wzmiankę o GAC. Ale jako programista BizTalk nauczyłem się tego.

— Znaki
źródło
0

To rozwiązanie zadziałało dla mnie (to zabawne, ale działa)

Edytowałem strony widoku i skopiowałem zawartość i wkleiłem w to, nie zmieniałem żadnej treści widoków, ale po prostu zredagowałem, aby studio wizualne mogło śledzić strony, a potem wszystko zaczęło działać

Rozwiązanie - po prostu edytuj strony i zamień na te same strony (działało dla mnie)

— Arun Prasad ES
źródło
0

w modelach spacename, yourClassModel, dodaj public przed name class

public class yourClassModel{
    prop
}
— Milad Jafari
źródło
0

W moim przypadku pakiet, którego próbowałem użyć, odwoływał się do standardu .net 2.1, podczas gdy mój projekt biblioteki klas maszynki do golenia był ustawiony na 2.0

— Denis Reichelt
źródło
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.