Re: [WiX-users] Upgrading an older version of product

[Neil Sleightholm]

I am not sure this will work but it is worth a try. Change you v2 upgrade code 
then add this:
  


What this does is detect any version of the old product and always remove it.
 
Neil
 
Neil Sleightholm
X2 Systems Limited
n...@x2systems.com  
 



From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@microsoft.com]
Sent: Thu 02/04/2009 01:40
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading an older version of product



Thanks Phil.
Your have hit the bullseye. You are right. I saw the log and it seemed the 
ALLUSERS property which was the reason. Using ORCA I added ALLUSERS as a new 
row in the property table and set its value to 1. After that the upgrade worked 
perfectly.

So, now my next question is... Is there any way to remove the older version 
even if the ALLUSERS property is different for the two versions? The old MSI 
was created by some other guy and has been deployed to many machines. I have to 
use ALLUSERS as 1 in my new setup. Is there any way to uninstall the old 
product?


Thanks.
Sudripta.






Re: [WiX-users] Upgrading an older version of 
product
From: Wilson, Phil  - 2009-04-02 00:09

It's nothing to do with the same user account. It's about the value of the 
MSI's ALLUSERS property. If you didn't set it before then it defaulted to a 
per-user install. Your current setup is a per system install with ALLUSERS=1 
that will not upgrade the other version. Produce a log while doing the upgrade 
and see what FindRelatedProducts reports.

It's not important that ARPNOMDIFY is different. It is important that ALLUSERS 
is different.

Phil Wilson


-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...]
Sent: Wednesday, April 01, 2009 4:53 PM
To: wix-us...@li...
Subject: Re: [WiX-users] Upgrading an older version of product

The older version hadn't any ALLUSERS value set. The new version has ALLUSERS 
set to 1. But, I am installing both the versions from the same user account and 
it's still failing.

One more important aspect is that the older version had 'ARPNOMODIFY' set to 1. 
But, it hadn't any 'ARPNOREMOVE' property. The new version hasn't got any of 
the property.


Thanks.
Sudripta.




Re: [WiX-users] Upgrading an older version of 
product
From: Wilson, Phil  - 2009-04-01 23:38

. and are the ALLUSERS values the same? I believe there's a permachine / 
perUser choice but the MSI default is per user I believe.
Phil Wilson


-Original Message-
From: Jim Williams [mailto:jimwilliam...@co...]
Sent: Wednesday, April 01, 2009 4:21 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrading an older version of product

Do you have a RemoveExistingProducts action defined in your execution sequence?

Jim Williams

-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...]
Sent: Wednesday, April 01, 2009 4:03 PM
To: wix-us...@li...
Subject: [WiX-users] Upgrading an older version of product

I have two versions of my MSI... one is version 1.0.0.0 and another is
2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many
significant differences between version 1.0.0.0 and 2.0.1000.0, including
different install directories and files-to-install. Version 1.0.0.0 installs
under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program
Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0
except the upgrade code.

But, even when the upgrade codes are same, version 2.0.1000.0 is unable to
detect the previous version '1.0.0.0'. I have the following element defined
within my wix file:





But, seems the old version is not getting removed/replaced by the new version.
The new version installs/uninstalls as a separate product.


What am I doing wrong?


Thanks.
Sudripta.
--
___
WiX-users mailing list
wix-us...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
wix-us...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
wix-us...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list

[WiX-users] set-up a redirect for a WebVirtualDir element using WiX

[sunil bisoyi]

Hi

 I want to create a  virtual directory that performs a redirect only.

You can set this up in IIS by right-clicking on the virtual directory,
viewing properties and then going to the Virtual Directory tab and
selecting “A redirection to a URL” and then defining the value.
this step is manual  is it possible to do this programmatically through WiX?





-- 
Regards,

Sunil Bisoyi
Ignify,Inc.
"Excellence in  Technology"
Tel: +91(20)66218120
Fax: +91(20)66218199
Mob-+91-9373138655
Email:sunil.bis...@ignify.com
 sunilbis...@gmail.com

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] .Net Framework question

[Andy2k8]

Does .Net framework vary across languages?
Can I use the same Dotnetfx.exe to install .Net framework on different language 
OSs?

-
Andy
MSI Developer
Schneider Electric:working:
-- 
View this message in context: 
http://n2.nabble.com/.Net-Framework-question-tp2573430p2573430.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] extracting wix xml from wixlibs

[Brian Rogers]

Adam,

I wouldn't suggest going about it this way. If there is a change to the way
WIX generates the Lib files this could impact you. The XML/Binary format is
not documented short of looking through the code itself.

However, from a built MSI you could use dark.exe to decompile it into WIX
Source.

Thanks,

Brian Rogers
"Intelligence removes complexity." - Me
http://icumove.spaces.live.com


On Tue, Mar 31, 2009 at 7:48 PM, Adam Langley wrote:

> Hi,
>
> I am writing a tool to make it easier to create custom WiX dialogs, can
> someone tell me how I would go about extracting the wix dialog files (i.e.
> WelcomeDlg.wxs) from the UI wixlib?
> I realise that I could just obtain these files from the source code, but I
> don't want to have to require our team members to extract the source code
> when the WiX binaries are already on the system...
>
> Thanks
>
> Adam Langley
> Senior Developer
> Tel: +64 9 486 9010
> www.winscribe.com
>
>
>
>
>
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat missing some RegistryValue elements (Programmable) from VB6 code?

[Brian Rogers]

Hey Roy,

If you are still able to reproduce this please file a bug in heat and upload
the DLL. I would recommend that the DLL ONLY contain required information to
reproduce the issue IF possible.

Thanks,

Brian Rogers
"Intelligence removes complexity." - Me
http://icumove.spaces.live.com


On Wed, Apr 1, 2009 at 5:07 PM, Roy Abou Assaly  wrote:

