Re: [WiX-users] Best practices for WiX (v2)

[Neil Enns]

The WiX help file for WiX 3.0 has a bunch of "how tos" that document best 
practices for various tasks. Most of them will likely apply to WiX 2.0 as well.

When you are done with your best practices doc I'd love to see a copy :)

Neil

-Original Message-
From: Greg Silin [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 21, 2008 11:39 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Best practices for WiX (v2)

Hi,

I'm helping our dev group develop a standards doc for WiX development.  Does 
anyone know of a good pointer to share on best practices or suggested standards?

Thanks!
-greg

-
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 user groups using WIX

[Neil Enns]

It is part of WiX 3.0.

Neil

-Original Message-
From: Kalvagadda, SivaKrishna (MLX Technology) [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 17, 2008 8:55 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creating user groups using WIX

Thanks for your response.

I use http://wix.sourceforge.net/manual-wix2/wix_xsd_index.htm for
checkout the schema. But I couldn't find the tab mailto:[EMAIL PROTECTED] 
Sent: Friday, October 17, 2008 11:18 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creating user groups using WIX

Check out the util:User/Group schema.

On Fri, Oct 17, 2008 at 10:44 AM, Kalvagadda, SivaKrishna (MLX
Technology) <
[EMAIL PROTECTED]> wrote:

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

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


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

Re: [WiX-users] List of built-in custom actions?

[Neil Enns]

The Wix.chm file lists them. Look under the Advanced WiX Topics section, 
Standard Custom Actions.

Neil

-Original Message-
From: David Bartmess [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 17, 2008 8:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] List of built-in custom actions?

Is there a list of the built-in customactions somewhere? I'm new to wix,
and finding a customaction requires me going into the source code and
just searching.
 
Would be a lot easier if I knew if a customaction existed already...
 
Thanks!
 

 

David Bartmess

Wall Street On Demand 

[EMAIL PROTECTED]  

direct: 303.417. x585

cell: 303.883-9117

fax: 303.444.2586

 
-
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] WiX Install path

[Neil Enns]

I don't know whether the change was intentional, but to fix this you can edit 
the .wixproj file to redirect the location. See the "Using WiX with MSBuild" 
topic in the WiX.CHM for the property you need to set.

Neil


From: Neil Sleightholm [EMAIL PROTECTED]
Sent: Saturday, October 11, 2008 2:34 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] WiX Install path

I have just updated to WiX v 3.0.4603.0 and the install location has
changed, it was "C:\Program Files\Windows Installer XML Toolset v3" and
it now "C:\Program Files\Windows Installer XML Toolset 3.0.4603.0". This
seems to have broken Visual Studio projects which are still looking in
"C:\Program Files\Windows Installer XML Toolset v3".



Was this change intentional?



Neil



Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED] 



-
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] Install Condition for .Net framework 3.5 SP1

[Neil Enns]

Use the NetFx library that comes with WiX. See the WiX documentation, there's a 
topic in the How To that describes how to check the Framework version. It 
should also have a reference to a table with all the predefined properties for 
each framework version.

Neil


From: Sandeep Gautam (HCL Technologies Ltd) [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 6:35 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Install Condition for .Net framework 3.5 SP1

Hi,

How can I add acheck for .net framework 3.5 SP1.
Actually I want to check for "v3.0 SP1" under 
HKLM\Software\Microsoft\.NETFramework.

Currently I am opting below mentioned work around for this. I am looking inside 
v3.0 SP1\SBSDisabled and reading Uninstall value.


  



  FRAMEWORK35SP1 = "#1"


Please suggest me how can I do this.

-Original Message-
From: Nic Barden [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 6:04 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Intercepting the SQL CA

Hi,



I'm trying to perform token replacement on SQL script files (such as
database name, server name etc) via a custom CA before the SQL CA executes
them.  I have successfully created the custom CA.  However, I am unsure how
to "intercept" the SQL CA to provide it the "new" files/scripts to execute.
I am not fussed whether they are executed as SqlScripts or SqlStrings.  I
have tried adding the modified files to both the SqlScript and SqlString
tables as temporary rows, however, they do not get picked up by the SQL CA.



Is the SQL CA not seeing the temp rows that I am adding because it runs
deferred, and cannot see temporary rows that I have added? Or do deferred
CAs also have access to the temp rows that I am adding?

Has anyone else got any ideas of how I can achieve the goal of having the
SQL CA execute my modified files?



Thanks!

-
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] How to GAC .Net assemblies the correct way?

[Neil Enns]

There is a complete example of how to do this in the WiX help file that ships 
with WiX. Look under the How To section.

Neil


From: Wong Shao Voon [EMAIL PROTECTED]
Sent: Wednesday, October 08, 2008 2:54 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to GAC .Net assemblies the correct way?

Hey guys,

I could use a custom action to gacutil the .Net dlls into the GAC. But I 
searched that WiX and MSI has the correct way of GAC'ing the dlls, instead of 
using gacutil.exe . After I googled, I still couldn't find a single example on 
how to do it. Could someone kind enough to enlighten me the correct way to 
specify it in the WXS file?

Thank you very much!

And have a nice day!

Best regards,
Shao Voon




-
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] Problem using WiX tasks(MSBuild task)

[Neil Enns]

Shao Voon,

Your attachment didn't come through, but I'm curious: why are you trying to 
hand-author build process for this? WiX ships with a complete build process for 
building WiX projects using MSBuild. See the topic "Using WiX with MSBuild" in 
the Wix.chm file that ships with your install. It's much, much, easier than 
trying to write your own process using the shipping tasks.

Neil


From: Wong Shao Voon [EMAIL PROTECTED]
Sent: Sunday, October 05, 2008 9:52 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problem using WiX tasks(MSBuild task)

Hi guys,

I got the error as below,

2>Project "d:\xx\xx\Installer\MakeInstaller.proj" (default targets):
2>Target BuildInstaller:
2>  d:\xx\xx\Installer\MakeInstaller.proj(43,9): error MSB4067: The element 
 beneath element  is unrecognized.
2>Done building target "BuildInstaller" in project "MakeInstaller.proj" -- 
FAILED.
2>Done building project "MakeInstaller.proj" -- FAILED.
2>Build FAILED.
2>d:\xx\xx\Installer\MakeInstaller.proj(43,9): error MSB4067: The element 
 beneath element  is unrecognized.
2>0 Warning(s)
2>1 Error(s)
2>Time Elapsed 00:00:00.01

My MS Build task is attached as MakeInstaller.proj in this email, it is just a 
very short XML.

Please help!

Thank you!

Best regards,
Shao Voon




-
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] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Neil Enns]

John,

Do you have multiple localized versions of your merge module, and you're trying 
to reference the matching merge module for the culture of the main MSI that's 
being built?

Neil

-Original Message-
From: John Nannenga [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 24, 2008 1:11 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Done...

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

-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 1:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Yes, that looks like it won't work. Can you log a bug on this in SourceForge?

Neil

-Original Message-
From: John Nannenga [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 10:54 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Is this change not compatible with the "List of Supported Project References"?



Before this change, I had a reference in my MSI WiX project to a merge module 
WiX project.  I then referred to the built merge module via 
$(var..TargetPath).  This worked just peachy, until this change 
was introduced.  Now (WiX 3.0.4519.0), during a build this continues to 
resolves to: ...\bin\Release\MyMergeModule.msm instead of where the file was 
actually built to, ...\bin\Release\en-us\MyMergeModule.msm



Within the Wix.chm under "List of Supported Project References", I don't see 
anything for specifying culture.  The var.ProjectName.TargetPath example 
indicates it should resolve to the full filename of where the item was built to 
(but it isn't, anymore)...



Thoughts?









-Original Message-----

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns

Sent: Thursday, September 11, 2008 1:53 PM

To: General discussion for Windows Installer XML toolset.

Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land



Sorry, my mistake. I looked at my changes to the WiX build process and you'll 
get the different output locations any time you have a localized build (one 
that has .wxl files in it).



What are you trying to do in your Pre- and Post-Build steps? Depending on what 
you are doing there may be existing things in the wix.targets file you can 
leverage (much like VS does) to make small tweaks to your targets that work 
with the output file locations.



Neil



-Original Message-

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien

Sent: Thursday, September 11, 2008 1:43 PM

To: 'General discussion for Windows Installer XML toolset.'

Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land



Thanks for the response.  I currently only have a single Resources\Strings.wxl 
in my project settings which has the Culture="en-us" attribute set.  Should I 
just remove that string resources file Culture attribute setting to get build 
output landing in bin\$(Configuration) again?



http://schemas.microsoft.com/wix/2006/localization";>



For now since we only build Language="1033" setup output getting msi and msp 
build output to land in bin\$(Configuration) again is super helpful in terms of 
TFS automated build processing where being able to have postBuild events simply 
reference $(OutDir) makes the desktop vstudio and tfs build agent server 
pre/postBuild event authoring more straight forward.

-
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 

Re: [WiX-users] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Neil Enns]

Yes, that looks like it won't work. Can you log a bug on this in SourceForge?

Neil 

-Original Message-
From: John Nannenga [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 24, 2008 10:54 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Is this change not compatible with the "List of Supported Project References"?



Before this change, I had a reference in my MSI WiX project to a merge module 
WiX project.  I then referred to the built merge module via 
$(var..TargetPath).  This worked just peachy, until this change 
was introduced.  Now (WiX 3.0.4519.0), during a build this continues to 
resolves to: ...\bin\Release\MyMergeModule.msm instead of where the file was 
actually built to, ...\bin\Release\en-us\MyMergeModule.msm



Within the Wix.chm under "List of Supported Project References", I don't see 
anything for specifying culture.  The var.ProjectName.TargetPath example 
indicates it should resolve to the full filename of where the item was built to 
(but it isn't, anymore)...



Thoughts?









-Original Message-

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns

Sent: Thursday, September 11, 2008 1:53 PM

To: General discussion for Windows Installer XML toolset.

Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land



Sorry, my mistake. I looked at my changes to the WiX build process and you'll 
get the different output locations any time you have a localized build (one 
that has .wxl files in it).



What are you trying to do in your Pre- and Post-Build steps? Depending on what 
you are doing there may be existing things in the wix.targets file you can 
leverage (much like VS does) to make small tweaks to your targets that work 
with the output file locations.



Neil



-Original Message-

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien

Sent: Thursday, September 11, 2008 1:43 PM

To: 'General discussion for Windows Installer XML toolset.'

Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land



Thanks for the response.  I currently only have a single Resources\Strings.wxl 
in my project settings which has the Culture="en-us" attribute set.  Should I 
just remove that string resources file Culture attribute setting to get build 
output landing in bin\$(Configuration) again?



http://schemas.microsoft.com/wix/2006/localization";>



For now since we only build Language="1033" setup output getting msi and msp 
build output to land in bin\$(Configuration) again is super helpful in terms of 
TFS automated build processing where being able to have postBuild events simply 
reference $(OutDir) makes the desktop vstudio and tfs build agent server 
pre/postBuild event authoring more straight forward.

-
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] Questions about using MFC Merge Module

[Neil Enns]

You didn't read the comment from Heath just below Aaron's blog post :)

"It's important to note that the policy MSM should be merged after the payload, 
if merged at all. It is recommended that you do not merge the policy MSM as 
this will redirect all applications depending on the related native assembly to 
that version. If you have no major reason to affect every application, merge 
only the payload MSM. I'll be doing a post or two on the situation as a whole 
very soon."

We also confirmed this before writing the topic on merging VC Redist into your 
installer for the How To in the WiX CHM.

Neil

-Original Message-
From: Wilson, Phil [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 23, 2008 11:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Questions about using MFC Merge Module

Are you sure? I was just reading Aaron Stebner's blog about building an MSI 
with  WiX that includes the VC 8.0 merge modules and he includes the policy 
merge module. I don't believe this would change for VC 9.0.

http://blogs.msdn.com/astebner/archive/2007/02/13/building-an-msi-using-wix-v3-0-that-includes-the-vc-8-0-runtime-merge-modules.aspx

The policy file redirects people to use the newer version, so this might just 
be a "good citizen" choice to upgrade the system.

The Dll merge modules contain multiple copies of files, that's why they 
increase the size. Orca reveals that Unicode and non-Unicode are also in there, 
plus versions of mfcm90.dll for Winforms integration.

Phil Wilson


-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 8:05 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Questions about using MFC Merge Module

The answer to your last question is no, you do not need (and should not) 
include the policy modules.

Neil


From: Travis Burkitt [EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 7:58 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Questions about using MFC Merge Module

Hello,

I am adding the VC 9.0 and the MFC 9.0 Merge modules to an installation.
Previously I was directly including the required files in my application
directory, but now I wanted to do it properly.  Everything seems to work
fine except that I would like to keep this install as small as possible
and the install is now significantly larger.  (previously was less than
3MB, but now it is almost 15Mb)

Part of what is confusing me is that in that in my windows\winsxs
directory I have 3 VC and 3 MFC directories (3 versions)
x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_a173767a
x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.30411.0_x-ww_421e9f78
x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_405b0943
The dlls in the 21022 directory are much smaller than those in the other
two directories.  (1.1Mb vs 3.6Mb)
The MFC merge modules picking up the middle version 9.0.30411.


My main questions are:
- Why do I have an MFC merge module that is picking up the middle
version of the 3 that are installed?  (FYI the VC module does the same
thing)
- Is there a way to reduce the size of the msi file and still ensure
that the necessary files are included for the end user?  (e.g. any way
to use version 9.0.21022.8 which likely has all I need and is much smaller?)
- It isn't as clean, but is it acceptable to require users to download
and install the MS VC++ 2008 Redistributable Package.
- Also I need to use the policy merge modules?  (e.g.
policy_9_0_Microsoft_VC90_MFC_x86.msm)


Thanks,
Travis


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

Re: [WiX-users] Questions about using MFC Merge Module

[Neil Enns]

The answer to your last question is no, you do not need (and should not) 
include the policy modules.

Neil


From: Travis Burkitt [EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 7:58 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Questions about using MFC Merge Module

Hello,

I am adding the VC 9.0 and the MFC 9.0 Merge modules to an installation.
Previously I was directly including the required files in my application
directory, but now I wanted to do it properly.  Everything seems to work
fine except that I would like to keep this install as small as possible
and the install is now significantly larger.  (previously was less than
3MB, but now it is almost 15Mb)

Part of what is confusing me is that in that in my windows\winsxs
directory I have 3 VC and 3 MFC directories (3 versions)
x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_a173767a
x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.30411.0_x-ww_421e9f78
x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_405b0943
The dlls in the 21022 directory are much smaller than those in the other
two directories.  (1.1Mb vs 3.6Mb)
The MFC merge modules picking up the middle version 9.0.30411.


My main questions are:
- Why do I have an MFC merge module that is picking up the middle
version of the 3 that are installed?  (FYI the VC module does the same
thing)
- Is there a way to reduce the size of the msi file and still ensure
that the necessary files are included for the end user?  (e.g. any way
to use version 9.0.21022.8 which likely has all I need and is much smaller?)
- It isn't as clean, but is it acceptable to require users to download
and install the MS VC++ 2008 Redistributable Package.
- Also I need to use the policy merge modules?  (e.g.
policy_9_0_Microsoft_VC90_MFC_x86.msm)


Thanks,
Travis


-
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] Need help with WIX unistall

[Neil Enns]

Alex's blog entry at 
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx
 is a good starting point.

Neil

-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Monday, September 22, 2008 10:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Need help with WIX unistall

Ensure your Product/@Id, Product/@UpgradeCode and Upgrade elements follow the 
MSI SDK suggestions for Major Upgrades.

-Original Message-
From: Nimisha Saboo [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 09:55
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Need help with WIX unistall

 Hi,

I have a Wix project, which currently allows multiple installs of my
application,
although I have done nothing to enable this.
What this means is: I install my application, and then again click on the
msi.
Ideally, it should start an uninstall of my application, but currently it
starts another install.

Any idea, what do I need to set in order to get this done?

Thanks in advance,
Nimisha
-
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] Cannot use project references variables for Win32 project

[Neil Enns]

This is by design. Project references to Win32 (non-managed) projects are not 
supported.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Worawit Wangwarunyoo 
[EMAIL PROTECTED]
Sent: Thursday, September 18, 2008 9:09 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Cannot use project references variables for Win32 project

Hi all,

I am a new user to Wix. I am using Visual Studio 2005 for development. I just 
installed Wix-3.0.4318.0.

When I tried to follow the help adding reference from .NET project, it works 
fine.

Then I tried to add my real projects (using Win32) references. There is 
exclamation icon at new project reference in Solution pane. Also I cannot use 
project reference variables such as var.MyWin32Project.TargetFileName.

Could someone help me?

Thanks,
Worawit Wang




-
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] Question about LGHT0204:ICE43 and ICE57

[Neil Enns]

I'll leave the answer to that up to others more knowledgeable about those 
specific ICE errors. The steps listed in the How to document, however, are the 
recommended way of doing this.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Yen
Sent: Thursday, September 18, 2008 2:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Question about LGHT0204:ICE43 and ICE57

Hello,

Thanks for the reply, I guess I saw this solution before as I tried
googling my problem a while ago.

I don't really like the idea of installing irrelevant registry keys(in
HKCU) unless it is really necessary, so if I leave my installer as it
was without the HKCU registry, what might be the consequences?(Though it
gives error messages, the installer was still built anyhow, and I
haven't seen it causing any problems yet...)

Thank you,

Roger Yen
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 18, 2008 4:26 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Question about LGHT0204:ICE43 and ICE57

Look in the Wix.CHM file for the How To topic on how to create shortcuts
to applications. It shows you the steps to take to author the setup
correctly to remove these errors.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Roger Yen
Sent: Thursday, September 18, 2008 1:25 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Question about LGHT0204:ICE43 and ICE57

Hello,



I am getting these error messages when building my installer due to
having a non-advertised shortcut:



error LGHT0204 : ICE43: Component Exe has non-advertised shortcuts. It
should use a registry key under HKCU as its KeyPath, not a file.

error LGHT0204 : ICE57: Component 'Exe' has both per-user and
per-machine data with a per-machine KeyPath.



I am wondering if it will cause any "serious" problems or if I can just
ignore them...as I need my shortcut as non-advertised because it is a
shared component by several tools...



Thank you,



Roger Yen




-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.

-
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 transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

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

Re: [WiX-users] Question about LGHT0204:ICE43 and ICE57

[Neil Enns]

Look in the Wix.CHM file for the How To topic on how to create shortcuts to 
applications. It shows you the steps to take to author the setup correctly to 
remove these errors.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Yen
Sent: Thursday, September 18, 2008 1:25 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Question about LGHT0204:ICE43 and ICE57

Hello,



I am getting these error messages when building my installer due to
having a non-advertised shortcut:



error LGHT0204 : ICE43: Component Exe has non-advertised shortcuts. It
should use a registry key under HKCU as its KeyPath, not a file.

error LGHT0204 : ICE57: Component 'Exe' has both per-user and
per-machine data with a per-machine KeyPath.



I am wondering if it will cause any "serious" problems or if I can just
ignore them...as I need my shortcut as non-advertised because it is a
shared component by several tools...



Thank you,



Roger Yen




-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
-
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] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Neil Enns]

Weird, I've never seen that before. Can you please send me your .wixproj file? 
You can mail it to me at [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> so you 
don't have to send it to the whole list.

Thanks,

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Saturday, September 13, 2008 3:25 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Tried adding  to my wixproj postBuild event and it gives me the following build output 
error.

The syntax of the command is incorrect.
C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.0\Wix.targets(1860,5): error 
MSB3073: The command "http://schemas.microsoft.com/developer/msbuild/2003"; />


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, September 12, 2008 4:21 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

You should be able to add it anywhere inside the postbuild Target. What error 
did you get?

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Friday, September 12, 2008 11:38 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Tried adding "echo 
$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)" 
to my post build event and it caused build errors.

Where am I supposed to add "" in my Setup.wixproj to see it during build processing?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 8:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Ok, this is pretty straightforward then. In your postbuild step where you're 
using bin\$(Configuration) change it to this:

$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)

