I've inherited a Wix-based installer. Most of the Directory#Id attributes are generated in the form Id="dirE039ABA27AC02A3F578F38F62EAD8474". Are there any side effects to changing that value in and every place the ID is referenced? I am hoping this isn't, for example, like a Component#Guid which must not be changed otherwise Windows Installer won't know its the same component.
Are all Wix #Id attributes similar? I'm hoping they are just internal Wix linkages and have no semantics for Windows Installer.
I want to change IDs from gibberish to something self-documenting.
Directory/#Id values end up in the .msi as specified.
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 using a Wix bootstrapper. I have a custom Theme that has a radio button that sets variables called "Client" or "Server", based on which button is selected.
What I'm searching for is a way to have the "InstallCommand" in an "ExePackage" be different based on whether "Client" or "Server" is set. (They are boolean "1" or "0") variables.
I could always duplicate the "ExePackage" and run the same installer executable with a different InstallCommand based on the variable. That has worked for me in the past. However, I am trying to avoid including the ExePackage twice, since it's rather large and would unnecessarily bloat the bootstrapper executable.
I was thinking of trying to set a variable or property based on whether one or the other is set, then use that variable or property in the InstallCommand. Any thoughts on how to go about doing this? I've searched and I can't find a solution.
My research has indicated that this simply cannot be done with the Wix managed bootstrapper application. You have to "roll your own" custom bootstrapper application to achieve this.
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'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.
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.