>
> Hi,
> No, I was using version 11.34.  The same one attached in the email.  I just
> redownloaded the DLL I had attached to you and ran it in 3.0.5120.0...still
> the same exception.  Strange.
>
> On Wed, Apr 1, 2009 at 3:36 PM, Neil Sleightholm (via Nabble) <
> ml-user+58265-122838...@n2.nabble.com
> 
> >
> > wrote:
>
> > I just tried this again and didn't see an error, has the dll changed from
> > the one you sent me?
> >
> > Neil
> >
> > Neil Sleightholm
> > X2 Systems Limited
> > n...@...<
> http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2571127&i=0
> > > n...@...<
> http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2571127&i=1>>
> >
> >
> >
> > 
> >
> > From: Roy Abou Assaly [mailto:royass...@...<
> http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2571127&i=2>]
> >
> > Sent: Wed 01/04/2009 14:39
> > To: wix-us...@...<
> http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2571127&i=3>
>  > Subject: Re: [WiX-users] Heat missing some RegistryValue elements
> > (Programmable) from VB6 code?
> >
> >
> >
> >
> >
> > I have just tried the latest version 3.0.5120.0 and the programmable
> > attribute on is set for your dll on the ClassId e.g.
> >
> >  > Description="PRISMXMLEditor.XMLChunk" Version="12.3" Programmable="yes">
> >
> > If you are not already you may also want to try the -svb6 option with
> > Heat as that will remove the VB6 runtime properties that are not
> > required (see help file).
> >
> > Neil
> >
> >
> > Hi Neil and Roger,
> >
> > I just ran heat 3.0.5120.0 and got this error:
> >
> > D:\lab\WiX\XMLEditor>heat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out
> > result.xml
> > Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5120.0
> > Copyright (C) Microsoft Corporation. All rights reserved.
> >
> > heat.exe : error HEAT0001 : Item has already been added. Key in
> dictionary:
> > 'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}\ProxyStubClsid/'  Key
> > being added: 'Interface\{0B7F3153-C8E7-4E6
> > D-AEBE-B6D61D78B9A3}\ProxyStubClsid/'
> >
> > Exception Type: System.ArgumentException
> >
> > Stack Trace:
> >at System.Collections.SortedList.Add(Object key, Object value)
> >at
> >
> Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.MutateComponents()
> >
> >at
> >
> Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.Mutate(Wix
> > wix)
> >at Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)
> >at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)
> >
> > Then I ran 3.0.4923.0
> >
> > D:\lab\WiX\XMLEditor>heat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out
> > result.xml
> > Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.4923.0
> > Copyright (C) Microsoft Corporation. All rights reserved.
> >
> > And yes, you're right.  Programmable is set as an attribute of Class
> rather
> > than being created in RegistryValue.  I'm going to assume that those 2
> are
> > the equivalent?  Can you confirm this?  If that is true, I will stick
> with
> > 3.0.4923.0 since it works and I have tested the builds with this version.
> >  That's basically where I got confused.  I saw that I was missing
> > RegistryValue elements and figured that certain keys were being missing.
> >
> > Do you still want me to open a bug Roger?  Although, this time it would
> be
> > for another Reason.  Also, how did it manage to run heat 3.0.5120.0 on
> your
> > machine Neil?  I hope it's not the dreaded "It runs on my machine" bug :)
> >
> > Thanks guys
> > --
> > View this message in context:
> >
> http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2569042.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> >
> >
> --
> >
> > ___
> > WiX-users mailing list
> > wix-us...@...<
> http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2571127&i=4>
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
> --
> >
> >
> > ___
> > WiX-users mailing list
> > wix-us...@...<
> http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2571127&i=5>
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > --
> >  View message @
> >
> http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2571127.html
> >

Re: [WiX-users] Upgrading an older version of product

[Sudripta Nandy (Sarangsoft Corporation)]

Thanks Phil.
Your have hit the bullseye. You are right. I saw the log and it seemed the 
ALLUSERS property which was the reason. Using ORCA I added ALLUSERS as a new 
row in the property table and set its value to 1. After that the upgrade worked 
perfectly.

So, now my next question is... Is there any way to remove the older version 
even if the ALLUSERS property is different for the two versions? The old MSI 
was created by some other guy and has been deployed to many machines. I have to 
use ALLUSERS as 1 in my new setup. Is there any way to uninstall the old 
product?


Thanks.
Sudripta.






Re: [WiX-users] Upgrading an older version of 
product
From: Wilson, Phil  - 2009-04-02 00:09

It's nothing to do with the same user account. It's about the value of the 
MSI's ALLUSERS property. If you didn't set it before then it defaulted to a 
per-user install. Your current setup is a per system install with ALLUSERS=1 
that will not upgrade the other version. Produce a log while doing the upgrade 
and see what FindRelatedProducts reports.

It's not important that ARPNOMDIFY is different. It is important that ALLUSERS 
is different.

Phil Wilson


-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...]
Sent: Wednesday, April 01, 2009 4:53 PM
To: wix-us...@li...
Subject: Re: [WiX-users] Upgrading an older version of product

The older version hadn't any ALLUSERS value set. The new version has ALLUSERS 
set to 1. But, I am installing both the versions from the same user account and 
it's still failing.

One more important aspect is that the older version had 'ARPNOMODIFY' set to 1. 
But, it hadn't any 'ARPNOREMOVE' property. The new version hasn't got any of 
the property.


Thanks.
Sudripta.




Re: [WiX-users] Upgrading an older version of 
product
From: Wilson, Phil  - 2009-04-01 23:38

. and are the ALLUSERS values the same? I believe there's a permachine / 
perUser choice but the MSI default is per user I believe.
Phil Wilson


-Original Message-
From: Jim Williams [mailto:jimwilliam...@co...]
Sent: Wednesday, April 01, 2009 4:21 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrading an older version of product

Do you have a RemoveExistingProducts action defined in your execution sequence?

Jim Williams

-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...]
Sent: Wednesday, April 01, 2009 4:03 PM
To: wix-us...@li...
Subject: [WiX-users] Upgrading an older version of product

I have two versions of my MSI... one is version 1.0.0.0 and another is
2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many
significant differences between version 1.0.0.0 and 2.0.1000.0, including
different install directories and files-to-install. Version 1.0.0.0 installs
under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program
Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0
except the upgrade code.