It's pretty long but will translate into the full path of each MSI produced by 
the build. You can test this out by sticking it in a Message task and seeing 
what happens:



The result in my test project is this:

  d:\projects\WixProject7\bin\Debug\en-us\WixProject7.msi
  d:\projects\WixProject7\bin\Debug\en-ca\WixProject7.msi

Let me know if that does (or doesn't!) work.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 7:43 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Correct. Currently only have a reason to have a macro value for full path of 
msi files output in postbuild step.  Prebuild processing currently only 
involves strong name signing and sandcastle chm file generation prior to msi 
build that uses those bits.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 5:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert,

One follow-up question: do you need to know the path to the MSI files in the 
prebuild step? From what you write below it sounds like you only need it for 
postbuild. Prebuild is only about signing the assemblies that go into the MSI, 
correct? (It is very easy to give you the full paths to the built MSIs after 
build, but a bit trickier prebuild).

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 2:27 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

In prebuild events I execute a custom process that carries out a process that 
does full signing of all 

Re: [WiX-users] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Neil Enns]

You should be able to add it anywhere inside the postbuild Target. What error 
did you get?

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Friday, September 12, 2008 11:38 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Tried adding "echo 
$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)" 
to my post build event and it caused build errors.

Where am I supposed to add "" in my Setup.wixproj to see it during build processing?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 8:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Ok, this is pretty straightforward then. In your postbuild step where you're 
using bin\$(Configuration) change it to this:

$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)

It's pretty long but will translate into the full path of each MSI produced by 
the build. You can test this out by sticking it in a Message task and seeing 
what happens:



The result in my test project is this:

  d:\projects\WixProject7\bin\Debug\en-us\WixProject7.msi
  d:\projects\WixProject7\bin\Debug\en-ca\WixProject7.msi

Let me know if that does (or doesn't!) work.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 7:43 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Correct. Currently only have a reason to have a macro value for full path of 
msi files output in postbuild step.  Prebuild processing currently only 
involves strong name signing and sandcastle chm file generation prior to msi 
build that uses those bits.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 5:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert,

One follow-up question: do you need to know the path to the MSI files in the 
prebuild step? From what you write below it sounds like you only need it for 
postbuild. Prebuild is only about signing the assemblies that go into the MSI, 
correct? (It is very easy to give you the full paths to the built MSIs after 
build, but a bit trickier prebuild).

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 2:27 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

In prebuild events I execute a custom process that carries out a process that 
does full signing of all assemblies that were built using public key only delay 
signed build output.

In postbuild events I execute a custom process that carries out publisher 
signing of msi build output.  I also execute a robocopy command that copies our 
set of service deliverable specific automated distributed msi deployment 
processing xml to the same folder as the service deliverable msi build output.

With this new build output folder scheme this means that pre/postBuild steps 
that may have been using the $(TargetPath) macro value which is no longer valid 
now have to use a set of $(TargetDir)\$(TargetName) steps, e.g. 
$(TargetDir)en-us\$(TargetName).

I guess I was just thrown off by the assumption that there might be something 
like a default / language neutral culture which lands in the 
bin\$(Configuration) folder and only non-default / language neutral culture 
output lands in bin\$(Configuration)\ folder.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Sorry, my mistake. I looked at my changes to t

Re: [WiX-users] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Neil Enns]

Ok, this is pretty straightforward then. In your postbuild step where you're 
using bin\$(Configuration) change it to this:

$(TargetDir)%(EmbeddedResourceWithCulture.Culture)\$(TargetName)$(TargetExt)

It's pretty long but will translate into the full path of each MSI produced by 
the build. You can test this out by sticking it in a Message task and seeing 
what happens:



The result in my test project is this:

  d:\projects\WixProject7\bin\Debug\en-us\WixProject7.msi
  d:\projects\WixProject7\bin\Debug\en-ca\WixProject7.msi

Let me know if that does (or doesn't!) work.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 7:43 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Correct. Currently only have a reason to have a macro value for full path of 
msi files output in postbuild step.  Prebuild processing currently only 
involves strong name signing and sandcastle chm file generation prior to msi 
build that uses those bits.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 5:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert,

One follow-up question: do you need to know the path to the MSI files in the 
prebuild step? From what you write below it sounds like you only need it for 
postbuild. Prebuild is only about signing the assemblies that go into the MSI, 
correct? (It is very easy to give you the full paths to the built MSIs after 
build, but a bit trickier prebuild).

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 2:27 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

In prebuild events I execute a custom process that carries out a process that 
does full signing of all assemblies that were built using public key only delay 
signed build output.

In postbuild events I execute a custom process that carries out publisher 
signing of msi build output.  I also execute a robocopy command that copies our 
set of service deliverable specific automated distributed msi deployment 
processing xml to the same folder as the service deliverable msi build output.

With this new build output folder scheme this means that pre/postBuild steps 
that may have been using the $(TargetPath) macro value which is no longer valid 
now have to use a set of $(TargetDir)\$(TargetName) steps, e.g. 
$(TargetDir)en-us\$(TargetName).

I guess I was just thrown off by the assumption that there might be something 
like a default / language neutral culture which lands in the 
bin\$(Configuration) folder and only non-default / language neutral culture 
output lands in bin\$(Configuration)\ folder.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Sorry, my mistake. I looked at my changes to the WiX build process and you'll 
get the different output locations any time you have a localized build (one 
that has .wxl files in it).

What are you trying to do in your Pre- and Post-Build steps? Depending on what 
you are doing there may be existing things in the wix.targets file you can 
leverage (much like VS does) to make small tweaks to your targets that work 
with the output file locations.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1:43 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Thanks for the response.  I currently only have a single Resources\Strings.wxl 
in my project settings which has the Culture="en-us" attribute set.  Should I 
just remove that string resources file Culture attribute setting to get build 
output landing in bin\$(Configuration) again?

http://schemas.microsoft.com/

Re: [WiX-users] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Neil Enns]

Robert,

One follow-up question: do you need to know the path to the MSI files in the 
prebuild step? From what you write below it sounds like you only need it for 
postbuild. Prebuild is only about signing the assemblies that go into the MSI, 
correct? (It is very easy to give you the full paths to the built MSIs after 
build, but a bit trickier prebuild).

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Robert O'Brien [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 2:27 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

In prebuild events I execute a custom process that carries out a process that 
does full signing of all assemblies that were built using public key only delay 
signed build output.

In postbuild events I execute a custom process that carries out publisher 
signing of msi build output.  I also execute a robocopy command that copies our 
set of service deliverable specific automated distributed msi deployment 
processing xml to the same folder as the service deliverable msi build output.

With this new build output folder scheme this means that pre/postBuild steps 
that may have been using the $(TargetPath) macro value which is no longer valid 
now have to use a set of $(TargetDir)\$(TargetName) steps, e.g. 
$(TargetDir)en-us\$(TargetName).

I guess I was just thrown off by the assumption that there might be something 
like a default / language neutral culture which lands in the 
bin\$(Configuration) folder and only non-default / language neutral culture 
output lands in bin\$(Configuration)\ folder.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Sorry, my mistake. I looked at my changes to the WiX build process and you'll 
get the different output locations any time you have a localized build (one 
that has .wxl files in it).

What are you trying to do in your Pre- and Post-Build steps? Depending on what 
you are doing there may be existing things in the wix.targets file you can 
leverage (much like VS does) to make small tweaks to your targets that work 
with the output file locations.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1:43 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Thanks for the response.  I currently only have a single Resources\Strings.wxl 
in my project settings which has the Culture="en-us" attribute set.  Should I 
just remove that string resources file Culture attribute setting to get build 
output landing in bin\$(Configuration) again?

http://schemas.microsoft.com/wix/2006/localization";>

For now since we only build Language="1033" setup output getting msi and msp 
build output to land in bin\$(Configuration) again is super helpful in terms of 
TFS automated build processing where being able to have postBuild events simply 
reference $(OutDir) makes the desktop vstudio and tfs build agent server 
pre/postBuild event authoring more straight forward.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert,

This happens when you have multiple .wxl files in your project with different 
cultures in them. Setting the Cultures field in properties will control which 
languages get built, but the output will still go into the sub-folder (this is 
so you can set up different configurations, for example, to control which 
languages get built for different types of builds).

The only way to disable this is to remove the .wxl files from the project that 
are for other languages. You could also perhaps do some tweaking to the project 
file to conditionally include those .wxl files based on a flag somewhere, but 
that would be some additional work and tweaking.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1:33 PM
To: 'General discussion for Windows Install

Re: [WiX-users] Debugging C++ Custom Actions

[Neil Enns]

I've found the MsiBreak environment variable is a very useful tool for 
debugging custom actions. See 
http://msdn.microsoft.com/en-us/library/aa368264.aspx for the details, but in a 
nutshell:

1) Start a command prompt (if you are on Vista make sure it is elevated. XP 
make sure you are an admin)
2) Set the MsiBreak environment variable to the name of your custom action
3) Run the MSI from within the command prompt window

MSI will throw a dialog up before it runs your custom action with the process 
number you should attach to. Then attach to that process, click on on the MSI 
dialog, and it'll automatically break at the start of your custom action. You 
can then debug from there.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Tony Juricic [EMAIL 
PROTECTED]
Sent: Thursday, September 11, 2008 4:47 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Debugging C++ Custom Actions

I often encounter problems debugging deferred C++ DLL CAs. Most of the
time DebugBreak() works. Now and then it won't and then I use __asm {
int 3 } which, for some reason, tends to work more often than
DebugBreak.

Then I encounter situations when even int 3 won't work in the sense that
Vista (and 4.0 Installer) does not offer me a chance to break into the
debugger but, instead, shows a dialog box saying "Windows installer
stopped working and was closed".

In this dialog I can only press Close button and my installation appears
successful. I just appears so because the bunch of CA code that was
supposed to execute after int 3 didn't execute and that is fatal for my
apps.
If I remove int 3 (or DebugBreak()) then I don't see the dialog box
mentioned above and but that doesn't help my debugging.

Do you encounter similar problems and can anybody suggest reliable
method to break into deferred action DLL code?

Thanks!

-
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] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Neil Enns]

Ok. Let me think about this tonight, there are likely a couple of solutions to 
this that will work.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 2:27 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

In prebuild events I execute a custom process that carries out a process that 
does full signing of all assemblies that were built using public key only delay 
signed build output.

In postbuild events I execute a custom process that carries out publisher 
signing of msi build output.  I also execute a robocopy command that copies our 
set of service deliverable specific automated distributed msi deployment 
processing xml to the same folder as the service deliverable msi build output.

With this new build output folder scheme this means that pre/postBuild steps 
that may have been using the $(TargetPath) macro value which is no longer valid 
now have to use a set of $(TargetDir)\$(TargetName) steps, e.g. 
$(TargetDir)en-us\$(TargetName).

I guess I was just thrown off by the assumption that there might be something 
like a default / language neutral culture which lands in the 
bin\$(Configuration) folder and only non-default / language neutral culture 
output lands in bin\$(Configuration)\ folder.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Sorry, my mistake. I looked at my changes to the WiX build process and you'll 
get the different output locations any time you have a localized build (one 
that has .wxl files in it).

What are you trying to do in your Pre- and Post-Build steps? Depending on what 
you are doing there may be existing things in the wix.targets file you can 
leverage (much like VS does) to make small tweaks to your targets that work 
with the output file locations.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1:43 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Thanks for the response.  I currently only have a single Resources\Strings.wxl 
in my project settings which has the Culture="en-us" attribute set.  Should I 
just remove that string resources file Culture attribute setting to get build 
output landing in bin\$(Configuration) again?

http://schemas.microsoft.com/wix/2006/localization";>

For now since we only build Language="1033" setup output getting msi and msp 
build output to land in bin\$(Configuration) again is super helpful in terms of 
TFS automated build processing where being able to have postBuild events simply 
reference $(OutDir) makes the desktop vstudio and tfs build agent server 
pre/postBuild event authoring more straight forward.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert,

This happens when you have multiple .wxl files in your project with different 
cultures in them. Setting the Cultures field in properties will control which 
languages get built, but the output will still go into the sub-folder (this is 
so you can set up different configurations, for example, to control which 
languages get built for different types of builds).

The only way to disable this is to remove the .wxl files from the project that 
are for other languages. You could also perhaps do some tweaking to the project 
file to conditionally include those .wxl files based on a flag somewhere, but 
that would be some additional work and tweaking.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1:33 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

This is really got me in a tail spin.

In my existing project started with 4004 and recentl

Re: [WiX-users] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Neil Enns]

Sorry, my mistake. I looked at my changes to the WiX build process and you'll 
get the different output locations any time you have a localized build (one 
that has .wxl files in it).

What are you trying to do in your Pre- and Post-Build steps? Depending on what 
you are doing there may be existing things in the wix.targets file you can 
leverage (much like VS does) to make small tweaks to your targets that work 
with the output file locations.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1:43 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Thanks for the response.  I currently only have a single Resources\Strings.wxl 
in my project settings which has the Culture="en-us" attribute set.  Should I 
just remove that string resources file Culture attribute setting to get build 
output landing in bin\$(Configuration) again?

http://schemas.microsoft.com/wix/2006/localization";>

For now since we only build Language="1033" setup output getting msi and msp 
build output to land in bin\$(Configuration) again is super helpful in terms of 
TFS automated build processing where being able to have postBuild events simply 
reference $(OutDir) makes the desktop vstudio and tfs build agent server 
pre/postBuild event authoring more straight forward.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, September 11, 2008 1:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert,

This happens when you have multiple .wxl files in your project with different 
cultures in them. Setting the Cultures field in properties will control which 
languages get built, but the output will still go into the sub-folder (this is 
so you can set up different configurations, for example, to control which 
languages get built for different types of builds).

The only way to disable this is to remove the .wxl files from the project that 
are for other languages. You could also perhaps do some tweaking to the project 
file to conditionally include those .wxl files based on a flag somewhere, but 
that would be some additional work and tweaking.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1:33 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

This is really got me in a tail spin.

In my existing project started with 4004 and recently migrated to the latest 
wix drop regardless of whether I do or do not have a  | properties 
| build | cultures field value specified my light.exe output is getting 
directed to bin\$(Configuration)\en-us.

In any file | new | wix project regardless of whether I do or do not have a 
 | properties | build | cultures field value specified my light.exe 
output is getting directed to bin\$(Configuration).

Diff'ng both wixproj files I am unable to find anything different that would 
suggest why.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, September 10, 2008 6:47 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert O'Brien wrote:
> If I clear my  | properties | build | cultures to build field and 
> rebuild I'm still getting output in the bin\$(Configuration)\en-us folder.   
> Is there a way to restore build output landing in bin\$(Configuration) ?
>

Not that I'm aware of.

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

Re: [WiX-users] what setting causes current wix build output to land in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used to land

[Neil Enns]

Robert,

This happens when you have multiple .wxl files in your project with different 
cultures in them. Setting the Cultures field in properties will control which 
languages get built, but the output will still go into the sub-folder (this is 
so you can set up different configurations, for example, to control which 
languages get built for different types of builds).

The only way to disable this is to remove the .wxl files from the project that 
are for other languages. You could also perhaps do some tweaking to the project 
file to conditionally include those .wxl files based on a flag somewhere, but 
that would be some additional work and tweaking.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Brien
Sent: Thursday, September 11, 2008 1:33 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

This is really got me in a tail spin.

In my existing project started with 4004 and recently migrated to the latest 
wix drop regardless of whether I do or do not have a  | properties 
| build | cultures field value specified my light.exe output is getting 
directed to bin\$(Configuration)\en-us.

In any file | new | wix project regardless of whether I do or do not have a 
 | properties | build | cultures field value specified my light.exe 
output is getting directed to bin\$(Configuration).

Diff'ng both wixproj files I am unable to find anything different that would 
suggest why.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, September 10, 2008 6:47 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] what setting causes current wix build output to land 
in bin\$(Configuration)\en-us versus bin\$(Configuration) where it always used 
to land

Robert O'Brien wrote:
> If I clear my  | properties | build | cultures to build field and 
> rebuild I'm still getting output in the bin\$(Configuration)\en-us folder.   
> Is there a way to restore build output landing in bin\$(Configuration) ?
>

Not that I'm aware of.

--
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] Check whether VS.NET is installed.

[Neil Enns]

You don't even have to that much. WiX includes a library to do this for you, 
which you can just include and then reference the property with a .

See the How To: Check for .NET Framework Versions in the WiX CHM file for the 
general approach, but substitute in WixVSExtension instead of WiXNetExtension. 
The "WixVSExtension" topic lists the available properties.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Sergey Abakumoff [EMAIL 
PROTECTED]
Sent: Wednesday, September 10, 2008 11:27 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Check whether VS.NET is installed.


Found the answer myself:
* Define the following properties:

  



  



  


Then use these properties to block the installation of the certain
components..
--
View this message in context: 
http://n2.nabble.com/Check-whether-VS.NET-is-installed.-tp1082028p1082052.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] VC redist msm not installing completely

[Neil Enns]

For specific explanations of how to integrate the redists into your installer 
see the How To topic in the CHM that comes with WiX. It's in the How Tos 
section and goes step by step through how to make this work.

Note that you shouldn't be including the policy files in your installer either. 
There's a note to that effect in the blog below, as well as in the WiX 
documentation.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil
Sent: Tuesday, September 02, 2008 1:41 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] VC redist msm not installing completely

You're installing with merge modules, that means the runtime Dlls are part of 
your installation, and are not installed like the standalone redist exe that 
also installs them.  The normal overwrite rules will apply if those Dlls are 
already installed.

Phil Wilson

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeb Remus
Sent: Tuesday, September 02, 2008 12:46 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] VC redist msm not installing completely


Hello,

I hope I'm mailing the correct list about this.  In trying to 
develop an installer for our product in WIX, I've hit a wall concerning VC 8.0 
redist prerequisites.  I followed the steps available at

https://blogs.msdn.com/astebner/archive/2007/02/13/building-an-msi-using-wix-v3-0-that-includes-the-vc-8-0-runtime-merge-modules.aspx

to leverage WIX to build an MSI that installs the VC redist.  I 
included the CRT, ATL, MFC, and all three respective policy msm files.  Running 
the install on a target 2003 machine, installation completes successfully, 
however the VC redist is NOT listed in add/remove programs, and the registry 
keys in ...\CurrentVersion\Installer\UserData\S-1-5-18\Products\ are not set.  
When running the downloadable vcredist_x86.exe, both of these things happen.
Our product code checks this registry key to determine the 
existence of the redist on the computer, so obviously it's important the WIX 
msi leverages the msm to accomplish this.
Has anyone seen anything like this? Is there any complications with the SP1 
redist? Are the SP1 msm's available separately?
Any help would be hugely appreciated, thanks very much.

Sincerely,
Jeb Remus
-
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] OS Version

[Neil Enns]

You should be able to use a combination of the Intel, Intel64, and Msix64 
standard properties. They are documented at 
http://msdn.microsoft.com/en-us/library/aa370905.aspx#hardware_properties.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Michael Faden [EMAIL 
PROTECTED]
Sent: Friday, August 15, 2008 4:02 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] OS Version

Hi,

can anbody tell me, how I can construct a conditional element for the
OS-version (32/64bit) like



  
 (OS is 32bit) 

  

  
(OS is 64bit)

   

Thx in adavnce

Filum




-
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



Sample disclaimer text
-
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] Minor Upgrade not detecting existing version

[Neil Enns]

Sonar,

