J'essaie de créer une vue fortement typée basée sur une classe d'un autre assembly. Pour une raison quelconque, ma vue Razor ne semble pas avoir de visibilité sur les autres assemblys référencés sur mon projet. par exemple.
@model MyClasses.MyModel
entraîne l'erreur dans Visual Studio 2010: "Le nom du type ou de l'espace de nom MyClasses
est introuvable (vous manque une directive using ou une référence Assembly?)"
La même classe référencée dans le moteur de vue standard fonctionne bien. J'ai le même problème en essayant de faire référence à la classe dans le corps de ma vue.
Est-ce que je manque quelque chose à propos de Razor ou dois-je faire référence à l'Assemblée d'une autre manière?
Une nouvelle section de configuration est utilisée pour référencer les espaces de noms pour les vues Razor.
Ouvrez le fichier web.config
dans votre dossier Views
et assurez-vous qu’il contient les éléments suivants:
<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>
Vous pouvez également ajouter des instructions using à votre mise en page partagée:
@using Your.Namespace.Etc;
<!DOCTYPE html>
<head>
....
Après avoir modifié Web.config, redémarrez Visual Studio pour appliquer les modifications.
J'ai eu le même problème: Projet MVC3 MyCore.Web faisait référence à un espace de noms MyCore.DBLayer à partir d'un autre projet de la même solution (avec le nom d'assembly MyCoreDBLayer). Tous les objets de MyCore.DBLayer fonctionnaient parfaitement dans les contrôleurs et les modèles, mais échouaient dans les vues Razor avec une erreur 'Le nom de type ou d'espace de nom' DBLayer 'n'existe pas dans l'espace de nom' MyCore '(vous manque-t-il une référence à Assembly?)' ce qui n'était évidemment pas le cas.
L'ajout du référent Assembly à la section system.web/compilation/assemblies du fichier racine web.config a résolu le problème. La section ressemble maintenant à:
<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>
Omettre la version, la culture et le jeton était acceptable pour le moment, mais devrait être corrigé à l'avenir.
Dans mon cas, le projet distinct qui contenait l'espace de nom était une application console. Le changer en une bibliothèque de classes a résolu le problème.
Aucune de ce qui précède n'a fonctionné pour moi non plus;
Mais j'ai finalement trouvé quelque chose qui a fonctionné pour moi:
C'était parce que ma sortie de construction se dirigeait vers bin\Debug\pour la configuration de débogage et bin\Release\pour les configurations de version. Dès que j'ai changé la configuration de construction en "bin \" pour toutes les configurations (comme dans l'image ci-dessous), tout a commencé à fonctionner comme il se doit !!!
Je ne sais pas pourquoi la séparation de vos versions dans les dossiers Release et Debug devrait entraîner la rupture de la syntaxe Razor, mais cela semble être dû au fait que quelque chose n'a pas pu trouver les assemblys. Pour moi, les projets qui avaient des problèmes de syntaxe de rasoir sont en réalité mes projets de «bibliothèque de rasoirs». Ils sont définis en tant que projets d'application, mais je les utilise en tant que bibliothèques de classes avec RazorGenerator pour compiler mes vues. Lorsque j'ai réellement essayé d'exécuter directement l'un de ces projets, l'erreur de configuration suivante a été générée:
Impossible de charger le fichier ou l'assembly 'System.Web.Helpers, Version = 3.0.0.0, Culture = neutre, PublicKeyToken = 31bf3856ad364e35 'ou l'un de ses dépendances. Le système ne peut pas trouver le fichier spécifié.
Cela me conduit à essayer de modifier la sortie de construction, car je remarque que pour tous les projets Web, la sortie de construction semble toujours se trouver directement dans le dossier bin, contrairement à la valeur par défaut pour les bibliothèques de classes, qui contiennent à la fois des dossiers de publication et de débogage.
Vous semblez chercher cette réponse: https://stackoverflow.com/a/4136773/176877
En d’autres termes, ouvrez le fichier Views\Web.Config (PAS la racine), et ajoutez l’espace de nom sous la balise 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>
Enregistrez cela, puis fermez et rouvrez le fichier Razor.
Si vous utilisez des zones, vous devrez le faire pour chaque Web.Config de chaque zone.
Au fil des années, Visual Studio a eu des problèmes. Il peut donc être nécessaire de fermer le fichier Razor à l'aide d'une version de débogage, puis de rouvrir le fichier Razor, ou, dans le pire des cas, de redémarrer Visual Studio. Mais en fin de compte, il vous présentera le fichier Razor, comme si tout dans la liste des espaces de noms se trouvait dans des instructions @ en haut de toutes vos vues.
Pour moi, je faisais référence à un projet qui était une application console. Il a été configuré pour générer en tant qu'exe (application console) au lieu d'une bibliothèque de classes (DLL). Quand j'ai changé cela, j'ai pu voir les modèles de ce projet séparé sans problème.
Dans ASP.NET Core MVC , la solution consiste à ajouter un using
dans _ViewImports.cshtml au lieu de le placer web.config dans le dossier View lorsque vous utilisez 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
Vue
@model LoginViewModel // Add to _ViewImports to make this line work
<div>This is the View for the login screen.</div>
Je recevais une erreur similaire après avoir déplacé ma machine de développement de Win7 32 bits à Win7 64 bits. Message d'erreur:
...\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
Il s'avère que j'avais les deux versions dans le GAC. La vue web.config
faisait référence à la v1 mais l'application faisait référence à la v2. Suppression des assemblages référencés et ajout de la v1. de System.Web.WebPages.Razor
, etc.
J'avais la même erreur en essayant d'utiliser des objets Smo dans une vue Razor . Apparemment, c'est parce que Razor ne peut pas trouver les DLL référencées dans le projet . J'ai résolu ce problème en définissant "Copy Local" sur true Pour toutes les dlls Smo, cependant, il pourrait y avoir une meilleure solution (voir le lien de Czechdude ci-dessus) @ éditer et web.config sont inutilisables Serveur au lieu de Microsoft.SqlServer.Management.Smo.Server)
J'avais aussi le même problème, mais c'était avec le cadre Target de l'Assemblée.
L'assembly référencé se trouvait dans .NET Framework 4.6 où le projet a été défini sur .NET Framework 4.5.
J'espère que cela aidera quelqu'un qui a eu des problèmes avec les frameworks.
eh bien, pour moi c'était différent. Il me manquait l'assemblage de mon projet d'application console avec le projet MVC. Donc, ajouter une référence n'était pas suffisant.
cela pourrait aider quelqu'un d'autre. Accédez au fichier racine web.config system.web
-> compilation
-> ajoutez votre référence de projet comme ceci.
<assemblies>
<add Assembly="Your.Namespace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</assemblies>
Essayez d’ajouter l’espace de nom dans lequel votre MyClasses
se trouve dans le fichier web.config sous
<pages>
<namespaces></namespaces>
</pages>
inclure tout l'espace de noms
@model namespace.myclasses.mymodel
En plus d'apporter les modifications web.config pour <assemblies>
et <namespaces>
, j'ai constaté que GAC 'Assembly faisait une grande différence. Vous pouvez appliquer un jeton de culture et de clé publique comme tout assemblage .NET principal enregistré globalement.
Certains peuvent frémir à la mention du GAC. Mais en tant que développeur BizTalk, j'ai appris à l'accepter.
Aucune de celles-ci https://stackoverflow.com/a/7597360/808128 ne fonctionne pour moi. Même "ajouter Assembly referecene à la section system.web/compilation/assemblies du fichier racine web.config". Il me reste donc deux moyens: 1) d’ajouter une classe de bouclage public à mon Assemblée à laquelle le code Razor peut accéder à cette Assemblée par le biais de ce bouclage; 2) ajoutez simplement la logique d'assemblage à une classe publique dans l'assembly dans lequel se trouve le code de Razor.
dans les modèles spacename, yourClassModel, ajouter public avant name class
public class yourClassModel{
prop
}
Cette solution a fonctionné pour moi (c'est drôle, mais ça marche)
J'ai édité les pages de vue, copié le contenu et collé dessus. Je n'ai modifié aucun contenu des vues, mais je l'ai simplement modifié pour que Visual Studio puisse faire le suivi des pages, puis tout a commencé à fonctionner.
Solution - Éditez simplement les pages et remplacez-les par les mêmes pages (Fonctionne pour moi)
Votre nom de dossier de projet doit être identique. Si le nom de votre projet ou de votre solution est différent, MVC vous blessera.
Exemple: Si vous créez une nouvelle application et qu'elle obtient le nom par défaut Webapplicaiton1, cet espace de noms sera créé. Donc, disons que vous ne voulez pas avoir cet espace de noms, donc du VS vous changez partout où vous pouvez voir "MyNamespace" Vous recherchez également et remplacez tout le code de "Webapplication1" et le remplacez par "MyNamespace". Cela change également le fichier web.config, de sorte qu’il
Maintenant, tout fonctionnera, sauf les vues Razor.
RazorViews ne peut pas le trouver, car il existe une sorte de dépendance étrange sur le FOLDERNAME du projet. C'est un design terrible.
J'ai testé cela de manière approfondie en copiant mes fichiers dans une nouvelle solution, la seule différence étant le nom de pliage.