I believe Patch works by creating a transform by comparing the existing MSI (1st one) and the new one (2nd MSI). I have a customer requirement (don't ask me why) not to create the 2nd MSI and still have another option to create a patch. Is this possible? If so, can you please provide the details? If not, can you please provide links / proofs substantiating this?
Since all files are just a collection of bytes, it's hard to prove the impossibility. However the only Microsoft-documented way to create a patch (.msp file) involves invoking patchwiz.dll (perhaps through msimsp.exe) to process the differences between two or more installation databases (.msi files). Creating a Patch Package describes this process in more detail.
If you got past this, skipping msimsp.exe/patchwiz.dll and thus avoiding creating the upgraded .msi file here, you would still have to create the transforms that go in the transform substorage. The only documented way to generate a transform (.mst file) still requires two installation databases, so you'd need your second .msi file for this step.
If you figure out how to generate .mst files without a pair of .msi files, then in theory it may also be possible to package it all up into a .msp file. I have yet to see enough documentation on how to do this, however.
(Pointers to that documentation would be gratefully accepted, whether as comments, edits, or alternate answers.)
Related
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 been trying to set up a WiX component such that the user can specify that the installer should not upgrade that component on a MajorUpgrade. I had the following code, but this means that if the condition is met then the new version is not installed, but the old version is also removed.
<Component Id="ExampleComponent" GUID="{GUID here}">
<Condition>NOT(KEEPOLDFILE="TRUE")</Condition>
<File Id="ExampleFile" Name="File.txt" KeyPath="yes" Source="File.txt"/>
</Component>
Ideally, if the user specifies "KEEPOLDFILE=TRUE", then the existing version of "File.txt" should be kept. I've looked into using the Permanent attribute, but this doesn't look relevant.
Is this possible to achieve without using CustomActions?
A bit more background information would be useful, however:
If your major upgrade is sequenced early (e.g. afterInstallInitialize) the upgrade is an uninstall followed by a fresh install, so saving the file is a tricky proposition because you'd save it, then do the new install, then restore it.
If the upgrade is late, then file overwrite rules apply during the upgrade, therefore it won't be replaced anyway. You'd need to do something such as make the creation and modify timestamps identical so that Windows will overwrite it with the new one. The solution in this case would be to run a custom action conditioned on "keep old file", so you'd do the reverse of this:
https://blogs.msdn.microsoft.com/astebner/2013/05/23/updating-the-last-modified-time-to-prevent-windows-installer-from-updating-an-unversioned-file/
And it's also not clear if that file is ALWAYS updated, so if in fact it has not been updated then why bother to ask the client whether to keep it?
It might be simpler to ignore the Windows Installer behavior by setting its component id to null, as documented here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx
Then you can do what you want with the file. If you've already installed it with a component guid it's too late for this solution.
There are better solutions that require the app to get involved where you install a template version of this file. The app makes a copy of it that it always uses. At upgrade time that template file is always replaced, and when the app first runs after the upgrade it asks whether to use the new file (so it copies and overwrites the one it was using) or continue to use the existing file. In my opinion delegating these issues to the install is not often an optimal solution.
Setting attributes like Permanent is typically not a good idea because they are not project attributes you can turn on and off on a whim - they apply to that component id on the system, and permanent means permanent.
I tried to make this a comment, it became to long. I prefer option 4 that Phil describes. Data files should not be meddled with by the setup, but managed by your application exe (if there is one) during its launch sequence. I don't know about others, but I feel like a broken record repeating this advice, but hear us out...
There is a description of a way to manage your data file's overwriting or preservation here. Essentially you update your exe to be "aware" of how your data file should be managed - if it should be preserved or overwritten, and you can change this behavior per version of your application exe if you like. The linked thread describes registry keys, but the concept can be used for files as well.
So essentially:
Template: Install your file per-machine as a read-only template
Launch Sequence: Copy it in place with application.exe launch sequence magic
Complex File Revision: Update the logic for file overwrite or preservation for every release as you see fit along the lines as the linked thread proposes
Your setup will "never know" about your data file, only the template file. It will leave your data file alone in all cases. Only the template file it will deal with.
Liberating your data files from the setup has many advantages:
Setup.exe bugs: No unintended accidental file overwrites or file reset problems from problematic major upgrade etc... this is a very common problem with MSI.
Setup bugs are hard to reproduce and debug since the conditions found on the target systems can generally not be replicated and debugging involves a lot of unusual technical complexity.
This is not great - it is messy - but here is a list of common MSI problems: How do I avoid common design flaws in my WiX / MSI deployment solution? - "a best effort in the interest of helping sort of thing". Let's be honest, it is a mess, but maybe it is helpful.
Application.exe Bugs: Keep in mind that you can make new bugs in your application.exe file, so you can still see errors - obviously. Bad ones too - if you are not careful - but you can easily implement a backup feature as well - one that always runs in a predictable context.
You avoid the complicated sequencing, conditioning and impersonation concerns that make custom actions and modern setups so complicated to do right and make reliable.
Following from that and other, technical and practical reasons: it is much easier to debug problems in the application launch sequence than bugs in your setup.
You can easily set up test conditions and test them interactively. In other words you can re-create problem conditions easily and test them in seconds. It could take you hours to do so with a setup.
Error messages can be interactive and meaningful and be shown to the user.
QA people are more familiar with testing application functionality than setup functionality.
And I repeat it: you are always in the same impersonation context (user context) and you have no installation sequence to worry about.
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 have an .ini file with configuration. I need to check if it exists in new installation to avoid creating it again. Besides if the new .ini have new fields add to the existing file.
Don't install an ini file as a file, but convert the entries into IniFile Table entries. This allows all ini file changes to be treated as "atomic change units" that allows proper merging and rollback via built-in MSI mechanism. You avoid all custom action complexity.
As Chris points out in his major upgrade comment: do things the right way in Wix / MSI and you avoid a lot of problems that start to pop up when requirements change or updates get complicated. IniFile updates implemented the right way are robust and simple to deal with.
In Wix you use the IniFile Element to achieve this. All merge capabilities, rollback support and advanced ini file handling comes along for free. All you need to do is to define what needs to be added or modified in the ini file during your installation. It will also be created if it is not there in the first place.
Using the IniFile element may look harder than it is. Here is a sample. You can also have a look at the well known Wix tutorial here.
All MSI-experts keep repeating this advice: never use a custom action to change a system if there are equivalent built-in MSI constructs.
Set NeverOverwrite="yes" on the .ini file's component and then handle the update via a custom action.
Edit: Generally it is much better to use the IniFile table as explained in my answer since you get rollback and merge capabilities. However, some people prefer the INI file installed as a file to allow easy modification of the file from outside the MSI file. Though not preferred, this does allow people to "hotfix" the INI file directly on the installation media location. Teams can use this to have the installer pick up the latest INI from development. There are technical problems with this that can be handled via a custom action (most significantly file replacement issues on install). It is also possible that an INI file can feature non-standard elements and formatting that doesn't fit in the IniFile table (rare, but possible - people with sense then use a different file extension than ini). As already explained, I would strongly advice against updating INI files via your own custom action, unless you are doing something very special - that's actually needed. It is complicated to implement and to get right.
I would suggest having 2 INI files. One that the installer owns and one that the application / user owns. The installer can always overwrite it's INI file and never worry about stomping on user data.
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.