What happens is that XmlConfig runs after DuplicateFiles, long after
RemoveFiles. There are not TWO CAs (one to run before DeleteFiles and
another after DuplicateFiles when the will newly exist). There is code in
the CA to ensure that deletes will not fail if the file is missing. It is
only when you create/write something that the file must be present. It is
when you attempt to recreate the empty node after the file is removed that
you get the error.
What would happen if you took this original authoring:
<XmlFile Id="SignWrapper_XMLSettings_PDF1"
File="[SignWrapper_RootDir]signwrapper.xml" Action="setValue" Value="0"
ElementPath="//signwrapper/BEFDE7B3-54DB-419e-BB46-5FA8CE997AD5/spezial/disa
blePdfInline" Sequence="1" />
<XmlConfig Id="SignWrapper_XMLSettings_PDF2"
File="[SignWrapper_RootDir]signwrapper.xml" Action="delete" Node="element"
ElementPath="//signwrapper/BEFDE7B3-54DB-419e-BB46-5FA8CE997AD5/spezial"
VerifyPath="disablePdfInline" Sequence="1" On="uninstall" />
<XmlConfig Id="SignWrapper_XMLSettings_PDF3"
File="[SignWrapper_RootDir]signwrapper.xml" Action="create" Node="element"
Name="disablePdfInline"
ElementPath="//signwrapper/BEFDE7B3-54DB-419e-BB46-5FA8CE997AD5/spezial"
Sequence="2" On="uninstall" />
And changed it to this:
<XmlFile Id="SignWrapper_XMLSettings_PDF1"
File="[SignWrapper_RootDir]signwrapper.xml" Action="setValue" Value="0"
ElementPath="//signwrapper/BEFDE7B3-54DB-419e-BB46-5FA8CE997AD5/spezial/disa
blePdfInline" Sequence="1" />
<XmlConfig Id="SignWrapper_XMLSettings_PDF2"
File="[SignWrapper_RootDir]signwrapper.xml" Action="delete" Node="value"
ElementPath="//signwrapper/BEFDE7B3-54DB-419e-BB46-5FA8CE997AD5/spezial/disa
blePdfInline" Sequence="1" On="uninstall" />
Are there other parts of the software (inside or outside of the
installation) that either change the element's value or add attributes? Can
you know them all?
BTW, if you supply the @Name attribute to the XmlConfig element, that will
cause Action='delete' Node='value' to delete the named attribute, just as
not supplying the @Name attribute will cause the element's value to be
cleared.
-----Original Message-----
From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
Sent: Sunday, October 11, 2009 6:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Problems with deactivating a component while
package removal
Guten Tag Blair,
am Samstag, 10. Oktober 2009 um 23:58 schrieben Sie:
> What are the criteria used to determine which of the four components
> operates on the file?
The components are bound to a feature for each component which is
designed to change exactly one config value. I have a feature and
component for the whole software "SignWrapper" to install or remove
the directories and files needed, which includes signwrapper.xml, and
sub features for the 4 components which should each change one config
value.
- feature of SignWrapper-software
- (sub)feature of config value 1
- (sub)feature of config value 2
- (sub)feature of config value 3
- (sub)feature of config value 4
My goal was to provide a simple way to change each config value in the
xml file using a feature and a component for each value. "install"
sets the value to a predefined value, "remove" deletes the node and
creates an empty one which is used with proper default values by the
software.
> What criteria is used to determine if the file itself
> is installed/removed?
This should be the component and feature of the SignWrapper-software
itself, I think. I thought sub features where processed first on
removal of the parent feature, therefore changing the values in the
xml file to it's default and afterwards removing the file while
removing the component for feature SignWrapper. But it seems the file
is removed first and afterwards the removal of the installed sub
features is processed, resulting in an error message about the missing
file.
While removing the feature for the SignWrapper software and deleting
the xml file itself, the uninstallation of the components to configure
the file is not needed. Is there something like a removal order for
features and components to schedule the removal of the sub features of
SignWrapper before deleting the xml file itself?
> Are these components all in the same feature or in
> separate features?
Each component has it's own feature, like stated above, but all
components belong to the same Fragment, if this have something to do
with removal order or stuff like that.
> Do any of these components have conditions apart from
> what you have shown attempting?
No, just a feature and a ComponentRef for each config value.
> When all features/products that a component belong to are removed, the
> component is removed as well.
Which isn't a problem at all, if I could somehow influence the order
of the removal of my sub feature-components. It's not a problem to
change the xml file to anything and delete it afterwards, but that
doesn't seem to happen now.
> The only way to leave a component behind is to
> mark it permanent (which causes it to be additionally associated with a
> "dummy" product that cannot be removed).
Which I don't want because I want to be able to remove the component
for a given configuration value and therefore changing it back to it's
default.
> The only way to
> conditionally leave a component during removal is to isolate that
component
> into a feature you "leave behind", except that the product remains
installed
> as well.
> The only other question I have for you is how you plan on addressing
> upgrades? I can only refine that question once I have the answers to the
> other questions, however.
One step after the other, I didn't thought about upgrades yet. ;-) If
I'm able to get working what I want and configure the xml file using
MSI features, I could always remove the complete package and install a
new one with the features for configuration values I need. At least
this was one idea. Shouldn't it be possible to uninstall specific
components during upgrades, therefore uninstall my configuration
value-components if needed?
I think if there's any way to get my sub feature-components removed
before removing the parent feature, this should be it. Maybe you see
some errors in my feature definitions? Thanks for your help.
<Feature Id="SignWrapper_Feature"
Title="SignWrapper"
Description="Dieses Hilfsprogramm wird für die Anbringung
von Signaturen aus, Word, über das Kontextmenü, die Kommandozeile usw.
benötigt."
Level="1"
AllowAdvertise="no"
InstallDefault="followParent">
<ComponentRef Id="SignWrapper"
/>
<Feature Id="Feature_SignWrapper_ContextMenu"
Title="Kontextmenüeintrag"
Description="Mit dieser Option lassen sich Dateien
einfach per Kontextmenü im Windows Explorer signieren."
Level="1"
AllowAdvertise="no"
InstallDefault="followParent">
<ComponentRef Id="SignWrapper_ContextMenu"
/>
</Feature>
<Feature Id="Feature_SignWrapper_XMLSettings_PDF"
Title="PDF-Inline-Signatur"
Description="Mit dieser Option aktivieren Sie die
PDF-Inline-Signatur."
Level="99"
AllowAdvertise="no"
InstallDefault="followParent">
<ComponentRef Id="SignWrapper_XMLSettings_PDF"
/>
</Feature>
<Feature Id="Feature_SignWrapper_XMLSettings_Tastaturpin"
Title="Tastaturpineingabe"
Description="Mit dieser Option aktivieren Sie die
Eingabe der Pin über die Tastatur."
Level="99"
AllowAdvertise="no"
InstallDefault="followParent">
<ComponentRef Id="SignWrapper_XMLSettings_Tastaturpin"
/>
</Feature>
<Feature Id="Feature_SignWrapper_XMLSettings_PKCS7"
Title="PKCS7-Dateiendung"
Description="Mit dieser Option aktivieren Sie die
Erstellung von .pkcs7-Dateien."
Level="99"
AllowAdvertise="no"
InstallDefault="followParent">
<ComponentRef Id="SignWrapper_XMLSettings_PKCS7"
/>
</Feature>
</Feature>
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoen...@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
----------------------------------------------------------------------------
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
