You should change the component code if the destination of the component
changes, as documented here:
http://msdn.microsoft.com/en-us/library/aa367849(v=vs.85).aspx
Changing the component code is incompatible with minor/small updates; since
you're talking about a patch and a major upgrade patch is
Try the UPGRADINGPRODUCTCODE property[1] as well as the property associated
with your Major Upgrade[2]. There's no need for all the custom actions. The
Major Upgrade property is set for the version to be installed and the
UPGRADINGPRODUCTCODE property is set for the version that is being
upgrad
The only restriction is that no two installations can be in their execute
sequence at the same time. Installing something silently more or less jumps
straight to the execute sequence.
-Original Message-
From: Prantik Sarmah [mailto:prantik.sar...@grapecity.com]
Sent: Thursday, April 24,
ong, I just know how it feels when a
relatively easy task turns into a mountain...
Quoting Bryan Wolf :
> As far as I'm aware, neither FileSearch, DirectorySearch, RemoveFile
> or RemoveFileEx can target Assemblies because the paths to them are
> generated and the FileKeys d
ber.html
and then if the Installed file >= N remove said file and replace with N - 1
Carter
Quoting Bryan Wolf :
> The issue was fixed in MSI 5.0 or if you install the hotfix
> (http://support.microsoft.com/kb/972397/EN-US), but that won't help
> him because he's do
MigrateFeatureState capability.
---
Phil Wilson
On Tue, Apr 22, 2014 at 7:11 AM, Bryan Wolf wrote:
> The always overwrite flag in InstallShield just sets the FileVersion column
> to 65535.0.0.0. WiX has the DefaultVersion field, which should duplicate the
> experience. Alternativ
The always overwrite flag in InstallShield just sets the FileVersion column to
65535.0.0.0. WiX has the DefaultVersion field, which should duplicate the
experience. Alternatively, just modify the MSI post-build for this one-off. It
would be easier if you were not using an assembly file because y
time of upgrade. this "unlocker" exe removes it)
1. is there a way to run the copy files twice? once to copy all that can be
copied, run the unlocker and then copy again?
2. or Johns suggestion of streaming the exe out...how would I go about that?
3. or could a separate element wor
ion, but I want to understand something.
In an upgrade of a non-binary (non-versioned) files how does windows installer
know to keep the file on the system and not replace it with its empty file
contained in the MSI.
Thanks for the info,
Marc
-Original Message-----
From: Bryan Wolf [
Files are copied as part of an atomic step. Technically they are staged
somewhere during the copy but it's nothing you could meaningfully interact
with. There is no "OnFileCopy" type functionality, either.
Is there a reason you couldn't run the unlock CA before InstallFiles and just
attempt to
t involve any code except changing
the app to update existing files rather than create them, assuming a late REP
works for the product upgrade.
---
Phil Wilson
On Thu, Apr 17, 2014 at 9:32 AM, Bryan Wolf wrote:
> You could also schedule the RemoveExistingProducts action later in the
You could also schedule the RemoveExistingProducts action later in the
sequence. You lose several advantages of major upgrades and pretty much
absolutely have to follow component rules closely as if it were a minor/small
upgrade but it is an alternative to the preserve & restore pattern.
Altern
It's clear your catch handler is being called because of the EXCEPTION property
being set. You're probably having an exception in the course of handling the
exception. In general, having things that can throw exceptions in catch blocks
(especially unreliable things such as File I/O access) is no
on.Database.Execute("UPDATE `SqlDatabase` SET `SqlDatabase`.`User_` =
NULL")
But this fails with 'Function failed during execution. Database: Table(s)
Update failed.'.
On Thu, Mar 13, 2014 at 10:57 AM, Bryan Wolf wrote:
> The core of this issue might be that you'
__
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Bryan Wolf [mailto:brw...@jackhenry.com]
Sent: Thursday, March 13, 2014 8:32 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Conditional SSP
n
a machine that may not have it?
Levi
On Thu, Mar 13, 2014 at 10:57 AM, Bryan Wolf wrote:
> The core of this issue might be that you're trying to create the database.
>
> But while the WiX SQL Custom Actions are good for one-offs like what
> John wrote, I think you'll fi
The core of this issue might be that you're trying to create the database.
But while the WiX SQL Custom Actions are good for one-offs like what John
wrote, I think you'll find them not adequate for modern day database apps -
especially in the creation world - unless you're creating some type of
The sample that Harold Wood posted is for MSI dialogs, not the burn
bootstrapper. The standard bootstrapper is very limited in what it can do,
unfortunately. Most of which is pretty hard coded.
The Wix installer (in the burn solution) is a good sample on how to quickly
write your own if somethi
based destination directory (like MyApp.1.1.1 instead of just
> MyApp) accomplish at least most of what Pavan wants?
> On Mar 6, 2014 3:20 PM, "Bryan Wolf" wrote:
>
>> My thoughts were more focused on what the product actually supports
>> in terms of side-by-sid
re no longer at an n! problem but just a nice linear n :-)
-Original Message-
From: Bryan Wolf
Sent: Friday, March 7, 2014 3:03 PM
To: General discussion about the WiX toolset.
Subject: RE: [WiX-users] Upgrade and side by side with the same installer
This solution would also require a numb
aller(even though the product is only a Windows only deployment), which is
a complete different technology. I am in the process of changing the IA
installer to WIX.
--Pavan
-Original Message-
From: Bryan Wolf [mailto:brw...@jackhenry.com]
Sent: Thursday, March 06, 2014 12:07 PM
To: Ge
Another way of looking at what John is suggesting is considering that you
probably want to take a step back a moment and focus more on version 3 and less
on version 2. You're looking at some sort of super-linear number of
installations you're going to have to support; all those permutations on t
The Launch Target command just calls shell execute with the "open" verb on
whatever you pass it, so in theory a URL should just work, no? I don't see
anything that would explicitly cause it to fail in an obvious way.
-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.co
To pile on: where I work that pattern would fail promptly on many of our
machines because VBScript is disabled by GP.
There's a (rather accurate) ranting of Rob's on these CAs here:
http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx and, as someone
who has had to support installatio
I've been playing with the burn bootstrappers and my only thought on this is
that the options page has a lot of background work that's done and may not be
the best page to overload. On the flip side, I think the mba basically hard
codes the installation path.
Tbh, until/unless someone writes a
t
for Windows 7 and above (with the programfiles routing to appdata/programs.
But I have to support XP and Vista as well.
I will now try to ignore ICE38 and see if that fixes the issues.
Thanks.
Wes
-Original Message-----
From: Bryan Wolf [mailto:brw...@jackhenry.com]
Sent: Febru
ing-ICE38-error-td712044.html.
So looks like not a good idea to ignore it.
Wes
-Original Message-----
From: Bryan Wolf [mailto:brw...@jackhenry.com]
Sent: February-11-14 6:15 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Using advertised shortcuts/progid in per user
Since that is the case, ICE38 is (in my opinion) incorrect and you will want to
ignore it. ICE38 implies you are installing per-user resources in the context
of a per-machine installation but never verifies that this is so.
Actually authoring a per-user install requires that you ignore ICE38 be
28 matches
Mail list logo
