I have created an installer with Visual Studio 2012 and WiX 3.7. When I try to install this on a terminal server where the local disks are hidden, I need to be able to choose a network path for installation of a file. If I choose a network disk now, I get a message box saying "Installation directory must be on a local hard drive.".
I have tried to add this line to the WiX source:
<Property Id="WIXUI_DONTVALIDATEPATH" Value="1"/>
but without any luck...
Definitely possible at least in 3.10. Add following property to your main product.wxs ...
You must TYPE IN the path you wish to install to fully.
If you try and change it change the Change Folder dialog you will get the error "installation directory must be a local hard drive"
This is a WiX bug and is scheduled to be fixed in WiX 4.0 - https://github.com/wixtoolset/issues/issues/4737
Healy
I don't think it will be possible. You need to map out the network location to make it work.
Check out FW: Issue Regarding Install on mapped/shared drives.
Related
I used the Wix tool in Visual Studio 2015 to generate an msi in a custom directory - not in Program Files. The software got installed alright (only for current user) but I am unable to uninstall it.
The error shown is: The specified path 'H:\Config.Msi\' is unavailable.
However, a folder with name exists at the specified path. Also, the uninstallation succeeds when I delete the contents of the folder created by the installer.
Any ideas on how I can get the software to uninstall cleanly?
The problem was that the referenced path H: was a virtual drive that caused the error. Mapping TARGETDIR to reference the correct path was a work-around. For my use case, this was sufficient.
I need to change an entry of a .NET config file.
The problem is that the App.config in the project folder needs to stay untouched, because otherwise the application won't work within the IDE anymore.
I need the installed .NET config file changed after its installation.
Whenever I try to reference that file and build my installer, i get an error that the file can't be found. Of course it can't be found there, because the installation folder doesn't exist, when I build the installer.
How can I achieve that goal?
You are not saying how you are editing it, but WIX has two facilities for doing this properly. You can use XmlFile or XmlConfig. These are scheduled at the proper time by WIX for you. You can set the path to the file a few ways as they accept a formatted string, so you can use an expected installed path or the file id.
I am trying to repair an installed msi setup with below argument:
msiexec /f "msipath"
It is repairing properly. But while repairing i need to change its install path too. I tried this argument msiexec /f "msipath" INSTALLDIR="path"
But this is not working.
Whether it is possible to change the install path of an msi while repairing it?. If possible means, please share the exact argument.
It is not possible. For a component to be moved, it must be uninstalled and then reinstalled. (Repair just replaces resources in their original locations.) Consider this note on MsiSetTargetPath:
Do not attempt to configure the target path if the components using those paths are already installed for the current user or for a different user. Check the ProductState property before calling MsiSetTargetPath to determine if the product containing this component is installed.
Thus you typically have to remove and reinstall the entire package. A major upgrade can be a good way to accomplish that, depending on your other needs.
The existing installer for our product does not write any information to the registry, nor does it write any custom environment variables. The user is allowed to change the install directory in the installer's UI. When I'm doing an upgrade, how do I find out what folder the previous version was installed into?
I need to know the folder so I can find the previous configuration file & copy values from it. The new version's configuration file has new tags and a new structure, so I can't just keep the previous file & reuse it.
Tony
MSI doesn't have that information directly. (MSI packages can have multiple "root" directories, so there's no telling which one a developer might want.) If you have the directory in the registry, use RegistrySearch. Otherwise, you can use MsiGetComponentPath in a custom action.
I've done some research into this and here's the solution that I came up with:
When the installer finishes installing, it creates a node in the registry under the path
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\<Product ID>
for 32 bit installs on 32 bit OS or 64 bit installs on 64 bit OS, or
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<Product ID>
for 32 bit installs on 64 bit OS.
This node contains a value called InstallLocation which gives you the path to where the executables are installed.
Unfortunately, the previous version of our installer did not set this property, so I can't use it. BUT our installer creates a Service. I have found the path to the node in the registry for that service. From there, I can retrieve the value of the ImagePath value and extract the path from the service's .EXE file name.
So my solution is to:
Fix the new installer so it does set the InstallLocation value.
When upgrading from the previous version only, it will retrieve the registry node for the service & use the service's ImagePath key.
If upgrading from any later version, we'll retrieve the Uninstall node and use the InstallLocation key.
Tony
msiexec keeps a copy of the msi from the last install so it will handle uninstalling the previous version you will need to just include the InstallExecuteSequence section
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallValidate" />
</InstallExecuteSequence>
This will only work if you are using the same UpgradeCode attribute in your Product Element.
Good Luck!
I am creating an install package using InstallShield Pro X. The upgrade works properly. However, the product manager wants the upgrade to replace all files on an upgrade even if the create date != modify date on the file.
I see that to do this I need to set REINSTALLMODE=vamus rather than vomus. However, I don't see how to tell InstallShield that I want it to use that setting. By default setup.exe always passes vomus to windows installer.
There is a property in the InstallShield project named ReinstallModeText that I changed from omus to amus but that seemed to have no effect.
So, how what do I set in the install project so that when setup.exe detects to run an upgrade it sends REINSTALLMODE=vamus? Thanks.
Update: Tried adding the following to the MSI Command Line value in the Release section:
REINSTALLMODE=vamus
This did not work. Setup.exe didn't set REINSTALL=ALL on the command line what I did this. I added that to the MSI Command line and the upgrade worked as expected. But, not the problem is if it is a NEW install those properties are still being set and the installer fails.
In investigating this further and testing more options I think the best answer is to modify the product code in addition to the product version and author it as a major upgrade which removes the previous version first and then installs the new files.
The main problem with this is that it takes alot longer for the installer to run. I also think that you can not issue this as a patch, but I could be wrong on that count.
Don't set the REINSTALLMODE to amus or vamus (force overwrite files). These settings apply to all components in the MSI, and could hence in theory downgrade system files or at least shared files - this typically involves files included via merge modules. It is normally safe to set REINSTALLMODE to emus (replace files with lower or equal version number). Even this can trigger a file replacement error if you try to overwrite a system protected file on newer versions of Windows featuring Windows Resource Protection (wikipedia) (Windows Server 2008 and Vista onwards). On older Windows versions the file would likely be overwritten and then restored in its right version from the dllcache via the Windows File Protection feature provided that feature had a good day. There was (and is) an associated tool for system file checking: System File Checker.
If you have issues with files that should be replaced even if they have been edited, you can use the RemoveFile table to schedule the file for removal during install (and then it will be reinstalled).
The real solution is to consider the installation folder in %ProgramFiles% as read only, and not have the application save ANY settings or change any files. All config files should go to the user profile or the alluser profile and the application EXE file should be responsible for the copy to the profile locations.
See my answer here.
I don't have IS X handy, but in later versions of InstallShield you would go to "Releases", highlight your release, go to the "Setup.exe" section and there's a field called "MSI Command Line Arguments". There you would indicate any command-line arguments that you want Setup.exe to pass to Windows Installer. E.g. REINSTALLMODE=vamus
You mentioned you used ReinstallModeText with "amus". Have you tried ReinstallModeText equal to "vamus". The "v" causes the installer to run off the source package, not the cached package, and that may be your problem.