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

    Question

  • 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
    

    Friday, July 10, 2009 6:17 PM

Answers

  • 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
    Thursday, July 16, 2009 5:56 PM

All replies

  •  

    Welcome to MSDN Visual Basic General Forum,

    This example will help you to understand how to implement and use a C# DLL in VB 6.0 code. As C# is an object-oriented language, we can use the object-oriented features to create proper classes in C# DLL. We can use COM Interop or follow the COM Plus Approach to refer to such DLLs in our old VB 6.0 applications. It's like delegating our business logic to this DLL. In this article, I tried to show two different approaches to refer to a C# DLL in VB 6.0. The code is attached herewith; you can directly refer it to understand the following instructions or try to create your own code from the instructions.

    To create COM Interop

    By using COM Interop, we create a DLL that can be private or shared. This DLL can be referred to in a VB 6.0 application. A VB 6.0 application refers to a Type Library of this DLL, i.e. a file with the .tlb extension that is created using the VS tool utility. For a client of a COM object to have access to the object, the client needs a description of it, how to locate it and how to call its methods and properties. For a "real" unmanaged COM class, this description is available in the form of a Type Library. A Type Library is a binary description of the GUIDs, classes, and interfaces (methods, properties, and parameters) that the COM class supports.

    .NET assemblies don't include information in Type Library compatible format. So, it is necessary for the programmer to run one of two .NET-supplied utilities to extract the assembly description of a class into a Type Library file. One utility is tlbexp.exe, the .NET Type Library Exporter. This command-line utility takes as input the name of an assembly DLL file to be converted to a Type Library. The programmer can also specify the name of a Type Library file to be created.

    http://www.codeproject.com/KB/vb-interop/csCom.aspx



    Best regards,
    Xingwei Hu


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

    Thursday, July 16, 2009 8:52 AM
  • Thank you for your reply, Xingwei.

    The website you linked to provided some pretty good information that I was able to use and go on a couple tangents with.  I found out some interesting things while playing with the example from the website and my test DLLs. Here are the main findings that I discovered:
    1. The example source code in the article you 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?

    Again, thank you very much for your help! We definitely found out a lot more information about this problem.

    Sincerely,
     - Christopher Patrick
    Thursday, July 16, 2009 4:31 PM
  • 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
    Thursday, July 16, 2009 5:56 PM