Rushabh Verma 0 Newbie Poster

I have a C# project that creates a COM object for use with a POS terminal. Before I give it to the customer, I want to make sure that it will work as a COM dll. The RegAsm says it works.

using System;
using System.Runtime.InteropServices;

namespace POS
{
    [Guid( "0135bc5c-b248-444c-94b9-b0b4577f5a1a" )]
    [InterfaceType( ComInterfaceType.InterfaceIsDual )]
    [ComVisible( true )]
    public interface ITwoWay
    {
        // The Initialize method is called to establish the communications connection...
        [DispId( 1 )]
        void Initialize( String IPAddress, long Port, long MaxPacketSize );

        // A convenience method that allows the POS to test the Third Party’s back-end...
        [DispId( 2 )]
        void TestConnect();

        // The Terminate method is called to indicate that the POS system is about to terminate...
        [DispId( 3 )]
        void Terminate();

        // All interface calls made during a transaction send the same record format with specific reply fields ...
        [DispId( 4 )]
        void TransactionCall( String viPOSMsg, ref String InterceptArray );
    }
}

The actual entry points are defined in class TwoWay

using System.Runtime.InteropServices;
using System.EnterpriseServices;

namespace POS
{
    [Guid( "0135bc5c-b248-444c-94b9-b0b4577f5a1b" )]
    [ComDefaultInterface(typeof(ITwoWay))]
    [ClassInterface( ClassInterfaceType.None )]
    [ComVisible( true )]
    public class TwoWay : ITwoWay
    ...
    [ComVisible( true )]
    public void Initialize( string iPAddress, long port, long maxPacketSize )
    ...

I have a C# project that creates a COM object for use with a POS terminal. Before I give it to the customer, I want to make sure that it will work as a COM dll. The RegAsm says it works.

using System;
using System.Runtime.InteropServices;

namespace POS
{
    [Guid( "0135bc5c-b248-444c-94b9-b0b4577f5a1a" )]
    [InterfaceType( ComInterfaceType.InterfaceIsDual )]
    [ComVisible( true )]
    public interface ITwoWay
    {
        // The Initialize method is called to establish the communications connection...
        [DispId( 1 )]
        void Initialize( String IPAddress, long Port, long MaxPacketSize );

        // A convenience method that allows the POS to test the Third Party’s back-end...
        [DispId( 2 )]
        void TestConnect();

        // The Terminate method is called to indicate that the POS system is about to terminate...
        [DispId( 3 )]
        void Terminate();

        // All interface calls made during a transaction send the same record format with specific reply fields ...
        [DispId( 4 )]
        void TransactionCall( String viPOSMsg, ref String InterceptArray );
    }
}
The actual entry points are defined in class TwoWay

using System.Runtime.InteropServices;
using System.EnterpriseServices;

namespace POS
{
    [Guid( "0135bc5c-b248-444c-94b9-b0b4577f5a1b" )]
    [ComDefaultInterface(typeof(ITwoWay))]
    [ClassInterface( ClassInterfaceType.None )]
    [ComVisible( true )]
    public class TwoWay : ITwoWay
    ...
    [ComVisible( true )]
    public void Initialize( string iPAddress, long port, long maxPacketSize )
    ...

I had thought that I could import the .tlb into another .net project and test it that way but when I add my COM project as a COM reference VS rejects it because it was created as .NET dll.

I tried to create a vb script to run CreateObject but that errors on permissions. I attempted to set up the I_USER account, etc but I couldn't get that going.

The registry shows an entry with the right name and the class id is set to the correct guid. But still, I want to load it and run it through the COM interface.

How does one verify that a COM .dll is actually a COM .dll? As old as this is, there must be a way.

Dani AI

Generated

Short, practical verification plan for a .NET-to-COM class (based on ’s report that RegAsm reported success). Confirm three things: the registry entries are correct for COM activation, a non-.NET client can CoCreate/CreateObject the class, and the runtime/process bitness and DCOM permissions match the target environment. The Registry/InprocServer32 behavior and the named values RegAsm writes are described in Microsoft’s COM registration docs. (learn.microsoft.com)

Register (or re-register) from an elevated Developer Command Prompt and produce a typelib/regfile for inspection. Typical commands:

"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" "C:\path\POS.dll" /tlb:POS.tlb /codebase
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe" "C:\path\POS.dll" /tlb:POS.tlb /codebase

Use /regfile:out.reg to generate a .reg without touching the registry; /codebase is required if the assembly is not in the GAC (strong-name recommended). Always run the RegAsm.exe that matches the target process bitness. (learn.microsoft.com)

Verify the registry keys created under HKCR\CLSID{...}: the default ProgID, an InprocServer32 entry that points to the CLR loader (mscoree.dll) and the named values like Assembly and Class. Use the OLE/COM Object Viewer (oleview.exe) to inspect the registered TypeLib and interfaces (easier than eyeballing raw registry). (learn.microsoft.com)

Exercise activation from a native automation client (VBScript or PowerShell) to prove the COM entrypoint works outside Visual Studio’s managed reference behavior. Example tests:

' test.vbs
Set obj = CreateObject("POS.TwoWay")
obj.TestConnect
# PowerShell
$tw = New-Object -ComObject "POS.TwoWay"
$tw.TestConnect()

Run scripts from an elevated interactive session first; if activation fails under IIS/service accounts, adjust Launch/Activation and Access permissions in Component Services (DCOMCNFG) or set an appropriate identity for the app–these settings control CreateObject/CoCreateInstance access. (learn.microsoft.com)

Quick checklist of common gotchas: bitness mismatch (register with Framework vs Framework64), assembly moved after registration (re-register), missing public/ComVisible types, and DCOM permissions when the caller runs as a service. Regasm’s /unregister cleans up after tests. (learn.microsoft.com)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.