404 – Une méthode d’action publique X n’a ​​pas été trouvée sur le contrôleur Y (ActionInvoker.InvokeAction renvoie false)

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:

Session de débogage Visual Studio

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:

  1. Cela fonctionnait très bien à un moment donné.
  2. Le verbe HTTP ( GET ) doit être accepté par l’action UpdateCart (voir les annotations au-dessus de la signature de la méthode).
  3. Les parameters envoyés ne sont pas pertinents: l’erreur se produit avec POST , GET et toute combinaison de parameters.
  4. D’autres actions similaires dans le même contrôleur fonctionnent bien.
  5. J’ai pris la capture d’écran avec UpdateCart marqué virtual , mais supprimer virtual ne fait aucune différence.
  6. La capture d’écran montre que 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.

entrer la description de l'image ici