Have you looked at the sample on Alex's blog for doing major upgrades? The 
details are at 
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx.
 It's a little lengthy but it should give you the details you need to make this 
work properly.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Sonar Chopra [EMAIL 
PROTECTED]
Sent: Thursday, August 14, 2008 5:43 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Minor Upgrade not detecting existing version

Hi,



I am trying to build a simple UI installer for our application. I want
to make sure that the application is upgradable in future. In order to
do so, I am playing around with Upgrade element in WIX source file.
Upgrade seems to work fine but I am not able to detect the old version
and newer version and stop the upgrade. Here is what I am trying to do:

1.   Install version 1.0.0 of the application.

msiexec /I ClientSetup.msi

Should work fine.



2.   Upgrade to version 1.0.1.

msiexec /I ClientSetup.msi  REINSTALL=ALL REINSTALLMODE=vamus

Should work fine.



3.   Try upgrading back to version 1.0.0.

msiexec /I ClientSetup.msi  REINSTALL=ALL REINSTALLMODE=vamus

Should display a message stating that a newer version already exists.



4.   Try upgrading back to version 1.0.1

msiexec /I ClientSetup.msi  REINSTALL=ALL REINSTALLMODE=vamus

Should display a message stating that this version already exists.



I have attached the source code in a zipped file. Please rename
ClientSetup._zip to ClientSetup.zip. The only change I am doing between
version 1.0.0 and version 1.0.1 is the change on line 7 in Product.wxs.

Please have a look and let me know what Am I missing here? Any help
would be greatly appreciated.





Thanks & regards,

-Sonar




CONFIDENTIALITY NOTICE: This communication may contain privileged or other 
confidential information.
If you have received it in error, please advise the sender by reply email and 
immediately delete the message and any attachments without copying or 
disclosing the contents.



Sample disclaimer text
-
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] Problem with [#fileid] reference.

[Neil Enns]

Michael,

Were you getting ICE validation warning when you were using the # reference? 
The way you had your components set up I would expect to see the validation 
warning specifically designed to prevent us from having to think :) It was 
raised in my installer when I used # incorrectly, so I fixed it.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] [EMAIL 
PROTECTED]
Sent: Thursday, August 14, 2008 1:04 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Problem with [#fileid] reference.



Thanks for the clarifications.

As cemiles suggest I've
changed the code to exactly that of using "[DIR]filename"

It just show that you cannot headlessly be sure that
"[#fileid]" references always work across your components and
wix source files. Now you'll have to think (we hate that, right?) when
using the [#fileid] references. And if the filename changes you may need
to change your "[DIR]filename" references.

/Michael


-
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



Sample disclaimer text
-
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] Problem with [#fileid] reference.

[Neil Enns]

That's correct. This is alluded to in the documentation for ICE warning 69 at 
http://msdn.microsoft.com/en-us/library/aa369019(VS.85).aspx:

"If the component referenced with the [$componentkey] property is already 
installed and is not being changed during the current installation (for 
example, being reinstalled, moved to source, and so forth), the expression 
[$componentkey] evaluates to null, because the action state of the component in 
[$componentkey] is null. Similar problems can occur during upgrade and repair 
operations."

I would expect that you're getting ICE69 warnings given the snippet below, 
since you are doing a cross-component reference using #.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, August 13, 2008 2:46 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problem with [#fileid] reference.




Am I correct to assume that using [#fileid] syntax to refer to a file
does not work if that files' component is marked with
Permanent="yes" and/or NeverOverwrite="yes"?

I.e. it will only be correctly evaluated if the installer actually
"processes", e.g. installs, the file.

Example:

...
 
   
 

 



 
...

The "[#SystemSettings.xml]" reference will only work the
first time the install is run. When uninstalling, the SystemSettings.xml
file will not be uninstalled (due to the Permanent attribute) and when
re-installed it will not be overwritten (due to the
NeverOverwrite="yes" attribute). But at the same time it will
evaluate [#SystemSettings.xml] to blank/empty so that referenced may not
get what is expected (or what?).

Is this by design or a bug?

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


Sample disclaimer text

-
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] Unicode characters in MSI setup package?

[Neil Enns]

Glad to help!

-Original Message-
From: Nemzági Ferenc <[EMAIL PROTECTED]>
Sent: Monday, August 11, 2008 3:31 PM
To: General discussion for Windows Installer XML toolset. 

Subject: Re: [WiX-users] Unicode characters in MSI setup package?


Hi Neil,

Wow, your relpy was extremely fast, thanks a lot!

I changed it Central Europan (1250), a it it works!

Thanks again,

Nemzagi



Neil Enns <[EMAIL PROTECTED]> írta:


> Have you set the codepage appropriately on your  element? See the 
> "Code Page" topic in the WiX documentation for more details.
>
> Neil
>
> -Original Message-
> From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Nemzági Ferenc
> Sent: Monday, August 11, 2008 3:19 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Unicode characters in MSI setup package?
>
> Hi,
>
>
>
> Iâ019m using WIX 2 to create a MSI setup package for German users, so texts 
> contain special Unicode characters like 'ö' and 'ü'. The encoding of my "wxs" 
> file is "UTF-8 with signature", but unfortunately candle.exe (2.0.5325.0) 
> creates question marks (?) instead of these characters in MSI texts.
>
> What shall I do? Can WIX 2 support Unicode? I cannot found any specific 
> command line switch of candle.exe. If WIX 2 cannot support such Unicode 
> characters, I cannot use it at all.
>
>
>
> Thanks a lot for your replies and suggestions.
>
> Best,
>
>
>
> Nemzagi
>
>
>
> __
> Egész nyáron szombat esti láz!
> http://videa.hu/videok/zene/mtv-icon-tribute-to-lgt-balaton-cokeclub-coketv-YUxNbEgI5kzWjLjP
> -
> 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
>
>
> Sample disclaimer text
>
> -
> 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
>

__
Egész nyáron szombat esti láz!
http://videa.hu/videok/zene/mtv-icon-tribute-to-lgt-balaton-cokeclub-coketv-YUxNbEgI5kzWjLjP
-
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


Sample disclaimer text

-
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] Unicode characters in MSI setup package?

[Neil Enns]

Have you set the codepage appropriately on your  element? See the 
"Code Page" topic in the WiX documentation for more details.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nemzági Ferenc
Sent: Monday, August 11, 2008 3:19 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Unicode characters in MSI setup package?

   Hi,



   Iâ019m using WIX 2 to create a MSI setup package for German users, so texts 
contain special Unicode characters like 'ö' and 'ü'. The encoding of my "wxs" 
file is "UTF-8 with signature", but unfortunately candle.exe (2.0.5325.0) 
creates question marks (?) instead of these characters in MSI texts.

   What shall I do? Can WIX 2 support Unicode? I cannot found any specific 
command line switch of candle.exe. If WIX 2 cannot support such Unicode 
characters, I cannot use it at all.



   Thanks a lot for your replies and suggestions.

   Best,



  Nemzagi



__
Egész nyáron szombat esti láz!
http://videa.hu/videok/zene/mtv-icon-tribute-to-lgt-balaton-cokeclub-coketv-YUxNbEgI5kzWjLjP
-
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


Sample disclaimer text

-
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] Call a .NET dll file in wix using custom

[Neil Enns]

A live.com search for 0x80131043 yielded many results, including this one at 
Aaron's blog: http://blogs.msdn.com/astebner/archive/2004/11/10/255346.aspx, 
and this specific comment from him in the comment section:

"The error code you are getting is 0x80131043.  According to the chart at the 
top of this blog post, it means "Modules which are not in the manifest were 
streamed in."  This most likely means that your assembly component contains 
other files that are not a part of this assembly.  You will need to double 
check your WXS file and make sure that you are only installing one assembly per 
component (unless the assembly consists of multiple files and is a multi-module 
assembly)."

Neil


From: Poornima S [EMAIL PROTECTED]
Sent: Monday, August 04, 2008 9:54 PM
To: wix-users@lists.sourceforge.net
Cc: Neil Enns
Subject: Re: [WiX-users] Call a .NET dll file in wix using custom

I tried to register DLL in the GAC, by adding Assembly=".net" to my
 element, as below:




But I am getting an error when I try to run my installer as follows:

An error occurred during the installation of assembly
'DLFetcher,version="1.1.0.0",
culture="neutral",publickeyToken="402B9D8975482830'". Please refer to
Help and support for more information. HRESULT:0x80131043.

Please can you further help me out in solving this issue.

Regards
Poornima.S
Aztecsoft Limited


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Monday, August 04, 2008 8:32 PM
To: wix-users@lists.sourceforge.net
Subject: WiX-users Digest, Vol 27, Issue 8

Send WiX-users mailing list submissions to
wix-users@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wix-users
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]

You can reach the person managing the list at
[EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of WiX-users digest..."


Today's Topics:

   1. FW: Re:  ServiceInstall account problem (Daniel Rieck)
   2. updating with a different account? (Mattias ?slund)
   3. Call a .NET dll file in wix using custom action (Poornima S)
   4. Re: updating with a different account? (Eitan Behar)
   5. Re: Call a .NET dll file in wix using custom action (Neil Enns)
   6. Sending params to Deferred Custom Action (Benas)
   7. Re: Sending params to Deferred Custom Action (Buddell, James)


--

Message: 1
Date: Mon, 04 Aug 2008 13:07:39 +0200
From: Daniel Rieck <[EMAIL PROTECTED]>
Subject: [WiX-users] FW: Re:  ServiceInstall account problem
To: "General discussion for Windows Installer XML toolset."

Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-15



That put me in the right direction.

Thanks to everyone!

*Von:* "Daniel Rieck" <[EMAIL PROTECTED]>
*Gesendet:* 01.08.08 22:35:39
*An:* "General discussion for Windows Installer XML toolset."

*Betreff:* Re: [WiX-users] ServiceInstall account problem
I'm already home for the weekend, but I'll check that on Monday, because
I changed all the names in the file before sending it...


*Von:* "Wilson, Phil" <[EMAIL PROTECTED]>
*Gesendet:* 01.08.08 20:40:07
*An:* General discussion for Windows Installer XML toolset.

*Betreff:* Re: [WiX-users] ServiceInstall account problem



Isn't the Name required to be the same in ServiceInstall and
ServiceControl?

(As in the example at
http://avinashkt.blogspot.com/2007/05/how-to-install-windows-service-usi
ng.html where they are both WixServiceInstaller).

Phil Wilson


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Daniel
Rieck
Sent: Friday, August 01, 2008 12:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] ServiceInstall account problem



Here's my entire WiX file:


http://schemas.microsoft.com/wix/2006/wi
[http://schemas.microsoft.com/wix/2006/wi]";>





























I found this snippet at
http://avinashkt.blogspot.com/2007/05/how-to-install-windows-service-usi
ng.html
[http://avinashkt.blogspot.com/2007/05/how-to-install-windows-service-us
ing.html]

I tried removing the Account and Password properties altogether, so it
would default to LocalSystem, but that didn't help either.


*Von:* "Bob Arnson" <[EMAIL PROTECTED]>
*Gesendet:* 31.07.08 23:47:23
*An:* "General discussion for Windows Installer XML toolset."

*Betreff:* Re: [WiX-users] ServiceInstall account problem



Daniel Rieck wrote:
> 1) I&#

Re: [WiX-users] How to ignore selected ICE errors or warnings during compilation

[Neil Enns]

John,

Are you building using a .wixproj file? Or custom command-line stuff?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Gilbert 
(MBS)
Sent: Monday, August 04, 2008 4:26 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to ignore selected ICE errors or warnings during 
compilation

I just started using WIX build 3.0.2420.0,  (I was using 3.0.1502.0).  When 
Light.exe runs it performs the ICE validations.
Some of those, I want to ignore.  However, I have not been able to figure out 
how to do so.

Here are a couple of lines of output I am seeing:
1>c:\main\source\setup\msiwix\components64\components64.wxs(424) : error 
LGHT0204 : ICE80: This 32BitComponent Client.Anameterdll uses 64BitDirectory 
DIR_Client_Common
1>c:\main\source\setup\msiwix\components64\components64.wxs(438) : error 
LGHT0204 : ICE80: This 32BitComponent RemoveDIR_SetupTmpFiles uses 
64BitDirectory DIR_Setup
1>c:\main\source\setup\msiwix\components64\components64.wxs(442) : error 
LGHT0204 : ICE80: This 32BitComponent Setup.SynchronizationServiceDll uses 
64BitDirectory DIR_Setup
1>c:\main\source\setup\msiwix\components64\components64.wxs(449) : error 
LGHT0204 : ICE80: This 32BitComponent Setup.NetBusinessConnector uses 
64BitDirectory DIR_Setup
1>c:\main\source\setup\msiwix\components64\components64.wxs(458) : error 
LGHT0204 : ICE80: This 32BitComponent Setup.SynchronizationProxyOfficeDll uses 
64BitDirectory DIR_Setup

In this instance, the errors relate to a common merge module included in both a 
32bit and 64bit MSI.  Everything had been working just fine on 64 bit machines, 
(with MSIs built with build 1502), so it appears that I can ignore this error.  
However it is causing the compile to fail.

I tried the following SW command line parms for Light.exe, but they either 
caused their own errors or did nothing.  Some of the errors say the parm should 
look like "-sw6".
-sw
-sw0204
-swLGHT0204
-sw80
-swICE80
All of the above with the values in angle brackets.

Anybody know how to get Light.exe to skip selected ICE validations?


:-) John Gilbert


-
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] Call a .NET dll file in wix using custom action

[Neil Enns]

If all you are trying to do is register your DLL in the GAC, add 
Assembly=".net" to your  element and it'll automatically get installed to 
the GAC.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Poornima S [EMAIL 
PROTECTED]
Sent: Monday, August 04, 2008 5:38 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Call a .NET dll file in wix using custom action




Hi All,



I have a DLfetcher.dll file which is in .NET. I need to create a WIX
installer for my application, and when I run that msi the dll file
should get registered in GAC. I modified my WXS file to use custom
action behaviour of WIX. Code is as below:















But when I run installer, I couldn't find in gac folder the registry
entry creating a DlFetcher folder. Please help me to get out of here.

Is there any way to call a dll file from wix and while I try to run my
installer that should get registered in GAC.?



Thanks everyone in advance...



Regards

Poornima.S





This email message and its attachments may contain CONFIDENTIAL AND PRIVILEGED 
INFORMATION intended for the sole use of the addressee(s). If you have received 
it in error, please contact the sender by return email, notify your system 
manager and destroy the original message and any copies thereof. Any review, 
use, disclosure or distribution is unlawful. Please check this email and any 
attachments for the presence of viruses. The Company accepts no  liability for 
any damage caused by any virus transmitted by this email. The views or opinions 
presented in this e-mail are solely those of the author and do not necessarily 
represent those of the company.
The Company reserves the right to monitor, review and store the content of all 
messages sent to or from this e-mail address.

www.aztecsoft.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] Loading Extensions

[Neil Enns]

Neil,

Can you open a sourceforge bug on this requesting the clarified documentation? 
Thanks!

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Neil Sleightholm [EMAIL 
PROTECTED]
Sent: Sunday, August 03, 2008 2:38 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Loading Extensions

Thanks, that was it. I had a hunt round the documentation and I couldn't
see that documented and I didn't think the command line help made it too
clear either. I'm sure there is lots that need documenting but I think
this would be useful to add.

Neil

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: 02 August 2008 21:43
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Loading Extensions

Neil Sleightholm wrote:
> That's odd, I tried it today before posting with v3.0.4401.0 and it
> doesn't work. Just to confirm what I did, I put candle in the path and
> got this error:
>   candle.exe : error CNDL0144 : The extension WixUIExtension.dll'
> could not be loaded.
>

Drop the ".dll" extension. If you give a filename, it will try to load
it as a path and it doesn't have enough information to do so.

--
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] Overriding DefaultConstants or sending variables to candle using TFSBuild

[Neil Enns]

Unfortunately I don't have a TFS install handy to look at this directly :( I 
did some quick searches on-line and it looks like depending on the version of 
Team Build you're using that you might need to modify some targets files to 
make this work. I would suggest asking your question over at the Team Build 
fourm (http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=481&SiteID=1), 
someone there likely can tell you how to do this.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Joe Pub [EMAIL PROTECTED]
Sent: Saturday, August 02, 2008 3:12 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Overriding DefaultConstants or sending variables to 
candle using TFSBuild

But my problem is that I need some of the properties that are created
in the tfsbuild.proj.  I am trying to get the version number that is
generated in the tfsbuild.proj into the .wixproj.  So there is no way
to get them into the .wixproj?

Thanks


2008/8/1 Neil Enns <[EMAIL PROTECTED]>:
> Joe,
>
> Simply setting properties in the tfsbuild.proj file won't get them passed 
> down into the .wixproj. I wasn't sure about this and had to look it up. Is it 
> an option to just include those changes directly in the .wixproj file instead?
>
> Neil
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Pub
> Sent: Friday, August 01, 2008 9:19 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Overriding DefaultConstants or sending variables to 
> candle using TFSBuild
>
> I have tried both CreateProperty and PropertyGroup, and neither seem
> to work.  I have placed mine inside Project element inside the
> TFSBuild.proj file which looks like this
>
>  
>TestString
>  
>
>  
>Test=$(TestProp)
>  
>
> So based off my understanding, the DefineConstants should be totally
> replaced using the above code, but when checking the build log, it has
> all the defines that have been specified using votive.
>
> Any ideas?
>
> 2008/8/1 Neil Enns <[EMAIL PROTECTED]>:
>> You can definitely do this. My first question is why are you using 
>> CreateProperty instead of setting a property directly using  
>> elements? You should only have to use CreateProperty if the value is 
>> something computed on the fly by the build.
>>
>> Here's what our project file looks like:
>>
>>  
>>  
>>
>>$(EXTPATH)\BootstrapFiles
>>
>>
>> $(INETROOT)\target\$(Configuration)\i386
>>  
>>
>>  
>> 
>> $(DefineConstants);SourceFileLocation=$(SourceFileLocation);RedistPath=$(RedistPath)
>>  
>>
>> The values for $(DefineConstants), $(SourceFileLocation), etc. can come from 
>> anywhere, including from your TFSBuild.proj file I believe. In our case they 
>> happen to be in the same .wixproj as the  element.
>>
>> Neil
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Pub
>> Sent: Friday, August 01, 2008 9:03 AM
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] Overriding DefaultConstants or sending variables to 
>> candle using TFSBuild
>>
>> Hi,
>>
>> I am using Wix 3.0.4318.0.  I have created a Wix project using Votive
>> and have added it to TFS.  I am attempting to either customise the
>> whole DefaultConstants property inside my TFSBuild.proj file or create
>> a property which is referenced in the DefaultsConstants property at no
>> avail.
>>
>> I have created a property insode the BeforeCompile target inside
>> TFSBuild.proj like this
>>
>>
>>  
>>
>>
>> and then Votive has a reference to using the Define preprocessor
>>
>> Test=$(TestProp).
>>
>> When checking the Build log, the candle command line lists the Test
>> var as empty.
>>
>> I have also tried another approach of attempting to override the whole
>> DefaultsConstants property inside TFSBuild.proj.  Is there a way to
>> get variables to the candle compiler?
>>
>> Thanks
>>
>> -
>> 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=/
>> ___
>> Wi

Re: [WiX-users] Overriding DefaultConstants or sending variables to candle using TFSBuild

[Neil Enns]

Joe,

Simply setting properties in the tfsbuild.proj file won't get them passed down 
into the .wixproj. I wasn't sure about this and had to look it up. Is it an 
option to just include those changes directly in the .wixproj file instead?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Pub
Sent: Friday, August 01, 2008 9:19 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Overriding DefaultConstants or sending variables to 
candle using TFSBuild

