Software Deployment

you can use wisecomcapture to extract the dll/ocx reg entries

install your msi
copy vbs file to your desktop
copy wisecomcapture to the root of c:\
do a search for the dll/ocx's on your workstation
drag and drop dll/ocx into this vbs
reg entires are created in my documents
create a component and add reg entries and delete entries from self reg table
recompile
job done



'*******************************************************************
'* *
'* *
'* *
'* *
'* *
'* *
'* *
'* *
'*******************************************************************
Const MAXIMIZE_WINDOW = 3
Const MY_DOCUMENTS = &H5&
Const WISE_cOM_cAPTURE_PATH = """c:\WiseComCapture.exe"" "

Set objShell = CreateObject("Shell.Application")
Set objFolder = objShell.Namespace(MY_DOCUMENTS)
Set objFolderItem = objFolder.Self
strDestination = objFolderItem.Path

Set args = WScript.Arguments
strFile = args.Item(0)
strFilename = StripPath(strFile)

strCmd = WISE_cOM_cAPTURE_PATH & " " _
& """" & strFile & """" & " " & """" & strDestination & "\" & strFilename & ".reg" & """"
Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run strCmd, MAXIMIZE_WINDOW


'************************************************
'* Returns just the filename from the full path *
'************************************************
Function StripPath(strFile)
Count = len(strFile)
do until LastSlash = "\"
LastSlash = mid(strFile, Count,1)
Count = Count -1
Loop
StripPath = right(strFile,(len(strFile)-Count-1))
End Function

My understanding of this is that when selecting yes, it is overwriting any existing values in the advertising tables with the values in the .REG, when no is selected there is no change made to the package. Sound correct? No. When you select 'No', WPS uses the Registry table instead of the advertising tables. You should already have removed the rogue entries from the Registry table before the import. Otherwise, you end up with duplicates which is probably worse! In general, it's simpler to re-do the capture, having made sure you have WPS set up to not use self-registration (Tools/Options/Advertising, select 'Scan advertising info...', un-check 'Automatically add self-registration', check 'Default to rescan advertising...')

VBScab your answer not to make your code public makes me very sad. Many beginners here on this forum would be glad to use your code in order to get their MSI's fully and properly working.
I can comprehend your reasons but please think about the beginners who does't know much about VBS scripting...

Cheers

The script won't make any difference to any MSI. It's simply a time-saving device, to take the crashing boredom out of creating .REGs for a folder-full of DLLs/OCXs. There are a quadzillion sample scripts out there for recursing through a folder. It's easy enough to take one and adapt it to suit this job and, as I say, create a template that you can use for any recursive job. Here's one, for example: http://www.ericphelps.com/scripting/samples/FolderFileProperties/FolderFileProperties.txt

Yes, that is the risk of sharing your code that can potentially be modified by others but at least your name is still on it... [;)]

In my opinion, people doesn´t really mind who created the script and just go for the chance that it may work for them. You should have had encrypted it to vbe or exe if you put your name or share it without name. There are tons of scripts out there as and that is true but nothing is good to a reliable source.

When importing some of the .REG files with Wise Package Studio 7.0, I am receiving the following message. Let me confirm that I am understanding it right.

This registry file contains keys that are normally placed into the advertising tables (Class, ProgID, Extensions, etc.). Do you want the advertising keys removed and replaced with the proper advertising information?

Yes/No


My understanding of this is that when selecting yes, it is overwriting any existing values in the advertising tables with the values in the .REG, when no is selected there is no change made to the package. Sound correct?

ORIGINAL: VBScab

The script won't make any difference to any MSI. It's simply a time-saving device, to take the crashing boredom out of creating .REGs for a folder-full of DLLs/OCXs. There are a quadzillion sample scripts out there for recursing through a folder. It's easy enough to take one and adapt it to suit this job and, as I say, create a template that you can use for any recursive job. Here's one, for example: http://www.ericphelps.com/scripting/samples/FolderFileProperties/FolderFileProperties.txt


I have to say I agree with VBScab. I think primarily he is concerned for his name being in the scripts that people muck up, and secondly that you need to teach someone to fish, not just give them a fish. If we all had all our scripts handed to us, none of us would probably ever learn how to make and modify them.

No. When you select 'No', WPS uses the Registry table instead of the advertising tables. You should already have removed the rogue entries from the Registry table before the import. Otherwise, you end up with duplicates which is probably worse! In general, it's simpler to re-do the capture, having made sure you have WPS set up to not use self-registration (Tools/Options/Advertising, select 'Scan advertising info...', un-check 'Automatically add self-registration', check 'Default to rescan advertising...')

i agree

you need to teach someone to fish, not just give them a fish - Yeah, I partially agree. But on one specific occasion last year I was majorly strapped for time, and had deadlines looming like a heavy grey cloud. I was a good fisherman at the time, and caught many fish of moderate size, but I just didn't have the time to go fishing. So I asked a fellow fisherman called Google to go and fish for me, and he came back with a lovely fish. It was sparkling in the sunlight, and bred by one of the finest fish breeders in town (VBScab).

(OK....let's stop talking about fish for a second....)

The moral of my story is that a lot of 'experienced' scripters can also greatly benefit off scripts created by fellow scripters. I could have perhaps made a script like the one VBScab mentions, but because he'd already done it he saved me a day (minimum). Hence, I think VBScab should dig deep and post the link again......go onVBScab......you can do it.....[;)]

ORIGINAL: captain_planet


The moral of my story is that a lot of 'experienced' scripters can also greatly benefit off scripts created by fellow scripters. I could have perhaps made a script like the one VBScab mentions, but because he'd already done it he saved me a day (minimum). Hence, I think VBScab should dig deep and post the link again......go onVBScab......you can do it.....[;)]


Yeah come on VDScab. I wanna learn as much as possible concerning VBScript. And I wanna learn as quick as possible, ya know.
And if somebody would post his script like you, also 'experienced' scripters can really benefit from it.

Please do us all a favor and chew your arguments over.

Cheers

All I'm going to say is, look harder.

Worked like a charm on a repackage.

Points to Cygan for taking the time to share a valuable script, and to VBScab for explaining in detail the WPS error message. Thanks to all who contributed.

Hi, i am not anu Guru.....but the way which we follow is,
for e.g. we check self reg entry msvc71.dll, we go in it's component, we check any advertising registry is captured or not? if it is not captured, we manually try to extract dll com data in to reg file with the help of wise com capture. if we find registry keys then we import those in respective component, and delete self reg entry and if we do not find anything we directly deletes self reg entry.

You must be paid by the hour, right? I can't think of any other reason why you would make work for yourself :)

It would be simpler to turn off WPS's option that tells it to use the SelfReg table, wouldn't it?!?

hey dude! you do not worrie about my payments. when we get selfreg entry, once again we confirm, by registering it manually....and i do not think it is a bad thing. After all we should not be 100% dependent on tool.

i do not think it is a bad thingBut self-registration IS very much A Bad Thing!

The single-most important reason for not allowing it is that the DLL being registered may have a dependency. If that dependency isn't present on the target, the self-reg will fail, producing errors in the eventual deployment. If you turn off the option in WPS which tells it to use self-reg and instead tell it to use the advertising tables, the problem disappears.

If u register any dll or ocx file, through Wise com capture...then u will get regfile, and you will have to import this regfile, in the respective component. Which includes com registry data. If wise package studio, does not capture com data, for any of the dll, and if we have to do this process, then will it be a self registration?

Maybe, maybe not. Self-registration is where the SelfReg table is populated with the names of DLLs or OCXs which the Wi engine will attempt to register. Whether or not WPS populates that table depends on how you have it set up. To NOT use self-registration, choose 'Tools/Options' then click the 'Advertising' tab. The 'Advertising Setting' should be set to 'Scan advertising information...'. Un-check 'Automatically add self-registration'. It's up to you if you select 'Default to rescan advertising...' but I'd recommend it.

when we get selfreg entry, once again we confirm, by registering it manually
by all means feel free if that is what you are comfortable with

Thanks a lot. This code is very helpful. I'll give it a try.
I was looking for something like this for weeks.

Cheers

don't forget to give a score if it works for you
cheers

I gave the post a score. Because your script works fantastic. Thanks very much...

Cheers

Wow, this is exactly what I was looking for. I'll give it a shot and make sure to vote up for you if it works out. Thanks much.

Many moons ago, when I started doing this packaging nonsense, it became clear that I needed a script onto which a folder could be dropped and which would then process the contents of that folder, be that files or other folders. I have used the shell of that script over and over again.

One of those uses was to build a script which would take a folder (and obviously sub-folders), test any DLL or OCX it found for the DLLRegisterServer entry-point (by a means no more sophisticated than looking for that text in the file!) and, if present, populate a dictionary (or an array, if you prefer) Then, the dictionary is read and WiseComCapture run against the file, producing a .REG for each.

Notes:
- If you get an empty .REG, it's likely that the file contains the entry-point but no COM information. The most common ones are for apps which use a JRE and thus include NPJAVAxy.DLL. These files contain the EP but no COM information. Test such files by running RegSvr32 against them. They'll fail.

- In testing early versions of my script, I found that WCC would occasionally produce an empty .REG for files which definitely contained COM information. In these cases, calling WCC from the folder containing the DLL normally fixes the problem. Later versions test the size of the .REG and, if less than 100 bytes, switch the paths and re-run WCC.

Lastly, before anyone asks, no, I won't send my script to you. I made that mistake once and in short order found hideously-edited, mostly non-functioning versions springing up everywhere, with my name on!

BTW, cygan, there's no need to keep WCC in the root of C:. Just add a registry read to get the installed path of WPS and use that to prefix the EXE name.