Re: [WiX-users] Merge Module Help

[James Minnis]

For major updates, changing the GUIDs should not matter as it does an
uninstall of the old version then an install of the new version.  I just
won't provide a patch to make that leap.  This should be acceptable because
it will be infrequent.

For smaller changes, a minor upgrade via patch should be doable with hand
updates, but it is very much not ideal.  The biggest problem with this is
the lag in the Visual Studio IDE when dealing with a roughly 3 MB XML file
for the merge module.  I can mitigate this to some extent by breaking it
into several smaller projects by subdirectory, but I'm unfortunately dealing
with a directory and file structure that cannot be changed (this installer
is for a mod for a video game).

I'm surprised that Heat doesn't have the functionality of leaving the
existing GUIDs in place.  I just presumed I wasn't seeing how to do it.

I'm familiar with merge modules from developing MSIs for work, so that was
my first thought when looking at Heat's options.  I haven't been able to
find any documentation on how to create a wixlib with Heat or how to include
a wixlib in a primary project.  A sample project featuring a wixlib would be
even better.  Do either documentation or a sample project exist somewhere?

-Jamey

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:wix-users-
> [EMAIL PROTECTED] On Behalf Of Christopher Karper
> Sent: Friday, July 18, 2008 5:52 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Merge Module Help
> 
> I can't really answer intelligently to question #1, as to question #2,
> I'll
> do my best.
> 
> Heat is really built for initial import functionality, not continual
> maintenance.  You do not want your GUIDs changing on your components with
> each build, it will turn upgrades into a nightmare, and will make patching
> just about impossible, IMO.   The "suggested" method, is to use heat.exe
> to
> build your .wxs up front, then manually maintain the .wxs file as part of
> your development process from there on out.   If someone adds an artifact
> to
> a project in a future version, they need to add it to the installer
> definition as well.
> 
> If you have the ability to go pure Wix with your installers, then you can
> break this into manageable chunks using a .wixlib project for each major
> subsystem, and having one parent .msi project link them all together.
> This
> is similar, but superior, to building .msm files and importing those in.
> If your "parent" project is not Wix, then you're stuck in the same boat I
> am, building .msm's.
> 
> Either way you're stuck making manual changes to the .wxs files to keep
> them
> in sync with your project's outputs and required support files.  I
> *really*
> wish this wasn't the case, as the whole point of using an IDE (for me) is
> to
> manage all the grunt work like that, but there are some pretty substantial
> complexities making it a pretty large undertaking that the team just
> hasn't
> gotten to yet.
> 
> Chris
> 
> On Fri, Jul 18, 2008 at 7:53 PM, James Minnis <[EMAIL PROTECTED]>
> wrote:
> 
> > I'm working on a fairly large installer.  It contains roughly 7000 files
> in
> > 165 folders and a total of 670 MB of uncompressed data.  Needless to
> say,
> > I'm generating the files, components, and directories using Heat.
> >
> > Right now, I'm generating a merge module WXS file using Heat and then
> using
> > the Merge and MergeRef elements in my main installer.  This is all
> working
> > correctly.  I have several questions related to this:
> >
> > 1) I want to create shortcuts to several of the files in the merge
> module.
> > I'm doing this currently in a start menu shortcuts component in the main
> > installer.  However, I cannot figure out how to reference the
> directories
> > in
> > the merge module in the main project (I get an empty string when I try
> to
> > reference them like I do the directories in the main installer project).
> > How do I reference the directories?  Or is there a better way to do
> this?
> >
> > 2) The components in the merge module are generated with GUIDs.  If I
> > regenerate the merge module WXS file using Heat (e.g. if I add files),
> > those
> > GUIDs change.  How will this affect patches?  Will the patch recognize
> the
> > files as being the same, or will it consider all of the files changed
> and
> > overwrite everything?  Will I need to add files manually to the merge
> > module
> > WXS file to make patching work correctly?
> >
> > -Jamey
> >
> >
> > 
> -
> > 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

Re: [WiX-users] Merge Module Help

[Christopher Karper]

I can't really answer intelligently to question #1, as to question #2, I'll
do my best.

Heat is really built for initial import functionality, not continual
maintenance.  You do not want your GUIDs changing on your components with
each build, it will turn upgrades into a nightmare, and will make patching
just about impossible, IMO.   The "suggested" method, is to use heat.exe to
build your .wxs up front, then manually maintain the .wxs file as part of
your development process from there on out.   If someone adds an artifact to
a project in a future version, they need to add it to the installer
definition as well.

If you have the ability to go pure Wix with your installers, then you can
break this into manageable chunks using a .wixlib project for each major
subsystem, and having one parent .msi project link them all together.  This
is similar, but superior, to building .msm files and importing those in.
If your "parent" project is not Wix, then you're stuck in the same boat I
am, building .msm's.

Either way you're stuck making manual changes to the .wxs files to keep them
in sync with your project's outputs and required support files.  I *really*
wish this wasn't the case, as the whole point of using an IDE (for me) is to
manage all the grunt work like that, but there are some pretty substantial
complexities making it a pretty large undertaking that the team just hasn't
gotten to yet.

Chris

On Fri, Jul 18, 2008 at 7:53 PM, James Minnis <[EMAIL PROTECTED]>
wrote:

> I'm working on a fairly large installer.  It contains roughly 7000 files in
> 165 folders and a total of 670 MB of uncompressed data.  Needless to say,
> I'm generating the files, components, and directories using Heat.
>
> Right now, I'm generating a merge module WXS file using Heat and then using
> the Merge and MergeRef elements in my main installer.  This is all working
> correctly.  I have several questions related to this:
>
> 1) I want to create shortcuts to several of the files in the merge module.
> I'm doing this currently in a start menu shortcuts component in the main
> installer.  However, I cannot figure out how to reference the directories
> in
> the merge module in the main project (I get an empty string when I try to
> reference them like I do the directories in the main installer project).
> How do I reference the directories?  Or is there a better way to do this?
>
> 2) The components in the merge module are generated with GUIDs.  If I
> regenerate the merge module WXS file using Heat (e.g. if I add files),
> those
> GUIDs change.  How will this affect patches?  Will the patch recognize the
> files as being the same, or will it consider all of the files changed and
> overwrite everything?  Will I need to add files manually to the merge
> module
> WXS file to make patching work correctly?
>
> -Jamey
>
>
> -
> 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] Merge Module Help

[James Minnis]

I'm working on a fairly large installer.  It contains roughly 7000 files in
165 folders and a total of 670 MB of uncompressed data.  Needless to say,
I'm generating the files, components, and directories using Heat.

Right now, I'm generating a merge module WXS file using Heat and then using
the Merge and MergeRef elements in my main installer.  This is all working
correctly.  I have several questions related to this:

1) I want to create shortcuts to several of the files in the merge module.
I'm doing this currently in a start menu shortcuts component in the main
installer.  However, I cannot figure out how to reference the directories in
the merge module in the main project (I get an empty string when I try to
reference them like I do the directories in the main installer project).
How do I reference the directories?  Or is there a better way to do this?

2) The components in the merge module are generated with GUIDs.  If I
regenerate the merge module WXS file using Heat (e.g. if I add files), those
GUIDs change.  How will this affect patches?  Will the patch recognize the
files as being the same, or will it consider all of the files changed and
overwrite everything?  Will I need to add files manually to the merge module
WXS file to make patching work correctly?

-Jamey


-
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] Help customizing FilesInUse Dialog

[Tony Juricic]

Disregard my previous comment. It is dialog ID which must remain
"FilesInUse", of course, everything else can be customized. 
In my case which requires a lot of customization I have pulled in the
entire WixUI_en-us.wxl and renamed it into CustomWixUI_en-us.wxl


-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 18, 2008 5:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help customizing FilesInUse Dialog

Taking this approach will require literally pulling in everything,
right? Including all the localization files for WiXUI_Minimal?

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Karper
Sent: Friday, July 18, 2008 1:58 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help customizing FilesInUse Dialog

Are you using votive?   And are you using the WixUIExtension?

If so, I would imagine you can skip the extension, and just fully
replace
the FilesInUse name.   Copy down all the rest of the UI wxs and just go
to
town.

Chris

On Fri, Jul 18, 2008 at 4:42 PM, Dan Giambalvo <
[EMAIL PROTECTED]> wrote:

> I'm in need of some help trying to customize the FilesInUse dialog for
my
> app's installer.  Our designers want to customize the look and feel of
the
> entire installer, so starting with WIXUI_Minimal I've been making
local
> copies of each dialog wxs file and then making modifications.  This
worked
> perfectly for all the non-required dialogs (like WelcomeEulaDlg) but
I'm now
> running into some issues with some of the "required" dialogs like
> FilesInUse.  Basically, if I change the name of my dialog to something
like
> MyAppFilesInUse and don't reference FilesInUse, then the installer
complains
> about a lack of a FilesInUse dlg.  If I instead name my dialog
FilesInUse,
> then I get a conflict because there are duplicates.
>
> Given the above, I'm at something of an Impasse.  I'm sure there's a
way to
> do this. Can someone offer some help?
>
> Thanks in advance!
> -Dan
>

-
> 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




-
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] Help customizing FilesInUse Dialog

[Dan Giambalvo]

I don't really need to customize it's name,  I simply want to override the 
default FilesInUse dialog.  If there was some way I could distinguish between 
the name that the dialog gets in the MSI and the way I reference it in my 
 I'd be all set.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic
Sent: Friday, July 18, 2008 2:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help customizing FilesInUse Dialog

I was under the impression that runtime requires this dialog to have
exactly FilesInUse name since it is invoked by installer, not by user.

IOW, its name cannot be customized.

-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 5:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help customizing FilesInUse Dialog

Taking this approach will require literally pulling in everything,
right? Including all the localization files for WiXUI_Minimal?

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Karper
Sent: Friday, July 18, 2008 1:58 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help customizing FilesInUse Dialog

Are you using votive?   And are you using the WixUIExtension?

If so, I would imagine you can skip the extension, and just fully
replace
the FilesInUse name.   Copy down all the rest of the UI wxs and just go
to
town.

Chris

On Fri, Jul 18, 2008 at 4:42 PM, Dan Giambalvo <
[EMAIL PROTECTED]> wrote:

> I'm in need of some help trying to customize the FilesInUse dialog for
my
> app's installer.  Our designers want to customize the look and feel of
the
> entire installer, so starting with WIXUI_Minimal I've been making
local
> copies of each dialog wxs file and then making modifications.  This
worked
> perfectly for all the non-required dialogs (like WelcomeEulaDlg) but
I'm now
> running into some issues with some of the "required" dialogs like
> FilesInUse.  Basically, if I change the name of my dialog to something
like
> MyAppFilesInUse and don't reference FilesInUse, then the installer
complains
> about a lack of a FilesInUse dlg.  If I instead name my dialog
FilesInUse,
> then I get a conflict because there are duplicates.
>
> Given the above, I'm at something of an Impasse.  I'm sure there's a
way to
> do this. Can someone offer some help?
>
> Thanks in advance!
> -Dan
>

-
> 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




-
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] Help customizing FilesInUse Dialog

[Tony Juricic]

I was under the impression that runtime requires this dialog to have
exactly FilesInUse name since it is invoked by installer, not by user.

IOW, its name cannot be customized.

-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 18, 2008 5:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help customizing FilesInUse Dialog

Taking this approach will require literally pulling in everything,
right? Including all the localization files for WiXUI_Minimal?

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Karper
Sent: Friday, July 18, 2008 1:58 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help customizing FilesInUse Dialog

Are you using votive?   And are you using the WixUIExtension?