I have tried both CreateProperty and PropertyGroup, and neither seem
to work.  I have placed mine inside Project element inside the
TFSBuild.proj file which looks like this

  
TestString
  

  
Test=$(TestProp)
  

So based off my understanding, the DefineConstants should be totally
replaced using the above code, but when checking the build log, it has
all the defines that have been specified using votive.

Any ideas?

2008/8/1 Neil Enns <[EMAIL PROTECTED]>:
> You can definitely do this. My first question is why are you using 
> CreateProperty instead of setting a property directly using  
> elements? You should only have to use CreateProperty if the value is 
> something computed on the fly by the build.
>
> Here's what our project file looks like:
>
>  
>  
>
>$(EXTPATH)\BootstrapFiles
>
>
> $(INETROOT)\target\$(Configuration)\i386
>  
>
>  
> 
> $(DefineConstants);SourceFileLocation=$(SourceFileLocation);RedistPath=$(RedistPath)
>  
>
> The values for $(DefineConstants), $(SourceFileLocation), etc. can come from 
> anywhere, including from your TFSBuild.proj file I believe. In our case they 
> happen to be in the same .wixproj as the  element.
>
> Neil
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Pub
> Sent: Friday, August 01, 2008 9:03 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Overriding DefaultConstants or sending variables to 
> candle using TFSBuild
>
> Hi,
>
> I am using Wix 3.0.4318.0.  I have created a Wix project using Votive
> and have added it to TFS.  I am attempting to either customise the
> whole DefaultConstants property inside my TFSBuild.proj file or create
> a property which is referenced in the DefaultsConstants property at no
> avail.
>
> I have created a property insode the BeforeCompile target inside
> TFSBuild.proj like this
>
>
>  
>
>
> and then Votive has a reference to using the Define preprocessor
>
> Test=$(TestProp).
>
> When checking the Build log, the candle command line lists the Test
> var as empty.
>
> I have also tried another approach of attempting to override the whole
> DefaultsConstants property inside TFSBuild.proj.  Is there a way to
> get variables to the candle compiler?
>
> Thanks
>
> -
> 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] Overriding DefaultConstants or sending variables to candle using TFSBuild

[Neil Enns]

Fixed a typo below, I botched a closing PropertyGroup tag.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, August 01, 2008 9:10 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Overriding DefaultConstants or sending variables to 
candle using TFSBuild

You can definitely do this. My first question is why are you using 
CreateProperty instead of setting a property directly using  
elements? You should only have to use CreateProperty if the value is something 
computed on the fly by the build.


Here's what our project file looks like:

  
  

$(EXTPATH)\BootstrapFiles


$(INETROOT)\target\$(Configuration)\i386
  

  
 
$(DefineConstants);SourceFileLocation=$(SourceFileLocation);RedistPath=$(RedistPath)
  

The values for $(DefineConstants), $(SourceFileLocation), etc. can come from 
anywhere, including from your TFSBuild.proj file I believe. In our case they 
happen to be in the same .wixproj as the  element.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Pub
Sent: Friday, August 01, 2008 9:03 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Overriding DefaultConstants or sending variables to candle 
using TFSBuild

Hi,

I am using Wix 3.0.4318.0.  I have created a Wix project using Votive
and have added it to TFS.  I am attempting to either customise the
whole DefaultConstants property inside my TFSBuild.proj file or create
a property which is referenced in the DefaultsConstants property at no
avail.

I have created a property insode the BeforeCompile target inside
TFSBuild.proj like this


  


and then Votive has a reference to using the Define preprocessor

Test=$(TestProp).

When checking the Build log, the candle command line lists the Test
var as empty.

I have also tried another approach of attempting to override the whole
DefaultsConstants property inside TFSBuild.proj.  Is there a way to
get variables to the candle compiler?

Thanks

-
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] Overriding DefaultConstants or sending variables to candle using TFSBuild

[Neil Enns]

You can definitely do this. My first question is why are you using 
CreateProperty instead of setting a property directly using  
elements? You should only have to use CreateProperty if the value is something 
computed on the fly by the build.

Here's what our project file looks like:

  
  

$(EXTPATH)\BootstrapFiles


$(INETROOT)\target\$(Configuration)\i386
  

  
 
$(DefineConstants);SourceFileLocation=$(SourceFileLocation);RedistPath=$(RedistPath)
  

The values for $(DefineConstants), $(SourceFileLocation), etc. can come from 
anywhere, including from your TFSBuild.proj file I believe. In our case they 
happen to be in the same .wixproj as the  element.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Pub
Sent: Friday, August 01, 2008 9:03 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Overriding DefaultConstants or sending variables to candle 
using TFSBuild

Hi,

I am using Wix 3.0.4318.0.  I have created a Wix project using Votive
and have added it to TFS.  I am attempting to either customise the
whole DefaultConstants property inside my TFSBuild.proj file or create
a property which is referenced in the DefaultsConstants property at no
avail.

I have created a property insode the BeforeCompile target inside
TFSBuild.proj like this


  


and then Votive has a reference to using the Define preprocessor

Test=$(TestProp).

When checking the Build log, the candle command line lists the Test
var as empty.

I have also tried another approach of attempting to override the whole
DefaultsConstants property inside TFSBuild.proj.  Is there a way to
get variables to the candle compiler?

Thanks

-
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] Wix and TFS

[Neil Enns]

Here's the documentation I mentioned that should show up in the next weekly WiX 
build:

Integrating WiX Projects Into Daily Builds

One of the most common reasons for using MSBuild with WiX project files is to 
integrate the build of an installer into an existing daily build process. This 
is often coupled with a need to build WiX projects without having to 
pre-install any WiX tools on the daily build machine. WiX projects and the WiX 
toolset to build them can be added to most daily build processes that support 
MSBuild using a few simple steps.

Step 1: Check in the WiX Toolset

To avoid having to install WiX on build machines you can check all the tools 
necessary to build WiX projects into your source code control system. Here's 
how:

1. Install WiX on a developer machine using the standard WiX installer
2. Create a directory in your source code control system to hold the WiX tools
3. Copy the contents of c:\Program Files\Windows Installer XML v3\bin into the 
directory created in step 2
4. Copy the contents of c:\Program Files\MSBuild\Microsoft\WiX\v3.0 into the 
directory created in step 2
5. Add and check in the files from steps 3 and 4

Step 2: Modify Your .wixproj File

After checking the WiX tools into source code control the .wixproj file must be 
modified to point to the location of the checked in tools. Open the .wixproj 
file in any text editor, such as Visual Studio, and add the following to the 
file anywhere between the  element before the  element:


$(SourceCodeControlRoot)\wix\3.0.4311.0
$(WixToolPath)\Wix.targets
$(WixToolPath)\wixtasks.dll


The WixToolPath must be set to point to the location of the WiX tools directory 
created in Step 1. The method used to reference the location will vary 
depending on your build system, but it can either be a relative path to the 
directory (such as ..\..\tools), an MSBuild property that is set via an 
environment variable (such as $(BinariesRoot) in a Team Foundation Server 
build) or a custom property passed in on the command-line or via an environment 
variable.

The WixTargetsPath and WixTasksPath properties direct MSBuild to use the WiX 
build process and WiX tasks from the tools directory.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sajid1105
Sent: Thursday, July 31, 2008 11:18 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix and TFS


I have a list of wxs files that packages files from a share folder where Team
build stages its build result. Currently I am having batch file containing
candle and light commands with sharefolder path as a parameter.

I want to integrate it with TFS so that each time I schedule a build it
creates an msi package.
What is the best way to do that in this situation?
I looked at wix.targets but left with no clue of what to do with that.
--
View this message in context: 
http://www.nabble.com/Wix-and-TFS-tp18768809p18768809.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] Wix and TFS

[Neil Enns]

Sajid,

Create a .wixproj file either manually or using the Votive integration with 
Visual Studio, then check that project into TFS. After that's done you can go 
through some easy steps to check the WiX tools into TFS and make a minor 
modification to the .wixproj file so it will build on your daily build machine.

I have a new topic in the WiX help documentation that addresses this, although 
we haven't released that build yet. When I get in to work today I"ll reply 
again with the information.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Sajid1105 [EMAIL 
PROTECTED]
Sent: Thursday, July 31, 2008 11:18 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix and TFS


I have a list of wxs files that packages files from a share folder where Team
build stages its build result. Currently I am having batch file containing
candle and light commands with sharefolder path as a parameter.

I want to integrate it with TFS so that each time I schedule a build it
creates an msi package.
What is the best way to do that in this situation?
I looked at wix.targets but left with no clue of what to do with that.
--
View this message in context: 
http://www.nabble.com/Wix-and-TFS-tp18768809p18768809.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] Information about PrintEula.dll

[Neil Enns]

Stefan,

We had the same problem and resolved it by simply downloading the source to WiX 
and then building the printeula project inside of it. Then we included the 
printeula.dll in our installer.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Stefan Webb [EMAIL 
PROTECTED]
Sent: Wednesday, July 30, 2008 12:58 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Information about PrintEula.dll

I am trying to customize my dialogs in Wix 3.0.4318. I have extracted the
standard dialogs from the source and compiled a modified version of them
with my project. If I include WixUIExtension.dll then it is not possible to
customize the FilesInUse dialog, as pointed out in an earlier thread.
However, if I do not include WixUIExtension.dll, then I do not have access
to the custom actions in PrintEula.dll.

My understanding is that PrintEula.dll contains two functions,
WixUIPrintEula and WixUIValidatePath. I believe WixUIPrintEula finds the
handle of the RichEdit control in the MSI window, extracts the text, and
sends it the printer. It doesn't take or return any parameters. Is this
correct? I am not sure what the WixUIValidatePath function does, if it is
crucial and how it is called. I am an experienced Win32 developer and would
like to implement my own PrintEula.dll file. Would somebody be able to
provide more information on the PrintEula.dll file?

Thanks,
Stefan.
-
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] Building msi across OS's

[Neil Enns]

Something's not making sense. Properties like [WindowsFolder] are stored 
directly in the MSI and are resolved at install time. Were you simply using it 
as a path in something like a  element? What do the install logs show 
when you run the MSI on the target machine?

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Greg Silin [EMAIL 
PROTECTED]
Sent: Tuesday, July 29, 2008 7:12 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Building msi across OS's

Rob,

Thanks for the advice.  Unfortunately, my experience was that when 
[WindowsFolder] was used, it would resolve on the machine where the code *was 
compiled*.  Since I built my code on the client (which might not be a smart 
choice anyway, but that's a different story), it resolved to C:\Windows in the 
wixobj file.  That will not work on the Win 2003 OS.

Am I doing something wrong?

Thanks
-greg

-Original Message-
Date: Mon, 28 Jul 2008 20:45:25 -0700
From: Rob Mensching <[EMAIL PROTECTED]>
Subject: Re: [WiX-users] Building msi across OS's
To: General discussion for Windows Installer XML toolset.

Message-ID:
<[EMAIL PROTECTED]>

Content-Type: text/plain; charset="us-ascii"

You don't need a CustomAction.  The Windows Installer has built in variables 
for a great many paths in Windows.  WindowsFolder in this case.  MSI SDK lists 
them all.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Silin
Sent: Monday, July 28, 2008 16:48
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Building msi across OS's

Hi,

Question from a wix newbie.

I ran into the following issue:

I am building an msi in Vista (let's just say client) that could be installed 
either on Vista (client) or Win 2003 Server OS.  One of the issues was that the 
framework resides under C:\WINNT in the server OS, and under C:\Windows in 
client (vista in my case).

Apparently, any environment variables in wxs are resolved at compile, not run 
time.  Is the only way to make it possible to use one MSI to do a CustomAction 
that first determines which of the OS's I'm running on and then attempt to set 
the property?  Is that even possible?

Thanks for any tips :)
-greg

-
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] How to include localized components?

[Neil Enns]

To elaborate a bit on what Rob states below (thanks for setting me straight, 
Rob!), you can use !(loc) variables as the value for the Source attribute on a 
 element. So in your Japanese localization file you can set a String 
property to the path to the Japanese version of the files on disk, and in the 
English localization file the path can be to the English files.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Rob Mensching [EMAIL 
PROTECTED]
Sent: Monday, July 28, 2008 8:35 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to include localized components?

.wxl files are an easier way to do this.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Ballou
Sent: Monday, July 28, 2008 18:51
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to include localized components?

I currently have two installs for my product.  One in English and one in
Japanese.  Most files are the same for both languages, but some files
are different.



I was planning to use Wix include files (wxi) for the languages (one for
English, and one for Japanese).  I could then include the correct
components and files in the Japanese install and separate components and
files in the English install.



I'm currently using VS 2008 with Wix to build my project which can build
both the English and Japanese at the same time, but I'm trying to see
how I can use a preprocessor variable to perform the right include.



So my main .wxs file would have this at the top:



  





Is that possible, or is there a much easier way to do this?  I don't see
any variables for the culture currently being built.



Thanks,

Mike Ballou



-
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] Building msi across OS's

[Neil Enns]

Greg,

Check out the netfxutil extension. It includes many properties, including the 
directories for various versions of the framework. The help file has a how to 
on using it to get the framework version, and that is similar to using it for 
the directory. All the available properties are in the help file as well.

-Original Message-
From: Greg Silin <[EMAIL PROTECTED]>
Sent: Monday, July 28, 2008 4:49 PM
To: wix-users@lists.sourceforge.net 
Subject: [WiX-users] Building msi across OS's


Hi,

Question from a wix newbie.

I ran into the following issue:

I am building an msi in Vista (let's just say client) that could be installed 
either on Vista (client) or Win 2003 Server OS.  One of the issues was that the 
framework resides under C:\WINNT in the server OS, and under C:\Windows in 
client (vista in my case).

Apparently, any environment variables in wxs are resolved at compile, not run 
time.  Is the only way to make it possible to use one MSI to do a CustomAction 
that first determines which of the OS's I'm running on and then attempt to set 
the property?  Is that even possible?

Thanks for any tips :)
-greg

-
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] GUID generation in WiX

[Neil Enns]

That GUID would be generated at MSI build time, not at MSI install time, so it 
won't be unique for each user.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Pat Higgins [EMAIL 
PROTECTED]
Sent: Monday, July 28, 2008 4:51 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] GUID generation in WiX

You could try something like




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stas Klyachkovsky
Sent: 28 July 2008 12:32
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] GUID generation in WiX

Hi there,
I need to generate a GUID during the setup and put it in the registry key.
Is there a simple way to generate random GUID in Windows Installer during 
installation? Is there WiX tag to do this?

Thanks,
Stas
-
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


About Microsoft Ireland:  
www.microsoft.com/ireland
Microsoft Ireland Operations Limited. A company incorporated and registered in 
Ireland number 256796.
Microsoft Ireland Research. A company incorporated and registered in Ireland 
number 342235.
Registered office 70 Sir John Rogerson's Quay, Dublin 2, Ireland

-
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] Output file name and location changes in build 3.0.4325.0

[Neil Enns]

For those that don’t read Bob’s blog and see the weekly release summaries, 
please pay close attention to the note below regarding changes to address bug 
2020595. In builds 3.0.4325.0 and later the output location for WiX builds of 
localized installers is now outputdir\culturename\targetname.msi.

This change was made based on feedback and discussion on this list, and 
addresses the problem where my previous change broke minor upgrades due to the 
package name change. For those with additional build process that wraps the 
regular WiX builds you may need to tweak your scripts to account for the new 
output location when you move to this build of WiX (I know I will when I move 
my team to this build!).

The output location for unlocalized WiX projects (those that don’t contain a 
.wxl file) remains unchanged.

Thanks,

Neil

Feed: Joy of Setup
Posted on: Saturday, July 26, 2008 2:50 PM
Author: Bob Arnson
Subject: Highlights of WiX v3.0.4325.0


WiX v3.0.4325.0 was released on Friday, 25-July-08. You can download it from 
http://wix.sourceforge.net/releases/3.0.4325.0/.

New features

 *   Mike Carlson changed the preprocessor to stop evaluating expressions in a 
false  block. That lets you check for the presence of a preprocessor 
variable, for example, and use it in the block "knowing" that it’s defined.

Bug fixes

 *   Jason and Mike cleaned up FxCop warnings.
 *   Mike also added an error message when the cab-handling code couldn’t 
create temporary files.
 *   Aaron cleaned up some 
command-line handling code.
 *   2010040: Bind files into the library file not 
working.
 *   2013944: CAs always fail on Windows 2000 (or 
lower).
 *   2016490: Votive doesn’t honour Visible item metadata 

 *   2020595: 3.0.4309.0 breaks msi filename 
compatibility
Note that this change places localized output into subdirectories named after 
the culture (e.g., en-us). The previous change embedded the culture id in the 
output name (e.g., foo.en-us.msi) which might have caused problems because MSI 
package names can’t change except by major upgrade. Thanks to blogless Neil for 
the MSBuild mojo.
 *   2025134: Using ExtractFiles Method 

 *   2025411: Localized incremental builds are somewhat 
broken


View 
article...
-
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] Build Fails with NAnt. The format of the file 'NAntTasks.dll' is invalid.

[Neil Enns]

One option to consider is using the shipping MSBuild .targets file that has a 
complete build process for WiX in conjunction with NAnt. Trying to re-construct 
a build process using individual tasks is often fraught with peril, and using 
the one that ships with WiX is almost always a better idea.

You would create a .wixproj that uses the MSBuild process for building WiX (a 
quick way to do this is to create a WiX project in Visual Studio), and then in 
your nant build script just do . You'll 
get our well-tested and supported build process for free, yet still be able to 
use nant as your overall build driver.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Latendresse
Sent: Tuesday, July 22, 2008 2:36 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Build Fails with NAnt. The format of the file 
'NAntTasks.dll' is invalid.

I am using NAnt to build my WiX project. Here is the code:









































Here is the error I am getting:



BUILD FAILED - 1 non-fatal error(s), 0 warning(s)



D:\Development\SuiteBuild_Development\BuildProcess.build(209,4):

Failure scanning \"C:\Program Files (x86)\Windows Installer XML
v3\bin\Microsoft.

Tools.WindowsInstallerXml.NAntTasks.dll\" for extensions.

The format of the file
'Microsoft.Tools.WindowsInstallerXml.NAntTasks.dll' is invalid.



Total time: 0.1 seconds.





Eric





-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] conditionally adding registry entries (NOT conditional full installation)

[Neil Enns]

This won't work because you're using a pre-processor check for your condition, 
which happens at the time you build the MSI, not at the time you run it.

You need to do the check by adding a  element to the  
element that I assume eventually includes the Registry snippet below.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Deepak Bansal [EMAIL 
PROTECTED]
Sent: Tuesday, July 22, 2008 5:40 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] conditionally adding registry entries (NOT conditional 
full installation)

Hi All,

While installing a product, I want to add few extra registry entries
if the OS is Windows Vista. To achieve this, I created my .ddr file as
given below..but its not working. Am i missing something? Any help
will be highly appreciated..








  






-deepak

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

[Neil Enns]

Ilya,

Thanks for the additional insight into how your builds work. A follow-up 
question: is there something fundamental in the new localization work that 
doesn't integrate into your builds, or is the issue that the change to either a 
suffix or directory will require tweaks to your existing build process to 
integrate properly? For what it's worth, when I integrated this build of WiX 
into my own team we had to make a few build process tweaks as well.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ilya Slobodin
Sent: Monday, July 21, 2008 8:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Localization filename change

Hi Neil,

We use at least two builds of WiX at the same time. Newer builds on
the development computers and older and well-tested on the production
server. And we upgrade the server only when we need to use some new
functions. Before each upgrade we have to make sure that all our
setups are not broken.

For our environment, the output into subdirectories is better than
culture suffix but this still is not as flexible as It could be.

Is it possible to replace the proposed

$(TargetDir)\CultureName\$(TargetName)$(TargetExt).

