In der messerbasierten Ansicht werden keine referenzierten Assemblys angezeigt


101

Ich versuche, eine stark typisierte Ansicht basierend auf einer Klasse aus einer anderen Assembly zu erstellen. Aus irgendeinem Grund scheint meine Razor-Ansicht keine Sichtbarkeit anderer Assemblys zu haben, auf die in meinem Projekt verwiesen wird. z.B

@model MyClasses.MyModel

führt in Visual Studio 2010 zu dem Fehler "Der Typ- oder Namespace-Name wurde MyClassesnicht gefunden (fehlt Ihnen eine using-Direktive oder eine Assembly-Referenz?)."

Dieselbe Klasse, auf die in der Standardansicht-Engine verwiesen wird, funktioniert einwandfrei. Ich habe die gleichen Probleme beim Versuch, die Klasse im Hauptteil meiner Ansicht zu referenzieren.

Vermisse ich etwas an Razor oder muss ich auf andere Weise auf die Baugruppe verweisen?


Verwenden Sie den gesamten Namespace? @model namespace.myclasses.mymodel vielleicht?
Brettski

Antworten:


107

Es gibt einen neuen Konfigurationsabschnitt, in dem auf Namespaces für Razor-Ansichten verwiesen wird.

Öffnen Sie die web.configDatei in Ihrem ViewsOrdner und stellen Sie sicher, dass sie Folgendes enthält:

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

Alternativ können Sie Ihrem freigegebenen Layout mithilfe von Anweisungen hinzufügen:

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

Starten Sie Visual Studio nach dem Bearbeiten der Datei Web.config neu, um die Änderungen zu übernehmen.


18
Dies funktioniert jedoch, stellen Sie sicher, dass auf Ihre Assemblys verwiesen wird Copy Local = true. Externe Baugruppen funktionieren möglicherweise nicht anders.
Terry

1
Hierbei ist zu beachten, dass Sie, wenn Sie Ansichten aus einer "virtuellen" Quelle (z. B. der Datenbank) anstelle von realen Ansichtsdateien verwenden, diese in die Datei ROOT web.config einfügen müssen, damit der Code in den Ansichten funktioniert.
NightOwl888

2
@ Terry, es scheint, dass Copy local = true auch für einige Assemblys mit Systemstammnamen erforderlich ist.
Dan Esparza

2
Meine Assemblys werden zur Laufzeit geladen, daher kann ich sie nicht mit der Datei web.config hinzufügen. Kann ich noch etwas ausprobieren? Gibt es eine Möglichkeit, meine externen Ansichten mit ihren eigenen web.config-Dateien zu importieren? Es ist ziemlich seltsam, weil ich auf Namespaces innerhalb derselben Assembly wie meine Ansichten verweise.
Maksim Vi.

Ein Neustart von Visual Studio ist nicht erforderlich. Es reicht aus, die Ansichten einfach zu schließen und wieder zu öffnen.
user247702

58

Ich hatte das gleiche Problem: MVC3-Projekt MyCore.Web verwies auf den Namespace MyCore.DBLayer aus einem anderen Projekt in derselben Lösung (mit dem Assemblynamen MyCoreDBLayer). Alle Objekte aus MyCore.DBLayer funktionierte perfekt in Controller und Modelle aber in Razor Ansichten mit einem Fehler fehlgeschlagen ‚Der Typ oder Namespace - Name‚DBLayer‘existiert nicht im Namensraum‚MyCore‘(möglicherweise fehlt ein Assemblyverweis?)‘ , Die wurde offensichtlich nicht der Fall.

  • Die Option Lokal kopieren wurde auf true gesetzt.
  • Das Hinzufügen von "using ..." - Anweisungen in Razor-Ansichten war nutzlos
  • Das Hinzufügen von Namespaces zum Abschnitt system.web.webPages.razor war ebenfalls nutzlos

Durch Hinzufügen einer Assemblyreferenz zum Abschnitt system.web / compilation / Assemblys der Root-Datei web.config wurde das Problem behoben. Der Abschnitt sieht jetzt so aus:

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

Das Weglassen von Version, Kultur und Token war vorerst in Ordnung, sollte aber in Zukunft behoben werden.