If so, I would imagine you can skip the extension, and just fully
replace
the FilesInUse name.   Copy down all the rest of the UI wxs and just go
to
town.

Chris

On Fri, Jul 18, 2008 at 4:42 PM, Dan Giambalvo <
[EMAIL PROTECTED]> wrote:

> I'm in need of some help trying to customize the FilesInUse dialog for
my
> app's installer.  Our designers want to customize the look and feel of
the
> entire installer, so starting with WIXUI_Minimal I've been making
local
> copies of each dialog wxs file and then making modifications.  This
worked
> perfectly for all the non-required dialogs (like WelcomeEulaDlg) but
I'm now
> running into some issues with some of the "required" dialogs like
> FilesInUse.  Basically, if I change the name of my dialog to something
like
> MyAppFilesInUse and don't reference FilesInUse, then the installer
complains
> about a lack of a FilesInUse dlg.  If I instead name my dialog
FilesInUse,
> then I get a conflict because there are duplicates.
>
> Given the above, I'm at something of an Impasse.  I'm sure there's a
way to
> do this. Can someone offer some help?
>
> Thanks in advance!
> -Dan
>

-
> 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




-
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] Help customizing FilesInUse Dialog

[Dan Giambalvo]

Yup, I think so.  Basically, we'd take the Wix UIExtension project as it 
stands, tweak the dialogs, and then compile that into our main installer as if 
it's the real Wix UIExtension.  Of course, then we get into a much bigger 
maintenance situation.  I'm not thrilled about this.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, July 18, 2008 2:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help customizing FilesInUse Dialog

Taking this approach will require literally pulling in everything, right? 
Including all the localization files for WiXUI_Minimal?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Karper
Sent: Friday, July 18, 2008 1:58 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help customizing FilesInUse Dialog

Are you using votive?   And are you using the WixUIExtension?

If so, I would imagine you can skip the extension, and just fully replace
the FilesInUse name.   Copy down all the rest of the UI wxs and just go to
town.

Chris

On Fri, Jul 18, 2008 at 4:42 PM, Dan Giambalvo <
[EMAIL PROTECTED]> wrote:

> I'm in need of some help trying to customize the FilesInUse dialog for my
> app's installer.  Our designers want to customize the look and feel of the
> entire installer, so starting with WIXUI_Minimal I've been making local
> copies of each dialog wxs file and then making modifications.  This worked
> perfectly for all the non-required dialogs (like WelcomeEulaDlg) but I'm now
> running into some issues with some of the "required" dialogs like
> FilesInUse.  Basically, if I change the name of my dialog to something like
> MyAppFilesInUse and don't reference FilesInUse, then the installer complains
> about a lack of a FilesInUse dlg.  If I instead name my dialog FilesInUse,
> then I get a conflict because there are duplicates.
>
> Given the above, I'm at something of an Impasse.  I'm sure there's a way to
> do this. Can someone offer some help?
>
> Thanks in advance!
> -Dan
> -
> 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


-
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] Help customizing FilesInUse Dialog

[Neil Enns]

Taking this approach will require literally pulling in everything, right? 
Including all the localization files for WiXUI_Minimal?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Karper
Sent: Friday, July 18, 2008 1:58 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Help customizing FilesInUse Dialog

Are you using votive?   And are you using the WixUIExtension?

If so, I would imagine you can skip the extension, and just fully replace
the FilesInUse name.   Copy down all the rest of the UI wxs and just go to
town.

Chris

On Fri, Jul 18, 2008 at 4:42 PM, Dan Giambalvo <
[EMAIL PROTECTED]> wrote:

> I'm in need of some help trying to customize the FilesInUse dialog for my
> app's installer.  Our designers want to customize the look and feel of the
> entire installer, so starting with WIXUI_Minimal I've been making local
> copies of each dialog wxs file and then making modifications.  This worked
> perfectly for all the non-required dialogs (like WelcomeEulaDlg) but I'm now
> running into some issues with some of the "required" dialogs like
> FilesInUse.  Basically, if I change the name of my dialog to something like
> MyAppFilesInUse and don't reference FilesInUse, then the installer complains
> about a lack of a FilesInUse dlg.  If I instead name my dialog FilesInUse,
> then I get a conflict because there are duplicates.
>
> Given the above, I'm at something of an Impasse.  I'm sure there's a way to
> do this. Can someone offer some help?
>
> Thanks in advance!
> -Dan
> -
> 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


-
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] Help customizing FilesInUse Dialog

[Christopher Karper]

Are you using votive?   And are you using the WixUIExtension?

If so, I would imagine you can skip the extension, and just fully replace
the FilesInUse name.   Copy down all the rest of the UI wxs and just go to
town.

Chris

On Fri, Jul 18, 2008 at 4:42 PM, Dan Giambalvo <
[EMAIL PROTECTED]> wrote:

> I'm in need of some help trying to customize the FilesInUse dialog for my
> app's installer.  Our designers want to customize the look and feel of the
> entire installer, so starting with WIXUI_Minimal I've been making local
> copies of each dialog wxs file and then making modifications.  This worked
> perfectly for all the non-required dialogs (like WelcomeEulaDlg) but I'm now
> running into some issues with some of the "required" dialogs like
> FilesInUse.  Basically, if I change the name of my dialog to something like
> MyAppFilesInUse and don't reference FilesInUse, then the installer complains
> about a lack of a FilesInUse dlg.  If I instead name my dialog FilesInUse,
> then I get a conflict because there are duplicates.
>
> Given the above, I'm at something of an Impasse.  I'm sure there's a way to
> do this. Can someone offer some help?
>
> Thanks in advance!
> -Dan
> -
> 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] Help customizing FilesInUse Dialog

[Dan Giambalvo]

I'm in need of some help trying to customize the FilesInUse dialog for my app's 
installer.  Our designers want to customize the look and feel of the entire 
installer, so starting with WIXUI_Minimal I've been making local copies of each 
dialog wxs file and then making modifications.  This worked perfectly for all 
the non-required dialogs (like WelcomeEulaDlg) but I'm now running into some 
issues with some of the "required" dialogs like FilesInUse.  Basically, if I 
change the name of my dialog to something like MyAppFilesInUse and don't 
reference FilesInUse, then the installer complains about a lack of a FilesInUse 
dlg.  If I instead name my dialog FilesInUse, then I get a conflict because 
there are duplicates.

Given the above, I'm at something of an Impasse.  I'm sure there's a way to do 
this. Can someone offer some help?

Thanks in advance!
-Dan
-
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] A method for avoiding ICE38 error

[Tony Juricic]

Yes, writing ICE30 instead of ICE38 was a typo. Example with the current
%userprofile% path that gets enumerated at heal time answers my
question, thanks.

Writing  wouldn't
cause key not to be written on install, as I thought. Clearly to be used
as a keypath, something has to be written to the Registry. Thus, it made
sense for me to create a 'normal' Registry key (i.e. with company name,
product name etc. in key path) and use it for component registry.  
 

-Original Message-
From: jmcfadyen [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 17, 2008 10:30 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] A method for avoiding ICE38 error


ICE30 and ICE38 are two quite different errors. ICE38 seems pertinent in
this
case so I will assume you are talking about this. 

When deploying files to a users profile if the file is a keypath to the
component the files fullpath will be written to the component's registry

i.e. c:\users\%username%\appdata\xxx.xxx or more precisely
c:\users\john\appdata\xxx.xxx as such during self healing it can get a
little confused if your logged in as another user. particularly if that
user
doesnt have admin rights. 

By changing the keypath to an HKCU it ensures that it queries
HKCU\software\ to determine if the component needs to be
installed. because of this the current %userprofile% path gets
enumerated at
heal time. 

where a keypath is an HKCU reg key it ensures these keys are dropped for
all
successive profiles after the installation occurs (using self healing). 

im not sure if this answers all your question or not, let me know if you
need more input. 


Tony Juricic wrote:
> 
> During installation I create some per-user folders in
> Users\username\AppData\Roaming. Thus I get hit by ICE30 error. 
> 
> I don't really understand why would creating folders under CU profile
> cause problems for component un/installation in this particular case.
> Anyhow, I solved the problem with a trick as follows:
> 
>   
> 
> 
>   
> 
>   
> 
> 
>  On="uninstall" />
>   
> 
>  
>
> 
> I feel uneasy about this "solution" and would appreciate your
comments.
> In particular what, if anything, may go wrong creating CU profile
> folders in this way.
> 
> 
>

-
> 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
> 
> 

-- 
View this message in context:
http://www.nabble.com/A-method-for-avoiding-ICE38-error-tp18517038p18521
532.html
Sent from the wix-users mailing list archive at Nabble.com.




-
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] Automatically setting version number

[Rob Mensching]

Oh, thanks, how very sloppy of me.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm
Sent: Friday, July 18, 2008 11:21
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Rob, I know I'm being picky but just in case anyone else is reading
this, the syntax is "!(bind.FileVersion.)" i.e. ! not $

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: 18 July 2008 18:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Correct.  At this point, I tend towards "$(bind.FileVersion.)" instead
of "$(bind.assemblyFileVersion.)" because FileVersion is always
available.  

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil
Sleightholm
Sent: Friday, July 18, 2008 09:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

In addition I think I am correct in saying that
!(bind.assemblyFileVersion.xxx) is not set unless you use the -fv
option.

It is a good idea though, I think I will be changing my installs.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: 18 July 2008 17:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Note, only the "assembly" binder variables require GAC'ing.  If you use
"$(bind.FileVersion.FileId)" then that will always work.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, July 18, 2008 08:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

This was my approach for a long time as well, but last week I changed to
using a binder variable. The core application we install is always
stamped with an assemblyversion by the build process. Instead of passing
flags in via the Candle command line, or using a pre-processor variable,
I now grab the assemblyversion directly off the .exe at link time.

Check out the Binder Variables topic in the help file, and
http://blogs.msdn.com/heaths/archive/2008/02/08/get-binder-variables-for
-assemblies-without-installing-into-the-gac.aspx for information on how
to get the binder variable to work without having to install into the
GAC.



Neil


From: [EMAIL PROTECTED]
[EMAIL PROTECTED] On Behalf Of Adam Connelly
[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 7:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Thanks for the replies.  I ended up using a wix pre-processor directive,
like Neil suggested.  I had to write a msbuild task to set the
environment variable if it's not already set, however, since on a dev
machine the variable would not normally be set (i.e. it's the build
server that sets it), and this was causing the candle to squeal.

Cheers,
Adam

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Karper
Sent: 18 July 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

I write an msbuild action, but I have lot's of custom activity, so I
have a
.targets file of my own that I include in my new projects.   That makes
it
easier to remember, and quick to fix once I find it missing.  I like
your
$(var) method though.

Chris

On Fri, Jul 18, 2008 at 6:48 AM, Neil Sleightholm <[EMAIL PROTECTED]>
wrote:

> 1. I think it is ok but Windows Installer will ignore the 4th part.
>
> 2. I pass the version in on the candle command line and use code like
this
> in the wxs file:
>
> 
> 
> 
> 
>
> 
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> [EMAIL PROTECTED] 
>
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Adam
Connelly
> Sent: Fri 18/07/2008 11:30
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Automatically setting version number
>
>
>
> Hi,
>
> I've got a CI setup that automatically generates a x.x.x.x style
version
> number.  I've got all my assemblies versioned properly (with a
generated
> shared SolutionInfo.cs file), and I set the msi output name as
> MyMSI-x.x.x.x.msi and now I want to set the Version attribute of the
Product
> tag.  Two questions:
>
>
> 1)  Is it ok to put a four digit version number in here?
>
> 2)  How would you recommend I set the version, bearing in mind I
get my
> version number from a $(build_number) environment variable?
>
> I was thinking of modifying the project file and shoving a msbuild
task
> that edits the Product.wxs in, but if possible I'd like to avoid
modifying
> project files si

