1

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!

Community
  • 1
  • 1
melic
  • 19
  • 4

2 Answers2

1

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.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
-1

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.

melic
  • 19
  • 4