We use InstallShield InstallScript projects to create our installers and are looking for a good way to migrate to the WiX Toolset. As far as I know there is no UpgradeCode (as for MSI) to update from an Installshield InstallScript project to a WiX project.
The only solution I found so far is:
manually save configurations
uninstall the InstallScript installation completely
install the WiX installation
apply the saved configurations
Is there a better way?
Ok after all those comments I think I understand why this is such an issue. Unfortunately I don't think there is a very simple way to do waht you want to do.
I think your method will be the only real way to migrate from this isntallscript setup based installation. There should be some registry entry in HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall that relates to your product. In here there may be a uninstall command which you could read into a Variable from your burn package and pass that value as a property to your msi.
In you MSI you can have 3 custom actions specifically related to upgrading from the installshield product installation. All these tasks should be deferred custom actions so that they can run with administrator elevation. The first task should copy all the configuration settings to a safe place (generally %temp%\ProductConfig\ would be fine). The second part after saving the configuration would run that uninstall command to remove the product, you may need to append /q or something to make it run passively/quietly. Then at the end of the installation you can copy back the configuration files from temp.
Each of the custom actions should run conditionally on whether or not the property you passed in is set to something. I would schedule the copy cofig after InstallInitialize, the uninstall after the copy and the restore before InstallFinalize just to ensure that everything is copied over after the installer puts all the files on the system.
Ideally you would like to get everything to upgrade without the user needing to interact except in a minimal way by clicking next and Install.
I've only dealt with InstallShield enough to know I really don't like it so if someone else knows more and knows of a better way to do it they'll hopefully chime in.
Related
I am trying to make my Wix Burn installer install two applications that use NSIS for their installer. Install works great. However, I want them to be removed when I uninstall my app (Permanent="no"). This is not so straightforward as I cannot call a different exe (the uninstall.exe that is created) from the UninstallCommand property on he ExePackage. Is there another way? Is there a simple command line argument that an NSIS installer can take to uninstall?
You would have to request the author of those installers to add support for that, NSIS does not support it by default.
I don't even think it makes any sense for installers to support it:
The same program could be installed multiple times on the same machine (single user and all users?, multiple versions?)
What if the installer does not write to the registry, how is it even supposed to find the original install?
Not what I would call a perfect answer, but a functional one, so I thought I'd share. Save someone providing a better option, I am creating custom actions to handle the uninstall. NSIS is consistent (by default, anyway) in their uninstall policy. Knowing what that is, I can plan for it. Messy, for sure, but seems sound.
I'm still very new to Wix so i'm trying to get my head around how it works. There is a lot to it and its a bit hard to get an understanding of it. If my Wix MSI Contains a bunch of patch files. Can i use a Custom Action with extract the files to a temp location, run a patcher, update the version with the patched file version and then run any other MSI actions?
I'm not really sure how to do this in the XML. I Assume there is some sort of execution sequence
Also if this is possible i need a way to dynamically add the patch files to the MSI during the Build. Can you base this on an output folder?
WiX is far better than installshield and the like, but without seeing your existing .wixproj this is hard to answer directly. You can use custom actions to do all of what you want, but it's not exactly the "WiX way", as that would not be easily reversible for a rollback or uninstall. Dynamically adding files during a build is absolutely possible. I must absolutely direct you to Ramirez' WiX: A Developer's Guide for Windows Installer XML. I got stuck building a complicated installer like this, and this book was invaluable.
What I can easily say is that for the patching portion, you can run exec tasks to run the patcher program and pass the patch files you want to run. You can dump all of these to a temporary directory to do it.
I have an existing large WiX install that has already been released. I need to create a small install for just a couple of files that have changed. I have created a patch (.MSP file) in WiX for these few files using the "PatchCreation" element. When the patch is run, it presents the user with a "Reinstall/Repair/Remove" dialog. If the user selects repair, the patch does exactly what it is supposed to. My problem here is that I don't want the patch to say "repair," or to give the user these options. I just want it to install over the few files I have, more or less like a regular install. What can I do to fix this?
MSI implements patches as repairs. In WiX v3.5, the WixUI dialog library has dialogs that are displayed when installing patches.
I have found a more flexible way to work around this, thanks to some help I found here. If you start MSIExec with command-line options (for example, "msiexec /p [patch file] REINSTALL=ALL REINSTALLMODE=omus"), you can get the install to start up without the "Repair" option coming up. You can also use the IExpress tool (which is shipped with Windows, and can be brought up in a command-prompt) to create a wrapper/bootstrapper that will start the MSP file from MSIExec.
Thanks very much to the answers I received. I would not have figured this out without your help.
I partially agree with Bob. Patches in WiX are applied through a repair, but Windows Installer does support a standalone patch installation. Other setup authoring tools can create them.
Regarding the WiX patch, I recommend using a custom bootstrapper which applies the patch automatically.
i have already an installer for our application. but it is exe-file. it was created many years ago.. application of course was updated. we used a bat-file to register new dll-files and to install our service(windows). but we want to do all this by installer not a bat-file. we chosen a wix techology. i read about <Patch> node, but to use it i need an msi from previous version.. i think to do a simple installer, that will stop service,copy and register dll in the installed application's directory, install service. but i don't know will it overwrite the files without any problems?
You can only create an MSP (Patch) for an MSI (Installer). Also, you're going to run into component ref counting problems if you install your components into the same directory as the original install. The problem is MSI will go to see a file is already there, make it as a shared resource and increment the usage counters. Then on uninstall it will decrement, see that it's not 0 and remove to uninstall the files.
I'd suggest installing to a new directory and then using the RemoveFile table to get rid of the old files. Also I'd suggest following good CM / Versioning practices so that you don't have to worry about hacks such as Version Lying.
If all your application just needs to xcopy files, setup a directory and maybe even a ShortCut, it should be a piece of cake.
Versioned files like executables will automatically be overwritten if the version of the file number is lower.
See also Copy if not exist in WiX.
I've developed a Wix installer for an internal project however entirely by accident I've found that I'm unable to uninstall the installer on my development machine as I get the following error message:
The feature you are trying to use is on a network resource that is unavailable
with a dialog pointing to the path of the .msi that I installed from feature from. (The .msi is there, however is has been rebuilt and so has changed since I installed it)
I'm concerned by this dialog as I had believed that Windows Installer kept track of installed .MSI files, however this dialog seems to suggest that I can break my uninstaller by deleting, moving or changing the installer.
Is this the case?
What do I need to do to make sure that I don't break my uninstaller in this way? (Do we need to keep copies of all versions of the installer ever installed on a machine?)
The easiest way to get out of this situation is to do a recache/reinstall. Build a new version of your MSI that isn't "broken" (in whatever way it is broken, in this case, it might not really be broken at all, you just need a new source). Then you use a command line like:
msiexec /fv path\to\your.msi /l*v i.txt
That will copy your.msi over the MSI that is cached and do a repair. Then you'll be in a better place.
One of the first painful lessons of writing installs is to never run your install on your own box. Certainly not until it reaches a point of maturity and has gone through several QA cycles. This is what we have integration labs and virtual machines for. (There is a saying about things you shouldn't do in your own back yard.)
That said, normally an MSI uninstall doesn't require the MSI but there are situations where it could be required. For example if one was to call the ResolveSource action during an uninstall, MSI would then look for the .MSI.
Now there are several ways out of this pickle:
Take an MSI you do have and edit it with ORCA to match to file name, UpgradeCode, ProductCode and PackageCode of the MSI that you installed. You should be able to get all of this information from looking at the stripped cached MSI that exists in %WINDIR%\Installer. CD to that directory and do a findstr -i -m SOMESTRING *.msi where SOMESTRING is something unique like your ProductName property. Once you know the name of the cached MSI, open it in Orca to get the required attributes. Then put these attributes in a copy of the MSI you have available and try to do an uninstall. No, it's not the exact MSI that you installed but usually it's close enough.
or
Use the front end windows installer cleanup utility (if you still have it) and/or the backend MSIZAP utility to wipe all knowledge of the application from MSI and Add/RemovePrograms. Note, this doesn't actually uninstall the program so you'll have to also write a script or otherwise manually uninstall all traces of the program.
or
Reimage your workstation
If you know exactly what is wrong (which is often the case during development), I prefer to open the MSI file that Windows will use for uninstallation and edit it directly with a tool like Orca to fix or remove the part that causes the failure.
For example:
Locate the MSI file in %WINDIR%\Installer. The MSI should be the last edited MSI file in that folder right after you did the failed uninstallation.
Open the msi file with Orca.
Remove the failing part - for example the InstallExecuteSequence action that fails which is atypical scenario.
Save the msi and close Orca to release the lock on the msi file.
1 - Have you experimented with "run from source" during installation?
This is an option in the feature tree which allows you to run some files from their installation source. This is generally combined with an admin image on the network. See image below. I haven't tried it, but I assume this could cause: "The feature you are trying to use is on a network resource that is unavailable" if the network is down and you are trying to uninstall. Just a theory, there are other ways this could happen.
2 - Are you running script custom actions? If so, do you extract to the tmp folder or run from installed files or the binary table? If so, is the custom action conditioned to run only on install?
3 - Are you perhaps running an EXE custom action that is pointing to an installed file? If so this file may be unreachable on the network.
4 - Are any of your userprofile folders redirected to a network share?
5 - Are you installing anything directly to a folder on the network?
There are plenty of other possibilities.