Re: [WiX-users] Automatically setting version number

[Neil Sleightholm]

Rob, I know I'm being picky but just in case anyone else is reading
this, the syntax is "!(bind.FileVersion.)" i.e. ! not $

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: 18 July 2008 18:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Correct.  At this point, I tend towards "$(bind.FileVersion.)" instead
of "$(bind.assemblyFileVersion.)" because FileVersion is always
available.  

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil
Sleightholm
Sent: Friday, July 18, 2008 09:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

In addition I think I am correct in saying that
!(bind.assemblyFileVersion.xxx) is not set unless you use the -fv
option.

It is a good idea though, I think I will be changing my installs.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: 18 July 2008 17:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Note, only the "assembly" binder variables require GAC'ing.  If you use
"$(bind.FileVersion.FileId)" then that will always work.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, July 18, 2008 08:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

This was my approach for a long time as well, but last week I changed to
using a binder variable. The core application we install is always
stamped with an assemblyversion by the build process. Instead of passing
flags in via the Candle command line, or using a pre-processor variable,
I now grab the assemblyversion directly off the .exe at link time.

Check out the Binder Variables topic in the help file, and
http://blogs.msdn.com/heaths/archive/2008/02/08/get-binder-variables-for
-assemblies-without-installing-into-the-gac.aspx for information on how
to get the binder variable to work without having to install into the
GAC.



Neil


From: [EMAIL PROTECTED]
[EMAIL PROTECTED] On Behalf Of Adam Connelly
[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 7:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Thanks for the replies.  I ended up using a wix pre-processor directive,
like Neil suggested.  I had to write a msbuild task to set the
environment variable if it's not already set, however, since on a dev
machine the variable would not normally be set (i.e. it's the build
server that sets it), and this was causing the candle to squeal.

Cheers,
Adam

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Karper
Sent: 18 July 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

I write an msbuild action, but I have lot's of custom activity, so I
have a
.targets file of my own that I include in my new projects.   That makes
it
easier to remember, and quick to fix once I find it missing.  I like
your
$(var) method though.

Chris

On Fri, Jul 18, 2008 at 6:48 AM, Neil Sleightholm <[EMAIL PROTECTED]>
wrote:

> 1. I think it is ok but Windows Installer will ignore the 4th part.
>
> 2. I pass the version in on the candle command line and use code like
this
> in the wxs file:
>
> 
> 
> 
> 
>
> 
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> [EMAIL PROTECTED] 
>
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Adam
Connelly
> Sent: Fri 18/07/2008 11:30
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Automatically setting version number
>
>
>
> Hi,
>
> I've got a CI setup that automatically generates a x.x.x.x style
version
> number.  I've got all my assemblies versioned properly (with a
generated
> shared SolutionInfo.cs file), and I set the msi output name as
> MyMSI-x.x.x.x.msi and now I want to set the Version attribute of the
Product
> tag.  Two questions:
>
>
> 1)  Is it ok to put a four digit version number in here?
>
> 2)  How would you recommend I set the version, bearing in mind I
get my
> version number from a $(build_number) environment variable?
>
> I was thinking of modifying the project file and shoving a msbuild
task
> that edits the Product.wxs in, but if possible I'd like to avoid
modifying
> project files since it would probably be quite easy to forget to do
when
> setting up new projects.
>
> Thanks,
> Adam
>

-
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based appli

Re: [WiX-users] using preprocessor variables in pre/postbuild stepsin VS2005

[Antoine, David]

Steve,

I am defining them in a WXI file using the 
preprocessor construct.  They are then referenced in one or more WXS
files (each WiX project are broken into multiple WXS files).  Should I
be using a different method?

David J. Antoine

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve
Baker
Sent: Thursday, July 17, 2008 5:03 PM
To: wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] using preprocessor variables in pre/postbuild
stepsin VS2005

Where are you defining the preprocessor variables you would like to have
access to in the pre and post build steps?  In the wixproj file? in a
wxs?

Steve Baker


From: "Antoine, David" <[EMAIL PROTECTED]>
Sent: Thursday, July 17, 2008 4:22 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] using preprocessor variables in pre/postbuild steps
in VS2005 

Everyone,

I am currently using WiX v3.0.2925.0.  I have a few projects
that use local preprocessor variables.  I may need to pass one or more
of these on to pre- and post-build steps in Visual Studio 2005.  So far
I have been unable to do so.  From reading the documentation, there are
WiX variables that can be passed as far as I can tell.  However, it does
not seem that user-created preprocessor variables can be passed with the
version of WiX v3 that I am using (that or I am not reading the
documentation closely enough).  Is there a way to do so, and does it
require a more recent build of WiX v3?  Thank you for your time.


-
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

-
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] Multiple Instances and Torch.exe

[Rob Mensching]

Ahh, got it.  Yeah.  Okay.  Nothing in WiX v3 will show up for "instance-izing" 
your Components.  It's a problem I'm still walking around trying to find a good 
solution for.  Localizing Components is a similar problem and it be nice to 
have a good solution for both... but we're not doing features in WiX v3 right 
now, just fixing bugs to hit a final release. So this is a problem to be 
tackled in WiX vNext.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Friday, July 18, 2008 09:50
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

I referred to "NON file related data"...this goes back to the reference 
counting thread recently discussed.

If I have a component that installs INI keys in the application target dir 
(INSTALLLOCATION); if I don't [instance-ize] that component (meaning that if I 
don't assign unique component guids for that component for every instance I 
support), only the last instance to be uninstalled will get its ini keys 
uninstalled.  All the other uninstalled instances will have orphaned INI keys 
remaining on the system.  This is true for registry keys, shortcuts, ini keys, 
etc... (All non-file based data).


So I was asking if WiX had a nice way to "instance-ize" a component; or if what 
I'm doing is about as good as it gets.


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

* To keep the nonfile data of each instance isolated, the base package should 
collect nonfile data into sets of components for each instance. The appropriate 
components should then be installed based on conditional statements that depend 
on the instance identifier



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Friday, July 18, 2008 11:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

I don't understand what you mean here: "file related data (such as INI keys) 
for instances need to have their own component GUIDs."  If the Component 
content is identical then you shouldn't put them in different Components.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Friday, July 18, 2008 07:31
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

1.  Nothing really is different from one component to the next, [that's my 
point] however non file related data (such as INI keys) for instances need to 
have their own component GUIDs.  That means the component containing the INI 
keys gets duplicated for each instance.  The only thing that changes are the 
IDs, the GUID, and the condition of the components to be installed.  I was 
wondering if there was a cleaner way to go about "duplicating" the components 
for instances...


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Friday, July 18, 2008 3:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

2.  Well, I'm glad we finally built something useful.You can thank 
Peter Marcu, it was his feature.

1.  I don't really understand what is different from one Component to the next.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 15:35
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

FRIGGEN AWESOME YOU GUYS KICK ARSE!!!

Just what I needed  Thanks!


[After I come down from my emotionally high roller coaster here... regarding 
question #1, is there a cleaner way [a method to avoid code duplication]?]



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Wednesday, July 16, 2008 5:28 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

Take a look at the new "Instance" element in WiX v3.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 14:28
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Multiple Instances and Torch.exe

Looking for some advice:

I need to support multiple instances of my product installation (for sake of 
discussion, let's just say 50 of the suckers).

Regarding all non-file data, I've authored separate components and conditioned 
their installation based upon an internal instance name property:

Example:

  
  
  
  



  
  
  
  


  
  
  
 

Re: [WiX-users] Localization filename change

[Neil Enns]

While Rob wasn't part of the change, I was :)

I'm looking for feedback on how to best approach tweaking this. One option 
that's been suggested is to not rename the MSI file, and to instead put them 
into subdirectories. So on a build you'd have 
$(TargetDir)\CultureName\$(TargetName)$(TargetExt).

Would that work better for people? For those of you that commented on the 
original issue at the tracker below, do your projects have multiple languages 
in them? Or do you just have a single language in the project?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Friday, July 18, 2008 9:38 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Localization filename change

No need to escalate to a vote necessarily.  We can have an open discussion 
about the change and what behavior people would like to see.  Bob's comment was 
accurate but that doesn't mean the conversation has to end there.  If you 
disagree about the change, let's just talk about it here and then get a summary 
in the bug.


Note: I'm not really part of the change so I'll let those that made it argue 
the merits/demerits of it.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ilya Slobodin
Sent: Friday, July 18, 2008 06:49
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Localization filename change

Hi list,

Please vote that this issue should be resolved. I guess many WiX users
have scripts that are now broken by 3.0.4309.0.

I have already opened a bug on sourceforge on this issue.

https://sourceforge.net/tracker/?func=detail&atid=642714&aid=2020595&group_id=105970

The bug was closed with the following reason:

Bob Arnson: That was an intentional change to support building
multiple localized outputs from a single project.

Best regards,
Ilya Slobodin



-
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


-
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] Automatically setting version number

[Rob Mensching]

Correct.  At this point, I tend towards "$(bind.FileVersion.)" instead of 
"$(bind.assemblyFileVersion.)" because FileVersion is always available.  


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm
Sent: Friday, July 18, 2008 09:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

In addition I think I am correct in saying that
!(bind.assemblyFileVersion.xxx) is not set unless you use the -fv
option.

It is a good idea though, I think I will be changing my installs.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: 18 July 2008 17:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Note, only the "assembly" binder variables require GAC'ing.  If you use
"$(bind.FileVersion.FileId)" then that will always work.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, July 18, 2008 08:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

This was my approach for a long time as well, but last week I changed to
using a binder variable. The core application we install is always
stamped with an assemblyversion by the build process. Instead of passing
flags in via the Candle command line, or using a pre-processor variable,
I now grab the assemblyversion directly off the .exe at link time.

Check out the Binder Variables topic in the help file, and
http://blogs.msdn.com/heaths/archive/2008/02/08/get-binder-variables-for
-assemblies-without-installing-into-the-gac.aspx for information on how
to get the binder variable to work without having to install into the
GAC.



Neil


From: [EMAIL PROTECTED]
[EMAIL PROTECTED] On Behalf Of Adam Connelly
[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 7:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Thanks for the replies.  I ended up using a wix pre-processor directive,
like Neil suggested.  I had to write a msbuild task to set the
environment variable if it's not already set, however, since on a dev
machine the variable would not normally be set (i.e. it's the build
server that sets it), and this was causing the candle to squeal.

Cheers,
Adam

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Karper
Sent: 18 July 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

I write an msbuild action, but I have lot's of custom activity, so I
have a
.targets file of my own that I include in my new projects.   That makes
it
easier to remember, and quick to fix once I find it missing.  I like
your
$(var) method though.

Chris

On Fri, Jul 18, 2008 at 6:48 AM, Neil Sleightholm <[EMAIL PROTECTED]>
wrote:

> 1. I think it is ok but Windows Installer will ignore the 4th part.
>
> 2. I pass the version in on the candle command line and use code like
this
> in the wxs file:
>
> 
> 
> 
> 
>
> 
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> [EMAIL PROTECTED] 
>
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Adam
Connelly
> Sent: Fri 18/07/2008 11:30
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Automatically setting version number
>
>
>
> Hi,
>
> I've got a CI setup that automatically generates a x.x.x.x style
version
> number.  I've got all my assemblies versioned properly (with a
generated
> shared SolutionInfo.cs file), and I set the msi output name as
> MyMSI-x.x.x.x.msi and now I want to set the Version attribute of the
Product
> tag.  Two questions:
>
>
> 1)  Is it ok to put a four digit version number in here?
>
> 2)  How would you recommend I set the version, bearing in mind I
get my
> version number from a $(build_number) environment variable?
>
> I was thinking of modifying the project file and shoving a msbuild
task
> that edits the Product.wxs in, but if possible I'd like to avoid
modifying
> project files since it would probably be quite easy to forget to do
when
> setting up new projects.
>
> Thanks,
> Adam
>

