self-registering a dll

[menchar]

Has anyone successfully implemented a "self-registering" dll using CVI?

I am creating a dll in CVI 8.0 for use from a VB 6.0 application on WinXP Pro SP2.    While I can add the self-registration functions to the dll, it's not clear to me that if I have a non-ActiveX DLL that I gain anything by making it "self registering" or indeed does that even makes any sense at all.

I've searched MSDN and nothing leaps out as being an overview of this topic.

Thanks for any insight into this.

Menchar

[Makoto]

If your DLL is a COM DLL (including ActiveX Control, IVI-COM instrument driver, etc), it makes sense to "register" the DLL into the system registry under the HKEY_CLASSES_ROOT.  Then the DLL should have DllRegisterServer() and DllUnregisterServer() being exported.  The client app (such as VB), when at runtime, loads the DLL through the Microsoft COM runtime engine.  The actual DLL path is decided based on the registry content.

If the DLL is legacy non-COM type, such as simply exporting C-language-style functions, it makes *** no sense *** to self-register it.  The client app will load the DLL based on the PATH environment variable.  Actually, the app will search for the DLL in app's directory, System32, Windows, or any other PATH-enabled directories.

[menchar]

Makato -

Thanks.  VB users will just have to add the dll as a reference before they can see its type library to help them write code (VB's syntax directed editor prompts for function parameters).

They were used to using COM dll's and tried to register the CVI-authored non-COM dll I had given them and it caused all sorts of problems with registry entries and tangled up the VB IDE's reference to the dll.  We cleaned up the registry, added the dll as a reference, and now everything's OK.

Thanks again.

Menchar