[WiX-users] Using x86 screensaver on x64

[Chris Mumford]

I have an x86 screensaver that unfortunately needs to remain so at present
because it uses COM objects that are still x86. I can install this on an x64
system and the *.scr file runs OK, but doesn't show up as a screensaver
because it's in %sys32%\SysWow64. I can right-click on the *.scr file in the
SysWow64 folder, select "Install" and then it does show up as a screensaver.
So this appears to be an installation problem and it seems like if I just
knew what registry setting to set then my x86 screensaver would show up. Has
anybody had experience with this problem?
--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Possible to create an installation report?

[Chris Mumford]

Yes, but that isn't suitable for giving to a non-developer so I'd have to
write some kind of script to parse it to produce a report.

On Sat, Oct 18, 2008 at 9:42 AM, Michael Owings <[EMAIL PROTECTED]> wrote:

> If they're not that picky, there's always the installation log. Ithe log
> also has the advantage of being pretty precise as to the changes made.
>
> Chris Mumford wrote:
> > I've got a customer asking me what files and registry values my installer
> > creates. I'm thinking of something like MakeMSI's installation
> > report<http://makemsi-manual.dennisbareis.com/sample.htm>.
> > I understand that a report like this isn't that valuable because of
> > conditional logic and differences between different operating systems,
> but
> > I'd like to satisfy this request.
> >
> > I remember coming across a tool that would record an installation and
> > generate a report, but after 30 min. or so I can't seem to dig it up
> > anywhere. Any suggestions?
> > -
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
>
>
> --
> Teleoperate a roving mobile robot from the web:
> http://www.swampgas.com/robotics/rover.html
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Possible to create an installation report?

[Chris Mumford]

I've got a customer asking me what files and registry values my installer
creates. I'm thinking of something like MakeMSI's installation
report.
I understand that a report like this isn't that valuable because of
conditional logic and differences between different operating systems, but
I'd like to satisfy this request.

I remember coming across a tool that would record an installation and
generate a report, but after 30 min. or so I can't seem to dig it up
anywhere. Any suggestions?
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Manual un-install

[Chris Mumford]

I think you want to use msizap.

On Thu, Jul 24, 2008 at 12:51 PM, Eric Latendresse <
[EMAIL PROTECTED]> wrote:

> How can I manually un-install a setup? I get an error when I try to
> remove my setup from Add\Remove programs.
>
> Thanks,
>
>
>
> Eric
>
>
>
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Another newbie question: condition on custom action

[Chris Mumford]

I can't see anything obviously wrong here, but my suggestion is to create a
verbose log and see what the property values are:

msiexec /i setup.msi /l*vx Install.log

Also, if you aren't using it
Wilogutl.exeis
a nice tool to analyze the logs with.

On Mon, Jul 14, 2008 at 3:16 PM, Amir Kolsky <[EMAIL PROTECTED]>
wrote:

> Anyone? HELP?
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Amir
> Kolsky
>  Sent: Sunday, July 13, 2008 11:25 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Another newbie question: condition on custom
> action
>
> OK... So this, I don't get...
>
> Given:
>
>  
>
>  
>
>
> Which *obviously* does not exist :-)
> Why does:
>  
>IT_EXISTS AND NOT Installed
>  
> Get invoked?
>
> Thanks!
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Amir
> Kolsky
> Sent: Saturday, July 12, 2008 4:38 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Another newbie question: condition on custom
> action
>
> That would be a good thing to write in the chm
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rob
> Mensching
> Sent: Saturday, July 12, 2008 2:12 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Another newbie question: condition on custom
> action
>
> Yes.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Amir
> Kolsky
> Sent: Saturday, July 12, 2008 13:33
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Another newbie question: condition on custom
> action
>
> This means "the condition that determines if the action will be taken,
> calculated just prior to taking the action?"
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rob
> Mensching
> Sent: Saturday, July 12, 2008 9:12 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Another newbie question: condition on custom
> action
>
> Uhh, yeah.  You asked how to "condition a custom action" and that says
> "specifies the condition of the action".  Am I missing something?  Is
> there some way we could make the documentation clearer?
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Amir
> Kolsky
> Sent: Friday, July 11, 2008 17:27
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Another newbie question: condition on custom
> action
>
> Are you referring to this?
>
> *Inner Text (xs:string)*
>Text node specifies the condition of the action.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rob
> Mensching
> Sent: Friday, July 11, 2008 5:04 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Another newbie question: condition on custom
> action
>
> See the text of the Custom element in the WiX.chm.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Amir
> Kolsky
> Sent: Friday, July 11, 2008 15:03
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Another newbie question: condition on custom action
>
> Hi All!
>
>
>
> How do I  a custom action (basically for NOT installed)?
>
> I tried to put it in a fragment but then it stops the uninstall dead.
>
> The level=0 is only accepted inside Features, but this is and install
> sequence thing...
>
>
>
> This must be trivial, what am I missing?
>
>
>
> Thanks, Amir
>
>
>
> 
> -
> 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
>
> __
> This email has been scanned by the MessageLabs Email Security Sys

Re: [WiX-users] Another newbie question: condition on custom action

[Chris Mumford]

I think that having examples in the documentation would help out immensely.

On Sat, Jul 12, 2008 at 9:12 AM, Rob Mensching <[EMAIL PROTECTED]>
wrote:

> Uhh, yeah.  You asked how to "condition a custom action" and that says
> "specifies the condition of the action".  Am I missing something?  Is there
> some way we could make the documentation clearer?
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Amir Kolsky
>  Sent: Friday, July 11, 2008 17:27
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Another newbie question: condition on custom
> action
>
> Are you referring to this?
>
> *Inner Text (xs:string)*
>Text node specifies the condition of the action.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rob
> Mensching
> Sent: Friday, July 11, 2008 5:04 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Another newbie question: condition on custom
> action
>
> See the text of the Custom element in the WiX.chm.
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Amir
> Kolsky
> Sent: Friday, July 11, 2008 15:03
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Another newbie question: condition on custom action
>
> Hi All!
>
>
>
> How do I  a custom action (basically for NOT installed)?
>
> I tried to put it in a fragment but then it stops the uninstall dead.
>
> The level=0 is only accepted inside Features, but this is and install
> sequence thing...
>
>
>
> This must be trivial, what am I missing?
>
>
>
> Thanks, Amir
>
>
>
> 
> -
> 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
>
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> __
>
> -
> 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
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] General Merge Module Questions