with

$(TargetDir)\$(CultureSuffix)\$(TargetName)$(TargetExt)

where CultureSuffix is overridable and is empty by default when single
culture is used?

Or, even better, put
$(TargetDir)\$(CultureSuffix)\$(TargetName)$(TargetExt) into the
overridable property, say TargetDirLocalized.

Best regards,
Ilya Slobodin

- Original Message -----
From: "Neil Enns" <[EMAIL PROTECTED]>
To: "General discussion for Windows Installer XML toolset."

Sent: Monday, July 21, 2008 6:18 PM
Subject: Re: [WiX-users] Localization filename change


> Ilya,
>
> If we changed things so the localized output went into
> subdirectories, rather than modified the name of the MSI, would htat
> work for your situation?
> Neil
>
> 
> From: [EMAIL PROTECTED]
> [EMAIL PROTECTED] On Behalf Of Ilya Slobodin
> [EMAIL PROTECTED]
> Sent: Monday, July 21, 2008 1:59 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Localization filename change



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

[Neil Enns]

Thanks for the feedback Dominik. You're correct, there's no way to do count 
tests against items in an itemgroup using MSBuild.

One option I'm exploring is to modify the WiXAssignCultures task to supply that 
information.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Dominik Guder [EMAIL 
PROTECTED]
Sent: Monday, July 21, 2008 12:23 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Localization filename change




Neil Enns wrote:
>
> 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
>
>

Hi Neil,

I think there is no single way to do fit in all circumstances.
Adding the culture makes sense, if you really use it to provide msi files
for multiple cultures. Also the directory would help.
But in case of a single culture there should be a way to handle this without
culture in filename.
I took a short look and I couldn't find a masbuild way to determine if a
itemgroup contains only one
item. So maybe the culture dialog/light should be extendend to use another
property like "single culture" or "create *.culture.msi" to handle this
issue.

Regards Dominik
--
View this message in context: 
http://www.nabble.com/Localization-filename-change-tp18527119p18563392.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] Localization filename change

[Neil Enns]

Ilya,

If we changed things so the localized output went into subdirectories, rather 
than modified the name of the MSI, would htat work for your situation?
Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Ilya Slobodin [EMAIL 
PROTECTED]
Sent: Monday, July 21, 2008 1:59 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Localization filename change

Hi Bob, Rob, Neil and others,

Sorry for being so emotional, I really appreciate your work for the
WiX project.

>From my point of view the best approach is overridability, and
backward compatibility when possible. So, I fully agree with Dominik's
position.

Our projects have multiple languages that are build into different
subdirectories by custom scripts. That's why I was pleased to see the
new multi-language-build feature and then I was slightly dissapointed
that I cannot override the output name and fit into my existing
environment. Anyway, such minor inconsitencies are usual for a growing
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] 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] 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

[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] Where does FilesInUse dialog get its names from?

[Neil Enns]

Solved!

Tony, if you are writing a managed application, you need to make sure it has 
the AssemblyTitle assembly attribute set on it. That's where the string comes 
from.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic
Sent: Wednesday, July 16, 2008 7:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?

Same problem here so I second a plea for help and more info

-Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 12:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names
from?

Well, unfortunately, that's not what's happening. It's detecting that
we're running, and if we say "next" on the dialog our application shuts
down properly. But the list box is empty.

How can we go about debugging why?

Neil


From: [EMAIL PROTECTED]
[EMAIL PROTECTED] On Behalf Of Bob Arnson
[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2008 6:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names
from?

Neil Enns wrote:
> It appears that our installer is magically detecting whether our
application is running at the time of an install, and even correctly
closes it. However, the FilesInUse dialog that comes with WiXUI isn't
showing anything in the listbox of running processes. What magic do we
need to do to populate the listbox with the name of our application?
>

MSI should be showing only apps with visible, top-level windows; the
content of the list box item is the window title. So it should be
automatic "free." If MSI doesn't find the right kind of windows or
titles, it should skip them and, if none, not show FilesInUse at all
(just reboot).

--
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] Where does FilesInUse dialog get its names from?

[Neil Enns]

Ok, I'm making a bit of progress. Here's what the msi log says:

MSI (s) (80:C8) [10:11:05:038]: RESTART MANAGER: Detected that application with 
id 5816, friendly name ' ', of type RmUnknownApp and status 1 holds file[s] in 
use.

Clearly the friendly name is blank. So the big question is: where do we set the 
friendly name? I've also got a bug about how our application doesn't display 
any name in the default programs dialog. Clearly something on the assembly 
isn't being set. What is that something?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic
Sent: Wednesday, July 16, 2008 7:30 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?

Same problem here so I second a plea for help and more info

-----Original Message-
From: Neil Enns [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 12:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names
from?

Well, unfortunately, that's not what's happening. It's detecting that
we're running, and if we say "next" on the dialog our application shuts
down properly. But the list box is empty.

How can we go about debugging why?

Neil


From: [EMAIL PROTECTED]
[EMAIL PROTECTED] On Behalf Of Bob Arnson
[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2008 6:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names
from?

Neil Enns wrote:
> It appears that our installer is magically detecting whether our
application is running at the time of an install, and even correctly
closes it. However, the FilesInUse dialog that comes with WiXUI isn't
showing anything in the listbox of running processes. What magic do we
need to do to populate the listbox with the name of our application?
>

MSI should be showing only apps with visible, top-level windows; the
content of the list box item is the window title. So it should be
automatic "free." If MSI doesn't find the right kind of windows or
titles, it should skip them and, if none, not show FilesInUse at all
(just reboot).

--
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] Wix and MSBuild

[Neil Enns]

That sounds perfectly reasonable!

Neil


-Original Message-
From: Adam Connelly <[EMAIL PROTECTED]>
Sent: Thursday, July 17, 2008 8:41 AM
To: General discussion for Windows Installer XML toolset. 

Subject: Re: [WiX-users] Wix and MSBuild


Thanks a lot for the replies.  I'm hitting myself on the head - just 5 minutes 
before reading both replies I had given up with the hand-editing and added a 
Wix project.  So I now have exactly what Christopher recommended :P

I created a separate Solution configuration that just builds Wix projects (i.e. 
the only one I have at the moment), then just use the MSBuild task in my build 
file to build them.  Does that sound sensible or have I overcomplicated things?

Anyhow, thanks again - everything's working.

Adam

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: 17 July 2008 15:14
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and MSBuild

Adam,

WiX ships with complete MSBuild support through a set of tasks and targets, 
there's no need to try and hand-edit things.

Do you have Visual Studio installed? If so, create a new Visual Studio project 
and look for a WiX node in the new project dialog. Create that, add the 
contents of your existing ProjA.wxs to the .wxs file that's created, and build. 
Voila!

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Adam Connelly [EMAIL 
PROTECTED]
Sent: Thursday, July 17, 2008 6:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and MSBuild

I actually sorted the problem (a typo :().  I would still be interested to find 
out how others structure their projects.

Adam

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Connelly
Sent: 17 July 2008 11:19
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix and MSBuild

Hi,

I currently trying to add a task into my MSBuild file that will create the 
various MSI files needed for the project.  I've got the following file 
structure:

Root/
  Build.xml
  Code/
Deploy/
  ProjA
  ProjB
  Installs/
ProjA.wxs

Sorry if that's not amazingly clear.  Basically, all the assemblies, etc for 
each project are in Code/Deploy/ProjX, and the wix file is in 
Installs/ProjX.wxs.  I want to be able to build an installer while keeping this 
structure if possible.

The problem I'm having is that although candle.exe runs fine, light.exe can't 
seem to find the source files no-matter if I set the -b switch, or if I alter 
the Source attributes in the wxs file.

I guess what I really want to know is how do other people structure their 
builds when there may be multiple projects needing installers built, etc.

Sorry for such a broad question.

Cheers,
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 m

Re: [WiX-users] Wix and MSBuild

[Neil Enns]

Adam,

WiX ships with complete MSBuild support through a set of tasks and targets, 
there's no need to try and hand-edit things.

Do you have Visual Studio installed? If so, create a new Visual Studio project 
and look for a WiX node in the new project dialog. Create that, add the 
contents of your existing ProjA.wxs to the .wxs file that's created, and build. 
Voila!

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Adam Connelly [EMAIL 
PROTECTED]
Sent: Thursday, July 17, 2008 6:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix and MSBuild

I actually sorted the problem (a typo :().  I would still be interested to find 
out how others structure their projects.

Adam

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Connelly
Sent: 17 July 2008 11:19
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix and MSBuild

Hi,

I currently trying to add a task into my MSBuild file that will create the 
various MSI files needed for the project.  I've got the following file 
structure:

Root/
  Build.xml
  Code/
Deploy/
  ProjA
  ProjB
  Installs/
ProjA.wxs

Sorry if that's not amazingly clear.  Basically, all the assemblies, etc for 
each project are in Code/Deploy/ProjX, and the wix file is in 
Installs/ProjX.wxs.  I want to be able to build an installer while keeping this 
structure if possible.

The problem I'm having is that although candle.exe runs fine, light.exe can't 
seem to find the source files no-matter if I set the -b switch, or if I alter 
the Source attributes in the wxs file.

I guess what I really want to know is how do other people structure their 
builds when there may be multiple projects needing installers built, etc.

Sorry for such a broad question.

Cheers,
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] Where does FilesInUse dialog get its names from?

[Neil Enns]

I don't quite understand your comment about FilesInUse vs MsiRmFilesInUse. If 
they're different code paths maybe I'll actually get the text with the Rm 
version?

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Bob Arnson [EMAIL 
PROTECTED]
Sent: Wednesday, July 16, 2008 8:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?

Neil Enns wrote:
> Still no love through the verbose log. I'm going to try making our app 
> restart manager aware (which we should be anyway) to see if that helps.
>

I believe they're different code paths, unfortunately, so it won't help
with FilesInUse -v- MsiRmFilesInUse.

> Speaking of which, is there a property that gets set during install if the 
> app was auto-shutdown?
>

The only one I know of is ReplacedInUseFiles, which isn't Restart
Manager-savvy.

--
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] Version 3.0.4309.0 localization error & WixLib/dll with imbedded files

[Neil Enns]

Murray gave me some logs and a sample project offline, and there is indeed a 
bug in the new localization work I checked in last week. If anyone else hits 
this let me know and I can give you a workaround.

Thanks,

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murray Hipper
Sent: Wednesday, July 16, 2008 10:10 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Version 3.0.4309.0 localization error & WixLib/dll with 
imbedded files

Hi All,

I've come across a problem in a recent upgrade of Wix where I went to
3.0.4311.0 and found I couldn't compile anymore.  I tracked it down
between the two weekly releases 3.0.4227.0 it does work and 3.0.4309.0
is the first weekly release where it fails.
The problem I am having is with localization and my custom dialogs. The
compile error is basically a generic 'Error 1   The localization
variable !(loc.SetupDlgBannerBitmap) is unknown.  Please ensure the
variable is defined.
D:\Snowden\D\Reconcilor_Core\Trunk\Test\Setup\WixUIReconcilor\GeneralSet
up.wxs  14  1   Setup.Product' for each localization that 
have specified. I thought maybe something had changed in the
localization file so I got the latest source from the new version and
compiled it like I used to which worked in previous versions and I get
the same error for every localization that the UIExtension has. I
noticed that the 'Leave blank to build all cultures.' Line in visual
studio was also added at the same time so I thought maybe it was to do
with my cultured. I tried everything from multiple cultures to no
cultures and it's the same deal. If I define something in the original
UiExtensions.Dll like !(loc.WixUIBack) it won't throw the error, but if
I make my own !(loc.test) and have the localization file:

http://schemas.microsoft.com/wix/2006/localization";>
  Test!


I will throw the error message above.

Question 1) Does anyone know of any work around to this, or what I can
do to make it work? If not I'll just go back to using version 3.0.4227.0


I want to make an dll extension which is based on a .wixlib file, in the
same way in which UIExtension has the wixlib which is wix library file
and the wixext which is the C# dll. Looking at the dll I see only 3
files which no way in which it links with the wixlib so I am really lost
in how to bind it into the dll exactly like the 'WixUIExtension.dll'
that comes with WiX.
Question 2) Any tips on how to do this? :P I have found tutorials on
making a extension, and a precompilerextension, but doesn't reach the
level I need.

My last question revolves my build scenario in which we have many tiers
of inheritance. A lower hierarchy needs to be inherited and small
customizations build on top of it. We have the this all working in our
.net program so with wix I was hoping to produce a .wixlib at each level
and slowly include things like files, features and custom actions but be
able to build on existing fragments. The problem occurs with the files
as it compiles fine into the wixlib in the first tier, but moving onto
the second it is still expecting to find the source files at the
original location. I believed the fix for this would be to use the 'Bind
files into wixlibrary' feature, but from what i can tell the visual
studio flag isn't working.

Question 3) I guess I'm asking when do you think the visual studio flag
for binding files will work and is there a work around in the mean time
where I can still use visual studio, or do I have to use the command
line to use this. Also if you can think of a better way to do the tiers
than using wixlib and building on them then please offer your
suggestions.

Currently I'm carting around the project files with the path to the
files as a variable which I redefine at different levels, but this is
less than ideal and Merge modules won't work (from what I can tell)
because I need to build on the existing wix code.

Apologies for the tacky email, it's 1am in aus and I need to get up for
work tomorrow,
Thanks,
Murray

This e-mail and any attachments to it (the "Communication") are confidential 
and are for the use only of the intended recipient. The Communication may 
contain copyright material of the Snowden Group ("Snowden"), or any of its 
related entities or of third parties. If you are not the intended recipient of 
the Communication, please notify the sender immediately by return e-mail, 
delete the Communication, and do not copy, print, retransmit, disclose, store 
or act in reliance on the Communication. Any views expressed in the 
Communication are those of the individual sender only, unless expressly stated 
to be those of Snowden. Although virus protection devices and procedures are in 
place, Snowden does not guarantee the integrity of the Communication, or that 
it is free from errors, viruses or interference. Snowden advises email 
recipients to carry out their own virus checks before opening any attachment.  
Please note that the main telephone n

Re: [WiX-users] Where does FilesInUse dialog get its names from?

[Neil Enns]

Still no love through the verbose log. I'm going to try making our app restart 
manager aware (which we should be anyway) to see if that helps.

Speaking of which, is there a property that gets set during install if the app 
was auto-shutdown?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 16, 2008 7:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?

Neil Enns wrote:
> Well, unfortunately, that's not what's happening. It's detecting that we're 
> running, and if we say "next" on the dialog our application shuts down 
> properly. But the list box is empty.
>
> How can we go about debugging why?
>

Verbose log (always). There is some logging and a bit of redundant
logging on Vista/Srv2008 from Restart Manager.

--
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] Version 3.0.4309.0 localization error & WixLib/dll with imbedded files

[Neil Enns]

Murray,

I checked in changes between the builds you mention that change how localized 
installers are built, to support multiple .wxl files in a project.

To figure out what's going on I'll need to see the verbose build log. From a 
command line type "msbuild /v:d yourproject.wixproj > foo.txt" then e-mail me 
the log so I can take a peek at what's happening.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Murray Hipper
Sent: Wednesday, July 16, 2008 10:10 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Version 3.0.4309.0 localization error & WixLib/dll with 
imbedded files

Hi All,

I've come across a problem in a recent upgrade of Wix where I went to
3.0.4311.0 and found I couldn't compile anymore.  I tracked it down
between the two weekly releases 3.0.4227.0 it does work and 3.0.4309.0
is the first weekly release where it fails.
The problem I am having is with localization and my custom dialogs. The
compile error is basically a generic 'Error 1   The localization
variable !(loc.SetupDlgBannerBitmap) is unknown.  Please ensure the
variable is defined.
D:\Snowden\D\Reconcilor_Core\Trunk\Test\Setup\WixUIReconcilor\GeneralSet
up.wxs  14  1   Setup.Product' for each localization that 
have specified. I thought maybe something had changed in the
localization file so I got the latest source from the new version and
compiled it like I used to which worked in previous versions and I get
the same error for every localization that the UIExtension has. I
noticed that the 'Leave blank to build all cultures.' Line in visual
studio was also added at the same time so I thought maybe it was to do
with my cultured. I tried everything from multiple cultures to no
cultures and it's the same deal. If I define something in the original
UiExtensions.Dll like !(loc.WixUIBack) it won't throw the error, but if
I make my own !(loc.test) and have the localization file:

http://schemas.microsoft.com/wix/2006/localization";>
  Test!


I will throw the error message above.

Question 1) Does anyone know of any work around to this, or what I can
do to make it work? If not I'll just go back to using version 3.0.4227.0


I want to make an dll extension which is based on a .wixlib file, in the
same way in which UIExtension has the wixlib which is wix library file
and the wixext which is the C# dll. Looking at the dll I see only 3
files which no way in which it links with the wixlib so I am really lost
in how to bind it into the dll exactly like the 'WixUIExtension.dll'
that comes with WiX.
Question 2) Any tips on how to do this? :P I have found tutorials on
making a extension, and a precompilerextension, but doesn't reach the
level I need.

My last question revolves my build scenario in which we have many tiers
of inheritance. A lower hierarchy needs to be inherited and small
customizations build on top of it. We have the this all working in our
.net program so with wix I was hoping to produce a .wixlib at each level
and slowly include things like files, features and custom actions but be
able to build on existing fragments. The problem occurs with the files
as it compiles fine into the wixlib in the first tier, but moving onto
the second it is still expecting to find the source files at the
original location. I believed the fix for this would be to use the 'Bind
files into wixlibrary' feature, but from what i can tell the visual
studio flag isn't working.

Question 3) I guess I'm asking when do you think the visual studio flag
for binding files will work and is there a work around in the mean time
where I can still use visual studio, or do I have to use the command
line to use this. Also if you can think of a better way to do the tiers
than using wixlib and building on them then please offer your
suggestions.

Currently I'm carting around the project files with the path to the
files as a variable which I redefine at different levels, but this is
less than ideal and Merge modules won't work (from what I can tell)
because I need to build on the existing wix code.

Apologies for the tacky email, it's 1am in aus and I need to get up for
work tomorrow,
Thanks,
Murray

This e-mail and any attachments to it (the "Communication") are confidential 
and are for the use only of the intended recipient. The Communication may 
contain copyright material of the Snowden Group ("Snowden"), or any of its 
related entities or of third parties. If you are not the intended recipient of 
the Communication, please notify the sender immediately by return e-mail, 
delete the Communication, and do not copy, print, retransmit, disclose, store 
or act in reliance on the Communication. Any views expressed in the 
Communication are those of the individual sender only, unless expressly stated 
to be those of Snowden. Although virus protection devices and procedures are in 
place, Snowden does not guarantee the integrity of the Communication, or that 
it is free from errors, viruses or interf

Re: [WiX-users] Merge module question

[Neil Enns]