-
> 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] Automatically setting version number

[Neil Sleightholm]

In addition I think I am correct in saying that
!(bind.assemblyFileVersion.xxx) is not set unless you use the -fv
option.

It is a good idea though, I think I will be changing my installs.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: 18 July 2008 17:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Note, only the "assembly" binder variables require GAC'ing.  If you use
"$(bind.FileVersion.FileId)" then that will always work.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, July 18, 2008 08:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

This was my approach for a long time as well, but last week I changed to
using a binder variable. The core application we install is always
stamped with an assemblyversion by the build process. Instead of passing
flags in via the Candle command line, or using a pre-processor variable,
I now grab the assemblyversion directly off the .exe at link time.

Check out the Binder Variables topic in the help file, and
http://blogs.msdn.com/heaths/archive/2008/02/08/get-binder-variables-for
-assemblies-without-installing-into-the-gac.aspx for information on how
to get the binder variable to work without having to install into the
GAC.



Neil


From: [EMAIL PROTECTED]
[EMAIL PROTECTED] On Behalf Of Adam Connelly
[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 7:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Thanks for the replies.  I ended up using a wix pre-processor directive,
like Neil suggested.  I had to write a msbuild task to set the
environment variable if it's not already set, however, since on a dev
machine the variable would not normally be set (i.e. it's the build
server that sets it), and this was causing the candle to squeal.

Cheers,
Adam

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Karper
Sent: 18 July 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

I write an msbuild action, but I have lot's of custom activity, so I
have a
.targets file of my own that I include in my new projects.   That makes
it
easier to remember, and quick to fix once I find it missing.  I like
your
$(var) method though.

Chris

On Fri, Jul 18, 2008 at 6:48 AM, Neil Sleightholm <[EMAIL PROTECTED]>
wrote:

> 1. I think it is ok but Windows Installer will ignore the 4th part.
>
> 2. I pass the version in on the candle command line and use code like
this
> in the wxs file:
>
> 
> 
> 
> 
>
> 
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> [EMAIL PROTECTED] 
>
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Adam
Connelly
> Sent: Fri 18/07/2008 11:30
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Automatically setting version number
>
>
>
> Hi,
>
> I've got a CI setup that automatically generates a x.x.x.x style
version
> number.  I've got all my assemblies versioned properly (with a
generated
> shared SolutionInfo.cs file), and I set the msi output name as
> MyMSI-x.x.x.x.msi and now I want to set the Version attribute of the
Product
> tag.  Two questions:
>
>
> 1)  Is it ok to put a four digit version number in here?
>
> 2)  How would you recommend I set the version, bearing in mind I
get my
> version number from a $(build_number) environment variable?
>
> I was thinking of modifying the project file and shoving a msbuild
task
> that edits the Product.wxs in, but if possible I'd like to avoid
modifying
> project files since it would probably be quite easy to forget to do
when
> setting up new projects.
>
> Thanks,
> Adam
>

-
> 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-use

Re: [WiX-users] Multiple Instances and Torch.exe

[John Nannenga]

I referred to "NON file related data"...this goes back to the reference 
counting thread recently discussed.

If I have a component that installs INI keys in the application target dir 
(INSTALLLOCATION); if I don't [instance-ize] that component (meaning that if I 
don't assign unique component guids for that component for every instance I 
support), only the last instance to be uninstalled will get its ini keys 
uninstalled.  All the other uninstalled instances will have orphaned INI keys 
remaining on the system.  This is true for registry keys, shortcuts, ini keys, 
etc... (All non-file based data).


So I was asking if WiX had a nice way to "instance-ize" a component; or if what 
I'm doing is about as good as it gets.


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

* To keep the nonfile data of each instance isolated, the base package should 
collect nonfile data into sets of components for each instance. The appropriate 
components should then be installed based on conditional statements that depend 
on the instance identifier



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Friday, July 18, 2008 11:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

I don't understand what you mean here: "file related data (such as INI keys) 
for instances need to have their own component GUIDs."  If the Component 
content is identical then you shouldn't put them in different Components.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Friday, July 18, 2008 07:31
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

1.  Nothing really is different from one component to the next, [that's my 
point] however non file related data (such as INI keys) for instances need to 
have their own component GUIDs.  That means the component containing the INI 
keys gets duplicated for each instance.  The only thing that changes are the 
IDs, the GUID, and the condition of the components to be installed.  I was 
wondering if there was a cleaner way to go about "duplicating" the components 
for instances...


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Friday, July 18, 2008 3:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

2.  Well, I'm glad we finally built something useful.You can thank 
Peter Marcu, it was his feature.

1.  I don't really understand what is different from one Component to the next.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 15:35
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

FRIGGEN AWESOME YOU GUYS KICK ARSE!!!

Just what I needed  Thanks!


[After I come down from my emotionally high roller coaster here... regarding 
question #1, is there a cleaner way [a method to avoid code duplication]?]



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Wednesday, July 16, 2008 5:28 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

Take a look at the new "Instance" element in WiX v3.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 14:28
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Multiple Instances and Torch.exe

Looking for some advice:

I need to support multiple instances of my product installation (for sake of 
discussion, let's just say 50 of the suckers).

Regarding all non-file data, I've authored separate components and conditioned 
their installation based upon an internal instance name property:

Example:

  
  
  
  



  
  
  
  


  
  
  
  

... etc...

1st Question:
  Using the sweet new tools / approaches available in WiX, is there a more 
clever way of going about the above so I don't have to duplicate a bunch of 
code?

Then, what I did in the past was (after my install built), copied the MSI.  In 
the copy I change the ProductCode and INSTANCE_NAME_INTERNAL properties, then 
generate a transform.  Change the values, then generate another transform 
(rinse and repeat until I get 50 instance transforms).  These transforms are 
then embedded within the original built MSI.  [This process was automated via a 
custom, console based utility]

2nd Question:
  Usin

Re: [WiX-users] Automatically setting version number

[Neil Sleightholm]

I didn't explain the code, the idea of the  is that
you can build it on a dev machine without have to set the variable.
Typically I set this to a number lower than the build number e.g. for
build 1.2.xxx I would set it to 1.2.0.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adam
Connelly
Sent: 18 July 2008 15:15
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Thanks for the replies.  I ended up using a wix pre-processor directive,
like Neil suggested.  I had to write a msbuild task to set the
environment variable if it's not already set, however, since on a dev
machine the variable would not normally be set (i.e. it's the build
server that sets it), and this was causing the candle to squeal.

Cheers,
Adam

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Karper
Sent: 18 July 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

I write an msbuild action, but I have lot's of custom activity, so I
have a
.targets file of my own that I include in my new projects.   That makes
it
easier to remember, and quick to fix once I find it missing.  I like
your
$(var) method though.

Chris

On Fri, Jul 18, 2008 at 6:48 AM, Neil Sleightholm <[EMAIL PROTECTED]>
wrote:

> 1. I think it is ok but Windows Installer will ignore the 4th part.
>
> 2. I pass the version in on the candle command line and use code like
this
> in the wxs file:
>
> 
> 
> 
> 
>
> 
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> [EMAIL PROTECTED] 
>
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Adam
Connelly
> Sent: Fri 18/07/2008 11:30
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Automatically setting version number
>
>
>
> Hi,
>
> I've got a CI setup that automatically generates a x.x.x.x style
version
> number.  I've got all my assemblies versioned properly (with a
generated
> shared SolutionInfo.cs file), and I set the msi output name as
> MyMSI-x.x.x.x.msi and now I want to set the Version attribute of the
Product
> tag.  Two questions:
>
>
> 1)  Is it ok to put a four digit version number in here?
>
> 2)  How would you recommend I set the version, bearing in mind I
get my
> version number from a $(build_number) environment variable?
>
> I was thinking of modifying the project file and shoving a msbuild
task
> that edits the Product.wxs in, but if possible I'd like to avoid
modifying
> project files since it would probably be quite easy to forget to do
when
> setting up new projects.
>
> Thanks,
> Adam
>

-
> 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
>

-
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

-
This SF.Net email is sponsored by

Re: [WiX-users] Localization filename change

[Rob Mensching]

No need to escalate to a vote necessarily.  We can have an open discussion 
about the change and what behavior people would like to see.  Bob's comment was 
accurate but that doesn't mean the conversation has to end there.  If you 
disagree about the change, let's just talk about it here and then get a summary 
in the bug.


Note: I'm not really part of the change so I'll let those that made it argue 
the merits/demerits of it.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ilya Slobodin
Sent: Friday, July 18, 2008 06:49
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Localization filename change

Hi list,

Please vote that this issue should be resolved. I guess many WiX users
have scripts that are now broken by 3.0.4309.0.

I have already opened a bug on sourceforge on this issue.

https://sourceforge.net/tracker/?func=detail&atid=642714&aid=2020595&group_id=105970

The bug was closed with the following reason:

Bob Arnson: That was an intentional change to support building
multiple localized outputs from a single project.

Best regards,
Ilya Slobodin



-
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] Multiple Instances and Torch.exe

[Rob Mensching]

I don't understand what you mean here: "file related data (such as INI keys) 
for instances need to have their own component GUIDs."  If the Component 
content is identical then you shouldn't put them in different Components.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Friday, July 18, 2008 07:31
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

1.  Nothing really is different from one component to the next, [that's my 
point] however non file related data (such as INI keys) for instances need to 
have their own component GUIDs.  That means the component containing the INI 
keys gets duplicated for each instance.  The only thing that changes are the 
IDs, the GUID, and the condition of the components to be installed.  I was 
wondering if there was a cleaner way to go about "duplicating" the components 
for instances...


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Friday, July 18, 2008 3:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

2.  Well, I'm glad we finally built something useful.You can thank 
Peter Marcu, it was his feature.

1.  I don't really understand what is different from one Component to the next.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 15:35
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

FRIGGEN AWESOME YOU GUYS KICK ARSE!!!

Just what I needed  Thanks!


