Ce n’est PAS une question en double et le problème me rend fou. Je reçois l’erreur type “Une méthode d’action publique X n’a pas été trouvée sur le contrôleur Y” qui renvoie un 404 Not Found
. La capture d’écran vous donne une bonne idée:
L’image montre le débogueur mis en pause juste avant la ligne qui lance l’exception est exécutée ( base.HandleUnknownAction(actionName)
). Maintenant, avant de sauter dans les conclusions, voici quelques informations:
GET
) doit être accepté par l’action UpdateCart
(voir les annotations au-dessus de la signature de la méthode). POST
, GET
et toute combinaison de parameters. UpdateCart
marqué virtual
, mais supprimer virtual
ne fait aucune différence. ActionInvoker.InvokeAction(this.ControllerContext, "UpdateCart")
renvoie false . Je ne sais pas pourquoi la reflection effectuée sur mon contrôleur ne trouve pas la méthode, mais il est bien là! Les routes sont celles par défaut et elles fonctionnent, sinon je n’aurais pas pu arrêter le débogueur pour prendre la capture d’écran ci-dessus. Voici le code de Global.asax.cs
:
public static void RegisterRoutes(RouteCollection routes) { routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); routes.MapRoute( "Default", // Route name "{controller}/{action}/{id}", // URL with parameters new { controller = "Tickets", action = "Index", id = UrlParameter.Optional } ); }
Toutes les idées sont grandement appréciés.
MODIFIER
La réponse d’Ethan Brown ci-dessous est correcte: HttpGet
et HttpPost
s’excluent mutuellement. La solution consistait à remplacer ces atsortingbuts par [AcceptVerbs(HttpVerbs.Get | HttpVerbs.Post)]
.
Le problème est que vous spécifiez à la fois les HttpGet
et HttpPost
. Si vous les laissez tous deux désactivés, l’action accepte les requêtes POST et GET. HttpGet
que les HttpGet
et HttpPost
ne signalent pas à MVC d’autoriser le type de requête correspondant, mais de refuser le type opposé. Donc, en incluant [HttpPost]
, vous refusez les requêtes GET, et en incluant [HttpGet]
, vous refusez les requêtes POST … en refusant tous les types de requêtes. Laissez les atsortingbuts désactivés et les deux types seront acceptés.
Mise à jour : Je viens de vérifier la source MVC et mon hypothèse est correcte. Dans ActionMethodSelector
, il vérifie les atsortingbuts ainsi:
if (attrs.All(attr => attr.IsValidForRequest(controllerContext, methodInfo))) { matchesWithSelectionAtsortingbutes.Add(methodInfo); }
En d’autres termes, tous les ActionMethodSelectorAtsortingbute
(dont dérivent HttpPostAtsortingbute
et HttpGetAtsortingbute
) doivent retourner true pour l’action à appeler. L’un ou l’autre retournera toujours faux, ainsi l’action ne s’exécutera jamais.
Attention: dans mon cas, j’obtiens une erreur 500 en essayant d’atteindre une nouvelle méthode d’action.
Erreur détaillée IIS 8.5 – 500.0 – Une méthode d’action publique ‘getwells’ n’a pas été trouvée sur le contrôleur ‘ITVizion.VizionLogs.Widgets.Controllers.MapController’.
J’ai ajouté la méthode d’action au contrôleur et “déployais” l’application mise à jour sur IIS.
Le problème: je déployais la configuration Debug
dans Visual Studio et j’avais décoché ce projet spécifique de la construction. Cela devait accélérer la création de Visual Studio, car la solution comporte de nombreux projets. : D En allant dans le dossier de l’application IIS, j’ai vu que la DLL du projet était obsolète.
Donc, assurez-vous de vérifier le projet à construire. 🙂 Cela permettra évidemment de déployer le nouveau codez sur IIS.