You can think of merge modules (MSMs) like an application DLL: it's a package 
of install instructions that can be included in a parent installer. You still 
need some sort of tool to author the MSM, something that explains what files to 
include, where they should go, and what the order of installation should be. 
WiX is one of several available tools that helps with that authoring.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Anidil [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 2:32 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Merge module question


Can't we author all the setup components inside an msm?Do we really need wix
then?What all are the advantages of going for wix instead of deploying an
application using merge modules?
--
View this message in context: 
http://www.nabble.com/Merge-module-question-tp18483804p18483804.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] Where does FilesInUse dialog get its names from?

[Neil Enns]

Well, unfortunately, that's not what's happening. It's detecting that we're 
running, and if we say "next" on the dialog our application shuts down 
properly. But the list box is empty.

How can we go about debugging why?

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Bob Arnson [EMAIL 
PROTECTED]
Sent: Tuesday, July 15, 2008 6:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where does FilesInUse dialog get its names from?

Neil Enns wrote:
> It appears that our installer is magically detecting whether our application 
> is running at the time of an install, and even correctly closes it. However, 
> the FilesInUse dialog that comes with WiXUI isn't showing anything in the 
> listbox of running processes. What magic do we need to do to populate the 
> listbox with the name of our application?
>

MSI should be showing only apps with visible, top-level windows; the
content of the list box item is the window title. So it should be
automatic "free." If MSI doesn't find the right kind of windows or
titles, it should skip them and, if none, not show FilesInUse at all
(just reboot).

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

[WiX-users] Where does FilesInUse dialog get its names from?

[Neil Enns]

It appears that our installer is magically detecting whether our application is 
running at the time of an install, and even correctly closes it. However, the 
FilesInUse dialog that comes with WiXUI isn't showing anything in the listbox 
of running processes. What magic do we need to do to populate the listbox with 
the name of our application?

Thanks,

Neil
-
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] Questions about WiX V3

[Neil Enns]

For #2 you also have to add a reference to WiXUiExtension.dll. Since you are 
using Visual Studio integration right click on the References node in Solution 
Explorer and select Add Reference. Then find WixUiExtension.dll in the list and 
click add. Close the dialog and build and things should work.

Additional information on using WiXUi is available in the help file that ships 
with WiX. Look under Advanced WiX Topics > WiXUI Dialog Library.

WixWiki also has some good information at 
http://www.wixwiki.com/index.php?title=UiExtension.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Minnis
Sent: Sunday, July 13, 2008 3:06 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Questions about WiX V3

I installed the latest beta of WiX 3 because I want to use the Visual Studio
integration.  I've run into some problems getting started.  I'm hoping that
I can get some assistance.

1) The text of error messages are not being displayed in VS 2005.  When the
build fails, I have to build from a command line to actually read the build
error.  This is a known bug that I read about in other messages in the list
archive, but it is extremely frustrating for someone trying to get started
with WiX.

2) I'd like to have a UI in my installer.  To get started, I was going to
use the WixUI.  Following the samples for WiX 2, I included the following:



Light outputs:

Product.wxs(45) : error LGHT0094 : Unresolved reference to symbol
'WixUI:WixUI_InstallDir' in section
'Product:{6D829382-8D41-43C9-AC80-7B98DA1BBD72}'.

How do I reference WixUI?  Or has it been removed?

I suppose I could build my own dialogs in an RC file and then use Tallow to
create WiX dialogs.  Which brings me to #3.

3) Is Tallow still a part of WiX 3?  The executable is not anywhere in the
installation.  Are its features now included somewhere else?

-Jamey


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


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

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

[Neil Enns]

Thanks for the suggestion, Amir. I'll tweak it next time I'm mucking with the 
help file.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Amir Kolsky [EMAIL 
PROTECTED]
Sent: Saturday, July 12, 2008 4:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Another newbie question: condition on custom action

That would be a good thing to write in the chm

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: Saturday, July 12, 2008 2:12 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Another newbie question: condition on custom
action

Yes.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Amir
Kolsky
Sent: Saturday, July 12, 2008 13:33
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Another newbie question: condition on custom
action

This means "the condition that determines if the action will be taken,
calculated just prior to taking the action?"

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: Saturday, July 12, 2008 9:12 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Another newbie question: condition on custom
action

Uhh, yeah.  You asked how to "condition a custom action" and that says
"specifies the condition of the action".  Am I missing something?  Is
there some way we could make the documentation clearer?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Amir
Kolsky
Sent: Friday, July 11, 2008 17:27
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Another newbie question: condition on custom
action

Are you referring to this?

*Inner Text (xs:string)*
Text node specifies the condition of the action.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: Friday, July 11, 2008 5:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Another newbie question: condition on custom
action

See the text of the Custom element in the WiX.chm.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Amir
Kolsky
Sent: Friday, July 11, 2008 15:03
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Another newbie question: condition on custom action

Hi All!



How do I  a custom action (basically for NOT installed)?

I tried to put it in a fragment but then it stops the uninstall dead.

The level=0 is only accepted inside Features, but this is and install
sequence thing...



This must be trivial, what am I missing?



Thanks, Amir




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



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

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__


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



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

Re: [WiX-users] Wix Extension Problem

[Neil Enns]

For what it's worth I got going simply by duplicating what the WixUtilExtension 
does. Similar to your SqlExtension approach I think. I trimmed it down to just 
implementing a stub compiler object and extension object.

My biggest problem was figuring out the appropriate string to pass in to load 
the .xsd and .wixlib.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Karper
Sent: Friday, July 11, 2008 10:22 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix Extension Problem

That would be excellent.   I can't really wait, but I fear I will not make
substantial progress today, so it would probably be wonderful to have this
anyway.   :-)

Chris

On Fri, Jul 11, 2008 at 1:17 PM, Neil Enns <[EMAIL PROTECTED]> wrote:

> Christopher,
>
> Last night in my aborted attempt to automate including files in my
> installer, I got a basic extension up and running and working. If you can
> wait, I can zip it up and send it to you tonight as a starting point.
>
> Neil
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Brian Rogers
> Sent: Friday, July 11, 2008 10:15 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Wix Extension Problem
>
> Do you have a compiler class specified? It is going to be a bit difficult
> to
> troubleshoot this without some additional information. Have you also
> specified an XSD? Are you adding the project to the CVS checkout or are you
> building as a stand-alone?
> --
> Brian Rogers
> "Intelligence removes complexity." - Me
> http://www.codeplex.com/wixml/
>
> On Fri, Jul 11, 2008 at 10:09 AM, Christopher Karper <
> [EMAIL PROTECTED]> wrote:
>
> > OK, I'm trying to build a Wix extension to handle some tasks for me.
> > First
> > I tried basing mine off of the code in SqlExtension from the Wix source,
> > but
> > that did not work at all.
> >
> > Then I tried the dumbest simple sample:
> >
> >
> http://blogs.msdn.com/pmarcu/archive/2007/11/02/wix-writing-your-own-wix-extension-part-1.aspx
> >
> > As detailed in that blog post.  An extension that does nothing but load.
> > And that doesn't work.
> > Something is wrong somewhere, and I'm beginning to think it's not me.
> Can
> > someone clue me in to what I'm missing, or which piece is broken?
> >
> >
> > I can build the extension with no issues, but:
> >
> >
> > D:\src\SampleWixExtension\SampleWixExtension\bin\Debug>candle Test.wxs
> -ext
> > SampleWixExtension.dll
> > Microsoft (R) Windows Installer Xml Compiler version 3.0.4207.0
> > Copyright (C) Microsoft Corporation. All rights reserved.
> >
> > candle.exe : error CNDL0144 : The extension 'SampleWixExtension.dll'
> could
> > not be loaded.
> >
> >
> > Every time, I get this error, no matter what changes I make...
> >
> >
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


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

Re: [WiX-users] Wix Extension Problem

[Neil Enns]

Christopher,

Last night in my aborted attempt to automate including files in my installer, I 
got a basic extension up and running and working. If you can wait, I can zip it 
up and send it to you tonight as a starting point.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Rogers
Sent: Friday, July 11, 2008 10:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix Extension Problem

Do you have a compiler class specified? It is going to be a bit difficult to
troubleshoot this without some additional information. Have you also
specified an XSD? Are you adding the project to the CVS checkout or are you
building as a stand-alone?
--
Brian Rogers
"Intelligence removes complexity." - Me
http://www.codeplex.com/wixml/

On Fri, Jul 11, 2008 at 10:09 AM, Christopher Karper <
[EMAIL PROTECTED]> wrote:

> OK, I'm trying to build a Wix extension to handle some tasks for me.
> First
> I tried basing mine off of the code in SqlExtension from the Wix source,
> but
> that did not work at all.
>
> Then I tried the dumbest simple sample:
>
> http://blogs.msdn.com/pmarcu/archive/2007/11/02/wix-writing-your-own-wix-extension-part-1.aspx
>
> As detailed in that blog post.  An extension that does nothing but load.
> And that doesn't work.
> Something is wrong somewhere, and I'm beginning to think it's not me.   Can
> someone clue me in to what I'm missing, or which piece is broken?
>
>
> I can build the extension with no issues, but:
>
>
> D:\src\SampleWixExtension\SampleWixExtension\bin\Debug>candle Test.wxs -ext
> SampleWixExtension.dll
> Microsoft (R) Windows Installer Xml Compiler version 3.0.4207.0
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> candle.exe : error CNDL0144 : The extension 'SampleWixExtension.dll' could
> not be loaded.
>
>
> Every time, I get this error, no matter what changes I make...
>
>
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


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

Re: [WiX-users] Why do binder variables require GAC installation?

[Neil Enns]

Thanks!

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Painter
Sent: Friday, July 11, 2008 9:44 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Why do binder variables require GAC installation?

http://blogs.msdn.com/heaths/archive/2008/02/08/get-binder-variables-for-assemblies-without-installing-into-the-gac.aspx

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


--- On Fri, 7/11/08, Neil Enns <[EMAIL PROTECTED]> wrote:

> From: Neil Enns <[EMAIL PROTECTED]>
> Subject: [WiX-users] Why do binder variables require GAC installation?
> To: "General discussion for Windows Installer XML toolset." 
> 
> Date: Friday, July 11, 2008, 11:41 AM
> I'm messing around with trying to get my installer's
> ProductVersion to be based off our main application's
> assemblyVersion. I thought this would be as simple as
> putting !(bind.assemblyVersion.MyApplicationId) in the
> right places, but this doesn't work unless I put
> Assembly=".net" on my main application's file
> element.
>
> I don't want to install my app into the GAC. Is there
> another way to make this work?
>
> Neil
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE
> NOW!
> Studies have shown that voting for your favorite open
> source project,
> along with a healthy diet, reduces your potential for
> chronic lameness
> and boredom. Vote Now at
> http://www.sourceforge.net/community/cca08
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users




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


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

[WiX-users] Why do binder variables require GAC installation?

[Neil Enns]

I'm messing around with trying to get my installer's ProductVersion to be based 
off our main application's assemblyVersion. I thought this would be as simple 
as putting !(bind.assemblyVersion.MyApplicationId) in the right places, but 
this doesn't work unless I put Assembly=".net" on my main application's file 
element.

I don't want to install my app into the GAC. Is there another way to make this 
work?

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

Re: [WiX-users] Automating the inclusion of a mess of files

[Neil Enns]

Thanks Rob. I'm currently exploring another approach, although if I wind up 
going the HeatTask route I'll keep all the below in mind.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching
Sent: Friday, July 11, 2008 9:01 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automating the inclusion of a mess of files

Answering the questions backwards:

1.  The rules are called the "Component Rules".  They are documented in the MSI 
SDK and I added a bunch of color commentary here: 
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx

2.  It appears that HeatTask does have the support the heat auto-generate-guid 
switch.

3.  First, understand what you are up against.  If you don't understand the 
rules you stand a good chance of breaking them.  Basically, it comes down to no 
Component may ever overlap with the contents of another Component.  After that, 
if the auto-generated-guid (Component/@Guid="*") works for you then that is a 
nice way out.  There are limitations in its use but they tend to push you 
towards Components that have higher chance of being patched/updated/upgraded 
anyway.  Also, if you can simplify your application to be completely isolated, 
things get a lot easier as well.