But, even when the upgrade codes are same, version 2.0.1000.0 is unable to
detect the previous version '1.0.0.0'. I have the following element defined
within my wix file:





But, seems the old version is not getting removed/replaced by the new version.
The new version installs/uninstalls as a separate product.


What am I doing wrong?


Thanks.
Sudripta.
--
___
WiX-users mailing list
wix-us...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
wix-us...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
wix-us...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] how to configure windows service recovery behavior

[Zhisheng Huang]

Hi,

Could anyone please help on how to configure windows service recovery behavior 
in wix?

The recovery behavior refers to the Recovery tab of a windows service from 
management console, like
  First failure: Take No Action | Restart the service | Run a program | 
restart the computer
  Second failure: Take No Action | Restart the service | Run a program 
| restart the computer
  Subsequent failure: Take No Action | Restart the service | Run a 
program | restart the computer
  Reset fail count after: ? days
  Restart service after: ? minutes

Thanks a lot for help!
Zhisheng


  

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat missing some RegistryValue elements (Programmable) from VB6 code?

[Roy Abou Assaly]

Hi,
No, I was using version 11.34.  The same one attached in the email.  I just
redownloaded the DLL I had attached to you and ran it in 3.0.5120.0...still
the same exception.  Strange.

On Wed, Apr 1, 2009 at 3:36 PM, Neil Sleightholm (via Nabble) <
ml-user+58265-122838...@n2.nabble.com
> wrote:

> I just tried this again and didn't see an error, has the dll changed from
> the one you sent me?
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> n...@... n...@...>
>
>
>
> 
>
> From: Roy Abou Assaly 
> [mailto:royass...@...]
>
> Sent: Wed 01/04/2009 14:39
> To: 
> wix-us...@...
> Subject: Re: [WiX-users] Heat missing some RegistryValue elements
> (Programmable) from VB6 code?
>
>
>
>
>
> I have just tried the latest version 3.0.5120.0 and the programmable
> attribute on is set for your dll on the ClassId e.g.
>
>  Description="PRISMXMLEditor.XMLChunk" Version="12.3" Programmable="yes">
>
> If you are not already you may also want to try the -svb6 option with
> Heat as that will remove the VB6 runtime properties that are not
> required (see help file).
>
> Neil
>
>
> Hi Neil and Roger,
>
> I just ran heat 3.0.5120.0 and got this error:
>
> D:\lab\WiX\XMLEditor>heat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out
> result.xml
> Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5120.0
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> heat.exe : error HEAT0001 : Item has already been added. Key in dictionary:
> 'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}\ProxyStubClsid/'  Key
> being added: 'Interface\{0B7F3153-C8E7-4E6
> D-AEBE-B6D61D78B9A3}\ProxyStubClsid/'
>
> Exception Type: System.ArgumentException
>
> Stack Trace:
>at System.Collections.SortedList.Add(Object key, Object value)
>at
> Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.MutateComponents()
>
>at
> Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.Mutate(Wix
> wix)
>at Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)
>at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)
>
> Then I ran 3.0.4923.0
>
> D:\lab\WiX\XMLEditor>heat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out
> result.xml
> Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.4923.0
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> And yes, you're right.  Programmable is set as an attribute of Class rather
> than being created in RegistryValue.  I'm going to assume that those 2 are
> the equivalent?  Can you confirm this?  If that is true, I will stick with
> 3.0.4923.0 since it works and I have tested the builds with this version.
>  That's basically where I got confused.  I saw that I was missing
> RegistryValue elements and figured that certain keys were being missing.
>
> Do you still want me to open a bug Roger?  Although, this time it would be
> for another Reason.  Also, how did it manage to run heat 3.0.5120.0 on your
> machine Neil?  I hope it's not the dreaded "It runs on my machine" bug :)
>
> Thanks guys
> --
> View this message in context:
> http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2569042.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
>
> ___
> WiX-users mailing list
> wix-us...@...
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
>
>
> ___
> WiX-users mailing list
> wix-us...@...
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
>  View message @
> http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2571127.html
> To unsubscribe from Heat missing some RegistryValue elements (Programmable)
> from VB6 code?, click here< (link removed) >.
>
>
>

-- 
View this message in context: 
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2572340.html
Sent from the wix-users mailing list archive at Nabble.com.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrading an older version of product

[Wilson, Phil]

It's nothing to do with the same user account. It's about the value of the 
MSI's ALLUSERS property. If you didn't set it before then it defaulted to a 
per-user install. Your current setup is a per system install with ALLUSERS=1 
that will not upgrade the other version.  Produce a log while doing the upgrade 
and see what FindRelatedProducts reports. 

It's not important that ARPNOMDIFY is different. It is important that ALLUSERS 
is different. 

Phil Wilson 


-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@microsoft.com] 
Sent: Wednesday, April 01, 2009 4:53 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Upgrading an older version of product

The older version hadn't any ALLUSERS value set. The new version has ALLUSERS 
set to 1. But, I am installing both the versions from the same user account and 
it's still failing.

One more important aspect is that the older version had 'ARPNOMODIFY' set to 1. 
But, it hadn't any 'ARPNOREMOVE' property. The new version hasn't got any of 
the property.


Thanks.
Sudripta.




Re: [WiX-users] Upgrading an older version of 
product
From: Wilson, Phil  - 2009-04-01 23:38

. and are the ALLUSERS values the same? I believe there's a permachine / 
perUser choice but the MSI default is per user I believe.
Phil Wilson


-Original Message-
From: Jim Williams [mailto:jimwilliam...@co...]
Sent: Wednesday, April 01, 2009 4:21 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrading an older version of product

Do you have a RemoveExistingProducts action defined in your execution sequence?

Jim Williams

-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...]
Sent: Wednesday, April 01, 2009 4:03 PM
To: wix-us...@li...
Subject: [WiX-users] Upgrading an older version of product

I have two versions of my MSI... one is version 1.0.0.0 and another is
2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many
significant differences between version 1.0.0.0 and 2.0.1000.0, including
different install directories and files-to-install. Version 1.0.0.0 installs
under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program
Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0
except the upgrade code.

