none
register typelib (COM Interop) properly RRS feed

  • Question

  • Hi

    I have a COM-visible assembly, designed for Windows-Scripts ( WSH, sig ;-) )
    registered it with regasm and the options


     regasm <mycomassembly.dll> /register /codebase /tlb

    Console output was: everything OK.
    Now I can created the COM-classes in VBS, JS or WSF scripts.
    But there is problem importing the "identifiers", that is public constants and
    enumerations of my com-visble classes, which should be exposed by the typelib.

    In a WSF-script this can be achieved through the <object> element and its
    special "reference"-attribute, which  - when set to 'True' - should import the identifiers.
    (unfortunately, the refernce-attribute isn't mentioned by the docs,
    only the reference element, but the attribute exists anyhow... the refernce attribute should look for the typelib GUID in the registry
    and then find the local file path and import it, but it doesn't seem to find it..)
    Using the refernce atribute works for example for built-in ActiveX-classes
    such "Scripting.FileSystemObject".
    When I try to reference my typelib in a WSF script like:

    <object id="keywatch" reference="True" progid="MyLib.MyNamespace.KeyWatch" />

    it says: 0x80040068 "Typlib for this reference not found".
    So the /tlb switch doesn't seem to do the full job, does it ?!?

    I tried it with a x64 Dll-build and the x64-regsam and with
    a x86 versions of both.

    Registering in itself always works fine, but the typelib/reference
    thing fails.

    Platform is Windows 7 x64.

    Where's the point?

    Regards,
    Chris









     
    Sunday, February 19, 2012 4:30 PM

Answers

  • Hi once again

    I got it working if I compile with "Any CPU" and
    when using the reference element with the guid attribute:

    <object reference="false" progid="MyLib.MyClass" />
    <reference guid="{0000002F-0000-0000-C000-000000000046}" />

    where the guid value is the guid of the assembly (AssemblyInfo.cs)

    The enum values then can be accessed in script
    with the enum name as prefix:

    C#
    enum Size
    {
         Big,
         Small
    }

    becomes


    TLB:
    enum Size
    {
         Size_Big,
         Size_Small
    }

    So 'Size_Big' is a constant I can use in script.
    Maybe there' some attributes to remove the prefix.

    Thursday, February 23, 2012 11:38 PM

All replies

  • I am not familiar with WSH development. According to your command options, I'd like to know whether the assembly you would like to resgister is strong-named and whether the generated type library is able to be found in X86 folder or x64 folder?

    Pleaser refer to description of Regasm command options:
    /codebase

    Creates a odebase entry in the registry. The Codebase entry specifies the file path for
    an assembly that is not installed in the global assembly cache. You should not
    specify this option if you will subsequently install the assembly that you are
    registering into the global assembly cache. The
    assemblyFile argument that
    you specify with the
    /codebase option must be a strong-named
    assembly
    .

    /tlb [:typeLibFile]

    Generates a type library
    from the specified assembly containing definitions of the accessible types
    defined within the assembly.

    If it is strong-named, maybe you can try the command below:

    regasm <mycomassembly.dll> /codebase /tlb:myCOm.tlb


    Paul Zhou [MSFT]
    MSDN Community Support | Feedback to us

    Wednesday, February 22, 2012 7:13 AM
  • Hi Paul

    Thanks for your reply.
    Yes the assembly is signed and strong named, and the files (dll and tlb)
    are found after building (in x86 a/o x64 subfolders, depending on configuration).
    Specifiying the tlb-path explicitly works - tlb is created - but doesn't change the issue.

    Searching the registry I noticed that the tlb-file is registered
    in the "TypeLib" branch(es). Also the enum values I'd like to
    reference are present in the "Record" branch.
    But there is no "TypeLib" subkey in the CLSID\{MyGuid} registry branch.
    In old times when creating ActiveX libs with VB6 or ATL there always was
    a TypeLib subkey that linked the CLSIDs to the typelibs.

    Maybe there's another mechanism for associating CLSID with typelibs.
    Maybe it has got something to do with some 64 to 32 transition or vice versa.

    Anyhow, I stop wasting time on this prio-5 subject.
    The scripts work also without these references, if the
    constant values are defined inside the script explicitly.

    Regards,
    Chris

    Thursday, February 23, 2012 9:59 PM
  • Hi once again

    I got it working if I compile with "Any CPU" and
    when using the reference element with the guid attribute:

    <object reference="false" progid="MyLib.MyClass" />
    <reference guid="{0000002F-0000-0000-C000-000000000046}" />

    where the guid value is the guid of the assembly (AssemblyInfo.cs)

    The enum values then can be accessed in script
    with the enum name as prefix:

    C#
    enum Size
    {
         Big,
         Small
    }

    becomes


    TLB:
    enum Size
    {
         Size_Big,
         Size_Small
    }

    So 'Size_Big' is a constant I can use in script.
    Maybe there' some attributes to remove the prefix.

    Thursday, February 23, 2012 11:38 PM