Wix 3.5.1721 was tested today. Failed to add defaultDocument - error
disappeared. Also full uninstall doesn't remove all existing virtual dirs,
but still I get errors during upgrade. Attached is part of upgrade log -
please help what is the reason?
Action 09:34:46: StartIIS7ConfigTransaction.
1. You can try code like this:
Directory Id=TARGETDIR Name=SourceDir
Directory Id=INSTALL_LOCATION Name=MyTool FileSource=.
/Directory
/Directory
Property Id=WIXUI_INSTALLDIR Value=INSTALL_LOCATION /
UIRef Id=WixUI_PaymentSystem /
Actually I'm not sure whether this code will
I've just checked Heat in WiX 3.5. It also ignores Copy Local property
of referenced assemblies.
My conclusion: at the moment there is no way to harvest referenced
assemblies using heat.exe with the project mode.
Ilya Serbis
On 17.05.2010 14:57, Илья Сербис wrote:
Hi Matt,
I've
Here are the verbose log snippet on the component states
MSI (s) (80:D8) [14:49:58:457]: Component: C_FL_apc.exe; Installed: Local;
Request: Absent; Action: Absent; Client State: Local
MSI (s) (80:D8) [14:49:58:457]: Component: ServiceExeComponent; Installed:
Local; Request: Absent;
I also notice that I see this behavior after introducing upgrade specific
actions (RemoveExistingProducts) as part of the InstallExecuteSequence.
And I do not have the KeyPath set for any components. Will that cause an
issue like this??
-
Andy
BuildDeployment
Schneider Electric
--
View
Hello,
I get this error message:
heat.exe : error HEAT5055 : Error applying transform file.xslt to
harvested WiX: Execution of the 'document()' function was prohibited.
Use the XsltSettings.EnableDocumentFunction property to enable it. An
error occurred at..
Is there a way to quickly
Hi,
This is typical behaviour I have seen before. The Msi will be
setting the environment variable by api call, what this will not be
doing is updating the environment of the running process and as Nick
says the batch file will probably be a child of the msi process that
called it.
I
I got the root cause of the issue.
I had a condition that is evaluating the Component out. :)
-
Andy
BuildDeployment
Schneider Electric
--
View this message in context:
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
The title reflects the strangeness of the problem that I am trying to solve. It
is not WiX specific but in the broader install community there is higher chance
that somebody may have had similar experience.
It starts with user installing vcredist_x86.exe on his Windows 7 64-bit. He is
sharing
In WiX 3.5 I've found new version of RegistrySearch:
http://wix.sourceforge.net/manual-wix3/util_xsd_registrysearch.htm
Looks like it can manage with empty keys. Unfortunately it's not
finished yet and I had problems to use it. Specifically I couldn't get
it worked inside Product.
On
Shut down System Protection and try ?
-Original Message-
From: Tony Juricic [mailto:tjuri...@tradestation.com]
Sent: Monday, May 24, 2010 5:39 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Do UFOs visit Install land?
The title reflects the strangeness of the problem that I
Hi all,
I have noticed that if I have a deferred custom action in vbscript, I can
reference properties using Session.PropertyPropertyname). But, in a c#
deferred custom action using the session object, that same property is not
available to me using session[Propertyname]. The c# ca's seem to
The Condition table is designed for enabling/disabling which features get
installed at install-time. It sounds like your intent is to control which
features get included into your various MSIs at build-time. For your
situation the use of shared install code would enable you to have a similar
That is correct, the is an open bug report for this:
http://sourceforge.net/tracker/?func=detailaid=2998492group_id=105970;
atid=642714.
Neil
-Original Message-
From: Ilya [mailto:iser...@shtrih-m.ru]
Sent: 24 May 2010 08:43
To: General discussion for Windows Installer XML toolset.
I'm trying to use WixUI_InstallDir as my UI, and when I do, and compile it,
and run it, I get the following message in the MSI log:
The installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 2343. The
arguments are:
The three solutions in order of speed are:
1. Edit/recompile WixUtilExtension.dll to enable the document() XSLT
function. (Source file appears to be UtilTransformMutator.cs)
2. Change your transform to eliminate the use of the Document function.
3. Open a bug with the WiX team to enable the
Have you set
Property Id=WIXUI_INSTALLDIR Value=INSTALLDIR /
?
From the looks of
Property(C): WIXUI_INSTALLDIR = TOP_LEVEL_DIR
you haven't.
See http://wix.sourceforge.net/manual-wix3/WixUI_installdir.htm
Palbinder Sandher
Software Deployment IT Administrator
T: +44 (0) 141 945 8500
F: +44
This would place MyTool on the fixed drive with the largest free space at
the time of installation (see
http://blogs.msdn.com/heaths/archive/2007/07/12/installing-to-targetdir.aspx
).
Since http://msdn.microsoft.com/library/aa372817.aspx says to not use
WindowsVolume in the directory table, what
It is the KeyPath for the component containing the shortcut. See Ilya's
answer for that. Shortcuts cannot (unfortunately) be KeyPaths and there is
an ICE test that more-or-less demands that shortcut's have an HKCU registry
as their keypath. The content of the registry doesn't matter, so use your
Aw man! Pally! You rock!
Thanks for the quick response - That fixed it!
I was confused by the tutorial here:
http://www.tramontana.co.hu/wix/lesson2.php
I put Property Id=WIXUI_INSTALLDIR Value=TOP_LEVEL_DIR /
because I saw in this tutorial that it was needed if I used
WixUI_InstallDir!
According to http://msdn.microsoft.com/library/aa370543.aspx deferred custom
actions, both those written in script and those that compiled, can only
access the following three properties: CustomActionData, ProductCode, or
UserSID. If you are seeing different, it is a happy error in the version of
In the tutorial, TOP_LEVEL_DIR is a placeholder for the directory's name
that is the top level directory of your installation.
-Original Message-
From: gapearce [mailto:mr_gapea...@yahoo.com]
Sent: Monday, May 24, 2010 11:03 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users]
Thanks Blair! You are very helpful.
I did see that link, but was hoping it was wrong because I'm able to get any
property using the vbscript ca's. Thanks for the warning about different
platforms. We test on several, but I'll probably get bit with that eventually,
so I will make changes to
The C++ runtimes are very specific about what they want. You didn't say what
versions you're referring to, but there are people have installed VC++ 2008
redist thinking it will support their VC++ 2005 app (it won't), and, for
example, if you have built with VC++ 2008 SP1 the RTM VC++ 2008
OH! Duh! (Sheesh!)
Thanks - that makes sense.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Trying-to-keep-it-simple-WixUI-InstallDir-error-2343-tp5094719p5095087.html
Sent from the wix-users mailing list archive at Nabble.com.
The RTM 3.0 wix.targets file contains the UsingTask element for that task.
Verify that your wix.targets file is not corrupted.
-Original Message-
From: Andrew Hammond [mailto:andrew.george.hamm...@gmail.com]
Sent: Thursday, May 20, 2010 4:47 PM
To: General discussion for Windows
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
Hi Phil,
Here are the missing context and details.
The app is 32 bit. It was built with C++ redistributables version
9.0.30729.4148. Exactly the same vcredist_x86.exe, that was installed on a
build machine before RTM build, is run on end user's machine, before the
application-specific MSI
I've followed the instructions in WiX.chm to the T, and also used the code
from the tutorial (http://www.tramontana.co.hu/wix/lesson4.php#4.1) - using
this code here
(http://www.tramontana.co.hu/wix/download.php?file=samples/sampleupgrade.ziptype=application/zip).
I cannot for the life of me get
First cut: normally once you designate an UpgradeCode for whatever
represents a product, you never change it. Always use the same UpgradeCode
(Product/@Upgrade value) between your products that are intended to replace
each other/be mutually exclusive.
-Original Message-
From: fragorl
Blair-2 - thanks for your reply, and that'll be exactly what the problem is.
So one UpgradeCode Guid for all versions of one product? And I assume that
by having different ones, I've essentially told windows installer that each
msi represents an entirely different product. That will explain the
Hi guys,
I have created a WiX 3.5 project in VS2010 and added a few project references.
One of the projects is a WCF IIS project. Wix has automatically generated the
following Product.Generated.wxs file:
?xml version='1.0' encoding='UTF-8'?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
33 matches
Mail list logo