[Chris Mumford]

OK, so you're talking about this page
http://msdn.microsoft.com/en-us/library/aa370530(VS.85).aspx. Thanks for the
info.

On Fri, Jul 4, 2008 at 4:17 AM, Rob Mensching <[EMAIL PROTECTED]>
wrote:

> Mean by what?  Modularization?  Modularization is the process of adding the
> Module Guid as a ".G_U_I_D" to the end of all the primary key identifiers in
> the MSI.  The MSI SDK talks about this process in detail.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Chris Mumford
> Sent: Thursday, July 03, 2008 16:36
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] General Merge Module Questions
>
> Hey Rob, could you elaborate on what you mean by that? Have you already
> discussed this elsewhere?
>
> On Thu, Jun 26, 2008 at 5:36 PM, Rob Mensching <
> [EMAIL PROTECTED]>
> wrote:
>
> > Correct, .wixlibs won't help you there.  Unfrotunately, that means you're
> > stuck fighting with the Modularization of identities to get things to all
> > line up.
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:
> > [EMAIL PROTECTED] On Behalf Of Christopher Karper
> > Sent: Thursday, June 26, 2008 15:28
> > To: General discussion for Windows Installer XML toolset.
> >  Subject: Re: [WiX-users] General Merge Module Questions
> >
> > But the other installations are built with InstallShield.   They won't
> work
> > with .wixlibs, will they?
> >
> > On Thu, Jun 26, 2008 at 6:01 PM, Rob Mensching <
> > [EMAIL PROTECTED]>
> > wrote:
> >
> > > I would recommend .wixlibs instead of .msm files (unless you have share
> > > your Merge Modules with people that don't use WiX).  .wixlibs are far
> > more
> > > flexible than Merge Modules.
> > >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:
> > > [EMAIL PROTECTED] On Behalf Of Christopher
> Karper
> > > Sent: Thursday, June 26, 2008 13:59
> > > To: General discussion for Windows Installer XML toolset.
> > > Subject: [WiX-users] General Merge Module Questions
> > >
> > > OK, I am redoing some of my installations to be in merge modules.  Now,
> I
> > > have no idea what I'm doing, so it's kind of learn as I go.  I'm stuck
> in
> > a
> > > few spots, and was hoping someone out here would be kind enough to help
> > me.
> > > :-)
> > >
> > > I am installing a .NET web application, which is why this gets
> > complicated.
> > >
> > >
> > > * I have all the files to install.  This was pretty straightforward.
> > > * I have some config changes to apply.  I had this working in the .msi,
> > but
> > > does the module have access to the public properties the containing MSI
> > > will
> > > have?  Is this the preferred method of getting data, or is there some
> > > mechanism for explicitly passing the information?  (something like
> > > CustomActionData for CAs)
> > > * I need to set up IIS properly.  This gets complicated since I want to
> > > allow a choice for a web site, or a virtual directory installation.
> >  Also,
> > > different versions of IIS are configured differently.   I don't mind
> > having
> > > a complicated set of conditions in my MSM, I just want to avoid making
> an
> > > MSM for each of these conditions.  Is this possible?
> > > * I am using the ASP.NET <http://asp.net/> <http://asp.net/> built in
> Membership
>  > providers, so I need to
> > > either
> > > run aspnet_config.exe, or directly run the SQL script against the
> > > datasource.  Is it possible to test for the existence of this database
> > > before running either of these?
> > >
> > > Thanks in advance for any assistance...  I'll take help for any or all
> of
> > > these questions.:-)
> > >
> > > Chris
> > >
> -
> > > Check out the new SourceForge.net Marketplace.
> > > It's the best place to buy or sell services for
> > > just about anything Open Source.
> > > http://sourceforge.net/services/buy/index.php
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > >
> ---

Re: [WiX-users] General Merge Module Questions

[Chris Mumford]

Hey Rob, could you elaborate on what you mean by that? Have you already
discussed this elsewhere?

On Thu, Jun 26, 2008 at 5:36 PM, Rob Mensching <[EMAIL PROTECTED]>
wrote:

> Correct, .wixlibs won't help you there.  Unfrotunately, that means you're
> stuck fighting with the Modularization of identities to get things to all
> line up.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Christopher Karper
> Sent: Thursday, June 26, 2008 15:28
> To: General discussion for Windows Installer XML toolset.
>  Subject: Re: [WiX-users] General Merge Module Questions
>
> But the other installations are built with InstallShield.   They won't work
> with .wixlibs, will they?
>
> On Thu, Jun 26, 2008 at 6:01 PM, Rob Mensching <
> [EMAIL PROTECTED]>
> wrote:
>
> > I would recommend .wixlibs instead of .msm files (unless you have share
> > your Merge Modules with people that don't use WiX).  .wixlibs are far
> more
> > flexible than Merge Modules.
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:
> > [EMAIL PROTECTED] On Behalf Of Christopher Karper
> > Sent: Thursday, June 26, 2008 13:59
> > To: General discussion for Windows Installer XML toolset.
> > Subject: [WiX-users] General Merge Module Questions
> >
> > OK, I am redoing some of my installations to be in merge modules.  Now, I
> > have no idea what I'm doing, so it's kind of learn as I go.  I'm stuck in
> a
> > few spots, and was hoping someone out here would be kind enough to help
> me.
> > :-)
> >
> > I am installing a .NET web application, which is why this gets
> complicated.
> >
> >
> > * I have all the files to install.  This was pretty straightforward.
> > * I have some config changes to apply.  I had this working in the .msi,
> but
> > does the module have access to the public properties the containing MSI
> > will
> > have?  Is this the preferred method of getting data, or is there some
> > mechanism for explicitly passing the information?  (something like
> > CustomActionData for CAs)
> > * I need to set up IIS properly.  This gets complicated since I want to
> > allow a choice for a web site, or a virtual directory installation.
>  Also,
> > different versions of IIS are configured differently.   I don't mind
> having
> > a complicated set of conditions in my MSM, I just want to avoid making an
> > MSM for each of these conditions.  Is this possible?
> > * I am using the ASP.NET  built in Membership
> providers, so I need to
> > either
> > run aspnet_config.exe, or directly run the SQL script against the
> > datasource.  Is it possible to test for the existence of this database
> > before running either of these?
> >
> > Thanks in advance for any assistance...  I'll take help for any or all of
> > these questions.:-)
> >
> > Chris
> > -
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> > -
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> 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-u

