How Add a COM-Exposed .NET Project to the VB6 (or VBA) References Dialog?

一笑奈何 提交于 2019-11-30 15:02:15

问题


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:

How to get COM Server for Excel written in VB.NET installed and registered in Automation Servers list?

-- Mike


回答1:


Did your regasm command include the /codebase flag?




回答2:


I know this was a long time ago, but I can't find any sensible answers. I had a similar problem and the resolution was to run Visual Studio as the same user who installed it. If I run it as a different user everything except the COM registrations works.




回答3:


It doesn't give the warning if you run VS2008 under Vista, but not elevated. Elevated is the way we (Vista users) learn to always use the thing, but for this, for some reason, it likes it better the other way.

N.B.: while elevated, mine launched some sort of install for SQL Server Tools that I was eventually able to get past, but when running not elevated, it tries to do this again and fails with permission problems. It doesn't seem to affect the actual build result, though.




回答4:


The Typelib registry entries will be missing in the registry. You need to use regtlibv12 [path]MyTypeLib.tlb from the Microsoft.NET\framework\ folder for the version of .NET you built the assembly with. After doing this, the additional registry entries will exist, and VBA references can find it. Alternatively for Windows 10 I use regtlib.exe [path]MyTypeLib.tlb in the windows folder You must then reharvest the asesembly for your installer so it now has the typelib entries. I personally use wix installers, and use 'heat' for this purpose. Regasm /regfile will not do it. Use heat on both the .dll and the .tlb to get both the classid and the typelib registry entries



来源:https://stackoverflow.com/questions/742851/how-add-a-com-exposed-net-project-to-the-vb6-or-vba-references-dialog

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!