I'm already familiar with prebuild steps such as updating XML or using the automation interface to update a project. I'm looking for a far more simplistic approach to the following situation.
I'm using TFS 2010 and InstallShield's native MSBuild support to build an MSI. Is there a way to pass a property into the build to transform the output MSI name?
For example I'm already updated my .isproj file to create an InstallShieldPropertyOverrides item group to override the ProductCode and define the InstallShieldProductVersion property to override the ProductVersion Property. ( I only support Major Upgrades on this install. )
What I want to do is create MSI names like:
[ProductName]_[ProductVersion].msi
I want the name unique to be more obvious and I'm not concerned about side effects since I already support only Major Upgrades.
I tried putting the above string in the ProductConfiguration screen but the compiler didn't evaluate the expression. The result was an MSI of that literal name.
Related
I have a custom bootstrapper using burn, in which I have to detect the driver version of a specific printer on startup and store this value in a burn variable for later usage. Until now, I did this in the overriden Run method of BootstrapperApplication, but I would rather create a WixExtension, to be able to do something like this:
<customUtil:PrinterDriverVersion PrinterName="somePrinter"
Variable="variableToStoreVersionValue" />
This would be similar to the RegistrySearch element in wix's UtilExtension.
There is an example of a CompilerExtension in the book "WiX 3.6: A Developer's Guide To Windows Installer XML", but I don't get it. Why do I need a new msi table? I just want to use that in burn, not in an msi installer?
I looked at the source code of wix, trying to understand, how the RegistrySearch element works. So UtilCompiler just parses the xml attributes and then creates some rows in the WixRegistrySearch table. This table gets iterated by the binder, who writes all searches in the BurnManifest and then creates the resulting output file (.exe). But when and where do this searches get executed at runtime?
Is a CompilerExtension capable to get my task done, or am I on the wrong way?
WiX doesn't have this functionality today. This use case is also needed for the VSExtension to support installing VSIX packages into VS2017 with a bundle, since code needs to be executed to detect VS2017 instances. I created a feature request here.
The UtilExtension searches are special. As you said, they end up in the BurnManifest. The code that executes the searches is in the Burn engine.
I am someone with little to no experience with wix and I am trying to support Windows also for the component I am responsible for. I am trying to create merge module for a set of files that my product generates. These files exist in numerous sub directories. I was wondering how I can create a single component ID for all the files in the entire tree. I am not worried about minor upgrades as that is something I am not going to be doing. I am trying to avoid generating numerous GUIDs for each of the file.
Also is there any way I can change the name of the root directory I want the files to be installed. Currently, in our build system the files I want to install end up in a directory name "install". In the wxs file generated by heat it comes up as install. I was wondering if I could change it to the actual product name instead of "install".
Use one file per component - this avoids all sorts of problems (except .NET assemblies spanning multiple files). See the following thread: One file per component or several files per component?
Wix is a great framework for creating installers, but it has a steep learning curve. I strongly recommend you read a few sections of this great, online tutorial: https://www.firegiant.com/wix/tutorial/
If you are a "sample based tinkerer", you can find an even quicker, sample based tour in this article: http://www.codeproject.com/Tips/105638/A-quick-introduction-Create-an-MSI-installer-with
Wix is hands-on. Just focus on the samples, and focus on getting the components created and a major upgrade set up:
How to implement WiX installer upgrade? (modern, convenience way)
How to get WiX major upgrade working? (legacy way - more flexible, less convenient)
http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html
Once you got that running the rest of the details fall into place by reading the documentation for whatever feature you need. Using Visual Studio / Votive with intellisense ensures that you can learn as you go with features such as shortcuts, ini files, xml files, dialogs, etc...
Another top tip is to use dark.exe (part of the Wix toolkit) to decompile existing MSI files. This yields Wix XML with code you can copy and paste into your own Wix files. I use other MSI tools to compile such MSI files, and then copy the sections I need into my Wix file - just to speed up the process of creating the Wix XML. Studying the decompiled XML is very educational - a real time saver.
UPDATE, May 2021: Some more links:
WiX Quick Start - Very long version
WiX Quick Start - Short version
If all the files are going to the same destination folder, then you can create one single COMPONENT with all the FILE within it. There is nothing stopping you to do that. You can then just create one GUID for that component. Also read these answers which talks about the advantages vs disadvantages of one component vs multiple components before you implement it: Answer1 Answer2. To Summarize:
You will have trouble with minor upgrades/repairs. If a component is
being updated, only the file designated as the KEYPATH is checked to see if
it is out of date: if it is up to date, all the others are ignored.
You'll also have difficulty if you want to add or remove files from each
component. Once released, a component is immutable (in terms of what files
are in it). The only way to update it without breaking component rules would
be to effectively remove and install the a new version of the MSI.
Understanding the component rules is key in Windows Installer and one file
per component makes the component rules easier to work with, which is why it
is the recommendation of many people here.
LINK
The root directory name can be changed by modifying the "Name" property for the DIRECTORY element.
I am working on an installer with a handful of custom actions that look for values in the following MSI properties:
ADDLOCAL
ADDDEFAULT
REINSTALL
REMOVE
When running the installer with the full UI, these properties contain lists of comma-separated feature names as appropriate given the options that are selected by the user. However, when I run the installer in passive mode or with only a basic UI (or no UI) from the command line, I find that the properties are empty/blank. It is only when I explicitly set them from the command line that they have any value. This is an acceptable work-around, but it would be much better if these could take on some kind of default, such as "all", without requiring values to be passed on the command line. Is there some way I can specify this in WiX (which I am using to build the MSI) or do I have to do something in the custom action code (or something else entirely)?
I have looked at the property reference here, but I did not see any mention of how one could specify default features for these properties.
What I also found interesting is if I do specify a feature this way on the command line during install, it seems to be stored for the uninstall in the REMOVE property (in other words, I do not have to pass any parameters when uninstalling in any mode). Is this a feature that I can rely on? Will it automatically update if someone modifies the installation later?
I'm running WiX 3.5.2519 and using Visual Studio 2010 with Visual C++ for the custom action code. Thanks for any help you can give me!
Edit:
Actually, I was wrong. It appears that the REMOVE property is always set to "all" when uninstalling and running in one of these modes, even if I pass a different value on the command line or only install a subset of features. This seems broken. Am I doing something wrong here?
C:\> msiexec REMOVE=FeatureName /passive /l* uninstall.log /x Product.msi
It will completely ignore what I specify for "FeatureName" and use "all" in its place.
Your custom actions probably shouldn't examine those properties. Instead they should examine the feature and/or component states of the product, depending on what they're trying to do. In conditional statement syntax, this looks like $component-action or &feature-action (where you use the name of the component or feature whose action you are trying to condition against). In C++ (for inside the custom action) this looks like MsiGetFeatureState or MsiGetComponentState, and these are of course made available through similar means in most other languages (such as session.FeatureRequestState / session.ComponentRequestState in a language you shouldn't use).
It is a recommended practice that all properties to be used by the installation be entered into the Property table with an initial value. The installer sets the properties to these values at the launch of the installation. Properties for which a blank is an acceptable value and properties built into the installer do not need to be initialized.
You can then change the default value programmatically or on the command line as described here: Using Properties.
I created a MSI "appA.msi" with WiX 3.5 and have discrete GUIDs in the .wxs file for
Product Id
UpdgradeCode
Package Id
I do not have any component GUIDs specified.
It installs like this:
...program files...
.....homedir
.......launcher.exe
.........appdirA
...........app.exe
...........app.exe.config
I then built another MSI with the same project called "appB.msi", all bits the saedited the app.exe.config file, changed the GUIDs for
Product Id
UpdgradeCode
Package Id
And I expected it to install like this:
...program files...
.....homedir
.......launcher.exe
.........appdirB
...........app.exe
...........app.exe.config
(yes launcher.exe is the same file going in the same spot)
But instead of installing, I get the message "Another version of this product is already installed."
But AFAIK the versions are completely different, right?
Thanks.
Generally speaking you are best off using the ?????-??? format for the package code and for the product code rather than using a static one that you have to keep editing.
Not setting the component GUIDs means the components will be orphaned on the system.
Do you need these two packages to co-exist or should they be mututally exclusive. Depending on the answer you may need to put a little more work into them.
I am in the process of creating an MSI for our product. I would like the product to be able to install side-by-side. So that I can install 1.0.0 first and later can add 1.0.1 so that the two versions are both installed.
I am using WiX to create the msi and would like to know how this can and should be done in Wix? For example
Do I need to create new Guids for all components?
How would i add the version info to wix or should i rename my product completely?
How can I create the projects so that releasing a new version requires minimal changes in the wix project?
Greetings,
Martijn
You should be able to get away with just changing the top-level productcode and UpgradeCode GUIDs to make your two products completely unrelated, and use the Productversion to identify the version. You can share component guids between products (that's how merge modules work) so that the guts of your installer (component definitions) needn't be tweaked and can still be shared.
You major challenge will be ensuring that the two decoupled products don't interfere with one another, for example by having the same default installation folder, start menu entries and the same Add/Remove programs entry. You might achieve this by including the product version number in the ProductName Property, which can look a bit techy in your install UI, but it isn't unheard of.
Regarding your first question: No, you don't need to.
But why?
I had difficulties to understand the windows installer rules in my side-by-side scenario.
You really need to understand the concepts of component rules (including when you need to brake them) and key paths. WiX doesn't abstract these aspects away.
This answer does already highlight possible interferences.
Let's consider a few examples.
The GUID of the component with the application executable does not need to be changed. This breaks the component rules, but it works, as both versions of the product define the same component in a non-interfering way.
A resource shared by both versions is not directly supported. A prominent example is the use of file extensions using ProgIDs, as shown here.
If you change the GUID (also happening when using the "*" GUID), the extension will be removed when uninstalling either version.
If you don't change the GUID, the extension will be retained, but point to the version which was installed most recently. You may go with this option as the lesser of two devils, supporting at least a scenario where users uninstall the versions in the same order in which they installed them.
There is a pitfall here: The extension needs to be the key path of the component. This makes the usage of the ProgID element problematic in a side-by-side scenario as you'll get the ICE69 warning in case you don't put the ProgID element in the same component as the referenced file. Further more, it's an implementation detail of WiX which registry entry it generates will be the key path.