[After I come down from my emotionally high roller coaster here... regarding 
question #1, is there a cleaner way [a method to avoid code duplication]?]



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Wednesday, July 16, 2008 5:28 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

Take a look at the new "Instance" element in WiX v3.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 14:28
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Multiple Instances and Torch.exe

Looking for some advice:

I need to support multiple instances of my product installation (for sake of 
discussion, let's just say 50 of the suckers).

Regarding all non-file data, I've authored separate components and conditioned 
their installation based upon an internal instance name property:

Example:

  
  
  
  



  
  
  
  


  
  
  
  

... etc...

1st Question:
  Using the sweet new tools / approaches available in WiX, is there a more 
clever way of going about the above so I don't have to duplicate a bunch of 
code?

Then, what I did in the past was (after my install built), copied the MSI.  In 
the copy I change the ProductCode and INSTANCE_NAME_INTERNAL properties, then 
generate a transform.  Change the values, then generate another transform 
(rinse and repeat until I get 50 instance transforms).  These transforms are 
then embedded within the original built MSI.  [This process was automated via a 
custom, console based utility]

2nd Question:
  Using the sweet new tools / approaches available in WiX, how might I go about 
this so that the above process becomes part of my MSI WiX Project build within 
Votive?  Can I somehow leverage torch?  Is there a WiX process / utility / MS 
Build Script, etc... to assist in this process (modifying an MSI, generate 
transform, stuff transform into an MSI)?


-
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.sourcefor

Re: [WiX-users] Testing for existence of a Project Reference

[Rob Mensching]

Feel free to file a documentation bug if you think the documentation needs 
updating.  The more detail you provide the more likely we get it fixed right.  


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Baker
Sent: Friday, July 18, 2008 08:02
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Testing for existence of a Project Reference

Yes it does Rob, thank you.

I looked at the documentation for the Preprocessor and do not see any examples 
of that syntax o_O

Steve Baker


From: Rob Mensching <[EMAIL PROTECTED]>
Sent: Friday, July 18, 2008 3:25 AM
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, General discussion for Windows 
Installer XML toolset. 
Subject: RE: [WiX-users] Testing for existence of a Project Reference

Does the following work...?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Baker
Sent: Thursday, July 17, 2008 16:12
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Testing for existence of a Project Reference

Thanks bob, i missed that  syntax in the help file omits the $(var. )

So now I have broken this down to the simplest example i can think of and still 
seem to be having troubles.

I created a new solution, added one class library and one wix installer 
project. I added a reference to ClassLibrary1 in the wix project.

I added:

when i try to compile i get this error:

Error1preprocessor definition value: 
C:\code\Test\ClassLibrary1\bin\Debug\

what this tells me is that the check to see if the preprocessor definition 
exists says that it doesn't, but the value is expanded correctly in the error 
statement so it must.

what am i doing wrong ?

Steve Baker


From: Bob Arnson
Sent: Thursday, July 17, 2008 5:51 PM
To: [EMAIL PROTECTED],  "General discussion for Windows Installer XML toolset."
Subject: Re: [WiX-users] Testing for existence of a Project Reference

Steve Baker wrote:
> I am trying to test if a project reference has been defined from inside a wxi 
> file by testing one of the constants that should be defined like this:
>
> 
>
>

$(var.id) is a variable resolution, to expand the id into its variable
value.  and  are looking for the id itself, so just drop the
$(var.) portion.

--
sig://boB
http://joyofsetup.com/

-
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


-
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] Automatically setting version number

[Rob Mensching]

Note, only the "assembly" binder variables require GAC'ing.  If you use 
"$(bind.FileVersion.FileId)" then that will always work.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, July 18, 2008 08:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

This was my approach for a long time as well, but last week I changed to using 
a binder variable. The core application we install is always stamped with an 
assemblyversion by the build process. Instead of passing flags in via the 
Candle command line, or using a pre-processor variable, I now grab the 
assemblyversion directly off the .exe at link time.

Check out the Binder Variables topic in the help file, and 
http://blogs.msdn.com/heaths/archive/2008/02/08/get-binder-variables-for-assemblies-without-installing-into-the-gac.aspx
 for information on how to get the binder variable to work without having to 
install into the GAC.



Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Adam Connelly [EMAIL 
PROTECTED]
Sent: Friday, July 18, 2008 7:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Thanks for the replies.  I ended up using a wix pre-processor directive, like 
Neil suggested.  I had to write a msbuild task to set the environment variable 
if it's not already set, however, since on a dev machine the variable would not 
normally be set (i.e. it's the build server that sets it), and this was causing 
the candle to squeal.

Cheers,
Adam

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Karper
Sent: 18 July 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

I write an msbuild action, but I have lot's of custom activity, so I have a
.targets file of my own that I include in my new projects.   That makes it
easier to remember, and quick to fix once I find it missing.  I like your
$(var) method though.

Chris

On Fri, Jul 18, 2008 at 6:48 AM, Neil Sleightholm <[EMAIL PROTECTED]>
wrote:

> 1. I think it is ok but Windows Installer will ignore the 4th part.
>
> 2. I pass the version in on the candle command line and use code like this
> in the wxs file:
>
> 
> 
> 
> 
>
> 
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> [EMAIL PROTECTED] 
>
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Adam Connelly
> Sent: Fri 18/07/2008 11:30
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Automatically setting version number
>
>
>
> Hi,
>
> I've got a CI setup that automatically generates a x.x.x.x style version
> number.  I've got all my assemblies versioned properly (with a generated
> shared SolutionInfo.cs file), and I set the msi output name as
> MyMSI-x.x.x.x.msi and now I want to set the Version attribute of the Product
> tag.  Two questions:
>
>
> 1)  Is it ok to put a four digit version number in here?
>
> 2)  How would you recommend I set the version, bearing in mind I get my
> version number from a $(build_number) environment variable?
>
> I was thinking of modifying the project file and shoving a msbuild task
> that edits the Product.wxs in, but if possible I'd like to avoid modifying
> project files since it would probably be quite easy to forget to do when
> setting up new projects.
>
> Thanks,
> Adam
> -
> 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
>
-
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

Re: [WiX-users] Create custom dialog for Votive & VS08 project - Radio Button to select different versions of same file

[Lanteigne, Alan]

Ok, I've got the custom dialog worked out.  I never found the files the
WIX documentation specified, but I found some other samples online to
look at.  Now I'm stuck with a new problem.  I'm using a radio button to
specify which config file should be installed.  The config file is
always called config.xml.  I would like to install a different
config.xml based on the user's selection in the Radio Button Group.

 

What I've tried so far is this:

 



  



 



  

  

 

Coupled with conditional features:

 

  





  

 

  





  

 

My hope was the radio button property "propFlavor" would allow me to
conditionally install a particular config as a feature.  It doesn't
work, I get this error:

 

Error 2 ICE30: The target file 'config.xml' is installed in
'[TARGETDIR]\spotcg7w\hc3csqhp\' by two different components on an SFN
system: comp_config_MS24' and ' comp_config_MS30'. This breaks component
reference counting.  D:\WixProjects\ProjectB\ProjectB.wxs

 

By the way, I've simplified things a little for the example.  I actually
have about 6 different config files.

 

I'm stuck!  Any advice would be appreciated...

 

Alan



From: Lanteigne, Alan 
Sent: Friday, July 18, 2008 9:18 AM
To: 'wix-users@lists.sourceforge.net'
Subject: Create custom dialog for Votive & VS08 project

 

How can I create a custom dialog with a radiobutton group using Votive?
I've found instructions for doing so at:

 

http://wix.sourceforge.net/manual-wix2/WixUI_dialog_library.htm

 

but it looks like they don't apply to Votive.  Under the "Customizing
dialog sets" section, several files are listed for modification, but
those files aren't installed on my machine.  I'm currently using the
WixUI_Minimal template, but would like to add a dialog.  How can I do
this?

 

Thanks,

 

Alan

 

Alan S. Lanteigne | Channel Ready Solutions
phone & fax +1.317.715.8293| [EMAIL PROTECTED]

Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com   

 

-
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] Automatically setting version number

[Steve Baker]

Neil,

Awsome Idea! 

saves me a ton of work, including overriding Team Builds
 core target, now that I don't have to pass the version down
through the msbuild stack to the wix project.

Thanks for sharing it, 

Steve Baker


From: Neil Enns <[EMAIL PROTECTED]>
Sent: Friday, July 18, 2008 10:33 AM
To: General discussion for Windows Installer XML toolset. 

Subject: Re: [WiX-users] Automatically setting version number 

This was my approach for a long time as well, but last week I changed to using 
a binder variable. The core application we install is always stamped with an 
assemblyversion by the build process. Instead of passing flags in via the 
Candle command line, or using a pre-processor variable, I now grab the 
assemblyversion directly off the .exe at link time.

Check out the Binder Variables topic in the help file, and 
http://blogs.msdn.com/heaths/archive/2008/02/08/get-binder-variables-for-assemblies-without-installing-into-the-gac.aspx
 for information on how to get the binder variable to work without having to 
install into the GAC.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Adam Connelly [EMAIL 
PROTECTED]
Sent: Friday, July 18, 2008 7:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Thanks for the replies.  I ended up using a wix pre-processor directive, like 
Neil suggested.  I had to write a msbuild task to set the environment variable 
if it's not already set, however, since on a dev machine the variable would not 
normally be set (i.e. it's the build server that sets it), and this was causing 
the candle to squeal.

Cheers,
Adam

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Karper
Sent: 18 July 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

I write an msbuild action, but I have lot's of custom activity, so I have a
.targets file of my own that I include in my new projects.   That makes it
easier to remember, and quick to fix once I find it missing.  I like your
$(var) method though.

Chris

On Fri, Jul 18, 2008 at 6:48 AM, Neil Sleightholm 
wrote:

> 1. I think it is ok but Windows Installer will ignore the 4th part.
>
> 2. I pass the version in on the candle command line and use code like this
> in the wxs file:
>
> 
> 
> 
> 
>
> 
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> [EMAIL PROTECTED] 
>
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Adam Connelly
> Sent: Fri 18/07/2008 11:30
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Automatically setting version number
>
>
>
> Hi,
>
> I've got a CI setup that automatically generates a x.x.x.x style version
> number.  I've got all my assemblies versioned properly (with a generated
> shared SolutionInfo.cs file), and I set the msi output name as
> MyMSI-x.x.x.x.msi and now I want to set the Version attribute of the Product
> tag.  Two questions:
>
>
> 1)  Is it ok to put a four digit version number in here?
>
> 2)  How would you recommend I set the version, bearing in mind I get my
> version number from a $(build_number) environment variable?
>
> I was thinking of modifying the project file and shoving a msbuild task
> that edits the Product.wxs in, but if possible I'd like to avoid modifying
> project files since it would probably be quite easy to forget to do when
> setting up new projects.
>
> Thanks,
> Adam
> -
> 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
>
-
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 t

Re: [WiX-users] WiX-users Digest, Vol 26, Issue 91

[Dane Anderson (Volt)]

Bob Arnson <[EMAIL PROTECTED]>
Subject: Re: [WiX-users] Custom UI Dialog errors
To: "General discussion for Windows Installer XML toolset."

Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Dane Anderson (Volt) wrote:
> I am attempting to create a trial Custom UI (my first). Nothing spectacular, 
> just a single dialog box
> with a single edit control, and a next button (fancy will come later after I 
> get THIS to work).
>

There's a bunch of minimum requirements you have to meet if you have any
UI in your package. That's what the ICE errors are telling you.

I'd suggest using WixUI instead of entirely rolling your own. Otherwise,
see the MSI SDK topic "Using the User Interface" for the content you'll
need.
*

I'm afraid that the WixUI built in dialogs won't do what I need to do.
I have 6-9 properties that would normally be set on the command line,
but we are anticipating testers that will be starting the install by
dbl clicking on the msi file icon. The properties have defaults, but
the defaults may NOT be what the testers need them to be, so I have
been tasked with providing a UI that they can use to see the defaults,
and change them if necessary. As far as I know there are no pre-defined
dialogs that do what I need to do. THAT in itself should be understandable
as the Wix Documentation does not seem to document ANY of the pre-defined
dialogs (it defines only the predefined UI sequences WixUI_Mondo,
WixUI_FeatureTree, WixUI_InstallDir). Is there a place where all these
pre-defined dialogs are documented? They are not in the Wix documentation
that comes with the Wix install package (I know, I've read it and searched
it from the the front to the back. Unless I missed seeing them accidentally
they (the dialogs) are NOT there)

I managed to fix the problem the compiler/linker had with the missing 
FilesInUse dialog,
by adding:



to the InstallUISequence element (Whether that will work correctly or not is
a question I will have to find out later) , and:



to the UI element (because it wanted the banner defined in the binary table).

That leaves me with the error dialog. I added:



