11

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

Community
  • 1
  • 1
Mike Rosenblum
  • 12,027
  • 6
  • 48
  • 64
  • Clarification: The TLB not registering will not prevent compiled DLL's from using your COM DLL, if the GUID's have not changed. The TLB's sole purpose in life is to provide type information to the IDE at design time and to your compiler at build time, but once a DLL is built against your COM DLL, the TLB is technically no longer necessary (the GUID's are "hard-wired" into the DLL when it is built). Hence existing DLL's that use your COM assembly will work without the TLB being present. – Mike Spross Apr 25 '09 at 04:16
  • To further clarify, the TLB file is needed initially in order to register the COM assembly, but after the class and interface ID's are registered, it's no longer needed. When you instantiate a COM class, COM won't even look at the TLB file or the TypeLib entries in the regstry. Only the CLSID's and IID's matter at object instantiation time. – Mike Spross Apr 25 '09 at 04:20
  • Thanks Mike, that was a very, very clear explanation, and it makes a lot of sense. Thank you! – Mike Rosenblum May 15 '09 at 11:43
  • Did you ever get a satisfactory resolution on Vista+VS 2008? I am making an Excel addin in VB.NET, and it has to be exposed as a COM server, and I've tried every dead end that you have listed here. – hughdbrown Oct 01 '09 at 20:34
  • Hi Hugh, I saw your thread first before noticing your comment here. So I replied there: http://stackoverflow.com/questions/1506858/how-to-get-com-server-for-excel-written-in-vb-net-installed-and-registered-in-aut/1506932#1506932 – Mike Rosenblum Oct 01 '09 at 23:09

5 Answers5

2

Did your regasm command include the /codebase flag?

jpoh
  • 4,536
  • 4
  • 35
  • 60
  • Actually, I'm using a .msi Setup Package, and not explicitly using RegAsm. The assembly is being correctly registered -- within the HKCR\CLSID\{myGUID}\InprocServer32 is the 'CodeBase' key correctly holds the full path to the assembly. – Mike Rosenblum Apr 13 '09 at 13:21
  • Again, compiled COM components find it and execute just fine, it's only when developing against it using VB 6.0 or VBA that I need to 'browse' to the correct file location. Is there another setting, file location, or registry value I need? Or is something else going "wrong" with my installation? – Mike Rosenblum Apr 13 '09 at 13:23
  • The entries in the References dialog box come from the HKCR\TypeLib registry key, not from HKCR\CLSID. If your assembly does not show up in the References dialog but compiled DLL's can still use your COM assembly, it means the classes and interfaces were correctly registered for your assembly, but that the type library itself was not. This would appear to be a bug with VS2008 in Vista, as mentioned in the forum thread you linked to. Running regasm explicitly from your MSI should fix it. – Mike Spross Apr 25 '09 at 04:44
  • Ah, gotcha, that explains the mystery, Mike. That makes sense, as this is exactly the behavior that I was getting: compiled code that referenced the dll ran fine, but to develop against the dll required that I browse to the dll location. Your idea to run Regasm explicitly from the MSI is a good idea. Instead I developed the required .REG files using Regasm and Regcap on a W'XP machine and utilized those from the MSI, but either way you have to do an end-around on the MSI's default behavior when developing on Vista. A strange bug. Thanks for your thoughts Mike, it's a big help. :-) – Mike Rosenblum Apr 25 '09 at 11:56
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.

John Thewlis
  • 1
  • 1
0

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.

Atario
  • 1,371
  • 13
  • 24
  • Atario, thanks for that thought. I'll have to give this a try next time. (And there will be a next time!) It could be weeks from now before I try this again, but when I do I'll post back to let you know how it goes. Thanks a ton for your input. – Mike Rosenblum Jul 24 '09 at 22:53
0

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

Simon A
  • 1
0

You can use the ability to generate TLB and ComVisibleAttribute in .net projects to create a file with the extension tlb for this website along with the Ija dll, now you can add this file to your com level project and enjoy this feature. But it should be noted that the installation of the .NET version related to the main project is required enter image description here

BQF
  • 33
  • 7