locked
Method Not found error in COM+ RRS feed

  • Question

  • Hi all,
     When i access my COM+ from Dotnet solution, and create an object for this COM+, then i can see the methods which are in the COM+. There is no compilation error when i make use of those methods, but there is a runtime error saying 'Missing Method Exception : Method not found'. The method exists, and it is also shown in dotnet intellisense, and strangely no compilation error as well. Where am i going wrong ? did any had such problem before ?

     ex : My COM+ component name which i referenced is say Client
       Client cl = new Client();
       object obj = cl.getObjectInfos();

    // the getObjectInfos returns a object type. Below is my getObjectInfos() method.
    // The COM+ code, which is in a different solution.....
       
    public object getObjectInfos()
    {
        Status sta = new Status();
        object obj = sta.getValues();
        return obj;
    }


    ............please help

    regards,
    abhi
    Thursday, August 11, 2005 7:44 AM

Answers

  • 1. When searching the filemon log, just looked for the word 'Denied' instead of 'Access Denied'. I think filemon logs access errors like AccDenied or something like that.

    2. If you shut down the COM+ application on the remote server, then try to reproduce the error from the client machine, do you see the COM+ application startup automatically? If so then we are able to Lauch the remote COM+ app.

    3. If you are running Windows 2003, then enable DCOM Logging and restart the COM+ application, then reproduce the error, then check event logs for any DCOM errors indicating any DCOM permissions problems. To be honest if this was the case I'd expect different errors.

    892500 Programs that use DCOM do not work correctly after you install Microsoft
    http://support.microsoft.com/?id=892500

    4. If you have Security Failure auditing enabled, then reproduce the problem and then check the security event log to see if there are any logon failures

    5. What is the client application? Do you have a .NET Web App or Windows App trying to access the remote COM+ object? If it's failing as a web app, then try changing worker process identity (check <processModel/> tag in machine.config), or maybe try building console app that runs same code. Basically change the client process identity to an administrator, or domain admin that has permissions on remote machine.... any changes?

    Anything outside of that might require debugging.

    -Todd

    Friday, August 12, 2005 5:16 AM

All replies

  • Hello Abhi,

    I can only think of two reasons you would run into this error message:

    1. Permissions. Make sure that your .NET application has permissions to access the dlls hosting the Client and Status classes. Download and run Filemon while reproducing the error and make sure you do not see any Access Denied errors when trying to access the dlls.

    2. You need to upload your referenced assemblies. Try deleting everything out of your \bin directory and re-adding references and rebuild. We've seen a lot of people run into this error when they expect the application to use an updated version of the dll, but it is still using an older version of the dll.

    Hope this helps
    -Todd Foust
    Thursday, August 11, 2005 9:08 PM
  • Hello Todd,
     I think the problem is to do with the permissions. i downloaded  the Filemon software, but did not see any access denied errors. Btw, the COM+ which i access, is an application proxy, exported from another pc. So im actually trying to hit the DLL of the other computer.
     Could you please tell me where im going wrong ? I have disabled the firewalls on both PC's and the port 135 is also open. I get either method not found error of 'RPC Server Unavailable'.

    i have tried deleting everything in the bin folder, and re-complied. but that doesnt help too.

    regards
    abhi

    Friday, August 12, 2005 1:20 AM
  • 1. When searching the filemon log, just looked for the word 'Denied' instead of 'Access Denied'. I think filemon logs access errors like AccDenied or something like that.

    2. If you shut down the COM+ application on the remote server, then try to reproduce the error from the client machine, do you see the COM+ application startup automatically? If so then we are able to Lauch the remote COM+ app.

    3. If you are running Windows 2003, then enable DCOM Logging and restart the COM+ application, then reproduce the error, then check event logs for any DCOM errors indicating any DCOM permissions problems. To be honest if this was the case I'd expect different errors.

    892500 Programs that use DCOM do not work correctly after you install Microsoft
    http://support.microsoft.com/?id=892500

    4. If you have Security Failure auditing enabled, then reproduce the problem and then check the security event log to see if there are any logon failures

    5. What is the client application? Do you have a .NET Web App or Windows App trying to access the remote COM+ object? If it's failing as a web app, then try changing worker process identity (check <processModel/> tag in machine.config), or maybe try building console app that runs same code. Basically change the client process identity to an administrator, or domain admin that has permissions on remote machine.... any changes?

    Anything outside of that might require debugging.

    -Todd

    Friday, August 12, 2005 5:16 AM
  • Hi Todd,
     I donot have much hopes of solving this problem now, as im running out of ideas, and the problems are still there. Thanks a lot for ur inputs.
    I searched for the word 'Denied' in the Filemon, but didnt find anything, i think it does not even connect to the dll of the remote computer, so i wudnt expect this error to come up.
     If i shutdown the COM+ application on the remote server, and launch the application from the Client machine, the remote COM+ application does not get launched. Im using windows XP.
    What is Security Failure editing ? i havent touched any of such settings. Is it important to change any settings in that ?
     The client application is a webpage....(c#).
    Yes, i think this problem requires extensive debugging. Im reading up in the msdn site, but the chances of solving this problem seems rare...

    thanks so much todd..

    regards,
    abhi
    Friday, August 12, 2005 7:18 AM