To fix the problem with the ErrorDialog Property not being in the property 
table,
and added a TerminalError dialog which has a control (type text) ErrorText (as 
its
first child), BUT the compiler/linker want that ErrorText element to be flagged 
as
Control_First. The Wix documentation I have doesn't mention Control_First 
ANYWHERE.
So, how do, from inside my wxs file, I flag that ErrorText element as the
Control_First for the error dialog? I suspect that it will be an attribute of 
the
dialog, or the control, but the Wix docs don't say, and the VS drop down hints 
don't
contain anything that appears to be correct.

Oh, the suggestion to look in MSI SDK topic "Using the User Interface" helped a
little. At least it gave me some clues about where to look in the Wix 
documentation.
It also helped me find the ICE Reference
( http://msdn.microsoft.com/en-us/library/aa369206(VS.85).aspx ).
That helped me to figure out what was needed.

-
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] Automatically setting version number

[Neil Enns]

This was my approach for a long time as well, but last week I changed to using 
a binder variable. The core application we install is always stamped with an 
assemblyversion by the build process. Instead of passing flags in via the 
Candle command line, or using a pre-processor variable, I now grab the 
assemblyversion directly off the .exe at link time.

Check out the Binder Variables topic in the help file, and 
http://blogs.msdn.com/heaths/archive/2008/02/08/get-binder-variables-for-assemblies-without-installing-into-the-gac.aspx
 for information on how to get the binder variable to work without having to 
install into the GAC.



Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Adam Connelly [EMAIL 
PROTECTED]
Sent: Friday, July 18, 2008 7:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

Thanks for the replies.  I ended up using a wix pre-processor directive, like 
Neil suggested.  I had to write a msbuild task to set the environment variable 
if it's not already set, however, since on a dev machine the variable would not 
normally be set (i.e. it's the build server that sets it), and this was causing 
the candle to squeal.

Cheers,
Adam

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Karper
Sent: 18 July 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

I write an msbuild action, but I have lot's of custom activity, so I have a
.targets file of my own that I include in my new projects.   That makes it
easier to remember, and quick to fix once I find it missing.  I like your
$(var) method though.

Chris

On Fri, Jul 18, 2008 at 6:48 AM, Neil Sleightholm <[EMAIL PROTECTED]>
wrote:

> 1. I think it is ok but Windows Installer will ignore the 4th part.
>
> 2. I pass the version in on the candle command line and use code like this
> in the wxs file:
>
> 
> 
> 
> 
>
> 
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> [EMAIL PROTECTED] 
>
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Adam Connelly
> Sent: Fri 18/07/2008 11:30
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Automatically setting version number
>
>
>
> Hi,
>
> I've got a CI setup that automatically generates a x.x.x.x style version
> number.  I've got all my assemblies versioned properly (with a generated
> shared SolutionInfo.cs file), and I set the msi output name as
> MyMSI-x.x.x.x.msi and now I want to set the Version attribute of the Product
> tag.  Two questions:
>
>
> 1)  Is it ok to put a four digit version number in here?
>
> 2)  How would you recommend I set the version, bearing in mind I get my
> version number from a $(build_number) environment variable?
>
> I was thinking of modifying the project file and shoving a msbuild task
> that edits the Product.wxs in, but if possible I'd like to avoid modifying
> project files since it would probably be quite easy to forget to do when
> setting up new projects.
>
> Thanks,
> Adam
> -
> 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
>
-
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 applicat

Re: [WiX-users] Testing for existence of a Project Reference

[Steve Baker]

Yes it does Rob, thank you.

I looked at the documentation for the Preprocessor and do not see any examples 
of that syntax o_O

Steve Baker


From: Rob Mensching <[EMAIL PROTECTED]>
Sent: Friday, July 18, 2008 3:25 AM
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, General discussion for Windows 
Installer XML toolset. 
Subject: RE: [WiX-users] Testing for existence of a Project Reference 

Does the following work...?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Baker
Sent: Thursday, July 17, 2008 16:12
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Testing for existence of a Project Reference

Thanks bob, i missed that  syntax in the help file omits the $(var. )

So now I have broken this down to the simplest example i can think of and still 
seem to be having troubles.

I created a new solution, added one class library and one wix installer 
project. I added a reference to ClassLibrary1 in the wix project.

I added:

when i try to compile i get this error:

Error1preprocessor definition value: 
C:\code\Test\ClassLibrary1\bin\Debug\

what this tells me is that the check to see if the preprocessor definition 
exists says that it doesn't, but the value is expanded correctly in the error 
statement so it must.

what am i doing wrong ?

Steve Baker


From: Bob Arnson 
Sent: Thursday, July 17, 2008 5:51 PM
To: [EMAIL PROTECTED],  "General discussion for Windows Installer XML toolset." 
Subject: Re: [WiX-users] Testing for existence of a Project Reference

Steve Baker wrote:
> I am trying to test if a project reference has been defined from inside a wxi 
> file by testing one of the constants that should be defined like this:
>
> 
>
>

$(var.id) is a variable resolution, to expand the id into its variable
value.  and  are looking for the id itself, so just drop the
$(var.) portion.

--
sig://boB
http://joyofsetup.com/

-
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] The Tooltip string is overflowed!

[Derek Tarm]

Hi Chris,

Thanks for your reply!

The problem is that I must get rid of all the warning, otherwise the central
building server in my corp will reject my code :-(.
And it is odd that although this warning exists, the MSI package works
perfectly, that means, the tooltip string is shown completely during the
installation!
If it puts the string into the table, is there any way to re-configure the
table property so that it can hold longer string?

Thanks!

Derek

On Fri, Jul 18, 2008 at 8:39 PM, Christopher Karper <
[EMAIL PROTECTED]> wrote:

> Is the property formattable?   If so, you could assign a property value to
> it.
>
> But, the fact is, that is a valid warning.   Wix just puts the string into
> a
> table in the resulting .msi/.msm and that technology imposes limits on it's
> content.   If you want to use the installer, you have to play by their
> rules.
>
> You can just turn the warning off if you just don't want to see it, but the
> underlying issue would remain.
>
> Chris
>
> On Fri, Jul 18, 2008 at 6:06 AM, Derek Tarm <[EMAIL PROTECTED]> wrote:
>
> > Hi folks,
> >
> > 
> >
> > > Title="foobar">
> > > Width="280" Height="15" Property="NR_IPADDRESS" ToolTip="I write a
> tooltip
> > here but it's too darn long. and even worse i must write it as long as
> this
> > one!" />
> >
> >
> >
> >
> >
> > I wrote this UI code in WiX 3.0. And the compiler complained that
> > "Warning33ICE03: String overflow (greater than length permitted
> in
> > column); Table: Control, Column: Help, Key(s):
> > NRconfigParametersDlg.NR_DBIPEdit
> > D:\FoobarProject\Forbar\UI\DialogConfig.wxs131FoobarServer".
> >
> > If I shorten the tooltip string length, the warning is gone.
> >
> > So is there anybody who can tell me how to configure the WiX to get rid
> of
> > this warning without changing my tooltip string?
> >
> > Thank you!
> > Derek
> >
> > --
> > Andrew S. Tanenbaum  - "The nice thing about standards is that there are
> so
> > many of them to choose from."
> > -
> > 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
>



-- 
Woodrow Wilson  - "A conservative is a man who sits and thinks, mostly
sits."
-
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] Customizing GUI using wix3 beta 3.0.4311.0 fails

[Stephan Mueller]

* Stephan Mueller <[EMAIL PROTECTED]> [18.07.2008]:

> For me it looks like the WixUIExtension stuff in the binaries and the
> wxs files from the source distribution for version 3.0.4311.0 differ.
> Can anyone confirm this problem or show me how to fix this?

Oomph. I am stupid. I forgot to update my build environment to version
3.0.4311.0 so in fact they were different. :( Now it works.

Sorry for the noise...


Cheers,

Steph.

-
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] Multiple Instances and Torch.exe

[John Nannenga]

1.  Nothing really is different from one component to the next, [that's my 
point] however non file related data (such as INI keys) for instances need to 
have their own component GUIDs.  That means the component containing the INI 
keys gets duplicated for each instance.  The only thing that changes are the 
IDs, the GUID, and the condition of the components to be installed.  I was 
wondering if there was a cleaner way to go about "duplicating" the components 
for instances...


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Friday, July 18, 2008 3:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

2.  Well, I'm glad we finally built something useful.You can thank 
Peter Marcu, it was his feature.

1.  I don't really understand what is different from one Component to the next.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 15:35
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

FRIGGEN AWESOME YOU GUYS KICK ARSE!!!

Just what I needed  Thanks!


[After I come down from my emotionally high roller coaster here... regarding 
question #1, is there a cleaner way [a method to avoid code duplication]?]



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Wednesday, July 16, 2008 5:28 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

Take a look at the new "Instance" element in WiX v3.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 14:28
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Multiple Instances and Torch.exe

Looking for some advice:

I need to support multiple instances of my product installation (for sake of 
discussion, let's just say 50 of the suckers).

Regarding all non-file data, I've authored separate components and conditioned 
their installation based upon an internal instance name property:

Example:

  
  
  
  



  
  
  
  


  
  
  
  

... etc...

1st Question:
  Using the sweet new tools / approaches available in WiX, is there a more 
clever way of going about the above so I don't have to duplicate a bunch of 
code?

Then, what I did in the past was (after my install built), copied the MSI.  In 
the copy I change the ProductCode and INSTANCE_NAME_INTERNAL properties, then 
generate a transform.  Change the values, then generate another transform 
(rinse and repeat until I get 50 instance transforms).  These transforms are 
then embedded within the original built MSI.  [This process was automated via a 
custom, console based utility]

2nd Question:
  Using the sweet new tools / approaches available in WiX, how might I go about 
this so that the above process becomes part of my MSI WiX Project build within 
Votive?  Can I somehow leverage torch?  Is there a WiX process / utility / MS 
Build Script, etc... to assist in this process (modifying an MSI, generate 
transform, stuff transform into an MSI)?


-
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


-
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-us

Re: [WiX-users] Executing Sql Stored Procedure from SqlString

[sai rahul]

oh ok... thanks for the reply.
-
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] Automatically setting version number

[Adam Connelly]

Thanks for the replies.  I ended up using a wix pre-processor directive, like 
Neil suggested.  I had to write a msbuild task to set the environment variable 
if it's not already set, however, since on a dev machine the variable would not 
normally be set (i.e. it's the build server that sets it), and this was causing 
the candle to squeal.

Cheers,
Adam

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Karper
Sent: 18 July 2008 13:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automatically setting version number

I write an msbuild action, but I have lot's of custom activity, so I have a
.targets file of my own that I include in my new projects.   That makes it
easier to remember, and quick to fix once I find it missing.  I like your
$(var) method though.

Chris

On Fri, Jul 18, 2008 at 6:48 AM, Neil Sleightholm <[EMAIL PROTECTED]>
wrote:

> 1. I think it is ok but Windows Installer will ignore the 4th part.
>
> 2. I pass the version in on the candle command line and use code like this
> in the wxs file:
>
> 
> 
> 
> 
>
> 
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> [EMAIL PROTECTED] 
>
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Adam Connelly
> Sent: Fri 18/07/2008 11:30
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Automatically setting version number
>
>
>
> Hi,
>
> I've got a CI setup that automatically generates a x.x.x.x style version
> number.  I've got all my assemblies versioned properly (with a generated
> shared SolutionInfo.cs file), and I set the msi output name as
> MyMSI-x.x.x.x.msi and now I want to set the Version attribute of the Product
> tag.  Two questions:
>
>
> 1)  Is it ok to put a four digit version number in here?
>
> 2)  How would you recommend I set the version, bearing in mind I get my
> version number from a $(build_number) environment variable?
>
> I was thinking of modifying the project file and shoving a msbuild task
> that edits the Product.wxs in, but if possible I'd like to avoid modifying
> project files since it would probably be quite easy to forget to do when
> setting up new projects.
>
> Thanks,
> Adam
> -
> 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
>
-
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] Customizing GUI using wix3 beta 3.0.4311.0 fails