But, even when the upgrade codes are same, version 2.0.1000.0 is unable to
detect the previous version '1.0.0.0'. I have the following element defined
within my wix file:





But, seems the old version is not getting removed/replaced by the new version.
The new version installs/uninstalls as a separate product.


What am I doing wrong?


Thanks.
Sudripta.
--
___
WiX-users mailing list
wix-us...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
wix-us...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrading an older version of product

[Karl Denning]

Hi


Have you remembered to add "SecureCustomProperties" to your property table?
(Or does candle/light do that for you??)


K.



Yes, I have the following element defined within InstallExecuteSequence of 
version 2.0.1000.0.




Another thing is that in the new version of the product, I have completely new 
components with different IDs. Also the files-to install and the target 
directory are different. Another important thing is that the product name is 
also different in the new version. The only similarity between the two versions 
is the upgrade code.


Thanks.
Sudripta.



-- 
View this message in context: 
http://n2.nabble.com/Upgrading-an-older-version-of-product-tp2572133p2572316.html
Sent from the wix-users mailing list archive at Nabble.com.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrading an older version of product

[Sudripta Nandy (Sarangsoft Corporation)]

The older version hadn't any ALLUSERS value set. The new version has ALLUSERS 
set to 1. But, I am installing both the versions from the same user account and 
it's still failing.

One more important aspect is that the older version had 'ARPNOMODIFY' set to 1. 
But, it hadn't any 'ARPNOREMOVE' property. The new version hasn't got any of 
the property.


Thanks.
Sudripta.




Re: [WiX-users] Upgrading an older version of 
product
From: Wilson, Phil  - 2009-04-01 23:38

. and are the ALLUSERS values the same? I believe there's a permachine / 
perUser choice but the MSI default is per user I believe.
Phil Wilson


-Original Message-
From: Jim Williams [mailto:jimwilliam...@co...]
Sent: Wednesday, April 01, 2009 4:21 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrading an older version of product

Do you have a RemoveExistingProducts action defined in your execution sequence?

Jim Williams

-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...]
Sent: Wednesday, April 01, 2009 4:03 PM
To: wix-us...@li...
Subject: [WiX-users] Upgrading an older version of product

I have two versions of my MSI... one is version 1.0.0.0 and another is
2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many
significant differences between version 1.0.0.0 and 2.0.1000.0, including
different install directories and files-to-install. Version 1.0.0.0 installs
under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program
Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0
except the upgrade code.

But, even when the upgrade codes are same, version 2.0.1000.0 is unable to
detect the previous version '1.0.0.0'. I have the following element defined
within my wix file:





But, seems the old version is not getting removed/replaced by the new version.
The new version installs/uninstalls as a separate product.


What am I doing wrong?


Thanks.
Sudripta.
--
___
WiX-users mailing list
wix-us...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
wix-us...@li...
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrading an older version of product

[Sudripta Nandy (Sarangsoft Corporation)]

Yes, I have the following element defined within InstallExecuteSequence of 
version 2.0.1000.0.




Another thing is that in the new version of the product, I have completely new 
components with different IDs. Also the files-to install and the target 
directory are different. Another important thing is that the product name is 
also different in the new version. The only similarity between the two versions 
is the upgrade code.


Thanks.
Sudripta.




Re: [WiX-users] Upgrading an older version of 
product
From: Jim Williams  - 2009-04-01 23:19

Do you have a RemoveExistingProducts action defined in your execution sequence?

Jim Williams

-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@mi...]
Sent: Wednesday, April 01, 2009 4:03 PM
To: wix-us...@li...
Subject: [WiX-users] Upgrading an older version of product

I have two versions of my MSI... one is version 1.0.0.0 and another is
2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many
significant differences between version 1.0.0.0 and 2.0.1000.0, including
different install directories and files-to-install. Version 1.0.0.0 installs
under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program
Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0
except the upgrade code.

But, even when the upgrade codes are same, version 2.0.1000.0 is unable to
detect the previous version '1.0.0.0'. I have the following element defined
within my wix file:





But, seems the old version is not getting removed/replaced by the new version.
The new version installs/uninstalls as a separate product.


What am I doing wrong?


Thanks.
Sudripta.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrading an older version of product

[Wilson, Phil]

. and are the ALLUSERS values the same? I believe there's a permachine / 
perUser choice but the MSI default is per user I believe. 
Phil Wilson 


-Original Message-
From: Jim Williams [mailto:jimwilliam...@comcast.net] 
Sent: Wednesday, April 01, 2009 4:21 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrading an older version of product

Do you have a RemoveExistingProducts action defined in your execution sequence?

Jim Williams

-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@microsoft.com] 
Sent: Wednesday, April 01, 2009 4:03 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrading an older version of product

I have two versions of my MSI... one is version 1.0.0.0 and another is
2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many
significant differences between version 1.0.0.0 and 2.0.1000.0, including
different install directories and files-to-install. Version 1.0.0.0 installs
under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program
Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0
except the upgrade code.

But, even when the upgrade codes are same, version 2.0.1000.0 is unable to
detect the previous version '1.0.0.0'. I have the following element defined
within my wix file:





But, seems the old version is not getting removed/replaced by the new version.
The new version installs/uninstalls as a separate product.


What am I doing wrong?


Thanks.
Sudripta.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstall / Update forgetting files ... still

[Alex Cater]

Developers above me. I originally set up using the COM+ extension then when 
someone found out, I was queried and basically asked to move back to the 
custom scripts we had used before. In the end its not my decision. I can sort 
of understand their thinking, "its never failed us before so why change it", 
but that's not a justification I always agree with.


Ouch... IMHO, there is no excuse for this type of mentality, but hey, if its 
not your call...  
It's somewhat analogous to "But we've always bashed our heads against the 
wall... Sure it hurts like hell but nobody has died yet..."


There has never been a case where I sat down and thought, "Oh, batch file would 
be a good solution in an installation package." Actually, finding an 
installation package that has a batch file in it would only encourage me to 
return the product for a refund.