[WiX-users] transform creation

[Chris Mumford]

I just wanted to make sure I'm not doing thing the hard way here. I'm
creating an inatallation and I want my customers to be able to modify some
its many properties. From what I can see they have the following options:

   1. Specify a property on the command line.
   2. Use Orca.
   3. Use a WiX tool (like torch).

These solutions have their problems:

   1. Setting lots of properties means a really long command line and it's
   error prone.
   2. Not "normal-user" friendly and huge download.
   3. Even less user friendly than #2 since it's a developer tool.

So instead I'm writing my own tool to use MSI.DLL to create a new modified
MSI and/or MST. I just wanted to check that I'm not doing things the hard
way here. Is this the best way to solve this problem?

Thanks,

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

Re: [WiX-users] Help me fix my mistake please...

[Chris Mumford]

BTW, it turned out that my previous installs did not have the ALLUSERS
property set (and were installed per-user), but my new ones do. That was the
issue. It took a while to track down because the log message:

FindRelatedProducts: current install is per-machine

never mentions the UpgradeCode, just the product code. I wound up doing a
RegistrySearch to detect these old products (fortunately only 3) and fail
the install with a CA if detected. I wish there was a good way to know they
are installed per-user w/o a CA, but this is good enough.
-Chris
On Tue, Jun 17, 2008 at 7:40 PM, Chris Mumford <[EMAIL PROTECTED]>
wrote:

