Discussion:
C# DLL is throwing Automation Errors on some machines when called from VB6
(too old to reply)
GasDay DevelopmentTeam
2009-07-14 19:12:44 UTC
Permalink
Hello,

I've been having an issue with COM Interop over the past couple of
days.
The issue is that certain computers throw an Automation error
(-2146232576 (80131700)) when the VB6 code attempts to instantiate a
new object from the .NET code; however, the 3 development machines can
run the code without any issues.

Here are some details on what we have done thus far as well as the
configuration of the interop:

* The VB6 code is within an Excel module.
* The C# code has been set up for interop by providing COM visible
interfaces, specifying the class interface types, and registering it
to the registry by running 'regasm TestVBDLL.dll /tlb:TestVBDLL.tlb /
codebase' (after ensuring that it has been unregistered) and verifying
it is in the registry.
* After that step, the DLL/TLB is visible and usable on the
development machines AND is visible in the object browser on the
problematic machines.
* However, where we are having the issue is that once the code is
run on the problem machine it throws an automation error on the line
in which the test object is set to a new object. After that the class
is no longer visible in the object browser, but this may be unrelated.
* We've tried creating an entirely new Excel project and C# DLL
with just the bare minimum required to do the COM interop (as opposed
to the thousands of lines in the other projects) and it still fails in
the same manner.

The computers that it isn't working on are fairly new machines with
intel Core 2 Duo E6600s, 3.25GB RAM, Windows XP SP3, .NET Framework 2,
3, and 3.5, as well as Visual Basic Enterprise edition.

We've tried just about everything we can think of with regasm,
registering and unregistering, recompiling, etc.

Any help or suggestions would be greatly appreciated!

Thank you,
- Christopher Patrick


Here is the minimal code we tried to use:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;

namespace TestVBDLL {
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch),
ComVisible(true)]
public interface IClass1 {
void doStuff();
}

[ClassInterface(ClassInterfaceType.None),
ComVisible(true)]
public class Class1 : IClass1 {
String test = String.Empty;
public Class1() {
test = "This is the variable test.";
}
public void doStuff() {
MessageBox.Show("This is a test.\n\n" + test, "A message
from .NET", MessageBoxButtons.OK);
}
}
}

//VB6
Option Explicit

Sub test()
Dim obj As Class1
Set obj = New Class1
Call obj.doStuff
End Sub
Wilson, Phil
2009-07-14 22:42:46 UTC
Permalink
You haven't got any .NET 1.1 assemblies anywhere by any chance?
--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972
Post by GasDay DevelopmentTeam
Hello,
I've been having an issue with COM Interop over the past couple of
days.
The issue is that certain computers throw an Automation error
(-2146232576 (80131700)) when the VB6 code attempts to instantiate a
new object from the .NET code; however, the 3 development machines can
run the code without any issues.
Here are some details on what we have done thus far as well as the
* The VB6 code is within an Excel module.
* The C# code has been set up for interop by providing COM visible
interfaces, specifying the class interface types, and registering it
to the registry by running 'regasm TestVBDLL.dll /tlb:TestVBDLL.tlb /
codebase' (after ensuring that it has been unregistered) and verifying
it is in the registry.
* After that step, the DLL/TLB is visible and usable on the
development machines AND is visible in the object browser on the
problematic machines.
* However, where we are having the issue is that once the code is
run on the problem machine it throws an automation error on the line
in which the test object is set to a new object. After that the class
is no longer visible in the object browser, but this may be unrelated.
* We've tried creating an entirely new Excel project and C# DLL
with just the bare minimum required to do the COM interop (as opposed
to the thousands of lines in the other projects) and it still fails in
the same manner.
The computers that it isn't working on are fairly new machines with
intel Core 2 Duo E6600s, 3.25GB RAM, Windows XP SP3, .NET Framework 2,
3, and 3.5, as well as Visual Basic Enterprise edition.
We've tried just about everything we can think of with regasm,
registering and unregistering, recompiling, etc.
Any help or suggestions would be greatly appreciated!
Thank you,
- Christopher Patrick
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace TestVBDLL {
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch),
ComVisible(true)]
public interface IClass1 {
void doStuff();
}
[ClassInterface(ClassInterfaceType.None),
ComVisible(true)]
public class Class1 : IClass1 {
String test = String.Empty;
public Class1() {
test = "This is the variable test.";
}
public void doStuff() {
MessageBox.Show("This is a test.\n\n" + test, "A message
from .NET", MessageBoxButtons.OK);
}
}
}
//VB6
Option Explicit
Sub test()
Dim obj As Class1
Set obj = New Class1
Call obj.doStuff
End Sub
GasDay DevelopmentTeam
2009-07-15 15:06:23 UTC
Permalink
Thanks for your reply, Phil.

