[WiX-users] HowTo check for pressed Cancel Button in Custom Action
Hi, HowTo check for pressed Cancel Button in Custom Action ? Wichtiger Hinweis: Diese E-Mail und etwa angeh?ngte Dateien k?nnen vertrauliche Informationen enthalten und sind ausschlie?lich f?r den/die Adressaten bestimmt. Sollten Sie irrt?mlich diese E-Mail erhalten haben, bitten wir Sie, uns dar?ber zu informieren und die E-Mail aus Ihrem System zu l?schen. Das unerlaubte Kopieren und die unbefugte Weitergabe dieser Mail und ihrer Inhalte sind nicht gestattet. Important notice: This email and some of the attached files can contain confidential information and are intended solely for the addressee. Should you have received this email in error, we ask that you inform us about this and delete the email from your system. The illegal copying and unauthorised re-distribution of this email and its contents are not permitted. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] HowTo check for pressed Cancel Button in Custom Action
iResult = MsiProcessMessage(hInstall, INSTALLMESSAGE_PROGRESS, hProgressRec); if ((iResult == IDCANCEL)) return ERROR_INSTALL_USEREXIT; http://msdn.microsoft.com/en-us/library/aa367525(v=vs.85).aspx -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/HowTo-check-for-pressed-Cancel-Button-in-Custom-Action-tp7594248p7594249.html Sent from the wix-users mailing list archive at Nabble.com. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major upgrade removing files
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 you could just
author a RemoveFile table entry associated with the component and it would
actually cover all bases. But I'm not sure RemoveFile or RemoveFileEx can help
you with assemblies - seems like the answer is "No".
Down-versioning files is always a rough experience. The third party case is
always an especially nasty one; sometimes that's where something like Burn
might be able to help or a custom bootstrapper to just purge the old version
before-hand giving you a clean slate.
-Original Message-
From: kirannhegde [mailto:kirann.he...@gmail.com]
Sent: Monday, April 21, 2014 11:30 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Major upgrade removing files
Hello ,
Here is my scenario:
A higher version installer contains lower version of certain binaries . In
the higher versioned installer, sequencing "RemoveExistingProducts"
after "InstallInitialize" results in missing files. This is an issue with
Windows Installer service and has been around since 2002.
I see the following entires in the log file:
Here is a snippet from the Merlin RTM windows installer log file:
MSI (s) (48:F0) [07:39:20:997]: skipping installation of assembly component:
{3C582984-7607-3E35-A337-D3D327097351} since the assembly already exists MSI
(s) (48:F0) [07:39:21:001]: skipping installation of assembly component:
{6D321E57-3E99-3B87-BF23-2CDFF3361CB4} since the assembly already exists MSI
(s) (48:F0) [07:39:21:003]: skipping installation of assembly component:
{229E8F96-1AE0-32E6-8428-D2CBCA122740} since the assembly already exists MSI
(s) (48:F0) [07:39:21:006]: skipping installation of assembly component:
{AE56AAF5-F3C0-3D4B-8859-A1E50A3E27BF} since the assembly already exists MSI
(s) (48:F0) [07:39:21:024]: Disallowing installation of component:
{4D2EB851-13AC-500F-9704-AB78102F8D0F} since the same component with higher
versioned keyfile exists MSI (s) (48:F0) [07:39:21:029]: skipping installation
of assembly component:
{F2F5F3C2-7A2E-58A8-81FB-6D05B2446DC5} since the assembly already exists MSI
(s) (48:F0) [07:39:21:032]: skipping installation of assembly component:
{084F57E8-E40B-5B1E-AABC-7F0A7B77D223} since the assembly already exists MSI
(s) (48:F0) [07:39:21:035]: skipping installation of assembly component:
{5DF9A9B3-8FBE-57C1-95AE-D08C44084A77} since the assembly already exists MSI
(s) (48:F0) [07:39:21:041]: skipping installation of assembly component:
{F703FAD2-5314-5C11-B7B3-AA960D6CB678} since the assembly already exists MSI
(s) (48:F0) [07:39:21:043]: skipping installation of assembly component:
{FB288044-FD6A-5A2C-BE23-BD941E55B184} since the assembly already exists MSI
(s) (48:F0) [07:39:21:046]: skipping installation of assembly component:
{7DF41602-3F0E-5FED-BC1B-3E55EB39E439} since the assembly already exists MSI
(s) (48:F0) [07:39:21:049]: skipping installation of assembly component:
{F1A4761C-24F2-5A42-9BAE-B9E3AFFA9F51} since the assembly already exists MSI
(s) (48:F0) [07:39:21:056]: skipping installation of assembly component:
{9ED4023C-789C-5FB2-B8AD-19FE3B0B816F} since the assembly already exists MSI
(s) (48:F0) [07:39:21:195]: skipping installation of assembly component:
{EA346F23-593F-5D59-9605-5B764FC05873} since the assembly already exists MSI
(s) (48:F0) [07:39:21:199]: skipping installation of assembly component:
{3CAED2EB-627D-52F7-AD44-7138E03EE961} since the assembly already exists
To solve this, i have come across the following suggestions:
-Schedule "RemoveExistingProducts" earlier in the sequence, even before
costing i.e before CostInitialize.However, doing that violates the guidelines
laid out by MSDN. MSDN suggests a sequencing between InstallValidate and
Install Initialize as one of the positions.
InstallValidate is sequenced after costing. Hence, even though this solution
might work, this is a violation of Microsoft rules
-Use REINSTALLMODE = emus
-Force the file to be always overwritten - Not feasible for Wix. Only exists
in InstallShield
-Version - Handle the versions properly in the higher versions of the
installer.
I agree that having higher versions of the files in the higher versioned
installer is the easiest and safest approach. However, there could be genuine
cases where you might want to include lower versions of certain binaires in a
highver verison of your product. This is common with third
party binaries.
So how do you think that this should be handled?
As usual, any assistance is very much appreciated.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Major-upgrade-removing-files-tp7594245.html
Sent from the wix-users mailin
Re: [WiX-users] Major upgrade removing files
This shouldn't apply to later MSI engines - according this KB article
it shouldn't be a problem if you make sure you have at least MSI 4.0,
or ship the 4.5 redist.
http://support.microsoft.com/kb/905238/en-us
but I vaguely remember the original MSI needs installing with a
correct MSI engine too, not too sure on that.
I had a call with MS support a while back on that proposed fix of
sequencing REP before CostInitialize and they said it would be ok. But
you will lose 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. Alternatively, just modify the MSI post-build for this one-off.
> It would be easier if you were not using an assembly file because you could
> just author a RemoveFile table entry associated with the component and it
> would actually cover all bases. But I'm not sure RemoveFile or RemoveFileEx
> can help you with assemblies - seems like the answer is "No".
>
> Down-versioning files is always a rough experience. The third party case is
> always an especially nasty one; sometimes that's where something like Burn
> might be able to help or a custom bootstrapper to just purge the old version
> before-hand giving you a clean slate.
>
> -Original Message-
> From: kirannhegde [mailto:kirann.he...@gmail.com]
> Sent: Monday, April 21, 2014 11:30 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Major upgrade removing files
>
> Hello ,
>
> Here is my scenario:
>
> A higher version installer contains lower version of certain binaries . In
> the higher versioned installer, sequencing "RemoveExistingProducts"
> after "InstallInitialize" results in missing files. This is an issue with
> Windows Installer service and has been around since 2002.
>
> I see the following entires in the log file:
>
> Here is a snippet from the Merlin RTM windows installer log file:
> MSI (s) (48:F0) [07:39:20:997]: skipping installation of assembly component:
> {3C582984-7607-3E35-A337-D3D327097351} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:001]: skipping installation of assembly component:
> {6D321E57-3E99-3B87-BF23-2CDFF3361CB4} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:003]: skipping installation of assembly component:
> {229E8F96-1AE0-32E6-8428-D2CBCA122740} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:006]: skipping installation of assembly component:
> {AE56AAF5-F3C0-3D4B-8859-A1E50A3E27BF} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:024]: Disallowing installation of component:
> {4D2EB851-13AC-500F-9704-AB78102F8D0F} since the same component with higher
> versioned keyfile exists MSI (s) (48:F0) [07:39:21:029]: skipping
> installation of assembly component:
> {F2F5F3C2-7A2E-58A8-81FB-6D05B2446DC5} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:032]: skipping installation of assembly component:
> {084F57E8-E40B-5B1E-AABC-7F0A7B77D223} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:035]: skipping installation of assembly component:
> {5DF9A9B3-8FBE-57C1-95AE-D08C44084A77} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:041]: skipping installation of assembly component:
> {F703FAD2-5314-5C11-B7B3-AA960D6CB678} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:043]: skipping installation of assembly component:
> {FB288044-FD6A-5A2C-BE23-BD941E55B184} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:046]: skipping installation of assembly component:
> {7DF41602-3F0E-5FED-BC1B-3E55EB39E439} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:049]: skipping installation of assembly component:
> {F1A4761C-24F2-5A42-9BAE-B9E3AFFA9F51} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:056]: skipping installation of assembly component:
> {9ED4023C-789C-5FB2-B8AD-19FE3B0B816F} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:195]: skipping installation of assembly component:
> {EA346F23-593F-5D59-9605-5B764FC05873} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:199]: skipping installation of assembly component:
> {3CAED2EB-627D-52F7-AD44-7138E03EE961} since the assembly already exists
>
>
>
> To solve this, i have come across the following suggestions:
> -Schedule "RemoveExistingProducts" earlier in the sequence, even before
> costing i.e before CostInitialize.However, doing that violates the
> guidelines laid out by MSDN. MSDN suggests a sequencing between
> InstallValidate and Install Initialize as one of the positions.
> InstallValidate is sequenced after costing. Hence, even though this solution
> might work, this is a violation of Microsoft rules
>
> -Use REINSTALLMODE = emus
>
> -Force the file to be always overwritten - Not feasible for
Re: [WiX-users] Major upgrade removing files
Dit mailadres is niet meer in gebruik. Mail kan je voortaan sturen naar basti...@careercontrol.nl. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn: different bundles, same msi package - not detected
I have two different products/bundles that install different versions of the same msi package. I had expected that the bundle would detect the existing installation of the msi and log it as an upgrade, but instead it's logging it as "absent" and the subsequent execution of the package runs the upgrade anyway. I'm using WiX 3.9.203.0. Is this expected with different bundles, or should the msi package be found by both? -- Bruce -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major upgrade removing files
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 down-revving a versioned file. Even if it remains after the major upgrade,
it will still be version (n) and not (n - 1).
To be honest, I think sequencing REP before CostInitialize is probably the only
"good" answer for assemblies. As a warning: sequencing REP before
CostInitialize does cause an ICE27 error.
-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com]
Sent: Tuesday, April 22, 2014 11:04 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Major upgrade removing files
This shouldn't apply to later MSI engines - according this KB article it
shouldn't be a problem if you make sure you have at least MSI 4.0, or ship the
4.5 redist.
http://support.microsoft.com/kb/905238/en-us
but I vaguely remember the original MSI needs installing with a correct MSI
engine too, not too sure on that.
I had a call with MS support a while back on that proposed fix of sequencing
REP before CostInitialize and they said it would be ok. But you will lose
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. Alternatively, just modify the MSI post-build for this one-off.
> It would be easier if you were not using an assembly file because you could
> just author a RemoveFile table entry associated with the component and it
> would actually cover all bases. But I'm not sure RemoveFile or RemoveFileEx
> can help you with assemblies - seems like the answer is "No".
>
> Down-versioning files is always a rough experience. The third party case is
> always an especially nasty one; sometimes that's where something like Burn
> might be able to help or a custom bootstrapper to just purge the old version
> before-hand giving you a clean slate.
>
> -Original Message-
> From: kirannhegde [mailto:kirann.he...@gmail.com]
> Sent: Monday, April 21, 2014 11:30 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Major upgrade removing files
>
> Hello ,
>
> Here is my scenario:
>
> A higher version installer contains lower version of certain binaries . In
> the higher versioned installer, sequencing "RemoveExistingProducts"
> after "InstallInitialize" results in missing files. This is an issue with
> Windows Installer service and has been around since 2002.
>
> I see the following entires in the log file:
>
> Here is a snippet from the Merlin RTM windows installer log file:
> MSI (s) (48:F0) [07:39:20:997]: skipping installation of assembly component:
> {3C582984-7607-3E35-A337-D3D327097351} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:001]: skipping installation of assembly component:
> {6D321E57-3E99-3B87-BF23-2CDFF3361CB4} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:003]: skipping installation of assembly component:
> {229E8F96-1AE0-32E6-8428-D2CBCA122740} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:006]: skipping installation of assembly component:
> {AE56AAF5-F3C0-3D4B-8859-A1E50A3E27BF} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:024]: Disallowing installation of component:
> {4D2EB851-13AC-500F-9704-AB78102F8D0F} since the same component with higher
> versioned keyfile exists MSI (s) (48:F0) [07:39:21:029]: skipping
> installation of assembly component:
> {F2F5F3C2-7A2E-58A8-81FB-6D05B2446DC5} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:032]: skipping installation of assembly component:
> {084F57E8-E40B-5B1E-AABC-7F0A7B77D223} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:035]: skipping installation of assembly component:
> {5DF9A9B3-8FBE-57C1-95AE-D08C44084A77} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:041]: skipping installation of assembly component:
> {F703FAD2-5314-5C11-B7B3-AA960D6CB678} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:043]: skipping installation of assembly component:
> {FB288044-FD6A-5A2C-BE23-BD941E55B184} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:046]: skipping installation of assembly component:
> {7DF41602-3F0E-5FED-BC1B-3E55EB39E439} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:049]: skipping installation of assembly component:
> {F1A4761C-24F2-5A42-9BAE-B9E3AFFA9F51} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:056]: skipping installation of assembly component:
> {9ED4023C-789C-5FB2-B8AD-19FE3B0B816F} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:195]: skipping installation of assembly component:
> {EA346F23-593F-5D59-9605-5B764FC05873} since the assembly already exists MSI
> (s) (48:F0) [07:39:21:199]: skipping installa
Re: [WiX-users] Major upgrade removing files
I may be talking out the side of my mouth here,, but why cant he
remove version N doing a version check like so:
http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/check_the_version_number.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 down-revving a versioned file. Even if it remains
> after the major upgrade, it will still be version (n) and not (n - 1).
>
> To be honest, I think sequencing REP before CostInitialize is
> probably the only "good" answer for assemblies. As a warning:
> sequencing REP before CostInitialize does cause an ICE27 error.
>
> -Original Message-
> From: Phil Wilson [mailto:phildgwil...@gmail.com]
> Sent: Tuesday, April 22, 2014 11:04 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Major upgrade removing files
>
> This shouldn't apply to later MSI engines - according this KB
> article it shouldn't be a problem if you make sure you have at least
> MSI 4.0, or ship the 4.5 redist.
>
> http://support.microsoft.com/kb/905238/en-us
>
> but I vaguely remember the original MSI needs installing with a
> correct MSI engine too, not too sure on that.
>
> I had a call with MS support a while back on that proposed fix of
> sequencing REP before CostInitialize and they said it would be ok.
> But you will lose 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. Alternatively, just
>> modify the MSI post-build for this one-off. It would be easier if
>> you were not using an assembly file because you could just author a
>> RemoveFile table entry associated with the component and it would
>> actually cover all bases. But I'm not sure RemoveFile or
>> RemoveFileEx can help you with assemblies - seems like the answer
>> is "No".
>>
>> Down-versioning files is always a rough experience. The third party
>> case is always an especially nasty one; sometimes that's where
>> something like Burn might be able to help or a custom bootstrapper
>> to just purge the old version before-hand giving you a clean slate.
>>
>> -Original Message-
>> From: kirannhegde [mailto:kirann.he...@gmail.com]
>> Sent: Monday, April 21, 2014 11:30 PM
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] Major upgrade removing files
>>
>> Hello ,
>>
>> Here is my scenario:
>>
>> A higher version installer contains lower version of certain binaries . In
>> the higher versioned installer, sequencing "RemoveExistingProducts"
>> after "InstallInitialize" results in missing files. This is an
>> issue with Windows Installer service and has been around since
>> 2002.
>>
>> I see the following entires in the log file:
>>
>> Here is a snippet from the Merlin RTM windows installer log file:
>> MSI (s) (48:F0) [07:39:20:997]: skipping installation of assembly component:
>> {3C582984-7607-3E35-A337-D3D327097351} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:001]: skipping installation of
>> assembly component:
>> {6D321E57-3E99-3B87-BF23-2CDFF3361CB4} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:003]: skipping installation of
>> assembly component:
>> {229E8F96-1AE0-32E6-8428-D2CBCA122740} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:006]: skipping installation of
>> assembly component:
>> {AE56AAF5-F3C0-3D4B-8859-A1E50A3E27BF} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:024]: Disallowing installation of
>> component:
>> {4D2EB851-13AC-500F-9704-AB78102F8D0F} since the same component
>> with higher versioned keyfile exists MSI (s) (48:F0)
>> [07:39:21:029]: skipping installation of assembly component:
>> {F2F5F3C2-7A2E-58A8-81FB-6D05B2446DC5} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:032]: skipping installation of
>> assembly component:
>> {084F57E8-E40B-5B1E-AABC-7F0A7B77D223} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:035]: skipping installation of
>> assembly component:
>> {5DF9A9B3-8FBE-57C1-95AE-D08C44084A77} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:041]: skipping installation of
>> assembly component:
>> {F703FAD2-5314-5C11-B7B3-AA960D6CB678} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:043]: skipping installation of
>> assembly component:
>> {FB288044-FD6A-5A2C-BE23-BD941E55B184} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:046]: skipping installation of
>> assembly component:
>> {7DF41602-3F0E-5FED-BC1B-3E55EB39E439} since the assembly alrea
Re: [WiX-users] Major upgrade removing files
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 don't point to those assembly paths.
Otherwise it would be easy to just do a Remove File table entry and all will
work "automagically" including update, uninstall, rollback, etc. with the note
that you'll always end up reinstalling that file (desirable) and skip the
search entirely.
-Original Message-
From: Carter Young [mailto:ecyo...@grandecom.net]
Sent: Tuesday, April 22, 2014 2:18 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Major upgrade removing files
I may be talking out the side of my mouth here,, but why cant he remove version
N doing a version check like so:
http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/check_the_version_number.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 down-revving a versioned file. Even if it remains
> after the major upgrade, it will still be version (n) and not (n - 1).
>
> To be honest, I think sequencing REP before CostInitialize is probably
> the only "good" answer for assemblies. As a warning:
> sequencing REP before CostInitialize does cause an ICE27 error.
>
> -Original Message-
> From: Phil Wilson [mailto:phildgwil...@gmail.com]
> Sent: Tuesday, April 22, 2014 11:04 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Major upgrade removing files
>
> This shouldn't apply to later MSI engines - according this KB article
> it shouldn't be a problem if you make sure you have at least MSI 4.0,
> or ship the 4.5 redist.
>
> http://support.microsoft.com/kb/905238/en-us
>
> but I vaguely remember the original MSI needs installing with a
> correct MSI engine too, not too sure on that.
>
> I had a call with MS support a while back on that proposed fix of
> sequencing REP before CostInitialize and they said it would be ok.
> But you will lose 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. Alternatively, just modify the MSI
>> post-build for this one-off. It would be easier if you were not using
>> an assembly file because you could just author a RemoveFile table
>> entry associated with the component and it would actually cover all
>> bases. But I'm not sure RemoveFile or RemoveFileEx can help you with
>> assemblies - seems like the answer is "No".
>>
>> Down-versioning files is always a rough experience. The third party
>> case is always an especially nasty one; sometimes that's where
>> something like Burn might be able to help or a custom bootstrapper to
>> just purge the old version before-hand giving you a clean slate.
>>
>> -Original Message-
>> From: kirannhegde [mailto:kirann.he...@gmail.com]
>> Sent: Monday, April 21, 2014 11:30 PM
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] Major upgrade removing files
>>
>> Hello ,
>>
>> Here is my scenario:
>>
>> A higher version installer contains lower version of certain binaries . In
>> the higher versioned installer, sequencing "RemoveExistingProducts"
>> after "InstallInitialize" results in missing files. This is an
>> issue with Windows Installer service and has been around since
>> 2002.
>>
>> I see the following entires in the log file:
>>
>> Here is a snippet from the Merlin RTM windows installer log file:
>> MSI (s) (48:F0) [07:39:20:997]: skipping installation of assembly component:
>> {3C582984-7607-3E35-A337-D3D327097351} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:001]: skipping installation of
>> assembly component:
>> {6D321E57-3E99-3B87-BF23-2CDFF3361CB4} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:003]: skipping installation of
>> assembly component:
>> {229E8F96-1AE0-32E6-8428-D2CBCA122740} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:006]: skipping installation of
>> assembly component:
>> {AE56AAF5-F3C0-3D4B-8859-A1E50A3E27BF} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:024]: Disallowing installation of
>> component:
>> {4D2EB851-13AC-500F-9704-AB78102F8D0F} since the same component with
>> higher versioned keyfile exists MSI (s) (48:F0)
>> [07:39:21:029]: skipping installation of assembly component:
>> {F2F5F3C2-7A2E-58A8-81FB-6D05B2446DC5} since the assembly already
>> exists MSI (s) (48:F0) [07:39:21:032]: skipping installation of
>> assembly component:
>> {084F57E8-E40B-5B1E-AABC-7F0A7B77D223} since the assembly already
>> exists MSI (s) (48:F0) [07
Re: [WiX-users] Major upgrade removing files
Dobt all Assemblies get added to the GAC though?? Then use the Version
Search to Search the GAC. Could be totally wrong, 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 don't point to those assembly paths.
>
> Otherwise it would be easy to just do a Remove File table entry and
> all will work "automagically" including update, uninstall, rollback,
> etc. with the note that you'll always end up reinstalling that file
> (desirable) and skip the search entirely.
>
> -Original Message-
> From: Carter Young [mailto:ecyo...@grandecom.net]
> Sent: Tuesday, April 22, 2014 2:18 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Major upgrade removing files
>
> I may be talking out the side of my mouth here,, but why cant he
> remove version N doing a version check like so:
>
> http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/check_the_version_number.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 down-revving a versioned file. Even if it remains
>> after the major upgrade, it will still be version (n) and not (n - 1).
>>
>> To be honest, I think sequencing REP before CostInitialize is probably
>> the only "good" answer for assemblies. As a warning:
>> sequencing REP before CostInitialize does cause an ICE27 error.
>>
>> -Original Message-
>> From: Phil Wilson [mailto:phildgwil...@gmail.com]
>> Sent: Tuesday, April 22, 2014 11:04 AM
>> To: General discussion about the WiX toolset.
>> Subject: Re: [WiX-users] Major upgrade removing files
>>
>> This shouldn't apply to later MSI engines - according this KB article
>> it shouldn't be a problem if you make sure you have at least MSI 4.0,
>> or ship the 4.5 redist.
>>
>> http://support.microsoft.com/kb/905238/en-us
>>
>> but I vaguely remember the original MSI needs installing with a
>> correct MSI engine too, not too sure on that.
>>
>> I had a call with MS support a while back on that proposed fix of
>> sequencing REP before CostInitialize and they said it would be ok.
>> But you will lose 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. Alternatively, just modify the MSI
>>> post-build for this one-off. It would be easier if you were not using
>>> an assembly file because you could just author a RemoveFile table
>>> entry associated with the component and it would actually cover all
>>> bases. But I'm not sure RemoveFile or RemoveFileEx can help you with
>>> assemblies - seems like the answer is "No".
>>>
>>> Down-versioning files is always a rough experience. The third party
>>> case is always an especially nasty one; sometimes that's where
>>> something like Burn might be able to help or a custom bootstrapper to
>>> just purge the old version before-hand giving you a clean slate.
>>>
>>> -Original Message-
>>> From: kirannhegde [mailto:kirann.he...@gmail.com]
>>> Sent: Monday, April 21, 2014 11:30 PM
>>> To: wix-users@lists.sourceforge.net
>>> Subject: [WiX-users] Major upgrade removing files
>>>
>>> Hello ,
>>>
>>> Here is my scenario:
>>>
>>> A higher version installer contains lower version of certain binaries . In
>>> the higher versioned installer, sequencing "RemoveExistingProducts"
>>> after "InstallInitialize" results in missing files. This is an
>>> issue with Windows Installer service and has been around since
>>> 2002.
>>>
>>> I see the following entires in the log file:
>>>
>>> Here is a snippet from the Merlin RTM windows installer log file:
>>> MSI (s) (48:F0) [07:39:20:997]: skipping installation of assembly
>>> component:
>>> {3C582984-7607-3E35-A337-D3D327097351} since the assembly already
>>> exists MSI (s) (48:F0) [07:39:21:001]: skipping installation of
>>> assembly component:
>>> {6D321E57-3E99-3B87-BF23-2CDFF3361CB4} since the assembly already
>>> exists MSI (s) (48:F0) [07:39:21:003]: skipping installation of
>>> assembly component:
>>> {229E8F96-1AE0-32E6-8428-D2CBCA122740} since the assembly already
>>> exists MSI (s) (48:F0) [07:39:21:006]: skipping installation of
>>> assembly component:
>>> {AE56AAF5-F3C0-3D4B-8859-A1E50A3E27BF} since the assembly already
>>> exists MSI (s) (48:F0) [07:39:21:024]: Disallowing installation of
>>> component:
>>> {4D2EB851-13AC-500F-9704-AB78102F8D0F} since the same component with
>>> higher versioned keyfile exists MSI (s
Re: [WiX-users] Major upgrade removing files
They could also be in the WinSxS directory but yes. I just generally would consider traversing the GAC as if it were a directory structure worse than just setting the FileVersion or rescheduling REP before CostFinalize because you can't guarantee that Microsoft doesn't decide to reorganize the whole structure or move it somewhere else ( see also: the thousands of complaints they get about its size even though it's a misreported size ). Not to mention you're not really supposed to just yank things out of the GAC or Win32 assembly stores. -Original Message- From: Carter Young [mailto:ecyo...@grandecom.net] Sent: Tuesday, April 22, 2014 2:54 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Major upgrade removing files Dobt all Assemblies get added to the GAC though?? Then use the Version Search to Search the GAC. Could be totally wrong, 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 don't point to those assembly paths. > > Otherwise it would be easy to just do a Remove File table entry and > all will work "automagically" including update, uninstall, rollback, > etc. with the note that you'll always end up reinstalling that file > (desirable) and skip the search entirely. > > -Original Message- > From: Carter Young [mailto:ecyo...@grandecom.net] > Sent: Tuesday, April 22, 2014 2:18 PM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Major upgrade removing files > > I may be talking out the side of my mouth here,, but why cant he > remove version N doing a version check like so: > > http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registr > y/check_the_version_number.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 down-revving a versioned file. Even if it remains >> after the major upgrade, it will still be version (n) and not (n - 1). >> >> To be honest, I think sequencing REP before CostInitialize is >> probably the only "good" answer for assemblies. As a warning: >> sequencing REP before CostInitialize does cause an ICE27 error. >> >> -Original Message- >> From: Phil Wilson [mailto:phildgwil...@gmail.com] >> Sent: Tuesday, April 22, 2014 11:04 AM >> To: General discussion about the WiX toolset. >> Subject: Re: [WiX-users] Major upgrade removing files >> >> This shouldn't apply to later MSI engines - according this KB article >> it shouldn't be a problem if you make sure you have at least MSI 4.0, >> or ship the 4.5 redist. >> >> http://support.microsoft.com/kb/905238/en-us >> >> but I vaguely remember the original MSI needs installing with a >> correct MSI engine too, not too sure on that. >> >> I had a call with MS support a while back on that proposed fix of >> sequencing REP before CostInitialize and they said it would be ok. >> But you will lose 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. Alternatively, just modify the MSI >>> post-build for this one-off. It would be easier if you were not >>> using an assembly file because you could just author a RemoveFile >>> table entry associated with the component and it would actually >>> cover all bases. But I'm not sure RemoveFile or RemoveFileEx can >>> help you with assemblies - seems like the answer is "No". >>> >>> Down-versioning files is always a rough experience. The third party >>> case is always an especially nasty one; sometimes that's where >>> something like Burn might be able to help or a custom bootstrapper >>> to just purge the old version before-hand giving you a clean slate. >>> >>> -Original Message- >>> From: kirannhegde [mailto:kirann.he...@gmail.com] >>> Sent: Monday, April 21, 2014 11:30 PM >>> To: wix-users@lists.sourceforge.net >>> Subject: [WiX-users] Major upgrade removing files >>> >>> Hello , >>> >>> Here is my scenario: >>> >>> A higher version installer contains lower version of certain binaries . In >>> the higher versioned installer, sequencing "RemoveExistingProducts" >>> after "InstallInitialize" results in missing files. This is an >>> issue with Windows Installer service and has been around since >>> 2002. >>> >>> I see the following entires in the log file: >>> >>> Here is a snippet from the Merlin RTM windows installer log file: >>> MSI (s) (48:F0) [07:39:20:997]: skipping installation of assembly
Re: [WiX-users] Major upgrade removing files
Good Call, ill crawl back to my corner now lol :) Quoting Bryan Wolf : > They could also be in the WinSxS directory but yes. > > I just generally would consider traversing the GAC as if it were a > directory structure worse than just setting the FileVersion or > rescheduling REP before CostFinalize because you can't guarantee > that Microsoft doesn't decide to reorganize the whole structure or > move it somewhere else ( see also: the thousands of complaints they > get about its size even though it's a misreported size ). Not to > mention you're not really supposed to just yank things out of the > GAC or Win32 assembly stores. > > -Original Message- > From: Carter Young [mailto:ecyo...@grandecom.net] > Sent: Tuesday, April 22, 2014 2:54 PM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Major upgrade removing files > > Dobt all Assemblies get added to the GAC though?? Then use the > Version Search to Search the GAC. Could be totally wrong, 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 don't point to those assembly paths. >> >> Otherwise it would be easy to just do a Remove File table entry and >> all will work "automagically" including update, uninstall, rollback, >> etc. with the note that you'll always end up reinstalling that file >> (desirable) and skip the search entirely. >> >> -Original Message- >> From: Carter Young [mailto:ecyo...@grandecom.net] >> Sent: Tuesday, April 22, 2014 2:18 PM >> To: wix-users@lists.sourceforge.net >> Subject: Re: [WiX-users] Major upgrade removing files >> >> I may be talking out the side of my mouth here,, but why cant he >> remove version N doing a version check like so: >> >> http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registr >> y/check_the_version_number.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 down-revving a versioned file. Even if it remains >>> after the major upgrade, it will still be version (n) and not (n - 1). >>> >>> To be honest, I think sequencing REP before CostInitialize is >>> probably the only "good" answer for assemblies. As a warning: >>> sequencing REP before CostInitialize does cause an ICE27 error. >>> >>> -Original Message- >>> From: Phil Wilson [mailto:phildgwil...@gmail.com] >>> Sent: Tuesday, April 22, 2014 11:04 AM >>> To: General discussion about the WiX toolset. >>> Subject: Re: [WiX-users] Major upgrade removing files >>> >>> This shouldn't apply to later MSI engines - according this KB article >>> it shouldn't be a problem if you make sure you have at least MSI 4.0, >>> or ship the 4.5 redist. >>> >>> http://support.microsoft.com/kb/905238/en-us >>> >>> but I vaguely remember the original MSI needs installing with a >>> correct MSI engine too, not too sure on that. >>> >>> I had a call with MS support a while back on that proposed fix of >>> sequencing REP before CostInitialize and they said it would be ok. >>> But you will lose 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. Alternatively, just modify the MSI post-build for this one-off. It would be easier if you were not using an assembly file because you could just author a RemoveFile table entry associated with the component and it would actually cover all bases. But I'm not sure RemoveFile or RemoveFileEx can help you with assemblies - seems like the answer is "No". Down-versioning files is always a rough experience. The third party case is always an especially nasty one; sometimes that's where something like Burn might be able to help or a custom bootstrapper to just purge the old version before-hand giving you a clean slate. -Original Message- From: kirannhegde [mailto:kirann.he...@gmail.com] Sent: Monday, April 21, 2014 11:30 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Major upgrade removing files Hello , Here is my scenario: A higher version installer contains lower version of certain binaries . In the higher versioned installer, sequencing "RemoveExistingProducts" after "InstallInitialize" results in missing files. This is an issue with Windows Installer service and has been around since 2002. >>>
Re: [WiX-users] Major upgrade removing files
Folks,
Thanks for all the responses.
This issue happens even with normal files(not just assemblies)
MSI (s) (48:F0) [07:39:21:024]: Disallowing installation of component:
{4D2EB851-13AC-500F-9704-AB78102F8D0F} since the same component with higher
versioned keyfile exists
I dont want to implement a solution on a case by case basis. I want a
generic solution which once implemented continues to work for any file, if
that file has to be downgraded.
Sequencing REP seems the most appropriate at the moment.
Regards,
Kiran Hegde
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Major-upgrade-removing-files-tp7594245p7594268.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major upgrade removing files
Dit mailadres is niet meer in gebruik. Mail kan je voortaan sturen naar basti...@careercontrol.nl. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