> No (but that's good to know). I'm trying to upgrade version 2.3.1 to
> version 4.0.0.0 and that is the version that doesn't get removed.
>
>
> On Tue, Jun 17, 2008 at 9:49 AM, Wilson, Phil <[EMAIL PROTECTED]>
> wrote:
>
>> Major upgrades use only the first three fields of a ProductVersion, so
>> there's no distinction between 3.0.0.0 and 3.0.0.1.  Is that what you're
>> seeing?
>>
>> Phil Wilson
>>
>> -----Original Message-
>> From: [EMAIL PROTECTED] [mailto:
>> [EMAIL PROTECTED] On Behalf Of Chris Mumford
>> Sent: Monday, June 16, 2008 8:28 PM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: [WiX-users] Help me fix my mistake please...
>>
>> I learned a few years back not to change my upgrade code, unfortunately a
>> little too late. The good news is that I only changed it once. My current
>> WiX source is:
>>
>> >Language="1033" Version="$(var.Version)" Manufacturer="MyCompany"
>>UpgradeCode="9B672C80-9A35-4EA5-9A9B-7D7E3626E912">
>>
>>  ...
>>
>>  
>>>  IncludeMinimum="yes"
>>  Maximum="$(var.Version)"
>>  IncludeMaximum="no"
>>  Language="1033"
>>  Property="UPGRADE_OLD_VERSION" />
>>>  IncludeMinimum="no"
>>  OnlyDetect="yes"
>>  Language="1033"
>>  Property="NEWPRODUCTFOUND" />
>>
>>
>>  
>>>  IncludeMinimum="yes"
>>  Maximum="3.0.0.0"
>>  IncludeMaximum="no"
>>  Language="1033"
>>  Property="UPGRADE_ANCIENT_VERSION" />
>>  
>>
>> And what I'm seeing is that version 3.0.0.1 and later is being upgraded
>> properly, but prior versions (those having UpgradeCode
>> 9B672C80-9A35-4EA5-9A9B-7D7E3626E912) are not being uninstalled and are
>> left
>> on the machine.
>>
>> Can anybody spot what I'm doing wrong here?
>>
>> Thanks,
>>
>> -Chris
>> -
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>>
>> -
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSBuild inside Wix development

[Chris Mumford]

Thanks. I'm sure it's in there somewhere, but MSBuild is not Visual Studio -
it's part of .Net (oddly IMHO). And if you search the index for MSBuild
you'll find nothing at all, but if you "search" for it you will find the
link. I'm not saying that it isn't there, but I do think it's very easy to
miss.

Once I get my installer released, and once I feel I know enough to be
helpful to others (and this thread proves I'm not really there yet) I may
stop whining and start contributing this project. :-)

-Chris

On Wed, Jun 18, 2008 at 10:34 PM, Neil Enns <[EMAIL PROTECTED]> wrote:

> You can use it stand-alone, but it's also part of the Votive stuff that's
> significantly reworked in WiX v3. Assuming you installed WiX v3 on a machine
> that has VS on it you should be able to do File > New Project... and then
> pick WiX from the left nodes and create a new WiX project.
>
> This is in the WiX.chm file :) When you run the chm click on "Using WiX in
> Visual Studio" in the first page that shows up. There's 6 topics on it.
>
> Neil
>
> 
> From: [EMAIL PROTECTED] [
> [EMAIL PROTECTED] On Behalf Of Chris Mumford [
> [EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2008 9:52 PM
>  To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] MSBuild inside Wix development
>
> Well in part because these have evolved for a while and I've been using
> them
> for at least three years - possibly before wix.targets became part of the
> product? And in part because I had no idea they were there :-/
>
> I'm really glad you pointed this out, but it got me wondering (again) how I
> missed this??? Apparently this is part of Visual Studio 2008 and/or .Net
> 3.5. Man it sure would be nice to have this at least referenced in WiX.chm
> or the web site or did I just miss it?
>
> Well anyhow, thanks for pointing this out.
>
> On Tue, Jun 17, 2008 at 10:08 PM, Neil Enns <[EMAIL PROTECTED]>
> wrote:
>
> > Chris,
> >
> > I'm curious, why do you use this approach instead of the shipping
> > wix.targets build process that comes with WiX?
> >
> > Neil
> >
> > 
> > From: [EMAIL PROTECTED] [
> > [EMAIL PROTECTED] On Behalf Of Chris Mumford [
> > [EMAIL PROTECTED]
> > Sent: Tuesday, June 17, 2008 8:04 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] MSBuild inside Wix development
> >
> > You don't want to call MSBuild *from* WiX. Instead you want to mave
> MSBuild
> > call WiX. Attached is my MSBuild project file that calls candle.exe and
> > light.exe to build an MSI file.
> >
> > You can see that I have the path to the WiX bin folder hard-coded (and my
> > machine is x64). So as an improvement you could use the MSBuild Community
> > Tasks (http://msbuildtasks.tigris.org/) to read the registry (via
> > RegistryRead) to dynamically determine the install location of WiX.
> >
> > Hope this helps.
> >
> > -Chris
> >
> > On Tue, Jun 17, 2008 at 1:08 AM, Krishnan Senthilraj <
> > [EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > I am new to Wix and MSBuild area. I have one fundamental quention.
> > >
> > > I completed all the building of my application in MSBuild. Now I am
> > writing
> > > Wix construction. I was under impressing we can call the MSBuild
> project
> > > inside Wix.
> > >
> > > I am trying examples for this. But unfortunately I didn't get that. So
> I
> > > would like to confirm with this group that *Is it possible and workable
> > > solution to call the MSBuild project inside the Wix?*
> > >
> > > If answer is yes then please give some links/direction to acheive the
> > same.
> > >
> > > Cheers
> > > Senthilraj
> > >
> -
> > > Check out the new SourceForge.net Marketplace.
> > > It's the best place to buy or sell services for
> > > just about anything Open Source.
> > > http://sourceforge.net/services/buy/index.php
> > > ___
> > > WiX-users mailing list
> > > WiX-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > -
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to bu

Re: [WiX-users] MSBuild inside Wix development

[Chris Mumford]

Well in part because these have evolved for a while and I've been using them
for at least three years - possibly before wix.targets became part of the
product? And in part because I had no idea they were there :-/

I'm really glad you pointed this out, but it got me wondering (again) how I
missed this??? Apparently this is part of Visual Studio 2008 and/or .Net
3.5. Man it sure would be nice to have this at least referenced in WiX.chm
or the web site or did I just miss it?

Well anyhow, thanks for pointing this out.

On Tue, Jun 17, 2008 at 10:08 PM, Neil Enns <[EMAIL PROTECTED]> wrote:

> Chris,
>
> I'm curious, why do you use this approach instead of the shipping
> wix.targets build process that comes with WiX?
>
> Neil
>
> 
> From: [EMAIL PROTECTED] [
> [EMAIL PROTECTED] On Behalf Of Chris Mumford [
> [EMAIL PROTECTED]
> Sent: Tuesday, June 17, 2008 8:04 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] MSBuild inside Wix development
>
> You don't want to call MSBuild *from* WiX. Instead you want to mave MSBuild
> call WiX. Attached is my MSBuild project file that calls candle.exe and
> light.exe to build an MSI file.
>
> You can see that I have the path to the WiX bin folder hard-coded (and my
> machine is x64). So as an improvement you could use the MSBuild Community
> Tasks (http://msbuildtasks.tigris.org/) to read the registry (via
> RegistryRead) to dynamically determine the install location of WiX.
>
> Hope this helps.
>
> -Chris
>
> On Tue, Jun 17, 2008 at 1:08 AM, Krishnan Senthilraj <
> [EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I am new to Wix and MSBuild area. I have one fundamental quention.
> >
> > I completed all the building of my application in MSBuild. Now I am
> writing
> > Wix construction. I was under impressing we can call the MSBuild project
> > inside Wix.
> >
> > I am trying examples for this. But unfortunately I didn't get that. So I
> > would like to confirm with this group that *Is it possible and workable
> > solution to call the MSBuild project inside the Wix?*
> >
> > If answer is yes then please give some links/direction to acheive the
> same.
> >
> > Cheers
> > Senthilraj
> > -
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSBuild inside Wix development

[Chris Mumford]

You don't want to call MSBuild *from* WiX. Instead you want to mave MSBuild
call WiX. Attached is my MSBuild project file that calls candle.exe and
light.exe to build an MSI file.

You can see that I have the path to the WiX bin folder hard-coded (and my
machine is x64). So as an improvement you could use the MSBuild Community
Tasks (http://msbuildtasks.tigris.org/) to read the registry (via
RegistryRead) to dynamically determine the install location of WiX.

Hope this helps.

-Chris

On Tue, Jun 17, 2008 at 1:08 AM, Krishnan Senthilraj <
[EMAIL PROTECTED]> wrote:

> Hi,
>
> I am new to Wix and MSBuild area. I have one fundamental quention.
>
> I completed all the building of my application in MSBuild. Now I am writing
> Wix construction. I was under impressing we can call the MSBuild project
> inside Wix.
>
> I am trying examples for this. But unfortunately I didn't get that. So I
> would like to confirm with this group that *Is it possible and workable
> solution to call the MSBuild project inside the Wix?*
>
> If answer is yes then please give some links/direction to acheive the same.
>
> Cheers
> Senthilraj
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
http://schemas.microsoft.com/developer/msbuild/2003"; 
DefaultTargets="installer">

  
C:\Program Files (x86)\Windows Installer XML v3\bin

-ext WixNetFxExtension -ext WixUIExtension


1.0.0.0
  

  
  

  

  
  

  

  
  





http://timestamp.verisign.com/scripts/timstamp.dll 
VisibleStatement.msi" />

  

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help me fix my mistake please...

[Chris Mumford]

No (but that's good to know). I'm trying to upgrade version 2.3.1 to version
4.0.0.0 and that is the version that doesn't get removed.

On Tue, Jun 17, 2008 at 9:49 AM, Wilson, Phil <[EMAIL PROTECTED]>
wrote:

> Major upgrades use only the first three fields of a ProductVersion, so
> there's no distinction between 3.0.0.0 and 3.0.0.1.  Is that what you're
> seeing?
>
> Phil Wilson
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Chris Mumford
> Sent: Monday, June 16, 2008 8:28 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Help me fix my mistake please...
>
> I learned a few years back not to change my upgrade code, unfortunately a
> little too late. The good news is that I only changed it once. My current
> WiX source is:
>
> Language="1033" Version="$(var.Version)" Manufacturer="MyCompany"
>UpgradeCode="9B672C80-9A35-4EA5-9A9B-7D7E3626E912">
>
>  ...
>
>  
>  IncludeMinimum="yes"
>  Maximum="$(var.Version)"
>  IncludeMaximum="no"
>  Language="1033"
>  Property="UPGRADE_OLD_VERSION" />
>  IncludeMinimum="no"
>  OnlyDetect="yes"
>  Language="1033"
>  Property="NEWPRODUCTFOUND" />
>
>
>  
>  IncludeMinimum="yes"
>  Maximum="3.0.0.0"
>  IncludeMaximum="no"
>  Language="1033"
>  Property="UPGRADE_ANCIENT_VERSION" />
>  
>
> And what I'm seeing is that version 3.0.0.1 and later is being upgraded
> properly, but prior versions (those having UpgradeCode
> 9B672C80-9A35-4EA5-9A9B-7D7E3626E912) are not being uninstalled and are
> left
> on the machine.
>
> Can anybody spot what I'm doing wrong here?
>
> Thanks,
>
> -Chris
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Help me fix my mistake please...

[Chris Mumford]

I learned a few years back not to change my upgrade code, unfortunately a
little too late. The good news is that I only changed it once. My current
WiX source is:



  ...

  




  

  

And what I'm seeing is that version 3.0.0.1 and later is being upgraded
properly, but prior versions (those having UpgradeCode
9B672C80-9A35-4EA5-9A9B-7D7E3626E912) are not being uninstalled and are left
on the machine.

Can anybody spot what I'm doing wrong here?

Thanks,

-Chris
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Vista: per-user installation without administrator privileges

[Chris Mumford]

And BTW thanks for mentioning the deployment engineering blog. I never came
across that, but just subscribed to it.

On Tue, Jun 10, 2008 at 7:02 PM, Christopher Painter <[EMAIL PROTECTED]>
wrote:

> But you could write a bootstrapper that caches and tweaks the package based
> on user input before calling into the install.   I know of several tools and
> package authors that follow this pattern.
>
>
> 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 Tue, 6/10/08, Bob Arnson <[EMAIL PROTECTED]> wrote:
>
> From: Bob Arnson <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] Vista: per-user installation without administrator
> privileges
> To: "General discussion for Windows Installer XML toolset." <
> wix-users@lists.sourceforge.net>
> Date: Tuesday, June 10, 2008, 6:57 PM
>
> Andreas Hellwig wrote:
> > Is there a way to avoid the UAC for the Per-User installation, and only
> > get it for the Per-Machine installation?
> >
>
> No. Unfortunately, MSI in Vista puts the flag for no-elevation-required
> in the package summary info. That means you can't change it at install
> time, only at build time.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Source vs. target

[Chris Mumford]

yes, thanks a bunch Jason. Those little gem's helped me fiture out the
answer to my quetion.

On Tue, Jun 10, 2008 at 10:31 AM, Jason <[EMAIL PROTECTED]> wrote:

> I would highly suggest reading Rob's series of blog posts "Deciphering
> the MSI Directory table"..
> Part 1 - http://blogs.msdn.com/robmen/archive/2005/06/21/431294.aspx
> Part 2 - http://blogs.msdn.com/robmen/archive/2005/06/28/433241.aspx
> Part 3 - http://blogs.msdn.com/robmen/archive/2005/07/04/435572.aspx
> Part 4 - http://blogs.msdn.com/robmen/archive/2005/07/12/437912.aspx
> Part 5 - http://blogs.msdn.com/robmen/archive/2005/11/04/489346.aspx
> Part 6 -
> http://blogs.msdn.com/robmen/archive/2006/10/12/deciphering-the-msi-directory-table-part-6-standard-directories.aspx
> Part 7 -
> http://blogs.msdn.com/robmen/archive/2006/10/17/deciphering-the-msi-directory-table-part-7-directories-are-properties.aspx
>
> On Mon, Jun 9, 2008 at 11:12 PM, Chris Mumford <[EMAIL PROTECTED]>
> wrote:
> > Hey Neil:
> >
> > Thanks for responding. Sure, I do have other directories like:
> >
> > 
> > 
> > 
> > 
> > 
> >
> > But only 2 of these are direct children of the parent TARGETDIR folder so
> > things seem a bit arbitrary here. Why not just call the top level
> >  tag  since there really isn't the parent child
> > relationship that the file format suggests - at least suggests to me. The
> > larger mystery is the relatioship between the ID and the Name. I'm sure
> I'll
> > figure it out eventually...
> >
> > -Chris
> > On Sun, Jun 8, 2008 at 9:03 PM, Neil Enns <[EMAIL PROTECTED]>
> wrote:
> >
> >> What do you have underneath your  element? Generally you put
> >> another  element in to make the files go where you want, as
> in
> >> this example from "Authoring your first .wxs file" in the wix help:
> >>
> >>  
> >> 
> >>
> >>>> Guid='12345678-1234-1234-1234-123456789012'>
> >>       >> Source='readme.txt' />
> >>   
> >>
> >> 
> >>  
> >> I'm sure there's a rational reason for the cryptic first, required,
> >>  entry but I don't know it :)
> >>
> >> Neil
> >>
> >> 
> >> From: [EMAIL PROTECTED] [
> >> [EMAIL PROTECTED] On Behalf Of Chris Mumford [
> >> [EMAIL PROTECTED]
> >> Sent: Sunday, June 08, 2008 5:42 PM
> >> To: General discussion for Windows Installer XML toolset.
> >> Subject: [WiX-users] Source vs. target
> >>
> >> I'm ashamedly naive about a fairly core issue with WiX. Maybe you guys
> can
> >> clear this up for me. As I write my installer I've been thinking of the
> >> "source" files as those that I am installing, and the "target" as where
> >> they
> >> will be on the machine on which the install is being run.
> >>
> >> So right away I'm looking at the first directory element in my *.wxs
> file:
> >>
> >> 
> >> and I'm having a hard time figuring out what the heck this even means.
> The
> >> MSDN documetation for
> >> SourceDir<http://msdn.microsoft.com/en-us/library/aa371857(VS.85).aspx
> >> >just
> >> says, "The
> >> *SourceDir* property is the root directory that contains the source
> cabinet
> >> file or the source file tree of the installation package". Now since I
> >> never
> >> create or see a cabinet file when running WiX I'm assuming that this is
> the
> >> directory containing my MSI file when running the installation. But when
> I
> >> run the installation it's set to drive C:\ weven though my MSI is on a
> >> network share.
> >>
> >> -Chris
> >>
> -
> >> Check out the new SourceForge.net Marketplace.
> >> It's the best place to buy or sell services for
> >> just about anything Open Source.
> >> http://sourceforge.net/services/buy/index.php
> >> ___
> >> WiX-users mailing list
> >> WiX-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> -
> >> Check out the new SourceForge.net Mark

Re: [WiX-users] Adding files to msi

[Chris Mumford]

bump.

On Sat, Jun 7, 2008 at 6:26 PM, Chris Mumford <[EMAIL PROTECTED]> wrote:

> I have a requirement for the end user to be able to add files to my MSI
> before they deploy it to their machines.
>
> At present I wrote a program to use msi.dll to allow them to customize some
> properties - it writes out a modified *.msi file as well as a *.mst
> transform file.
>
> I see some discussion on the web about using Orca to add files, but I can't
> see any API to do this. Is it possible via the API?
>
> This needs to be very simple for the end user or I have to come up with a
> different solution.
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Source vs. target

[Chris Mumford]

Hey Neil:

Thanks for responding. Sure, I do have other directories like:







But only 2 of these are direct children of the parent TARGETDIR folder so
things seem a bit arbitrary here. Why not just call the top level
 tag  since there really isn't the parent child
relationship that the file format suggests - at least suggests to me. The
larger mystery is the relatioship between the ID and the Name. I'm sure I'll
figure it out eventually...

-Chris
On Sun, Jun 8, 2008 at 9:03 PM, Neil Enns <[EMAIL PROTECTED]> wrote:

> What do you have underneath your  element? Generally you put
> another  element in to make the files go where you want, as in
> this example from "Authoring your first .wxs file" in the wix help:
>
>  
> 
>
>Guid='12345678-1234-1234-1234-123456789012'>
>   Source='readme.txt' />
>   
>
> 
>  
> I'm sure there's a rational reason for the cryptic first, required,
>  entry but I don't know it :)
>
> Neil
>
> 
> From: [EMAIL PROTECTED] [
> [EMAIL PROTECTED] On Behalf Of Chris Mumford [
> [EMAIL PROTECTED]
> Sent: Sunday, June 08, 2008 5:42 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] Source vs. target
>
> I'm ashamedly naive about a fairly core issue with WiX. Maybe you guys can
> clear this up for me. As I write my installer I've been thinking of the
> "source" files as those that I am installing, and the "target" as where
> they
> will be on the machine on which the install is being run.
>
> So right away I'm looking at the first directory element in my *.wxs file:
>
> 
> and I'm having a hard time figuring out what the heck this even means. The
> MSDN documetation for
> SourceDir<http://msdn.microsoft.com/en-us/library/aa371857(VS.85).aspx
> >just
> says, "The
> *SourceDir* property is the root directory that contains the source cabinet
> file or the source file tree of the installation package". Now since I
> never
> create or see a cabinet file when running WiX I'm assuming that this is the
> directory containing my MSI file when running the installation. But when I
> run the installation it's set to drive C:\ weven though my MSI is on a
> network share.
>
> -Chris
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Source vs. target

[Chris Mumford]

I'm ashamedly naive about a fairly core issue with WiX. Maybe you guys can
clear this up for me. As I write my installer I've been thinking of the
"source" files as those that I am installing, and the "target" as where they
will be on the machine on which the install is being run.

So right away I'm looking at the first directory element in my *.wxs file:


and I'm having a hard time figuring out what the heck this even means. The
MSDN documetation for
SourceDirjust
says, "The
*SourceDir* property is the root directory that contains the source cabinet
file or the source file tree of the installation package". Now since I never
create or see a cabinet file when running WiX I'm assuming that this is the
directory containing my MSI file when running the installation. But when I
run the installation it's set to drive C:\ weven though my MSI is on a
network share.

-Chris
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Adding files to msi

[Chris Mumford]

I have a requirement for the end user to be able to add files to my MSI
before they deploy it to their machines.

At present I wrote a program to use msi.dll to allow them to customize some
properties - it writes out a modified *.msi file as well as a *.mst
transform file.

I see some discussion on the web about using Orca to add files, but I can't
see any API to do this. Is it possible via the API?

This needs to be very simple for the end user or I have to come up with a
different solution.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] newbie question about uninstalling

[Chris Mumford]

One small difference that I can see between yours and mine which is working
is that you don't specify the Language in your UpgradeVersion elements.

Also, this isn't required to upgrade, but to prevent downgrade:


  NEWAPPFOUND

Just making sure you had that too.

On Fri, May 30, 2008 at 9:36 AM, Weinstein, Scott <[EMAIL PROTECTED]>
wrote:

> Hello -
>
> For some reason my install packages is not detecting the prior install,
> and the upgrade process is not working. I'm unable to see what I've done
> wrong and hoping it's a simple thing.
>
> Here's what I have:
>
>
>  
>Version="$(var.Util-VersionDots)"
>
>UpgradeCode="85179051-c66c-4039-9be4-9afab9aa4e0e"
>
>Name="Client Deployment $(var.Util-VersionDots)"
>
>Language="1033"
>
>Manufacturer="Citi">
>
>
>
> Compressed="yes" />
>
>
>
>
>
>   Minimum="0.0.0.0" IncludeMaximum="no"
> Maximum="$(var.Util-VersionDots)"/>
>
>   Minimum="$(var.Util-VersionDots)"  OnlyDetect="yes"/>
>
>
>
>
>
>
>
>  
>
>
>
>
>
>
> When I increment the version, recompile, and install the new MSI - the
> prior files from the install remain, and a new entry in add/remove
> programs is created. I am able to confirm that the version is in fact
> increasing from the directory names - which include
> $(var.Util-VersionDots)
>
> I'm using WiX 3.0.4123.0 on XP.
>
> Any ideas?
>
> --Scott
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Can't find a file version

[Chris Mumford]

Can somebody help me figure out what I'm doing wrong here. I'm trying to
lookup a file path in the registry and then do a FileSearch to see if it
meets the minimum version I require. Here's my code:


  

  

So this sorta makes sense to me. RegistrySearch will get that registry value
and set the FLASH_FILE_PATH property to that value, but then FileSearch
never overwrites it. So I'm confused as to why FileSearch can be a child of
RegistrySearch???

I then found this
responsethat
helped me figure it out (sorta). The problem is that my search doesn't
even consult the registry and is hard coded to the file name: "flash9f.ocx".
So now when flash 10/11 comes out I'll probably think that no Flash is
installed and try to install flash 9. My current (sorta working) version
looks like this:


  



  

  

Is there maybe a better solution to this in WiX 3.0 that I'm overlooking, or
is this just a limitation in Windows Installer?
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Help with Flash merge module.

[Chris Mumford]

Hello again:

I'm looking for a little help integrating a merge module. I'm trying to
distribute the Adobe Flash player - and Adobe does distribute a merge
module. So I added a  tag inside a  and then added a
 into a  in my main installer.

Now I'm getting these errors:

"C:\Program Files (x86)\Windows Installer XML v3\bin\candle.exe" -ext
WixNetFxExtension -ext WixUIExtension Project.wxs
Microsoft (R) Windows Installer Xml Compiler version 3.0.4109.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.
"C:\Program Files (x86)\Windows Installer XML v3\bin\light.exe" -ext
WixNetFxExtension -ext WixUIExtension Project.wixobj
Microsoft (R) Windows Installer Xml Linker version 3.0.4109.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.
C:\chris\Project.wxs(139): warning LGHT1056: The Directory table contains a
row with primary key(s) 'CommonAppDataFolder' which cannot be merged from
the merge module '..\3rdparty\flashplayermergemodule.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.
C:\chris\Project.wxs(139): warning LGHT1056: The Directory table contains a
row with primary key(s) 'SystemFolder' which cannot be merged from the merge
module '..\3rdparty\flashplayermergemodule.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.
C:\chris\Project.wxs(139): warning LGHT1056: The Directory table contains a
row with primary key(s) 'ProgramFilesFolder' which cannot be merged from the
merge module '..\3rdparty\flashplayermergemodule.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.
C:\chris\Project.wxs(139): warning LGHT1056: The Directory table contains a
row with primary key(s) 'ProgramMenuFolder' which cannot be merged from the
merge module '..\3rdparty\flashplayermergemodule.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.
C:\chris\Project.wxs(127): warning LGHT1076: ICE09: Component: sys.log4net
is a non-permanent system component
C:\chris\Project.wxs(130): warning LGHT1076: ICE09: Component:
SystemCommonComponent is a non-permanent system component
C:\chris\Project.wxs(135): warning LGHT1076: ICE09: Component:
ScreensaverComponent is a non-permanent system component
light.exe : error LGHT0204: ICE27: 'SelfUnregModules' Action in
InstallExecuteSequence table in wrong place. Current: Selection, Correct:
Execution
light.exe : error LGHT0204: ICE27: Action: 'SelfUnregModules' in
InstallExecuteSequence table must come after the 'InstallValidate' action.
light.exe : error LGHT0204: ICE27: Action: 'SelfUnregModules' in
InstallExecuteSequence table must come after the 'InstallInitialize' action.
light.exe : error LGHT0204: ICE27: Action: 'InstallFiles' in
InstallExecuteSequence table must come before the 'SelfRegModules' action.
Current seq#: 4000. Dependent seq#: 2850.
light.exe : error LGHT0204: ICE27: 'ResolveSource' Action in
InstallUISequence table in wrong place. Current: Search, Correct: Costing
light.exe : error LGHT0204: ICE57: Component
'Flash.ocx.52442A12_0334_40E2_BC90_E3BE2AD2E349' has both per-user and
per-machine data with a per-machine KeyPath.
light.exe : error LGHT0204: ICE77: ISUnSelfRegisterFiles is a in-script
custom action.  It must be sequenced in between the InstallInitialize action
and the InstallFinalize action in the InstallExecuteSequence table
light.exe : error LGHT0204: ICE99: The directory name: PrimaryVolumePath is
the same as one of the MSI Public Properties and can cause unforeseen side
effects.
light.exe : error LGHT0204: ICE99: The directory name: WindowsVolume is the
same as one of the MSI Public Properties and can cause unforeseen side
effects.

What confuses me here (aside from the error messages) is that I have to put
the  element inside of one of my  elements. I mean I have
no idea whatsoever what files this merge module installs, and what
directories it puts them in. So why must I nest my reference to it in one of
my  tags?

thanks for any assistance - I'm SO confused.

-Chris
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Starting & stopping program during install & uninstall

[Chris Mumford]

Hi again:

During install I need to start a program that I've just installed, and I
also need to kill it during uninstall/upgrade.

I believe that I can just add a custom action to start it, but what about to
stop it? Is there a non CA solution to this problem?

Thanks!

-Chris
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] yep - back to being 100% frustrated

[Chris Mumford]

Definitely interesting commentary. I'd have to say that I agree with Richard
and mostly disagree with Markus' comment - although I see where he's coming
from. My guess is that his rules are mostly born from experience and he's
chosen the most pragmatic approach that seems likely to work. It's my
understanding that nearly all custom actions are improperly written and I
really want to try to create an installation with zero CA's if possible. I'm
sure that when I get to some crazy things like deleting files and registry
values (that no installer would ever want to do ) I'll have to
write a CA.

I did my first MSI somewhere around 8-9 years ago and have used most of the
major installer tools from Wise, InstallShield, WiX, and MakeMSI. It's been
a good five years since I've wrestled with Windows Installer - staying away
for obvious reasons.

So now I'm rewriting one of my installations (which has always had issues)
and I'm going to try to do it "right" with WiX. So I get it to install a few
files in the right folder, and my very next step is to create a simple
stupid shortcut - and it doesn't work with an ICE48 error. Searching around
didn't really turn up much, but there was a Google hit on Rob's site - which
was down - G.

Call me old fashioned but I think that any solution should make it easy to
do what 80% of the users want. Maybe this is a bad example but who cares a
flip about advertised features. I don't see this as a feature at all. It
just complicates our lives as installer writers and it complicates the lives
of the end user too. Sure this isn't a WiX thing - it's a *feature* of
Windows Installer, but man I wish WiX made things easier for us - and it
could.

Well anyhow, I've gotta get back to my day gig now. Thanks for your
thoughts.

BTW stay in touch Siva - I may be begging you forward my resume for that
security guard gig after a few more weeks of playing with this tech. ;-)

Cheers.

On Mon, May 12, 2008 at 11:53 AM, Markus Kuehni <[EMAIL PROTECTED]>
wrote:

>  Hi Chris
>
> I can only second your opinion. It's almost unbelievable, how difficult
> even the most common, primitive task is.
>
> One has this long-honed professional developer instinct that constantly
> tells you "there must be an easier way, I just have to find it". Believe me:
> in case of MSI there is none! Stop wasting your time searching for any sign
> of logic, design or even common sense.
>
> And it took me a while to realize, that WiX is only a wrapper. No
> abstraction whatsoever. So dont't blame WiX, except maybe for not making the
> "thin wrapper catch" clear from the beginning.
>
> It helps to cross the custom action / custom dialog barrier. Don't even
> try without, even if you think your application is plain vanilla!
>
> There has to be an awful lot of (pre-)historical bagagge that crippels
> MSIs "design" (to insult that word). I guess its a cross-breed between
> declarative and imperative princibles terribly gone wrong and awfully
> neglected since.
>
> Survival guide:
>
> 0. switch off your expectations
> 1. learn how to write custom actions and use them liberally
> 2. learn how to write custom dialogs and use them liberally
> 3. forget minor and small updates - use major upgrades only
> 4. realize that they only really thought of files and registry entries! 
> Shortcuts,
> .ini-file entries, in some cases even directories, etc. were seemingly
> "tacked on later" and are terribly crippled because they have to somehow
> "piggy back" either on a file, directory or registry key; use the ugly hacks
> in the internet and don't waste your time searching for elegance
> 5. realize the power of properties set through custom actions
> 6. realize the power of conditions (often you can't dynamically change
> even the simplest things, like i.e. the name of a shortcut. But you can
> switch OFF one component and switch ON another - sometimes that helps)
> 6. isolate everything in your application that remains absolutely static
> once it's deployed
> 7. then only(!) setup that static part with MSI/WiX
> 8. setup everything else (such as initial configuration, initial
> databases, etc.) either with a custom action or with your application (first
> run)
> 9. expect problems - this "technology" (to insult that word too) is
> gagging for trial and error (and shot deadlines)
>
>
> Hope that helps a bit.
>
> -Mark
>
>
>
>  --
> *Von:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *Im Auftrag von *Chris Mumford
> *Gesendet:* Montag, 12. Mai 2008 06:13
> *An:* wix-users@lists.sourceforge.net
> *Betreff:* [WiX-users] yep - back to

[WiX-users] yep - back to being 100% frustrated

[Chris Mumford]

Man:

I can't believe how much making Windows Installer based installs suck - I
mean really sucks! Did we just invent this technology to make us hate our
lives?

And WiX doesn't make it any easier.

I'm calling it a night.

Peace out man...
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Some STUPID Limitations in WiX

[Chris Mumford]

Hi Justin:

Even though your advice and comments to Dong are 100% correct I'm still
going easy on him. I've had many frustrating days with Windows
Installer/WiX. I would say that these are most surely issues with Windows
Installer's complexity and not WiX - however WiX's tendency to assume that
you are already a Windows Installer expert, and it's missing support for UI
(until recently) never helped matters.

On 9/25/07, Justin Rockwood <[EMAIL PROTECTED]> wrote:
>
> Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the
> WiX
> toolset, it's typically not a good idea to call it STUPID and then in the
> same sentence ask for help. You're biting the hand that feeds you. Plus if
> you think it's stupid then why would you trust the advice from the people
> that created it? At any rate, good luck with your "powerful installer."
> Since we don't really know how to build those (smile), you may want to
> take
> any advice we give with a grain of salt.
>
> Justin
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Dong Fang
> Xie
> (Excell Data Corporation)
> Sent: Tuesday, September 25, 2007 12:04 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Some STUPID Limitations in WiX
>
> I'm working on a small and simple installer using WiX toolset (the latest
> stable version 2.0.3719.0). To my surprise, it is really very very tough
> !!
> It almost drove me crazy.  I really don't understand why there are so many
> stupid limitations:
>
> LIMIT 1:
> Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why
> there is no ProcessSearch or TaskSearch ?!I need to know whether a
> specific process is running before installation/uninstallation.
>
> LIMIT 2:
> If all files in a msi package are from different small projects, I can
> build
> a module for each small project, and create a main wxs file to merge all
> modules. It should be a good idea, but how can I use the files from
> different modules ?  There is no way for now. I must control all custom
> actions in the main wxs file, and some custom actions need a FileKey to a
> file in a module. I cannot distribute all cutom actions in different
> modules, if I do so, how can I control the InstallSequence ? Using stupid
> numbers?
>
> LIMIT 3:
> I defined a dialog which must be shown not only during installation but
> also
> during uninstallation. But how to make it shown during uninstallation
> ?  the
> UILevel will be set to basic UI or no UI automatically by msiexec.exe
> .  How
> can I beg Windows NOT do that for me? I can use command "msiexec /qf /x
> msifile", but how can I know my customer can do that each time they want
> to
> uninstall the msi file ?  Is there any way I can define UILevel of
> uninstallation inside msi file ?
>
> WiX is a very good toolset, but far from perfect !  I bet the developers
> of
> WiX toolset have never built a powerful installer for customers.  I will
> never know the limit if I wasn't assigned the job to build a small and
> simple installer.
>
> I noticed that there are some extensions in WiX 3.0, but it is still far
> from enough.
>
> For LIMIT 1, I've built my own dll to detect running processes. But how to
> break LIMIT 2 and LIMIT 3 ?  Can you guys give me some ideas ?
>
> Thanks in advance
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] What do I do with per-user data when I uninstall?

[Chris Mumford]

I read a blog posting titled "What do I do with per-user data when I
uninstall?"
this morning and have often asked myself the same question. What do you
experts think?
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Copying a directory of files from SourceDir\subdir

[Chris Mumford]

Hey there:

I have an installation layout like this:

Setup.msi
CommonFiles/

where CommonFiles contain user configurable files. When I run the installer
I want to copy all of the files in the CommonFiles directory which is beside
my MSI into the:

%ALLUSERSPROFILE%\Application Data\MyProgram\CommonFiles directory.

Here is a snippet from my *.wxs file:



  

  

  

  

  
  
  
  

  

  


Looking at the setup log file it looks like the SOURCEDIR property is being
set after the D_CommonFilesSrc is set. Is there a good way to solve this?
I'm desperately trying to avoid creating any kind of custom actions.

Thanks for any help.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Yet another ICE38 question

[Chris Mumford]

Hi everyone:

Believe it or not I've been trying to solve this problem for about
five hours so needless to say I would love some help here!

My product installs a service and a screensaver. Because of the
service (and maybe the screensaver) I'm making the installation
require admin privileges to install. i.e. no per-user installations.

I'm trying to put a shortcut in the All Users programs menu. I've got
this code to create a menu in the Start/Program Files menu:


  

  


  

  

However, light.exe is giving me these warnings:

c:\chris\src\VisibleStatement-Vista\wix\VisibleStatement.wxs(40):
 error LGHT0204: ICE38: Component C_VisStmtStartMenu installs to user profile.
 It must use a registry key under HKCU as its KeyPath, not a file.

Now I do have this at the top of the file:



And am also setting the 
attribute. Is light/WMI just not smart enough to know that this isn't
a per-user install, or am I failing to specify something correctly.

Thanks in advance for any assistance. It' seems that others are just
as confused as I am.

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users