-- 
View this message in context: 
http://n2.nabble.com/Uninstall---Update-forgetting-files-...-still-tp2568948p2572239.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrading an older version of product

[Jim Williams]

Do you have a RemoveExistingProducts action defined in your execution sequence?

Jim Williams

-Original Message-
From: Sudripta Nandy (Sarangsoft Corporation) [mailto:v-su...@microsoft.com] 
Sent: Wednesday, April 01, 2009 4:03 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrading an older version of product

I have two versions of my MSI... one is version 1.0.0.0 and another is
2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are many
significant differences between version 1.0.0.0 and 2.0.1000.0, including
different install directories and files-to-install. Version 1.0.0.0 installs
under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program
Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0
except the upgrade code.

But, even when the upgrade codes are same, version 2.0.1000.0 is unable to
detect the previous version '1.0.0.0'. I have the following element defined
within my wix file:





But, seems the old version is not getting removed/replaced by the new version.
The new version installs/uninstalls as a separate product.


What am I doing wrong?


Thanks.
Sudripta.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Upgrading an older version of product

[Sudripta Nandy (Sarangsoft Corporation)]

I have two versions of my MSI... one is version 1.0.0.0 and another is 
2.0.1000.0. The upgrade code for both the MSIs are the same. But, there are 
many significant differences between version 1.0.0.0 and 2.0.1000.0, including 
different install directories and files-to-install. Version 1.0.0.0 installs 
under 'Program Files\Orange' whereas version 2.0.1000.0 installs to 'Program 
Files\Red'. There are no similarities between version 1.0.0.0 and 2.0.1000.0 
except the upgrade code.

But, even when the upgrade codes are same, version 2.0.1000.0 is unable to 
detect the previous version '1.0.0.0'. I have the following element defined 
within my wix file:





But, seems the old version is not getting removed/replaced by the new version. 
The new version installs/uninstalls as a separate product.


What am I doing wrong?


Thanks.
Sudripta.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstall / Update forgetting files ... still

[Adam Burton]

On Wednesday 01 April 2009 22:47:46 Alex Cater wrote:
> I suggest you break the problem down to isolate the cause:
>
> 1. Simplify the authoring to just install the web files (or simply a
> reduced set) and test: a) Install, uninstall
> b) Install, upgrade, uninstall
>
> Then flesh it out gradually...
>
> 2. Cut to the chase and use the ComPlusExtension to manage the COM+ stuff.
> You're clearly already aware that using immediate CAs to modify the system
> is a very bad idea. Why exactly is it 'beyond my control'??
1. Yea I will try that. I've been trying before and not had many consistent 
results (I felt posting on here was a long shot really, more of a "with any 
luck someone will look at it and go, umm your not supposed to do that else it 
will cause that", no such luck I guess :-) ). Often when debuging it works 
then one day it stops (at moment using it as part of automated installs for a 
test rig, every so often it stops updating files, but lately been consistently 
failing, with the odd success). I guess I will just have to be persistent, 
sooner or later I will notice something I am doing wrong I guess :-).

2. Developers above me. I originally set up using the COM+ extension then when 
someone found out, I was queried and basically asked to move back to the 
custom scripts we had used before. In the end its not my decision. I can sort 
of understand their thinking, "its never failed us before so why change it", 
but that's not a justification I always agree with.

Cheers for the suggestions,
Adam

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Editing resitry values on Change option.

[Sachin Dubey (Tata Consultancy Services)]

Hi All,
I have created MSI using Wix 3.0.
At the installation, I am creating a registry key using "". This 
works all fine. Now the requirement came is to enable "Change" option and edit 
the value of the registry created on installation.
I enabled the "Change", and now if the product is already installed, clicking 
on MSI would take to Change option. 
I tried following to edit the registry key but nothing seem working:
1. Changed the value of property that is used to assign value to registry key 
during installation, using c# custom action.
2. Wrote direct registry editing code in c# custom action.
3. And calling these custom action on "Change" click event.

If anyone can point me to right direction. Where I am going wrong and what 
should be the best way to achieve this.

Any help would be greatly appreciated.
Thanks in Advance.

Thanks
Sachin


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstall / Update forgetting files ... still

[Alex Cater]

I suggest you break the problem down to isolate the cause:

1. Simplify the authoring to just install the web files (or simply a reduced 
set) and test:
a) Install, uninstall
b) Install, upgrade, uninstall

Then flesh it out gradually...

2. Cut to the chase and use the ComPlusExtension to manage the COM+ stuff. 
You're clearly already aware that using immediate CAs to modify the system is a 
very bad idea. Why exactly is it 'beyond my control'??

-- 
View this message in context: 
http://n2.nabble.com/Uninstall---Update-forgetting-files-...-still-tp2568948p2571758.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ServiceInstall not removing service?

[Alex Cater]

The Name attribute of the ServiceControl element must correspond to the name of 
the service.

http://n2.nabble.com/ServiceInstall-not-removing-service--tp2570445p2571646.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ServiceInstall not removing service?

[Wilson, Phil]

It looks like a Name issue to me. I believe the Name values need to be 
identical - they map to the actual name of the service in the 
ServiceControl/ServiceInstall tables in the MSI file. 

Phil Wilson 

-Original Message-
From: Josh Pepper [mailto:josh.pep...@microsoft.com] 
Sent: Wednesday, April 01, 2009 1:29 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] ServiceInstall not removing service?

Thanks for the reply Chad.  I have the Remove="uninstall" set in the 
ServiceControl  any other thoughts as to why it wouldn't remove the service 
on uninstall?

I've included the relevant wxs below.

Thanks
Josh










  





  


-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com] 
Sent: Wednesday, April 01, 2009 1:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] ServiceInstall not removing service?

Hi Josh - Attachments don't come through on the mailing list, but I
think you just need to add a ServiceControl element with a
Remove="uninstall" attribute. Check it out and see if that helps.

Chad

