आंतरायिक asp.net mvc अपवाद: "एक सार्वजनिक कार्रवाई विधि एबीसी नियंत्रक XYZ पर नहीं पाया जा सकता है।"

Question

मुझे यह कहते हुए एक अपवाद मिल रहा है कि asp.net mvc एक्शन विधि नहीं पा सकता है। यहाँ अपवाद है:

नियंत्रक 'Schoon.Form.Web.Controllers.ChrisController' पर एक सार्वजनिक कार्रवाई पद्धति 'भरण' नहीं पाई जा सकी।

मुझे लगता है कि मेरे पास रूटिंग सही ढंग से सेट है क्योंकि यह एप्लिकेशन ज्यादातर समय काम करता है। यहाँ नियंत्रक की क्रिया विधि है।

[ActionName("Fill")]
[AcceptVerbs(HttpVerbs.Get | HttpVerbs.Post), UserIdFilter, DTOFilter]
public ActionResult Fill(int userId, int subscriberId, DisplayMode? mode)
{
     //…
}

मार्ग:

routes.MapRoute(
        "SchoonForm",
        "Form/Fill/{subscriberId}",
        new { controller = "ChrisController", action = "Fill" },
        new { subscriberId = @"\d+" }
    );

और यहाँ स्टैक है:

System.Web.HttpException: एक पब्लिक एक्शन मेथड 'Fill' कंट्रोलर 'Schoon.Form.Web.Controllers.ChrisController' पर नहीं पाया जा सकता है। System.Web.Mvc.Controller.HandleUnognAction (स्ट्रिंग कार्रवाईनाम) में C: \ dev \ ThirdParty \ MvcDev \ src \ SystemWebMvc \ Mvc \ Controller.cs, पंक्ति 197 System.Web.Mvc.Controller.ExecuteCore () C पर : \ dev \ ThirdParty \ MvcDev \ src \ SystemWebMvc \ Mvc \ Controller.cs: पंक्ति 164 में System.Web.Mvc.ControllerBase.Execute (RequestContext requestCuttext) C: \ dev \ ThirdParty \ MvcDev \ src \ SystemWebMvc पीवीसी। ControllerBase.cs: Line 76 System.Web.Mvc.ControllerBase.System.Web.Mvc.IController.Execute (RequestContext requestContext) C में: \ dev \ thirdParty / MvcDev \ src \ SystemWebMvc \ Mvc \ ControllerBase.cs: पंक्ति 87 System.Web.Mvc.MvcHandler.ProcessRequest (HttpContextBase httpContext) में C:

यहाँ मेरे फिल्टर का एक उदाहरण है, वे सभी उसी तरह काम करते हैं:

public class UserIdFilter : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        const string Key = "userId";

        if (filterContext.ActionParameters.ContainsKey(Key))
        {
            filterContext.ActionParameters[Key] = // get the user id from session or cookie
        }

        base.OnActionExecuting(filterContext);
    }
}

धन्यवाद, क्रिस

Comments

मुझे इसी तरह की समस्या थी जो मुझे लगता है कि यहां ध्यान देने योग्य है क्योंकि यह पहला परिणाम था जो Google में ऊपर अपवाद को खोजते समय सामने आया था। मेरे आवेदन ने अमान्य फॉर्म जमा करते समय इस अपवाद को फेंक दिया। यह उस पृष्ठ के कारण था जो (पुनः) रेंडरएशन को कॉल कर रहा था और एक आंशिक दृश्य को रेंडर करने के लिए कॉल की गई कार्रवाई को HttpGet विशेषता के साथ चिह्नित किया गया था, इस विशेषता को हटाकर समस्या का समाधान किया गया।

— s1mm0t

मैंने इस व्यवहार पर ध्यान दिया है - शायद इसके लिए सबसे अच्छा है कि किसी भी Http विशेषताओं को लागू न करने के लिए कंट्रोलर के तरीके जो PartialViewResults लौटाएँ।

— स्टुअर्ट

@ s1mm0t: सही है। मेरे मामले के लिए, उनकी टिप्पणी ने समस्या को हल कर दिया

— मजदक शोजाई

@ s1mm0t - कृपया मुझे अपना डाक पता तुरंत भेजें। स्कॉच की एक बोतल यह आपके लिए इस क्रिसमस पर है !!!!!

— शेन

