Using VS2010. I have a VS Installer project. I've learned how to set the default install dir according to a registry value.
But, I need to add logic so that if there is no such RegKey, then fall back onto the default [ProgramFilesFolder][Manufacturer]\[ProductName] as the default install dir.
Hoping to not need WiX for this (due to time constraints and learning curve).
This is my first post. Please correct me if I haven't followed the guidelines.
Thanks.
This can be done through a type 51 custom action (property set with formatted). Basically, you set the folder property to the default path when that property is empty.
Since this needs to be done before CostInitialize, you will need to either edit the MSI with Orca to move the custom action or use WiX to configure the action manually.
Either way, make sure that this custom action is immediate.
Related
I'm building a setup executable using Visual Studio 2015 Setup Project template.
I added an external executable in the file system of my package that the user needs to install to be able to run my program. Then, I added this package as a custom action on Commit.
I want my install package to recognize if this external executable is already installed on the user computer by looking at the registry of looking at a certain folder structure on the computer (the method to check is not defined yet).
How can I set up this kind of check for the custom actions ? I've seen that there is a Condition property when clicking on the .EXE in the Custom Actions window, but all I can find about this property is that, which does not really answers my problem.
VS setups offer a registry search, and that search will set a property name that you define (in uppercase). If the registry entry exists, meaning that you don't need to run the program, then you give the custom action a condition of NOT FOUNDREGISTRY assuming FOUNDREGISTRY is the name of the property.
Having said that, if that program is a redistributable that installs something then:
They are typically smart enough to figure out if they need to do anything or not, and that includes seeing if what's already installed is an older version, so they should run anyway because it's a newer version. So it may be best to just run it anyway.
If the executable wraps a MSI-based setup then it will fail because you can't install an MSI-based setup with a custom action in a VS MSI setup.
I am using InstallShield 2015 and project type is basic MSI. I need to run a few different batch files during the install process as well as the uninstall process. For the install process I created a custom action to run an EXE (or batch file in my case). The working folder is the SystemFolder and the command line is the following:
"[SystemFolder]cmd.exe" /c "[INSTALLDIR]PrinterInstaller\installPrinterDriver.cmd" [INSTALLDIR]PrinterInstaller\
This works perfect during the install process. A problem occurs during the uninstall. I have another custom action for the uninstall:
"[SystemFolder]cmd.exe" /c "[INSTALLDIR]PrinterInstaller\removePrinterDriver.cmd"
This above does not work. I reviewed the log and [installdir] is returning the default path instead of the path the user chooses during the install process. So if the user accepts the default install path during installation, everthing works great. If they choose a different path, the uninstall process fails. I researched this and my mistake is that I can't use the INSTALLDIR property during uninstall as it will return the default. I've read several posts on this subject and I understand the problem. I am facing the same issue with some custom installscript that runs during the uninstall process. I solved this by using the registry to store the "user" selected install folder during install then retrieving it during the uninstall. This works. Is there a way to apply a similar technique to custom actions that run batch files? I mean, can I lookup from the registry somehow and get rid of the [INSTALLDIR] syntax in my command line.
Here is a similar post, but was not a solution for me:
Install file create by InstallShield 2012 sometimes did not get the proper INSTALLDIR when uninstall
OK, I found a solution for this. I created a system search to read the registry and retrieve a value which can be stored into a public PROPERTY. Here are the steps:
1. Create a system search (uses the AppSearch and RegLocator tables). The system search will lookup the value from the registry and store it into a new public property (i.e. REALINSTALLDIR) that I choose.
2. During install phase the correct installation path will be stored into the registry under something like HKLM\software\mycompany\myproduct. Make sure the registry path and value used here matches the path/value used in the system search.
3. Change the custom action to use the new property.
"[SystemFolder]cmd.exe" /c "[REALINSTALLDIR]PrinterInstaller\removePrinterDriver.cmd"
REALINSTALLDIR will contain the user selected path or the default if the user accepts the defaut path. This expands correctly during the uninstall phase because the system search will populate the property at runtime.
The following post was the key to my answer:
http://forum.installsite.net/index.php?showtopic=10773
My scenario is as follows:
I have a client-server application. The client is deployed through an MSI package. I would like to customize the MSI to include some details that are specific for the each installation (i.e. I need to write the address of the server into one of my configuration files; this address is different in each installation).
I am considering the following alternatives:
Unpack MSI, un-compress CAB, modify file, compress CAB, create MSI (as explained in this link). The problem is that I need this to be done automatically (no GUI, no user intervention)
Pass the address as a parameter to the MSI. Then during the installation read this parameter and modify the file. This is far less desirable since creating the configuration file on the client is something that I am not currently doing, and this means adding another component to the client.
Create the MSI from scratch on the server.
If someone has experience doing something similar, I would appreciate the feedback.
What are you using to author your installer? I know WiX and InstallShield both have custom actions designed to update XML files using XPath statements. You can do things like
For Foo.Exe.Config
//appSettings/Add[#key="Server"] set Value = "[SERVERNAMEPROPERTY]"
Then you could write a custom dialog that asks the user for the value to set the property. You can also do silent installs with:
msiexec /i foo.msi /qn SERVERNAMEPROPERTY=MyServerName
When we deploy our products using OEM we have a requirement that our company name will not appear in the Publisher property of the installation in the add remove / other.
although we have easy way of choosing neutral name for the publisher we would love to be able to set the name dynamic according to property for the installation (and allow our partner to add his name to it)
Is it possible?
Will that impact the sign of the MSI?
Trying to add [PROPERYNAME] to the Manufacturer property in WIX 3 didn't work as it simply set the name to include the "[PROPERTYNAME]"
Changing the MSI would invalidate the signature, and since Manufacturer is a private property, it cannot be passed in from the command line. What can work is a transform, and the transform can be signed by the vendor so it doesn't harm the aggregate signature status on Windows 7 (MSI 5.0) and up. However applying the transform also requires a command line, so that may or may not be easy, depending on your bootstrap.
I want to make a installation which can be both new installation and update installation.
When it was used as an update installation, I want some files to be updated regardless the version and modified datetime. And some files would never be updated.
What I tried:
Set the "REINSTALLMODE" to "amus". And set the "Never overwrite" property of never updated files' components to be "Yes".
What I get:
It doesn't work. Those components with "Never overwrite = yes" are still updated somehow.
My question:
Is this right? REINSTALLMODE has the higher priority than component's "Never overwrite" property?
How to deal with this partial updates issue?
Thanks in advance.
MSI has specific File replacement logic (Archived link).
I would look into doing a Major upgrade.
Assuming these are unversioned files (for example text/xml config files, not assemblies) I would manually set the File Version on any file I wanted to always be updated (the manually set version will override what is already installed), and leave alone the others which the file replacement logic should ignore.
Here is a doc about REINSTALLMODE=amus which mentions the 'a' means ignore file versioning rules and update everything. not what you want. Also, I believe REINSTALLMODE is generally for 'repair' operations, not install/upgrade anyways.
We do something like this...
Install files to program files
Install default configuration to all users appdata
Copy default config to per-user appdata if per-user config not found.
What this means is that if an update is applied, the default configuration is reset but the per-user configuration is not. All settings, etc are saved and not overwritten during the MSI update.
Depending on what files you're trying to "not update" I suspect you can probably do something along similar lines.