-Original Message-
From: Josh Pepper [mailto:josh.pep...@microsoft.com] 
Sent: Wednesday, April 01, 2009 10:22 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ServiceInstall not removing service?

Hi folks  -

I just made a very simple Hello World service install with
ServiceInstall.  It installed fine.  But when I uninstalled, the service
itself remained, despite the fact that the service exe was removed.

It seems to be that the service should have been removed, or the MSI
should have failed... I thought vital defaults to Yes, right?  Or is
that just for File?

I've included my wxs file 

Thanks
Josh




--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ServiceInstall not removing service?

[Chad Petersen]

Isn't your ServiceControl using a different name than your
ServiceInstall? My installer is set to use the same name for both for
each given service. Not seeing that consistency with your code, but not
100% sure it's critical. Might be worth a try. Here's an example that
works 100%








What I'm seeing in your code is

MyWindowsServiceName being used in ServiceInstall 

And

WixServiceInstaller being used in the two ServiceControl elements.



-Original Message-
From: Josh Pepper [mailto:josh.pep...@microsoft.com] 
Sent: Wednesday, April 01, 2009 1:29 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] ServiceInstall not removing service?

Thanks for the reply Chad.  I have the Remove="uninstall" set in the
ServiceControl  any other thoughts as to why it wouldn't remove the
service on uninstall?

I've included the relevant wxs below.

Thanks
Josh










  





  


-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com] 
Sent: Wednesday, April 01, 2009 1:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] ServiceInstall not removing service?

Hi Josh - Attachments don't come through on the mailing list, but I
think you just need to add a ServiceControl element with a
Remove="uninstall" attribute. Check it out and see if that helps.

Chad

-Original Message-
From: Josh Pepper [mailto:josh.pep...@microsoft.com] 
Sent: Wednesday, April 01, 2009 10:22 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ServiceInstall not removing service?

Hi folks  -

I just made a very simple Hello World service install with
ServiceInstall.  It installed fine.  But when I uninstalled, the service
itself remained, despite the fact that the service exe was removed.

It seems to be that the service should have been removed, or the MSI
should have failed... I thought vital defaults to Yes, right?  Or is
that just for File?

I've included my wxs file 

Thanks
Josh





--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ServiceInstall not removing service?

[Josh Pepper]

Thanks for the reply Chad.  I have the Remove="uninstall" set in the 
ServiceControl  any other thoughts as to why it wouldn't remove the service 
on uninstall?

I've included the relevant wxs below.

Thanks
Josh










  





  


-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com] 
Sent: Wednesday, April 01, 2009 1:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] ServiceInstall not removing service?

Hi Josh - Attachments don't come through on the mailing list, but I
think you just need to add a ServiceControl element with a
Remove="uninstall" attribute. Check it out and see if that helps.

Chad

-Original Message-
From: Josh Pepper [mailto:josh.pep...@microsoft.com] 
Sent: Wednesday, April 01, 2009 10:22 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ServiceInstall not removing service?

Hi folks  -

I just made a very simple Hello World service install with
ServiceInstall.  It installed fine.  But when I uninstalled, the service
itself remained, despite the fact that the service exe was removed.

It seems to be that the service should have been removed, or the MSI
should have failed... I thought vital defaults to Yes, right?  Or is
that just for File?

I've included my wxs file 

Thanks
Josh




--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] "This installation package could not be opened."

[Karl Denning]

I just tried my msi when locked by orca, and when it is on a nw share (I don't 
manage the nw share, and I have no idea why I cannot open it when it's on that 
particular share). In both cases i get error 1619. So it's not what I think it 
might be.

I'd guess it's corrupt to.

However... http://www.appdeploy.com/msierrors/detail.asp?id=26 says other 
things.

K.




Here's the log file from the failed install.  This looks like it could be file 
corruption error, unless someone else can tell me otherwise?

=== Verbose logging started: 4/1/2009  11:02:16  Build type: SHIP UNICODE 
3.01.4001.5512  Calling process: C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (28:DC) [11:02:16:072]: Resetting cached policy values
MSI (c) (28:DC) [11:02:16:072]: Machine policy value 'Debug' is 0
MSI (c) (28:DC) [11:02:16:072]: *** RunEngine:
   *** Product: PixelActiveCityScape_v1_7_Demo.msi
   *** Action: 
   *** CommandLine: **
MSI (c) (28:DC) [11:02:16:072]: Note: 1: 2203 2: 
PixelActiveCityScape_v1_7_Demo.msi 3: -2147287010 
MSI (c) (28:DC) [11:02:16:072]: MainEngineThread is returning 1620
=== Verbose logging stopped: 4/1/2009  11:02:16 ===



-- 
View this message in context: 
http://n2.nabble.com/%22This-installation-package-could-not-be-opened.%22-tp2566106p2571317.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Add/Remove Programs Fatal Error 1603 after abort uninstall because of in-use/locked file

[Paul Lewis]

Hi Folks,

When uninstalling from Add/Remove Programs if the uninstall is canceled 
because a file is in-use (click Cancel at the Retry/Cancel problem, then 
confirm Yes at the "Are you sure you wish to cancel" prompt) Add/Remove 
Programs reports a "Fatal error during installation".

Is there anyway to suppress this message? I've searched but not found 
anything that seems relevant.

I would have thought the exit state from the MSI would be 1602 "User 
canceled" after the cancel confirmation, does the 1603 error state 
override that?

When manually initiating the uninstall from the MSI's 
Change/Repair/Remove UI the error is swallowed and the install 
terminated final screen is shown and 1602 is returned as the exit code.

I've read somewhere that setting the ARPNOREMOVE property forces the 
Change/Repair/Remove install UI, is that a directions I should be 
looking in.

Any suggestions or pointers in the right direction are appreciated.

Regards,
Paul

-- 
-
Paul Lewis
Software Engineer
Wimba - People Teach People
 
10 East 40th Street, Floor 11
New York, NY 10016
ple...@wimba.com
http://www.wimba.com
-


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] custom action 51

[Arthur Curvello]

Hmmm my fault.. 
Solved..

Thanks Chad and Don

