From: BeeJ on
So all this VB6 development has left junk all through my registry.
OK so I don't know what I am doing.
I like to create ActiveX EXEs etc and find the clutter of non-existent
references in Project\References.
And I cannot unRegester 'cause I screwed up and deleted a project that
contained that registered reference.

1) how can I minimize it as I do development?

2) how can I clean out the registry safely? Me no want to edit.
Reg Clean Apps?
a) for free? links please.
b) best Reg Cleaner at lowest price. links please.

Running WinXP(latest) and Vista(latest).

I am a retired individual who really enjoys the programming challenge
but needs lots of input.

MesNews rocks! In through news.aioe.org


From: Mayayana on
| The bottom line is to reduce the possibility of conflicts. i.e. a
| different ActiveX EXE or .DLL running from the IDE vs running from the
| Main App EXE and reducing the clutter in Project\References.
|

It's unfortunate that there's no option to wait
on registration in the IDE. It's very difficult to
avoid at least a few false listings, and they're
tedious to clean out by hand.

I just tried the TweakNow that Ralph linked.
It seems to work OK, providing a list of what
it finds before deleting anything. But the program
is ridiculously bloated. 17MB on disk! For a program
that should probably be less than 100 KB. I can't
imagine what's in that EXE.


From: Nobody on
See also:

http://groups.google.com/group/microsoft.public.vb.general.discussion/msg/7fd4405ff69570a3


From: MikeD on


"BeeJ" <nospam(a)live.com> wrote in message
news:i31ecd$g76$1(a)speranza.aioe.org...

Please try to remember to trim your quotes to just what's relevant to what
you're writing. Makes life much easier on everybody.


> I never knew that moving with W E would register. That has probably got
> me in trouble before.

It DOESN'T register them. And if you recompile before setting binary
compatibility (or have to break binary compatibility because you've changed
the public interface), that's what causes all the orphaned entries in the
Registry. Same thing can happen if you simply delete files. Easiest rule,
IMO, to remember is to just always unregister before moving or deleting. If
you're careful about always doing that, you won't end up with junk in the
Registry. I always merge the following into the Registry to make this
easier:

**dllfile.reg**
--
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\dllfile\shell]

[HKEY_CLASSES_ROOT\dllfile\shell\Register]

[HKEY_CLASSES_ROOT\dllfile\shell\Register\command]
@="\"c:\\windows\\system32\\regsvr32.exe\" \"%1\""

[HKEY_CLASSES_ROOT\dllfile\shell\Unregister]

[HKEY_CLASSES_ROOT\dllfile\shell\Unregister\command]
@="\"c:\\windows\\system32\\regsvr32.exe\" /u \"%1\""
--


**ocxfile.reg**
--
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\ocxfile\shell]

[HKEY_CLASSES_ROOT\ocxfile\shell\Register]

[HKEY_CLASSES_ROOT\ocxfile\shell\Register\command]
@="\"c:\\windows\\system32\\regsvr32.exe\" \"%1\""

[HKEY_CLASSES_ROOT\ocxfile\shell\Unregister]

[HKEY_CLASSES_ROOT\ocxfile\shell\Unregister\command]
@="\"c:\\windows\\system32\\regsvr32.exe\" /u \"%1\""
--

Copy and paste into separate files the text between the pairs of "--"
characters. Make changes to the Windows path if necessary. You can use
Notepad for this. Save the files with whatever name you want, but give them
each a .reg extension. Double click each file to merge it into the Registry
(must be an Administrator; under Vista, I think you must run these from an
elevated command prompt window or have UAC off; under Win7, depends on how
high a level you've set UAC). Now, you can right-click any DLL or OCX file
and have Register and Unregister menu commands. One caveat of this is that
under Vista and Win7 and WinServer2008, it won't work if UAC is enabled. For
me that's not a problem because I turn UAC off. And of course you must be a
member of the Administrators group even under XP/2000.

> The bottom line is to reduce the possibility of conflicts. i.e. a
> different ActiveX EXE or .DLL running from the IDE vs running from the
> Main App EXE and reducing the clutter in Project\References.

It's actually very simple and is pretty much what Ralph outlined. One thing
he said that I don't really understand why is compiling into the project
folder. There's nothing wrong with doing that if that's what you want to do,
but personally, I compile all my production-ready ActiveX components into a
"common" folder named "Distribution". I also use a common Compatibility
folder too. For me, it's just more organized if they're all in these 2
common folders rather than scattered about in various folders. But there's
really no right or wrong here. It's just whatever works best for you. And
just to be clear, the files in your Compatibility folder should NEVER be
registered. And unless there's a specific reason not to (for example, you
always want to retain compatibility against a specific version), you should
always copy (never move) your latest build to the Compatibility folder.

The key point to remember is to manually unregister ActiveX files before
moving or deleting them.

--
Mike


From: ralph on
On Sat, 31 Jul 2010 12:38:18 -0400, "MikeD" <nobody(a)nowhere.edu>
wrote:


>
>It's actually very simple and is pretty much what Ralph outlined. One thing
>he said that I don't really understand why is compiling into the project
>folder. There's nothing wrong with doing that if that's what you want to do,
>but personally, I compile all my production-ready ActiveX components into a
>"common" folder named "Distribution". ...

I suggested compiling to the project folder simply because the OP
reported having problems and the most common reason for having
problems is having multiple copies scattered all over, registered or
not. Having one *place* firmly in mind helps to avoid that. But that
place could be anywhere. So no disagreement on that.

[Also a bit of supersition - VB5 used to have real problems compiling
to 'removeable locations'. If the location disappeared compiles failed
with memory violations. Old news - but some habits die hard. <g>]

Second I tend to develop my install and build packages along side my
projects using a Sandbox approach. Thus during later development if I
need to test a product in a specific environment I install it and not
copy. Overkill for a few components, but a handy habit for a suite.
Fewer surprises come delivery time.

>
>The key point to remember is to manually unregister ActiveX files before
>moving or deleting them.

By controlling copies, I let the RegCleaner sort it out. But the
result is the same, and there is certainly no harm in manually
insuring the correct registration. Wearing suspenders with a belt has
saved many a potential embarrassment. <g>

-ralph