Re: HowTo: Unregister a DLL/Control when the File no longer Exists
- From: "Peter Young" <youngpa@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 15 Jun 2006 14:12:32 -0500
Hello all,
Just wanted to provide a bit of an overview of what's going on here...
DllRegisterServer and DllUnregisterServer are exports in every VB DLL/OCX
(an OCX is actually a DLL, so I'll just say DLL from now on) and their sole
purpose is to write COM registration information into the Registry and
remove it when the component is no longer needed.
When you run RegSvr32, all that is happening is that RegSvr32.exe is calling
either the DllRegisterServer or DllUnregisterServer function in your VB DLL.
Your VB DLL is what is actually doing the work of writing to the Registry.
Even though you never see this code and even though you don't explicitly
create those two functions, they do exist - VB does this work for you. Also,
these are not COM methods, these are "standard" function exports. ActiveX
EXEs are a different beast and this doesn't really apply for those.
So once you delete your DLL, all the code that is needed to remove those
Registry entries is gone with it. The ideal way to get rid of those entries
is by running the DllUnregisterServer function in your VB DLL (by using
RegSvr32 /u or some equivalent method). If you've deleted it then you've
lost that code and you then have to either manually sift through the
registry and delete them or run a registry cleaner utility and try to get
them all. Not fun. MUCH easier to just let your DLL do what it was built to
do in the first place. Also, there is no "API" for doing this - you simply
call the method as you would any API method. e.g. Declare Function
DllRegisterServer Lib "MyDll.Dll" () As Long
When you compile your DLL, VB actually calls DllUnregisterServer on your DLL
before it overwrites the DLL. It does NOT call DllRegisterServer on the DLL
though - instead it appears to run the equivalent code internally. Strange
that MS decided to do it that way, but that's what it does.
Now as far as project incompatabilities go, this stems from how VB does COM.
IMO, MS really screwed up VB here. The 3 compatability modes and how the IDE
behaves does not help us as much as it hurts us. This topic is far too
involved to really cover well here, but I'll just offer some hard-earned
advice. I NEVER use Project Compatability. This only leads to frustration.
VB is munging together a twisted COM typelibrary in the hopes that all of
your changes will remain compatible. It's not worth it. Instead, I use the
other 2 modes selectively. The nice thing about No Compatability is that it
creates a shiny new typelibrary on every compile. It's compatible with
nothing so you need to then immediately set Binary Compatability. Make a
copy of your shiny new DLL and rename it to have a CMP extension. Use this
CMP file as your Binary Compatability file. (A nice little feature of
vbAdvance is that it shows CMP files in the Binary file selection dialog.)
Now any time you change the COM interface (add a method, rename a method,
change an Enum, etc.) you must update that CMP file with your latest binary.
If you are breaking compatability, compile once with No Compatability to
create a clean new typelibrary, then reset Binary Compatability. Sounds like
a pain I know, but it isn't and it will save you a lot of headaches. The
problem is that VB is hiding the typelibrary generation from us. We can't
control it and therefore this process is a bit of a PITA. Matt Curland has
created some extremely useful tools to help with this. If you have his book
you have the tools. Highly recommended. Also, the rules of COM are clear -
once you publish an interface, that interface is immutable. IOW, no changing
method names, or parameter counts, etc. If you do, you have a new component.
This is where No Compat comes in - you are creating a new component, just as
you're supposed to do.
Hope that didn't confuse more than clarify,
Pete
Charles Law wrote:
I have a project group, in a specific location on disk, that contains
several projects. There is the main EXE and a few ActiveX DLLs.
The main project references one of the DLLs, which in turn references
another DLL. So far so good.
Periodically, I copy the entire directory hierarchy to another,
similar, location, and call it version 2; so the parent directory
MyProject still exists, but now there is one alongside it called
MyProject #2. I begin working on #2.
When I am happy with the changes in #2, I delete the original
directory structure altogether.
When I look in the references, I can still see the original controls.
How can I remove them without wading through the registry in the vain
hope that I know what I am doing? I realise that I can never include
one of these as a reference because I get an "Error loading DLL"
message, but in time I get a proliferation of entries in the
references section to files that do not exist, and at best this
creates clutter but at worst it means that I have to work through
them until I find the right one to include. [Of course, until I
delete the earlier version, it is still possible to include the wrong
file, which is more serious]
TIA
Charles
.
- References:
- HowTo: Unregister a DLL/Control when the File no longer Exists
- From: Charles Law
- HowTo: Unregister a DLL/Control when the File no longer Exists
- Prev by Date: Re: Sorting control array indexes in order
- Next by Date: Re: HowTo: Unregister a DLL/Control when the File no longer Exists
- Previous by thread: Re: HowTo: Unregister a DLL/Control when the File no longer Exists
- Next by thread: Problem with SHFileOperation function
- Index(es):
Relevant Pages
|
Loading
