Software Deployment

setup exe are bootstrappers.. they mostly collect information, checks the machine whether it has the installer runtime and if not checks the os and installs the necessary runtime version.. you can also pass parameters using these bootstappers..

k, see thats the kind of information that should probably be provided more forward in the windows installer documentation(I might of glazed over it somehow). Course I am dealing with mostly 2k and xp 32bit machines with a very small user base so that sort of testing should not be necessary, because of the default windows installer install with os install. What libraries and language combinations could I use if I were to build an exe to bootstrap my .msi installation process?

Thanks

Just say NO to bootstrapping!!

It was a concept invented by InstallShield in the Win 95/98 days when one could not be sure if Windows Installer existed on the machine. It also checks for the existance of and version level of an InstallShield Script driver, which is a proprietary Windows Installer add-on for extra bells & whistles used by InstallShield. This creates a major headache for repackagers attempting to conform applications to corporate level standards.

You're not using InstallShield Script and everyone had better have Windows Installer on their Windows machines by now. (Otherwise you are running 95/98/NT in desperate need of a current service pack) You can check base OS requirements in the MSI. There is absolutely no point in creating a bootstrap .exe for your MSI. It will do nothing but limit your deployment options.

There is no Windows Installer documentation on it because it is a violation of Windows Installer standards.

nice point there with vikingloki [8D].. since all machines using windows now have installer runtime i dont see the need for using bootstrappers.. most anything you could do with these bootstrappers you could just add to your msi project

Installshield bootstrap......"shudder"

One thing I have always said is that Wise creates zero footprint msi installations. Installshield creates msi installations that install a script engine that may not be needed but if it breaks then every msi is stuck on the machine until you rebuild it.

Ok, the reason I asked was that I felt ackward having only an msi file. It seems that many installations usually have a setup.exe or some other exe to perform the install. Rarely am I clicking on an msi file for an install. My guess is that those cases are usually for widely distributed files in which the developer does not have a controlled user base and needs to test OS vers.

Actually, you can check OS requirements within the MSI. You can check for product installations, versions, file existence/date/time, regkey existence/value... Heck, you can call DLLs, JScript, VBScript, external .exe's, there's a lot of room for customizing. It seems to me that the main reason why setup.exe still exists is out of sheer habit.

Creating an EXE may be usefull when you are trying to install more then one MSI's one after one or in the case where you need to apply some transform\patches to the MSI.
In that cases mentioned above simply clicking on the MSI wont be the best idea ......

Hi,

At the risk of sounding like an Installshield fanboy, I do like to correct a lot of the myths about Installshield for repackagers, and I see them all the time:

"Installshield creates msi installations that install a script engine that may not be needed but if it breaks then every msi is stuck on the machine until you rebuild it"

I hate ISSCRIPT as much as the next repackager, but the above sentence makes it sound like a default function of Installshield to install a script engine, as in any package created with Installshield will use it. This is simply not true. You can (and should) create MSI's with installshield that do not require ISSCRIPT, and in fact its default state (talking about Adminstudio 5 and up) is to not require ISSCRIPT. While developers keep on using it, Installshield will keep on selling it.

Also, if the isscript.msi breaks, it will not stop "every" msi, only ones that require ISSCRIPT (which is a lot of vendor provided MSI's I admit, again back to silly developers). You can still make fully functional MSI's with installshield and deploy them to a machine with a corrupt installation of isscript without any dramas. As long as it doesn't use isscript.

Rgds

Paul

Hey guys,

I’m creating a collection of installers and the requirement is for an msi (for network admins) & an exe (for end users) for deployment across corporate & "general" end users. I am doing it all through command line using WIX. Creating the msi is fine BUT building a bootstrapper is my problem. Does anyone have any ideas or know of any tools (pricing is important as there will be a need for 1000+ licenses) that builds setup exe from my generated WIX msi?

Sorry slightly off topic but I think you might be able to help me!

Thanks in advance,
Rian Fergusson

What about using kix to run the install of the msi? You can run kix from command line, batch file or convert the kix into an exe.

Thank you for the reply, very appriciated.

I am unfamilar with KIX, i have just downloaded KIXtart. Can i please have some pointers on how to create what you have described above?

Thanks

ORIGINAL: rianf

Hey guys,

I’m creating a collection of installers and the requirement is for an msi (for network admins) & an exe (for end users) for deployment across corporate & "general" end users. I am doing it all through command line using WIX. Creating the msi is fine BUT building a bootstrapper is my problem. Does anyone have any ideas or know of any tools (pricing is important as there will be a need for 1000+ licenses) that builds setup exe from my generated WIX msi?

Sorry slightly off topic but I think you might be able to help me!

Thanks in advance,
Rian Fergusson




I'm confused as to why you need 2 types of installs?

Using MSI's for both would be much cleaner and easier

Hi MSIMaker,

I need to create 2 installers for the following reasons:

1. MSI for network level deployment via such tools as Microsoft SMS, HP OpenView...
2. EXE for users to locally install.

I have been using Wise to create installation packages but we are moving to WIX. The problem is that WIX will only generate an MSI where Wise created an MSI + a bootstrap EXE. A bootstrap EXE is a requirement as it provides a user friendly GUI that can be branded, allows fluid version upgrades to name a few. Also, we do not want to provide users with an MSI, as this will give them extra control over the install (which will lead to greater amounts of support).

I have read that msiexec 3.0 supports an update switch but we are unable to use this as 2.0 is our minimum requirement. Version upgrading via MSI 2.0 is a major concern for us.

I agree with you, MSI is much nicer and cleaner from an installer perspective but the extra level of abstraction that a bootstrap exe provides does assist user, most users wouldn’t know what an MSI is.

Any thoughts? Thanks for you time!!

Rian

Hi;

I have repackaged an application (in MSI format) which creates/updates som registry values. When the application is uninstalled, the values are deleted. Is is possible to keep these entries when the package is uninstalled?

Maybe using some components conditions.

Component table > Condition > Not Installed.

Your components will install only if "Not installed" and (hope) uninstall only if "Not installed", which is, of course, false when you uninstall the product.
Care, I'm not sure about it, try it :-)

EDIT : better : use the permanent option :
Component Table > Attribute > Add "16" to the value written (or write 16 if no values)


EDIT 2 : Tsssss grilled [:D]

Put them in their own component and set the "msidbComponentAttributesPermanent" bit in the "Attributes" column of the "Component" table (for that component).

This will register the productcode "00000000-0000-0000-0000-000000000000" as a "client" of the component. Since this product doesn't exist, it will never be removed - therefore the component will always have at least one "client" (thus making it permanent).

Here's a VBScript that demonstrates what I said above. The component used below (part of Office) is "permanent" on my PC so it reports product "{00000000-0000-0000-0000-000000000000}" as one of it's clients.

Set oInst = CreateObject("WindowsInstaller.Installer")

Set oProds = oInst.ComponentClients("{C5B60850-9281-44C1-ACA6-034A37641418}")

For i = 0 To oProds.Count - 1

Msgbox oProds.Item(i)

Next

Set oProds = Nothing

set oInst = Nothing