views:

326

answers:

4

This issue has me baffled, it's affecting a single user (to my knowledge) and hasn't been reproduced by us...

  • The user is receiving a MissingMethodException, our trace file indicates it's occuring after we create a new instance of a component, when we're calling an Initialize/Setup method in preparation to have it do work (InitializeWorkerByArgument in the example)

  • The Method specified by the error is an interface method, which a base class implements and classes derived from the base class can override as-needed

  • The user has the latest release of our application

  • All the provided code is shipped within a single assembly

Here's a very distilled version of the component:

class Widget : UserControl
{

    public void DoSomething(string argument)
    {
        InitializeWorkerByArgument(argument);
        this.Worker.DoWork();
    }

    private void InitializeWorkerByArgument(string argument)
    {
        switch (argument)
        {
            case "SomeArgument":
                this.Worker = new SomeWidgetWorker();
                break;
        }

        // The issue I'm tracking down would have occured during "new SomeWidgetWorker()"
        // and would have resulted in a missing method exception stating that
        // method "DoWork" could not be found.

        this.Worker.DoWorkComplete += new EventHandler(Worker_DoWorkComplete);
    }

    private IWidgetWorker Worker
    {
        get;
        set;
    }

    void Worker_DoWorkComplete(object sender, EventArgs e)
    {
        MessageBox.Show("All done");
    }
}

interface IWidgetWorker
{
    void DoWork();
    event EventHandler DoWorkComplete;
}

abstract class BaseWorker : IWidgetWorker
{
    virtual public void DoWork()
    {
        System.Threading.Thread.Sleep(1000);
        RaiseDoWorkComplete(this, null);
    }

    internal void RaiseDoWorkComplete(object sender, EventArgs e)
    {
        if (DoWorkComplete != null)
        {
            DoWorkComplete(this, null);
        }
    }

    public event EventHandler DoWorkComplete;
}

class SomeWidgetWorker : BaseWorker
{
    public override void DoWork()
    {
        System.Threading.Thread.Sleep(2000);
        RaiseDoWorkComplete(this, null);
    }
}
+1  A: 

Any chance this is a .NET Framework dependency issue and this user doesn't have the required .NET version? Just a thought.

Lazarus
I doubt it--but can't rule it out; we have a firm framework 2.0 requirement and haven't found any issues where a user is running on an incompatible version--but I'll need to verify the user's framework from our telemetry data when I get into the office.
STW
Negatory--the station has everything up to date from 1.0 thru 3.5 :(
STW
+1  A: 

Given the rarity of the problem, it seems likely that this is the result of a broken software environment on that one user's computer.

Greg D
I tend to agree, but naturally the end-user is a terrifically obnoxious person to deal with--so I'm doing my best to perform due diligence prior to assuming it's specific to their one station.
STW
It's always the way it seems, there must be a name for this 'law'. You're definitely doing the right thing, narrow down the issue and then you are working from fact not supposition which is always hard for someone to argue with. Chances are it's something this user has *done* rather than a random issue.
Lazarus
I like to categorize these as "uniquely spontaneous OS rot"--although technically it's no the OS, I suppose "MS-rot" would be the broader category. There's always that one machine skewed just outside of norm that appears to be fine--except it blows chunks doing something innocent.If only it didn't take a full day to go through the full cycle of formatting - installing - updating - installing SPs - re-updating - doing that last set of updates
STW
+5  A: 

That sounds like you are using a method, that was release in a SP of the .NET Framework 2.0.

I had the same problem as i used the method WaitOne(int) of ManualResetEvent. I had to replace it with WaitOne(int,bool).

The method WaitOne(int) was added in .NET Framework SP 2, which is applied when you install .NET Framework 3.5 SP1.

In such a case, i recommend to read the MSDN. The "Version Information" tells you in which framework or service pack a specific method is supported.

Jehof
Thanks for the suggestion, but it doesn't appear to be the case... I've verified that the user's system is reporting the same .NET 2.0 version as my station's, 2.0.50727.3082 (SP2 installed with 3.5),
STW
+1  A: 

Is the OS on the problem machine different to all of the others? I debugged a similar error years ago and I think I traced it to weird behavior on one particular flavour of Windows in the area of .Net type resolving.

locster
Also, does it have a different virus scanner? I've seen the buffer overflow protection in virus scanners mess with .net apps in weird ways, so I guess anything is possible.
Greg
Looks like the OS is same as my machines, XP (SP3?) 5.1.2600. AV is a good avenue to explore; what I've realized is the specific method it's complaining about is relatively new--I'm considering it might be running from a cached/compiled copy of the DLL; considering getting a dump of loaded DLLs and their locations using Process Explorer
STW
Perhaps you could take a look in the GAC and remove any entries for the DLLs in question. Potentially you have an older DLL in there with the same version number as a newer DLL.
locster