Diese Lösung funktioniert, ist aber eine schlechte Idee. Als ich alle meine Klassen intern machte und die Webassembly zu einem Freund von MyCoreDBLayer machte, funktionierte sie nicht mehr. Am Ende schrieb ich eine öffentliche Klasse als MVC-Modell, die meine Klassen von Freundversammlungen umschließt. Ich glaube, man sollte keine anderen Klassen als den Modell-Namespace von MVC in Razor-Ansichten verwenden - es ist immer möglich, einen Wrapper zu schreiben
VB

Das hat bei mir funktioniert, ich habe versucht, es dem hinzuzufügen, Views/web.configund es hat funktioniert, als es auch dort platziert wurde.
Guanome

18

In meinem Fall war das separate Projekt, das den Namespace enthielt, eine Konsolenanwendung. Das Ändern in eine Klassenbibliothek hat das Problem behoben.


1
Das hat es für mich gelöst. Zuerst habe ich versucht, eine Klassenbibliothek (Paket) zu erstellen, aber es gab Probleme beim Verweisen auf ein Nuget-Paket, das ich benötigte. Am besten nicht schick werden und einfach eine einfache Klassenbibliothek (DLL)
erstellen

15

Keiner der oben genannten Punkte hat auch für mich funktioniert.

  • DLLs wurden auf Lokal kopieren gesetzt
  • Das Hinzufügen von Namespaces zu beiden web.configs hat nichts bewirkt
  • Das Hinzufügen von Assembly-Referenzen zu system.web \ compilation \ Assemblys hat ebenfalls nicht geholfen (obwohl ich diese Referenzen nicht entfernt habe, kann es sein, dass sie auch benötigt werden).

Aber ich habe endlich etwas gefunden, das für mich funktioniert hat:

Dies lag daran, dass meine Build-Ausgabe für die Debug-Konfiguration in bin \ Debug \ und für die Release-Konfiguration in bin \ Release \ ging. Sobald ich die Build-Konfiguration für alle Konfigurationen in "bin \" geändert habe (siehe Abbildung unten), funktionierte alles wie gewünscht !!!

Konfiguration erstellen

Ich habe keine Ahnung, warum das Aufteilen Ihrer Builds in Release- und Debug-Ordner dazu führen sollte, dass die Razor-Syntax unterbrochen wird, aber es scheint, dass etwas die Assemblys nicht finden konnte. Für mich sind die Projekte, bei denen Probleme mit der Rasierersyntax auftraten, meine Projekte für die "Rasiererbibliothek". Sie sind als Anwendungsprojekte festgelegt, ich verwende sie jedoch als Klassenbibliotheken mit RazorGenerator, um meine Ansichten zu kompilieren. Als ich tatsächlich versuchte, eines dieser Projekte direkt auszuführen, verursachte es den folgenden Konfigurationsfehler:

Datei oder Assembly 'System.Web.Helpers, Version = 3.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die angegebene Datei wurde vom System nicht gefunden.

Dies führte mich zu dem Versuch, die Build-Ausgabe zu ändern, da ich feststelle, dass sich die Build-Ausgabe bei allen Webprojekten immer direkt im bin-Ordner befindet, im Gegensatz zum Standard für Klassenbibliotheken, die sowohl Release- als auch Debug-Ordner haben.


1
Haben durch die Art und Weise bestätigt, dass Sie den Abschnitt system.web \ compilation \ Assemblys nicht benötigen, sobald sich die DLLs direkt im Ordner bin befinden. Dies kann darauf zurückgehen, nur <compilation debug = "true" targetFramework = "4.5.1" /> zu sein
Sylvia

2
Heiliger Bimbam! Nachdem ich lange nach einer Lösung gesucht hatte, löste dies endlich meine Razor-Ansichten in einem Klassenbibliotheksprojekt !! Ich danke dir sehr.
Hullah

2
Unglaublich! Ich habe meine Klassenbibliothek mit Ansichten in das Verzeichnis eines anderen Projekts eingebaut und hatte dieses Problem. Der Erstellungspfad muss bin \ sein, damit dies funktioniert. Verwenden Sie jetzt stattdessen Post-Build-Xcopy.
GlacialSpoon

