I need some advice about how to clean up an old Wix project that hasn't been managed very well. One problem is that the project currently has multiple entries for the same files, going to the same location. For example, several .wxs files in the project will define a new component for foo.exe, each using a different GUID and each sending this file to the same DirectoryRef. This hasn't yet created any issues, but now I want to use patches (MSPs) in our product and this sort of thing messes with their operation.
I'm wondering about the best way to resolve this without breaking upgrades (since all previous installers have gone out like this). If I simply remove all the duplicate components, we get undefined behavior during an upgrade. I think what's happening is that removing one or more duplicate entries will cause the installer to generate delete operations for that file. Even if the remaining entry for the file is a new version, there is no guarantee in the order of operations during the install. So some of these files will first get updated, then one or more delete operations will remove the updated file. Thus at the end of the upgrade several files will be missing. Running a repair immediately afterwards will restore the files, since the installer knows they are supposed to be there.
I imagine one way to resolve this is to do a one off "hack" in our next release, where we copy these files into a secondary location, then run a custom action post install that copies the files from the secondary location into the primary and delete the temporary directory.
Is there a cleaner way this could be resolved?
What you are likely going to have to do is use validation to identify all the duplicates and fix them. Then change your upgrade to be a major upgrade with the earliest possible scheduling. You may also have to change your install location to a slightly different directory to get around component reference counts breaking.
Once clean you should be able to go back to minor upgrades and start thinking about patching. An alternative would be "fake" patches. I've used an MSI that doesn't publish itself as a hotfix method very successfully. It breaks a lot of rules but can be useful for organizations that don't care about patching rules and just want to make the business happy.
Related
I have an MSI, which adds a registry key, installs and starts some services, installs a file and so on. Now, there is a requirement to update one file and add a new file. I know we can create a Patch by creating a difference / transform. But in my second MSI, I only want to include these 2 files (the updated one and the new one) and not the other files, probably like a HotFix. I don't want to create a Patch. I did try to create a separate MSI but with the same UpgradeCode but with a different Product ID and a different version. But this creates a new entry in Programs and Features. Also, while uninstalling this new MSI, it does rollback the new file, but it doesn't rollback the modified file (this file was originally created by the first MSI and modified by the second one). At least if it is able to rollback and restore the state during uninstallation, it would have been great. But it is not rolling back the modified file properly.Has anyone come across this scenario? If so, have you been able to find a solution without a Patch? Please help.
There are three ways to update an installed product: a patch, a major upgrade and a minor upgrade. Although you can create a new MSI that replaces some of the files in an existing product what you are actually doing is sharing them in the same way that Microsoft Dlls (for example) are shared between many different products. (Unless you use the same component Ids and share properly you are more likely to break the product instead of updating it.) This is why you see that behavior of preserving files.
The idea that the patch may contain "contain other changes also which he is not interested in" should not be an issue. You create the patch so that it contains only those changes. It will contain other changes only if you put them in the MSI file when you create the patch.
Adding files during a patch can be tricky because there are some rules involved.
The safest thing to do is a major upgrade when adding new files.
So the choces are:
A patch that contains only the required updates.
A major upgrade, which is the complete new MSI file that upgrades the product.
A minor update which again is the complete new MSI file with the same ProductCode, incremented version, only minor hotfix changes, install with a special command line that includes REINSTALL=ALL REINSTALLMODE=vomus
Only the patch can be made to include just the changes required.
We’re generating setups automatically every week, in order to fix bugs or introduce new features to our product.
All the components are being harvest automatically in the Wix Library(ies) pre build step(s).
eg:
"%WIX%bin\Heat.exe" project "%SolutionDir%projectNameXXX.Web\projectNameXXX.Web.csproj" -configuration %FlavorToBuild% -directoryid dirBE9FDAE56D974104BBF8070FB6CC7F69 -platform AnyCPU -pog Content -projectname projectNameXXX.Web -ag -sfrag -out "%ProjectDir%projectNameXXX.Web.wxs"
So, there is a component with a “*” Guid for every file we’re deploying.
We’ve automatized also the patch creation between any previous version of our setup (let’s say V0) and the current version (V1). The patch gets created, and is being deployed, as long as no file is being removed(or renamed) by V1. We don’t mind if the files from V0 don’t get deleted, as long as updated files and new files get deployed.
So far I’ve done dozens of tests, with different parameters for example:
adding –sfdvital on candle in order force the files not to be vital, but I finally figured out that the problem comes from the components, not the files…;
another significant test was setting hard coded Guids on 3 Components in V0, that I remove in the V1 setup. The generated patch gets installed (the to be deleted files are still on the disk, all the other files updates get deployed). When the setup gets uninstalled, everything is removed except for the 3 files. Unfortunately, if the setup V1 removes the 3 files but adds 1 other file, the patch doesn’t get installed, it stops as soon as it encounters the first to be removed file.
SELMGR: ComponentId '{68FB7BC2-8D59-4CFB-88F5-9AA8CA570345}' is registered to feature 'ProductFeature', but is not present in the Component table. Removal of components from a feature is not supported!
The related topic :
Remove file during minor upgrade
is not presenting a viable solution as I cannot apply the “puncture pattern” technique, or add tags as this cannot be done automatically. Or can it?
If a user has to edit the V0 msi, get the components ids and add them to the new msi or patch, this is not a solution for us. We’re deploying over 25000 files. A major upgrade is not a solution either.
Any idea would be welcomed!
You can't delete the component, but you can matk it transient and associate it with a property with a false value so that the file is not actually on the system. The component is still there but the file will be gone. The same should work if you want to rename a file. As above, arrange for the file to be absent and add the renamed file as a new component to an existing feature.
Minor updates are really used for fixing existing resources, not adding, renaming or removing them, which is why the safest solution is a major upgrade.
We have finally managed to generate minor update patches that are successfully installed.
Here is what we have done:
We have our SetupV0.msi
In the PreBuildEvent of our wix setup project we run dark.exe on the SetupV0.msi, e.g:
"%WIX%bin\dark.exe" "%OldSetupDir%SetupV0.msi" "%OldSetupDir%SetupV0.wxs"
A wxs file gets generated.
Then we call a console app that reads all the component GUIDs and ids from the resulting wxs and, for each one of them, tries to find a match in all the wxs libraries that are in our workspace. We recover all the GUIDs and ids that don’t have a match and we generate a wxs file with empty components (that have bogus registry keys as children) and component refs. This generated wxs is already included in the setup project.
Then the build happens and a SetupV1.msi gets generated. This setup contains all the component ids and GUIDs of the V0 and possibly some new files.
Then, in the PostBuild event we create the msp.
Maybe it is not the neatest solution, (not very proud of the registry keys), we’ve tried to add empty createfolder tags, but the create folder tags made the patch uninstallable.
So, I have a WIX project which is to install either fresh installations or over previous installations of a product. This product, if it was already installed, has several files inside of 3 different folders which need to be preserved. This project also needs to copy the contents of those 3 different folders into another set of folders (same content in two different locations). In order to accomplish this I have set up my project to first attempt to write into the original folders if the files don't already exist, then copy the contents of those folders. On an upgrade where those files already exist this works fine. On a fresh install the second set of folders do not get created, but all the files do.
My assumption, and I may be incorrect, is that the msi is attempting to copy the folders over before they have even been created. This would cause folders to not exist in the area they were supposed to be copied to as there would be nothing to copy from. Is there a way I can ensure the files have been generated before trying to copy them? Is there a better way of going about this that I'm not seeing?
EDIT:
I'm going to try to clear this up a little. What I'm trying to do is the following (pseudo):
1) See if an option file (hi.opt) exists in c:\options, if not create it.
2) Copy that file to c:\options\opt2015.
I'm doing this 3 times for 3 different folders. I am creating the initial files with Wix in the c:\options folder using the NeverOverwrite parameter. This part works great; the files are created without issue and none are overwritten if they already exist. Where the problem lies is step two where I'm using the CopyFile Wix command. This will only copy some of the files from the c:\options folder to the c:\options\opt2015 folder. Depending on the initial setup of the system (if the files at c:\options exist or not) some files will copy over and others won't. It's not random, the results are repeatable every time, but there seems to be no reason why some files copy and others don't depending on the initial setup of the system.
I hope this makes sense and is a little more clear, though I think it makes things worse! It is strange behavior because to me it looks like everything should just work, but it doesn't (isn't that every bug though).
Edit2:
After more work and creating a vb script which runs perfectly outside of WIX my team and I have determined that the files just are not being seen by WIX during the installation even though they do exist. We haven't found any permissions issues and the installation is running as admin on an admin account. Doing the copy via a VBS or through the Wix CopyFile command results in, well the same results; files that already exist on the system are not being copied. Any more ideas? Should we find a solution I'll be sure to post it because this is just getting weird.
I believe your installer design should work as long as you're attempting to copy the files after the InstallFiles action runs. You should be copying the files from the first set of folders to the second set of folders by doing one of the following:
Running a deferred custom action that executes after InstallFiles
Using the MoveFiles action
This is too long for a comment, but may not be an answer either....
There isn't really such a thing as "over previous installations of a product", especially if you end up with multiple instances in Programs/Features, and files that may or may not have the same component ids replacing each other - that's going to be a mess. If you need to upgrade the installed product, use a major upgrade, that seems to be where you're going with this. If you are already writing custom actions to do some of this "first attempt to write into the original folders" then I've no idea what's going on or where you doing this in the install. In general, if you need those files in the new install then add them to the new major upgrade MSI. If you need to copy the older existing files from the older product, then do a major upgrade with afterInstallExecute and write custom action code to copy them before the InstallFiles action. Or the CopyFile WiX element could do it, see the part about the element under a component with no fileid.
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
Well, as sometimes happens, the error was entirely elsewhere. It turns out that an uninstaller for another program which was in the chain of programs which are installed at the same time was destroying the folder. Unfortunately this is what happens when a product isn't touched for 10 years. Thank you for your contributions, they were very helpful. Even though I was going down the wrong path the whole time I still made use of them in my tests and am more adamant about checking the installation order.
I am in the following situation where I need to remove a component which is marked as permanent.
A previous version of our setup installs a windows service which should be left on the system after the main product was uninstalled.
Now we try to remove the left service and replace it with an updated version. The problem is we have two different component guids out there, because of changing the tools we used to create the msi's.
In my opinion there are three possible ways to achieve the goal:
a) Use a file search to update the files itself.
b) Use a component search and try to find it. If it was not found try to find the other one. If any one found use the upgrade element to upgrade the component.
c) ??? - probably the "best practice" way
Some of my fellows mentioned to only delete the files but this would cause more trouble because of the not unregistered component in the Windows Installer registry.
I don't mentioned CustomActions here because it should be the last option the achieve the goal.
Your best option here is to open your old MSI using InstEd It! or Orca and then copy the Component GUIDs and use them in your new installer.
This way WindowsInstaller will handle the upgrade for you. Obviously this will very painful if you have hundreds of Components that are set as permanent (you only need to bother about the permanent ones), but if it's a just the service element it should be a fairly easy task.
Also make sure your UpgradeCode is transferred across and do a MajorUpgrade so that your old installer is un-installed first.
The installer I'm writing using WiX 3.0 uses a RegistryValue element to modify an existing registry value (originally written by our main product). I'm trying to figure out a way to restore the registry value when the user uninstalls my utility. I'd like to avoid using a custom action, but that might be the only recourse? TIA.
I did this. The registry value in question was the application associated to a file extension, but it could be any registry value.
My first idea was to use a "custom action" for install and uninstall to preserve
and restore, respectively, the associated regy state. This
seemed simple enough.
I created a setup project in VS2008 and built the CA's as javascript files. The "on install" script grabbed the existing regy value and stashed it into a well-known place. The "on uninstall" script would look in the well-known place, and then put the value found there, back in the original location.
Easy, right?
There were two problems:
the script that ran during install, to preserve the pre-existing registry value,
runs AFTER the registry has already been updated
with the values for the newly installed thing. So it preserved the new setting instead of the setting that was there before the MSI ran. Not useful.
The script that runs during uninstall, runs AFTER the registry values, and in fact the entire directory subtree,
have been deleted. Including the stashed value. So it had lost its state.
To solve that I wrote another script that
re-orders the custom actions so they run at the proper times.
There's actually one more twist. Obviously, the "Restore" script (on
uninstall) won't work if it is run after the registry entries for the app have been deleted. I can't remember now, why... but I also determined that this script could not run before that. Somehow that wasn't working either.
So, I modified the MSI to run the restore script
twice. In phase 1, it transfers the stashed value to a "parking lot" in the registry.
Then the application's Keys and Values in the registry get deleted, but the parking lot remains. In
phase 2, outside the transactional protection, the restore script retrieves the state from the parking lot, restores
the file association, and then deletes the parking lot.
I can't remember exactly why I needed to do this in 2 steps, but I remember fighting with it for a while before coming up with that solution.
The way it works in development:
set the on install and on uninstall CA's in the VS project
build the VS Setup project
run the post-processing script that modifies the MSI.
When using the MSI, it's a little more complicated than I originally thought but it works.
If you are using WiX, you may have more control over the time and ordering of the steps, so may not need that post-processing step.
Finally, you said you wanted to avoid a CA. To me, CA's are avoided because they are painful to produce in C++, and producing them in .NET is often inappropriate. But, it's pretty simple to use Javascript for CA's. Some people think script is the wrong tool for the CA job. I think that's wrongheaded. I think script is a very good tool for this purpose. And once you can accept script as a good tool, then you don't need to hold your nose about creating a custom CA.
The registry table is incapable of writing a registry value during an uninstall so it is correct that this must be done via custom action. I am of the opinion that using script is bad. Whether you choose to listen is up to you. I can tell you that just the other day I was called into to trouble shoot a situation where some wrote a vbscript CA that was failing because the file system object had been unregistered as part of a security lockdown process.
I suggest C++ or C#/DTF depending on your needs.
Faced with similar issue, need to update the registry value on install and restore to previous value on uninstall.
Is the only solution possible is creating a custom action for this purpose?
I found a extension for wix that has fucntions for this purpose
link to wix extensions