Re: [WiX-users] Prevent overwriting a modified text file when upgrading

[Thomas Singer]

I want to add: I've read in the mailing list archive, that the installer by 
default should *keep* the file, but for our tests it definitely 
overwrites/uninstalls the file.

--
Tom


Thomas Singer wrote:
> Our installers install also a configuration (text) file where - if necessary 
> - the user can configure some options to run our application. Unfortunately, 
> it will be overwritten without request when installing an upgrade (different 
> Product Id, different Product Version) using "msiexec /i ". We are 
> using WiX 3.0.4227.0.
> 
> How we can prevent overwriting this file?
> 
> --
> Thanks in advance,
> Tom


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Mixed language (localization)

[Olivier Guezenec]

Thanks.

The trouble is I already use wixui_en-us.wxl and wixui_fr-fr.wxl. But few
strings (not all) of wixui_en-us.wxl are not overriding and few messages are
still in English despite a French version, with of course the same id.

 

I use the following switch : -ext WixUIExtension -cultures:fr-fr -loc
wixui_fr-fr.wxl


Thanks for your help,

Olivier




 

-

Hey Olivier,

I've not done it myself but there was a post last week  (3 July 2008 10:52)
discussing the overriding of text using a localisation file..

There were a couple of links to the variables that can be overriden:

http://wix.cvs.sourceforge.net/*checkout*/wix/wix/src/ext/UIExtension/wixlib
/ErrorProgressText.wxs
 

http://wix.cvs.sourceforge.net/*checkout*/wix/wix/src/ext/UIExtension/wixlib
/WixUI_en-us.wxl

I'm sure there is probably some info in the Wix chm about it.

Cheers,
Martin

2008/7/8 Olivier Guezenec <[EMAIL PROTECTED]>:

I have 2 versions of my package, one in English and the other in French.

The problem with the French version is that few messages are still in
English, such as:

"You must restart your system for this configuration changes made to."

"Removing backup files"

I use a recent Wix V3, with the switch -cultures:fr-fr

Any thought?



Thanks for your help,

Olivier



-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Stable Wixv3 build for VS 2008

[Vidya Kukke]

Hi,

Need help with the Wixv3 version to use for VS 2008.
I have downloaded 3.0.4227.0 and get errors when I open the properties window 
of any wix project. Is this expected? What am I missing?
FYI - The original wix project was created on VS 2005 using Wix v3 Beta and 
then we moved to 3.0.4227.0 on VS 2008 and are facing this problem.

Any help/pointers is appreciated.

Thanks
Vidya


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Stable Wixv3 build for VS 2008

[Neil Enns]

What errors are you getting?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vidya Kukke
Sent: Wednesday, July 09, 2008 10:25 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Stable Wixv3 build for VS 2008

Hi,

Need help with the Wixv3 version to use for VS 2008.
I have downloaded 3.0.4227.0 and get errors when I open the properties window 
of any wix project. Is this expected? What am I missing?
FYI - The original wix project was created on VS 2005 using Wix v3 Beta and 
then we moved to 3.0.4227.0 on VS 2008 and are facing this problem.

Any help/pointers is appreciated.

Thanks
Vidya


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Stable Wixv3 build for VS 2008

[Vidya Kukke]

When I right click on the project properties and select 'Build' or 'Tool 
Settings' see an error on the right pane with the message

"An error occurred trying to load the page.
Value does not fall within the expected range.".

Thanks
Vidya

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Wednesday, July 09, 2008 10:27 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Stable Wixv3 build for VS 2008

What errors are you getting?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vidya Kukke
Sent: Wednesday, July 09, 2008 10:25 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Stable Wixv3 build for VS 2008

Hi,

Need help with the Wixv3 version to use for VS 2008.
I have downloaded 3.0.4227.0 and get errors when I open the properties window 
of any wix project. Is this expected? What am I missing?
FYI - The original wix project was created on VS 2005 using Wix v3 Beta and 
then we moved to 3.0.4227.0 on VS 2008 and are facing this problem.

Any help/pointers is appreciated.

Thanks
Vidya


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Stable Wixv3 build for VS 2008

[Jason Ginchereau]

If your original project was created with a build of WiX more than a couple 
months old, you might need to edit the project file in notepad or the VS text 
editor to add an x86 Platform to the Debug and Release PropertyGroup 
conditions, like this:

  
bin\$(Configuration)\
...
  
  
bin\$(Configuration)\
...
  

You might also need to update the .sln file to make sure it builds "x86" 
instead of "Any CPU" platform for the WiX project.

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vidya Kukke
Sent: Wednesday, July 09, 2008 10:33 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Stable Wixv3 build for VS 2008

When I right click on the project properties and select 'Build' or 'Tool 
Settings' see an error on the right pane with the message

"An error occurred trying to load the page.
Value does not fall within the expected range.".

Thanks
Vidya

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Wednesday, July 09, 2008 10:27 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Stable Wixv3 build for VS 2008

What errors are you getting?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vidya Kukke
Sent: Wednesday, July 09, 2008 10:25 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Stable Wixv3 build for VS 2008

Hi,