[Stephan Mueller]

Hi,

I am currently trying to adjust the GUI of my msi Installation. I want
to modify an existing dialog. I am following the howto from 

http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/

Without changing anything and using -ext WixUIExtension everything works
fine. To modify an existing dialog I started now with copying
WixUI_InstallDir.wxs, renamed it to My_InstallDir.wxs, adjusted the Id
inside this file to My_InstallDir and referenced this new id in my
installer.wxs file.  Without changing anything else this leads to
compilation errors:

..\installer\My_InstallDir.wxs(44): error LGHT0094 : Unresolved reference to 
symbol 'CustomAction:WixUIValidatePath' in section 'Fragment:'.
..\installer\My_InstallDir.wxs(45): error LGHT0094 : Unresolved reference to 
symbol 'Dialog:InvalidDirDlg' in section 'Fragment:'.
..\installer\My_InstallDir.wxs(56): error LGHT0094 : Unresolved reference to 
symbol 'CustomAction:WixUIValidatePath' in section 'Fragment:'.
..\installer\My_InstallDir.wxs(57): error LGHT0094 : Unresolved reference to 
symbol 'Dialog:InvalidDirDlg' in section 'Fragment:'.

I find this somehow strange as i expected this to work without problems
like the original, because actually I didn't change anything.

For me it looks like the WixUIExtension stuff in the binaries and the
wxs files from the source distribution for version 3.0.4311.0 differ.
Can anyone confirm this problem or show me how to fix this?


Thanks and cheers,

Steph.

-
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] Localization filename change

[Ilya Slobodin]

Hi list,

Please vote that this issue should be resolved. I guess many WiX users 
have scripts that are now broken by 3.0.4309.0.

I have already opened a bug on sourceforge on this issue.

https://sourceforge.net/tracker/?func=detail&atid=642714&aid=2020595&group_id=105970

The bug was closed with the following reason:

Bob Arnson: That was an intentional change to support building 
multiple localized outputs from a single project.

Best regards,
Ilya Slobodin



-
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] Create custom dialog for Votive & VS08 project

[Lanteigne, Alan]

How can I create a custom dialog with a radiobutton group using Votive?
I've found instructions for doing so at:

 

http://wix.sourceforge.net/manual-wix2/WixUI_dialog_library.htm

 

but it looks like they don't apply to Votive.  Under the "Customizing
dialog sets" section, several files are listed for modification, but
those files aren't installed on my machine.  I'm currently using the
WixUI_Minimal template, but would like to add a dialog.  How can I do
this?

 

Thanks,

 

Alan

 

Alan S. Lanteigne | Channel Ready Solutions
phone & fax +1.317.715.8293| [EMAIL PROTECTED]

Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com   

 

-
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] Automatically setting version number

[Christopher Karper]

I write an msbuild action, but I have lot's of custom activity, so I have a
.targets file of my own that I include in my new projects.   That makes it
easier to remember, and quick to fix once I find it missing.  I like your
$(var) method though.

Chris

On Fri, Jul 18, 2008 at 6:48 AM, Neil Sleightholm <[EMAIL PROTECTED]>
wrote:

> 1. I think it is ok but Windows Installer will ignore the 4th part.
>
> 2. I pass the version in on the candle command line and use code like this
> in the wxs file:
>
> 
> 
> 
> 
>
> 
>
> Neil
>
> Neil Sleightholm
> X2 Systems Limited
> [EMAIL PROTECTED] 
>
>
> 
>
> From: [EMAIL PROTECTED] on behalf of Adam Connelly
> Sent: Fri 18/07/2008 11:30
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Automatically setting version number
>
>
>
> Hi,
>
> I've got a CI setup that automatically generates a x.x.x.x style version
> number.  I've got all my assemblies versioned properly (with a generated
> shared SolutionInfo.cs file), and I set the msi output name as
> MyMSI-x.x.x.x.msi and now I want to set the Version attribute of the Product
> tag.  Two questions:
>
>
> 1)  Is it ok to put a four digit version number in here?
>
> 2)  How would you recommend I set the version, bearing in mind I get my
> version number from a $(build_number) environment variable?
>
> I was thinking of modifying the project file and shoving a msbuild task
> that edits the Product.wxs in, but if possible I'd like to avoid modifying
> project files since it would probably be quite easy to forget to do when
> setting up new projects.
>
> Thanks,
> Adam
> -
> 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
>
-
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] The Tooltip string is overflowed!

[Christopher Karper]

Is the property formattable?   If so, you could assign a property value to
it.

But, the fact is, that is a valid warning.   Wix just puts the string into a
table in the resulting .msi/.msm and that technology imposes limits on it's
content.   If you want to use the installer, you have to play by their
rules.

You can just turn the warning off if you just don't want to see it, but the
underlying issue would remain.

Chris

On Fri, Jul 18, 2008 at 6:06 AM, Derek Tarm <[EMAIL PROTECTED]> wrote:

> Hi folks,
>
> 
>
> Title="foobar">
> Width="280" Height="15" Property="NR_IPADDRESS" ToolTip="I write a tooltip
> here but it's too darn long. and even worse i must write it as long as this
> one!" />
>
>
>
>
>
> I wrote this UI code in WiX 3.0. And the compiler complained that
> "Warning33ICE03: String overflow (greater than length permitted in
> column); Table: Control, Column: Help, Key(s):
> NRconfigParametersDlg.NR_DBIPEdit
> D:\FoobarProject\Forbar\UI\DialogConfig.wxs131FoobarServer".
>
> If I shorten the tooltip string length, the warning is gone.
>
> So is there anybody who can tell me how to configure the WiX to get rid of
> this warning without changing my tooltip string?
>
> Thank you!
> Derek
>
> --
> Andrew S. Tanenbaum  - "The nice thing about standards is that there are so
> many of them to choose from."
> -
> 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] Localization filename change

[Dominik Guder]

Hi folks,

adding the culture to the output file is a nice feature, if you have more
than one language to maintain.

In our case this is somewhat disturbing. We use standard wix dialogs wher we
change the font size with localized values. Therefore it is required to add
a wxl file. 
This results in filename.en-us.msi which was filename.msi before. For
deployment and some automated scripts we need to rename it back to
filename.msi since this is the only culture we are currently supporting.

I could think of following scenario:
- check wxl files(WixLocalization) (and if required  property in
wixproj)
- if only one culture wxl exists, then don't change the filename

Please give me a hint, if there is a way to achieve this with current
implementation. 

Regards Dominik
-- 
View this message in context: 
http://www.nabble.com/Localization-filename-change-tp18527119p18527119.html
Sent from the wix-users mailing list archive at Nabble.com.


-
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] Automatically setting version number

[Neil Sleightholm]

1. I think it is ok but Windows Installer will ignore the 4th part.
 
2. I pass the version in on the candle command line and use code like this in 
the wxs file:
 






 
Neil
 
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]  
 



From: [EMAIL PROTECTED] on behalf of Adam Connelly
Sent: Fri 18/07/2008 11:30
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Automatically setting version number



Hi,

I've got a CI setup that automatically generates a x.x.x.x style version 
number.  I've got all my assemblies versioned properly (with a generated shared 
SolutionInfo.cs file), and I set the msi output name as MyMSI-x.x.x.x.msi and 
now I want to set the Version attribute of the Product tag.  Two questions:


1)  Is it ok to put a four digit version number in here?

2)  How would you recommend I set the version, bearing in mind I get my 
version number from a $(build_number) environment variable?

I was thinking of modifying the project file and shoving a msbuild task that 
edits the Product.wxs in, but if possible I'd like to avoid modifying project 
files since it would probably be quite easy to forget to do when setting up new 
projects.

Thanks,
Adam
-
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] Automatically setting version number

[Adam Connelly]

Hi,

I've got a CI setup that automatically generates a x.x.x.x style version 
number.  I've got all my assemblies versioned properly (with a generated shared 
SolutionInfo.cs file), and I set the msi output name as MyMSI-x.x.x.x.msi and 
now I want to set the Version attribute of the Product tag.  Two questions:


1)  Is it ok to put a four digit version number in here?

2)  How would you recommend I set the version, bearing in mind I get my 
version number from a $(build_number) environment variable?

I was thinking of modifying the project file and shoving a msbuild task that 
edits the Product.wxs in, but if possible I'd like to avoid modifying project 
files since it would probably be quite easy to forget to do when setting up new 
projects.

Thanks,
Adam
-
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] The Tooltip string is overflowed!

[Derek Tarm]

Hi folks,










I wrote this UI code in WiX 3.0. And the compiler complained that
"Warning33ICE03: String overflow (greater than length permitted in
column); Table: Control, Column: Help, Key(s):
NRconfigParametersDlg.NR_DBIPEdit
D:\FoobarProject\Forbar\UI\DialogConfig.wxs131FoobarServer".

If I shorten the tooltip string length, the warning is gone.

So is there anybody who can tell me how to configure the WiX to get rid of
this warning without changing my tooltip string?

Thank you!
Derek

-- 
Andrew S. Tanenbaum  - "The nice thing about standards is that there are so
many of them to choose from."
-
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] Component Rules

[Rob Mensching]

I'm not sure where this thread is at so I'll just jump in here since it's close 
to the answer.

The Windows Installer handles Files slightly more gently than all of the other 
Resources (registry keys, shortcuts, etc).  In particular, the same Component 
can install the same File to different Directories and when the Components are 
removed the correct Files are removed.  This is necessary because it was 
possible to install Office2000 (the original test case for Windows Installer) 
and some standalone Office2000 product (say Word2000) to different directories. 
 There are a significant number of shared Components between those Products 
even though the Files go to different locations.  So, the Windows Installer has 
logic to track which Component went to which Directory (the Windows Installer 
actually tracks the Directories not the Files since it knows the file names 
can't change and all of the contents of a Component can only be installed to 
one Directory).

However, there are still problems in some cases.  For example, using our 
Office2000 and Word2000 from above say there is a shared COM DLL called 
"foo.dll" that has "CLSID_FOO" registry key.  You'd have something like this:

Office2000 Product
SharedComponent
path\to\office2000\foo.dll
HKCR\CLSID_FOO\Inproc32Server -> path\to\office2000\foo.dll

Word2000 Product
SharedComponent
path\to\word2000\foo.dll
HKCR\CLSID_FOO\Inproc32Server -> path\to\office2000\foo.dll


Notice that the registry key can only point to one of the file paths at a time 
(imagine the Registry/@Value="[!FooDllId]").  I think it would point at the 
last installed product (or the first installed... ).  Now, everything 
is reference counted just fine.  However, if you uninstall "Office2000 Product" 
then "path\to\office2000\foo.dll" will get removed correctly and the registry 
key will stay installed but the registry key will continue to point at the file 
that was just moved.  You'd have to run a full repair on Word2000 to get the 
registry key to be updated.  The same thing would happen if you put the 
registry key in a second shared component.

The issue above is why you find COM servers living in "CommonFilesFolder" 
rather than being installed with the product.  Because then the COM servers 
always install in the same place and the registry key has only one thing to 
point at.  Back in 2001, I spent Christmas Break moving the "Heart of Office" 
(mso.dll) from "ProgramFilesFolder\Microsoft Office\Office10" to 
"CommonFilesFolder\Microsoft Shared\Office10".  That was fun...



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 21:43
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Component Rules

> in relation to the non file components are you referring to non file keypath
> or components which simply contain additional resources but maintain a file
> keypath ?

