How can I register a COM enabled .net dll's type library (.tlb) file programmatically on a user's pc?

Did you use the Excel add-in template to create the .dll? Did you set the build properties to Register for COM Interop?

Technically, it is not an add in (it is unnecessary for it to be one), it is just a .net class library, with both "Register for COM Interop" and "Make COM visible" ticked.  It is also <strong>not</strong> signed (contrary to what Microsoft say, it is <strong>not</strong> necessary to put dlls in the Global Assembly Cache, nor is it necessary to make them strongly signed when using the /codebase flag with regasm).

For a very simple project, such as the one in the code snippet below, all that seems necessary for Excel VBA to be able to use the dll is that 1) the dll and tlb files generated by Visual Studio 2008 be placed in the same folder (e.g c:\test) on the client pc, 2) the dll be registered using (when running as admin from a command line) regasm "c:\test\COMEnabledClassLibrary.dll" /codebase and 3) that the VBA project have a reference to the tlb file.

My real life project has many more interfaces, classs and methods, including some with generics (which I know can't be exported to COM, but I'm not using those particular methods from COM, only from .net).  On some pcs, all that is needed is the three steps above. On some others, I get an "Object library not registered" error either at compile or run time in the Excel VBA project, and I can solve this by registering the COMEnabledClassLibrary.tlb file, either without regenerating it by 4a) running regtlibv12.exe "c:\test\COMEnabledClassLibrary.tlb", or by regenerating it by 4b) running regasm "c:\test\COMEnabledClassLibrary.dll" /codebase /tlb, in each case as administrator.

Aside from the issue of how to automate things (and thus avoid administrators at my clients having to run regasm or regtlibv12 from a command line), two things are puzzling about this: why the tlb file needs registering on some pcs but not others, and why the tlb file needs regenerating on some pcs and not others.  The original tlb file must include file paths on my development pc which do not match up with the deployment path on the client pc (in this example c:\test\), so if the tlb file needs registering at all I would have thought that it needed to be regenerated so that the correct path(s) could be stored in the registry, however VBA manages to get round that on some pcs.

For pre .net COM dlls (e.g. those generated by VB6), simply setting a reference to the dll in a VBA project was enough to register the dll, but for a .net COM enabled dll (such as I am using), it is not clear to me exactly what setting a reference to the .tlb file does.  Perhaps it registers the tlb file on some pcs, registers both the tlb and dll file on others, and simply enables the VBA project to compile on others without doing any registration.  (If so, that might explain why different actions are necessary on different pcs).  

I can run regasm with /codebase and /regfile to produce a .reg file which (without registering the dll or tlb file) shows me the registry entries needed to register the dll, but not the tlb file (one can't run regasm with both /regfile and /tlb, which seems silly, or at least Microsoft ought to have provided a way of producing a reg file with just the registry entries needed to register the tlb file).
Regtlib.exe and its successor regtlibv12.exe, which seem to be deprecated by Microsoft (they seem to have disappeared from my Vista pcs after some recent Windows updates, and don't seem to be documented properly, might provide information as to what registry entries are needed for a tlb file (e.g. if they allow a similar /regfile flag but I can't find any documentation that suggests that they do - I may try it as an experiment).

// 16 Jun 2008 Simple .net 3.5 C#Project to provide a minimum COM enabled (via Make COM visible and Register for COM Interop project properties) library
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace COMEnabledClassLibrary
{
 
    /// <summary>
    /// 
    /// </summary>
    public interface ICOMTestClass19
    {
        /// <summary>
        /// 
        /// </summary>
        int ReturnSeven();
     
    }
 
    /// <summary>
    /// 
    /// </summary>
    public class TestClass19 : ICOMTestClass19
    {
 
        #region ICOMTestClass19 Members
 
        public int ReturnSeven()
        {
           return 7;
        }
 
        #endregion
    }
}
 
// the corresponding simply VBA client code using this is
Public Sub Test
Dim obj as ICOMTestClass19
Set obj = new TestClass19
dim i1 as Long
i1 = obj.ReturnSeven
End Sub

Select allOpen in new window

Update: I have tested regtlibv12.exe and it ignores any /regfile flag so that can't be used to produce a .reg file with registry entries needed to register the .tlb file.
You experts might also like to know a bit of background: this is for a network installation of my software.  The dll and .tlb file are installed on a shared folder on the network, and each pc has been configured (via caspol) to trust software in that precise location (otherwise .net security by default won't allow the code in the dll to run).

Our client doesn't want to have to run a Windows Installer package on each pc, so, given the relatively small number of files involved (effectively just the dll and tlb file) putting the dll and tlb file in a shared folder on the network and getting them registered for each pc in an automated way seems to be the best way to deploy the software (with Excel VBA as one of the front ends).  Until recently, the registration has been done via login scripts (.bat files running [with admin rights] regasm pathtodllfile /codebase) but on a few pcs the tlb file seems not to have been registered (whereas it had been on the majority of pcs, possibly [as surmised above] via Excel VBA setting a reference to the tlb file), so we tried amending the .bat scripts to run regasm pathtodllfile /codebase /tlb: pathtotlbfile but the scripts seem to have failed silently, hence the need to run regasm pathtodllfile /codebase /tlb: pathtotlbfile as admin from the command line on each pc.
Am investigating why the scripts failed by getting them to report success/failure and to pause before being dismissed by the user, but any insights you can offer as to a) whether setting a reference in Excel VBA to a .tlb file sometimes registers the tlb file, and b) other advice if you would deploy things differently will be appreciated.

Did you try registering as below

regasm/codebase yourdotnetdll.dll /tlb:yourdotnetdll.tlb

I forget to mention you to do that from the command prompt

shasunder: (apologies for not replying earlier, somehow I missed your post) if you read my comment of 06.17.2008 at 10:22PM BST immediately before yours, you'll see that in the end we had to do precisely what you suggested:

regasm pathtodllfile /codebase /tlb: pathtotlbfile as admin from the command line on each pc.

so I'm afraid your comment doesn't add anything new.  

I conclude that this is an area where noone seems to know the answer (or perhaps people at Microsoft do, but if so, they aren't posting on this exchange.)
I am going to suggest to the admins that this post remain as unsolved, because it at least offers some suggestions of things to try and some manual solutions if others are looking at this area.


 

The learned one:
Rather than classify this question as abandoned and deleting it, I suggest leaving it with some other status, e.g. unsolved, because it at least offers some suggestions of things to try and some manual solutions if others are looking at this area.
Regards
Patrick