Need help with the Wixv3 version to use for VS 2008.
I have downloaded 3.0.4227.0 and get errors when I open the properties window 
of any wix project. Is this expected? What am I missing?
FYI - The original wix project was created on VS 2005 using Wix v3 Beta and 
then we moved to 3.0.4227.0 on VS 2008 and are facing this problem.

Any help/pointers is appreciated.

Thanks
Vidya


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Suppress light.exe & ICE warnings....

[John Nannenga]

Is there a way to suppress a specific instance of a light.exe warning?

For example, I'm consuming some VBA 6.4 merge modules where they incorrectly 
authored a DefaultDir of "SOURCEDIR" for the Directory of "TARGETDIR".  When 
including this module into my WiX v3.0 installation that has a DefaultDir of 
"SourceDir" for Directory "TARGETDIR", I receive a LGHT1056 warning; The 
Directory table contains a row with primary key(s) 'TARGETDIR' which cannot 
merged from the merge module 'vba64.core.msm'.  This is likely due to collision 
of rows with the same primary key(s) (but other different values in other 
columns) between the database and the merge module.

While I know that I can suppress specific classes of ICE validations and 
specific classes of light.exe warnings, I don't want to suppress all 1056 
warnings, just the one for this particular instance.  (If I consume a module 
that I've authored that might have this problem in the future, I'd want to know 
about it to correct it).


Is there a  way to suppress a specific instance of a warning?
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Prevent overwriting a modified text file when upgrading

[Wilson, Phil]

Where is your RemoveExistingProducts sequenced? A major upgrade will not use 
file update rules if it's sequenced early in the install, such as just after 
InstallInitialize.

Phil Wilson


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Singer
Sent: Wednesday, July 09, 2008 12:25 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Prevent overwriting a modified text file when upgrading

I want to add: I've read in the mailing list archive, that the installer by
default should *keep* the file, but for our tests it definitely
overwrites/uninstalls the file.

--
Tom


Thomas Singer wrote:
> Our installers install also a configuration (text) file where - if necessary
> - the user can configure some options to run our application. Unfortunately,
> it will be overwritten without request when installing an upgrade (different
> Product Id, different Product Version) using "msiexec /i ". We are
> using WiX 3.0.4227.0.
>
> How we can prevent overwriting this file?
>
> --
> Thanks in advance,
> Tom


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Stable Wixv3 build for VS 2008

[Jason Ginchereau]

Blogged with more detail at 
http://blogs.msdn.com/jasongin/archive/2008/07/09/votive-project-platform-configurations.aspx

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Ginchereau
Sent: Wednesday, July 09, 2008 10:39 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Stable Wixv3 build for VS 2008

If your original project was created with a build of WiX more than a couple 
months old, you might need to edit the project file in notepad or the VS text 
editor to add an x86 Platform to the Debug and Release PropertyGroup 
conditions, like this:

  
bin\$(Configuration)\
...
  
  
bin\$(Configuration)\
...
  

You might also need to update the .sln file to make sure it builds "x86" 
instead of "Any CPU" platform for the WiX project.

-Jason-

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vidya Kukke
Sent: Wednesday, July 09, 2008 10:33 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Stable Wixv3 build for VS 2008

When I right click on the project properties and select 'Build' or 'Tool 
Settings' see an error on the right pane with the message

"An error occurred trying to load the page.
Value does not fall within the expected range.".

Thanks
Vidya

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Wednesday, July 09, 2008 10:27 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Stable Wixv3 build for VS 2008

What errors are you getting?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vidya Kukke
Sent: Wednesday, July 09, 2008 10:25 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Stable Wixv3 build for VS 2008

Hi,

Need help with the Wixv3 version to use for VS 2008.
I have downloaded 3.0.4227.0 and get errors when I open the properties window 
of any wix project. Is this expected? What am I missing?
FYI - The original wix project was created on VS 2005 using Wix v3 Beta and 
then we moved to 3.0.4227.0 on VS 2008 and are facing this problem.

Any help/pointers is appreciated.

Thanks
Vidya


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Prevent overwriting a modified text file when upgrading

[Thomas Singer]

The relevant source code is:
   
 
   

Where should I schedule it instead?

--
Tom


Wilson, Phil wrote:
> Where is your RemoveExistingProducts sequenced? A major upgrade will not use 
> file update rules if it's sequenced early in the install, such as just after 
> InstallInitialize.
> 
> Phil Wilson
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Singer
> Sent: Wednesday, July 09, 2008 12:25 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Prevent overwriting a modified text file when 
> upgrading
> 
> I want to add: I've read in the mailing list archive, that the installer by
> default should *keep* the file, but for our tests it definitely
> overwrites/uninstalls the file.
> 
> --
> Tom
> 
> 
> Thomas Singer wrote:
>> Our installers install also a configuration (text) file where - if necessary
>> - the user can configure some options to run our application. Unfortunately,
>> it will be overwritten without request when installing an upgrade (different
>> Product Id, different Product Version) using "msiexec /i ". We are
>> using WiX 3.0.4227.0.
>>
>> How we can prevent overwriting this file?
>>
>> --
>> Thanks in advance,
>> Tom
> 
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Prevent overwriting a modified text file when upgrading

