Just started using windows installer. Is there a reason to create an exe to run an .msi file? Lets say I go through the process of creating an .msi file using orca (for example), should I create an exe to run that .msi or is it enough to just have the user double click my .msi file to run the installation. I find it a bit confusing that I can click my .msi file and run the installation, yet I see some installation distributions have an exe and an .msi file. The windows installer documentation does not seem to directly address this with any bit of normalcy.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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..
Answered 07/06/2005 by: rikx2
Purple Belt

Please log in to comment
0
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
Answered 07/06/2005 by: jayvatar
Yellow Belt

Please log in to comment
0
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.
Answered 07/07/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
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
Answered 07/07/2005 by: rikx2
Purple Belt

Please log in to comment
0
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.
Answered 07/08/2005 by: MSIMaker
Second Degree Black Belt

Please log in to comment
0
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.
Answered 07/11/2005 by: jayvatar
Yellow Belt

Please log in to comment
0
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.
Answered 07/12/2005 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
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 ......
Answered 07/14/2005 by: Lillude
Senior Purple Belt

Please log in to comment
0
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
Answered 07/17/2005 by: plangton
Second Degree Blue Belt

Please log in to comment
0
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
Answered 07/27/2005 by: rianf
Yellow Belt

Please log in to comment
0
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.
Answered 07/27/2005 by: glwday
Orange Belt

Please log in to comment
0
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
Answered 07/28/2005 by: rianf
Yellow Belt

Please log in to comment
0
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
Answered 07/29/2005 by: MSIMaker
Second Degree Black Belt

Please log in to comment
0
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
Answered 08/02/2005 by: rianf
Yellow Belt

Please log in to comment
0
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?
Answered 08/11/2005 by: h_alaie@hotmail.com
Yellow Belt

Please log in to comment
0
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]
Answered 08/11/2005 by: babric
Senior Purple Belt

Please log in to comment
0
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).
Answered 08/11/2005 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
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
Answered 08/11/2005 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
Answer this question or Comment on this question for clarity