Software Deployment

ORIGINAL: tron2ole
I remember looking at an article on the Altiris website and mentioned how to use the wisecomcapture tool.
But also mentioned to cleanout classIDs etc from the output registry file from the wisecomcapture.
What are the rules and how do you know which entries to remove from the output registry COM information? I can't imagine why you'd want to clean out the class ID stuff, since that is the entire point of importing the .REG! :) I think, perhaps, it might be to do with whether or not you have Wise set to use self-registration (not recommended) or to populate the advertising tables (recommended). You can find an article (is it on Juice, John?) which tells you in great deal why the latter is NOT a good idea but I think it's fair to say that the overwhelming majority of packagers will tell you that it is.

In summary:
- set Wise to use the advertising tables
- use WiseComCapture to create .REGs for your registerable DLLs (remembering that some DLLs have the DLLRegisterServer entry-point but no COM information)
- reply 'Yes' when WPS asks if you want to use advertising tables when you import the .REG.

In a word, don't. Using RegSvr32 is the work of Satan, as is using the SelfReg table (effectively the same thing).

Do the job properly. Use your MSI authoring tool's utilities to extract the DLL's COM information into a .REG file, import that into your project and, if prompted, elect to use the advertising tables.

The reason behind this is straightforward. RegSvr32 and the SelfReg tables rely on ALL of a DLL's dependencies being present at registration-time, something you probably cannot guarantee. If they're not present, the DLL in question won't register and the installation will fail, unless you set it to ignore errors returned from the registration Custom Action, in which case, why bother registering the DLL at all?

ORIGINAL: VBScab
In a word, don't. Using RegSvr32 is the work of Satan, as is using the SelfReg table (effectively the same thing).
Do the job properly. Use your MSI authoring tool's utilities to extract the DLL's COM information into a .REG file, import that into your project and, if prompted, elect to use the advertising tables.
The reason behind this is straightforward. RegSvr32 and the SelfReg tables rely on ALL of a DLL's dependencies being present at registration-time, something you probably cannot guarantee. If they're not present, the DLL in question won't register and the installation will fail, unless you set it to ignore errors returned from the registration Custom Action, in which case, why bother registering the DLL at all?


That's in interesting approach. I know that Wise sometimes puts DLLs into the SelfReg table that get errors. Is that only because of the dependency problem, or is it a wise bug? I thought Wise was supposed to put all the COM entries in the registry automatically when you add the DLL.

How do you extract a DLL's com information into a reg file? Maybe i know how to do this by different term names

ORIGINAL: duplexrj

How do you extract a DLL's com information into a reg file? Maybe i know how to do this by different term names


Use WiseComCapture.exe - it's a command line tool that comes with WPS.

I remember looking at an article on the Altiris website and mentioned how to use the wisecomcapture tool.
But also mentioned to cleanout classIDs etc from the output registry file from the wisecomcapture.
What are the rules and how do you know which entries to remove from the output registry COM information?

Ian is very correct.

If you do however want to register a dll manually you can also use msiexec /y or /z as CA's. Again I don't recommend it but the functionality is there.

here is a blurb about COM inclusive of how to use WiseComCapture and other related tools http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!151.entry

I am not sure if I know of which document you are referring to.

there is a good document on Realtimepublishers to do with windows 2000 deployment which goes into heavy detail about COM and dll hell.

I have a question about this topic. I am registering DLL/OCX files using wisecomcapture with the DLL's in the InstallFolder. Should I do the same with the DLL's that are in System32 that aren't part of Merge Modules? How should I handle them?

My current Process:
-Capture Package 'Convert Registration into Advertising Info' (No SelfReg Table created)
-Identify COM DLL/OCX's
-Use WiseComCapture to gather Reg info
-Delete (Relevent to COM DLL/OCX's) info from Class and ProgID table.
-Import Reg files created using WiseComCapture to their appropriate components, and Advertising them.

ORIGINAL: Digitalweezil
Should I do the same with the DLL's that are in System32 that aren't part of Merge Modules? Yes.

If you have a 'Projects' folder in your Wise share point, I presume you're also using discrete folders for each app. I generally have SetupCapture copy the app's files to the project folder and run my WiseComCapture script against THAT folder. Then, I use TextPad to bulk-edit the UNC path in the .REGs produced by the script so that they point correctly to %SystemRoot%\System32. *THEN* I import them into the project. You'll find doing it that way is W A Y easier than trying to run the script against files actually IN %SystemRoot%\System32!

BTW, step 4 in your process isn't really required. Leave the Class, ProgID and other COM tables as they are.

Thanks for the System32 info

About Step 4 - I guess what I was doing that is pretty pointless. Even if some of the entries in ProgID table are missing, then importing the .Reg file will automagically correct it when I tell the files to Adveritize. Thanks for making my life easier yet again VB :)

All-
here is the code to make a VBS. just drag the file onto the VBS and it will extract the info into a reg file. [:D]

Dim oShell
Set oShell = WScript.CreateObject ("WSCript.shell")
StrExepath="""C:\Program Files\Altiris\Wise Package Studio\Windows Installer Editor\WiseComCapture.exe"""
Set objArgs = WScript.Arguments
strComPath=objArgs(0)
strregpath=Left( strComPath,InStrRev(strComPath,".")) & "reg"
strCommandline=StrExepath & " """ & strComPath & """ """ & strregpath & """"
msgbox strcommandline
oShell.run strCommandline
Set oShell = Nothing

Many thanks for your contribution, Mike. However, Patrick has a copy of my script http://www.planet-source-code.com/URLSEO/vb/scripts/ShowCode!asp/txtCodeId!9560/lngWid!4/anyname.htm which walks a folder tree, checks for DLLs and OCXs with the DLLRegisterServer entry point and runs WiseComCapture against such files.