[Christopher Painter]

Read:

http://msdn.microsoft.com/en-us/library/aa371197(VS.85).aspx

Do be advised that if you aren't following good versioning patterns upstream 
and you move the the action in the sequence, you might see other adverse side 
effects.


Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me


--- On Wed, 7/9/08, Thomas Singer <[EMAIL PROTECTED]> wrote:

> From: Thomas Singer <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Prevent overwriting a modified text file when 
> upgrading
> To: "General discussion for Windows Installer XML toolset." 
> 
> Date: Wednesday, July 9, 2008, 2:04 PM
> The relevant source code is:
>
>   After="InstallValidate" />
>
> 
> Where should I schedule it instead?
> 
> --
> Tom
> 
> 
> Wilson, Phil wrote:
> > Where is your RemoveExistingProducts sequenced? A
> major upgrade will not use file update rules if it's
> sequenced early in the install, such as just after
> InstallInitialize.
> > 
> > Phil Wilson
> > 
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Thomas Singer
> > Sent: Wednesday, July 09, 2008 12:25 AM
> > To: General discussion for Windows Installer XML
> toolset.
> > Subject: Re: [WiX-users] Prevent overwriting a
> modified text file when upgrading
> > 
> > I want to add: I've read in the mailing list
> archive, that the installer by
> > default should *keep* the file, but for our tests it
> definitely
> > overwrites/uninstalls the file.
> > 
> > --
> > Tom
> > 
> > 
> > Thomas Singer wrote:
> >> Our installers install also a configuration (text)
> file where - if necessary
> >> - the user can configure some options to run our
> application. Unfortunately,
> >> it will be overwritten without request when
> installing an upgrade (different
> >> Product Id, different Product Version) using
> "msiexec /i ". We are
> >> using WiX 3.0.4227.0.
> >>
> >> How we can prevent overwriting this file?
> >>
> >> --
> >> Thanks in advance,
> >> Tom
> > 
> > 
> >
> -
> > Sponsored by: SourceForge.net Community Choice Awards:
> VOTE NOW!
> > Studies have shown that voting for your favorite open
> source project,
> > along with a healthy diet, reduces your potential for
> chronic lameness
> > and boredom. Vote Now at
> http://www.sourceforge.net/community/cca08
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> > 
> > 
> > 
> >
> -
> > Sponsored by: SourceForge.net Community Choice Awards:
> VOTE NOW!
> > Studies have shown that voting for your favorite open
> source project,
> > along with a healthy diet, reduces your potential for
> chronic lameness
> > and boredom. Vote Now at
> http://www.sourceforge.net/community/cca08
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> > 
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE
> NOW!
> Studies have shown that voting for your favorite open
> source project,
> along with a healthy diet, reduces your potential for
> chronic lameness
> and boredom. Vote Now at
> http://www.sourceforge.net/community/cca08
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


  

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Configurable Merge Modules

[Christopher Karper]

I'm still working on my merge module solution here, and my last e-mail riled
up some interesting convo, but never really answered my questions.   I'm
trying to use the Configuration element in my modules, does this just make
the elements available as properties?   Do I need to access them some other
way?
If someone had an example of how to do this, that would help me out a great
deal I think.   I've searched high and low, and just can't seem to find one.

Thanks for any assistance. :-)
Chris
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Unable to execute commonds on commnad prompt..

[Kalvagadda, SivaKrishna (GMIT-TASS)]

Hi All,

I am very much new to WIX. I am trying to implementing executing
commands on Command prompt.
I am using below code to do but its failing while installation.



 

Where .bat is placed on c:\ path.


I have tried with different methods like using properties. Please help
me on this.

Regards,
SivaKrishna Kalvagadda,
201-671-5552.


This message w/attachments (message) may be privileged, confidential or 
proprietary, and if you are not an intended recipient, please notify the 
sender, do not use or share it and delete it. Unless specifically indicated, 
this message is not an offer to sell or a solicitation of any investment 
products or other financial product or service, an official confirmation of any 
transaction, or an official statement of Merrill Lynch. Subject to applicable 
law, Merrill Lynch may monitor, review and retain e-communications (EC) 
traveling through its networks/systems. The laws of the country of each 
sender/recipient may impact the handling of EC, and EC may be archived, 
supervised and produced in countries other than the country in which you are 
located. This message cannot be guaranteed to be secure or error-free. This 
message is subject to terms available at the following link: 
http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you 
consent to the foregoing.


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Unable to execute commonds on commnad prompt..

[Neil Sleightholm]

I think the problem is that you can't evaluate properties in the
ExeCommand attribute so you need to do it in two steps. Here is an
example that works for me:





  NOT
Installed
  NOT
Installed


I hope this helps,

Neil

Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Kalvagadda, SivaKrishna (GMIT-TASS)
Sent: 09 July 2008 20:29
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Unable to execute commonds on commnad prompt..

Hi All,

I am very much new to WIX. I am trying to implementing executing
commands on Command prompt.
I am using below code to do but its failing while installation.



 

Where .bat is placed on c:\ path.


I have tried with different methods like using properties. Please help
me on this.