If I'm understanding your question correctly, then no that target
machine does NOT have .NET 1.1 installed. It has 2.0, 3.0, and the
latest 3.5 .

I installed the .NET 1.1 and unregistered / re-registered (regasm dll /
tlb:tlb /codebase) the DLL. This got rid of the "Automation Error"
per se, but created another issue on the same line: Loading Image...
(File or assembly, or one of its dependencies, was not found). I
wanted to re-compile the DLL using the .NET 1.1 framework, however
that option was not in the drop down in Visual Studio C# Express 2008;
only 2.0, 3.0, and 3.5 were available.

I will keep trying other things in the mean time, and thanks again for
your assistance!

- Christopher Patrick, GasDay Development Team.
Post by Wilson, Phil
You haven't got any .NET 1.1 assemblies anywhere by any chance?
--
Phil Wilson
The Definitive Guide to Windows Installerhttp://www.apress.com/book/view/1590592972
Post by GasDay DevelopmentTeam
Hello,
I've been having an issue with COM Interop over the past couple of
days.
The issue is that certain computers throw an Automation error
(-2146232576 (80131700)) when the VB6 code attempts to instantiate a
new object from the .NET code; however, the 3 development machines can
run the code without any issues.
Here are some details on what we have done thus far as well as the
   * The VB6 code is within an Excel module.
   * The C# code has been set up for interop by providing COM visible
interfaces, specifying the class interface types, and registering it
to the registry by running 'regasm TestVBDLL.dll /tlb:TestVBDLL.tlb /
codebase' (after ensuring that it has been unregistered) and verifying
it is in the registry.
   * After that step, the DLL/TLB is visible and usable on the
development machines AND is visible in the object browser on the
problematic machines.
   * However, where we are having the issue is that once the code is
run on the problem machine it throws an automation error on the line
in which the test object is set to a new object. After that the class
is no longer visible in the object browser, but this may be unrelated.
   * We've tried creating an entirely new Excel project and C# DLL