Note: the auto-generate-guid on Components is still a bit experimental.  I'm 
using it on a couple of my smaller projects at work and things seem to be okay. 
 However, if you find a bug in it (i.e. two Components get the same Id or the 
same Component Id changes) then to let us know.  The other nasty part about the 
auto-generate-guid is that if we find a bug in the algorithm (we've found 3 in 
its lifetime and I'm pretty confident in it now) then you're going to be pretty 
much screwed (cause, in the worse case, all the GUIDs will change)... so 
buyer-beware.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, July 11, 2008 07:13
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automating the inclusion of a mess of files

Rob,

Any pointers on tips for getting the GUIDs right? Will HeatTask take care of 
this for me? If not, what rules do I need to follow?
Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Rob Mensching [EMAIL 
PROTECTED]
Sent: Friday, July 11, 2008 1:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automating the inclusion of a mess of files

There is a "HeatTask" provided by the WiX toolset already.  Getting the GUIDs 
right is the hardest part of "autogenerating" .wxs files.  The Windows 
Installer is brutally unforgiving for messing up your Component/@Guids.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm
Sent: Friday, July 11, 2008 00:30
To: General discussion for Windows Installer XML toolset.; General discussion 
for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automating the inclusion of a mess of files

Neil

Have you considered using a variant of Heat to generate the WiX code 
dynamically? I have done this sort of think in v2 using a tool called mallow 
(it is a variant of tallow) I think you should find it on the web if you search 
but if not let me know and I send you a copy. It can scan a folder full of 
files and generate WiX code and manage the GUIDs for you so it shouldn't break 
the component rules.

I know this sort of thing it considered bad but in the real world we have to 
consider things like this!

Neil

Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>




From: [EMAIL PROTECTED] on behalf of Neil Enns
Sent: Fri 11/07/2008 07:01
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Automating the inclusion of a mess of files



My application will wind up shipping with a ton of loose resource files on 
disk*. We will have several items with the following well-defined structure:

MyFile1.foo
MyFile1_files
   \ 0
  \ somefile.txt
   \ 1
  \ somefile.txt
   ...
   \ 9
  \ somefile.txt

This is how the files live on disk as source, and how we need them to live on 
disk on the target machine. As you can imagine, I have no desire to author the 
WiX to install these suckers by hand, especially since they're going to change 
relatively often between now and when we ship. I want to automate the process 
somehow.

I started tonight by thinking a custom extension would do. My plan was to 
create a new  element that took the root .foo file, then would 
automatically add all the necessary entries into the MSI for all the files and 
subdirectories. I got a custom extension up and running pretty quickly, but 
when it came time to actually think about add

Re: [WiX-users] Automating the inclusion of a mess of files

[Neil Enns]

Rob,

Any pointers on tips for getting the GUIDs right? Will HeatTask take care of 
this for me? If not, what rules do I need to follow?
Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Rob Mensching [EMAIL 
PROTECTED]
Sent: Friday, July 11, 2008 1:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automating the inclusion of a mess of files

There is a "HeatTask" provided by the WiX toolset already.  Getting the GUIDs 
right is the hardest part of "autogenerating" .wxs files.  The Windows 
Installer is brutally unforgiving for messing up your Component/@Guids.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Sleightholm
Sent: Friday, July 11, 2008 00:30
To: General discussion for Windows Installer XML toolset.; General discussion 
for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automating the inclusion of a mess of files

Neil

Have you considered using a variant of Heat to generate the WiX code 
dynamically? I have done this sort of think in v2 using a tool called mallow 
(it is a variant of tallow) I think you should find it on the web if you search 
but if not let me know and I send you a copy. It can scan a folder full of 
files and generate WiX code and manage the GUIDs for you so it shouldn't break 
the component rules.

I know this sort of thing it considered bad but in the real world we have to 
consider things like this!

Neil

Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>




From: [EMAIL PROTECTED] on behalf of Neil Enns
Sent: Fri 11/07/2008 07:01
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Automating the inclusion of a mess of files



My application will wind up shipping with a ton of loose resource files on 
disk*. We will have several items with the following well-defined structure:

MyFile1.foo
MyFile1_files
   \ 0
  \ somefile.txt
   \ 1
  \ somefile.txt
   ...
   \ 9
  \ somefile.txt

This is how the files live on disk as source, and how we need them to live on 
disk on the target machine. As you can imagine, I have no desire to author the 
WiX to install these suckers by hand, especially since they're going to change 
relatively often between now and when we ship. I want to automate the process 
somehow.

I started tonight by thinking a custom extension would do. My plan was to 
create a new  element that took the root .foo file, then would 
automatically add all the necessary entries into the MSI for all the files and 
subdirectories. I got a custom extension up and running pretty quickly, but 
when it came time to actually think about adding the things to the MSI this 
approach seemed, well, insane. I have no desire to recreate what the , 
, and  elements do in code.

My new alternate approach is to do this via a custom MSBuild task that runs 
before Candle and generates a WiX file that then gets added to the list of 
things to compile.

Anyone have any other suggestions for good ways to automate this?

Thanks,

Neil

* Don't ask why we have this structure and why they are loose files. It's a 
very long story best told over a frosty beverage.
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


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


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

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have s

Re: [WiX-users] Automating the inclusion of a mess of files

[Neil Enns]

Thanks for all the suggestions everyone, lots for me to go and look at.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Jason Swager [EMAIL 
PROTECTED]
Sent: Friday, July 11, 2008 6:05 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Automating the inclusion of a mess of files

You may want to look at Paraffin 
(http://www.wintellect.com/CS/blogs/jrobbins/archive/2007/10/21/wix-a-better-tallow-paraffin.aspx).
  This tool was designed for WiX 2.0, so you have to WiXCop the resulting file 
if you use WiX 3.0.  Paraffin handles much of the GUID generation and updating 
for you.  For maintaining large directories of non-binary files where additions 
and removals are common, this tool works very well for me.  I just wish it 
generated WiX 3.0 code

Jason Swager


- Original Message 
From: Neil Enns <[EMAIL PROTECTED]>
To: General discussion for Windows Installer XML toolset. 

Sent: Thursday, July 10, 2008 11:01:30 PM
Subject: [WiX-users] Automating the inclusion of a mess of files

My application will wind up shipping with a ton of loose resource files on 
disk*. We will have several items with the following well-defined structure:

MyFile1.foo
MyFile1_files
   \ 0
  \ somefile.txt
   \ 1
  \ somefile.txt
   ...
   \ 9
  \ somefile.txt

This is how the files live on disk as source, and how we need them to live on 
disk on the target machine. As you can imagine, I have no desire to author the 
WiX to install these suckers by hand, especially since they're going to change 
relatively often between now and when we ship. I want to automate the process 
somehow.

I started tonight by thinking a custom extension would do. My plan was to 
create a new  element that took the root .foo file, then would 
automatically add all the necessary entries into the MSI for all the files and 
subdirectories. I got a custom extension up and running pretty quickly, but 
when it came time to actually think about adding the things to the MSI this 
approach seemed, well, insane. I have no desire to recreate what the , 
, and  elements do in code.

My new alternate approach is to do this via a custom MSBuild task that runs 
before Candle and generates a WiX file that then gets added to the list of 
things to compile.

Anyone have any other suggestions for good ways to automate this?

Thanks,

Neil

* Don't ask why we have this structure and why they are loose files. It's a 
very long story best told over a frosty beverage.
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[WiX-users] Automating the inclusion of a mess of files

[Neil Enns]

My application will wind up shipping with a ton of loose resource files on 
disk*. We will have several items with the following well-defined structure:

MyFile1.foo
MyFile1_files
   \ 0
  \ somefile.txt
   \ 1
  \ somefile.txt
   ...
   \ 9
  \ somefile.txt

This is how the files live on disk as source, and how we need them to live on 
disk on the target machine. As you can imagine, I have no desire to author the 
WiX to install these suckers by hand, especially since they're going to change 
relatively often between now and when we ship. I want to automate the process 
somehow.

I started tonight by thinking a custom extension would do. My plan was to 
create a new  element that took the root .foo file, then would 
automatically add all the necessary entries into the MSI for all the files and 
subdirectories. I got a custom extension up and running pretty quickly, but 
when it came time to actually think about adding the things to the MSI this 
approach seemed, well, insane. I have no desire to recreate what the , 
, and  elements do in code.

My new alternate approach is to do this via a custom MSBuild task that runs 
before Candle and generates a WiX file that then gets added to the list of 
things to compile.

Anyone have any other suggestions for good ways to automate this?

Thanks,

Neil

* Don't ask why we have this structure and why they are loose files. It's a 
very long story best told over a frosty beverage.
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[Neil Enns]

I had the same thought yesterday and took a peek at the code to see how easy it 
would be to do, and it looked like something ranging between "pretty hard" and 
"nearly impossible" :(

Can you add this as a feature request on Source Forge? 
http://sourceforge.net/tracker/?group_id=105970&atid=642717

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of John Nannenga [EMAIL 
PROTECTED]
Sent: Thursday, July 10, 2008 7:36 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Suppress light.exe & ICE warnings

Any chance of this making it as a feature for WiX?  I liken it to FxCop 
warnings where devs can choose to ignore specific instances of warnings / mark 
them as OK.  I think this'd be rather useful to folks...



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Thursday, July 10, 2008 9:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Suppress light.exe & ICE warnings

John,

I don't think anyone got back to you on this yesterday. Unfortunately there's 
no way to suppress the warnings at the merge module level. It's all or nothing 
at the project level.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of John Nannenga [EMAIL 
PROTECTED]
Sent: Wednesday, July 09, 2008 10:53 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Suppress light.exe & ICE warnings

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

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

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


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

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


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

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

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

[Neil Enns]

John,

I don't think anyone got back to you on this yesterday. Unfortunately there's 
no way to suppress the warnings at the merge module level. It's all or nothing 
at the project level.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of John Nannenga [EMAIL 
PROTECTED]
Sent: Wednesday, July 09, 2008 10:53 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Suppress light.exe & ICE warnings

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

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

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


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

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

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

[Neil Enns]

What errors are you getting?

Neil

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

Hi,

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

Any help/pointers is appreciated.

Thanks
Vidya


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


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

Re: [WiX-users] Integration of WiX v3 on team build server

[Neil Enns]

While we do not use WiX inside TFS, we do use WiX in a daily build process on a 
machine without installing WiX on the build machine.

Instead, we have checked in all the WiX binaries and targets files into the 
tree. Basically, this is the contents of C:\Program Files\Windows Installer XML 
v3\bin and C:\Program Files\MSBuild\Microsoft\WiX\v3.0. These are all stored 
in, say enlistmentroot\tools\WiX in our source code enlistment.

In our WiX project file we have removed the default WixTargetsPath property and 
added the following:





enlistmentroot\tools\wix\

$(WixRoot)wix.targets

$(WixRoot)WixTasks.dll


You need to specify both WixTargetsPath and WixTasksPath for the build to work. 
There should be no need to create any kind of "CoreBuild" anything.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Dmitry Berkovich [EMAIL 
PROTECTED]
Sent: Monday, July 07, 2008 9:18 PM
To: [EMAIL PROTECTED]; General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Integration of WiX v3 on team build server

Hi,
  Thanks for a nice discussion, but last mails are missed a point of
the problem.

I will try explain how MSBuild working:
  If you are will look inside of teambuild.proj you will see at the
begin Microsoft.TeamFoundation.Build.targets/> where this
target file have target with name "CoreBuild" that execute "MSBuild"
task for each solution that declared in teambuild.proj. When "MSBuild"
task execute it very similar to executing to msbuild.exe from cmd
line, so if you are not providing any properties to "MSBuild" task
solution will not receive any new property that dide't created by
default by msbuld. So to put declaration of :
   
   ..\..\WiX\
   
or simillar its not enough.
Default implementation of "CoreBuild" in
Microsoft.TeamFoundation.Build.targets only pass about 5 parameters to
"MSBuild" task, so I did override of this target with my that pass
additional parameters ( I saw in some blogs that this feature will be
added in next version of team build).
The problem here that its not works as expected: I saw in msbuild logs
that I received warning that c:\prgrams
files\msbuld\Microsoft\WiX\v3.0\Wix.targets> not exists (it happend
because msbuild think  that i didn't provide WixTargetsPath property)
but at next line it start compile again my solution where my property
was passed to msbuild.
So at the end of MSBuild i receive error that build failed with 0
errors & 0 warning.


My question is:
 Did anybody use team build without installing WiX on build machine?

Thanks

Dima



On Tue, Jul 8, 2008 at 12:46 AM, Christopher Painter
<[EMAIL PROTECTED]> wrote:
> TFS enforces a mutex of 1 running build per build server per project.  
> Otherwise it's possible to get multiple builds going at once on a single 
> build server if they build out of seperate TFS projects.
>
> InstallShield craps out when attempting to do this and I've repeatedly tried 
> to get them to fix it.
>
> As an aside, one company that I used to work for did about 50,000 builds per 
> year.  The product line is broken down into chunks of assets and a series of 
> sometimes dozens of builds is needed to compose a product.   Using BuildForge 
> and ESX, they use a farm of virtual machines with the ability to create 
> complex chains of builds that get randomly assigned to build machines that 
> match the configuration requirements of a given build. Concurrent builds are 
> needed to keep up the tempo.
>
>
> Christopher Painter, Author of Deployment Engineering Blog
> Have a hot tip, know a secret or read a really good thread that deserves 
> attention? E-Mail Me
>
>
> --- On Mon, 7/7/08, Christopher Karper <[EMAIL PROTECTED]> wrote:
>
>> From: Christopher Karper <[EMAIL PROTECTED]>
>> Subject: Re: [WiX-users] Integration of WiX v3 on team build server
>> To: "General discussion for Windows Installer XML toolset." 
>> 
>> Date: Monday, July 7, 2008, 4:41 PM
>> Can TFS do concurrent builds?   If more than one build
>> kicked off at the
>> same time, that could be pretty bad.
>>
>> Chris
>>
>> On Mon, Jul 7, 2008 at 5:35 PM, Neil Sleightholm
>> <[EMAIL PROTECTED]> wrote:
>>
>> > Just a thought but why not put the WiX MSI in TFS and
>> then do a silent
>> > install of WiX at the start of the build. Then you get
>> the best of both
>> > worlds, a standard WiX install and WiX being
>> automatically updated on
>> > all build machines. Also, if the WiX tool set gets
>> some new tools or
>> > config you don't need to figure out how they need
>> to be installed.
>> >
>> > Neil
>> >
>> > -Original Message-
>> > From: [EMAIL PROTECTED]
>> > [mailto:[EMAIL PROTECTED] On
>> Behalf Of John
>> > Nannenga
>> > Sent: 07 July 2008 21:33
>> > To: General discussion for Windows Installer XML
>> toolset.
>> > Subject: Re: [WiX-users] Integration of WiX v3 on team
>> build server
>> >
>> > 2 big benefits I can think of:
>> >
>> > 1)  Machine maintenance
>> >If you have 5 build machine

Re: [WiX-users] WIX 3 UI Localisation

[Neil Enns]

See:

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

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of andywhitt
Sent: Wednesday, July 02, 2008 11:39 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WIX 3 UI Localisation


Hi

I've been reading you can override the UI strings with a localisation file.
I was wondering where I could find a list of the variable names?

Thanks
--
View this message in context: 
http://www.nabble.com/WIX-3-UI-Localisation-tp18244032p18244032.html
Sent from the wix-users mailing list archive at Nabble.com.


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


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

Re: [WiX-users] Launch internet Browser

[Neil Enns]

A new How To topic (should be in the next weekly build) covers launching your 
installed application after install. While not exactly what you are trying to 
do it does demonstrate how to use the ShellExec cusotm action. You can modify 
it slightly by changing the WixShellExecTarget element to simply be the URL you 
want to open instead of the installed application. The text of the topic is 
below.

Neil

How To: Run the Installed Application After Setup

Often when completing the installation of an application it is desirable to 
offer the user the option of immediately launching the installed program when 
setup is complete. This how to describes customizing the default WiX UI 
experience to include a checkbox and a WiX custom action to launch the 
application if the checkbox is checked.

This how to assumes you have already created a basic WiX project using the 
steps outlined in How To: Add a file to your installer.

Step 1: Add the extension libraries to your project

This walkthrough requires WiX extensions for UI components and custom actions. 
These extension libraries must must be added to your project prior to use. If 
you are using WiX on the command-line you need to add the following to your 
candle and light command lines:
-ext WixUIExtension -ext WixUtilExtension

If you are using Votive you can add the extensions using the Add Reference 
dialog:

Right click on your project in Solution Explorer and select Add Reference...
Select the WixUIExtension.dll assembly from the list and click Add
Select the WixUtilExtension.dll assembly from the list and click Add
Close the Add Reference dialog

Step 2: Add UI to your installer

The WiX Minimal UI sequence includes a basic set of dialogs that includes a 
finished dialog with optional checkbox. To include the sequence in your project 
add the following snippet anywhere inside the  element.





To display the checkbox on the last screen of the installer include the 
following snippet anywhere inside the  element:



The WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT property is provided by the standard 
UI sequence that, when set, displays the checkbox and uses the specified value 
as the checkbox label.

Step 3: Include the custom action

Custom actions are included in a WiX project using the  element. 
Running an application is accomplished with the WixShellExecTarget custom 
action. To tell Windows Installer about the custom action, and to set its 
properties, include the following in your project anywhere inside the  
element:




The Property element sets the WixShellExecTarget to the location of the 
installed application. WixShellExecTarget is the property Id the WixShellExec 
custom action expects will be set to the location of the file to run. The Value 
property uses the special # character to tell WiX to look up the full installed 
path of the keyfile for the component with the id myapplication.exe.

The CustomAction element includes the action in the installer. It is given a 
unique Id, and the BinaryKey and DllEntry properties indicate the assembly and 
entry point for the custom action. The Impersonate property tells Windows 
Installer to run the custom action as the installing user.

Step 4: Trigger the custom action

Simply including the custom action, as in Step 3, isn't sufficient to cause it 
to run. Windows Installer must also be told when the custom action should be 
triggered. This is done by using the  element to add it to the actions 
run when the user clicks the Finished button on the final page of the UI 
dialogs. The Publish element should be included inside the  element from 
Step 2, and looks like this:

WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and NOT 
Installed

The Dialog property specifies the dialog the Custom Action will be attached to, 
in this case the ExitDialog. The Control property specifies that the Finish 
button on the dialog triggers the custom action. The Event property indicates 
that a custom action should be run when the button is clicked, and the Value 
property specifies the custom action that was included in Step 3. The condition 
on the element prevents the action from running unless the checkbox from Step 2 
was checked and the application was actually installed (as opposed to being 
removed or repaired).

The Complete Sample



























WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and 
NOT Installed










From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Bob Arnson [EMAIL 
PROTECTED]
Sent: Tuesday, July 01, 2008 3:30 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Launch internet Browser

Ryan O'Neill wrote:
> That launches IE (a specific requirement of this installer, not just any web
> 

Re: [WiX-users] How to popup a warning mesagebox if there is old version already installed?

[Neil Enns]

Rather than prompt the user to do the uninstall, have you considered having MSI 
take care of it for you? How to make that work is reasonably well documented at 
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx.
 Note that this requires you increment one of the first three pieces of the 
product version, not the last piece, for detection to work properly (i.e. you 
have to roll from 1.2.10.1 to 1.2.11.0).

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Lio [EMAIL PROTECTED]
Sent: Tuesday, July 01, 2008 8:09 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to popup a warning mesagebox if there is old version 
already installed?

Hello Everyone,

I have a question on how to popup a warning mesagebox if there is old
version already installed.
I will appreciate any help.

Backround:
e.g, I have installed a product with version 1.2.10.1.
Now I have a installation with a higher version 1.2.10.2

When I double the product.msi, the maintaince page is shown up and ask me to
repair, modify or remove the product.
However, I don't want this page shown up but only a message box pop up and
give a warning message "An old version of this product is already installed.
Please use the Add/Remove to remove the product first and then install it
again." Then the installation wizard exists.


Could you please give me a hand?

Thanks in advance!


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

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

Re: [WiX-users] [ProductName] not replaced in Shortcut Name

[Neil Enns]

Andreas,

Another option is to make ProductName a localization string in your wxl file. 
Then use !(loc.ProductName) everywhere, including in the Product element. This 
is what we do and it works like a charm.

Neil


-Original Message-
From: Andreas Hellwig <[EMAIL PROTECTED]>
Sent: Tuesday, July 01, 2008 8:02 AM
To: General discussion for Windows Installer XML toolset. 

Subject: Re: [WiX-users] [ProductName] not replaced in Shortcut Name


Thanks for your answers.
I tried a property too. It didn't work. It wasn't replaced. Maybe that's
because the name field of a shortcut of the type Filename and not
Formatted. Well i guess i'll have to use text without the ProductName.

Andreas Hellwig

Tony Juricic schrieb:
> I had similar things happen to me and solved them by using CA like:
>
> 
>  Value="!(loc.ProgressDlg_Title)" Execute="immediate" />
>
> In this case above dialog title contained [ProductName] which was not
> resolved. Then you schedule CA very early and insert the property name
> where you need resolved string.
>
> The only way I can understand this is that MSI DB fields are not all
> equal. For some resolution works, for others doesn't.
>
> -Original Message-
> From: Andreas Hellwig [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 01, 2008 9:54 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] [ProductName] not replaced in Shortcut Name
>
> Well I used [ProductName] like it is used in the WiXUI localization
> files. Everywhere else it works correct. Just in the shortcut it isn't
> replaced correctly.
>
> in the .wxl file i've got this:
>   Uninstall
> [ProductName]
>   Removes
> [ProductName] from your computer.
>
> and in my .wxs file i've got this:
>Name="!(loc.Test_UninstallLinkTitle) "
>   Target="[System32Folder]msiexec.exe"
>   Arguments="/x {$(var.TEST_PRODUCT_CODE)}"
>   Directory="Test_startmenu_subfolder"
>   Description="!(loc.Test_UninstallLinkDescription)" />
>
> any idea why the [ProductName] isn't replaced for the shortcut?
>
> Andreas Hellwig
>
>
>
> Rob Hamflett schrieb:
>
>> [ProductName] indicates that ProductName is a property.  Are you sure
>>
> you don't want $(loc.ProductName)?
>
>> Rob
>>
>> Andreas Hellwig wrote:
>>
>>
>>> Hi,
>>>
>>> I'm trying to create a shortcut with a localized name, but sadly
>>> '[ProductName]' isn't replaced in the localization-string (same for
>>>
> the
>
>>> description). Is there a method to get it working correctly?
>>>
>>> Andreas Hellwig
>>>
>>>
>>>
> 
> -
>
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>>
>>>
>>
>>
> 
> -
>
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>
>
>
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>


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


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

Re: [WiX-users] Setting Support Information in "Add or Remove Programs"

[Neil Enns]

And the list of properties is at 
http://msdn.microsoft.com/en-us/library/aa370905(VS.85).aspx. They start with 
ARP.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Rob Hamflett [EMAIL 
PROTECTED]
Sent: Monday, June 30, 2008 5:34 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Setting Support Information in "Add or Remove Programs"

You can add a support link by adding the following property:


Rob

[EMAIL PROTECTED] wrote:
> Hello everyone!
> How can I set the support information which can be accessed through the
> "Change or Remove Program"-list? Examples: setting a link to the publisher
> or adding a comment.
> Thank's in advance,
> Chris
>
>
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php


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

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

Re: [WiX-users] LGHT0217 & VSTS

[Neil Enns]

Oh, wait, that's the same blog entries referenced by the FAQ item you said you 
read and followed below :) Never mind me... it's Friday morning.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Friday, June 27, 2008 10:17 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] LGHT0217 & VSTS

Try the following two blog entries:

http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx
http://blogs.msdn.com/astebner/archive/2007/06/07/3151752.aspx

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Friday, June 27, 2008 10:12 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] LGHT0217 & VSTS

If I run a build through the VS IDE on the build machine, everything works like 
a champ.  When I run the build through Visual Studio Team Suite, Team Build, I 
get the below errors...

I followed the link and information in the URL listed in the error message, 
everything checks out.  [But I'm also not getting the error 2738 that folks are 
referencing].

Any thoughts on how I can resolve this (aside from disabling validations)?  
[Incidentally, the domain account used for the build service is part of the 
administrators group on the build machine.  The build machine is Windows 2008 
Server, with UAC turned off]


Task "Light"
  Command:
  C:\Program Files\Windows Installer XML v3\bin\Light.exe -sw1076 -loc 
..\..\..\Strings\Common_ENG.wxl -loc Ddapi.wxl -out 
"C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed 
Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.msm" -pdbout 
"C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed 
Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.wixpdb" 
obj\x64\Release\DdapiMergeModule.wixobj
  Microsoft (R) Windows Installer Xml Linker version 3.0.4227.0
  Copyright (C) Microsoft Corporation. All rights reserved.

light.exe : error LGHT0217: Error executing ICE action 'ICEM01'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM02'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM03'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM04'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM05'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM06'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and

Re: [WiX-users] LGHT0217 & VSTS

[Neil Enns]

Try the following two blog entries:

http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx
http://blogs.msdn.com/astebner/archive/2007/06/07/3151752.aspx

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga
Sent: Friday, June 27, 2008 10:12 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] LGHT0217 & VSTS

If I run a build through the VS IDE on the build machine, everything works like 
a champ.  When I run the build through Visual Studio Team Suite, Team Build, I 
get the below errors...

I followed the link and information in the URL listed in the error message, 
everything checks out.  [But I'm also not getting the error 2738 that folks are 
referencing].

Any thoughts on how I can resolve this (aside from disabling validations)?  
[Incidentally, the domain account used for the build service is part of the 
administrators group on the build machine.  The build machine is Windows 2008 
Server, with UAC turned off]


Task "Light"
  Command:
  C:\Program Files\Windows Installer XML v3\bin\Light.exe -sw1076 -loc 
..\..\..\Strings\Common_ENG.wxl -loc Ddapi.wxl -out 
"C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed 
Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.msm" -pdbout 
"C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed 
Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.wixpdb" 
obj\x64\Release\DdapiMergeModule.wixobj
  Microsoft (R) Windows Installer Xml Linker version 3.0.4227.0
  Copyright (C) Microsoft Corporation. All rights reserved.

light.exe : error LGHT0217: Error executing ICE action 'ICEM01'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM02'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM03'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM04'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM05'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM06'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following string format was not expected by the 
external UI message logger: "The Windows Installer Service could not be 
accessed. This can occur if the Windows Installer is not correctly installed. 
Contact your support personnel for assistance.".
light.exe : error LGHT0217: Error executing ICE action 'ICEM07'. The most 
common cause of this kind of ICE failure is an incorrectly registered scripting 
engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to 
solve this problem. The following

Re: [WiX-users] how do I start an application after install, not conditionally and not based on clicking on dialog

[Neil Enns]

Bryan,

I have a new how-to topic out for review that covers launching an application 
based on a checkbox at the end of setup. I've included the text of it below. 
Assuming your installer has UI, you can wire up the action in the same way (to 
the Finish button), but simply omit the piece that turns on the checkbox and 
the condition for verifying the checkbox.

I hope this helps,

Neil

How To: Run the Installed Application After Setup

Often when completing the installation of an application it is desirable to 
offer the user the option of immediately launching the installed program when 
setup is complete. This how to describes customizing the default WiX UI 
experience to include a checkbox and a WiX custom action to launch the 
application if the checkbox is checked.

This how to assumes you have already created a basic WiX project using the 
steps outlined in How To: Add a file to your installer.

Step 1: Add the extension libraries to your project

This walkthrough requires WiX extensions for UI components and custom actions. 
These extension libraries must must be added to your project prior to use. If 
you are using WiX on the command-line you need to add the following to your 
candle and light command lines:

-ext WixUIExtension -ext WixUtilExtension

If you are using Votive you can add the extensions using the Add Reference 
dialog:

Right click on your project in Solution Explorer and select Add Reference...
Select the WixUIExtension.dll assembly from the list and click Add
Select the WixUtilExtension.dll assembly from the list and click Add
Close the Add Reference dialog

Step 2: Add UI to your installer

The WiX Minimal UI sequence includes a basic set of dialogs that includes a 
finished dialog with optional checkbox. To include the sequence in your project 
add the following snippet anywhere inside the  element.





To display the checkbox on the last screen of the installer include the 
following snippet anywhere inside the  element:


The WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT property is provided by the standard 
UI sequence that, when set, displays the checkbox and uses the specified value 
as the checkbox label.

Step 3: Include the custom action

Custom actions are included in a WiX project using the  element. 
Running an application is accomplished with the WixShellExecTarget custom 
action. To tell Windows Installer about the custom action, and to set its 
properties, include the following in your project anywhere inside the  
element:




The Property element sets the WixShellExecTarget to the location of the 
installed application. WixShellExecTarget is the property Id the WixShellExec 
custom action expects will be set to the location of the file to run. The Value 
property uses the special # character to tell WiX to look up the full installed 
path of the keyfile for the component with the id myapplication.exe.

The CustomAction element includes the action in the installer. It is given a 
unique Id, and the BinaryKey and DllEntry properties indicate the assembly and 
entry point for the custom action. The Impersonate property tells Windows 
Installer to run the custom action as the installing user.

Step 4: Trigger the custom action

Simply including the custom action, as in Step 3, isn't sufficient to cause it 
to run. Windows Installer must also be told when the custom action should be 
triggered. This is done by using the  element to add it to the actions 
run when the user clicks the Finished button on the final page of the UI 
dialogs. The Publish element should be included inside the  element from 
Step 2, and looks like this:

WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and NOT 
Installed

The Dialog property specifies the dialog the Custom Action will be attached to, 
in this case the ExitDialog. The Control property specifies that the Finish 
button on the dialog triggers the custom action. The Event property indicates 
that a custom action should be run when the button is clicked, and the Value 
property specifies the custom action that was included in Step 3. The condition 
on the element prevents the action from running unless the checkbox from Step 2 
was checked and the application was actually installed (as opposed to being 
removed or repaired).


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of bryan rasmussen
Sent: Thursday, June 26, 2008 1:12 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] how do I start an application after install, not 
conditionally and not based on clicking on dialog