Regards,
SivaKrishna Kalvagadda,
201-671-5552.


This message w/attachments (message) may be privileged, confidential or
proprietary, and if you are not an intended recipient, please notify the
sender, do not use or share it and delete it. Unless specifically
indicated, this message is not an offer to sell or a solicitation of any
investment products or other financial product or service, an official
confirmation of any transaction, or an official statement of Merrill
Lynch. Subject to applicable law, Merrill Lynch may monitor, review and
retain e-communications (EC) traveling through its networks/systems. The
laws of the country of each sender/recipient may impact the handling of
EC, and EC may be archived, supervised and produced in countries other
than the country in which you are located. This message cannot be
guaranteed to be secure or error-free. This message is subject to terms
available at the following link:
http://www.ml.com/e-communications_terms/. By messaging with Merrill
Lynch you consent to the foregoing.



-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Explicit Deny permissions

[John Nannenga]

I'm trying to 'ADD' [to existing permissions] an explicit deny permission on 
BUILTIN\Users for "Traverse Folder / Execute File", for "Subfolders and files 
only".

I'll spare you all the gory details of what I've all tried [Permission and the 
util:PermissionEx elements (from within a "CreateFolder" element], and simply, 
humbly ask, does anybody know how to do this?  (Is it even possible to do this 
with either of these elements within WiX?)









-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Prevent overwriting a modified text file when upgrading

[jmcfadyen]

Phil are you sure about this.. (not trying to be difficult I would be
interested to understand what your getting at here.)

My understanding of the sequencing relating to upgrades is the opposite of
what you suggest. 

by moving the RemoveExistingProducts action earlier in the sequences you are
effectively removing the older product prior to installing the new one. 

By leaving the RemoveExistingProducts later in the sequences you will have
the opportunity to leave components on the machine during installation of
the newer version. See this post for more details as its quite complex to
explain. This would require that you match component ID on the items you did
not wish to upgrade. 
 
http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!249.entry



Christopher Painter-2 wrote:
> 
> Read:
> 
> http://msdn.microsoft.com/en-us/library/aa371197(VS.85).aspx
> 
> Do be advised that if you aren't following good versioning patterns
> upstream and you move the the action in the sequence, you might see other
> adverse side effects.
> 
> 
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
> 
> 
> --- On Wed, 7/9/08, Thomas Singer <[EMAIL PROTECTED]> wrote:
> 
>> From: Thomas Singer <[EMAIL PROTECTED]>
>> Subject: Re: [WiX-users] Prevent overwriting a modified text file when
>> upgrading
>> To: "General discussion for Windows Installer XML toolset."
>> 
>> Date: Wednesday, July 9, 2008, 2:04 PM
>> The relevant source code is:
>>
>>  > After="InstallValidate" />
>>
>> 
>> Where should I schedule it instead?
>> 
>> --
>> Tom
>> 
>> 
>> Wilson, Phil wrote:
>> > Where is your RemoveExistingProducts sequenced? A
>> major upgrade will not use file update rules if it's
>> sequenced early in the install, such as just after
>> InstallInitialize.
>> > 
>> > Phil Wilson
>> > 
>> > 
>> > -Original Message-
>> > From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf
>> Of Thomas Singer
>> > Sent: Wednesday, July 09, 2008 12:25 AM
>> > To: General discussion for Windows Installer XML
>> toolset.
>> > Subject: Re: [WiX-users] Prevent overwriting a
>> modified text file when upgrading
>> > 
>> > I want to add: I've read in the mailing list
>> archive, that the installer by
>> > default should *keep* the file, but for our tests it
>> definitely
>> > overwrites/uninstalls the file.
>> > 
>> > --
>> > Tom
>> > 
>> > 
>> > Thomas Singer wrote:
>> >> Our installers install also a configuration (text)
>> file where - if necessary
>> >> - the user can configure some options to run our
>> application. Unfortunately,
>> >> it will be overwritten without request when
>> installing an upgrade (different
>> >> Product Id, different Product Version) using
>> "msiexec /i ". We are
>> >> using WiX 3.0.4227.0.
>> >>
>> >> How we can prevent overwriting this file?
>> >>
>> >> --
>> >> Thanks in advance,
>> >> Tom
>> > 
>> > 
>> >
>> -
>> > Sponsored by: SourceForge.net Community Choice Awards:
>> VOTE NOW!
>> > Studies have shown that voting for your favorite open
>> source project,
>> > along with a healthy diet, reduces your potential for
>> chronic lameness
>> > and boredom. Vote Now at
>> http://www.sourceforge.net/community/cca08
>> > ___
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>> > 
>> > 
>> > 
>> >
>> -
>> > Sponsored by: SourceForge.net Community Choice Awards:
>> VOTE NOW!
>> > Studies have shown that voting for your favorite open
>> source project,
>> > along with a healthy diet, reduces your potential for
>> chronic lameness
>> > and boredom. Vote Now at
>> http://www.sourceforge.net/community/cca08
>> > ___
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>> > 
>> 
>> -
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE
>> NOW!
>> Studies have shown that voting for your favorite open
>> source project,
>> along with a healthy diet, reduces your potential for
>> chronic lameness
>> and boredom. Vote Now at
>> http://www.sourceforge.net/community/cca08
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
>   
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and bor

Re: [WiX-users] Prevent overwriting a modified text file when upgrading

[Wilson, Phil]

What's happening when REP is just after InstallValidate ("early in the 
install") is that the older product is uninstalled and then the new one is 
installed. In this situation Tom's data file just gets removed and then 
installed by the new product.

When REP is "late" in the install the new product is installed on top of the 
older version, during which the file overwrite rules are used and component ref 
counts are incremented (so your guids should be consistent for files you care 
about, and Chris's side effects). Then the "uninstall" happens, which mainly 
consists of decrementing the component ref counts.

So I think we're both saying the same thing, and I don't think my earlier 
statement that "A major upgrade will not use file update rules if it's 
sequenced early in the install, such as just after InstallInitialize" 
contradicts anything you're saying.

Phil Wilson


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jmcfadyen
Sent: Wednesday, July 09, 2008 4:53 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Prevent overwriting a modified text file when upgrading


Phil are you sure about this.. (not trying to be difficult I would be
interested to understand what your getting at here.)

My understanding of the sequencing relating to upgrades is the opposite of
what you suggest.

by moving the RemoveExistingProducts action earlier in the sequences you are
effectively removing the older product prior to installing the new one.

By leaving the RemoveExistingProducts later in the sequences you will have
the opportunity to leave components on the machine during installation of
the newer version. See this post for more details as its quite complex to
explain. This would require that you match component ID on the items you did
not wish to upgrade.

http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!249.entry



Christopher Painter-2 wrote:
>
> Read:
>
> http://msdn.microsoft.com/en-us/library/aa371197(VS.85).aspx
>
> Do be advised that if you aren't following good versioning patterns
> upstream and you move the the action in the sequence, you might see other
> adverse side effects.
>
>
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves
> attention? E-Mail Me
>
>
> --- On Wed, 7/9/08, Thomas Singer <[EMAIL PROTECTED]> wrote:
>
>> From: Thomas Singer <[EMAIL PROTECTED]>
>> Subject: Re: [WiX-users] Prevent overwriting a modified text file when
>> upgrading
>> To: "General discussion for Windows Installer XML toolset."
>> 
>> Date: Wednesday, July 9, 2008, 2:04 PM
>> The relevant source code is:
>>
>>  > After="InstallValidate" />
>>
>>
>> Where should I schedule it instead?
>>
>> --
>> Tom
>>
>>
>> Wilson, Phil wrote:
>> > Where is your RemoveExistingProducts sequenced? A
>> major upgrade will not use file update rules if it's
>> sequenced early in the install, such as just after
>> InstallInitialize.
>> >
>> > Phil Wilson
>> >
>> >
>> > -Original Message-
>> > From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf
>> Of Thomas Singer
>> > Sent: Wednesday, July 09, 2008 12:25 AM
>> > To: General discussion for Windows Installer XML
>> toolset.
>> > Subject: Re: [WiX-users] Prevent overwriting a
>> modified text file when upgrading
>> >
>> > I want to add: I've read in the mailing list
>> archive, that the installer by
>> > default should *keep* the file, but for our tests it
>> definitely
>> > overwrites/uninstalls the file.
>> >
>> > --
>> > Tom
>> >
>> >
>> > Thomas Singer wrote:
>> >> Our installers install also a configuration (text)
>> file where - if necessary
>> >> - the user can configure some options to run our
>> application. Unfortunately,
>> >> it will be overwritten without request when
>> installing an upgrade (different
>> >> Product Id, different Product Version) using
>> "msiexec /i ". We are
>> >> using WiX 3.0.4227.0.
>> >>
>> >> How we can prevent overwriting this file?
>> >>
>> >> --
>> >> Thanks in advance,
>> >> Tom
>> >
>> >
>> >
>> -
>> > Sponsored by: SourceForge.net Community Choice Awards:
>> VOTE NOW!
>> > Studies have shown that voting for your favorite open
>> source project,
>> > along with a healthy diet, reduces your potential for
>> chronic lameness
>> > and boredom. Vote Now at
>> http://www.sourceforge.net/community/cca08
>> > ___
>> > WiX-users mailing list
>> > WiX-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wix-users
>> >
>> >
>> >
>> >
>> -
>> > Sponsored by: SourceForge.net Community Choice Awards:
>> VOTE NOW!
>> > Studies have shown that voting for your favorite open
>> source project,
>> > along with a healthy diet, reduces your potential for
>> chronic lameness
>> > a

Re: [WiX-users] Explicit Deny permissions

[Rob Mensching]

Not sure the PermissionEx supports the deny as you want it right now.  I am 
certain that the Permission (which translates to LockPermission table) does 
*not*.  Of course, PermissionEx is our own extension/custom action so it can be 
extended...

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 09, 2008 13:53
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Explicit Deny permissions

I'm trying to 'ADD' [to existing permissions] an explicit deny permission on 
BUILTIN\Users for "Traverse Folder / Execute File", for "Subfolders and files 
only".

I'll spare you all the gory details of what I've all tried [Permission and the 
util:PermissionEx elements (from within a "CreateFolder" element], and simply, 
humbly ask, does anybody know how to do this?  (Is it even possible to do this 
with either of these elements within WiX?)









-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Unable to execute commonds on commnad prompt..

[Kalvagadda, SivaKrishna (GMIT-TASS)]

Thanks for your reply...

I tried with below code but no luck :(


 

As you suggested I spited into two actions.

But I couldn't understand what does the property attribute refers to in
below sample  (Property="StartWebServer").

Actually I want to run .bat files from WIX.

Thanks one more time for reply.

Please help me on this.


Regards,
SivaKrishna Kalvagadda,
201-671-5552.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil
Sleightholm
Sent: Wednesday, July 09, 2008 4:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Unable to execute commonds on commnad prompt..

I think the problem is that you can't evaluate properties in the
ExeCommand attribute so you need to do it in two steps. Here is an
example that works for me:





  NOT
Installed
  NOT
Installed


I hope this helps,

Neil

Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Kalvagadda, SivaKrishna (GMIT-TASS)
Sent: 09 July 2008 20:29
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Unable to execute commonds on commnad prompt..

Hi All,

I am very much new to WIX. I am trying to implementing executing
commands on Command prompt.
I am using below code to do but its failing while installation.



 

Where .bat is placed on c:\ path.


I have tried with different methods like using properties. Please help
me on this.

Regards,
SivaKrishna Kalvagadda,
201-671-5552.


This message w/attachments (message) may be privileged, confidential or
proprietary, and if you are not an intended recipient, please notify the
sender, do not use or share it and delete it. Unless specifically
indicated, this message is not an offer to sell or a solicitation of any
investment products or other financial product or service, an official
confirmation of any transaction, or an official statement of Merrill
Lynch. Subject to applicable law, Merrill Lynch may monitor, review and
retain e-communications (EC) traveling through its networks/systems. The
laws of the country of each sender/recipient may impact the handling of
EC, and EC may be archived, supervised and produced in countries other
than the country in which you are located. This message cannot be
guaranteed to be secure or error-free. This message is subject to terms
available at the following link:
http://www.ml.com/e-communications_terms/. By messaging with Merrill
Lynch you consent to the foregoing.



-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Reference counting for new components in shared COM

[David Ruddock]

Hi all,

I was wondering how to correctly hand reference counting for components
in shared COM (say using an MSM). It seems to me that if two different
products are trying to use a same COM components and one upgrades it the
reference counting on any new components that are included will be
broken. I guess this is a breaking some component rule.

Is there a way in wix to fix this, i.e. perhaps rather than getting both
products to do the reference counting of the individual components
within the shared MSM, rather treating the whole shared COM as a product
as a whole. (Is bootstrapping the installer he only way to do this, or
is there a neater solution?)

Cheers, David


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Explicit Deny permissions

[John Nannenga]

Bummer.  Is this something I should log a feature request for (to add 
functionality to the PermissionEx CA)?




From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Rob Mensching [EMAIL 
PROTECTED]
Sent: Wednesday, July 09, 2008 8:21 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Explicit Deny permissions

Not sure the PermissionEx supports the deny as you want it right now.  I am 
certain that the Permission (which translates to LockPermission table) does 
*not*.  Of course, PermissionEx is our own extension/custom action so it can be 
extended...

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 09, 2008 13:53
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Explicit Deny permissions

I'm trying to 'ADD' [to existing permissions] an explicit deny permission on 
BUILTIN\Users for "Traverse Folder / Execute File", for "Subfolders and files 
only".

I'll spare you all the gory details of what I've all tried [Permission and the 
util:PermissionEx elements (from within a "CreateFolder" element], and simply, 
humbly ask, does anybody know how to do this?  (Is it even possible to do this 
with either of these elements within WiX?)









-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Re ference counting for new components in shared COM

[jmcfadyen]

hmmm your wording is a little confusing. 

the idea of using MM's is so that you gain referencing counting by proxy of
the components within the MM's being static. 

this post explains exactly how component reference counting works. 

http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!136.entry

you point on upgrading a component may mean that the com component should
still maintain counting. 

for example of a com component is upgraded, and assuming the developer /
manufacturer followed backwards compatibility rules then the component
should maintain the same component code. Where the component is not
backwards compatible you should generate new component ID's. this is
difficult to know as an application packaging and not the dev. 

now back to your post what did you mean by "I guess this is a breaking some
component rule"



wix-users-8 wrote:
> 
> Hi all,
> 
> I was wondering how to correctly hand reference counting for components
> in shared COM (say using an MSM). It seems to me that if two different
> products are trying to use a same COM components and one upgrades it the
> reference counting on any new components that are included will be
> broken. I guess this is a breaking some component rule.
> 
> Is there a way in wix to fix this, i.e. perhaps rather than getting both
> products to do the reference counting of the individual components
> within the shared MSM, rather treating the whole shared COM as a product
> as a whole. (Is bootstrapping the installer he only way to do this, or
> is there a neater solution?)
> 
> Cheers, David
> 
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Reference-counting-for-new-components-in-shared-COM-tp18374549p18374877.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Limited User Account, first-run problem

[Adam Langley]

Hi guys,

I have a question that will probably have a simple and obvious answer...
I have built a WiX MSI, where registry keys are installed under HKCU,
and the application is installed with the administrator account - it is
required to run under minimal user privileges.
When the 'underprivileged user' starts the application for the first
time - Windows Installer must obviously create the HKCU keys for that
user.
What I don't understand, is that Windows Installer expects to find the
MSI in the same location as when it was originally installed - network
drive, USB memory etc.
This is obviously a problem, when the user does not have access to any
of those resources.

It was my understanding that the MSI is copied to some system folder, so
that Repairs and Changes can be made from Add/Remove programs without
needing the original MSI. Why isn't this copy of the MSI also used for
setting up the new user?

Thanks in advance!

Adam Langley
Senior Developer
Tel: +64 9 486 9010
www.winscribe.com

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Limited User Account, first-run problem

[Rob Mensching]

Something is causing "source resolution".  Look in a verbose log file to see 
what caused it.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Langley
Sent: Wednesday, July 09, 2008 20:36
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Limited User Account, first-run problem

Hi guys,

I have a question that will probably have a simple and obvious answer...
I have built a WiX MSI, where registry keys are installed under HKCU,
and the application is installed with the administrator account - it is
required to run under minimal user privileges.
When the 'underprivileged user' starts the application for the first
time - Windows Installer must obviously create the HKCU keys for that
user.
What I don't understand, is that Windows Installer expects to find the
MSI in the same location as when it was originally installed - network
drive, USB memory etc.
This is obviously a problem, when the user does not have access to any
of those resources.

It was my understanding that the MSI is copied to some system folder, so
that Repairs and Changes can be made from Add/Remove programs without
needing the original MSI. Why isn't this copy of the MSI also used for
setting up the new user?

Thanks in advance!

Adam Langley
Senior Developer
Tel: +64 9 486 9010
www.winscribe.com

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Limited User Account, first-run problem

[jmcfadyen]

the copy of the msi at c:\windows\installer is only a partial cache.. 

there are no files in this copy. As such any file replacements will use the
original install source as its healing point. 



Rob Mensching-2 wrote:
> 
> Something is causing "source resolution".  Look in a verbose log file to
> see what caused it.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Adam Langley
> Sent: Wednesday, July 09, 2008 20:36
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Limited User Account, first-run problem
> 
> Hi guys,
> 
> I have a question that will probably have a simple and obvious answer...
> I have built a WiX MSI, where registry keys are installed under HKCU,
> and the application is installed with the administrator account - it is
> required to run under minimal user privileges.
> When the 'underprivileged user' starts the application for the first
> time - Windows Installer must obviously create the HKCU keys for that
> user.
> What I don't understand, is that Windows Installer expects to find the
> MSI in the same location as when it was originally installed - network
> drive, USB memory etc.
> This is obviously a problem, when the user does not have access to any
> of those resources.
> 
> It was my understanding that the MSI is copied to some system folder, so
> that Repairs and Changes can be made from Add/Remove programs without
> needing the original MSI. Why isn't this copy of the MSI also used for
> setting up the new user?
> 
> Thanks in advance!
> 
> Adam Langley
> Senior Developer
> Tel: +64 9 486 9010
> www.winscribe.com
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Reference-counting-for-new-components-in-shared-COM-tp18374549p18376095.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Limited User Account, first-run problem

[Christopher Painter]

MSI caches a stripped package under windows\installer\{guid}.  In some 
situations thats enough and in some situations, the original package ( as 
specified in the Sourcelist HKCR\Installer\Products\PackgedGUID\Sourcelist ) is 
needed.   Sometimes it's not really needed but if ResolveSource is scheduled, 
it will be needed regardless.

Generally for ISV situations I use a bootstrapper and custom action to cache 
and later cleanup the full package on the local filesystem.   


Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves 
attention? E-Mail Me


--- On Wed, 7/9/08, Adam Langley <[EMAIL PROTECTED]> wrote:

> From: Adam Langley <[EMAIL PROTECTED]>
> Subject: [WiX-users] Limited User Account, first-run problem
> To: "General discussion for Windows Installer XML toolset." 
> 
> Date: Wednesday, July 9, 2008, 10:35 PM
> Hi guys,
> 
> I have a question that will probably have a simple and
> obvious answer...
> I have built a WiX MSI, where registry keys are installed
> under HKCU,
> and the application is installed with the administrator
> account - it is
> required to run under minimal user privileges.
> When the 'underprivileged user' starts the
> application for the first
> time - Windows Installer must obviously create the HKCU
> keys for that
> user.
> What I don't understand, is that Windows Installer
> expects to find the
> MSI in the same location as when it was originally
> installed - network
> drive, USB memory etc.
> This is obviously a problem, when the user does not have
> access to any
> of those resources.
> 
> It was my understanding that the MSI is copied to some
> system folder, so
> that Repairs and Changes can be made from Add/Remove
> programs without
> needing the original MSI. Why isn't this copy of the
> MSI also used for
> setting up the new user?
> 
> Thanks in advance!
> 
> Adam Langley
> Senior Developer
> Tel: +64 9 486 9010
> www.winscribe.com
> 
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE
> NOW!
> Studies have shown that voting for your favorite open
> source project,
> along with a healthy diet, reduces your potential for
> chronic lameness
> and boredom. Vote Now at
> http://www.sourceforge.net/community/cca08
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


  

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Prevent overwriting a modified text file when upgrading

[jmcfadyen]

Phil, yeah looks like we are on the same page in understanding.  (nice book
by the way it has helped me alot) 


In this case however the OP mentioned he did not want the overwrite effect
of REP being early. 

On another note you could also look at marking the component not to be
uninstalled. (this can have both positive and negative side affects)
understanding component rules would go a long way here. I believe Rob M
wrote a great post on component rules somewhere. Unfortunately I don't have
a link handy perhaps Rob can assist with that link reference. 



Wilson, Phil wrote:
> 
> What's happening when REP is just after InstallValidate ("early in the
> install") is that the older product is uninstalled and then the new one is
> installed. In this situation Tom's data file just gets removed and then
> installed by the new product.
> 
> When REP is "late" in the install the new product is installed on top of
> the older version, during which the file overwrite rules are used and
> component ref counts are incremented (so your guids should be consistent
> for files you care about, and Chris's side effects). Then the "uninstall"
> happens, which mainly consists of decrementing the component ref counts.
> 
> So I think we're both saying the same thing, and I don't think my earlier
> statement that "A major upgrade will not use file update rules if it's
> sequenced early in the install, such as just after InstallInitialize"
> contradicts anything you're saying.
> 
> Phil Wilson
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of jmcfadyen
> Sent: Wednesday, July 09, 2008 4:53 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Prevent overwriting a modified text file when
> upgrading
> 
> 
> Phil are you sure about this.. (not trying to be difficult I would be
> interested to understand what your getting at here.)
> 
> My understanding of the sequencing relating to upgrades is the opposite of
> what you suggest.
> 
> by moving the RemoveExistingProducts action earlier in the sequences you
> are
> effectively removing the older product prior to installing the new one.
> 
> By leaving the RemoveExistingProducts later in the sequences you will have
> the opportunity to leave components on the machine during installation of
> the newer version. See this post for more details as its quite complex to
> explain. This would require that you match component ID on the items you
> did
> not wish to upgrade.
> 
> http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!249.entry
> 
> 
> 
> Christopher Painter-2 wrote:
>>
>> Read:
>>
>> http://msdn.microsoft.com/en-us/library/aa371197(VS.85).aspx
>>
>> Do be advised that if you aren't following good versioning patterns
>> upstream and you move the the action in the sequence, you might see other
>> adverse side effects.
>>
>>
>> Christopher Painter, Author of Deployment Engineering Blog
>> Have a hot tip, know a secret or read a really good thread that deserves
>> attention? E-Mail Me
>>
>>
>> --- On Wed, 7/9/08, Thomas Singer <[EMAIL PROTECTED]> wrote:
>>
>>> From: Thomas Singer <[EMAIL PROTECTED]>
>>> Subject: Re: [WiX-users] Prevent overwriting a modified text file when
>>> upgrading
>>> To: "General discussion for Windows Installer XML toolset."
>>> 
>>> Date: Wednesday, July 9, 2008, 2:04 PM
>>> The relevant source code is:
>>>
>>>  >> After="InstallValidate" />
>>>
>>>
>>> Where should I schedule it instead?
>>>
>>> --
>>> Tom
>>>
>>>
>>> Wilson, Phil wrote:
>>> > Where is your RemoveExistingProducts sequenced? A
>>> major upgrade will not use file update rules if it's
>>> sequenced early in the install, such as just after
>>> InstallInitialize.
>>> >
>>> > Phil Wilson
>>> >
>>> >
>>> > -Original Message-
>>> > From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf
>>> Of Thomas Singer
>>> > Sent: Wednesday, July 09, 2008 12:25 AM
>>> > To: General discussion for Windows Installer XML
>>> toolset.
>>> > Subject: Re: [WiX-users] Prevent overwriting a
>>> modified text file when upgrading
>>> >
>>> > I want to add: I've read in the mailing list
>>> archive, that the installer by
>>> > default should *keep* the file, but for our tests it
>>> definitely
>>> > overwrites/uninstalls the file.
>>> >
>>> > --
>>> > Tom
>>> >
>>> >
>>> > Thomas Singer wrote:
>>> >> Our installers install also a configuration (text)
>>> file where - if necessary
>>> >> - the user can configure some options to run our
>>> application. Unfortunately,
>>> >> it will be overwritten without request when
>>> installing an upgrade (different
>>> >> Product Id, different Product Version) using
>>> "msiexec /i ". We are
>>> >> using WiX 3.0.4227.0.
>>> >>
>>> >> How we can prevent overwriting this file?
>>> >>
>>> >> --
>>> >> Thanks in advance,
>>> >> Tom
>>> >
>>> >
>>> >
>>> -
>>> > Sponsored by: SourceForge.net Community Choice Aw