Importing static COM modules such as WriteProfileString

Question

I have a legacy VB 6 application that uses WriteProfileString which is provided only for compatibility with 16-bit versions of Windows.

I'm migrating it into a functional equivalent (that means an exact clone) .NET application. This requires me generate an Interop assembly from the TLB file of the WriteProfileString COM object using TlbImp.exe. This is a requirement and P/Invoke cannot be used.

When I do so TlbImp.exe generates an empty assembly.

WriteProfileString has the following IDL:

// Generated .IDL file (by the OLE/COM Object Viewer)
// 
// typelib filename: WriteProfileString.tlb

[
  uuid(13C9AF40-856A-101B-B9C2-04021C007003),
  version(0.0),
  helpstring("WritePrivateProfileStringW API Type Library")
]
library igrWriteProfileStringW
{
    // TLib :     // Forward declare all types defined in this typelib

    [
      dllname("KERNEL32"),
      helpstring("KERNEL API Calls")
    ]
    module KernelAPI {
        [entry("WritePrivateProfileStringW"), helpstring("Sets the value of a .ini file setting.")]
        long _stdcall WritePrivateProfileStringW(
                        [in] BSTR lpApplicationName, 
                        [in] BSTR lpKeyName, 
                        [in] BSTR lpString, 
                        [in] BSTR lpFileName);
    };
};

Fortunately Microsoft has open sourced the next version of TlbImp.exe named TlbImp2.exe.
I was able to debug through the code and found out that both TlbImp.exe and TlbImp2.exe do not import methods from modules. I had to hack through the code in order to make TlbImp2.exe to export the module's static methods.

I had to change the ConvModule.cs file:

public override void OnCreate()
{
    //
    // Avoid duplicate creation
    //
    if (m_type != null)
        return;

    // Create constant fields for the module
    ConvCommon.CreateConstantFields(m_info, RefNonAliasedTypeInfo, m_typeBuilder, ConvType.Module);
    ConvCommon.CreateMethodsForModule(m_info, RefNonAliasedTypeInfo, m_typeBuilder, ConvType.Module);

    m_type = m_typeBuilder.CreateType();
}

And add the following method to ConvCommon.cs:

public static void CreateMethodsForModule(ConverterInfo info, TypeInfo type, TypeBuilder typeBuilder, ConvType convType)
{
    using (TypeAttr attr = type.GetTypeAttr())
    {
        int cVars = attr.cFuncs;
        for (int n = 0; n < cVars; ++n)
        {
            using (var func = type.GetFuncDesc(n))
            {
                string methodName = type.GetDocumentation(func.memid);

                CreateMethod(new InterfaceInfo(info, typeBuilder, true, type, attr, false), new InterfaceMemberInfo(info, type, n, methodName, methodName, InterfaceMemberType.Method, TypeLibTypes.Interop.INVOKEKIND.INVOKE_FUNC, func.memid, func, null), CreateMethodMode.InterfaceMethodMode);
            }
        }
    }
}

So now it exports the methods correctly but I'm still wondering why it didn't export these methods in the first place.

This is the code of the exported assembly:

using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;

namespace igrWriteProfileStringW
{
  public static class KernelAPI
  {
    [DispId(1610612736)]
    [MethodImpl(MethodImplOptions.PreserveSig | MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]
    public abstract int WritePrivateProfileStringW([MarshalAs(UnmanagedType.BStr), In] string lpApplicationName, [MarshalAs(UnmanagedType.BStr), In] string lpKeyName, [MarshalAs(UnmanagedType.BStr), In] string lpString, [MarshalAs(UnmanagedType.BStr), In] string lpFileName);
  }
}

It generates a static class with an abstract member. That doesn't make any sense. Of course I can change the code to export it differently but why does TlbImp2.exe do so in the first place?

I'm assuming it exports it that way because it exports the module's constants. Am I right? What modifiers should I apply to the WriteProfileString method in order to ensure it can be used with interop?

Answer 1

It is easier to use the native api directly instead of jumping through all COM hoops..

from pinovke.net:

[DllImport("kernel32.dll", CharSet=CharSet.Unicode, SetLastError=true)]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool WritePrivateProfileString(string lpAppName,
   string lpKeyName, string lpString, string lpFileName);

Answer 2

Type libraries support a super-set of declarations that Tlbimp.exe supports. The ability to declare exports from a DLL is not used very often, type libraries are first and foremost vehicles to export COM declarations.

There's little you can do with Tlbimp to solve this problem. Nor should you try to solve it since the alternative is so simple. Just write a pinvoke declaration.

Do consider the next step, Read/WritePrivateProfileString() have really awful runtime behavior due to the heavy legacy appcompat built into Windows. Reading a single INI parameter costs about 50 milliseconds. Read 20 of them and you've blown your startup time with doing nothing very useful. And it is very lossy, it is entirely agnostic of text file encoding. You cannot typically use the built-in .NET support for Settings in a library, but an XML file is a fine substitute.