Software Deployment

If you need additional support files, you'll need to add them to the Binary table in the same way but you'll need a Custom Action to extract them from there. Try this, a heavily cut-down version of a routine I use:Function ExtractBinary(ByVal strBinaryName, ByVal strOutputFile)
Dim objDatabase
Dim objView
Dim objRecord
Dim objBinaryData
Dim objStream

Const msiReadStreamAnsi = 2

ExtractBinary = False

Set objDatabase = Session.Database

Set objView = objDatabase.OpenView("SELECT * FROM Binary WHERE Name = '" & strBinaryName & "'")
objView.Execute

Set objRecord = objView.Fetch

objBinaryData = objRecord.ReadStream(2, objRecord.DataSize(2), msiReadStreamAnsi)

Set objStream = objFSO.CreateTextFile(strOutputFile, True)
objStream.Write objBinaryData
objStream.Close

If objFSO.FileExists(strOutputFile) Then
ExtractBinary = True
End If

Set objStream = Nothing
Set objRecord = Nothing
Set objView = Nothing
Set objDatabase = Nothing

End FunctionAs you can see, you'll need to add error-trapping to it but the bones are there.

Another option you may wish to explore if you happen to use InstallShield as your toolset is to add the executable plus any DLL files as 'Support Files' to your project.

These files will then be available during installation but automatically removed once the installation has completed. The files will be extracted to a folder with the property SUPPORTDIR

So typically a VBScript custom action could contain the following code to determine where the executable is and then run it. (Note I haven't included any error handling in this fragment)

[font="courier new"]Set oWsh = WScript.CreateObject("WScript.Shell")
[font="courier new"]strMyExe = "myprog.exe"
[font="courier new"]strPathToExe = Session.Property("SUPPORTDIR") & "\" & strMyExe
[font="courier new"]oWsh.Run strPathToExe

By having the DLL files co-located with the executable, this should be sufficient for the executable to run assuming usual DLL search order rules apply.

The one area where you need to be careful is if you schedule the above custom action as a deferred action, in which case you won't be able to find the value of the SUPPORTDIR property unless you go down the CustomActionData route, for which there are many articles in this forum.

I suppose that, instead of adding the files concerned to the 'File' table, you could add them to the 'Binary' table and then create a Custom Action to execute them. You would need to add the same files to the 'RemoveFile' table so that you can be sure they get deleted during an uninstall.

I'm wondering why you've posted this in the 'Windows Installer Errors' forum, which is designed for posts concerning errors returned by the Windows Installer engine. I think you probably wanted the 'Package Development' forum. A moderator may well move the thread.

Ok I did that!! I added a new row to binary table. I specified a path of an executable (.exe - for testing purpose; I added a path of Notepad). I got this error,

'There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor.'

Why it is saying DLL if I have given a path of .EXE??
What if Notepad.exe had been a part of my package???

Just adding a row to the table is pointless. Did you import the executable, too? What tool are you using to edit the package?

Hey I got it worked. I was specifying incorrect 'Type. Now my question is, I specified a complete path in 'Binary' table. What if I want to execute such a file which exists in my package and not on the target machine? I want to execute such an executable which is not there on the target machine where my product will get installed but its there in the package itself. And based on the result/return value of the executable, installer should decide whether to proceed with the installation or not.

I hope I am not making your life miserable by making this questions complicated unnecessarily.

As I say, you'll need to execute it/them from the Binary table. You'll also need to author a Custom Action to remove it/them from the target if the install is aborted.

A simpler solution might be to build a separate package containing just the files you want to execute. Depending on the installed status of that package, you could install or abort the "main" package. You could wrap the two MSIs in a self-extracting EXE.

Hello,

I added the executable to the Binary table, added custom action as well as added row to InstallUISequence. Everything is working really fine now. My binary is executed at the beginning as expected. Well, the binary that I was using was just a test app that doesn't really need any DLLs.

Now my problem is, how do I play with my MSI if the binary that I want to run at the beginning of installation is using some DLLs??? I tried adding these DLLs to binary table and loaded them in CustomAction table without luck.

F1! F1!! F1!!!

Of course, you meant Set oWsh = CreateObject("WScript.Shell") <etc.>with no 'WScript' directive.

Good catch, Ian [:)]

Spartacus

I'm surprisingly awake this morning.

VBScab and Spartacus...You both are SUPER...!!!
Thanks...!! :)

You could always rate the posts you think deserve a rating...

Done!!! :)