3
votes

I have created a strongly signed assembly in Visual Studio 2008 against the .NET 3.5 framework (I tried 2.0 framework as well). I exposed a class as COM visible, and I am able to find this dll in the object browser of Visual Studio 6 for Visual Basic. I can create an exe in VB6 and run that exe directly from windows explorer, and everything works fine. However, when I try to run the VB6 project inside Visual Studio 6 the .net assembly doesn't want to load and fails with the following error:

ActiveX component can't create object

I also get this error instead of the one above, depending on how I register the dll:

-2147024894 File or assembly name (myComponentName), or one of its dependencies, was not found.

Or this:

-2146233082 Automation error

I have tried everything I can think of. It seems that this would be a problem with the way VS6 runs in debug mode. Maybe the environment is different with a missing path to this or another dll. I have this problem on two different development machines. I can also reference a COM .net dll that was built by another developer using an older version of visual studio .net. I even opened the dll with dependency walker and I didn't get any obvious errors.

UPDATE: Proc monitor is saying that VB6 is looking for my dll in the vb6 studio home directory "C:\Program Files\Microsoft Visual Studio\VB98\MyDLL.DLL" instead of where the DLL is registered. I placed the dll there and registered it, now I'm getting a new error:

-2146234105 (80131107) "The format of the file 'MyDllName' is invalid."

So, why is studio looking for my DLL there and not where it's registered? How can I fix that? At the very least, how can I get the dll to work in the "C:\Program Files\Microsoft Visual Studio\VB98\" folder

Final Update/SOLUTION: Ok, so I figured out the problem. This has to do with VB6.exe being locked out of the .net framework version I was using (2.0 or 3.5). I found this file "C:\Program Files\Microsoft Visual Studio\VB98\vb6.exe.config" that contained the following entry:

<configuration>
  <startup>
      <supportedRuntime version="v1.1.4322" />
  </startup>

As soon as I removed this file the dll started working fine from the visual studio 6 environment. Thanks to everyone who responded to help.

2
My guess is that something is valid in your OS path that loads one of your reference DLLs managed or otherwise. As I remember of VS6, it ignores the OS paths so you have have to add the path to VS6.kenny
Just checking - you do have .NET 2.0 installed on the box running Visual Studio 6, yes?user111013
I have Visual Studio 6, 2005, and 2008 installed...and 2005 or 2008 installed .net 2.0 with it. The dll runs just fine when called from another studio 2008 project, or when used in VB6 app when called from windows shell (explorer). Only VB6 IDE environment doesn't work.Alex
Kenny, how would I add the OS path to VS6? That sounds like a possible solution. Thanks!Alex

2 Answers

2
votes

Ok, so I figured out the problem. This has to do with VB6.exe being locked out of the .net framework version I was using (2.0 or 3.5). I found this file "C:\Program Files\Microsoft Visual Studio\VB98\vb6.exe.config" that contained the following entry:

<configuration>
  <startup>
      <supportedRuntime version="v1.1.4322" />
  </startup>

As soon as I removed this file the dll started working fine from the visual studio 6 environment. Thanks to everyone who responded to help.

1
votes

A common cause for the 1st error is to run Regasm.exe without the /codebase command line option.

The 2nd error is 0x8007002, a Windows error, "File not found". This is likely to be generated by an exception in your managed code.

The 3rd error is 0x80131506, the managed exception code for "Fatal execution engine error". That's a bad one, usually induced by having unmanaged code corrupt the garbage collected heap.

Clearly you don't really have registration problems, you are getting managed exceptions. But yes, they are hard to diagnose when you can no longer see the nice .NET exceptions with their stack traces. Fix this by using the debugger. Project + Properties, Debug tab, select "Start external program" and select your vb6 program. Set a breakpoint on the code you want to test. It will hit as soon as the vb6 program calls it. Debug + Exception, Thrown checkboxes is another good way to troubleshoot managed exceptions, the debugger stops at the throw statement. Albeit that it might not be your code that's throwing, look at the call stack.

You can even select vb6.exe from the VS6 install directory. Now you can debug both the vb6 code and the managed code.