Specifically I am trying to do this:


 



  



How should that be restructured to work?

Thanks,
Bryan Rasmussen

On Thu, Jun 26, 2008 at 9:47 AM, bryan rasmussen
<[EMAIL PROTECTED]> wrote:
> As per the subject line, it's just supposed to install and run. The
> user doesn't have to click on the dialog to say that they want it to
> run.
>
> Thanks,
> Bryan Rasmussen
>

Re: [WiX-users] VS setup project -> WiX 3.0 conversion

[Neil Enns]

Take a look at the RegistryKey element in the WiX documentation. You can 
specify the Action attribute and set it to createAndRemoveOnUninstall.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Ivanoff
Sent: Wednesday, June 25, 2008 12:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] VS setup project -> WiX 3.0 conversion

It worked, thank you. But now I have another problem. Lets say I have
version 1 of product:






Now I am doing version 1.1:





If I do upgrade from 1.0 to 1.1 the registry key 1.1.0.0 is created, but
1.0.0.0 does not get deleted. How do I fix this?



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Wednesday, June 25, 2008 10:15
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] VS setup project -> WiX 3.0 conversion

For #1 I keep forgetting that's one of the topics on my list to add to
the docs. In the mean time you can read Alex's blog entry which is how I
got it working:
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-par
t-8-major-upgrade.aspx.


For #2, we have this set up as a WiX preprocessor variable. Somewhere in
your file put . Then wherever you want to
refer to it use $(var.MyVersion).

Neil


From: [EMAIL PROTECTED]
[EMAIL PROTECTED] On Behalf Of Alex Ivanoff
[EMAIL PROTECTED]
Sent: Wednesday, June 25, 2008 8:04 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] VS setup project -> WiX 3.0 conversion

I am just starting with WiX 3.0. As an exercise I converted one of our
simple VS 2008 setup projects to WiX 3.0 and have two questions so far:

1. How do I make the new installer uninstall the previous version of the
product? Is it just a matter of setting UpgradeCode?
2. How can I use Product element's Version attribute in the script?
Something like this:


...
  


I guess I can define a property, but is there a better way?


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


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

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


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

Re: [WiX-users] Question about $(Platform) in Votive Output name

[Neil Enns]

Ah escaping. I'm not sure if it's a VS2008 vs. Votive thing either, but if you 
want to take a test to see how painful figuring out what to escape can be, see 
the following blog entries on how VS/MSBuild handle things:

http://blogs.msdn.com/msbuild/archive/2005/10/27/484742.aspx
http://blogs.msdn.com/msbuild/archive/2005/10/31/484750.aspx
http://blogs.msdn.com/msbuild/archive/2005/11/01/484754.aspx

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Karper
Sent: Wednesday, June 25, 2008 10:17 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Question about $(Platform) in Votive Output name

So, here's the part where I answer my own question.   Sheepishly, I have to
admit that when I changed the .wixproj file by hand, I put in ($Platform)
instead of $(Platform)..  So, once that was corrected, I got the behavior I
was looking for.

The fact remains that the 2008 version seems to be escaping the non
alphanumeric characters, but whether you consider that a bug or a feature is
up to you, I guess.   I'd rather see it not escaped, but that's just me.   I
don't even know if that's a WiX thing, or a VS2008 thing.

Chris

On Wed, Jun 25, 2008 at 1:00 PM, Christopher Karper <
[EMAIL PROTECTED]> wrote:

> In a project I created in VS2005 I used "Installer $(Platform)" as my
> output name...  It worked fine by created "Installer x64.msi"
>
> Now, I've converted to VS2008, and it still works fine.
>
> However, I created a new project, and set up a merge module WiX project,
> with "Module $(Platform)" as the output name, and it creates "Module
> $(Platform).msm" as the output.
>
> In the .wixproj XML, I noticed it had escaped the $() characters, so I
> replaced those manually and reopened it, but to no avail.  It's still
> creating the name without replacement.
>
> Is this a change in platform functionality?  Was I relying on a bug that
> was fixed? Is this a bug that was introduced?  Am I a great big fat idiot?
> Any and all advice would be appreciated.  :-)
>
> Thanks!
> Chris
>
>
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


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

Re: [WiX-users] Question about $(Platform) in Votive Output name

[Neil Enns]

I just gave this a try with a clean Votive project by manually editing the 
.wixproj file to add $(Project) to the output name and it worked fine. Here's 
what my MSBuild property looks like:

WixMergeModule1 $(Platform)

This is with WiX 3.0.4022.0.

Can you send out what your Property blob at the top of the project file looks 
like?

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
Karper
Sent: Wednesday, June 25, 2008 10:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Question about $(Platform) in Votive Output name

In a project I created in VS2005 I used "Installer $(Platform)" as my output
name...  It worked fine by created "Installer x64.msi"

Now, I've converted to VS2008, and it still works fine.

However, I created a new project, and set up a merge module WiX project,
with "Module $(Platform)" as the output name, and it creates "Module
$(Platform).msm" as the output.

In the .wixproj XML, I noticed it had escaped the $() characters, so I
replaced those manually and reopened it, but to no avail.  It's still
creating the name without replacement.

Is this a change in platform functionality?  Was I relying on a bug that was
fixed? Is this a bug that was introduced?  Am I a great big fat idiot?   Any
and all advice would be appreciated.  :-)

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


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

Re: [WiX-users] VS setup project -> WiX 3.0 conversion

[Neil Enns]

For #1 I keep forgetting that's one of the topics on my list to add to the 
docs. In the mean time you can read Alex's blog entry which is how I got it 
working: 
http://blogs.technet.com/alexshev/archive/2008/02/15/from-msi-to-wix-part-8-major-upgrade.aspx.

For #2, we have this set up as a WiX preprocessor variable. Somewhere in your 
file put . Then wherever you want to refer to it 
use $(var.MyVersion).

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Alex Ivanoff [EMAIL 
PROTECTED]
Sent: Wednesday, June 25, 2008 8:04 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] VS setup project -> WiX 3.0 conversion

I am just starting with WiX 3.0. As an exercise I converted one of our
simple VS 2008 setup projects to WiX 3.0 and have two questions so far:

1. How do I make the new installer uninstall the previous version of the
product? Is it just a matter of setting UpgradeCode?
2. How can I use Product element's Version attribute in the script?
Something like this:


...
  


I guess I can define a property, but is there a better way?

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

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

Re: [WiX-users] VS 2008 WIX template projects

[Neil Enns]

If you installed the latest weekly build of WiX 3.0 you can find several how to 
guides in the help file that was installed. There's a complete sample on how to 
build a simple installer, as well as examples on using registry keys. For 
information on dialogs see http://www.wixwiki.com/index.php?title=UiExtension.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Bianca Raluca [EMAIL 
PROTECTED]
Sent: Wednesday, June 25, 2008 2:16 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] VS 2008 WIX template projects

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1079850064-1214385393=:37011"

--0-1079850064-1214385393=:37011
Content-Type: text/plain; charset=us-ascii

Hi,

Where I could find some template projects to create an installer with
WIX project in VS 2008 ? Including dialogs, registry keys, copying
files, configuration files ... basic operations during an install.
My company uses IS projects for installer developing but we are searching other 
options.

Thanks,
Bianca




--0-1079850064-1214385393=:37011
Content-Type: text/html; charset=us-ascii

Hi,Where I could find some template 
projects to create an installer with
WIX project in VS 2008 ? Including dialogs, registry keys, copying
files, configuration files ... basic operations during an install. My 
company uses IS projects for installer developing but we are searching other 
options.Thanks,Bianca

  
--0-1079850064-1214385393=:37011--


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

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

Re: [WiX-users] Choosing the right language

[Neil Enns]

Andreas,

You'll need to manually build each localized version of your MSI. Votive 
doesn't currently support building multiple installers per language, nor 
selecting between them at build time. Here's the information from the "How To: 
Build a localized installer" topic in our new help file:

How To: Build a Localized Version of Your Installer

Once you have described all the strings in your installer using language files, 
as described in How To: Make your installer localizable, you can then build 
versions of your installer for each supported language. This how to explains 
building the localized installers both from the command line and using Votive.

Option 1: Building localized installers from the command line

The first step in building a localized installer is to compile your WiX sources 
using candle.exe:

candle.exe myinstaller.wxs -out myinstaller.wixobj
After the intermediate output file is generated you can then use light.exe to 
generate multiple localized MSIs:

light.exe myinstaller.wixobj -cultures:en-us -loc en-us.wxl -out 
myinstaller-en-us.msi
light.exe myinstaller.wixobj -cultures:fr-fr -loc fr-fr.wxl -out 
myinstaller-fr-fr.msi
The -loc flag is used to specify the language file to use. It is important to 
include the -cultures flag on the command line to ensure the correct localized 
strings are included for extensions such as WiXUIExtension.

Option 2: Building localized installers using Votive

If a single language file is included in your Votive project it will 
automatically be used for strings when your MSI is built.

If you need to localize to multiple languages you will need to manually run 
light.exe on the intermediate output from your votive project with the 
appropriate command line, as described in Option 1 above. The intermediate 
output file is typically located in the obj\ folder under your project, so the 
command line will look like this when run from a command window in your 
project's obj\ folder:

light.exe myinstaller.wixobj -cultures:en-us -loc ..\en-us.wxl -out 
..\bin\debug\myinstaller-en-us.msi
light.exe myinstaller.wixobj -cultures:fr-fr -loc ..\fr-fr.wxl -out 
..\bin\debug\myinstaller-fr-fr.msi

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Hellwig
Sent: Tuesday, June 24, 2008 5:14 AM
To: WiX-Users
Subject: [WiX-users] Choosing the right language

Hi,

i've got another problem. I'm using Visual Studio 2005 to develop my WiX
installer. The installer works fine, but one problem i have left is the
fact that I can't get Visual Studio/WiX to choose the right localization
files according to the language that is set. I have included all my
localization files into the project, some for german string some others
for the english versions. But I allways get a german version even if I
set the language attributes to english (1033). Does anyone have an idea
how to fix that?

Andreas Hellwig

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


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

Re: [WiX-users] MSBuild inside Wix development

[Neil Enns]

I'll see if I can add a topic about this somewhere on my next doc refresh to 
help make it easier to find. Thanks for the feedback!

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Chris Mumford [EMAIL 
PROTECTED]
Sent: Thursday, June 19, 2008 6:30 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSBuild inside Wix development

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

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

-Chris

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

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

Re: [WiX-users] How to install multiple assemlbies to GAC

[Neil Enns]

It is a best practice to always have one assembly per component. This gives you 
far moe flexibility when you have to service your application.

Neil


-Original Message-
From: Shiliang Li <[EMAIL PROTECTED]>
Sent: Thursday, June 19, 2008 6:46 AM
To: wix-users@lists.sourceforge.net 
Subject: [WiX-users] How to install multiple assemlbies to GAC

Hi, there,

It seems that the only way to install multiple assemblies to 
GAC is to add the same number of component element in the wix file, for example:


  

  
  

  


Can we just use ONE component element to install multiple 
assemblies to GAC? If the answer is no, why?

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


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

Re: [WiX-users] MSBuild inside Wix development

[Neil Enns]

You can use it stand-alone, but it's also part of the Votive stuff that's 
significantly reworked in WiX v3. Assuming you installed WiX v3 on a machine 
that has VS on it you should be able to do File > New Project... and then pick 
WiX from the left nodes and create a new WiX project.

This is in the WiX.chm file :) When you run the chm click on "Using WiX in 
Visual Studio" in the first page that shows up. There's 6 topics on it.

Neil


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Chris Mumford [EMAIL 
PROTECTED]
Sent: Wednesday, June 18, 2008 9:52 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSBuild inside Wix development

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

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

Well anyhow, thanks for pointing this out.

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

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

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

Re: [WiX-users] Question on Merge Modules

[Neil Enns]

Fixed a small wrapping issue below that made the code sample hard to read.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns
Sent: Wednesday, June 18, 2008 9:57 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Question on Merge Modules

Here's the info on how to do it from the new How To topic I wrote on this very 
topic that should show up in the next weekly WiX build:

How To: Install the Visual C++ Redistributable with your installer

If your application depends on the Visual C++ runtimes you can include them as 
part of your installer to simplify the installation experience for your end 
users. This how to describes including the Visual C++ runtime merge modules 
into your installer and explains the expected ICE warnings you will see.

Step 1: Obtain the correct Visual C++ runtime merge modules

The Visual C++ runtime merge modules are installed with Visual Studio and are 
located in \Program Files\Common Files\Merge Modules. The Visual C++ 8.0 
runtime file is Microsoft_VC80_CRT_x86.msm. This same MSM is used for the 
Visual C++ 8.0 SP1 runtime, however it is updated in place by the Visual Studio 
2005 SP1 installer. The Visual Studio 9.0 runtime file is 
Microsoft_VC90_CRT_x86.msm. There is generally no need to include the policy 
MSMs as part of the installation.

Step 2: Include the merge module in your installer

To include the merge module in your installer use the  and  
elements. The following example illustrates how these elements are used.









The Merge element ensures the merge module is included in the final Windows 
Installer package. A unique id is assigned using the Id attribute. The 
SourceFile attribute points to the location of the merge module on your 
machine. The DiskId attribute should match the DiskId specified in your 
project's Media element. The Language attribute should always be 0.

The MergeRef element is used within a Feature element to actually install the 
merge module. In the example above a feature specific to the runtime is created 
and marked as hidden to prevent it from displaying in any UI your installer may 
use. The MergeRef refers to the merge module by its unique id.

A note about ICE warnings

Including the Visual C++ Runtime merge module in your installer will result in 
the following ICE warnings:

light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.762.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.100.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.101.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.103.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.104.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.193.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.100.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.101.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.103.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.104.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.193.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.762.98CB24AD_52FB_DB5F_FF1F_C8

Re: [WiX-users] Question on Merge Modules

[Neil Enns]

Here's the info on how to do it from the new How To topic I wrote on this very 
topic that should show up in the next weekly WiX build:

How To: Install the Visual C++ Redistributable with your installer

If your application depends on the Visual C++ runtimes you can include them as 
part of your installer to simplify the installation experience for your end 
users. This how to describes including the Visual C++ runtime merge modules 
into your installer and explains the expected ICE warnings you will see.

Step 1: Obtain the correct Visual C++ runtime merge modules

The Visual C++ runtime merge modules are installed with Visual Studio and are 
located in \Program Files\Common Files\Merge Modules. The Visual C++ 8.0 
runtime file is Microsoft_VC80_CRT_x86.msm. This same MSM is used for the 
Visual C++ 8.0 SP1 runtime, however it is updated in place by the Visual Studio 
2005 SP1 installer. The Visual Studio 9.0 runtime file is 
Microsoft_VC90_CRT_x86.msm. There is generally no need to include the policy 
MSMs as part of the installation.

Step 2: Include the merge module in your installer

To include the merge module in your installer use the  and  
elements. The following example illustrates how these elements are used.








The Merge element ensures the merge module is included in the final Windows 
Installer package. A unique id is assigned using the Id attribute. The 
SourceFile attribute points to the location of the merge module on your 
machine. The DiskId attribute should match the DiskId specified in your 
project's Media element. The Language attribute should always be 0.

The MergeRef element is used within a Feature element to actually install the 
merge module. In the example above a feature specific to the runtime is created 
and marked as hidden to prevent it from displaying in any UI your installer may 
use. The MergeRef refers to the merge module by its unique id.

A note about ICE warnings

Including the Visual C++ Runtime merge module in your installer will result in 
the following ICE warnings:

light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.762.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.100.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.101.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.103.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.104.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Component, Column: KeyPath, Key(s): 
downlevel_manifest.8.0.50727.193.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.100.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.101.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.103.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.104.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.193.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE03: String overflow (greater than length 
permitted in column); Table: Registry, Column: Registry, Key(s): 
reg_downlevel_manifest.8.0.50727.762.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E
light.exe(0,0): warning LGHT1076: ICE25: Possible dependency failure as we do 
not find [EMAIL PROTECTED] v in ModuleSignature table
light.exe(0,0): warning LGHT1076: ICE82: This action 
SystemFolder.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E has duplicate sequence number 
1 in the table InstallExecuteSequence
light.exe(0,0): warning LGH

Re: [WiX-users] WiX and Support Information in "Add or Remove Programs" panel

[Neil Enns]

No idea how they did that. The second one isn't even a valid Windows file 
version number. It must be a text string that comes from somewhere else, 
although the Windows Installer property reference doesn't list any properties 
for the version number.

Neil

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maxim Vyazovsky
Sent: Wednesday, June 18, 2008 9:13 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX and Support Information in "Add or Remove 
Programs" panel

hm,
http://i.piccy.kiev.ua/i2/45/c7/aea71120584104c1c6b99d3ba93e.jpeg
what about this?
On Wed, Jun 18, 2008 at 7:01 PM, Neil Enns <[EMAIL PROTECTED]> wrote:

> You can't, assembly version numbers are stored as numbers by the OS, so
> leading zeros are stripped.
>
> Neil
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] On Behalf Of Maxim Vyazovsky
> Sent: Wednesday, June 18, 2008 8:31 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] WiX and Support Information in "Add or Remove
> Programs" panel
>
> Hi all,
>
> If I set version number like this:
>  http://7.5.6.1/>'
> Id='{BB52FB21-F007-40ef-A73E-6717AE770446}'
>Language='1033' Codepage='1252' Version='*7.5.6.001 <http://7.5.6.1/>*'
> Manufacturer='XXX,
> Inc.'
>UpgradeCode='ebb5dec0-edce-4531-9d2b-668c8a7e0ba7'>
>
> after installation process in support information I see version without
> leading zeroes - *7.5.6.1*
> Can somebody explain how to leave leading zeroes?
> --
> Thanks,
> Max
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



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


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