http://wixtoolset.org/documentation/manual/v3/wixui/dialog_reference/wixui_installdir.html
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945 8500
F: +44 (0)141 945 8501
http://www.iesve.com
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456
http://wixtoolset.org/documentation/manual/v3/xsd/wix/customaction.html
See the 'Impersonate' attribute.
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945 8500
F: +44 (0)141 945 8501
http://www.iesve.com
Integrated Environmental Solutions Limited. Registered in Scotland No.
Dear WiX users,
I am getting an Error 1723. There is a problem with this Windows
Installer package. A DLL required for this install to complete could not
be run. Contact your support personnel or package vendor when I try and
run a custom action to xcopy some config files during my
Why are you using xcopy at all? CopyFile is a thing which exists -
http://wixtoolset.org/documentation/manual/v3/xsd/wix/copyfile.html
And then your files will be part of uninstall/rollback/upgrade etc without any
extra work.
Palbinder Sandher
Software Platform Engineer
T: +44 (0)141 945
I am still trying to understand this problem, so any pointers would be
appreciated.
I am using the wix38-debug zip package, pdbs and source, to step into burn
with windbg. The issue seems to show up in src\burn\engine\apply.cpp in the
AcquireContainerOrPayload at line 1117.
// If
On 7/6/2014 10:57 AM, Dolevo Jay wrote:
Hi,
I have an installer in WIX. I have tried to deploy it to a group of target
computers in the network and encountered the following issue. The deployment
was successful but there is an issue when the installer launches the
application after the
Hello,
I'm quite new to WIX so apologies if this is a common gotcha
I have a windows service that I install via WIX.
To do this I used this blog post as a guide:
http://www.chrissurfleet.co.uk/post/2011/08/04/Creating-windows-service-installer-with-Visual-Studio-and-WiX.aspx
In short the
I have a Wix Bootstrapper which conditionally installs various components,
which are defaulted to not install unless a command line parameter is sent.
This works fine on the initial install, but when I attempt to perform an
upgrade, the command line parameters do not seem to be being read. It also
Well, the log indicates that Burn is uninstalling. What are the version
numbers for the initial and upgrade installs?
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
The original version was 6.0.0.0 and the new one was 6.0.0.1
Sent with AquaMail for Android
http://www.aqua-mail.com
On July 7, 2014 11:13:07 AM John Cooper jocoo...@jackhenry.com wrote:
Well, the log indicates that Burn is uninstalling. What are the version
numbers for the initial and
The fourth quad is ignored, which means the versions are effectively the same
generating the behavior you're experiencing. Only the first three quads are
considered by the installer service. So, 6.0.0.0 and 6.0.1.0 would have
worked but 6.0.0.0 and 6.0.0.1 never will.
--
John Merryweather
Hello,
You can try to use :
C:\Program Files\Windows Installer XML v3.5\bin\heat.exe file MyAddin.dll
-ag -template fragment -out path\for\desired\location\MyAddin.wxs
instead of :
C:\Program Files\Windows Installer XML v3.5\bin\heat.exe file MyAddin.dll
-ag -template fragment -out MyAddin.wxs
Hello,
If the GUID are created via an wxs file, how do you create this file?
Using this example- the -ag parameter makes guid on compile time, the guids
ramian the same for the same installer.
C:\Program Files\Windows Installer XML v3.5\bin\heat.exe file MyAddin.dll
-ag -template fragment -out
I just attempted to do this with version 6.0.1.0 from 6.0.0.0, and nothing
changed. Progress text displays previous version and all files from
previous install are removed, but no new files are installed.
Logs are attached (The one ending in 0_compuweigh is the MSI)
On Mon, Jul 7, 2014 at 11:20
Same ProductCode or a different ProductCode for each installer? You can find
the ProductCode with Orca in the Property table. If they're the same, you're
not setup for major upgrade.
--
John Merryweather Cooper
Build Install Engineer – ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS
Burn Bootstrappers do not have a ProductCode, do they?
The MSI Setup project has its product code set to *, and upgrades fine if
not run through the bootstrapper.
On Mon, Jul 7, 2014 at 11:52 AM, John Cooper jocoo...@jackhenry.com wrote:
Same ProductCode or a different ProductCode for each
No, they don't. So, that's no it. Do you the MajorUpgrade element or the
Upgrade table? What do the entries look like?
--
John Merryweather Cooper
Build Install Engineer – ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
Thanks for the moral support. I found the core cause of the problem, in my
mba ResolveSource code. So the problem was not related to the Atom or the
web server configuration. Thanks to everyone who contributed to Wix and
the great appsyndication features.
--
View this message in context:
It might be worth noting that after installing the bootstrapper, if i try
and install the same package and click repair, that it will fix the install
that never happened for the MSI, and that MSI will be the new version that
should have been installed in the first place. It is only when I attempt
Yes, that's an important clue. For most of your assemblies, do they differ
only in the fourth quad between the initial install and the upgrade?
--
John Merryweather Cooper
Build Install Engineer – ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
I just have the one Setup Project which is installed via my bootstrapper,
the other items are other installable items such as SQL Server and other
things that the software depends on. Since you telling me that the fourth
quad is ignored, I have been testing installs by incrementing the third
quad
Sadly I am suffering from a failing laptop, so my wix souce access is a bit
limited. You may have luck taking a look at
http://wix.codeplex.com/SourceControl/network/forks/jchoover/Wix/latest?branch=SelfUpdate.2
under .\test\data\JacobH\AtomParse, and seeing if you can merge that folder
across
Piping in a little later here, as had no requirements for PowerShell custom
actions but now do.
Our product team is developing a Server app and require a bunch of
PowerShell actions to be ran, some only require triggering commands that are
used to log server info, but others are more
I apologize for the double response, but as stated previously, the
bootstrapper is not reading command line arguments (which are used to
satisfy InstallConditions) only when I am trying to upgrade, and though
right now I am hard-coding INSTALLCW6=1 (the installcondition for the msi i
am trying to
The problem with running PowerShell directly is that the default execution
policy on many servers is Restricted. Which means not a jot of your script
will run. If you can guarantee yourself that you'll always be running on
systems with Unrestricted, Signed, or RemoteSigned, then your
Well, the bootstrapper will only accept command line line arguments that are:
1) declared as Variable and 2) marked with bal:Overrideable=yes attributes.
--
John Merryweather Cooper
Build Install Engineer – ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434
Yes, but it also applies to the assemblies within. If the installer service
doesn't think the assemblies are different, no update for each individual
assembly will occur.
--
John Merryweather Cooper
Build Install Engineer – ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office:
Sorry for the out of sync messages, hate web based mail... It sounds like the
atom feed is working , are you stil having issues with the update?
Note: The self updating bundle code didn't get accepted till 3.9, and there
were several bug fixes since the initial 3.8 version. You might want to
It is still removing all of the old assemblies, though, and all of the
components of the MSI that were not created via a custom action.
My command line arguments are both declared as variables and markes as
overrideable.
On Mon, Jul 7, 2014 at 2:38 PM, John Cooper jocoo...@jackhenry.com wrote:
Thanks for the information John.
I'll prompt the developers on if they know what modes the servers will be
ran under, but I would figure that it would be Restricted.
I do not have much/any experience in creating C#, so are you suggesting a
wrapper .exe or custom action dll, which would therefore
A C# custom action CA.dll
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: TimM [mailto:timmay...@smarttech.com]
Sent:
Just realized my parameters are being passed.. I was just being stupid, so my
apologies there. The issue in regards to upgrading still remains however,
where the installed files from the previous install are removed in my
attempt to upgrade, but the new files are not added.
--
View this message
Jacob, thank you for the posts! I had noticed the discussion about
self-updating bundles and the changes in 3.9. After some testing I
determined that this problem was not related to the atom feed. As soon as I
finish testing these changes, then I plan to migrate to 3.9. The root
problem was
I think this has been answered but in case this is read later this is not true
for WiX bundles they do use the forth quad. Also, within an MSI the forth quad
is used when comparing file versions, the only place it is not used is the MSI
itself.
Neil
-Original Message-
From: John
As far as I know that's only true for MSI product versions, not for
bootstrapper versions.
--
Nicolas
2014-07-07 12:20 GMT-03:00 John Cooper jocoo...@jackhenry.com:
The fourth quad is ignored, which means the versions are effectively the same
generating the behavior you're experiencing.
Yes, I was referring to the MSI (although I generally setup my bootstrappers to
have a version matching the primary MSI).
--
John Merryweather Cooper
Build Install Engineer - jXchange
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
36 matches
Mail list logo
