Re: HowTo: Unregister a DLL/Control when the File no longer Exists



Hi Tony --

Yep, I've had that situation happen, many times, myself. Probably almost as
often as simply overwriting with a non-compatible build. I've also built
compile scripts, in more formalized projects, but it's those Q&D ones where
you can't be bothered that cause the problem, eh?

Heh, that'd be a really cool addition to Windows! Any call to
SHFileOperation to move/delete files would unregister first? Wow... If
only, huh? :-)

Thanks... Karl


Tony Proctor wrote:
We also have another internal utility that builds a large suite of VB
projects, in the correct order, and deals with this exact situation
Karl (i.e. unregistering the previous binary before letting VB6.exe
generate the new one. It also does lots of other stuff too (e.g.
automatically building locale-dependent resources) but that's OT.
However, the RegClean type utility I mentioned before was for a
different case. It's oh so easy to go and build a temporary copy of
something, or install an older product version to test something, and
then get lazy and just delete the directory afterwards - I've even
done it myself. I guess you could put it down to a general COM
pitfall. The only solution I can think of would be if the Delete
operation first checked whether the file had self-registration code
(which is quite easy) and then confirm quickly whether it was still
recorded in the registry.

Tony Proctor

"Karl E. Peterson" <karl@xxxxxxxx> wrote in message
news:uWV1stxjGHA.3588@xxxxxxxxxxxxxxxxxxxxxxx
I wonder if an add-in could be written that automatically
unregistered a axComponent before compiling one destined to
overwrite it? That's my most-common scenario, when I'm in the very
early (ie, design-by-coding) phases of a project.
--
Working without a .NET?
http://classicvb.org/


Tony Proctor wrote:
We wrote an internal RegClean type utility to deal with this
situation since almost anyone can be guilty of deleting registered
files (e.g. QA/Installation teams as well as developers). We found
it was happening to a significant extent, plus Microsoft's RegClean
didn't always fix it, plus a third party tool had already caused
"registry bloat" by not cleaning the registry properly over a period
of time.

In principle, it's a matter of associating the Typelib records (may
be multiple versions) with their respective ClsID records, IID
records, and AppID records....and then deleting them all together.
However, matching them up without the original DLL (or EXE, or TLB)
is not foolproof. See



http://groups.google.ie/group/microsoft.public.vb.com/msg/6b5dd45f89c04a0b?hl=en&;
for instance

Tony Proctor

"Charles Law" <blank@xxxxxxxxxxx> wrote in message
news:#PHoB26iGHA.3408@xxxxxxxxxxxxxxxxxxxxxxx
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

--
Working without a .NET?
http://classicvb.org/


.



Relevant Pages

  • Re: HowTo: Unregister a DLL/Control when the File no longer Exists
    ... projects, in the correct order, and deals with this exact situation Karl ... "registry bloat" by not cleaning the registry properly over a period ... The main project references one of the DLLs, ... another DLL. ...
    (microsoft.public.vb.general.discussion)
  • Re: HowTo: Unregister a DLL/Control when the File no longer Exists
    ... "registry bloat" by not cleaning the registry properly over a period ... The main project references one of the DLLs, ... another DLL. ... MyProject still exists, but now there is one alongside it called ...
    (microsoft.public.vb.general.discussion)
  • Re: Getting at VBA
    ... I register the dll that I create. ... The only way to know for sure is to check your references in the VBA ... some of the DLL modules into your VBA project, ... The registry will point to the actual DLL file that's "registered." ...
    (microsoft.public.word.vba.general)
  • Re: Include existing ActiveX Dll without including it in the setup
    ... I'm unsure if the dll is registered. ... check it in VB6 References. ... Does this file not contain any parts of the DLL itself? ... The registry should know where it is so you don't need to ...
    (microsoft.public.dotnet.languages.vb)
  • Problem with performance of IDE devices
    ... index 0, dll tcpstk.dll, context 0x3f8a5c9 ... 0x801abbe8: FSREG: Mounted ROM portion of boot registry ... 0x8014abcc: FSREG: Invalid HKEY 0x00000000 ...
    (microsoft.public.windowsce.platbuilder)