RegClean
in [Visual Basic]
|
From: BeeJ on 30 Jul 2010 19:45 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 31 Jul 2010 12:20 | 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 31 Jul 2010 12:28 See also: http://groups.google.com/group/microsoft.public.vb.general.discussion/msg/7fd4405ff69570a3
From: MikeD on 31 Jul 2010 12:38 "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 31 Jul 2010 14:31
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 |