I am trying to launch another MSI while installing a first one. I found out about the chained packages. I followed this tuto, everything works great but I'd like to go further in the settings.
My final goal is to avoid, for the secondary installer, the install folder selection, and automatically install the files in the same folder as the principal MSI.
Is it possible ? If not, what could I do to reach my purpose ?
Any help would be greatful.
The main MSI install folder property is APPDIR. To achieve what you want you can set the install folder property of the chained MSI to the APPDIR property value. This can be done by setting the Properties field like this:
CHAINED_INSTALL_DIR_PROP = "[APPDIR]"
Also the chained package could be configured to install without full UI so the user cannot select the install folder.
Related
I am having trouble with my WiX installation in that I am registering a file extension but because you have to tie every component to a feature, I can't get the feature to install to "All Users"?
Specifically what is happening is I install the MSI under an admin account. The MSI is not located in a shared location that is accessible by all users. The extension appears to register for the other users however when other users click on the file (with the newly registered extension) to open it, it tries to look for the original MSI first to install a feature. If the MSI is found it will open the installed application like normal, otherwise it errors. For the admin account that installed the MSI, it does not ask to install the feature from the MSI (even if I delete the MSI before clicking on a file with that extension)
I have set the installlevel of all the features to "1" and set the TypicalDefault to "install" and InstallDefault to "local". The package is also set to install at the machine level.
Is there something else that needs to be set?
See if this helps: Troubleshooting unwanted self-repairs using the Event Viewer
Basically you need to understand why the repair is happening (which component key path ) and then remediate it. Alternatively you could wrap your MSI with a EXE (WiX Burn) and cache the MSI in a location that users can access if the repair is truly needed.
I have a setup made by Setup Project for my application. Is there a possibility to make my setup not check for any installed versions of a product?
I want it to work in this way: whenever I open my setup I want it to do a clean install. I don't want to have any repair option, but I want it to allways overwrite the installed product.
Is there a possibility to achieve it in Windows Installer? Are there any properties I could change in Orca to achieve it?
Thanks a lot for any help!
You would need to stop registering the package with Windows Installer. To do that you need to remove the following standard actions from InstallExecuteSequence table:
RegisterUser
RegisterProduct
PublishFeatures
PublishProduct
Just so you know, this will also make the product to not be listed in Control Panel, list of install programs.
We are installing several web sites using msi's as part of continuos integration tests.
For each build we want to uninstall the old msi and install a new one.
Problem is we do not have the old msi after the build server has done a get latest and rebuilt the system.
Is there a way in which we can uninstall the msi without having access to the orginal msi?
Yes you can, if you know the product code. Just type
msiexec /x [ProductCode]
on the command line. Or you could do it through the Add/Remove programs applet.
If you want to find the physical file, Windows actually stores a copy of the msi when it runs it - you will find it somewhere in your %WINDOWS%\Installer folder, but it will have been given a random name so could be quite hard to find :)
Alternatively if you don't know the product code (which you should) then try searching for your app name under the HKEY_CURRENT_USER\Software\Microsoft\Installer and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData registry keys, you will find the product code there. (quick hint: you can also search for UninstallString values in the registry).
I have created a Setup and deployment project using the Visual studio and install the setup.
After i install the setup it copies a few files(XML) which on using of the application are configured programmatically .
Now , If the user is reinstalling this setup again i need to ask the user whether these configured files need to be overwritten or be retained ??
Any idea as to how this can be accomplished ?
Thanks & Regards,
Fran
Look into file versioning rules for Windows Installer.
In short, assuming that these XML files you refer to are unversioned text files, MSI will compare the Created and Modified dates and will not replace the updated XML files which you say are updated programmatically (post-install-time).
I would suggest several other variables you need to consider to make sure things are working as you expect: major vs. minor upgrade, and the REINSTALLMODE property.
I find that the best way to approach this kind of scenario is to implement the "preserve changes" logic in your application as opposed to via the setup. This avoids complicating your setup and yields greater control of the config process since all logic is embedded in your main EXE file. This means you can step through the process and debug it the normal "development way".
To achieve this you can install your "base config" files to a read-only location such as
%ProgramFiles%\MyCompany\MyApp\MyConfig*.*
Then your application can detect on launch whether existing config files exist in the user profile (or in a writable shared location), and ask the user whether the new config files should overwrite the existing config or not. You can also easily implement backup functionality for the old config.
In order to ask the question only once per user after deployment, the normal apporach is to flag HKLM with the latest installed version of the application and then write a corresponding flag in HKCU when the copy operation has completed or the user dismissed it:
HKLM\Software\MyCompany\MyApp\Version = 2.0.0
HKCU\Software\MyCompany\MyApp\Version = 1.0.0
In the above scenario version 2.0.0 of the application has been installed, but the per user config copy has not run for the user in question yet. Once it has run the HKCU version will be set to 2.0.0 and the operation is not run again until HKLM is incremented.
I am creating a Visual Studio Setup project. I want to un-install another component from the system from the install of my component. The other component is installed from my own setup created using Visual Studio.
Currently when I am calling the un-install of the other component from the install action of the component I get the error code: 1618 (another MSI already running).
Could anyone suggest me an alternative way to solve this problem?
If you don't need to actually run the uninstall of the other component, you could use a Custom Action to remove files/folders you intend to replace.
Using a Custom Action will force you to do all the clean up actions the Uninstaller would do for you.
Is it that you're replacing something or are you just trying to uninstall something as a result of installing something entirely different?
MSDN Custom Action Walkthrough
I have also read a few articles from Phil Wilson that have been helpful with Custom Actions:
Phil Wilson on Custom Actions
I ran into a similar problem that required several installs to run together and could find no way to run MsiExec recursively. The solution I used was to bundle the installer with a script that would run MsiExec once to install/uninstall the old package, then again to run the new installer. Clients had to run the script to install.
If you find a better way, let me know.
I think you can run uninst.exe of that program through the shell command while setup starts.....