I'm writing COM compatible .Net DLL. In other words I'm writing a .Net DLL that, and I need it compatible with VBA so I have already set "Make Assembly COM-Visible"=True and checked "Register for COM interop". When I compile the Project it generates the tlb file and I'm able to reference the tlb from VBA. But once I go to instantiate a class I find a problem. Only one of the many public classes is availible.
My assembly is called TAS_RS_Calcs and I have several public classes including RefProp, Fluid, StreamPath, etc. So I should be able to see Fluid, for example, under TAS_RS_Calcs, but all I get in the intelliscense is RefProp.
Dim g As New TAS_RS_Calcs.Fluid fails from VBA, but Dim g As New TAS_RS_Calcs.RefProp works.
While Dim g As New TAS_RS_Calcs.Fluid works fine in .Net
So it seems that in the translation from COM to CLR there is a problem or vise-versa. This DLL was fully functional before I don't know what I could have done to cause this.
Here are my Class Declarations:
<System.Runtime.InteropSer
Partial Public Class RefProp
<System.Runtime.InteropSer
Public Class Fluid
<System.Runtime.InteropSer
Public Class StreamPath
and I've tried removing the class interface prefixes to see if that would help and it doesn't.
Can someone please tell me why only one class is accessible via the tlb COM reference?
ScreenShot of intellisense in both environments
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
OK, so I have to manually build and interface, Assign a GUID and ClassinterfaceType.None for each Class? And Change my Assembly GUID because it was initially registered with AutoDual?
But I don't waannaa.. <in a whiney voice>
I have tens of properties in each class. It there not a reliable way of having the interface generated?
Do you think the tlb is "stuck" with the original GUID because of the use of AutoDual?
Sadly, I don't remember a lot of the details. I learned a lot of this stuff from the book I mentioned. There was a reason for not wanting the AutoDual and I forget exactly why at this point. I seem to remember that you absolutely must have a seperate interface for this to work. It had something to do with how Com accessed objects. I think vbscript uses IDispatch and VB6 either/or. They're calling it "custom" here (http://publib.boulder.ibm
Anyway, the steps I described in the document were guaranteed to work. I certainly suspect not every one of them is critical (some are). I had so much trouble getting my solution to work that I think I took the brute force approach to guarantee success.
Honestly, declaring interfaces in any context seems equally tedious. I don't know of a shortcut. But, quit your wining, it's not that big a deal! :)
ok, I set the Created and interface for on class and implemented it. I also assigned GUIDs, set the Com visibility and set the interface type tpo none.
<ComVisible(True), Guid("756C858E-5C9B-427e-B
Public Interface IFluid
ReadOnly Property FluidName() As String
ReadOnly Property Quality_() As Double
Function GetExergyFlow(Optional ByVal sFlow As Double = 0, Optional ByVal sFlowUnits As String = Nothing) As Double
End Interface
<System.Runtime.InteropServ
Public Class Fluid
....
At the assembly level, I created a new GUID and tried both AutoDispatch and None for interface type:
<Assembly: ComVisible(True)>
<Assembly: ClassInterface(ClassInterf
' old <Assembly: Guid("183f40c1-f1b0-479e-b
<Assembly: Guid("6584A37D-A400-43b2-A
I rebuilt, unregistered and reregisterd/installed on test machine and it still only shows the one (RefProp) class
So your interface has all the methods and properties you want to be seen in COM?
Public Interface IFluid
ReadOnly Property FluidName() As String
ReadOnly Property Quality_() As Double
Function GetExergyFlow(Optional ByVal sFlow As Double = 0, Optional ByVal sFlowUnits As String = Nothing) As Double
End Interface
I don't even see RefProp in this list.
btw - I'm not sure if COM supports "optional" arguments. I don't know. You might want to keep your eye on that one.
When you change GUIDs and recompile, you have to unregister the OLD ASSEMBLY before you can reregister the new. It's super easy to end up with remnant registry entries referencing the old interface. I remember manually yanking lots of entries with regedit. After an unregister, you should not find any mention of the method names. I suspect you're still missing a step and you're seeing artifacts from previos experiments.
I was also able to add a new class with it custom interface and it works great, but my other classes that were there at the time when i built using AutoDual (like Fluid) still will not show up even if I do the same things.
this works fine:
Public Interface IExpander4
ReadOnly Property CGS() As String
End Interface
<System.Runtime.InteropServ
Public Class Expander4
Implements IExpander4
Public ReadOnly Property CGS() As String Implements IExpander4.CGS
Get
Return "hi"
End Get
End Property
End Class
ok, Maybe i missed something.
1) I unregisterd using regasm:
c:\Program Files\Microsoft Visual Studio 9.0\VC>regasm /u "C:\Documents and Sett
ings\bblanco\My Documents\Visual Studio 2008\Projects\TAS_RS_Calcs
bin\Debug\TAS_RS_Calcs.dll
\Visual Studio 2008\Projects\TAS_RS_Calcs
b"
Microsoft (R) .NET Framework Assembly Registration Utility 2.0.50727.3053
Copyright (C) Microsoft Corporation 1998-2004. All rights reserved.
Types un-registered successfully
Type library 'C:\Documents and Settings\bblanco\My Documents\Visual Studio 2008\
Projects\TAS_RS_Calcs\TAS_
cessfully
I did this for both the Debug and Release version.
2) Then I generated a new GUID and put it in the AssembyInfo.vb file. Is there somewhere else I should be putting this? <Assembly: Guid("86DE7B1D-006C-4993-8
3) I rebuilt the assembly
4) I re-referenced in in Excel
But it still doesn't show the Fluid Class and it still shows RefProp
You're registering a TLB with regasm? I've never seen that. I registered the DLL itself. The /tlb extracts the type library from the assembly and registers all public/com visible members. Since I'm not familiar with that syntax, I can't be sure if it's the same thing.
Once you're on your way you definitely don't want to be changing guids.
My point of cleaning the registry is that it's too easy to miss unregistering something before changing guids, especially when you're changing them, or allowing the compiler to auto-assign them. You can unregister the new one all day long, but you'll still have remnants from previous versions registered with the same member names if you forgot to unregister them. I'd definitely do an audit. I can't overstate how important that it. You can spin your wheels, not realizing there are orphaned entries masking your new ones.
After you've done this and if the problem remains, you'll have to post some code. It's just not possible to know what's going on without seeing it all, especially when the code you have posted doesn't match what you're reporting.
:(
Well, Unregistered the tlb and the dll:
c:\Program Files\Microsoft Visual Studio 9.0\VC>regasm /u "C:\Documents and Sett
ings\bblanco\My Documents\Visual Studio 2008\Projects\TAS_RS_Calcs
bin\Release\TAS_RS_Calcs.d
ts\Visual Studio 2008\Projects\TAS_RS_Calcs
s.tlb"
Microsoft (R) .NET Framework Assembly Registration Utility 2.0.50727.3053
Copyright (C) Microsoft Corporation 1998-2004. All rights reserved.
Types un-registered successfully
Type library 'C:\Documents and Settings\bblanco\My Documents\Visual Studio 2008\
Projects\TAS_RS_Calcs\TAS_
uccessfully
c:\Program Files\Microsoft Visual Studio 9.0\VC>regasm /u "C:\Documents and Sett
ings\bblanco\My Documents\Visual Studio 2008\Projects\TAS_RS_Calcs
bin\Release\TAS_RS_Calcs.d
Microsoft (R) .NET Framework Assembly Registration Utility 2.0.50727.3053
Copyright (C) Microsoft Corporation 1998-2004. All rights reserved.
Types un-registered successfully
Then removed any reference to either in the registry.
Created a new GUID and rebuilt the assembly.
Still the same.
This is the new test class that I added that works properly
__________________________
Public Interface IExpander4
ReadOnly Property CGS() As String
End Interface
<System.Runtime.InteropServ
Public Class Expander4
Implements IExpander4
Public ReadOnly Property CGS() As String Implements IExpander4.CGS
Get
Return "hi"
End Get
End Property
End Class
This is an old class does refuses to show up:
__________________________
<ComVisible(True)> _
Public Interface IFluid
ReadOnly Property FluidName() As String
ReadOnly Property Quality_() As Double
Function GetExergyFlow(Optional ByVal sFlow As Double = 0, Optional ByVal sFlowUnits As String = Nothing) As Double
End Interface
<System.Runtime.InteropServ
Public Class Fluid
Inherits RefProp
Implements IFluid
Dim lFluidName As String
Dim lUnits As RefProp.Units
Dim lOutputUnits As Units
Public ReadOnly Property FluidName() As String Implements IFluid.FluidName
Get
Return lFluidName
End Get
End Property
Public ReadOnly Property Quality_() As Double Implements IFluid.Quality_
Get
If IsMissing(lQ) Then
lQ = QualityC(lInpCode, lProp1, lProp2)
End If
Return lQ
End Get
End Property
...
...'and so on
End Class
This is the only original class that show up:
__________________________
<System.Runtime.InteropServ
Partial Public Class RefProp
...
...
end class
__________________________
Partial Public Class RefProp
...
...
end class
__________________________
If you notice in my blog, I'm NOT registering or unregistering a type library file (TLB). I'm registering the DLL itself, but extracting the type library. You still haven't hit on the exact sytax I had listed. Check that out. I can only assume that I had a reason for that.
Why do you keep changing the GUIDs? That will only add to your heartburn - a sure fire way to accumulate registry remnants.
In fact, as I look at your sample and read through my instructions, I see other differences, but it may be because you're pasting in snippets. The Fluid class isn't marked com visible, nor does it have a guid. The IFluid interface is marked visible, but has no guid.
This is a tough problem to troubleshoot without another computer. I was thinking of trying a sample, but I don't have another computer here.
Unless you just left out the above mentioned items from this post, I think you really need to go back and re-read the instructions and compare the two carefully. If you do all that and it still doesn't work, you should post a small, complete project that demonstrates the problem.
.Net actually registers the tlb automatically when the assembly is built(compiled).
As for the syntax, I assume you mean the use for the InteropServices prefixes like the GUID and the ComVisible setting. I tried using that syntax and it did not work. I found that these arguments were not neccessary when defining the new test classes that I added either, so after I tried them on the Fluid class it they had no effect I removed them. My third post shows the following:
<ComVisible(True), Guid("756C858E-5C9B-427e-B
Public Interface IFluid
ReadOnly Property FluidName() As String
ReadOnly Property Quality_() As Double
Function GetExergyFlow(Optional ByVal sFlow As Double = 0, Optional ByVal sFlowUnits As String = Nothing) As Double
End Interface
<System.Runtime.InteropServ
Public Class Fluid
....
Am I missing something? It's been known to happen. I'll go ahead and add these arguments back, just in case.
I thought the old class definition was somehow "stuck" with the GUID. I understood that changing the GUID was key. i also found that unregistering the tlb was effective in removing all references to the tlb, dll, and the associated GUID from the registry.
I would post the project, but I'm not sure it would do any good, since it depends on a set of COM dlls from a licensed tool called REFPROP from the National Institute of Science and Technology, so you would be able to compile it unless you bought REFPROP.
>>.Net actually registers the tlb automatically when the assembly is built(compiled).
This is not the case on the remote box, of course. That's what we're discussing, with regards to regasm /tlb. The "auto register" is controlled by "register for com" checkbox on the project properties. I'm under the impression that your problem is on the other box, and thus everything I've discussed about registration was centered there.
As long as you unregister the OLD version before replacing the assembly with the new version and registering that, changing the guid wouldn't be necessary. Hard-coding the guid simply ensures it never changes, which would break your bindings.
I know I had such a hard time getting this all to work back then, I carefully documented the steps in case I had to do again sometime. Until proven otherwise, I have to trust what I wrote. I understand why you'd be tempted to remove atrtibutes that didn't seem to work, but my concern is that if you missed some other step it could appear that the attributes didn't work and thus were unecessary.
So, where do we stand? Can you get a test library to work, with multiple classes with multiple members to work 100%? You talk about a 3rd party library, but I thought that was the only one that DID show up via COM.
My problem is not just on the remote box. I've been trying to get it to work on my dev machine first. either way i get the same result. No update to the tlb.
What do you mean by replaced the assembly with a new version? Create a new project in .Net or just building it with a new Assembly version?
I do have those class interface interop attributes added back.
I'm sure I can get a test library to work. I've had no problem adding new clases to this library an making them show up, but the problem seems to be with th classes in this library that were already there when i used autodual.
REfPROP is a third party COM dll. I'm creating a .Net wrapper for it so that it can be used by both .Net and COM clients. I'm also adding a bunch of classes of my own to this wrapper to extend it sfundtionality
Imagine you create a library with 10 guids in it. You register that library on a remote box. Then you change all the guids and recompile it. If you register THAT library on the remote box you'll have orphaned garbage with the old guids. You can't unregister it, because you've already replaced it. So you'd need to unregister the new one, restore the original assy and unregister THAT one to get rid of everything.
What do you mean by no update to the tlb? When the .net assy is copied to the remote box and registered with regasm /tlb, the type lib data is extracted from the assembly, not a tlb file. But it does create a tlb in the process. So in THAT file is where you can't find your other classes?
I really suggest you try to pick up the recommended book. I just dragged them out and was looking through the chapter about this very topic. There's so much to this that you should read through.
Note that any class to be exposed to COM must have a parameterless constructor. Probably not your issue, but you should be aware of it.
I'm not sure what to tell you. This is tough to work through in this format. You're saying that you can add new classes to this library and they show up? But existing classes that are all marked correctly with attributes don't? That would be very odd. What if you renamed them as a test? I don't understand how new classes can be added, but existing ones don't show up. Unless there's a problem with the registry as far as this assy is concerned.
>> You're saying that you can add new classes to this library and they show up? But existing classes that are all marked correctly with attributes don't? That would be very odd. What if you renamed them as a test? I don't understand how new classes can be added, but existing ones don't show up. Unless there's a problem with the registry as far as this assy is concerned.
That is correct. Or at least as of yesterday.
And I just tried renaming them to no avail.
AAAAnd the new classes I added today will not show up now.
Guess I'll submit the project for scrutiny.
Here is the code.
http://brazosportarea.com/
Yesterday before I left for the day, I was able to create a few COM visible test Classes successfully.
So this morning a I created another one called MaterilaStream with only two props. It worked.
Then I moved over allt he methods and props from Fluid to MaterialStream. Only the orininal two showed.
I backed up and slowly added the props and methods from Fluid a few at a time and the class finally showed everyhting.
Then I created a new empty class in another class module to do this same thing for the MaterialStreamPath class. So the new streamPath class showed up, BUT MaterialStream class was was just successfully added disapperared!!
This thing is flakey!
I registered the the dll with regasm verbose and got a strage result. Where the output is supposed to list the classes registered it says "Type 'T' exported" several times. Then i tried having regasm create a Registry file and it only generated reg entries for Refprop and the new empty test classes. It still ignored several classes. I don't think regasm like my assembly. Any ideas?
I meant to work on this last week. I even started a new project for it. Got sidetracked with work. So you can add new classes and see them. RefProp is there. But the other classes, like "Fluid" are not visible?
So I just worked up the a test library. I created a base class Fruit, along with its interface. Applied the COM attributes by copying the code from your Fluid module, chaning the GUID.
Next I created another class called Banana and based it on Fruit. Applied the attributes the same way.
I did NOT enable COM Interop in the project because I wanted to make sure the typelib was being generated correctly (manually) and nothing behind the scenes (visual studio) was masking an error in the manual generation.
Compiled.
regasm interoptestlib.dll /tlb /verbose
I got a simular mesage as you:
>regasm interoptestlib.dll /tlb /verbose
Microsoft (R) .NET Framework Assembly Registration Utility 2.0.50727.4016
Copyright (C) Microsoft Corporation 1998-2004. All rights reserved.
Types registered successfully
Type 'I' exported.
Type 'I' exported.
Type 'I' exported.
Type 'I' exported.
Assembly exported to '...interoptestlib.tlb', and the type library was registered successfully
Next, I looked at the typelib with OLE View. I could see my classes and properties (methods get/put) in the interfaces.
Next, I went into VB6. After setting the reference I could easily see the properties of both the base class and the sub class. Intellisense was perfect. When referencing the child class, I did not see any of the base class' properties. I don't know if there's a way to get that behavior. That would be a research item.
Option Explicit
Public Sub main()
Dim fruit As InteropTestLib.fruit
Dim banana As InteropTestLib.banana
fruit.Color = ""
fruit.Name = ""
banana.Length = ""
End Sub
Everything went quite smoothly. I really don't know what to say! Does this sound exactly like what you're doing?
Pretty much, except, that VBA will only see Refprop and those test classes I added last.
Did your interoptestlib.dll assembly have Refprop and my other classes in it or was it a fresh new assembly???
if so, I guess maybe the regasm and TLBExp are tripping on one of my classes then failing to build the interface structure for the others.
I see that I actually mentioned this in the blog. I noticed that I had NOT used this feature in the past project, so I must have documented the theory of the option, but not tested it in use. To understand how to use that global settings would take some research. For now, it seems that you should be able to export those members you want exported. Perhaps this finding could be used as a clue in searches if you really wanted to get it working on a global level. I don't know why it prevented items from appearing that were explicitly made visible.
Something I noticed, though, was that even those these classes wouldn't appear in intellisense as Types, they DID appear in the object browser as classes. I'll bet it's something simple.
Boy, do I feel dumb!? You were right about the class needing a parameterless constructor. that was it. I kind of blew that off because I thought that applied to another type of interop.
"...COM must have a parameterless constructor"
Didn't need the GUID's. Here is what worked
Imports System.Runtime.InteropServ
<ComVisible(True)> _
Public Interface IMotor
...
End Interface
<ClassInterface(ClassInter
Public Class Motor
Implements iMotor
...
Public Sub New()
End Sub
...
End Class
Business Accounts
Answer for Membership
by: ToddBeaulieuPosted on 2009-10-01 at 11:39:21ID: 25471814
Oh boy. This stuff can be messy and frustrating, indeed. I went through similar struggles a few years back and don't envy you.
I wouldn't use AutoDual, for one thing.
I just dug out an old document that I had created on this topic and posted it to my blog. Please read through it carefully, as a single missed point can be a major road block.
http://toddbeaulieu.spaces