with just the bare minimum required to do the COM interop (as opposed
to the thousands of lines in the other projects) and it still fails in
the same manner.
The computers that it isn't working on are fairly new machines with
intel Core 2 Duo E6600s, 3.25GB RAM, Windows XP SP3, .NET Framework 2,
3, and 3.5, as well as Visual Basic Enterprise edition.
We've tried just about everything we can think of with regasm,
registering and unregistering, recompiling, etc.
Any help or suggestions would be greatly appreciated!
Thank you,
 - Christopher Patrick
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace TestVBDLL {
   [InterfaceType(ComInterfaceType.InterfaceIsIDispatch),
       ComVisible(true)]
   public interface IClass1 {
       void doStuff();
   }
   [ClassInterface(ClassInterfaceType.None),
       ComVisible(true)]
   public class Class1 : IClass1 {
       String test = String.Empty;
       public Class1() {
           test = "This is the variable test.";
       }
       public void doStuff() {
           MessageBox.Show("This is a test.\n\n" + test, "A message
from .NET", MessageBoxButtons.OK);
       }
   }
}
//VB6
Option Explicit
Sub test()
   Dim obj As Class1
   Set obj = New Class1
   Call obj.doStuff
End Sub
Chris
2009-07-16 16:39:44 UTC
Permalink
I've been playing with some things for a little bit here today and
found out some more new information that I figured I should share.

I was referred to an article pertaining to COM Interop / COM+ things
which contained example source code as well as some explanations
( http://www.codeproject.com/KB/vb-interop/csCom.aspx ). I found out
some interesting things while playing with the example from the
website and my test DLLs. Here are my main discoveries:

1. The example source code in the article linked works just as it
said it would. This applies for the COM+ and COM Interop examples.
2. If I modified my C# DLL to mirror the configuration of the
example DLL and called it from the Excel VBA application as I had
been; it still was not working. Instead we received a dependency
error.
3. However, after noticing that the example DLL was being called
from VB6 and not VBA as our DLL was, I copied my test VB code into a
new VB6 application. This worked as the example did.
4. Thinking that it was just Excel that could not call the C# DLL I
created a new VB6 DLL to use the C# code. I then called the newly
created VB6 DLL from the Excel VBA. This did not work, resulting in
the same problem we had been having.

This leads me to ask a few questions. Mainly, why is it that the COM
Interop works when called from VB6 but does not work with VBA, even
when VBA is not directly interfacing with the C# DLL? Furthermore, how
come COM Interop from VBA works on a the majority of machines (such as
the dev computers), but not on other client/testing machines?
Post by GasDay DevelopmentTeam
Thanks for your reply, Phil.
If I'm understanding your question correctly, then no that target
machine does NOT have .NET 1.1 installed.  It has 2.0, 3.0, and the
latest 3.5 .
I installed the .NET 1.1 and unregistered / re-registered (regasm dll /
tlb:tlb /codebase) the DLL.  This got rid of the "Automation Error"
per se, but created another issue on the same line:http://imgur.com/gppPe.png
(File or assembly, or one of its dependencies, was not found). I
wanted to re-compile the DLL using the .NET 1.1 framework, however
that option was not in the drop down in Visual Studio C# Express 2008;
only 2.0, 3.0, and 3.5 were available.
I will keep trying other things in the mean time, and thanks again for
your assistance!
- Christopher Patrick, GasDay Development Team.
Post by Wilson, Phil
You haven't got any .NET 1.1 assemblies anywhere by any chance?
--
Phil Wilson
The Definitive Guide to Windows Installerhttp://www.apress.com/book/view/1590592972
Post by GasDay DevelopmentTeam
Hello,
I've been having an issue with COM Interop over the past couple of
days.
The issue is that certain computers throw an Automation error
(-2146232576 (80131700)) when the VB6 code attempts to instantiate a
new object from the .NET code; however, the 3 development machines can
run the code without any issues.
Here are some details on what we have done thus far as well as the
   * The VB6 code is within an Excel module.
   * The C# code has been set up for interop by providing COM visible
interfaces, specifying the class interface types, and registering it
to the registry by running 'regasm TestVBDLL.dll /tlb:TestVBDLL.tlb /
codebase' (after ensuring that it has been unregistered) and verifying
it is in the registry.
   * After that step, the DLL/TLB is visible and usable on the
development machines AND is visible in the object browser on the
problematic machines.
   * However, where we are having the issue is that once the code is
run on the problem machine it throws an automation error on the line
in which the test object is set to a new object. After that the class
is no longer visible in the object browser, but this may be unrelated.
   * We've tried creating an entirely new Excel project and C# DLL
with just the bare minimum required to do the COM interop (as opposed
to the thousands of lines in the other projects) and it still fails in
the same manner.
The computers that it isn't working on are fairly new machines with
intel Core 2 Duo E6600s, 3.25GB RAM, Windows XP SP3, .NET Framework 2,
3, and 3.5, as well as Visual Basic Enterprise edition.
We've tried just about everything we can think of with regasm,
registering and unregistering, recompiling, etc.
Any help or suggestions would be greatly appreciated!
Thank you,
 - Christopher Patrick
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace TestVBDLL {
   [InterfaceType(ComInterfaceType.InterfaceIsIDispatch),
       ComVisible(true)]
   public interface IClass1 {
       void doStuff();
   }
   [ClassInterface(ClassInterfaceType.None),
       ComVisible(true)]
   public class Class1 : IClass1 {
       String test = String.Empty;
       public Class1() {
           test = "This is the variable test.";
       }
       public void doStuff() {
           MessageBox.Show("This is a test.\n\n" + test, "A message
from .NET", MessageBoxButtons.OK);
       }
   }
}
//VB6
Option Explicit
Sub test()
   Dim obj As Class1
   Set obj = New Class1
   Call obj.doStuff
End Sub
Chris
2009-07-16 17:58:11 UTC
Permalink
I found the solution to the problem.

The issue was with using Microsoft Office 2003 SP2 and .NET framework
2.0 not allowing managed code to be used within the Word and Excel
applications. This was due to a missing an update / not having Office
SP3.

There is a Microsoft support article which points to a download that
applies an update to Office 2003 that enables manage code. They can
be found here:

You cannot load a .NET Framework 2.0 assembly from Visual Basic for
Applications in Word 2003 and earlier versions, or in Excel 2003 and
earlier versions (Description of problem): http://support.microsoft.com/kb/948461

Description of Update for Office: http://support.microsoft.com/kb/907417

Update For Office 2003 (KB907417):
http://www.microsoft.com/downloads/details.aspx?FamilyId=1B0BFB35-C252-43CC-8A2A-6A64D6AC4670&displaylang=en

Thanks for your help again,
- Christopher Patrick, GasDay Development Team
Post by Chris
I've been playing with some things for a little bit here today and
found out some more new information that I figured I should share.
I was referred to an article pertaining to COM Interop / COM+ things
which contained example source code as well as some explanations
(http://www.codeproject.com/KB/vb-interop/csCom.aspx).  I found out
some interesting things while playing with the example from the
   1. The example source code in the article linked works just as it
said it would. This applies for the COM+ and COM Interop examples.
   2. If I modified my C# DLL to mirror the configuration of the
example DLL and called it from the Excel VBA application as I had
been; it still was not working.  Instead we received a dependency
error.
   3. However, after noticing that the example DLL was being called
from VB6 and not VBA as our DLL was, I copied my test VB code into a
new VB6 application.  This worked as the example did.
   4. Thinking that it was just Excel that could not call the C# DLL I
created a new VB6 DLL to use the C# code.  I then called the newly
created VB6 DLL from the Excel VBA.  This did not work, resulting in
the same problem we had been having.
This leads me to ask a few questions.  Mainly, why is it that the COM
Interop works when called from VB6 but does not work with VBA, even
when VBA is not directly interfacing with the C# DLL? Furthermore, how
come COM Interop from VBA works on a the majority of machines (such as
the dev computers), but not on other client/testing machines?
Post by GasDay DevelopmentTeam
Thanks for your reply, Phil.
If I'm understanding your question correctly, then no that target
machine does NOT have .NET 1.1 installed.  It has 2.0, 3.0, and the
latest 3.5 .
I installed the .NET 1.1 and unregistered / re-registered (regasm dll /
tlb:tlb /codebase) the DLL.  This got rid of the "Automation Error"
per se, but created another issue on the same line:http://imgur.com/gppPe.png
(File or assembly, or one of its dependencies, was not found). I
wanted to re-compile the DLL using the .NET 1.1 framework, however
that option was not in the drop down in Visual Studio C# Express 2008;
only 2.0, 3.0, and 3.5 were available.
I will keep trying other things in the mean time, and thanks again for
your assistance!
- Christopher Patrick, GasDay Development Team.
Post by Wilson, Phil
You haven't got any .NET 1.1 assemblies anywhere by any chance?
--
Phil Wilson
The Definitive Guide to Windows Installerhttp://www.apress.com/book/view/1590592972
Post by GasDay DevelopmentTeam
Hello,
I've been having an issue with COM Interop over the past couple of
days.
The issue is that certain computers throw an Automation error
(-2146232576 (80131700)) when the VB6 code attempts to instantiate a
new object from the .NET code; however, the 3 development machines can
run the code without any issues.
Here are some details on what we have done thus far as well as the
   * The VB6 code is within an Excel module.
   * The C# code has been set up for interop by providing COM visible
interfaces, specifying the class interface types, and registering it
to the registry by running 'regasm TestVBDLL.dll /tlb:TestVBDLL.tlb /
codebase' (after ensuring that it has been unregistered) and verifying
it is in the registry.
   * After that step, the DLL/TLB is visible and usable on the
development machines AND is visible in the object browser on the
problematic machines.
   * However, where we are having the issue is that once the code is
run on the problem machine it throws an automation error on the line
in which the test object is set to a new object. After that the class
is no longer visible in the object browser, but this may be unrelated.
   * We've tried creating an entirely new Excel project and C# DLL
with just the bare minimum required to do the COM interop (as opposed
to the thousands of lines in the other projects) and it still fails in
the same manner.
The computers that it isn't working on are fairly new machines with
intel Core 2 Duo E6600s, 3.25GB RAM, Windows XP SP3, .NET Framework 2,
3, and 3.5, as well as Visual Basic Enterprise edition.
We've tried just about everything we can think of with regasm,
registering and unregistering, recompiling, etc.
Any help or suggestions would be greatly appreciated!
Thank you,
 - Christopher Patrick
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace TestVBDLL {
   [InterfaceType(ComInterfaceType.InterfaceIsIDispatch),
       ComVisible(true)]
   public interface IClass1 {
       void doStuff();
   }
   [ClassInterface(ClassInterfaceType.None),
       ComVisible(true)]
   public class Class1 : IClass1 {
       String test = String.Empty;
       public Class1() {
           test = "This is the variable test.";
       }
       public void doStuff() {
           MessageBox.Show("This is a test.\n\n" + test, "A message
from .NET", MessageBoxButtons.OK);
       }
   }
}
//VB6
Option Explicit
Sub test()
   Dim obj As Class1
   Set obj = New Class1
   Call obj.doStuff
End Sub
Peda
2009-08-13 13:24:02 UTC
Permalink
Thanks for this post. I was searching for about 10 hours for a solution of
exactly this problem, and this finally fixed it.

Why is this update not included in the Service Packs ?
Post by Chris
I found the solution to the problem.
The issue was with using Microsoft Office 2003 SP2 and .NET framework
2.0 not allowing managed code to be used within the Word and Excel
applications. This was due to a missing an update / not having Office
SP3.
There is a Microsoft support article which points to a download that
applies an update to Office 2003 that enables manage code. They can
You cannot load a .NET Framework 2.0 assembly from Visual Basic for
Applications in Word 2003 and earlier versions, or in Excel 2003 and
earlier versions (Description of problem): http://support.microsoft.com/kb/948461
Description of Update for Office: http://support.microsoft.com/kb/907417
http://www.microsoft.com/downloads/details.aspx?FamilyId=1B0BFB35-C252-43CC-8A2A-6A64D6AC4670&displaylang=en
Thanks for your help again,
- Christopher Patrick, GasDay Development Team
Post by Chris
I've been playing with some things for a little bit here today and
found out some more new information that I figured I should share.
I was referred to an article pertaining to COM Interop / COM+ things
which contained example source code as well as some explanations
(http://www.codeproject.com/KB/vb-interop/csCom.aspx). I found out
some interesting things while playing with the example from the
1. The example source code in the article linked works just as it
said it would. This applies for the COM+ and COM Interop examples.
2. If I modified my C# DLL to mirror the configuration of the
example DLL and called it from the Excel VBA application as I had
been; it still was not working. Instead we received a dependency
error.
3. However, after noticing that the example DLL was being called
from VB6 and not VBA as our DLL was, I copied my test VB code into a
new VB6 application. This worked as the example did.
4. Thinking that it was just Excel that could not call the C# DLL I
created a new VB6 DLL to use the C# code. I then called the newly
created VB6 DLL from the Excel VBA. This did not work, resulting in
the same problem we had been having.
This leads me to ask a few questions. Mainly, why is it that the COM
Interop works when called from VB6 but does not work with VBA, even
when VBA is not directly interfacing with the C# DLL? Furthermore, how
come COM Interop from VBA works on a the majority of machines (such as
the dev computers), but not on other client/testing machines?
Post by GasDay DevelopmentTeam
Thanks for your reply, Phil.
If I'm understanding your question correctly, then no that target
machine does NOT have .NET 1.1 installed. It has 2.0, 3.0, and the
latest 3.5 .
I installed the .NET 1.1 and unregistered / re-registered (regasm dll /
tlb:tlb /codebase) the DLL. This got rid of the "Automation Error"
per se, but created another issue on the same line:http://imgur.com/gppPe.png
(File or assembly, or one of its dependencies, was not found). I
wanted to re-compile the DLL using the .NET 1.1 framework, however
that option was not in the drop down in Visual Studio C# Express 2008;
only 2.0, 3.0, and 3.5 were available.
I will keep trying other things in the mean time, and thanks again for
your assistance!
- Christopher Patrick, GasDay Development Team.
Post by Wilson, Phil
You haven't got any .NET 1.1 assemblies anywhere by any chance?
--
Phil Wilson
The Definitive Guide to Windows Installerhttp://www.apress.com/book/view/1590592972
Post by GasDay DevelopmentTeam
Hello,
I've been having an issue with COM Interop over the past couple of
days.
The issue is that certain computers throw an Automation error
(-2146232576 (80131700)) when the VB6 code attempts to instantiate a
new object from the .NET code; however, the 3 development machines can
run the code without any issues.
Here are some details on what we have done thus far as well as the
* The VB6 code is within an Excel module.
* The C# code has been set up for interop by providing COM visible
interfaces, specifying the class interface types, and registering it
to the registry by running 'regasm TestVBDLL.dll /tlb:TestVBDLL.tlb /
codebase' (after ensuring that it has been unregistered) and verifying
it is in the registry.
* After that step, the DLL/TLB is visible and usable on the
development machines AND is visible in the object browser on the
problematic machines.
* However, where we are having the issue is that once the code is
run on the problem machine it throws an automation error on the line
in which the test object is set to a new object. After that the class
is no longer visible in the object browser, but this may be unrelated.
* We've tried creating an entirely new Excel project and C# DLL
with just the bare minimum required to do the COM interop (as opposed
to the thousands of lines in the other projects) and it still fails in
the same manner.
The computers that it isn't working on are fairly new machines with
intel Core 2 Duo E6600s, 3.25GB RAM, Windows XP SP3, .NET Framework 2,
3, and 3.5, as well as Visual Basic Enterprise edition.
We've tried just about everything we can think of with regasm,
registering and unregistering, recompiling, etc.
Any help or suggestions would be greatly appreciated!
Thank you,
- Christopher Patrick
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace TestVBDLL {
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch),
ComVisible(true)]
public interface IClass1 {
void doStuff();
}
[ClassInterface(ClassInterfaceType.None),
ComVisible(true)]
public class Class1 : IClass1 {
String test = String.Empty;
public Class1() {
test = "This is the variable test.";
}
public void doStuff() {
MessageBox.Show("This is a test.\n\n" + test, "A message
from .NET", MessageBoxButtons.OK);
}
}
}
//VB6
Option Explicit
Sub test()
Dim obj As Class1
Set obj = New Class1
Call obj.doStuff
End Sub
Loading...