1
Ich verwende die Razor Engine in einem Klassenbibliotheksprojekt und habe das gleiche Problem. Das Setzen des Ausgabepfads auf "bin \" hat dieses Problem auch für mich gelöst. Wie GlacialSpoon kopiere ich die Assembly in einem Post-Build-Schritt in den richtigen Ausgabeordner. Nicht der beste Weg, aber zumindest Intellisense, das Verweisen auf Assemblys und das Hervorheben von Syntax funktioniert.
Octoate

Es ist erwähnenswert, dass das ursprüngliche Problem auftritt, wenn Ihr benutzerdefiniertes Ausgabeverzeichnis auf a zeigt übergeordnetes Verzeichnis ala '.. \ some \ dir \' . Wenn Sie jedoch das Ausgabeverzeichnis in "some \ dir \" ändern, funktioniert alles einwandfrei. Dies ist sicher ein teuflischer Fehler in der Matrix.
XDS

7

Sie scheinen nach dieser Antwort zu suchen: https://stackoverflow.com/a/4136773/176877

Öffnen Sie also die innere Ansicht \ Web.Config (NICHT die Stammansicht) und fügen Sie den Namespace unter dem Tag Pages hinzu:

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

Speichern Sie das, schließen Sie die Razor-Datei und öffnen Sie sie erneut.

Wenn Sie Bereiche verwenden, müssen Sie dies für jede Web.Config in jedem Bereich tun.

Visual Studio ist im Laufe der Jahre fehlerhafter geworden, sodass möglicherweise die Razor-Datei geschlossen werden muss, in der ein Debug-Build ausgeführt wird, und die Razor-Datei erneut geöffnet werden muss, oder im schlimmsten Fall ein Neustart von Visual Studio erforderlich ist. Letztendlich wird Ihnen die Razor-Datei jedoch so angezeigt, als ob sich alles in dieser Namespace-Liste in @ using-Anweisungen oben in all Ihren Ansichten befindet.


4

In ASP.NET Core MVC besteht die Lösung darin, eine usingin _ViewImports.cshtml hinzuzufügen, anstatt sie web.config im Ordner View abzulegen, wenn Sie mit ASP.NET MVC 5 arbeiten.

_ViewImports.cshtml

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

Aussicht

@model LoginViewModel // Add to _ViewImports to make this line work
<div>This is the View for the login screen.</div>

3

Für mich bezog ich mich auf ein Projekt, das eine Konsolenanwendung war. Es wurde als exe (Konsolenanwendung) anstelle der Klassenbibliothek (DLL) erstellt. Als ich dies änderte, konnte ich die Modelle aus diesem separaten Projekt problemlos sehen.


Dank @ user1619480 hatte ich das gleiche Problem und in meinem Fall aus einer .NET Framework-Klassenbibliothek, die ich mit VS 2017 hinzugefügt habe, und aus irgendeinem Grund war der Ausgabetyp Konsolenanwendung.
Danfer

1

Beim Versuch, Smo-Objekte in einer Razor-Ansicht zu verwenden, wurde der gleiche Fehler angezeigt. Anscheinend liegt dies daran, dass Razor die DLLs, auf die im Projekt verwiesen wird, nicht finden kann. Ich habe dieses Problem behoben, indem ich "Copy Local" für alle Smo-DLLs auf "true" gesetzt habe. Es gibt jedoch möglicherweise eine bessere Lösung (siehe Link von Czechdude oben). @ Using und web.config-Änderungen sind nutzlos, da sie nur benötigt werden, wenn Sie den Namespace weglassen möchten Teil von den Typnamen (zum Beispiel Server anstelle von Microsoft.SqlServer.Management.Smo.Server)


1

Ich habe einen ähnlichen Fehler erhalten, nachdem ich meine Entwicklungsmaschine von Win7 32bit auf Win7 64bit verschoben habe. Fehlermeldung:

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

Es stellte sich heraus, dass ich beide Versionen im GAC hatte. Die Ansicht web.configverwies auf Version 1, aber die App verwies auf Version 2. Die referenzierten Assemblys wurden entfernt und v1 erneut hinzugefügt. von System.Web.WebPages.Razorusw.


+1 thx das war mein letzter Punkt, jetzt kann ich asp.net mvc 4 hohoho debuggen!
Citykid

1

