C# DLL is throwing Automation Errors on some machines when called from VB6

[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
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]

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

"GasDay DevelopmentTeam" <gasd...@gmail.com> wrote in message
news:84049d89-8930-4f93...@q11g2000yqi.googlegroups.com...

[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.

On Jul 14, 5:42 pm, "Wilson, Phil" <ph...@wonderware.nospam.com>
wrote:

> 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
>

> "GasDay DevelopmentTeam" <gasday...@gmail.com> wrote in message

[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
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?

On Jul 15, 10:06 am, GasDay DevelopmentTeam <gasday...@gmail.com>
wrote:

[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
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

On Jul 16, 11:39 am, Chris <lilpatrick...@gmail.com> wrote:
> 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

[Peda]

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 ?

"Chris" wrote:

> > > >news:84049d89-8930-4f93...@q11g2000yqi.googlegroups.com....