I have created a .NET assembly that is exposed to COM according to the exceptional article Build and Deploy a .NET COM Assembly by Phil Wilson.
And everything works fine in the sense that the .NET assembly is properly registered for COM, and compiled COM code can call it without any trouble.
The only odd thing is that developing against the COM-exposed .NET assembly when using VB 6.0 or VBA requires that the programmer 'browse' to the exact file location of the associated .tlb file, after which everything works just fine. That is, the class library is not showing up directly within the References dialog box, so you must browse to the file location.
Again, the COM Interop aspects do work 100%; however, I would think that there must be some setting that would make the library directly visible within the References dialog for VB 6.0 and VBA.
Does anyone know what this setting would be? Or should this be happening automatically for me just by having it registered?
Much thanks in advance for any advice...
Mike
Edit/Update
To answer jpoh's question about whether I'm using the /codebase switch, I'm using a .msi Setup Package, and not explicitly using RegAsm. The assembly is being correctly registered, which can be seen by the fact that within HKCR\CLSID{myGUID}\InprocServer32, the 'CodeBase' key correctly holds the full path to the assembly. Compiled COM components execute against this dll just fine, it's only when developing against it using VB 6.0 or VBA that they do not appear within the references dialog box. I therefore need to 'browse' to the correct file location, after which it works 100% fine.
Update #2
Upon further research, it appears that, although the class GUIDs are being registered properly, my .tlb file is not being registered. I have no idea why not. Registering the .tlb file should put some registry entries for the interface on which my class is based at HKCR\Interface{myInterfaceGUID}, but this is not occurring. Strange that this lack of registration does not seem to affect the dll's ability to function, other than its discoverability within VB6's and VBA's references dialog.
The properties for my .tlb file within the Setup Project do seem to be correct: the 'PackageAs' property is set to 'vsdpaDefault' and the 'Register' property is set to 'vsdrfCOM'. I am puzzled as to why this would not be successfully installed on the target machine.
Update #3
Ok, it turns out that the Setup Project is not being built successfully... despite it reporting that the "Build Succeeded".
There is actually a build warning (amazingly, a warning, not an error) being reported that it as "Unable to create registration information for file name 'DotNetLibrary3.tlb'". Since this was a warning, and not an error, the compile was stating "Build Succeeded" and the Error List was not opening up.
Tracking this down, it seems that this can be an issue when attempting to create a Setup Project when Vista is your development machine, as described here:
COM typelib registration problem in VS2008 Setup project
There is a somewhat manual fix described here:
Feedback: Unable to create registration information for file named 'filename'
I have not tried the fix yet, but I will tomorrow and I'll report back if this solves it.
Update #4
That did not work out so well... It seems that running RegCap.exe as suggested in that article does not work when running on Vista. Since RegCap is actually run internally by the setup project itself on creating the .msi, this is not terribly surprising. In short, the setup project was almost certainly failing because the RegCap command that it was calling was failing... So calling RegCap directly is of no help.
The bottom line is that this is simply a bug when attempting to create a setup package on Vista. Or, perhaps it is a combination of Visual Studio 2008 and Vista, I'm not sure. Attempting the same exact approach is to create a setup project on Visual Studio 2005 running on Windows XP had absolutely no problems whatsoever.
There very well may be fixes to get this running right on Vista and/or Visual Studio 2008, but I could not track it down. Much more efficient for me was to build using Visual Studio 2005 on Windows XP to generate the COM registration requirements, and then to import them into my Visual Studio 2008 setup project. These can be exported as .REG files via regasm using a /regfile switch against the dll and using RegCap (running on W'XP!) against the .tlb file. Since my COM interfaces will not be changing, I only have to do this once.
Hopefully this issue in Visual Studio 2008 when running on Vista will be corrected at some point, but if not, hopefully this post will be of some value to someone else who finds him or herself in the same situation...
See Also:
-- Mike