In general, I think I have a pretty good handle of the component rules / the 
best practices for laying out components like you mentioned below.  What I 
wasn't aware of was the technical nuts and bolts of how things are actually 
layed out (registry keys, products mapped to component GUIDs, etc...).  So to 
isolate the example, to answer your question, I would be refering to a 
component whose keypath is a non-file artifact, say a registry key for example.

I know that there is a difference in behavior between non-file data (shortcuts, 
registry keys, ini keys, etc...) and file data (actual files that get 
installed).  So I was looking to further understand the actual techincal merits 
of how this fits into the picture; or even if this fits into the ref-counting 
picture at all. (maybe everything fits the ref-counting picture, but some other 
magical MSI process treats files differently, etc...).


Or, in other words...

> when you uninstall a product it simply removes its product reference from
> under the component. where there are no products left it will remove the
> component.
>
> As such two products sharing the same component will not allow removal of
> a
> component unless both products are uninstalled. So if you uinstall
> ProductA
> without uninstalling ProductB you should find the component stays
> installed.

The above logic does make sense.  However, when two products share the same 
component, but install that [file based component] to different locations on 
the file system, this is not the case.  (File installed by Product A will be 
uninstalled regardless whether ProductB is or isn't uninstalled).  Assuming 
this relates to Windows Installer ref-counting, I was seeking to understand how 
this is accounted for.


[Refer to the 'really stupid example' with sample WiX code I posted under the 
same subject]...


  Phil Wilson's book I thought was an entertaining read.  I wasn't aware 
there could be more

Re: [WiX-users] Multiple Instances and Torch.exe

[Rob Mensching]

2.  Well, I'm glad we finally built something useful.You can thank 
Peter Marcu, it was his feature.

1.  I don't really understand what is different from one Component to the next.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 15:35
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

FRIGGEN AWESOME YOU GUYS KICK ARSE!!!

Just what I needed  Thanks!


[After I come down from my emotionally high roller coaster here... regarding 
question #1, is there a cleaner way [a method to avoid code duplication]?]



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Wednesday, July 16, 2008 5:28 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple Instances and Torch.exe

Take a look at the new "Instance" element in WiX v3.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Wednesday, July 16, 2008 14:28
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Multiple Instances and Torch.exe

Looking for some advice:

I need to support multiple instances of my product installation (for sake of 
discussion, let's just say 50 of the suckers).

Regarding all non-file data, I've authored separate components and conditioned 
their installation based upon an internal instance name property:

Example:

  
  
  
  



  
  
  
  


  
  
  
  

... etc...

1st Question:
  Using the sweet new tools / approaches available in WiX, is there a more 
clever way of going about the above so I don't have to duplicate a bunch of 
code?

Then, what I did in the past was (after my install built), copied the MSI.  In 
the copy I change the ProductCode and INSTANCE_NAME_INTERNAL properties, then 
generate a transform.  Change the values, then generate another transform 
(rinse and repeat until I get 50 instance transforms).  These transforms are 
then embedded within the original built MSI.  [This process was automated via a 
custom, console based utility]

2nd Question:
  Using the sweet new tools / approaches available in WiX, how might I go about 
this so that the above process becomes part of my MSI WiX Project build within 
Votive?  Can I somehow leverage torch?  Is there a WiX process / utility / MS 
Build Script, etc... to assist in this process (modifying an MSI, generate 
transform, stuff transform into an MSI)?


-
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


-
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] Executing Sql Stored Procedure from SqlString

[Rob Mensching]

SqlString only executes as a deferred custom action and does not set properties 
based on results of queries.  So, no... but it is a totally reasonable feature 
request.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sai rahul
Sent: Thursday, July 17, 2008 00:34
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Executing Sql Stored Procedure from SqlString

Sorry, i wasnt clear in the previous post. Can i use SqlString Select Query
to get Currencies and Bind it to the ComboBox properties or do i have to
write a custom action only?

Rahul
-
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] Testing for existence of a Project Reference

[Rob Mensching]

Does the following work...?





-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Baker
Sent: Thursday, July 17, 2008 16:12
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Testing for existence of a Project Reference

Thanks bob, i missed that  syntax in the help file omits the $(var. )

So now I have broken this down to the simplest example i can think of and still 
seem to be having troubles.

I created a new solution, added one class library and one wix installer 
project. I added a reference to ClassLibrary1 in the wix project.

I added:





when i try to compile i get this error:

Error1preprocessor definition value: 
C:\code\Test\ClassLibrary1\bin\Debug\

what this tells me is that the check to see if the preprocessor definition 
exists says that it doesn't, but the value is expanded correctly in the error 
statement so it must.

what am i doing wrong ?

Steve Baker


From: Bob Arnson <[EMAIL PROTECTED]>
Sent: Thursday, July 17, 2008 5:51 PM
To: [EMAIL PROTECTED],  "General discussion for Windows Installer XML toolset." 

Subject: Re: [WiX-users] Testing for existence of a Project Reference

Steve Baker wrote:
> I am trying to test if a project reference has been defined from inside a wxi 
> file by testing one of the constants that should be defined like this:
>
> 
>
>

$(var.id) is a variable resolution, to expand the id into its variable
value.  and  are looking for the id itself, so just drop the
$(var.) portion.

--
sig://boB
http://joyofsetup.com/


-
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] HowTo install a MSHelp2 collection into VS2005 or VS2008

[Rob Mensching]

Get the MS HTML Help team to release proper Merge Modules.  That would go a 
long way.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Francois Retief
Sent: Thursday, July 17, 2008 23:50
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] HowTo install a MSHelp2 collection into VS2005 or VS2008

Hello,

We need to install a MS Help2 collection into VS2005 and/or VS2008. I was
looking for a nice HowTo Guide on the subject. ;-)

But it don't seem to work.  Searching through the various blogs on the
subject, I found this open issue:

http://sourceforge.net/tracker/index.php?func=detail&aid=1588180&group_id=105970&atid=642714

I can confirm that the issue is still unresolved. What would it take to
resolve this issue before Wix v3 is released?  And what can I do to help?

Microsoft (R) Windows Installer Xml Linker version 3.0.4311.0
Copyright (C) Microsoft Corporation. All rights reserved.
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than
length permitted in column); Table: File, Column: File, Key(s):
FL_vsipccNamedURLs_hxk_86888.3643236F_FC70_11D3_A536_0090278A1BB8
light.exe(0,0): error LGHT0204: ICE03: Not a valid foreign key; Table:
HelpPlugin, Column: HelpNamespace_Parent, Key(s): MS_VSIPCC_v80.MS_VSCC_v80
light.exe(0,0): error LGHT0204: ICE03: Not a valid foreign key; Table:
HelpPlugin, Column: HelpNamespace_Parent, Key(s):
MS_VSIPCC_v80.MS_VSExpressCC_v80
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than
length permitted in column); Table: MsiFileHash, Column: File_, Key(s):
FL_vsipccNamedURLs_hxk_86888.3643236F_FC70_11D3_A536_0090278A1BB8
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than
length permitted in column); Table: Registry, Column: Registry, Key(s):
_FldbVs8_RegFile_15039_0.3643236F_FC70_11D3_A536_0090278A1BB8
light.exe(0,0): error LGHT0204: ICE27: 'CreateShortcuts' Action in
InstallExecuteSequence table in wrong place. Current: PostExecution,
Correct: Execution
light.exe(0,0): error LGHT0204: ICE77:
CA_HxMerge_VSIPCC_VSCC.3643236F_FC70_11D3_A536_0090278A1BB8 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(0,0): error LGHT0204: ICE77:
CA_HxMerge_VSIPCC_VSExpCC.3643236F_FC70_11D3_A536_0090278A1BB8 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(0,0): warning LGHT1076: ICE82: This action
CommonFilesFolder.3643236F_FC70_11D3_A536_0090278A1BB8 has duplicate
sequence number 1 in the table InstallExecuteSequence
light.exe(0,0): warning LGHT1076: ICE82: This action
CommonFilesFolder.3643236F_FC70_11D3_A536_0090278A1BB8 has duplicate
sequence number 1 in the table InstallUISequence
light.exe(0,0): warning LGHT1076: ICE82: This action
CommonFilesFolder.3643236F_FC70_11D3_A536_0090278A1BB8 has duplicate
sequence number 1 in the table AdminExecuteSequence
light.exe(0,0): warning LGHT1076: ICE82: This action
CommonFilesFolder.3643236F_FC70_11D3_A536_0090278A1BB8 has duplicate
sequence number 1 in the table AdminUISequence
light.exe(0,0): warning LGHT1076: ICE82: This action
CommonFilesFolder.3643236F_FC70_11D3_A536_0090278A1BB8 has duplicate
sequence number 1 in the table AdvtExecuteSequence

Cheers
  Francois
-
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] Merge module question

[Rob Mensching]

I consider Merge Modules more like a .DLL than a static library even though it 
gets merged into the MSI.  I look at it that way because there are so many 
boundaries between the Merge Module and the MSI (modularization of the primary 
keys) and the fact that Merge Modules are intended to be redistributed.  I 
consider .wixlibs more like static ".lib" files... thus the name. 

However, I can see why one might approach Merge Modules like .lib files.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hall
Sent: Friday, July 18, 2008 00:55
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Merge module question

> By extension, we do not need tools like WiX as we don't need
> tools like compilers. We can all hack binary codes directly
> to the processor and be done with it.
>
> BTW, .msm is like a .o to a .c

I think of them more like a static library, i.e. a .lib file ... :)

john

-
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] creating Localized installer.

[Rob Mensching]

Windows Installer does not support that.  You need a bootstrapper to detect and 
either pick the right package or apply language transform when doing install.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of bhupendra
Sent: Thursday, July 17, 2008 23:38
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] creating Localized installer.

Hi All,



Is it possible to create a localized installer that detects Locals of system
and installation get launched in local language.

i.e.  Say if installation started by a German user than installation
progress should be in German, and in Japanese if Japanese user start
installation.





>From some blogs what I could understood was, for each locale there would be
separate .msi file.

But I want single installable file for more than one languages.



Thanks in advance

Bhupendra Yadav



-
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] rollback after removing backup files

[Rob Mensching]

There is a COMMONDATA message sent before the rollback is being cleaned up that 
instructs the UI to hide the Cancel button.  I suppose it is possible some 
installs are not respecting that message correctly.  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anidil
Sent: Friday, July 18, 2008 00:22
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] rollback after removing backup files


I can't roll back when the installer/uninstaller is at removing backup files
stage..MSI gracefully exits without rolling back though user clicks 'Yes" on
the rollback confirmation dialog.
I have noticed this behavior with many different MSI based applicaitons
downloaded
Is this the expected MSI behavior??? please clarify


Thanks
Anidil
--
View this message in context: 
http://www.nabble.com/rollback-after-removing-backup-files-tp18523912p18523912.html
Sent from the wix-users mailing list archive at Nabble.com.


-
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] Merge module question

[John Hall]

> By extension, we do not need tools like WiX as we don't need 
> tools like compilers. We can all hack binary codes directly 
> to the processor and be done with it.
> 
> BTW, .msm is like a .o to a .c

I think of them more like a static library, i.e. a .lib file ... :)

john

-
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] rollback after removing backup files

[Anidil]

I can't roll back when the installer/uninstaller is at removing backup files
stage..MSI gracefully exits without rolling back though user clicks 'Yes" on
the rollback confirmation dialog.
I have noticed this behavior with many different MSI based applicaitons
downloaded
Is this the expected MSI behavior??? please clarify


Thanks
Anidil
-- 
View this message in context: 
http://www.nabble.com/rollback-after-removing-backup-files-tp18523912p18523912.html
Sent from the wix-users mailing list archive at Nabble.com.


-
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