हमने कुछ ऐसा ही पाया: कुछ मामलों में उस कार्रवाई के लिए एक पुनर्निर्देशन के बजाय एक अन्य कार्रवाई की वापसी समस्या पैदा कर रही थी। पूर्व में PostSomething { return HomePageActionMethod() }विफल रहता है जहां PostSomething { return RedirectToAction(nameof(HomePageActionMethod)); }काम करता है। (हमारे मामले में दृश्य में आपत्तिजनक कार्रवाई एक अलग नियंत्रक में स्थित है, और संभवतः कि नियंत्रक को कॉलिंग की पहली विधि के साथ पूरी तरह से आरंभ नहीं किया गया है।

— jleach

Answer 1

हमें जवाब मिल गया। हमने अपने वेब लॉग में देखा। इससे पता चला कि हम कुछ अजीब HTTP क्रियाओं (क्रियाओं / विधियों) को पसंद कर रहे हैं, जैसे विकल्प, PROPFIND और HEAD।

ऐसा कुछ अपवादों के कारण लगता है। यह बताता है कि यह क्यों आंतरायिक था।

हमने कर्ल। Exe टूल के साथ समस्या को पुन: प्रस्तुत किया:

curl.exe -X OPTIONS http://localhost/v2.3.1.0/(S(boztz1aquhzurevtjwllzr45))/Form/Fill/273
curl.exe -X PROPFIND http://localhost/v2.3.1.0/(S(boztz1aquhzurevtjwllzr45))/Form/Fill/273
curl.exe -X HEAD http://localhost/v2.3.1.0/(S(boztz1aquhzurevtjwllzr45))/Form/Fill/273

हमने जो फिक्स उपयोग किया था वह web.config में एक प्राधिकरण अनुभाग जोड़ने के लिए था:

<authorization>
  <deny users="*" verbs="OPTIONS, PROPFIND, HEAD"/>
</authorization>

Comments

हमने यह भी पाया है कि बॉट कुछ लिंक आपकी साइट को क्रॉल करेगा - और यहां तक ​​कि जावास्क्रिप्ट - लिंक खोजने के लिए। वे फिर गलत HTTP क्रिया के साथ इन यूआरआई को अनुरोध भेजने का प्रयास करते हैं। उदाहरण के लिए, यदि आपके पास कुछ कार्रवाई के लिए एक jQuery कॉल है - जैसे / कुछ-कार्रवाई और इस विधि के लिए POST की आवश्यकता होती है, तो बॉट एक GET भेजने का प्रयास कर सकता है, जिससे यह त्रुटि दिखाई देगी। यदि यह मामला था तो आपके वेब लॉग निश्चित रूप से पुष्टि करने में मदद कर सकते हैं। हम भी googlebot को ऐसा करते देखते हैं।

— जेकजगार्डन

मैं लाइव सर्वर (IIS 7.5) पर केवल यही त्रुटि कर रहा हूं। तैनाती मेरी विकास मशीन के साथ-साथ एक अन्य समर्थन मशीन पर ठीक काम करती है। इन क्रियाओं को जोड़ने और HttpGet को निकालने से समस्या ठीक नहीं हुई। कोई और सुझाव कृपया।

— भजन

आने वाले HEAD अनुरोधों को अस्वीकार करने का एक विकल्प, आप एक उचित प्रतिक्रिया की सेवा करना चाह सकते हैं। देखें stackoverflow.com/a/3197128/12484

— जॉन श्नाइडर

Answer 2

हमारे पास एक समान मुद्दा था, लेकिन पाया गया कि ऐसा इसलिए हो रहा था क्योंकि एक उपयोगकर्ता नियंत्रक के लिए पोस्ट कर रहा था, क्योंकि उसका लॉगिन समय समाप्त हो गया था। सिस्टम फिर लॉगिन स्क्रीन पर रीडायरेक्ट हो गया। इसमें लॉग इन करने के बाद, उस URL पर वापस भेज दिया जाता है, जिस पर उपयोगकर्ता पोस्ट करना चाहता था, लेकिन इस बार वह इसके बजाय GET अनुरोध कर रहा था और इसलिए उस कार्रवाई को नहीं ढूंढ रहा था जिसे [HttpPost] विशेषता के साथ चिह्नित किया गया था।

Comments

मेरा वर्तमान समाधान जितना संभव हो सके हमेशा एक कार्रवाई के अंत में सूचकांक कार्रवाई पर वापस निर्देशित करें। देरी से जवाब देने के लिए माफी।

— जोहान स्ट्रायडोम

Answer 3

मैं asp.net mvc में एक ही समस्या है। यह त्रुटि - 404 नहीं मिली। मैं इस तरह से समस्या का समाधान करता हूं - इस कोड को MyAppControllerBase(MVC) में डालें

    protected override void HandleUnknownAction(string actionName)
    {
        this.InvokeHttp404(HttpContext);
    }

    public ActionResult InvokeHttp404(HttpContextBase httpContext)
    {
        IController errorController = ObjectFactory.GetInstance<PagesController>();
        var errorRoute = new RouteData();
        errorRoute.Values.Add("controller", "Pages");
        errorRoute.Values.Add("action", "Http404");
        errorRoute.Values.Add("url", httpContext.Request.Url.OriginalString);
        errorController.Execute(new RequestContext(
             httpContext, errorRoute));

        return new EmptyResult();
    }

Answer 4

हमारे आवेदन पर हमारे पास बस यही मुद्दा था और मैं इसे जावास्क्रिप्ट / jquery मुद्दे पर ट्रेस करने में सक्षम था। हमारे पास Html.ActionLink () का उपयोग करके परिभाषित हमारे एप्लिकेशन में लिंक हैं जिन्हें बाद में jquery द्वारा POST में ओवरराइड किया जाता है।

पहले हमने लिंक को परिभाषित किया था:

Html.ActionLink("Click Me", "SomeAction", new { id = Model.Id})

बाद में हम अपने SomePostEventHandler फ़ंक्शन के साथ डिफ़ॉल्ट कार्रवाई को ओवरराइड करते हैं:

 $(document).ready(function() {
      $('#MyLink').click(SomePostEventHandler);
 }

यह हमारी MVC कार्रवाई को हिट कर रहा था जिसमें एक HttpPost फ़िल्टर था:

 [HttpPost]
 public ActionResult SomeAction(int id)
 {
      //Stuff
 }

हमने जो पाया वह यह है कि ज्यादातर समय यह काम किया। हालांकि, कुछ धीमे पृष्ठ लोड (या वास्तव में तेज़ उपयोगकर्ता) पर, उपयोगकर्ता $ jquery $ (दस्तावेज़) .ready () घटना से पहले लिंक पर क्लिक कर रहा था, जिसका अर्थ है कि वे इसके बजाय GET / नियंत्रक / SomeAction / XX की कोशिश कर रहे थे। पोस्टिंग।

हम नहीं चाहते कि उपयोगकर्ता उस यूआरएल को प्राप्त करें, इसलिए फ़िल्टर को हटाना हमारे लिए कोई विकल्प नहीं है। इसके बजाय हमने सीधे एक्शन लिंक के ऑनक्लिक ईवेंट को सीधे वायर्ड कर दिया (हमें काम करने के लिए SomePostEventHandler () को थोड़ा बदलना पड़ा):

string clickEvent = "return SomePostEventHandler(this);";

Html.ActionLink("Click Me", "SomeAction", new { id = Model.Id}, new { onclick = clickEvent })

तो, कहानी का नैतिक, कम से कम, हमारे लिए, यदि आप इन त्रुटियों को देख रहे हैं, तो उस URL को ट्रैक करें जिसे आप सोचते हैं कि आप पोस्ट कर रहे हैं और सुनिश्चित करें कि आप हैं।

Answer 5

मेरा भी यह मुद्दा था।

मेरे मामले में, यह अनुरोधित कार्रवाई पर क्रिया प्रतिबंधों से संबंधित था, जहां दृश्य एक POSTलेकिन आंशिक रूप से समर्थित GETऔर HEADकेवल अनुरोध के रूप में देखा जा रहा था । (MVC 1.0 में) POSTक्रिया को जोड़ने से AcceptVerbsAttributeसमस्या हल हो गई।

Answer 6

IIS लॉग से हमारी समस्या Googlebot द्वारा POST के लिए POST और GET का प्रयास करने से केवल नियंत्रक कार्रवाई के कारण हुई।

इस मामले के लिए मैं दिमित्री सुझाव जैसे 404 को संभालने की सलाह देता हूं।

Answer 7

वर्तमान में स्वीकृत उत्तर अपेक्षा के अनुरूप काम करता है लेकिन सुविधा के लिए प्राथमिक उपयोग का मामला नहीं है। इसके बजाय ASP.NET द्वारा परिभाषित सुविधा का उपयोग करें। मेरे मामले में, मैंने GET और POST:

  <system.webServer>
  <security>
      <requestFiltering>
          <verbs allowUnlisted="false">
              <add verb="GET" allowed="true"/>
              <add verb="POST" allowed="true"/>
          </verbs>
      </requestFiltering>
  </security>
 </system.webServer>

ऊपर कोड स्निपेट के साथ, एमवीसी सही ढंग से 404 लौटाएगा

Answer 8

यह नहीं होना चाहिए

routes.MapRoute(
        "SchoonForm",
        "Form/Fill/{subscriberId}",
        new { controller = "Chris", action = "Fill" },

इसके अलावा, आपके फ़िल्टर क्या करते हैं? क्या वे ActionMethodSelectorAttribute की तरह कार्रवाई छिपा नहीं सकते हैं?

Comments

यह एक संपादन गलती है। मैं मासूम को बचाने की कोशिश कर रहा था।

— क्रिस शून

वे कुछ मापदंडों को आबाद करते हैं। उदाहरण के लिए, UserIdFilter उपयोगकर्ता आईडी को सत्र / कुकी / आदि से प्राप्त करने के लिए एक सहायक है। यह पहले पैरामीटर को पॉप्युलेट करता है। मैं इसे शामिल करने के लिए पोस्ट संपादित करूंगा।

— क्रिस शॉन

Answer 9

मेरे पास इसी तरह का मुद्दा है qq फ़ाइल अपलोड के

जब पोस्ट एक्शन है तो /Document/Saveमुझे इसका अपवाद मिलेगा एक सार्वजनिक एक्शन विधि 'सेव' कंट्रोलर 'प्रोजेक्ट.कंट्रोलर्स.डीकॉममेंटकंट्रोलर' पर नहीं मिली थी।

लेकिन अगर पोस्ट एक्शन है /Document/Save/ , तो पोस्ट सही है और काम करता है!

भगवान बचाओ / ?

Answer 10

मेरा मूल कारण टिप्पणी में उल्लिखित एक के समान था।

मैं ajaxSubmittingएक बटन के क्लिक पर एक फॉर्म था । प्रपत्र फ़ील्ड्स में से एक प्रकार का था Date। हालाँकि, क्लाइंट और सर्वर मशीन के बीच दिनांक स्वरूपों में अंतर के कारण यह नियंत्रक में POST विधि को निष्पादित नहीं करता था। सर्वर ने एक 302प्रतिक्रिया वापस भेजी और फिर GETउसी विधि के लिए फिर से अनुरोध भेजा ।

हालांकि, नियंत्रक में कार्रवाई को HttpPostविशेषता के साथ सजाया गया था और इसलिए यह विधि नहीं ढूंढ सका और एक 404प्रतिक्रिया वापस भेज दी।

मैंने सिर्फ कोड को इस तरह तय किया है कि दिनांक स्वरूपों में बेमेल त्रुटि नहीं होगी और समस्या ठीक हो गई थी।

Answer 11

[HttpGet]विशेषताएँ निकालें और यह काम करेगा :)

Comments

जबकि यह "त्रुटियों" को हल करता है, संभावना यह है कि आप (या आपके सामने कोई) उन [HttpGet]विशेषताओं को उद्देश्य से रखता है, ताकि किसी अन्य VERBs के माध्यम से होने वाली क्रियाओं को रोका जा सके

— निक ऑर्लैंडो

Answer 12

कोणीयज, MVC और {{imagepath}} के साथ इस समस्या वाले किसी व्यक्ति के लिए, छवि src विशेषताएँ टाइप करें, जैसे:

"एक सार्वजनिक क्रिया विधि '{{imagepath}} पिछली.पिंग' नियंत्रक पर नहीं मिली थी"

समाधान src के बजाय ng-src का उपयोग करना है।

आशा है कि यह किसी की मदद करता है :)

Comments

लगभग एक साल बाद, मैं इस के लिए देख रहा था :) tnx!

