Hi.
I'm having problems with pyro.
I get this error: (note the weird Patch.msp in the temp directory
showing twice?!)
Copyright (C) Microsoft Corporation. All rights reserved.
Updating file information.
Creating cabinet files.
There will be '4' threads used to produce CAB files.
Creating cabinet
Try setting the RegistrySearch/@Type attribute to "directory" instead of
"raw".
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Registry-setting-with-configurable-install-directory-problem-with-value-of-SystemRoot-tp7255442p7260751.html
Sent from the
I'm creating my first MSPs. It appears that if a single component changes
then all other components in the same Feature are reinstalled/repaired when
the patch is applied. Is that correct behavior?
Backstory: I have some components that install Services. These components
do not change in the ne
Hello!
I managed to ignore the welcome screen, but in some cases, I need the
InstallDirDlg dialog to show up. So I put in these lines:
[Show Dialog="InstallDirDlg" After="WelcomeDlg"]UPGRADING_OLDER_PRODUCT
AND NOT INSTALL_LOCATION_FOUND[/Show]
This gives me these errors (I do not have
Hello!
I'm seeing a different in the output Light.exe command lines when I msbuild and
various combinations of switches, specifically /target. I tracked down the
issue to a wixlib that doesn't get included on the light command line.
When building from Visual Studio or the following command li
Never mind it is due to the way our policies are set up.Thanks,Pete
> From: peterhul...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Date: Mon, 6 Feb 2012 14:28:03 +
> Subject: Re: [WiX-users] standard bootstapper and non-admin user
>
>
> The me
Hi there,
I have a problem when I try to create a patch using torch and pyro.
What I did until now:
I saved the wixpdb files from the initial installer becaus I read it was
recommended to do so. Well, I did...
I created a new installer.msi with some changed files along with all
other files pac
Using Guid="*" does make things much simpler and I have started using this
layout to simplify even further:
This means there is only one entry for each file so it makes it even simpler
for non-WiX developers to add/remove files i.e. no need to edit Direc
A component in Windows Installer is the smallest "atom" available. It is
immutable. In particular, the Windows Installer engine decides which resources
to process based on which components are selected. When you place more than one
physical resource in a component you lose the ability to patch/u
To share my experience with harvesting:
We had a very simple setup (no COM, no installutil automated setup, etc.). The
projects producing built assemblies were responsible for staging all required
files in such a way that we could use heat to harvest a directory into the
setup. We didn't use pr
Hi, all. I'm encountering the problem ("*Could not harvest data from a
64bit dll*") detailed in this thread (
http://sourceforge.net/mailarchive/message.php?msg_id=27244946), which Rob
identified as a bug in heat.exe. I am wondering if
(A) anybody has been able to compile heat for the x64 target
The message is
"0x8007051b - This security ID maynot be assigned as the owner of this object."
Here's the log:
[12B8:12F8][2012-02-06T14:21:24]: Burn v3.6.2527.0, path: C:\Users\Peter
Hull\Documents\in2it System Software\Setup.exe, cmdline: ''
[12B8:12F8][2012-02-06T14:21:25]: Setting string var
Just as an FYI, I now updated WiX to v3.6.2603.0, but the issue is still
present.
-Original Message-
From: Alexander Krivács Schrøder [mailto:alexander.schro...@mermaid.no]
Sent: 6. February 2012 12:44
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] BootstrapperApplication.Detec
Further to my original question, I have been doing some testing. If find that:
(1) if the patch contains a _new_ file that belongs to a feature that the is
not installed on the user machine, then the patch effectively installs the
feature (and uninstalling the patch does not remove the feature)
I'm using the WiX v3.6 Beta (v3.6.2221.0) here. This functionality has worked
before, but now, the DetectMsiFeature event does not fire at all upon calling
Engine.Detect(). Other related events, like DetectPackageComplete and
DetectRelatedMsiPackage do fire. Is this a known problem?
For the archives:
Look at the "Specify source file locations" in the "Others" section of the
"How To Guides" part of the CHM (or navigate there in the online manual). If
those test.dll files are going into other directories than ones named
subfolder1/subfolder2/etc then you will probably be lookin
I know that this is really old, but I don't see any reply to this, and I
thought that I would respond so that, if nothing else, the archive will
contain the answer.
If you grab the source code and look at the WXS files for the extensions you
will see that many of the custom actions have @Overridab
17 matches
Mail list logo