Arthur Curvello 
arthur.curve...@conv.com.br
tel +55 21 2494-5476
cel +55 21 9762-4284

Confidencialidade: A informação contida nesta mensagem de e-mail, incluindo
quaisquer anexos, é confidencial e está reservada apenas à pessoa ou
entidade para a qual foi endereçada. Se você não é o destinatário ou a
pessoa responsável por encaminhar esta mensagem ao destinatário, você está,
por meio desta, notificado que não deverá rever, retransmitir, imprimir,
copiar, usar ou distribuir esta mensagem de e-mail ou quaisquer anexos. Caso
você tenha recebido esta mensagem por engano, por favor, contate o remetente
imediatamente e apague esta mensagem de seu computador ou de qualquer outro
banco de dados. Grato. 

Confidentiality Notice: The information contained in this email message,
including any attachment, is confidential and is intended only for the
person or entity to which it is addressed. If you are neither the intended
recipient nor the employee or agent responsible for delivering this message
to the intended recipient, you are hereby notified that you may not review,
retransmit, convert to hard copy, copy, use or distribute this email message
or any attachments to it. If you have received this email in error, please
contact the sender immediately and delete this message from any computer or
other data bank. Thank you. 



-Original Message-
From: Don Benson [mailto:dbenso...@gmail.com] 
Sent: Tuesday, March 31, 2009 5:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] custom action 51

On Tue, Mar 31, 2009 at 4:12 PM, Chad Petersen
wrote:

> You want to schedule it in the InstallUISequence, rather than the
> InstallExecuteSequence where it sounds like you might have it now. Might
be
> as simple as cut from one section and paste into another.


If the action needs to run with or without the UI, the action should be
scheduled in both sequences. You can set CustomAction/@Execute to
"firstSequence". This ensures that it won't run again in the Execute
sequence if it was already set in the UI sequence.

- Don Benson -

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat missing some RegistryValue elements (Programmable) from VB6 code?

[Neil Sleightholm]

I just tried this again and didn't see an error, has the dll changed from the 
one you sent me?
 
Neil
 
Neil Sleightholm
X2 Systems Limited
n...@x2systems.com  
 



From: Roy Abou Assaly [mailto:royass...@gmail.com]
Sent: Wed 01/04/2009 14:39
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Heat missing some RegistryValue elements 
(Programmable) from VB6 code?





I have just tried the latest version 3.0.5120.0 and the programmable
attribute on is set for your dll on the ClassId e.g.



If you are not already you may also want to try the -svb6 option with
Heat as that will remove the VB6 runtime properties that are not
required (see help file).

Neil


Hi Neil and Roger,

I just ran heat 3.0.5120.0 and got this error:

D:\lab\WiX\XMLEditor>heat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out 
result.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5120.0
Copyright (C) Microsoft Corporation. All rights reserved.

heat.exe : error HEAT0001 : Item has already been added. Key in dictionary: 
'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}\ProxyStubClsid/'  Key being 
added: 'Interface\{0B7F3153-C8E7-4E6
D-AEBE-B6D61D78B9A3}\ProxyStubClsid/'

Exception Type: System.ArgumentException

Stack Trace:
   at System.Collections.SortedList.Add(Object key, Object value)
   at 
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.MutateComponents()
   at 
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.Mutate(Wix
 wix)
   at Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)
   at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)

Then I ran 3.0.4923.0

D:\lab\WiX\XMLEditor>heat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out 
result.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.4923.0
Copyright (C) Microsoft Corporation. All rights reserved.

And yes, you're right.  Programmable is set as an attribute of Class rather 
than being created in RegistryValue.  I'm going to assume that those 2 are the 
equivalent?  Can you confirm this?  If that is true, I will stick with 
3.0.4923.0 since it works and I have tested the builds with this version.  
That's basically where I got confused.  I saw that I was missing RegistryValue 
elements and figured that certain keys were being missing.

Do you still want me to open a bug Roger?  Although, this time it would be for 
another Reason.  Also, how did it manage to run heat 3.0.5120.0 on your machine 
Neil?  I hope it's not the dreaded "It runs on my machine" bug :)

Thanks guys
--
View this message in context: 
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2569042.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] "This installation package could not be opened."

[Michael.A.Kelley]

Here's the log file from the failed install.  This looks like it could be file 
corruption error, unless someone else can tell me otherwise?

=== Verbose logging started: 4/1/2009  11:02:16  Build type: SHIP UNICODE 
3.01.4001.5512  Calling process: C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (28:DC) [11:02:16:072]: Resetting cached policy values
MSI (c) (28:DC) [11:02:16:072]: Machine policy value 'Debug' is 0
MSI (c) (28:DC) [11:02:16:072]: *** RunEngine:
   *** Product: PixelActiveCityScape_v1_7_Demo.msi
   *** Action: 
   *** CommandLine: **
MSI (c) (28:DC) [11:02:16:072]: Note: 1: 2203 2: 
PixelActiveCityScape_v1_7_Demo.msi 3: -2147287010 
MSI (c) (28:DC) [11:02:16:072]: MainEngineThread is returning 1620
=== Verbose logging stopped: 4/1/2009  11:02:16 ===


It's hard to say the exact circumstances.  The .msi is downloaded from our 
website, and I don't have access to the client's computer.

The client that last reported this problem has his AV scanner disabled.  I'll 
ask him if he's running it from a network share.


What are the circumstances when it fails?

Perhaps there is another process locking the file open?
I have seen this error occasionally when I try to open a package that is on a 
network share with orca.
I presume that there is an AV scanner running on the server locking the file 
open.



I have a .msi I've created using Wix that seems to work on a lot of computers.  
However, I occasionally have reports of of clients running the .msi on their 
computer and getting this error message:

"This installation package could not be opened.  Contact the application vendor 
to verify that this is a valid Windows Installer package."

Does anyone know how I can recreate this image, and what I could possibly be 
doing wrong in my .wxs file?  This error happens with both 2.0 and 3.0 versions 
of Wix.

Product.wxs 






