La vue doit provenir de WebViewPage ou de WebViewPage <TModel>.
Je suis le tutoriel d'architecture de plugin de Justin Slattery et j'essaie de l'adapter à Razor au lieu de WebForm Views.
Tout le reste (contrôleurs, chargement du plugin Assembly, etc.) semble bien se passer. Cependant, je ne parviens pas à faire fonctionner correctement les vues Razor intégrées. Lorsque j'essaie d'accéder à "HelloWorld/Index", j'obtiens le message d'erreur suivant:
The view at '~/Plugins/MyProjectPlugin.dll/MyProjectPlugin.Views.HelloWorld.Index.cshtml' must derive from WebViewPage or WebViewPage<TModel>.
L'exception est levée par System.Web.Mvc.RazorView.RenderView(ViewContext viewContext, TextWriter writer, Object instance) +262
Je peux inclure la trace complète de la pile, si nécessaire.
Quelqu'un peut-il me dire ce que je peux faire de mal?
Vous pouvez consulter le blog post suivant qui est plus adapté à Razor.
Mais pour répondre à votre question, étant donné que vous transmettez maintenant vos vues depuis un emplacement non standard, le fichier ~/Views/web.config n’applique plus et vous permet de spécifier le type de base de vos vues rasoir. Vous devrez donc peut-être ajouter les éléments suivants en haut de chaque vue de rasoir:
@inherits System.Web.Mvc.WebViewPage
@model ...
Remarque: j'ai eu un problème extrêmement similaire et j'ai finalement dû découvrir que j'étais le seul développeur avec MVC 4.0.0.0 lié dans leur solution.
Tous les autres utilisateurs avaient correctement référencé 3.0.0.0 et étaient en train de construire/exécuter sans erreur.
TL; DR Assurez-vous que vos références sont identiques à celles du reste de votre groupe de développement.
J'ai eu le même problème car je n'ai pas validé le dossier packages qui contient les bibliothèques rasoir. Ensuite, j'ai ajouté le paquet, ça a fonctionné, mais après la reconstruction, il est tombé en panne. Ensuite, j'ai désactivé l'exécution automatique du nuget au moment de la compilation et maintenant tout fonctionne correctement .. Dans mon cas, le nuget a tout gâché.
J'ai eu cette erreur lorsque j'ai essayé d'ajouter un échafaudage MVC (en particulier le dossier Views) à un projet d'API Web. La réponse de Darin Dimitrov dit:
il n'y a plus de fichier
~/Views/web.configqui s'applique et vous permet de spécifier le type de base pour vos vues rasoir
Et dans les commentaires sur cette réponse, joelnet a dit :
J'ai pu copier le fichier web.config de ~/Views vers mon autre emplacement pour résoudre le problème.
et Paul d'Aoust a dit :
Si vous rencontrez des difficultés pour faire fonctionner la solution du commentaire @ joelnet, essayez de nettoyer et de reconstruire le projet.
Ces indices m'ont aidé à trouver la solution.
J'ai d'abord copié le Web.config du dossier Views d'un autre projet de la même solution dans mon nouveau dossier Views. J'ai renommé la balise namespace principale afin qu'elle corresponde au nouveau projet et, après avoir obtenu une erreur, j'ai supprimé un autre <add namespace="..." /> dont je n'avais pas besoin. J'ai ensuite déclenché une construction (uniquement une construction normale, je n'avais pas besoin de nettoyer ni de reconstruire) et j'ai pu charger ma nouvelle vue sans erreur.
Je souhaite partager ma douleur. Le site fonctionnait bien localement. Toutefois, lorsque j'ai publié le fichier IIS du client, cette erreur était générée. Tous les fichiers web.config (root et/Views) correspondaient parfaitement à une copie de travail du site.
L'une des vues (logon.cshtml) avait des fins de ligne incohérentes et je n'ai pas cliqué sur Oui pour résoudre le problème sur mon ordinateur Windows.
En cliquant sur oui dans la boîte de dialogue des fins de ligne incohérentes et en publiant la vue logon.cshtml, cela a été corrigé.
Je viens de recevoir cette erreur aujourd'hui lors de la mise à jour d'un ancien projet MVC3 vers la version 4 et la solution pour moi consistait à supprimer l'attribut appliesTo="v2.0.50727" dans la section <assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">.