Hey guys,
I have a case here that I was wondering if you could help.
We've been looking at how Pyro makes MSP's. There are some rules which have
been baked into Pyro so that a particular configuration of a patch has to be
built with a not-Uninstallable switch. We found one of the situations that
triggers this need (we added a brand new feature with the patch). Of course, we
would like to be able to uninstall that not-uninstallable patch.
Here's where we got... creative.
We made a test MSI and applied a couple of patches, one (in between) which was
built as not-uninstallable as per the Pyro rules (i.e. Pyro wouldn't build the
msp unless we switched it not-uninstallable). We looked through the registry
and found the value switch that defines the patch as not-uninstallable. Just
for laughs, we decided to change the value of that switch (in essence, make the
patch not not-uninstallable) to see how the process would blow up and, to our
surprise, it _apparently_ worked fine. We were able to uninstall all the
patches, removing the added feature, and reinstall the patches back again.
Now, we recognize that the patches and MSI we made are very, very simple ones,
which only add & remove files. Given that this scenario seems to work for us,
what is the rationale behind making a patch that only adds a new feature
not-uninstallable (i.e. what are we missing that could be making our msi/msp
solution unstable through misuse)?
-Fernando Santiago
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
