views:

1492

answers:

2

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

+2  A: 

Did your regasm command include the /codebase flag?

jpoh
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
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
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
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
A: 

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
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

related questions