— वर्थोसा

Answer 13

देखें कि क्या केवल प्रश्न में URL ब्राउज़ करना त्रुटि को पुन: उत्पन्न करने के लिए पर्याप्त है। यदि कार्रवाई केवल POST कार्रवाई के रूप में परिभाषित की जाती है। ऐसा करने से आप अपनी इच्छानुसार त्रुटि को पुन: पेश कर सकते हैं।

किसी भी स्थिति में, आप नीचे दिए अनुसार त्रुटि को विश्व स्तर पर संभाल सकते हैं। यहां एक और जवाब है कि संदर्भ HandleUnknownActionकेवल खराब कार्रवाई के नाम वाले URL को संभालता है, न कि खराब नियंत्रक नामों को। निम्नलिखित दृष्टिकोण दोनों को संभालता है।

इसे अपने आधार नियंत्रक में जोड़ें (देखें कोड यहां छोड़ दिया गया है):

public ActionResult Error(string errorMessage)
{
    return View("Error");  // or do something like log the error, etc.
}

Global.asax.cs पर एक वैश्विक अपवाद हैंडलर जोड़ें, जो ऊपर दी गई विधि को कॉल करता है या जो कुछ आप करना चाहते हैं, वह 4 जीबी डेटा के साथ करता है:

void Application_Error(object sender, EventArgs e)
{
    Exception ex = Server.GetLastError();  // get the exception object
    HttpException httpException = ex as HttpException;

    if (httpException != null && httpException.GetHttpCode() == 404)  // if action not found
    {
        string errorMessage = "The requested page was not found.";

        RouteData routeData = new RouteData();
        routeData.Values.Add("controller", "Base");
        routeData.Values.Add("action", "Error");
        routeData.Values.Add("errorMessage", errorMessage);

        Server.ClearError();
        Response.TrySkipIisCustomErrors = true;

        // Go to our custom error view.
        IController errorController = new BaseController();
        errorController.Execute(new RequestContext(new HttpContextWrapper(Context), routeData));
    }
}