800a0035 Error with Net-COM Interop

Question

I have a C# application that needs to utilize a COM class that is written in VB6. The application has to use dynamic binding because it has to be able to use different versions of the code based on what version (i.e., what DLL) the user selected. The way the program supports this is to first detect all of the versions in the registry and then let the user pick.

The code works on my machine and that of my peer reviewers, but the code that references the COM class is crashing for the person doing quality assurance (QA).

I put a message box in the code to display the error, and this is what the QAer gets:

I find the "FILENOTFOUND" part particularly confusing because I know that the DLL is present on her machine. In fact, she personally registered the DLL on her machine by using a right-click-to-register utility on the DLL; and this is the same utility that I used.

I then did some further investigation to find exactly what line was crashing. Here is the code that instantiates the COM class with the problematic line called out :

//Constructor for HtmlRtfConvProxy
public HtmlRtfConvProxy(String convWrapperProj) {
    convUtilType = Type.GetTypeFromProgID(convWrapperProj + "." + WRAPPER_CLASS_NAME);
    if(convUtilType == null) {
        throw new ArgumentException("Unable to find COM class");
    }
    //The following line is crashing for the person doing QA
    vbTargetObject = Activator.CreateInstance(convUtilType);
    if(vbTargetObject == null) {
        throw new ExternalException("Unable to instantiate COM class");
    }
}

What I found even more confusing was which line was crashing. It was not the line where I tried to get a Type for the object but where I tried to instantiate the object. I would think that if the DLL couldn't be found, then the line where I am obtaining the Type would crash.

I suspect that this has something to do with permissions, but my investigations along those lines have been fruitless. It looks like the QAer has the necessary permissions.

Note: I'm no guru when it comes to Windows file permissions.

Answer 1

The problem was that some of the DLLs that were referenced by the target DLL could not be found on the computers that were experiencing this problem.