Is it possible to control the order of install/unintall of Wix Features? I am not sure if they are installed/uninstalled in the order they are defined in Product.wxs file. Could not find any documentation either.
Mostly I am concerned about uninstall order, I need to control the order in which features are uninstalled.
You can't control the order in which features are installed or uninstalled because that's not the way Windows Installer works. If you were to look at the MSI file with Orca and look at the order (by number) in the InstallExecuteSequence table you'd see actions like RemoveRegistryValues, RemoveFiles, RemoveFolders. These actions remove (for example) all the files in the product, not just the files (or registry entries) for a particular feature.
The short answer is that you can't control the order in which features are removed. It appears that you have asked a classic XY question and it might help to ask about the underlying problem you are trying to solve that leads you to believe that controlling feature uninstall order might help solve.
Related
We changed the UpgradeCode component to a different GUID. Is there a way to change an installed product's UpgradeCode without redoing the install?
Live?: Is the product live yet? If not, just uninstall all instances and revert to the original upgrade code? (Especially the case if you are in a corporate environment with proper control of deployment via a distribution system - then there are no constructs needed to add to the package itself for eternity).
Hotfix: Some would suggest hotfixing the cached installation database. I wouldn't even try. I find it very hacky, even when using the MSI API (Win32 functions / COM API to manipulate MSI files).
Upgrade Table: I haven't done so in ages, but you should be able to author the erronous upgrade code into your MSI file's Upgrade Table in addition to your main one. In other words, you can detect multiple related products (or even unrelated products), each with different upgrade codes by authoring the Upgrade Table. You would generally need to leave that legacy entry in there for the foreseeable future though, to ensure smooth upgrades for as long as that particular product line is relevant. You could keep using the new upgrade code, or revert to the old one (but you need both entries in there for as long as this product line updates - if you are live with all versions).
Sample: I am doing something along the lines of what is described above here: Adding entries to MSI UpgradeTable to remove related products
Background : Customers have been copying a set of binaries and putting it on a specific location for them to run NinjaTrader Indicators. For Eg: lets assume The customer "A" has used First.dll, second.dll and Customer "B" has used First.dll and Third.dll (they did not use any installers, but just copied from a server location)
Current Requirement: I have to create a WIX installer with all possible updated DLLs with a caveat that it should install only those updated dll whose previous version customer has already on his machine. So if the new WIX installer has First_1000.dll, Second_1000.dll, Third_1000.dll and Fourth_1000.dll, then it should behave on Customer "A" and "B" as follows:
Customer "A": Uses this installer, his machine should have only First_1000.dll and Second_1000.dll and not others.
Customer "B": Uses this installer, his machine should have only First_1000.dll and Third_1000.dll and not others.
What I have Tried: Using the directorySearch and FileSearch, but I am not able to conditionally install, either it installs all or installs none. Other issue with this is it wont remove the previous version of the binary.
What I need: How to call a CustomAction method and use the return result to make decision to install or not, with this I can remove the previous version of the file as well.
Overall advice: don't approach deployment as a development task first and foremost. Get your files and settings deployed, and do any advanced configuration on application launch.
Do not implement any custom logic if all you need is a file copy and some registry keys - and certainly don't do it all in one custom action using WiX / MSI as a "shell" or "container" only.
There are many tools that can help you deploy your software: How to create windows installer (also lists legacy tools that are not MSI tools).
At one point I wrote this step-by-step answer for a WiX installer.
If you ask me for the easiest way to achieve what you want, then I would install all files via a single MSI and use the application itself to adjust any access to advanced features (if applicable) via the license code (if any). This minimizes your deployment complexity, and puts advanced features in a familiar context: application debugging in user context (most likely).
This avoids a world of pain of custom setup logic - which is very heavily overcomplicated by sequencing, impersonation and conditioningconcerns, not to mention runtime dependencies and other challenges. Collectively this causes the overall problem that setup logic is very hard to debug - due to the collective impact of all these aspects of complexity.
The general approach that should work is to:
Group the components (that contain one file each) into Features that when installed will do the right thing for each customer.
Use Feature conditions based on the results of the file searches and the property values set from the searches.
This example in the WiX docs, Conditional Installation seems to do almost exactly what you're looking for.
In the longer term you should build a setup that doesn't require this type of search behavior. You don't say why the file names change, but I'll guess that you are using the different names as a kind of version control. Installs, patches, service packs, upgrades and so on all replace files based on their binary versions. In a well-designed application and install, the binary versions of the existing files might all be 1.0. If the new files are all versioned 1.1 then all the old files will be replaced. If one was version 1.0 (and therefore unchanged) it would not be replaced. The file names would not change. Version control is the basis for updates, so I recommend moving in that direction.
I've googled a lot, but there's little information about my question.
The question for short is "Suppose you have the target image(.msi), the list of changed binaries, but you don't have the upgrade image. How to make a patch based on those inputs?".
The detailed description is:
Currently, We use TFS as the source control. And each time when making a new MSI, we will increment the AssemblyFileVersion of all projects whether the project is really changed or not firstly. This is fine when there's no requirement to make a patch.But, actually, we DO have the requirement to make a patch now. I have tried to create a patch using Purely WiX or Patch Creation Properties, but almost all projects will be considered as changed when we use these MSIs directly.So if I have three inputs:
Target Image(.msi)
A list of really changed binaries
Upgrade Image(all binaries' file version is incremented) <--- this input may be useless
How Can I make use of above inputs to create a patch?
Thanks in advance.
Alternative to Phils answer, you could add an ignore switch for the only incremented files in your Patch Creative Properties File.
<UpgradeFile File="YourFileID" Ignore="yes" />
see
http://wixtoolset.org/documentation/manual/v3/xsd/wix/upgradefile.html
Depending on how many files there are to ignore might make Phils method easier. Although if you get the file table id list (export the table in orca and edit in excel, copy A3 down) and remove all the ids from you're really changed list, then add the xml around each id..it shouldn't take long.
You can still use the upgraded MSI build when you make a patch. I don't know all the WiX things you may need to do, but I've done exactly what you want to do by setting IgnoreMissingSrcFiles in the TargetImages table:
http://msdn.microsoft.com/en-us/library/aa372066(v=vs.85).aspx
and just delete all the files you don't want to be patched. You use admin images anyway to create the patch, so all you'll have are two admin images wiyth MSI files and only the files you want to patch.
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.
I need to add group within a group
e.g. COMPUTER\Users group to the "Backup Operators" group.
Wix provides a way to add a user to a group using the GroupRef Element but does not seem to provide an obvious way to add a group
Can this be done? If so how?
You'd need to write a CustomAction. It probably wouldn't take too much to extend the existing User and Group CustomAction in the WiX toolset to support this. In fact, there is a feature request open for this behavior in the WiX toolset today. Maybe you could contribute the fix?
Some resources:
http://msdn.microsoft.com/en-us/library/aa370283(VS.85).aspx (Local Group Functions)
http://support.microsoft.com/kb/119671 (link seems to be broken, leaving in for now)
I got some C++ code that wraps user and group creation, and as I recall adding groups to groups should be possible with relative ease. Unfortunately I no longer have access to that code-base, perhaps the Boost library has support, or a simple VBScript should suffice.
I don't like to make software recommendations, but I have found that the VbsEdit application features a large library of standard VBScript samples - perhaps you can find a ready made script in its' sample library.