-- 
View this message in context: 
http://n2.nabble.com/%22This-installation-package-could-not-be-opened.%22-tp2566106p2571048.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ServiceInstall not removing service?

[Chad Petersen]

Hi Josh - Attachments don't come through on the mailing list, but I
think you just need to add a ServiceControl element with a
Remove="uninstall" attribute. Check it out and see if that helps.

Chad

-Original Message-
From: Josh Pepper [mailto:josh.pep...@microsoft.com] 
Sent: Wednesday, April 01, 2009 10:22 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ServiceInstall not removing service?

Hi folks  -

I just made a very simple Hello World service install with
ServiceInstall.  It installed fine.  But when I uninstalled, the service
itself remained, despite the fact that the service exe was removed.

It seems to be that the service should have been removed, or the MSI
should have failed... I thought vital defaults to Yes, right?  Or is
that just for File?

I've included my wxs file 

Thanks
Josh




--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] ServiceInstall not removing service?

[Josh Pepper]

Hi folks  -

I just made a very simple Hello World service install with ServiceInstall.  It 
installed fine.  But when I uninstalled, the service itself remained, despite 
the fact that the service exe was removed.

It seems to be that the service should have been removed, or the MSI should 
have failed... I thought vital defaults to Yes, right?  Or is that just for 
File?

I've included my wxs file 

Thanks
Josh


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] CA before RemoveFiles

[Michael]

Hi,

I have set of CA(commit) to executes on uninstall. I'm running CA after 
'MsiUnpublishAssemblies'. While executing CA, I'm getting error in CA 
dll that file not found. I want to execute CA before all files are removed.
help me.

Regards,
-SMR

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat missing some RegistryValue elements (Programmable) from VB6 code?

[Roy Abou Assaly]

I have just tried the latest version 3.0.5120.0 and the programmable
attribute on is set for your dll on the ClassId e.g.



If you are not already you may also want to try the -svb6 option with
Heat as that will remove the VB6 runtime properties that are not
required (see help file).

Neil


Hi Neil and Roger,

I just ran heat 3.0.5120.0 and got this error:

D:\lab\WiX\XMLEditor>heat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out 
result.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5120.0
Copyright (C) Microsoft Corporation. All rights reserved.

heat.exe : error HEAT0001 : Item has already been added. Key in dictionary: 
'Interface\{0B7F3153-C8E7-4E6D-AEBE-B6D61D78B9A3}\ProxyStubClsid/'  Key being 
added: 'Interface\{0B7F3153-C8E7-4E6
D-AEBE-B6D61D78B9A3}\ProxyStubClsid/'

Exception Type: System.ArgumentException

Stack Trace:
   at System.Collections.SortedList.Add(Object key, Object value)
   at 
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.MutateComponents()
   at 
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilFinalizeHarvesterMutator.Mutate(Wix
 wix)
   at Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)
   at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)

Then I ran 3.0.4923.0

D:\lab\WiX\XMLEditor>heat file PRISMXMLEditor.dll -sfrag -gg -vb6 -out 
result.xml
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.4923.0
Copyright (C) Microsoft Corporation. All rights reserved.

And yes, you're right.  Programmable is set as an attribute of Class rather 
than being created in RegistryValue.  I'm going to assume that those 2 are the 
equivalent?  Can you confirm this?  If that is true, I will stick with 
3.0.4923.0 since it works and I have tested the builds with this version.  
That's basically where I got confused.  I saw that I was missing RegistryValue 
elements and figured that certain keys were being missing.

Do you still want me to open a bug Roger?  Although, this time it would be for 
another Reason.  Also, how did it manage to run heat 3.0.5120.0 on your machine 
Neil?  I hope it's not the dreaded "It runs on my machine" bug :)

Thanks guys
-- 
View this message in context: 
http://n2.nabble.com/Heat-missing-some-RegistryValue-elements-%28Programmable%29-from-VB6-code--tp2559361p2569042.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Uninstall / Update forgetting files ... still

[Adam Burton]

Hi,
I never got sent the email I sent to wix-users so couldn't see how to reply
to my previous email, so forced to re-post. Below is my previous email.

>Hi,
>there is something I am obviously doing seriously wrong with a particular
>installer I have, but I am clueless as to what.
>
>Installing, works great, however then when I come to uninstall, or update,
a
>majority of the time it simply executes custom actions and leaves it at
that
>(on uninstall it removes it from add remove programs, but all files are
still
>there!?).
>
>The installer is pretty basic. It is for a website and upgrades are always
>major upgrades. I have it set as one file per-component and there are
>approximately 3200 files (I have been wondering if this is maybe the cause?

>Since I am using major upgrades only and have everything removed first then

>reinstalled would it be worth changing so I have maybe a component per
>directory?), there are a couple XmlFile actions for the web.config in a
>component and I use a custom action (before anyone starts telling me its a
bad
>idea, this is beyond my control :-) ) for register and unregister some
COM+.
>Currently, that's it. In the future I would like to reintroduce IIS
>configuration, but need this fixed first obviously.
>
>I have some service installers that are for the most part the same, except
>they include a service, and they work consistently.
>
>I don't have the files on me now but I have attached a dirty hack file that

>should accurately represent the file, any suggestions welcome. Any files in

>there are stored in separate files and reference back using DirectoryRef,
they
>are just super basic, component with guid and file set to keypath. Then
another
>file that has some XmlFile in a couple components,
>
>When creating, the only warnings I get are there are some font files in the
web
>directory so it makes some comment about them and the fact having over
800ish
>components wont go down well in win9x (not an issue though).
>
>Thanks,
>Adam

Well, it seems I didn't attach the file, although my send items says
otherwise, but this time I hopefully have a better example since this is
straight from the original file instead of a guess off the top of my head.
As before the files are just basic component+file(with keypath) in separate
files/fragments so I not bothered posting them. Here is the main bit.



http://schemas.microsoft.com/wix/2006/wi"; xmlns:util="
http://schemas.microsoft.com/wix/UtilExtension";>
  








  



  





  
  
  
  



  
  
  
  
  












  
  

  

All help is appreciated,
Adam
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users