Nun, für mich war es anders. Mir fehlte die Zusammenstellung meines Konsolenanwendungsprojekts mit dem MVC-Projekt. Das Hinzufügen von Referenzen reichte also nicht aus.

Nun, das könnte jemand anderem helfen. Gehen Sie zur Root-Datei web.config system.web-> compilation-> fügen Sie Ihre Projektreferenz wie folgt hinzu.

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


1

Ich hatte auch das gleiche Problem, aber das Problem war mit dem Ziel-Framework der Assembly .

Die Assembly, auf die verwiesen wird, befand sich in .NET Framework 4.6, wo das Projekt auf .NET Framework 4.5 festgelegt wurde.

Hoffe, dies wird jemandem helfen, der mit Frameworks durcheinander gebracht hat.


1

Der Name Ihres Projektordners muss identisch sein. Wenn Ihr Projekt- oder Lösungsname unterschiedlich ist, verletzt Sie MVC.

Beispiel: Wenn Sie eine neue Anwendung erstellen und diese den Standardnamen Webapplicaiton1 erhält, wird dieser Namespace erstellt. Nehmen wir also an, Sie möchten diesen Namespace nicht haben. Von VS aus ändern Sie sich also überall, wo Sie "MyNamespace" sehen können. Sie suchen und ersetzen auch den gesamten Code aus "Webapplication1" und ersetzen ihn durch "MyNamespace". Dadurch wird auch die Datei web.config geändert, sodass sie enthalten ist

Jetzt wird alles funktionieren, außer Razor-Ansichten.

RazorViews kann es nicht finden, da es eine seltsame Abhängigkeit vom FOLDERNAME des Projekts gibt. Es ist schreckliches Design.

Ich habe dies halb gründlich getestet, indem ich meine Dateien in eine neue Lösung kopiert habe. Der einzige Unterschied ist der Ordnername.


Unglaublich, wie lächerlich das ist! Ich habe den Namen des Projektordners nach rechts umbenannt und die Lösung in einer Textdatei geöffnet und die Ordnerbeschreibung korrigiert! Es funktionierte! Ich benutze Visual Studio 2019
Daniel

0

Versuchen Sie, den Namespace, in dem Sie sich MyClassesbefinden, zur Datei web.config unter hinzuzufügen

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


0

Schließen Sie den gesamten Namespace ein

@model namespace.myclasses.mymodel

0

Keine dieser https://stackoverflow.com/a/7597360/808128 funktioniert für mich. Sogar "Hinzufügen von Assembly-Referenzen zum Abschnitt system.web / compilation / Assemblys der Root-Datei web.config". Ich habe also zwei Möglichkeiten: 1) Hinzufügen einer öffentlichen Wrap-Klasse für meine Assembly, auf die Razor-Code über diesen Wrap auf diese Assembly zugreifen kann; 2) Fügen Sie einer öffentlichen Klasse in derselben Assembly, in der sich der Razor-Code befindet, einfach Assembly-Logik hinzu.


0

Zusätzlich zum Ändern der web.config für <assemblies>und<namespaces> stellte ich fest, dass das GAC der Assembly einen großen Unterschied machte. Sie können Kultur- und Public-Key-Token wie jede global registrierte .NET-Kernassembly anwenden.

Einige mögen bei der Erwähnung des GAC schaudern. Aber als BizTalk-Entwickler habe ich mich darauf eingestellt.


0

Diese Lösung hat bei mir funktioniert (Es ist lustig, funktioniert aber)

Ich habe die Ansichtsseiten bearbeitet und den Inhalt kopiert und eingefügt. Ich habe keinen Inhalt der Ansichten geändert, sondern nur bearbeitet, damit das Visual Studio die Seiten nachverfolgen kann, und danach hat alles funktioniert

Lösung - Bearbeiten Sie einfach die Seiten und ersetzen Sie sie durch dieselben Seiten (bei mir funktioniert)


0

Fügen Sie in Raumnamenmodellen, yourClassModel, public vor der Namensklasse hinzu

public class yourClassModel{
    prop
}

0

In meinem Fall bezog sich das Paket, das ich verwenden wollte, auf .net Standard 2.1, während mein Projekt für die Rasiermesserklassenbibliothek auf 2.0 festgelegt war

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.