What establishes the reference name in a type library

[menchar]

I've created a DLL in CVI 9.1 for use with VB6.  I've used a function panel file (.fp) to define the exported functions in the DLL.

We add the DLL as a reference to the VB6 project, allowing the functions defined in the .fp to be use directly from VB6 without using prototype info of any kind.

One problem with this scheme is removing a reference from the VB6 development environment - there's no obvious way to do this - there's no "remove reference" capability.  We invariably wind up brute force ripping anything referent to the DLL out of the registry, and removing the DLL itself from the system so that VB6 won't keep finding it and insisting on using it.

An aspect of this is the reference name.  What estblishes the name of the reference to the VB6 development environment?  Is it the name of the DLL?  Is it the name of the .fp file? 

I could run an experiment I suppose but maybe somebody knows this and can tell me.

Thanks.

Menchar

[menchar · Accepted solution]

Menchar -

It turns out that the function panel filename (.fp file) establishes the name of the reference when the DLL is added to the VB6 development environment.

The developer can see the name of the associated DLL, but the reference itself is the function panel filename which may or may not be the same name as the DLL, the project, workspace, or anything else.

Thanks for the help, Menchar, you're always on the ball.

Menchar

[menchar]

Menchar -

Here's another question related to this same topic.

I have a DLL created in VCPP and yet another DLL created using VB6.  I've modified these to be new and unique, by changing the names of the DLL's as well as altering (directly or indirectly) the GUIDs used to identiofy the COM interfaces in each.

However, when I add the new DLL's to the Visual Studio evironment, it uses the same names as before for the references ... so while I've figured out how to alter the reference name from CVI (by changing the .fp file name) I still don't know how to do this for DLL's created in VB6 and VCPP.  I've changed the names of the DLL's, but as we know from our CVI DLL experience, this doesn't change the name of the reference.

Does anyone know how to do this in VB6 or VCPP?

Thanks for the help,

Menchar

[Mohan]

I would guess the reference name would be the name of the 'library' element in the type-library for the DLL. In CVI, the library name is the same as the FP name, and hence the behavior. In VC++ and VB, I am not sure what the library name would be - may be the project name? You could look for the library name in the IDL or ODL file - this is the source for the typelibrary and you may be able to change the name here. You could also look inside the typelibrary using oleview to see what the library name is, but you cannot change the name here.

[menchar]

Mohan -

Thanks for the thoughts.

Oddly enough, it appears to me that the VCPP DLL type library reference name is established by the IDL "helpstring" command contained in the attibutes for the library, rather than the library name itself.

Here's the IDL code:

[
    uuid(58777a42-4808-47c2-8d3a-6975a668054c),
    version(1.0),
    helpstring("Coreco x64 Framegrabber 3GFE")                     <===   this becomes the type library reference name for Visual Studio
]

library CorecoFramegrabber        <=== this isn't the type library reference name
{
    importlib("stdole32.tlb");

...

}

And in VB6, you indirectly can change the reference name by using the properties popup for the DLL project in project explorer.  The "make" tab has a text control titled "Application title"  and we think this becomes the type library reference name.

Weird, huh.  I looked and looked for info on this, but never found anything that said that the library name came from the IDL helpstring for the library module.  But from experimentation, that's how it works.  It appears to be a flaky aspect of the type library concept - NI decided to use the fp filename when creating the type library, MS is using the helpstring.  The helpstring is optional, I haven't determined what happens if it's not there.

We're trying to avoid DLL hell on some VB6 stuff, it's confusing as heck because you can create a unique DLL but if the reference name doesn't change, you're hard put to know exactly which one you have used in your project.  In fact, you wind up with multiple references (that are in fact unique due to GUIDs being different) but they have the exact same reference name when you look in the reference list.

[menchar]

The nightmare continues ...

I changed the name of both the function panel file used to create a type library for a DLL I've written and the name of the DLL itself, and that changed the reference name in the VB6 project I'm using BUT it's still referent to the old DLL!!!

If I add the new DLL, with the renamed function panel file as a reference in the VB6 project, it shows a new reference name, but it still seems to be referring to the old dll name.

What is going on here?

What is going into the type library?  Is something set at the time of original creation that can't be changed / edited?  Does the type library have a GUID that you can't change except by creating an entirely new fp file?

Menchar

[menchar]

Menchar -

VB6 uses the standard LoadLibrary search path at run time to find a DLL that's been used as a reference, even though VB6 "knows" perfectly well where the DLL is when you add it as a reference.

The way to understand this is that what you're adding to the VB6 IDE as a reference is the type library that happens to be in a DLL, not the DLL executable itself.  So VB6 is willing to load a type library from anywhere you tell it to find one, packaged up in a DLL.

At run time, it's a different issue - regardless of where the IDE found the type library, at run time the DLL needs to be found and loaded (assuming the so-called "static" DLL load model) at process start, and the location of the type library matters not a whit.  And, if all you did was put a new DLL in an off-load path location, then if there was, say, an old version in system32 folder, the old DLL will be found and used.

If you use "remove programs " from the Windows control panel to remove a DLL that was in the system32 folder, it's not removed!  I've noticed several NI DLL's act this way, from what I see it's true for a DLL I've created in CVI as well.

Just more DLL weirdness, it never seems to end.

Menchar

[LuisG]

>If you use "remove programs " from the Windows control panel to remove a DLL

>that was in the system32 folder, it's not removed!  I've noticed several NI DLL's act

>this way, from what I see it's true for a DLL I've created in CVI as well.

Menchar,

This can't be a general rule. There are plenty of installers that install DLLs to the system folder and those DLLs are routinely removed when the installer uninstalls the program. Unless the installer deliberately leaks some DLLs (the CVI RTE, for example, did this for a few versions, between 6.0 and 8.x, I think, for backwards compatibility reason), and of course a given DLL might be locked at the time the uninstaller runs, but other than that, I'm not aware of any reason why DLLs in the system folder wouldn't be uninstalled.

Luis

[menchar]

Luis -

It may be that I've fooled myself - I see that I copy the release version of my DLL into the system folder as part of the build, as well as a distribution kit destination.  The current copy of the DLL may be there as a result of a build, and even though the distribution kit puts it there too, it might be that if the build replaced the distribution version the remove programs tool knows it's not the version from the distribution and leaves the more recent, "build" version of the same DLL in place.

So it could be there's no way to truly "leak" a CVI-built DLL into the system folder when creating a distribution with the CVI distribution editor.

Menchar