Not sure what the problem actually was. I scrapped what I had, and started
over. Everything working now as expected.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Component-Guid-error-tp7579390p7581179.html
Sent from the wix-users mailing list a
Add a condition of '1' to each Publish directive, and see if that helps. The
WiX help links to the MSDN pages for Windows Installer for a reason. From
the ControlEvent Table you will find the following statement:
Condition
A conditional statement that determines whether the installer activates the
try
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/define-element-for-ProgramFilesFolder-not-working-in-include-file-tp7580463p7580487.html
Sent from the wix-users mailing list archive at Nabble.com.
--
I cannot suggest a solution for the patch problem you currently have, but I
might be able to suggest an alternative. I was unable to use the pure WiX
patching technique, as I was attempting to patch a file in a merge module.
The WiX help describes two methods of patch generation, the first WiX only
Rob,
Unless I am mistaken, that criteria: "[no] Property substitutions ..." is
only relevant if I am asking WiX to generate the Guid; which seems to be
indicated in the initial message.
"The Component/@Guid attribute's value '*' is not valid for this
component..."
What has me confused is that th
I am attempting to create AppId, Class and ProgId entries instead of using
raw registry key/value elements, which generate warnings. In the
documentation for Class it has the following entry:
SafeForInitializing
In General
Value "yes" specified:
[HKCR\CLSID\{Id}\Implemented
Categories\{7DD95802-98
Mark,
When I have dependencies, I have had to include the GUID of the merge module
in the dependency declaration, in order to match the signature.
Try adding the GUID to the dependency declaration:
Chris, John,
Thanks for the suggestions. I tried a vm with Server 2008 as a base OS
(instead of 2003) and it seems to help considerably. I did a couple of
trials and the set of merge modules took only 10+ minutes. The 2003 based vm
takes ~ 90 minutes. The real hardware (with 2003) takes about 20-
Not certain that this is exactly what you are looking for, if you are
actually attempting to update the directory table (based on the MY_DIRECTORY
property listed), then this may help.
...
The property SHORTCUTFOLDER is generated in the MSI and becomes the parent
directo
I think you can simplify what you have:
Then simply pass in on the command line SERVICEUSER and SERVICEPASSWORD. You
should not need the custom actions and multiple properties for the same
elements. You may need to mark
Bob,
Thanks for the response. What was confusing me is that the behavior is
different depending on whether the package default is compressed or not. I
expected to be able to have a default compressed package with specific
uncompressed files behave the same as a default uncompressed package with
I am attempting to build a project which contains a couple of rtf files
outside the msi. I have built a small Project.wxs that displays the issue.
In the project I have two components, each with a single file. One is
embedded, the other may not be. When the Package is set to Compressed="yes"
the e
Ultimately I am controlling what the user sees, the stripping out of the
merge modules is simply reducing the size of the package. Using the
condition table I have a consistent feature table for all packages, and
encapsulate exclusions within each package.
Probably FeatureGroups will work, but a
Mike,
Basically I need to adjust the feature tree for each MSI.
Each of the 10 MSIs is a distinct product package with a unique upgrade
code. Payload is attached to features via mergemodules. If the feature tree
contains features A and B, with sub-features A0 - An, B0 - Bn, the first MSI
could
14 matches
Mail list logo
