Re: [WiX-users] Error 26251 -- Failed to register DLL with PerfMon
That's an error from a custom action. You'll need to contact the owner of the CA. Moving SetupSup to BCC. Heath Stewart Software Design Engineer Deployment Technologies Group, Microsoft http://blogs.msdn.com/heaths From: Amol Tambat (Wipro Technologies) Sent: Friday, February 16, 2007 1:58 AM To: Rob Mensching; wix-users@lists.sourceforge.net Cc: Windows Installer Support (MS Internal) Subject: RE: Error 26251 -- Failed to register DLL with PerfMon Adding Windows Installer Support (MS Internal) and wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net for the below mentioned problem. From: Rob Mensching Sent: Friday, February 16, 2007 3:22 PM To: Amol Tambat (Wipro Technologies); Windows Installer Team Subject: RE: Error 26251 -- Failed to register DLL with PerfMon Please see http://sharepoint/sites/wix for the correct place to ask questions. From: Amol Tambat (Wipro Technologies) Sent: Friday, February 16, 2007 1:51 AM To: Windows Installer Team Subject: Error 26251 -- Failed to register DLL with PerfMon Hi, I got an error at the time of un-installation only once. Can any one from the team, help me out to find the exact issue which caused the problem. Product: Microsoft BizTalk RFID -- Error 26251. Failed to register DLL with PerfMon. (-2147024894 C:\Program Files\Microsoft BizTalk RFID\process.ini ) Thanks Regards, Amol Tambat - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] New WiX page on Facebook
The old Facebook group for WiX is about to expire / be archived, so I created a page (more appropriate for a technology like WiX) at http://www.facebook.com/pages/WiX/198093806902572. Once we have 25 Likes I can give it a username. So if you have a Facebook account, please consider Liking http://www.facebook.com/pages/WiX/198093806902572. -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] size of installation in Add\Remove programs applet
You can set it as a public property (all caps). In your dialog events, call the SetProperty control event to set it as needed. On Tue, May 24, 2011 at 10:16 PM, Sergey sh0...@gmail.com wrote: Hello, I have installation with a lot of features. CustomizeDlg allows to select what features to install. If user changes set of installed features, total size of installed files changes. In add\Remove programs applet size of program is displayed incorrectly. I found in google that i can use ARPSIZE property to give ARP a hint, what is the size of installation. But i can not write fixed value for this property in WIX project, because size depends on features, user selects to install. How can i set ARPSIZE according to real total size of files, user selected to install? Are there some other solutions of this problem? -- Thanks! -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to install local service data files
Depending on what of that path can vary from system to system, you could use [SystemFolder]config\systemprofile\appdata\roaming, but 1) why roaming for a system (local) service, and 2) can it be some other directory? If it can be a locked down but shared directory, you might instead use [CommonApDataFolder], which results to all users' AppData folder. The MSI documentation has more. On Fri, May 20, 2011 at 6:28 AM, Miles Waller miles.wal...@gmail.comwrote: Hi, I have written an installed for a service using wix, which runs under the Local System account. So far, so good. Now I want to install some data files that go with the service, under the Local System profile's data folder. On my machine, that means here: C:\Windows\System32\config\systemprofile\AppData\Roaming though presumably the path depends on the user's exact set up. (I got this location by getting the service to create some files when it started.) How do I get WIX to put my data file in the right place in this scenario - I naively tried APPDATA, but that of course is under the installing user's profile and not the local system account. I've googled around and looked in the docs but can't find anything useful on this... Thanks for your help, Miles -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New WiX page on Facebook
Thanks to all who have Liked the page so far. We have been able to claim http://www.facebook.com/wixtoolset now, though the link below should still work (albeit not as memorable). For the time being, we'll continue to publish toolset updates through the Facebook page. On Tue, May 24, 2011 at 11:13 PM, Heath Stewart clubs...@gmail.com wrote: The old Facebook group for WiX is about to expire / be archived, so I created a page (more appropriate for a technology like WiX) at http://www.facebook.com/pages/WiX/198093806902572. Once we have 25 Likes I can give it a username. So if you have a Facebook account, please consider Liking http://www.facebook.com/pages/WiX/198093806902572. -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to define the content expiration for folder in WebDirProperties (WIX3.5.2519.0)
According to http://msdn.microsoft.com/en-us/library/ms525353.aspx, it appears there's a space between D, and the hex number. On Wed, May 25, 2011 at 3:24 AM, Kiseleva Elena lena121...@yandex.ruwrote: Hi! I want to define the content expiration for some folder on IIS7 during installation. When I define it like: |iis:WebDirProperties Id=Folder_ContentExpiration HttpExpires=D,0x278d00/ | but it doesn't work. In this case when I open my directory (for which I defined HttpExpires) in IIS manager, click HTTP Response Headers in the center of window, click Set Common Headers... in right part of window and I see the next error: The string was not recognized as a valide DateTime. There is unknown word starting at index 0. So, which attributes (and in wich format) of WebDirProperties should I use for to define the content expiration for folder after 30 days? Wix version is 3.5.2519.0. Thanks, Elena -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in Torch?
Gilad, could you detail what the database code pages are set to? From the
Windows Installer SDK, you can use msiinfo /d *msifilename* to retrieve the
database code page (note this is not the same as the summary information
code page). Or if you can reproduce a small issues I would like to review it
and use it to test any fix.
On Wed, Jun 3, 2009 at 3:22 PM, Gilad Israeli gilad.isra...@mks.com wrote:
Created bug # 2800797. I included all the files in the Binder Unbinder
emporary directories
-- Gilad
-Original Message-
From: Rob Mensching [mailto:r...@wixtoolset.org]
Sent: June 3, 2009 6:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Never heard of it. Can you please post a bug and include all
of the Property.idt files from the directories listed below.
Gilad Israeli wrote:
Hello
I was trying to create a single language msi (for English
Japanese). Both compiled successfully with candle light but
I ran into the following problem when I ran torch to get the
difference between the msi files.
Running torch with the following parameters:
torch.exe -t language
c:/sandboxes/vsi/solution/components/integrations/obj/wix/en-us/MKS_VS
_Integration.msi
c:/sandboxes/vsi/solution/components/integrations/obj/wix/ja-jp/MKS_VS
_Integration.msi -out ja-jp.mst
gives the following error:
C:\Documents and Settings\gisraeli\Local
Settings\Temp\grsu1t0s\ja-jp_target\Property.idt : error
TRCH0136 : There was an error importing table 'Property' from
file 'C:\Documents and Settings\gisraeli\Local
Settings\Temp\grsu1t0s\ja-jp_target\Property.idt'.
Binder temporary directory located at 'C:\Documents and
Settings\gisraeli\Local Settings\Temp\grsu1t0s'.
Unbinder temporary directory located at 'C:\Documents and
Settings\gisraeli\Local Settings\Temp\grsu1t0s'.
Torch temporary directory located at 'C:\Documents and
Settings\gisraeli\Local Settings\Temp\ucjzoerv'.
make: Error code 136
was there a bug posted for this or a know workaround?
thanks
Gilad
--
OpenSolaris 2009.06 is a cutting edge operating system for
enterprises looking to deploy the next generation of Solaris that
includes the latest innovations from Sun and the OpenSource
community.
Download a copy and enjoy capabilities such as Networking,
Storage and
Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
OpenSolaris 2009.06 is a cutting edge operating system for
enterprises looking to deploy the next generation of Solaris
that includes the latest innovations from Sun and the
OpenSource community. Download a copy and enjoy capabilities
such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Heath Stewart
Deployment Technologies Team, Microsoft
http://blogs.msdn.com/heaths
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in Torch?
Gilad, I need the database code page. The code page shown there is only for
the summary information stream. The database code page can be displayed by
running msiinfo */d* *database.msi*.
On Thu, Jun 4, 2009 at 7:40 AM, Gilad Israeli gilad.isra...@mks.com wrote:
Running msiinfo on the english msi gives:
[C:/sandboxes/vsi/solution/components/integrations/obj/wix/en-us] info.exe
MKS_VS_Integration.msi
ClassId = {000C1084---C000-0046}
[ 1][/c] Codepage = 1252
[ 2][/t] Title = Installation Database
[ 3][/j] Subject = MKS Integrity Integration for Microsoft Visual Studio
[ 4][/a] Author = MKS Inc.
[ 5][/k] Keywords = Installer
[ 6][/o] Comments = This installer database contains the logic and data
required to install MKS Integrity Integration fo
r Microsoft Visual Studio.
[ 7][/p] Template(MSI CPU,LangIDs) = Intel;1033
[ 9][/v] Revision = {31BCE398-C733-413A-9786-D7FEBF090C42}
[12][/r] Created = 2009/06/03 18:14:14
[13][/q] LastSaved = 2009/06/03 18:14:14
[14][/g] Pages(MSI Version Used) = 200
[15][/w] Words(MSI Source Type) = 2
[18][/n] Application = Windows Installer XML (3.0.5217.0)
[19][/u] Security = 2
And on the japanese msi gives:
ClassId = {000C1084---C000-0046}
[ 1][/c] Codepage = 932
[ 2][/t] Title = Installation Database
[ 3][/j] Subject = ??? MKS Integrity Integration for Microsoft Visual
Studio
[ 4][/a] Author = MKS Inc.
[ 5][/k] Keywords = Installer
[ 6][/o] Comments = This installer database contains the logic and data
required to install ??? MKS Integrity Integratio
n for Microsoft Visual Studio.
[ 7][/p] Template(MSI CPU,LangIDs) = Intel;1041
[ 9][/v] Revision = {43153C45-B5F1-46E4-B264-5132DFEB96BC}
[12][/r] Created = 2009/06/03 18:14:24
[13][/q] LastSaved = 2009/06/03 18:14:24
[14][/g] Pages(MSI Version Used) = 200
[15][/w] Words(MSI Source Type) = 2
[18][/n] Application = Windows Installer XML (3.0.5217.0)
[19][/u] Security = 2
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com]
Sent: June 3, 2009 11:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Gilad, could you detail what the database code pages are set
to? From the Windows Installer SDK, you can use msiinfo /d
*msifilename* to retrieve the database code page (note this
is not the same as the summary information code page). Or if
you can reproduce a small issues I would like to review it
and use it to test any fix.
On Wed, Jun 3, 2009 at 3:22 PM, Gilad Israeli
gilad.isra...@mks.com wrote:
Created bug # 2800797. I included all the files in the Binder
Unbinder emporary directories
-- Gilad
-Original Message-
From: Rob Mensching [mailto:r...@wixtoolset.org]
Sent: June 3, 2009 6:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Never heard of it. Can you please post a bug and include
all of the
Property.idt files from the directories listed below.
Gilad Israeli wrote:
Hello
I was trying to create a single language msi (for English
Japanese). Both compiled successfully with candle light
but I ran
into the following problem when I ran torch to get the difference
between the msi files.
Running torch with the following parameters:
torch.exe -t language
c:/sandboxes/vsi/solution/components/integrations/obj/wix/en-us/MKS_
VS
_Integration.msi
c:/sandboxes/vsi/solution/components/integrations/obj/wix/ja-jp/MKS_
VS
_Integration.msi -out ja-jp.mst
gives the following error:
C:\Documents and Settings\gisraeli\Local
Settings\Temp\grsu1t0s\ja-jp_target\Property.idt : error
TRCH0136 : There was an error importing table 'Property'
from file
'C:\Documents and Settings\gisraeli\Local
Settings\Temp\grsu1t0s\ja-jp_target\Property.idt'.
Binder temporary directory located at 'C:\Documents and
Settings\gisraeli\Local Settings\Temp\grsu1t0s'.
Unbinder temporary directory located at 'C:\Documents and
Settings\gisraeli\Local Settings\Temp\grsu1t0s'.
Torch temporary directory located at 'C:\Documents and
Settings\gisraeli\Local Settings\Temp\ucjzoerv'.
make: Error code 136
was there a bug posted for this or a know workaround?
thanks
Gilad
--
OpenSolaris 2009.06 is a cutting edge operating system
for enterprises looking to deploy the next generation
of Solaris
that includes the latest innovations from Sun and the OpenSource
community.
Download a copy and enjoy capabilities such as Networking,
Storage and
Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
___
WiX-users mailing
Re: [WiX-users] Bug in Torch?
I can repro it and am debugging it. Just a quick note, though: because the
ProductName is localized and goes into the SummaryInfo stream, you should
also set the code page for the summary information stream which is a
separate @Codepage attribute. Currently it doesn't display properly because
code points in the ja-JP MSI's summary information stream aren't valid for
code page 1252.
On Fri, Jun 5, 2009 at 6:55 AM, Gilad Israeli gilad.isra...@mks.com wrote:
Sorry about that. Here it is with the /d option:
[C:/sandboxes/vsi/solution/components/integrations/obj/wix/en-us] info.exe
MKS_VS_Integration.msi /d
String ID size: 2
Code page: 1252
[C:/sandboxes/vsi/solution/components/integrations/obj/wix/en-us] cd ..
[C:/sandboxes/vsi/solution/components/integrations/obj/wix] cd ja-jp
[C:/sandboxes/vsi/solution/components/integrations/obj/wix/ja-jp] info.exe
MKS_VS_Integration.msi /d
String ID size: 2
Code page: 932
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com]
Sent: June 4, 2009 8:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Gilad, I need the database code page. The code page shown
there is only for the summary information stream. The
database code page can be displayed by running msiinfo */d*
*database.msi*.
On Thu, Jun 4, 2009 at 7:40 AM, Gilad Israeli
gilad.isra...@mks.com wrote:
Running msiinfo on the english msi gives:
[C:/sandboxes/vsi/solution/components/integrations/obj/wix/en-
us] info.exe
MKS_VS_Integration.msi
ClassId = {000C1084---C000-0046}
[ 1][/c] Codepage = 1252
[ 2][/t] Title = Installation Database [ 3][/j] Subject = MKS
Integrity Integration for Microsoft Visual Studio [ 4][/a] Author =
MKS Inc.
[ 5][/k] Keywords = Installer
[ 6][/o] Comments = This installer database contains the logic and
data required to install MKS Integrity Integration fo r Microsoft
Visual Studio.
[ 7][/p] Template(MSI CPU,LangIDs) = Intel;1033 [ 9][/v] Revision =
{31BCE398-C733-413A-9786-D7FEBF090C42}
[12][/r] Created = 2009/06/03 18:14:14 [13][/q] LastSaved =
2009/06/03
18:14:14 [14][/g] Pages(MSI Version Used) = 200 [15][/w] Words(MSI
Source Type) = 2 [18][/n] Application = Windows Installer XML
(3.0.5217.0) [19][/u] Security = 2
And on the japanese msi gives:
ClassId = {000C1084---C000-0046}
[ 1][/c] Codepage = 932
[ 2][/t] Title = Installation Database [ 3][/j] Subject = ??? MKS
Integrity Integration for Microsoft Visual Studio [ 4][/a] Author =
MKS Inc.
[ 5][/k] Keywords = Installer
[ 6][/o] Comments = This installer database contains the logic and
data required to install ??? MKS Integrity Integratio n for
Microsoft
Visual Studio.
[ 7][/p] Template(MSI CPU,LangIDs) = Intel;1041 [ 9][/v] Revision =
{43153C45-B5F1-46E4-B264-5132DFEB96BC}
[12][/r] Created = 2009/06/03 18:14:24 [13][/q] LastSaved =
2009/06/03
18:14:24 [14][/g] Pages(MSI Version Used) = 200 [15][/w] Words(MSI
Source Type) = 2 [18][/n] Application = Windows Installer XML
(3.0.5217.0) [19][/u] Security = 2
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com]
Sent: June 3, 2009 11:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Gilad, could you detail what the database code pages are set to?
From the Windows Installer SDK, you can use msiinfo /d
*msifilename* to retrieve the database code page (note
this is not
the same as the summary information code page). Or if you can
reproduce a small issues I would like to review it and use it to
test any fix.
On Wed, Jun 3, 2009 at 3:22 PM, Gilad Israeli
gilad.isra...@mks.com wrote:
Created bug # 2800797. I included all the files in the Binder
Unbinder emporary directories
-- Gilad
-Original Message-
From: Rob Mensching [mailto:r...@wixtoolset.org]
Sent: June 3, 2009 6:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Never heard of it. Can you please post a bug and include
all of the
Property.idt files from the directories listed below.
Gilad Israeli wrote:
Hello
I was trying to create a single language msi (for English
Japanese). Both compiled successfully with candle light
but I ran
into the following problem when I ran torch to get the
difference between the msi files.
Running torch with the following parameters:
torch.exe -t language
c:/sandboxes/vsi/solution/components/integrations/obj/wix/en-us/MKS_
VS
_Integration.msi
c:/sandboxes/vsi/solution/components/integrations/obj/wix/ja-jp/MKS_
VS
Re: [WiX-users] Bug in Torch?
The problem is that you're not specifying the
Product/@UpgradeCodeattribute. If you do, this should pass. The simple
test you provided did.
There is a bug in the code we will consider for WiX v3.5 but with a simple
workaround and WiX v3 shutting down for RTM (only high-pri bugs) we will not
fix this in 3.0.
Note that just because you specify the UpgradeCode it won't create an
upgrade package. More is involved (like authoring the Upgrade table and
RemoveExistingProducts) so your behavior won't change.
On Thu, Jun 11, 2009 at 8:19 PM, Heath Stewart clubs...@gmail.com wrote:
I can repro it and am debugging it. Just a quick note, though: because the
ProductName is localized and goes into the SummaryInfo stream, you should
also set the code page for the summary information stream which is a
separate @Codepage attribute. Currently it doesn't display properly because
code points in the ja-JP MSI's summary information stream aren't valid for
code page 1252.
On Fri, Jun 5, 2009 at 6:55 AM, Gilad Israeli gilad.isra...@mks.comwrote:
Sorry about that. Here it is with the /d option:
[C:/sandboxes/vsi/solution/components/integrations/obj/wix/en-us] info.exe
MKS_VS_Integration.msi /d
String ID size: 2
Code page: 1252
[C:/sandboxes/vsi/solution/components/integrations/obj/wix/en-us] cd ..
[C:/sandboxes/vsi/solution/components/integrations/obj/wix] cd ja-jp
[C:/sandboxes/vsi/solution/components/integrations/obj/wix/ja-jp] info.exe
MKS_VS_Integration.msi /d
String ID size: 2
Code page: 932
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com]
Sent: June 4, 2009 8:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Gilad, I need the database code page. The code page shown
there is only for the summary information stream. The
database code page can be displayed by running msiinfo */d*
*database.msi*.
On Thu, Jun 4, 2009 at 7:40 AM, Gilad Israeli
gilad.isra...@mks.com wrote:
Running msiinfo on the english msi gives:
[C:/sandboxes/vsi/solution/components/integrations/obj/wix/en-
us] info.exe
MKS_VS_Integration.msi
ClassId = {000C1084---C000-0046}
[ 1][/c] Codepage = 1252
[ 2][/t] Title = Installation Database [ 3][/j] Subject = MKS
Integrity Integration for Microsoft Visual Studio [ 4][/a] Author =
MKS Inc.
[ 5][/k] Keywords = Installer
[ 6][/o] Comments = This installer database contains the logic and
data required to install MKS Integrity Integration fo r Microsoft
Visual Studio.
[ 7][/p] Template(MSI CPU,LangIDs) = Intel;1033 [ 9][/v] Revision =
{31BCE398-C733-413A-9786-D7FEBF090C42}
[12][/r] Created = 2009/06/03 18:14:14 [13][/q] LastSaved =
2009/06/03
18:14:14 [14][/g] Pages(MSI Version Used) = 200 [15][/w] Words(MSI
Source Type) = 2 [18][/n] Application = Windows Installer XML
(3.0.5217.0) [19][/u] Security = 2
And on the japanese msi gives:
ClassId = {000C1084---C000-0046}
[ 1][/c] Codepage = 932
[ 2][/t] Title = Installation Database [ 3][/j] Subject = ??? MKS
Integrity Integration for Microsoft Visual Studio [ 4][/a] Author =
MKS Inc.
[ 5][/k] Keywords = Installer
[ 6][/o] Comments = This installer database contains the logic and
data required to install ??? MKS Integrity Integratio n for
Microsoft
Visual Studio.
[ 7][/p] Template(MSI CPU,LangIDs) = Intel;1041 [ 9][/v] Revision =
{43153C45-B5F1-46E4-B264-5132DFEB96BC}
[12][/r] Created = 2009/06/03 18:14:24 [13][/q] LastSaved =
2009/06/03
18:14:24 [14][/g] Pages(MSI Version Used) = 200 [15][/w] Words(MSI
Source Type) = 2 [18][/n] Application = Windows Installer XML
(3.0.5217.0) [19][/u] Security = 2
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com]
Sent: June 3, 2009 11:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Gilad, could you detail what the database code pages are set to?
From the Windows Installer SDK, you can use msiinfo /d
*msifilename* to retrieve the database code page (note
this is not
the same as the summary information code page). Or if you can
reproduce a small issues I would like to review it and use it to
test any fix.
On Wed, Jun 3, 2009 at 3:22 PM, Gilad Israeli
gilad.isra...@mks.com wrote:
Created bug # 2800797. I included all the files in the Binder
Unbinder emporary directories
-- Gilad
-Original Message-
From: Rob Mensching [mailto:r...@wixtoolset.org]
Sent: June 3, 2009 6:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bug in Torch?
Never heard of it. Can you please post a bug and include
all of the
Property.idt files from the directories listed below.
Gilad
Re: [WiX-users] Need examples For Major, Minor, Build a nd Revison changes
There are a number of examples in wix.chm (that installs with the product, and is availalbe online at http://wix.sourceforge.net) that show how to create small update and minor upgrade patches, as well as major upgrade products. You can also ship small update and minor upgrade products but it's not typical. Essentially you just build your upgrade layout and ship that without building a patch. If you have specific questions about the documentation, please be sure to reference which topic you're inquiring about. On Fri, Jun 5, 2009 at 4:07 AM, Uday Kumar uda...@hotmail.com wrote: Hi, I am new to WIX and trying to create MSI packages for Major, minor and revison changes for my application. Can someone please provide the examples on this. Also i dont want these versions to be displayed in add/remove programs. Thanks, Uday. _ Live Search extreme As India feels the heat of poll season, get all the info you need on the MSN News Aggregator http://news.in.msn.com/National/indiaelections2009/aggregator/default.aspx -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Inconsistent modification date time of Patched Binary on different timezone.
The timestamps in a file are not changed during install (only if a file was actually created by, say, a custom action during installation). There are no standard ways of changint the timestamps; to do so is non-standard. Is there some specific reason it matters? Perhaps we can help you determine an alternate solution. On Wed, Jun 10, 2009 at 4:46 AM, varun kataria varunk0...@yahoo.com wrote: Hi All, I am creating a basic patch on a basic msi and when i install this patch on two different machines with different timezone, the patched binary modification date time is same . Means the modification date time of the binary does not change according to the different timezone on the installation machine(where i am installing the patch). If you can provide me some property to set or the change in creation process of patch then it will be very helpful. I have tried using WIX2.0 and WIX3.0. Thanks Varun. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MergeModules vs. WixLib
Wixlibs are just a collection of compiled outputs and binaries. When you include them in your project, you must reference something from them (unlike MSMs that are merged in regardless of the target product). As if you used different fragments - one that defined a Component and another in your product that referenced it with a ComponentRef - it's no different for a wixlib. So if your wixlib defined Component/@Id=C, then your product should reference the wixlib (as you've done in VS) and add ComponentRef/@Id=C. That will pull in any other authoring within the same fragment, or any other fragments referenced by the first fragment (recursively). It's just like referencing symbols with multiple files during linkage. Wixlibs can contain anything you can put in a fragment normally, but to use the wixlib a fragment must define a symbol (something with a corresponding *Ref element). On Fri, Jun 12, 2009 at 12:09 AM, karthik.shenoy karthik.she...@robosoftin.com wrote: Hi All, I want to create an project with wix Lib instead of using WiX merge module. Where can I find any information on WiX lib projects. Can I include Files, registry information in WiX Libs. I created a sample project as mentioned below in WiXlib and gave the reference to same in MSI in visual studio through Add- references. Installation completes but neither the directory is created nor the files are installed. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=HS Name=HS Directory Id=DigitalImaging Name=Digital Imaging Merge Id=policy_9_0_Microsoft_VC90_MFC_x86.msm Language=1033 SourceFile=C:\Program Files\Common Files\Merge Modules\policy_9_0_Microsoft_VC90_MFC_x86.msm DiskId=1/ Component Id=TXT Guid=9E432F2A-869A-457A-8755-78C1665E778A File Id=VBS Source=C:\Documents and Settings\Sanjeev\Desktop\c.vbs/File /Component /Directory /Directory /Directory /Directory Feature Id=ProductFeature Title=MSI Level=1 ComponentRef Id=TXT/ MergeRef Id=policy_9_0_Microsoft_VC90_MFC_x86.msm/ /Feature /Fragment /Wix Am I going wrong somewhere?? Thanks in Advance Regards KPS --- Robosoft Technologies - Come home to Technology Disclaimer: This email may contain confidential material. If you were not an intended recipient, please notify the sender and delete all copies. Emails to and from our network may be logged and monitored. This email and its attachments are scanned for virus by our scanners and are believed to be safe. However, no warranty is given that this email is free of malicious content or virus. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating multi-instance installations using WiX
Instancing is a feature of MSI covered in the Windows Installer SDK. WiX v3 does add fairly simple support to build embedded instance transforms for known instances. See the documentation for the InstanceTransforms element. This and child Instance elements allow you to define unique property values as well. Patching these instances means building patches against each instanced ProductCode. Or you can also produce a patch where the Validation element does not target the ProductCode (by default it does). On Fri, Jul 3, 2009 at 9:05 AM, Carl Caulkett carl.caulk...@amxeurope.comwrote: Hello, Does anyone know of a way to create an installation using WiX where the user can specify a particular instance for the installation and for this to be controlled at the WiX level rather than delving down into the murky depths of MSI? In other words supposing we have an installer which installs application A, can the user run the installer and specify that she wants to install instance A1 in a particular folder, and then later come along and run the installer again, this time specifying the installation of instance A2 in a different folder, with the result that there are two separate installations of the A application, one instance called A1, the other called A2, and, crucially, separate entries in the Add/Remove Programs list. We have a solution at the moment but it is a hybrid approach with a Delphi written front end which gathers the installation details and then passes them as parameters to a WiX written MSI and uses MSI Transforms to achieve the multiple instances! It works quite well, but we would like a purely WiX solution going forward. Thanks in advance, Carl Carl Caulkett - Developer, Inspired Signage Group AMX http://www.amx.com/ - 6th Floor, Salisbury House, London Wall, London, EC2M 5QQ Main Office +44 (0) 1904 343 100 carl.caulk...@amxeurope.com mailto:carl.caulk...@amxuk.co.uk P Please consider the environment before deciding to print this email AMX AMX UK Auster Road Clifton Moor York, North Yorkshire United Kingdom YO30 4GD +44 (0) 1904 343100 office +44 (0) 1904 343101 fax AMX South 6th Floor Salisbury House London Wall London United Kingdom EC2M 5QQ +44 (0) 2076 529450 office +44 (0) 8701 991661 fax AMX Belgium Boerenkrijglaan, 96a B-2260 Westerlo Belgium + 32 (0) 1454 2763 office + 32 (0) 1454 2766 fax ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. This email was scanned and cleared by NetIQ MailMarshal. ## -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uncompressed package and error finding files
Uncompresed, non-embedded source files are not supported for Windows Installer patches. On Thu, Jul 2, 2009 at 11:33 AM, Chris Bardon cbar...@computer-talk.comwrote: I've been experimenting with creating msp files for all updates, and I've run into a strange problem. I read about having to create uncompressed cabs for a patch, so I created two different installers that upgrade a single text file, and actually managed to create the msp file, but then I noticed something strange with the original installer. When I run this setup now, it complains that it's unable to find readme.txt in the path that I run the installer from. If I change the Compressed attribute on the Package node to yes the installer works. Is there something else that I need to do to get the installer to work in the first place? Here's the markup for the original installer (it's pretty basic): ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=611D452A-D8D3-482e-AC5B-BFA9A9B1BF6D Name=Patch Test Product Language=1033 Version=1.0.0.0 Manufacturer=ComputerTalk UpgradeCode=edb51369-d386-46c8-96ee-8244a40d18d3 Package InstallerVersion=300 Description=Patch Test Manufacturer=ComputerTalk Comments=Some product Compressed=no / Media Id=1 Cabinet=PatchTest.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLLOCATION Name=PatchTest Component Id=ProductComponent Guid=b3bf3e0b-d116-49cd-8d24-b7c76a7c3b28 File Id=readme Name=readme.txt Source=..\$bin\readme.txt/ /Component /Directory /Directory /Directory Feature Id=ProductFeature Title=PatchTest Level=1 ComponentRef Id=ProductComponent / /Feature /Product /Wix The install log from my test machine looks like this when I run the msi from c:\insttemp: Error 1309. Error reading from file: C:\insttemp\PatchTest\readme.txt. System error 3. Verify that the file exists and that you can access it. This is building with Votive under VS 2008, and using version 3.5.0619.0 of the toolkit. Any idea what's going on? The \PatchTest directory doesn't exist under c:\insttemp, but the files should be embedded in the msi, correct? Thanks for the help, Chris -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Versioning interop assemblies for patching
tlbimp.exe does allow you to set the assembly version using the /asmversion option which also sets the file version. Note that it's the file version that matters, though - not the assembly or product version. During link, you won't need to pass -fv to light.exe since the assembly version changes. Ship a publisher policy assembly in the GAC to automatically update bindings to the new version as documented in the .NET Framework SDK at http://msdn.microsoft.com/en-us/library/dz32563a.aspx. On Thu, Jun 25, 2009 at 4:54 PM, Tony Juricic tjuri...@tradestation.comwrote: In this particular case I am not interested in setting Company Name and version number for my interop assemblies (that is, files generated using tlbimp) just so that the name is not an empty string and that the version is not 1.0.0.0. In order to have un-installable patches I need assembly file version numbers to change whenever the code changes. How are other developers handling this problem? Are you just praying that you never have to patch interop assembly or have you settled for solution as explained here: http://blogs.msdn.com/ianhu/archive/2005/06/16/429903.aspx I there any better, newer solution? As a matter of fact, I could not get the solution described at the blog link above to work because ilasm.exe from MS SDKs just won't run without fusion.dll. I have a bunch of fusion dlls installed in SxS (a new Hell after DLL Hell) but, really, does anybody in this century even run ilasm.exe anymore? If you do, please help! TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] (still) trying to install a PowerShell SnapIn using WiX
What command are you running to link your project (light.exe)? I see no notable differences between what you have and what I've had for a while that works for me ( http://psmsi.codeplex.com/SourceControl/changeset/view/28813#40647). On Tue, Oct 20, 2009 at 11:22 AM, Michael_A mcl...@fullarmor.com wrote: Mark Parker-2 wrote: Simon Dahlbacka wrote: On Mon, Sep 28, 2009 at 9:37 PM, Mark godef...@gmail.com wrote: I'm (still) trying to install a SnapIn using WiX and PSExtension. I'm (still) getting the same error, however, which doesn't make any sense to me, and I believe it's a bug in PSExtension. Here's the relevant component in my .wxs file: Component Id=nmps_dll Guid=1c48d3b5-64ab-4f0c-9ce6-c4eb6f3232e9 File Id=pstools.dll Source=$(var.pstools.TargetDir) KeyPath=yes Assembly=.net AssemblyApplication=pstools.dll ps:SnapIn Id=pstools Description=Management Tools Vendor=mycompany / /File /Component And when I try to build the installer, I get this error: Unresolved bind-time variable !(bind.assemblyName.pstools.dll), Version=!(bind.assemblyVersion.pstools.dll), Culture=!(bind.assemblyCulture.pstools.dll), PublicKeyToken=!(bind.assemblyPublicKeyToken.pstools.dll). If I leave the ps:SnapIn tag out, it builds fine (but doesn't register the snapin, of course), and if I leave the AssemblyApplication attribute out, I get an error about strong names (which is expected, it's not strong-named, but I don't want it to go in the GAC). Don't know anything about installing snapins but: Doesn't @Assembly=.net say that the file is to be installed in GAC ? /Simon Did you ever find a resoultion to this issue as I'm having the same problem. --Michael -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/still-trying-to-install-a-PowerShell-SnapIn-using-WiX-tp3731130p3860392.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: package ref-counting not working
There were some changes post-beta and we're working to get a new build published. Most of the scenarios are working now. Stayed tuned on http://blogs.msdn.com/heaths for more information when I can find time to start documenting the feature (and the protocol). On Thursday, January 12, 2012, Kryschan wrote: Hi folks, as I read in the WiX 3.6 Beta release notes, burn does support package ref-counting now, which according to my understanding should guarantee, that shared packages are uninstalled only if all bundles sharing the packages were removed. Here is a little example: - install Bundle1(containing SharedPackage, Package1) - install Bundle2(containing SharedPackage, Package2) - uninstall Bundle1 -- results in removal of SharedPackage and Package1 I would expect that only Package1 gets removed. Am I just misunderstanding the feature or may I miss something in my bundle definitions? Best regards Christian -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-package-ref-counting-not-working-tp7183258p7183258.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version
You need to add PropertyRef Id=ProductVersion/ to a patch family. I recommend using a unique patch family only for that purpose. Note that if you have other components in the same entry section (i.e., Product element fragment) they will be included as well. It's best to always put anything that can be in a fragment in a fragment (like features, components, custom actions/binary, etc.). On Thursday, January 12, 2012, Bob Arnson wrote: On 11-Jan-12 03:00, Ulrich Proeller wrote: The switch -sf in the pyro command was added the get rid of a duplicate key error. That's likely the root cause of your problem. Fix the underlying bug before trying workarounds. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.6 Burn - Automatic Updates could not be paused
www.dynagen.cahttp://www.dynagen.ca -- -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ __ __ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure_ __ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers
ICE does not seem work correctly on a default, locked-down install of Windows Server 2008 R2 with AppLocker enabled. IIRC, an MSI policy that is locked down on Server also has to be enabled (it's been a while since I had to ge this working on my own machine). On Thu, Mar 29, 2012 at 1:21 PM, Christopher Painter chr...@iswix.comwrote: I've done more research. I wrote a per-user install that didn't require admin and tried to install it by using an MSBuild Exec task. I got a 1601 error message saying the installer service was unavailable. I also ran sc query msiserver and it didn't say it was disabled. But clearly MSI is locked down in their build environment. From: John Cooper jocoo...@jackhenry.com Sent: Thursday, March 29, 2012 3:00 PM To: chr...@iswix.com chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers Could it be authority to execute/registration of vbscript? I believe some of those validation tests still have vbs in them, and if it can't run, it's going to fail every time. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, March 29, 2012 11:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Build WiX Projects via msbuild using TFSPreview Hosted Build Servers I've started playing with Microsoft's new hosted build service and I've come across some issues. The environment is locked down ( the builds don't run with administrative priv ) so you can't install software. While I understand WiX can xcopy deploy to a build envionment, I wanted to also leverage the MSBUILD ( .wixproj ) support because, well, that's kind of the whole design of TFS Team Build. So I grabbed the contents of the MSBuild Targets dirctory and the WiX directory and checked it into source control. Then I passed the following values into the build: /p:WiXTargetsPath=..\WiX\MSBuild\wix.targets;WixTasksPath=WiXTasks.dll;WixTo olPath=..\WiX\Application\bin;WixExtDir=..\WiX\Application\bin Everything almost worked except for ICE Validation. I was getting the usual suspect: light.exe: 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.. I'm running the X86 msbuild platform. Does anyone have any suggestions on what could be done with user-privs only to fix this problem? Turning off validation is a horrible work around. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle failing to build after upgrading to latest release (3.6.2823)
I've opened https://sourceforge.net/tracker/?func=detailaid=3521813group_id=105970atid=642714 to track this. On Wed, Apr 25, 2012 at 9:30 AM, Bob Arnson b...@joyofsetup.com wrote: On 25-Apr-12 11:45, Pally Sandher wrote: Microsoft (R) Windows Installer Xml Linker version 3.6.2823.0 Copyright (C) Microsoft Corporation. All rights reserved. light.exe(0,0): error LGHT0001: An item with the same key has already been added. Exception Type: System.ArgumentException That's bad. Can you unzip the .pdbs into your WiX directory to get line numbers and file a bug? -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle failing to build after upgrading to latest release (3.6.2823)
This should be fixed in the next build of WiX out Monday evening. Please verify and let me know. Thanks, On Thu, Apr 26, 2012 at 7:10 PM, Heath Stewart clubs...@gmail.com wrote: I've opened https://sourceforge.net/tracker/?func=detailaid=3521813group_id=105970atid=642714 to track this. On Wed, Apr 25, 2012 at 9:30 AM, Bob Arnson b...@joyofsetup.com wrote: On 25-Apr-12 11:45, Pally Sandher wrote: Microsoft (R) Windows Installer Xml Linker version 3.6.2823.0 Copyright (C) Microsoft Corporation. All rights reserved. light.exe(0,0): error LGHT0001: An item with the same key has already been added. Exception Type: System.ArgumentException That's bad. Can you unzip the .pdbs into your WiX directory to get line numbers and file a bug? -- sig://boB http://joyofsetup.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixExitEarlyWithSuccess not working for me
Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number?
The -val switch is actually to set transform validation flags and has nothing to do with validation during generation. See http://blogs.msdn.com/heaths/archive/2007/09/13/transform-validation-in-wix-patch-build.aspx for more information about that feature. Have you defined patch families in your patch authoring? If you don't or if you don't reference all the right fragments, the content of those fragments is ignored. You can find more information about patch families at http://blogs.msdn.com/pmarcu/archive/2007/04/27/wix-patchfamily-patch-filtering.aspx, http://blogs.msdn.com/heaths/archive/2007/05/08/patch-families-can-only-ever-grow.aspx, and http://blogs.msdn.com/heaths/archive/2008/01/14/patch-families-in-wix-and-windows-installer.aspx . On Thu, Jul 31, 2008 at 9:22 AM, Tony Juricic [EMAIL PROTECTED]wrote: Are you saying that there is some way to get better error diagnostics from Torch? I added -v option for verbosity but it has no effect. In fact, I can't even figure out how do validation flags validate?! For example, once I run Torch with -val y, next time with -val v, keeping the same wixout input files. I would expect some validation error to be reported: I mean, update versions of my DLLs can't be both larger and smaller than the target versions! However Torch reports no issues in either case, just silently outputs wixmst file which, according to Pyro, contains 120 MB of nothing. I certainly have-p option which is essential according to Peter's blog. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2008 11:04 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? There is a share proderrors or something Pete Yates Senior Systems Developer DDC - Distributed Components Team HBOS II IT B/1/C/243 (7725) 34383 / (0117) 376 4383 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: 31 July 2008 15:56 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? I have 120 MB large Wixmst created by Torch and when I pass it to Pyro it comes back with the message PYRO1079 saying that patch cabinet contains no files. My DLLs in RTM and Update respectively differ in the last, 4-th version number, plus the binaries themselves are different. Using SDK tools for patch creation these DLLs would be updated when applying the patch. I tested that long before I started using WiX and I am 100% sure that SDK doesn't ignore fourth version number for file substitution rules. So I am wondering if Pyro is ignoring binary differences if first 3 version numbers are the same? Patch.wxs content is the following: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Patch AllowRemoval=yes Classification=Update Codepage=1252 ... various other attributes Media Id=1000 Cabinet=RTM.cab EmbedCab=yes PatchBaseline Id=RTM/ /Media PatchFamily Id=MyPatchFamily Version=1.0.0 Supersede=yes ComponentRef Id=some component / ... a bunch of components follows /PatchFamily /Patch /Wix 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users . -- HBOS plc, Registered in Scotland No. SC218813. Registered Office: The Mound, Edinburgh EH1 1YZ. HBOS plc is a holding company, subsidiaries of which are authorised and regulated by the Financial Services Authority. HBOS is a carbon neutral company. Help keep it that way. Please don't print this message unless you really must. == - 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http
Re: [WiX-users] Multiple instance installations and patches
Actually, WiX supports this already without having to execute code. Under
your PatchBaseline element add the Validation element and set
ProductCode=no. The double-click scenario for the resulting MSP will
only apply to the default instance (the instance you created the patch from)
but it will apply explicitly to any instance even if the ProductCode is the
same (assuming your instance transforms aren't changing the ProductVersion,
ProductLanguage, or UpgradeCode). So they'd apply like so:
msiexec /i {42A33A91-36B0-4700-A6F5-1289D22F358C} PATCH=*path\to\patch.msp*
If you want to enable the double-click scenario while only building the
patch against the default instance (which makes sense - it's all the same
differences and files) use the new TargetProductCodes element added to WiX
3.0.5106.0. Under your Patch element, add;
TargetProductCodes
TargetProductCode Id={42A33A91-36B0-4700-A6F5-1289D22F358C}/
TargetProductCode Id={68C62C01-D064-4CF0-9239-F5D2FF36BD9A}/
/TargetProductCodes
Now when the MSP is double-clicked it will apply to any and all instances
installed.
On Tue, Dec 30, 2008 at 4:48 AM, Yan Sklyarenko y...@sitecore.net wrote:
Hello,
Well, I managed to overcome this myself. For those who interested in
details, please visit my blog:
http://ysdevlog.blogspot.com/2008/12/multiple-instance-installations-and
.htmlhttp://ysdevlog.blogspot.com/2008/12/multiple-instance-installations-and%0A.html
I would appreciate any comments.
-- Yan
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Wednesday, December 24, 2008 4:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Multiple instance installations and patches
Hello WiX community,
I'm just stuck with this scenario and I'd appreciate any hint.
I have a product which supports multiple instance installations with the
help of instance transforms. In order to make the components data
isolated, it is installed to different folders (like best practice guide
suggests), and also I apply another transform to change component GUIDs
for each instance. Hence, in order to install instance 1 I use the
following command line:
Msiexec /i MyPackage.msi MSINEWINSTANCE=1
TRANSFORMS=:InstanceId1;:ComponentGUIDTransform1.mst INSTALLLOCATION=...
And for instance 2:
Msiexec /i MyPackage.msi MSINEWINSTANCE=1
TRANSFORMS=:InstanceId2;:ComponentGUIDTransform2.mst INSTALLLOCATION=...
Etc.
This works perfectly.
Now I'd like to build a patch which then can be applied to any of the
instance. I use the pure-WiX way of building the .msp:
candle Patch.wxs
light Patch.wixobj -out Patch.wixmsp
torch -p -xi v100\MyPackage.wixpdb v101\ MyPackage.wixpdb -out
diff.wixmst
pyro Patch.wixmsp -out Patch.msp -t UpdatePatch diff.wixmst
The output patch.msp can successfully patch the default instance only.
Now, again following the guide, I'm going to populate the Targets
property of the patch SummaryInfo stream with the product codes of other
instances. Something like this:
static void SetTargetProductGUIDs(string mspPath, Liststring
productCodes)
{
using (Database patchDatabase = new Database(mspPath,
DatabaseOpenMode.Transact))
{
StringBuilder targetsBuilder = new StringBuilder();
foreach (string productCode in productCodes)
{
targetsBuilder.Append(targetsBuilder.Length == 0 ?
productCode : string.Format(;{0}, productCode));
}
patchDatabase.SummaryInfo.Template =
targetsBuilder.ToString();
patchDatabase.Commit();
}
}
This really updates the patch file. I can see this in Orca: View -
Summary Information - Targets field contains all product codes.
BUT, when I try to apply this modified patch to other instances of my
application (not only default), I get the same error:
The upgrade patch cannot be installed by the Windows Installer service
because the program to be upgraded may be missing, or the upgrade patch
may update a different version of the program. Verify that the program
to be upgraded exists on your computer and that you have the correct
upgrade patch.
Does anyone know what can be wrong? Any hint... Please, help...
Thank you.
-- Yan
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Heath Stewart
Deployment Technologies Team, Microsoft
http://blogs.msdn.com/heaths
Re: [WiX-users] Patch creation problems
3.0.4429.0 To create my patch I'm using the following method: 1. Compile original msi 2. Change a text file that is included in the msi. 3. Compile new msi 4. Create a transform between the two msi's. torch.exe -p -xi original\Product.wixpdb Product.wixpdb -out Patch\Diff.Wixmst 5. Build the patch pyro.exe Patch\Patch.WixMsp -out Patch\Patch.msp -t RTM Patch\Diff.wixmst here is my patch.wxs file: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Patch AllowRemoval=yes Manufacturer=Clearview Software DisplayName=Test Patch Description=Small Update Patch Classification=Update MinorUpdateTargetRTM=yes Media Id=5000 Cabinet=RTM.cab PatchBaseline Id=RTM / /Media PatchFamilyRef Id=TestPatchFamily / /Patch Fragment PatchFamily Id=TestPatchFamily Version=5.0.907.0 Supersede=yes ComponentRef Id=test.txt/ /PatchFamily /Fragment /Wix - 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=100url=/ ___ 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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values
Description=!(loc.ProductName) Comments=!(loc.ProductName) ShortNames=no Languages=1033 Compressed=yes Manufacturer=!(loc.ProductManufacturer) / PatchMetadata AllowRemoval=yes Description=!(loc.ProductName) ManufacturerName=!(loc.ProductManufacturer) TargetProductName=!(loc.ProductName) MoreInfoURL=!(loc.ProductUrl) Classification=Update DisplayName=!(loc.ProductName) / Family DiskId=5000 MediaSrcProp=v11Patch Name=v11Patch SequenceStart=5000 UpgradeImage Id=v11Upgrade SourceFile=$(var.ProjectDir)obj\$(var.Configuration)\v1.1adminInstall\RP Event Notification Service.msi TargetImage Id=v10Target IgnoreMissingFiles=no Order=2 SourceFile=$(var.ProjectDir)obj\$(var.Configuration)\v1.0adminInstall\RP Event Notification Service.msi / /UpgradeImage /Family PatchSequence PatchFamily=EventingV11PatchFamily Sequence=1.0.0.0 Supersede=yes / /PatchCreation rem msiexec.exe /a $(Setup.TargetDir)en-us\$(Setup.TargetFileName) /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log if $(IsDesktopBuild) == msiexec.exe /a $(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification Service.msi /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log if $(IsDesktopBuild) == false msiexec.exe /a $(OutDir)en-us\RP Event Notification Service.msi /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log if exist $(TargetDir)en-us\$(TargetName).log del $(TargetDir)en-us\$(TargetName).log pushd $(TargetDir)en-us\ C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\MsiMsp.exe -s $(ProjectDir)obj\$(Configuration)\$(TargetName).pcp -p $(TargetName).msp -l $(TargetName).log popd cmd /c echo end processing patch post-build event command lines -Original Message- From: wix-users-boun...@lists.sourceforge.net [mailto: wix-users-boun...@lists.sourceforge.net] On Behalf Of Bob Arnson Sent: Saturday, September 13, 2008 9:40 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values Robert O'Brien wrote: Any insights on what could be in my pretty typical wix3 sources generated msi's that would be preventing them from successfully creating the expected admininstall output where the contained files are unpacked which is needed for my torch patch installer related command to succeed? If a feature's install level is 0, 'msiexec /a' won't install it. -- 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=100url=/ ___ 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New wix binary delta patching doesn't work
Are you still having the same problem with recent builds? A month or two ago changes were made to fix a couple of issues with delta patching. On Tue, Aug 19, 2008 at 5:57 AM, Tony Juricic tjuri...@tradestation.comwrote: Ok, that makes sense. However, I can't get it to work either way. The problem is not in changing just the 4th version number either. I created a simple C# console executable that has one line of code: Console.Writeln(This is version 1.0.0.0); and assembly info AssemblyVersion(1.0.0.0)] and AssemblyFileVersion(1.0.0.0)]. I build WiX test project referencing this program with -bf -xo linker options. The output is WixTest1.msi but it is not msi file since it can't be opened with Orca. Is it wixpdb or wixout? Torch doesn't like wixpdb extension (error TRCH0048) but accepts wixout. I then update console program by changing all the strings 1.0.0.0 above to 1.0.1.0, then rebuild exe and WiX project, changing also Product element, Version attribute to 1.0.1.0. This gives me the second wixout file for input to torch and I get 31 KB large Diff.wixmst. When I run Pyro it comes with PYRO0252 error meaning that it can't find any transform. Torch and Pyro invoking batch files content is the following: %WIX%bin\torch.exe -p -xi -v -val g -val l -val r -val z Version1000\WiXTest1000.wixout Version1010\WiXTest1010.wixout -out Patch\Diff.Wixmst %WIX%bin\candle.exe Patch.wxs %WIX%bin\light.exe Patch.wixobj -out Patch\Patch.WixMsp REM %WIX%bin\pyro.exe -delta Patch\Patch.WixMsp -out Patch\Patch.msp -t RTM Patch\Diff.wixmst %WIX%bin\pyro.exe Patch\Patch.WixMsp -out Patch\Patch.msp -t RTM Patch\Diff.wixmst Note above REMarked -delta option. Patch.wxs content is: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Patch AllowRemoval=yes Classification=Update Codepage=1252 ClientPatchId=WiXTest1 Id=* DisplayName=WiXTest1 Update Manufacturer=WiXTest1 MoreInfoURL=http://www.WiXTest1.com; Description=Minor Update Patch TargetProductName=WixTest1 Media Id=1000 Cabinet=Patch.cab EmbedCab=yes Source=FIRSTPATCH_PROP PatchBaseline Id=RTM/ /Media PatchFamilyRef Id=WiXTest1_PatchFamily / /Patch Fragment PatchFamily Id=WiXTest1_PatchFamily Version=1.0.0 Supersede=no ComponentRef Id=CONSOLEAPPLICATION1.EXE / /PatchFamily /Fragment /Wix Obviously, I am doing something horribly wrong in my adaptation of Peter Marcu's blog example or there is a nasty bug somewhere in there. -Original Message- From: Blair Murri [mailto:bmu...@microsoft.com] Sent: Monday, August 11, 2008 1:56 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New wix binary delta patching doesn't work The -delta switch of pyro builds on top of the whole-file patch support in pyro, so if that isn't working, the delta addition won't do anything to help you. If you get pyro to build a whole file patch that updates your binaries, then add the -delta switch and test the results. - 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number?
In a verbose log Windows Installer 3.1+ will add a line line SELMGR: A component *foo* is registered to feature *bar*, but was removed from the feature., followed immediately by something like SELMGR: Removal of components from a feature is not supported. But this will not fail the patch. Instead it will advertise the feature and the content of that feature will never be repaired again. See http://blogs.msdn.com/heaths/archive/2006/01/23/516457.aspx for more information. MSIENFORCEUPGRADECOMPONENTRULES merely turns that into an error, so instead of silently breaking the product the property (and the corresponding machine policy) will fail the install. So a small update or minor upgrade patch will apply if you break this component violation, but the feature will forever be broken until explicitly added back into the local state. See http://blogs.msdn.com/heaths/archive/2009/01/27/repairing-products-after-patches-advertised-features.aspxfor some suggestions of how to do that. On Wed, Aug 6, 2008 at 1:33 AM, Tony Juricic tjuri...@tradestation.comwrote: It just goes to show how easy it is to commit gross component rules violations even after months of reading articles and blogs on component rules! However, it seems that I have also misunderstood the purpose of MSIENFORCEUPGRADECOMPONENTRULES property. I was under the impression that it would add to verbose log. I mean, if MSI *knows* that there is component violation, it would be of great help if it could add a sentence to the log saying at least something along the lines of: There is component rules violation of some sort! After reading all that I could find on MSIENFORCEUPGRADECOMPONENTRULES property I can't say that I am 100% sure about what is it that it really does? How can the consequences of having this property defined or not be seen on some practical example? I was certainly none the wiser in this specific case since verbose logs were identical with or without it, for all that I could see. It *seems* that a small update patch may be applied by MSI in some cases even if there was a component rule violation and this property prevents it. -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Saturday, August 02, 2008 1:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does Pyro (or Torch) ignore 4-th version number? Tony Juricic wrote: but reading the install.log I cannot find anything a bit more explicit about this violation. It is certainly not saying something like you changed the name of your root installation folder and you shouldn't :) Sorry, it's not that polite.g The Windows Installer Components topic summarizes the magic of component rules with two bullets: In brief, these rules are: * Each component must be stored in a single folder. * No file, registry entry, shortcut, or other resources should ever be shipped as a member of more than one component. This applies across products, product versions, and companies. So changing the directory violates 50 percent of the component rules.g -- 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=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to prevent downgrading when doing Minor Upgrade
I assume you mean a minor upgrade MSI, since for a patch this shouldn't be a problem unless you're using a minor upgrade MSP with bad validation bits targeting newer ProductVersions). A minor upgrade MSI won't apply by default. It has to be reinstalled - explicitly setting the REINSTALL property (or using msiexec /f, which is equivalent); optionally, REINSTALLMODE will contain v to cache the minor upgrade (otherwise the ProductVersion will not change and a subsequence repair will regress files). So whatever bootstrap application you're using to conditionally install the minor upgrade MSI - can't that check the product version of what's already installed? Seems you're doing something along these lines anyway to detect if the product is installed. If using MsiGetProductInfo(Ex)() for example, get the INSTALLPROPERTY_VERSIONSTRING property. You can then compare that with the ProductVersion you're trying to install and determine if they're newer. On Thu, Apr 2, 2009 at 5:46 PM, Rajesh P rajeshp.bl...@gmail.com wrote: Hi Is there a way iw WiX to prevent downgrade with minor upgrades. Can we write a custom action to verify and compare installed product version. If yes, can someone suggest some Msi api's that can use in my VC++ custom action dll. Is there any other easier way to achieve this. Thanks, Rajesh -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Edit Configuration file
This will completely break silent / unatended installations. You should prompt the user in your installer UI using public properties (they can pass to the installer whether running silent, basic, or reduced UI (required then) or in full UI (just defaults then). WiX does have custom actions for updating an XML file, but the format of the XML file is completely up to you. XML defines no standard schema, so your service can read whatever XML schema it needs. It could be incredibly simple like: service serverhttp://foo/server idbar/id /service So if you needed to customize server/ and id/, you can use WiX's XmlConfig elements using propeties passed from the UI. Bringing up notepad is ot a good user experience, nor is it always possible. On Thu, Apr 2, 2009 at 4:04 AM, Niaz Khan n...@purecm.com wrote: Hi, I need some help on wix. The installer works fine it installs the service and then starts the service. The service starts as soon as it is installed. i want to launch a notepad (Configuration file) in the middle of service install and start. Ideally I want that when the installation of service is completed the installer should lanunch the notepad rather than starting the service directly and when the user edits and save the notepad then it should start the service. I am able to launch the notepad on the exit dialog with a checkbox but i want it to be launched in the middle of service install and start. I am not quite sure if it is possible in wix. After some research on the internet I found that xmlfile has been used to edit the config files, but I am not quite sure of using this one because my config file has multiple sub elements for some elements. I think this approach is better when we have to edit small number of values. I am not sure if someone has used xmlfile approach for large config file, any other alternatives or ideas will be really appreciated. cheers. Niaz This e-mail is intended only for the above addressee. It may contain privileged information. If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. If you have received it in error please delete it and immediately notify the sender. PureCM.com Limited. Registered in England and Wales. Company Number : 0505 3024 Registered Office : Charter House, Charter Way, Hurdsfield, Macclesfield, Cheshire. SK10 2NG -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem reading Environment variables
The documentation for the WriteEnvironmentStrings action @ http://msdn2.microsoft.com/library/aa372883.aspx state that the variables are not effective in the current installation. So when you launch your console app from the installer process the environment variables are inherited from the installer process which will not include your new environment variables. On Fri, Apr 3, 2009 at 3:21 AM, sandun css sandun...@gmail.com wrote: Hi, I set few environment variables from my wix installer, and refer them from a console application (C#), whcih gets launched at the end of my WiX installer. (I have a custom action to launch that console app, when the user presses the 'Finish' button of the msi) But my console application fails to read the env. variables set by the msi. When I look at the env varibles (from 'control panel - System - Advanced System settings - Env variables'), I can see them as well. I am using Windows Server 2008. Can you please advice me on this? Thanks, Sandun -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstalling not default transform instances
As long as your shared resources are in a component with the same GUID (i.e., your instance transforms do not re-GUID your components) yes, Windows Installer (and fusion for GAC assemblies) do keep a reference count. Bear in mind, however, that if you uninstall a patch for any instance files are downgraded (shared component ref counts don't guard against that) *unless*you are installing with MSI 4.5 and specify the Component/@Shared=yes attribute. If you are applying your instance transforms as secure transforms (transfor...@emea_instance) you do not need to specify them again even during uninstall. When you look in a verbose installer log (msiexec.exe ... /L*vx install.log) does the log say the action was skipped because the condition evaluated to false? After a product is installed (after InstallFinalize returns) the property Installed should always be defined. On Tue, Jan 13, 2009 at 4:35 PM, phillip_sid...@dellteam.com wrote: I have created a number of instance transforms in my WiX installer as below: !-- Non-Default instances -- InstanceTransforms Property=APPINSTANCE !-- These instances are for DIT, SIT and PROD -- Instance ProductCode=4E7CC0E0-BECC-4e79-A626-20028B93C8C9 ProductName=MSS DAO Windows Service Id=DAO_Instance/ Instance ProductCode=3F164DA9-8C57-49e9-9346-A06DA9B5580D ProductName=MSS EMEA Windows Service Id=EMEA_Instance/ Instance ProductCode=35646A8B-F991-44b1-AAE8-57DF08B30272 ProductName=MSS APJ Windows Service Id=APJ_Instance/ !-- These instances are for UAT - special case becuase they may exist on same servers as SIT instances -- Instance ProductCode=14CAA264-8CF9-48d8-B174-0A5B298C561E ProductName=MSS DAO UAT Windows Service Id=DAO_UAT_Instance/ Instance ProductCode=CD94A497-0091-4522-AD60-E21A7CFBDFF0 ProductName=MSS EMEA UAT Windows Service Id=EMEA_UAT_Instance/ Instance ProductCode=2D226523-ADF4-40fa-BA1E-624FE84EF1CF ProductName=MSS APJ UAT Windows Service Id=APJ_UAT_Instance/ /InstanceTransforms When uninstalling one of these non-default instances, I need to make sure that my custom actions get run. Most of the time I will be leaving other instances on the machine. Custom Action=CleanupDataFiles After=InstallFinalizeInstalled/Custom This custom action does not run when uninstalling with msiexec /u TRANSFORMS=EMEA_Instance ... However, the rest of the app instance gets uninstalled fine. Does someone know the correct condition to use? On a related note when GACd assemblies and shared COM objects are removed for one instance, does the MSI and/or windows keep a usage count so that other instances are not broken? Thanks. - Phil -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unexpected supersedence behavior
Conditions are only evaluated at initial install unless they are transitive. To better diagnose the issue, do you have verbose install logs from installing QFE2 and SP1? On Fri, Jan 2, 2009 at 10:34 AM, Ryan Parlee list...@jesca.com wrote: I am trying to understand why some things are not behaving the way I expect. I have the following packages: MNP2000.msi (v.1.40) MNP2000-QFE1.mcp (targeted on v1.40, patch sequence = 1.40.1, supersedence = no) MNP2000-QFE2.mcp (targeted on v1.40, patch sequence = 1.40.2, supersedence = no) MNP2000-SP1.mcp (targeted on v1.40, patch sequence = 1.41.0, supersedence = yes, upgrades ProductVersion = 1.41) In the packages above, QFE1 updates the Concert.txt file. QFE2 removes the Dance.txt file by updating the Dance component condition with 1=0. SP1 contains the fixes in QFE1 but keeps the Dance component with condition 1=1. The problem I am having is that when SP1 is applied the Dance.txt file does not get reinstalled. Additional notes: 1. Dance.txt does correctly reinstall if I remove both SP1 and then QFE2. 2. I am getting what I believe to be correct experience from within appwiz.cpl: - Initial Install: MNP2000 [version = 1.40] - After install QFE1:MNP2000 + QFE1 [version = 1.40] - After install QFE2:MNP2000 + QFE1 + QFE2 [version = 1.40] - After install SP1:MNP2000 + SP1 [version = 1.41] - After uninstall SP:MNP2000 + QFE1 + QFE2 [version = 1.40] ... What I think is happening is that the diff between Initial Install and SP1 that is recorded in the SP1 patch does not contain data to restore the condition of the Dance component to 1=1. So my question is: How do I get SP1 to work the way I want? Shouldn't the installation of SP1 remove prior patches because its supersedence bit it set? If it worked that way, Component(Dance).Condition would be restored to 1=1. What am I missing? *** Thanks, Ryan Parlee -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Letters in ProductVersion
Along those same lines, you should consider never using the ProductVersion property in your installation for things like directories or registry keys (if you change them in a major upgrade, you break component rules). That said, you might consider not showing the ProductVersion property for the same reason (keep this purely MSI concept separate from your product display). So define a new property like AppProductVersion that you can set however you like and change whenever you like without negative ramification to Windows Installer. On Tue, Jan 6, 2009 at 6:39 PM, Michael Osmond mosm...@baytech.com.auwrote: Hi, The approach I would recommend is try not to put so much meaning into the version number. Make the MSI version number something simple, which always changes. We have deliberately restricted things to Major.Minor.build for the MSI version number. Internally the buil number is rolled every time anything changes, so nothing would be released that would not be different (well almost but that's a different story). If you want or need the other information put it somewhere else - in a reg key, in the product name in Add/Remove programs, in the Summary Information. Michael -Original Message- From: lesterbangs [mailto:datapa...@gmail.com] Sent: Wednesday, 7 January 2009 11:26 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Letters in ProductVersion Polite bump on this... Am I approaching this from the wrong angle? I mean, I know I can easily add a registry entry with the version string in any format I want, but I am more concerned about how to identify the product in x.y.z format in order for upgrades to work. There must be someone else here that has to deal with weird product versions... lesterbangs wrote: Our product versions mostly conform to the major.minor.build convention specified by the MSI standard, but sometimes we have to put letters in the strings to indicate an update or hotfix, i.e. 1.0.5.U1 or 2.4.16.HF02. Obviously this is a big no-no to have letters in ProductVersion property. Worse, sometimes we have updates to hotfixes, or vice-versa, such as 3.1.72.U1.HF04. I imagine we would have to come up with some sort of translation table to convert a numbers-letters string to a pure numbers string that MSI can understand. I.e. 2.4.16.HF02 becomes 2.4.1602 and 1.0.5.U1 becomes 1.0.5100. According to the specification, Windows Installer ignores anything after the 3rd field. So even if we were able to change it to all numbers, 3.1.72.U1.HF04 would become 3.1.72.01.04, but only 3.1.72 would be recognized. 3.1.720104 would also not work, as field 3 cant be larger than 65536. 3.1.7214 would work but only for update numbers less than 10. This could get confusing very fast. Is anyone in a similar situation? What is the easiest way to mitigate this issue? -- View this message in context: http://n2.nabble.com/Letters-in-ProductVersion-tp2113603p2120366.html Sent from the wix-users mailing list archive at Nabble.com. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX Patching, Merge Module problem?
MSMs would already be merged into the the MSI at that point, so any differences in your MSMs will be visible. But it depends on your patch authoring. What does your patch source file look like? Can you post it or a sample online? On Fri, Apr 3, 2009 at 11:24 AM, Stryder Crown stryde...@gmail.com wrote: Learning WiX, getting into patching and have all sorts of confusion. But, maybe someone can clarify for me: When running torch on two .msi files (the original and the updated one), torch isn't going to find differences in referenced merge modules is it? Which means my transform file isn't going to contain any 'new things', and that's why I'm getting these 'no valid transforms' error, right? What is the recommended strategy for patching if the update is in one of the merge modules? Or am I missing something? Stryder -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Running WiX tools from Cygwin, environment variables
If you use a .wixproj, you can run msbuild /v:diag and it will show all the variables for the process - whether environment variables or project variables. Details about writing a .wixproj file (wraps all the candle, light, etc. commands into a build project) can be found in wix.chm. On Fri, Apr 3, 2009 at 6:59 PM, Geoff Kennedy geoff.kenn...@belcarra.comwrote: Hi, new to the group! My question is this: I have a Cygwin shell script which sets an environment variable called REVISION (set to anotherversion). My .wxs has the following code in it: ?define BUILD=none? !-- Override BUILD if the environment variable REVISION is preset -- ?ifdef $(env.REVISION) ? ?define BUILD=$(env.REVISION) ? ?endif? I know the variable exists, but Candle doesn't seem to pick it up. The idea is that BUILD should be set to anotherversion. Has anyone else tried to run WiX in this way? My job needs this, so any tips are welcome! I've had zero success exploring the usual avenues (Google, FAQs, etc.). I'm also new to XML, is there a way that I can show the incoming env. vars from within my .wxs file? Thanks to all. GLK -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstalling second patch does not remove patched files
If patch 2 supersedes patch 1, it MUST include all the same content. If you're noticing that files are not removed, changes are that your features you've modified are now advertised: http://blogs.msdn.com/heaths/archive/2006/01/23/516457.aspx. But without logs it's hard to say. Can you update a verbose log from when you installed patch 2 after 1? If patch 2 does not supersede 1, both will show up in ARP. If it does supersede 1, only patch 2 should show up but it also depends if you set ARPSYSTEMCOMPONENT property or not. A log can help me help you diagnose it. On Thu, Apr 9, 2009 at 3:37 AM, shibo szheng...@googlemail.com wrote: More info: If I install patch 2 only, then uninstall it, files are removed. -- View this message in context: http://n2.nabble.com/uninstalling-second-patch-does-not-remove-patched-files-tp2610228p2610381.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multiple instance installations and patches
/p and some APIs care about the target ProductCodes and will actually
modified the resulting PATCH property if a ProductCode is not targetted. You
should use the TargetProductCodes element in that case. I have a blog post
coming about that (hopefully) soon at http://blogs.msdn.com.
On Wed, Apr 8, 2009 at 12:47 AM, Yan Sklyarenko y...@sitecore.net wrote:
Thanks a lot for the hint, Heath!
That's fantastic I can achieve the same without shaman dancing
dismembering msp file!
WiX rules!! :)
One small question: is there any reason why this command format works:
msiexec /i {42A33A91-36B0-4700-A6F5-1289D22F358C}
PATCH=*path\to\patch.msp*
but this doesn't (throwing that The upgrade patch cannot be installed
... error):
msiexec /p *path\to\patch.msp* /n
{42A33A91-36B0-4700-A6F5-1289D22F358C}
?
This is reproduced without TargetProductCode elements.
-- Yan
-Original Message-
From: Heath Stewart [mailto:clubs...@gmail.com]
Sent: Friday, April 03, 2009 9:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Multiple instance installations and patches
Actually, WiX supports this already without having to execute code.
Under
your PatchBaseline element add the Validation element and set
ProductCode=no. The double-click scenario for the resulting MSP will
only apply to the default instance (the instance you created the patch
from)
but it will apply explicitly to any instance even if the ProductCode is
the
same (assuming your instance transforms aren't changing the
ProductVersion,
ProductLanguage, or UpgradeCode). So they'd apply like so:
msiexec /i {42A33A91-36B0-4700-A6F5-1289D22F358C}
PATCH=*path\to\patch.msp*
If you want to enable the double-click scenario while only building the
patch against the default instance (which makes sense - it's all the
same
differences and files) use the new TargetProductCodes element added to
WiX
3.0.5106.0. Under your Patch element, add;
TargetProductCodes
TargetProductCode Id={42A33A91-36B0-4700-A6F5-1289D22F358C}/
TargetProductCode Id={68C62C01-D064-4CF0-9239-F5D2FF36BD9A}/
/TargetProductCodes
Now when the MSP is double-clicked it will apply to any and all
instances
installed.
On Tue, Dec 30, 2008 at 4:48 AM, Yan Sklyarenko y...@sitecore.net wrote:
Hello,
Well, I managed to overcome this myself. For those who interested in
details, please visit my blog:
http://ysdevlog.blogspot.com/2008/12/multiple-instance-installations-and
.htmlhttp://ysdevlog.blogspot.com/2008/12/multiple-instance-installatio
ns-and%0A.html
I would appreciate any comments.
-- Yan
-Original Message-
From: Yan Sklyarenko [mailto:y...@sitecore.net]
Sent: Wednesday, December 24, 2008 4:44 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Multiple instance installations and patches
Hello WiX community,
I'm just stuck with this scenario and I'd appreciate any hint.
I have a product which supports multiple instance installations with
the
help of instance transforms. In order to make the components data
isolated, it is installed to different folders (like best practice
guide
suggests), and also I apply another transform to change component
GUIDs
for each instance. Hence, in order to install instance 1 I use the
following command line:
Msiexec /i MyPackage.msi MSINEWINSTANCE=1
TRANSFORMS=:InstanceId1;:ComponentGUIDTransform1.mst
INSTALLLOCATION=...
And for instance 2:
Msiexec /i MyPackage.msi MSINEWINSTANCE=1
TRANSFORMS=:InstanceId2;:ComponentGUIDTransform2.mst
INSTALLLOCATION=...
Etc.
This works perfectly.
Now I'd like to build a patch which then can be applied to any of the
instance. I use the pure-WiX way of building the .msp:
candle Patch.wxs
light Patch.wixobj -out Patch.wixmsp
torch -p -xi v100\MyPackage.wixpdb v101\ MyPackage.wixpdb -out
diff.wixmst
pyro Patch.wixmsp -out Patch.msp -t UpdatePatch diff.wixmst
The output patch.msp can successfully patch the default instance only.
Now, again following the guide, I'm going to populate the Targets
property of the patch SummaryInfo stream with the product codes of
other
instances. Something like this:
static void SetTargetProductGUIDs(string mspPath, Liststring
productCodes)
{
using (Database patchDatabase = new Database(mspPath,
DatabaseOpenMode.Transact))
{
StringBuilder targetsBuilder = new StringBuilder();
foreach (string productCode in productCodes)
{
targetsBuilder.Append(targetsBuilder.Length == 0 ?
productCode : string.Format(;{0}, productCode));
}
patchDatabase.SummaryInfo.Template =
targetsBuilder.ToString();
patchDatabase.Commit();
}
}
This really updates the patch file. I can see this in Orca
Re: [WiX-users] MSI language problem
If you installed the German transform initially with the product as a secure transform, it is cached with the product and always used by default. You'll have to uninstall the product and reinstall without the transform. PatchPackage is a table that patches use. Patches (MSPs) contain transforms, so when MSI is applying transforms part of the code path assumes it might be a patch and, so, checks for patch tables. It's not a problem here - just an informational message. On Wed, Apr 8, 2009 at 2:53 AM, Andy2k8 appr...@gmail.com wrote: I have checked that and its correct. Here are the debug log snippet: MSI (c) (7C:0C) [15:08:32:611]: Looking for storage transform: DE_de.mst MSI (c) (7C:0C) [15:08:32:611]: Validating transform 'DE_de.mst' with validation bits 0 MSI (c) (7C:0C) [15:08:32:611]: Transform 'DE_de.mst' is valid. MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2205 2: 3: Patch MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2205 2: 3: PatchPackage MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2262 2: _Tables 3: -2147287038 MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2262 2: _Columns 3: -2147287038 MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2262 2: Media 3: -2147287038 MSI (c) (7C:0C) [15:08:32:611]: Note: 1: 2262 2: File 3: -2147287038 MSI (c) (7C:0C) [15:08:32:611]: TRANSFORM: 'PatchPackage' table is missing or empty. No pre-transform fixup necessary. MSI (c) (7C:0C) [15:08:32:611]: TRANSFORM: Applying regular transform to database. It looks like the MSI applies the german transform during the runtime even when i do not try to apply using the TRANSFORMS public property during the MSI runtime.What does PatchPackage has got to do with the transforms?? I have also tried applying an english transform to the same MSI.Even then i see that the MSI is getting launched in German..Somebody is overwriting the TRANSFORMS property.. from the debug logs:: MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Adding RestrictedUserControl property. Its value is '1'. MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Modifying TRANSFORMS property. Its current value is ':DE_de.mst'. Its new value: 'EN_en.mst'. MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'D:\'. MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '0'. MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Adding CLIENTPROCESSID property. Its value is '1916'. MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Modifying TRANSFORMS property. Its current value is 'EN_en.mst'. Its new value: ':DE_de.mst'. MSI (c) (7C:0C) [15:08:32:627]: TRANSFORMS property is now: :DE_de.mst MSI (c) (7C:0C) [15:08:32:627]: PROPERTY CHANGE: Adding PRODUCTLANGUAGE property. Its value is '1033'. Any idea why is the german transforms always getting dominated here theough i try to apply the english transform??? Check your Product/@Language and Package/@Language (if specified). Andy2k8 wrote: I see that the default UI language of the MSI got changed from English to German after I have fiddled with the German transforms.Now whenever I run any of my application MSI which is not embedded with any language transforms, it gets launched in the German language.The system locale is set to English - United States. What is going wrong here?? How do I get the MSIs run in the default English language? - Andy MSI Developer Schneider Electric:working: -- View this message in context: http://n2.nabble.com/MSI-language-problem-tp2591550p2591550.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Andy MSI Developer Schneider Electric:working: -- View this message in context: http://n2.nabble.com/MSI-language-problem-tp2591550p2604263.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- This SF.net email is sponsored by: High
Re: [WiX-users] Error 1723. A DLL required for this install to complete could not be run. C#
Are you using P/Invoke (DllImportAttribute) for any custom actions? If the referenced DLL is not available in the system PATH environment variable you will see this. This is common for native debug builds, but for managed CAs you shouldn't see this unless you're referencing an assembly that you're not packaging together with makesfxca.exe. And if you're not using makesfxca.exe, that's likely the problem. Unless managed assemblies are available in the GAC at install time, the Windows Installer service cannot access them. On Fri, Apr 10, 2009 at 6:10 AM, Natalia natalia.gladk...@arcadia.spb.ruwrote: I know that using custom actions written in C# is not a very good idea, but it happened we are using it in our project. I experience very exasperating problem with my dll. SOMETIMES, when I add new custom action to my cs-file, some custom action that worked good previously starts to return the error mentioned in the title: A DLL required for this install to complete could not be run. Installer cannot find entry point. I suspected that there's something wrong with encoding, tried to open my cs-file in various editors, remove spaces between [CustomAction] and the function's definition... Sometimes it helped in miraculous way. But now I can do nothing about this, my custom action doesn't work. Maybe someone experienced the same thing and knows some way to fix it? I use Microsoft Visual Studio 2008 with Votive, WiX 3.0.5120.0. -- View this message in context: http://n2.nabble.com/Error-1723.-A-DLL-required-for-this-install-to-complete-could-not-be-run.-C--tp2616125p2616125.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX MSBuild. WixLibrary HintPath
Please open a bug on http://sourceforge.net/projects/wix. Be sure to describe what version of WiX you're using and the thorough example you've posted here. On Wed, Apr 8, 2009 at 11:37 PM, Murray Hipper mhip...@snowdengroup.comwrote: Hi All, Why does user reference paths not update wix library locations and still enforces the use of the hint path? Is there any way around it? To give some Context, We have a scenario where we need to change the projects reference locations per user at different times in development. What usually happens is they will have a different copy of a dll that they are trying to integrate so they update the 'Reference Paths' sections in the projects properties such that it now points to their development directory on their local machine. This is fine because this setting change will be made to a new custom file (ProjectName.vbproj.user) which isn't checked into source control (important) with the following code. Project xmlns=http://schemas.microsoft.com/developer/msbuild/2003; PropertyGroup ReferencePathD:\MyDevArea\/ReferencePath /PropertyGroup /Project This works well as it updates the projects references ignoring the hintpath when the same dll is found in that directory. Now onto Wix, I was most pleased when I saw the Paths tab in the properties page. Updating 'Reference Paths' also made this .user file even though the method of adding them is different. What is my problem is that it does not update the path used for the WixLibrary. The code for the .wixproj is as follows: ItemGroup WixLibrary Include=ReconcilorCore HintPathL:\BuildDrop\Version\Etc\Core.wixlib/HintPath /WixLibrary /ItemGroup So I was hopeful that the Hintpath would be overridden by the user reference path, but it is not the case. So sadly the developers need to modify the .wixproj file when they are doing development which is a bit more complicated and requires the file to be checked out. Is there any way to fix this, know any other way to do it or is it a known bug? 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 number for the Snowden Perth office has changed to +61 8 9213 9213. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] on show dialog is loosing focus for my main screens
When is this dialog spawned? After and before what events? It also seems that your custom actions aren't scheduled and executing at the proper time. No UI should ever be displayed for those CAs, and they should be executed when the progress dialog is displayed. Any machine state-changing CAs should be marked as deferred. If you are using batch scripts - and that is discouraged for several reasons including a lack of logging and debugging, in lieu of either 1) not using custom actions if you don't have to, or 2) writing a DLL CA - use QuietExec CAs provided with WiX that will hide the console window. On Mon, Apr 6, 2009 at 10:07 PM, Hukumchand Shah hukum.s...@gmail.comwrote: Hi All, I am creating some message dialogs and showing them in InstallUISequence as shown below Dialog Id=upgrademsgdlg Width=260 Height=85 Title=[ProductName] [Setup] NoMinimize=yes Control Id=No Type=PushButton X=132 Y=57 Width=56 Height=17 Default=yes Cancel=yes Text=!(loc.CancelDlgNo) Publish Event=EndDialog Value=Exit1/Publish /Control Control Id=Yes Type=PushButton X=72 Y=57 Width=56 Height=17 Text=!(loc.CancelDlgYes) Publish Event=EndDialog Value=Return1/Publish /Control Control Id=Text Type=Text X=48 Y=15 Width=194 Height=30 Text!(loc.upgrademsg)/Text /Control Control Id=Icon Type=Icon X=15 Y=15 Width=24 Height=24 ToolTip=Information icon FixedSize=yes IconSize=32 Text=[InfoIcon] / /Dialog InstallUISequence Show Dialog=upgrademsgdlg Sequence=1398condition/Show /InstallUISequence when this dialog appears and when I press yes button of this dialog then my main screen get lost and some custom actions get executed (like batch files) and finally my finish screen appears. I want to retain my main installation progress screen. How do I do that? What changes I have to make to achive this? Anyone has any idea? I am new to wix. Thank you Regards, Hukum -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Supporting both Full UI and No UI?
msiexec.exe always returns immediately. Pass the same command to start /wait like so and the command will not return until msiexec.exe completes (and it's always a good idea to love, especially when diagnosing issues): start /wait msiexec.exe /i product.msi /qn /l*vx install.log On Tue, Apr 7, 2009 at 6:59 PM, He Shiming heshim...@gmail.com wrote: Hi, I built a setup package with customized WixUI . I'm using a custom version of WixUI_InstallDir mode. And I added a few custom actions including: launch app after setup (WixShellExec), execute a command after installfinalize (CustomAction ExeCommand=...), remember program installation folder (PropertyRegistrySearch. RegistryValue). And the setup package is now running as expected. My problem is how do I convert such a package so that it allows both Full UI install (double clicking the .msi) and No UI install (msiexec /i setup.msi /qn) . Because when I type this command at console, it does nothing. What do I do to convert this package to allow No UI install, and how do I provide answers such as installation folder (provide a default one if it's a new install, or get from registry if upgrading)? Many thanks in advance. Best regards, He Shiming -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] binary dependencies in binary stream
But how, when, and where the CA DLLs is not documented. You should not take advantage of undocumented features. Compiling and linking everything int your CAs as needed is recommended (or, better, don't require CAs during install/maintenance). On Fri, Apr 10, 2009 at 9:52 AM, Wilson, Phil phil.wil...@wonderware.comwrote: You could just install the files to (for example) somewhere in the Temp folder. Make sure the installer component guids are null so that they're not registered or managed by MSI, and then remove them when your code (or your custom action) doesn't need them. Phil Wilson -Original Message- From: Thomas S. Trias [mailto:tomtr...@artizan.com] Sent: Friday, April 10, 2009 9:12 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] binary dependencies in binary stream Is there any good way to deploy a temporary file resource using the File table and standard actions? I know that the scheduling gets tricky, especially since RemoveFiles occurs before InstallFiles. I wouldn't be one to second guess Bob, anyway. :-) It's really more of an academic question. Thomas S. Trias Senior Developer Artizan Internet Services http://www.artizan.com/ Original Message Subject: Re: [WiX-users] binary dependencies in binary stream From: Bob Arnson b...@joyofsetup.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Date: 4/10/2009 6:05 AM div class=moz-text-flowed style=font-family: -moz-fixedLeo ... wrote: How could I include two binaries where one references the other in the binary stream for use as custom actions? There's no built-in support for that; you'd need another custom action to stream out the dependency. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Linker Error when using PlugCollectionInto element (WixVSExtension)
CommonFilesFolder is a standard directory so you don't need to define a specific value, but add a Directory element with that Id like so: Directory Id=TARGETDIR Name=SourceDir Directory Id=CommonFilesFolder Name=Common/ !-- rest of your directories or directory references -- /Directory Are you referencing that directory anywhere else your all of your authoring? On Fri, Apr 10, 2009 at 2:05 PM, Matt Gollob mattgol...@gmail.com wrote: Hello everyone - I'm trying to build a merge module that contains some Help2 documentation that I want to integrate into VS2008. However, I'm getting the following error from Light when I try to build the merge module: C:\delivery\Dev\wix30_public\src\ext\VSExtension\wixlib\HTML_Help_Registration__RTL_X86_---.wxs(4,0): error LGHT0094: Unresolved reference to symbol 'Directory:CommonFilesFolder' in section 'Fragment:'. I've been able to simplify the problem down to the following element in my source file: vs:PlugCollectionInto TargetCollection=MS.VSIPCC.v90 TableOfContents=F_Test.SDKCollection.HxT TargetFeature=Help TargetTableOfContents=FL_vsipcc_hxt_86880_86880_cn_ln/ I'm building this in VS 2008 SP1 using WiX 3.0.5207.0. Can anyone confirm whether I am doing something wrong or if this is a bug somewhere in WiX? Below is the full build output from VS's Output Window and an entire project demonstrating the problem is attached (WixMergeModule1.zip). -- Build started: Project: WixMergeModule1, Configuration: Release x86 -- C:\Program Files\Windows Installer XML v3\bin\candle.exe -dDevEnvDir=C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\\ -dSolutionDir=C:\Projects\Priv\Sandbox\WixMergeModule1\ -dSolutionExt=.sln -dSolutionFileName=WixMergeModule1.sln -dSolutionName=WixMergeModule1 -dSolutionPath=C:\Projects\Priv\Sandbox\WixMergeModule1\WixMergeModule1.sln -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=C:\Projects\Priv\Sandbox\WixMergeModule1\WixMergeModule1\ -dProjectExt=.wixproj -dProjectFileName=WixMergeModule1.wixproj -dProjectName=WixMergeModule1 -dProjectPath=C:\Projects\Priv\Sandbox\WixMergeModule1\WixMergeModule1\WixMergeModule1.wixproj -dTargetDir=C:\Projects\Priv\Sandbox\WixMergeModule1\WixMergeModule1\bin\Release\ -dTargetExt=.msm -dTargetFileName=WixMergeModule1.msm -dTargetName=WixMergeModule1 -dTargetPath=C:\Projects\Priv\Sandbox\WixMergeModule1\WixMergeModule1\bin\Release\WixMergeModule1.msm -out obj\Release\MergeModule.wixobj -arch x86 -ext C:\Program Files\Windows Installer XML v3\bin\WixVSExtension.dll MergeModule.wxs C:\Program Files\Windows Installer XML v3\bin\Light.exe -ext C:\Program Files\Windows Installer XML v3\bin\WixVSExtension.dll -out C:\Projects\Priv\Sandbox\WixMergeModule1\WixMergeModule1\bin\Release\WixMergeModule1.msm -pdbout C:\Projects\Priv\Sandbox\WixMergeModule1\WixMergeModule1\bin\Release\WixMergeModule1.wixpdb obj\Release\MergeModule.wixobj C:\delivery\Dev\wix30_public\src\ext\VSExtension\wixlib\HTML_Help_Registration__RTL_X86_---.wxs(4,0): error LGHT0094: Unresolved reference to symbol 'Directory:CommonFilesFolder' in section 'Fragment:'. Done building project WixMergeModule1.wixproj -- FAILED. Build FAILED. == Build: 0 succeeded or up-to-date, 1 failed, 0 skipped == -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is it allowed to remove all files within a component with a patch?
Generally you should not remove files in a patch, but if you must: within the same component that owns the files remove the File elements and add RemoveFile elements for the same files. You cannot, however, remove the KeyPath file legally. You also cannot remove the component or you will break any parent features. See http://blogs.msdn.com/heaths/archive/2006/01/23/516457.aspx (trackbacks to that post also have some recommended solutions, but our blog server is currently down for maintenance and should be back up later this weekend). On Sat, Apr 25, 2009 at 2:44 AM, luciana istoc istoc_luci...@yahoo.comwrote: Hi, Does Windows Installer allow to remove all the files authored within a component by applying a patch? For example a patch (small update) would like to remove both files from the next component: Component Id=Comp_1 Guid=884C0AD3-4249-41d5-A722-60007DC9402B File Id=file_1.txt Name=file_1.txt KeyPath=yes/ File Id=file_2.txt Name=file_2.txt/ /Component Feature Id=ProductFeature Title=Test feature Level=1 ComponentRef Id=Comp_1 / ComponentRef Id=Comp_2 / /Feature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RemoveFile authored for a patch
What you did is recommended for removing non-keypath files. Please post your entire verbose patch installation log. On Sat, Apr 25, 2009 at 2:37 AM, luciana istoc istoc_luci...@yahoo.comwrote: Hi, I am building a patch (with the torch,pyro method and a separate wxs file that describes Patch and PatchFamily elements) for removing some files from the installation folder and some additional modifications in the existing files. Therefore, I have to use the element RemoveFile. Until now I have experienced the next two possibilities: 1. I add the RemoveFile line in the component below the line describing the file I want to remove (see below an illustration): Component Id=Comp_1 Guid=884C0AD3-4249-41d5-A722-60007DC9402B File Id=file_1.txt Name=file_1.txt KeyPath=yes/ File Id=file_2.txt Name=file_2.txt/ RemoveFile Id=rem_file_2.txt Name=file_2.txt On=both/ /Component In this case everything seems to work ok, the wix project solution build is successful, and the installation also (I checked the log file to see what files were removed and what files were reinstalled). 2. I add the RemoveFile line and I comment the line describing the file I want to be removed (see below an illustration): Component Id=Comp_1 Guid=884C0AD3-4249-41d5-A722-60007DC9402B File Id=file_1.txt Name=file_1.txt KeyPath=yes/ !--File Id=file_2.txt Name=file_2.txt/-- RemoveFile Id=rem_file_2.txt Name=file_2.txt On=both/ /Component In this case the effect is undesired and unacceptable: -at project build I get some warnings from which I deduce that the compiler considers that some files were modified (and therefore will reinstall them with the patch), although these files are exactly the same as in the baseline version! -after the patch installation I check the log file and I see that files that weren't modified at all (compared to the baseline version) were reinstalled. More, if some of these files have been modified by previous patches (patches made to the same baseline version as the current patch, but with a sequence number smaller than the current patch), these modifications are lost, because the files are brought back to the baseline version. Could anybody tell me, please, why do I get this behavior in the second scenario? Or maybe is it not allowed to author a RemoveFile element in such a manner? Also, it would be very useful for me to get a confirmation that the first scenario is correct. Thanks, Luciana -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How To Create Successive Patches That Supersede Previous?
toolset. Subject: Re: [WiX-users] How To Create Successive Patches That SupersedePrevious? I've created patches which do exactly what you're trying to do but from your description I can't pinpoint where you're going wrong. If you could post the .wxs file you're using to create your .pcp file, I or someone else on the list should be able to help point you in the right direction. Cheers, Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Emanuel Masciarelli [mailto:emasciare...@trionworld.com] Sent: 24 April 2009 01:53 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How To Create Successive Patches That SupersedePrevious? I tried looking through the digests on sourceforge but couldn't find a way to search, and didn't see this question answered so I apologize if it's a duplicate. I am trying to create patches for a product that will each be all encompassing of the previous ones, and want anybody at any version to be able to install the latest patch. Following the instructions on the site I can create patches just fine, so I can install 0.3.0.0 then patch from 0.3.0.0 to 0.3.1.0. I created my 0.3.2.0 patch from 0.3.0.0 (to encompass the 0.3.1.0 stuff) and when I apply it it says it cannot as The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. In my PatchFamily tag I have set the version to be the new version in both patches (so 0.3.1.0 and 0.3.2.0), and Supersede=yes for both. Is there something else I'm missing? From my understanding of the documentation the MsiPatchSequence table should have increasing numbers for all my patches and they should supersede each other just fine, but obviously I'm wrong. Any help is appreciated. --Emanuel -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX-users Digest, Vol 35, Issue 107
-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users End of WiX-users Digest, Vol 35, Issue 107 ** -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to suppress the batch file dos prompt in wix?
@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch or different product for an add-in ?
It's better that you use a separate MSI. To determine the correct installation locations, you can use a ComponentSearch to find some component for your other product that determines the installation location, and then use a type 51 custom action (CustomAction Property=TARGETDIR Value=*appsearch property from compsearch* .../) to set the TARGETDIR. Patching new components in can be difficult and doesn't provide you with a separate baseline. What if you need to patch those files? How do you avoid other customers from installing that patch that shouldn't have it? It is applicable, after all. Adding new components to existing features also poses another problem: http://blogs.msdn.com/heaths/archive/2008/02/18/adding-new-components-to-existing-features-installs-the-feature-tree.aspx . Shipping a separate product lets you service only that product. When you have large products or multiple editions, this has the additional of not having to build all those layouts just to patch a small subset. You can have this product show up as a child node if you define ARPSYSTEMCOMPONENT=1 in your add-in's Property table, and for your ARP registry values in the Registry table, write ParentKeyName and ParentDisplayName, where ParentKeyName is the name of the registry key for the product (just the key name itself, as a child of the Uninstall key) and ParentDisplayName is the same name as the product (by default, Windows Installer uses [ProductName] if ARPSYSTEMCOMPONENT is not defined). Note, however, that defining ARP yourself can yield some interesting problems. See http://blogs.msdn.com/heaths/archive/tags/ARPSYSTEMCOMPONENT/default.aspx. On Thu, Apr 30, 2009 at 3:57 AM, Olivier Cochelin ocoche...@notocord.comwrote: Hi all, I am wondering what is the best solution to solve the following problem. I hope the Windows Installer experts wandering to this list will provide interesting input. I want to deliver a main product and a complementary product, the latest being reserved to a limited set of customers. The complementary product is a kind of add-in for the main product, it cannot work if the main product is missing. For commercial reasons, we want these two products to be in different installers (.exe or .msi/.msp). For technical reasons, the complementary product must be bound to a specific version of the main product. I mean if the main product is updated the complementary product must also be updated. So, I would like to obtain the following behavior: - The complementary product installs if and only if the appropriate version of the main product is already installed - When the main product is uninstalled, the complementary product is also automatically uninstalled (if present of course) - The complementary product can be uninstalled alone, the main product remains installed - Finally, it would be nice if, in ARP, the complementary product could appear as a child node of the main product like Windows security updates for instance. What is the best way to do this ? - Create a patch for the main product or - Have another product and manually (don't know how) create the dependencies between main and complementary products. or - Something else I didn't think about Olivier Cochelin Notocord Systems -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching v1.0 with v1.n
WiX patching does support adding new components, but those components have
to be added to features in your products as well. They should also be in new
Fragments.
But if those features are optional features, adding new components to
optional and possibly absent features will cause prompt for source issues
(which will simply fail silent installs):
http://blogs.msdn.com/heaths/archive/2008/02/18/adding-new-components-to-existing-features-installs-the-feature-tree.aspx
.
On Wed, Apr 29, 2009 at 6:57 AM, troy hostetter troy.hostet...@gmail.comwrote:
I am having a hard time determining the best way to handle patching v1.0
with v1.n. I have all my wxs files built for v1.0, and would like to move
forward with v1.n. I have read the WiX doco, which explains the process of
building a patch Using Purely WiX. This process seems to assume v1.n
will
contain a subset of files to be patched in v1.0, but no new files.
For example, the WiX configuration assumes Sample.txt will be in all
versions:
Component Id=SampleComponent
Guid={C28843DA-EF08-41CC-BA75-D2B99D8A1983} DiskId=1 File
Id=SampleFile Name=Sample.txt Source=.\$(var.Version)\Sample.txt /
/Component
However, what if Sample.txt is only in v1.n and all subsequent releases?
Are there any best practices you might recommend?
Regards,
- Troy
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Heath Stewart
Deployment Technologies Team, Microsoft
http://blogs.msdn.com/heaths
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [Wix-users] Pyro and .Net assemblies
For public consumption, we still require the files during bind because we only diff the files (including Binary and Icon objects) then after filtering. For large products this saves a huge amount of time. The file info in the transforms may not always be correct, especially when wixmsts are created from msis (since support was added to diff admin layout msis). On Mon, May 4, 2009 at 7:17 PM, Blair Murri bmu...@microsoft.com wrote: Found a workaround (and I came up with some sort of explanation for it). Rule: If you use WIXPDB files when you call TORCH, you should always pass -sf to PYRO. Reason: In order to generate the .wixpdb files you will pass to torch you must run the binder in light.exe. The binder at that point populates all of the file-related information into the various file-related tables (File, MsiAssemblyName, etc.), unless you suppressed that using the -sa, -sf, or -sh arguments. That data is thus present in the .wixpdb files you pass to torch (to generate your .wixmst file) and doesn't need to be recalculated by the binder when pyro.exe calls it. If you don't pass -sf to pyro.exe, it will recalculate that data, and in the case of the MsiAssemblyName table, will attempt to insert the version row (which will fail, producing the PYRO0130 error, since that row is already present). The transforms in the resulting patch still contain the correct file information (since they were already present in the upgrade MSI/wixpdb file), and the patch works. From: Blair Murri Sent: Monday, May 04, 2009 4:46 PM To: wix-users@lists.sourceforge.net Subject: Pyro and .Net assemblies I'm getting an error PYRO0130 in the table MsiAssemblyName which makes no sense to me, especially since the wixmst file entry for that doesn't seem to match the error message (at least to my mind). Why would modifying a field on a row (when the field is not part of the primary key) generate this error, especially since there are no rows being added? Here is the error message: error PYRO0130 : The primary key 'PlatformApi_Interop_Comp/version' is duplicated in table 'MsiAssemblyName'. Please remove one of the entries or rename a part of the primary key to avoid the collision. And here is the portion from the wixmst for the entire table: table name=MsiAssemblyName xmlns= http://schemas.microsoft.com/wix/2006/objects; - row sectionId=/wix.section.2 sourceLineNumber=e:\enlistments\wlx\main-2\client\contact\setup\msm\ContactMSM.wxs*276 fieldPlatformApi_Interop_Comp/field fieldculture/field fieldneutral/field /row - row sectionId=/wix.section.2 sourceLineNumber=e:\enlistments\wlx\main-2\client\contact\setup\msm\ContactMSM.wxs*276 fieldPlatformApi_Interop_Comp/field fieldname/field fieldLivePlatform.Interop/field /row - row sectionId=/wix.section.2 sourceLineNumber=e:\enlistments\wlx\main-2\client\contact\setup\msm\ContactMSM.wxs*276 fieldPlatformApi_Interop_Comp/field fieldprocessorArchitecture/field fieldMSIL/field /row - row sectionId=/wix.section.2 sourceLineNumber=e:\enlistments\wlx\main-2\client\contact\setup\msm\ContactMSM.wxs*276 fieldPlatformApi_Interop_Comp/field fieldpublicKeyToken/field field8416CC26C44011B1/field /row - row op=modify sectionId=/wix.section.2 sourceLineNumber=e:\enlistments\wlx\main-2\client\contact\setup\msm\ContactMSM.wxs*276 fieldPlatformApi_Interop_Comp/field fieldversion/field field modified=yes15.0.2300.501/field /row /table As you can see, the only operation on that table is to modify just one row, the one that now has a duplicate. However, neither the target wixpdb (or msi) nor the upgrade wixpdb (or msi) contain any other rows (each contains just those five rows). Any ideas? A search of the wix-users mail-list showed just one other possible hit for this issue, an unresolved (on the list) mail from INRO(Robert Inzinger) robert.inzin...@skidata.com from Wed, 29 Oct 2008 14:52:48 +0100 titled [WiX-users] Pyro and .Net Assemblies (which looks to me to probably be the same issue). -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak
Re: [WiX-users] Upgrade Install Location Cascade Lookup
This property is intended to display the primary installation folder in Add/Remove Programs. I'm not sure how it makes anything easier during upgrades, as evident by the problems you're having. But it's just for display. What exactly are you trying to use it for? TARGETDIR is a required property, so an empty string is not supported. You should not be setting TARGETDIR directly using AppSearch, but instead set a different public property and then schedule a type 51 CA (see CustomAction/@Property attribute) to set TARGETDIR condioned on whether that AppSearch was set; otherwise, set it to something different (generally you should always set this explicitly, or at least never install any files directory to TARGETDIR or any child directories that are not otherwise redirected, like ProgramFilesFolder - doing so can lead to your files being installed to the root of the fixed drive with the most free space available). On Thu, May 7, 2009 at 9:04 AM, Chris Snider chris.sni...@wedge.hpc.milwrote: Hi all, I learned today about the ARPINSTALLLOCATION property to make upgrade easier. Since I did not use this in the previous version of the installer, but am adding as a custom task in the new version, I need to update my AppSearch process. I sequenced the AppSearch after FindRelatedProducts to load my PREVIOUSVERSIONFOUND property if the product was already installed. Once I have this value, I can search the uninstall points in the registry for the install location. However, if the value is blank, which it will be for all installations until the new one, I also need to perform the previous method of directory searching for a main file. I am attempting to use this construct, but it does not end up filling the TARGETDIR property when the Registry search returns a blank value; Property Id=TARGETDIR RegistrySearch Id=FindInstallLocation Root=HKLM Key=Software\Microsoft\Windows\CurrentVersion\Uninstall\[PREVIOUSVERSIO NSINSTALLED] Name=InstallLocation Type=directory DirectorySearch Id=targetDirSearch Depth=999 FileSearch Id=targetDirSearch Name=MyFileName.exe / /DirectorySearch /RegistrySearch /Property Ultimately, what I'd like to have happen is search the Registry first. If that fails, then do the much longer search through the DirectorySearch. Finally, I can display the full installation wizard instead of the upgrade version. Is this possible? Thanks, Christopher Bones Snider Software Engineer Warfighter's Edge (WEdge) Institute for Information Technology Applications (IITA) United States Air Force Academy www.wedge.hpc.mil chris.sni...@wedge.hpc.mil mailto:r...@wedge.hpc.mil DSN 333-0654/ COMM 719-333-0654 Yahoo! IM: chris_snider The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code. - Paul Graham -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technologies Team, Microsoft http://blogs.msdn.com/heaths -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to alwyas overwrite GAC assembly in fresh setup
You must keep the assembly version the same, but change the file version. See http://blogs.msdn.com/heaths/archive/2005/06/10/427803.aspx. Heath Stewart Technical Lead Deployment Technologies Group, Microsoft http://blogs.msdn.com/heaths From: Fei Cao Sent: Wednesday, April 11, 2007 12:31 PM To: 'wix-users@lists.sourceforge.net'; Windows Installer Support (MS Internal) Subject: how to alwyas overwrite GAC assembly in fresh setup It looks like if we want to specify an install for GAC assembly dll, we have to use Assembly='.net' in the File element, which will require KeyPath has to be set as yes (otherwise we'll have a build error when running candle.exe). Then this way, if GAC assembly has been left behind, then another fresh install wont overwrite that dll. How can we ensure the GAC assembly can always be overwritten? Below is just an example. Thanks, Fei Component Id='c_AdministrationAssembly' Guid='5FFF9101-F543-4C45-9B1F-624A63D0F037' File Id='f_67EA5751_1A60_49D5_BCE5_97930D86A3E8' DiskId='1' Name='MsUpdAdm.dll' LongName='Microsoft.UpdateServices.Administration.dll' Source='SourceDir\GAC\Microsoft.UpdateServices.Administration.dll' KeyPath='yes' Assembly='.net' AssemblyManifest='f_67EA5751_1A60_49D5_BCE5_97930D86A3E8'/ /Component - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] Problems about running a msi against Vista
1. The NoImpersonate bit only affects deferred custom actions. This
implies you're launching applications from a deferred CA. Immediate CAs
typically after InstallFinalize are best suited for this (like displaying a web
page or something).
2. Signing is really only necessary for the MSI, and that provides the
publisher in the dialog. You can't get rid of the dialog, though, for an MSI
install. You can only prevent this from popping up for patches if you follow
instructions in http://msdn2.microsoft.com/en-us/library/aa372388.aspx.
3. Public properties passed from client (how you invoke your installation
transaction) to the server must be listed in the SecureCustomProperties
property or they will be ignored. See
http://msdn2.microsoft.com/en-us/library/aa371571.aspx for more information.
Heath Stewart
Technical Lead
Deployment Technology Group, Microsoft
http://blogs.msdn.com/heaths
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hao Liu
Sent: Thursday, July 19, 2007 3:54 PM
To: wix-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: [WiX-devs] Problems about running a msi against Vista
I run a msi by using msiexec 4.0 on Vista with UAC ON. And the msi have two
custom actions (a setup dll and a remover dll). Even if my account is
Administrator, it failed to install on Vista though it worked on XP. After I
set the two CA with Impersonate=no as Bob Arnson suggested, they get
elevated, and installation and uninstalling went through well. However, there
are the following issues:
1. When I spawn another process after installation in my setup.dll, the
process actually run as system account context rather than current user context.
2. I signed my custom actions (a setup dll and a remove dll) and the msi as
well. But when I run the msi, I still get the UAC prompt like:
A program needs your permission to continue
Product Name
Company name
Install
Version
Is there any way to prevent the prompt opened?
3. One more issue when I uninstall. I could not pass successfully a public
parameter value pair on Vista. But it works on XP. The log is:
MSI (s) (60:84) [17:46:47:028]: Machine policy value 'AlwaysInstallElevated' is 0
MSI (s) (60:84) [17:46:47:028]: User policy value 'AlwaysInstallElevated' is 0
MSI (s) (60:84) [17:46:47:028]: Using cached product context: machine assigned
for product: FF01F0D58705B3A4EBBC07DB4FF537FC
MSI (s) (60:84) [17:46:47:028]: Product {5D0F10FF-5078-4A3B-BECB-70BDF45F73CF}
is admin assigned: LocalSystem owns the publish key.
MSI (s) (60:84) [17:46:47:028]: Product {5D0F10FF-5078-4A3B-BECB-70BDF45F73CF}
is managed.
MSI (s) (60:84) [17:46:47:028]: Running product
'{5D0F10FF-5078-4A3B-BECB-70BDF45F73CF}' with elevated privileges: Product is
assigned.
MSI (s) (60:84) [17:46:47:028]: Machine policy value 'EnableUserControl' is 0
MSI (s) (60:84) [17:46:47:028]: PROPERTY CHANGE: Adding RestrictedUserControl
property. Its value is '1'.
MSI (s) (60:84) [17:46:47:028]: Ignoring disallowed property REMOVEPARAMS
Thanks a lot,
Hao
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] FileSearch on x64
Have you verified that the component GUID is the same for the 64-bit component? Heath Stewart Technical Lead Deployment Technologies Group, Microsoft http://blogs.msdn.com/heaths From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Gariepy Sent: Monday, July 23, 2007 12:45 PM To: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: [WiX-devs] FileSearch on x64 The following FileSearch element works as expected on x86 machines but it doesn't work on x64 machines, with 64bit SQL, even though the file version of sqlservr.exe appears to be the same. Does FileSearch not support x64? Is there a trick to make it work? Property Id=SQLSERVER ComponentSearch Id=SQLSERVER Guid=42171F06-AFD9-4AD9-956E-9B68326429DE Type=file FileSearch Id=SQLSERVER Name=sqlservr.exe MinVersion=9.0.2047.0 / /ComponentSearch /Property Thanks, Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] FileSearch on x64
ComponentSearch/@Guid is the value of the Component/@Guid you want to search for, known as the Component ID. For both the x86 and x64 SQL products, I recommend you open each MSI and find that file in the File table. Take note of the Component_ column in the File table for sqlserver.exe in each, then find that component in the Component table. Use the value in the ComponentId column for that row. This locates the component based on the component ID. That's what Windows Installer registers for component. The ComponentSearch finds the location of that component. Then your FileSearch checks that the required file (with all your parameters specified) is there and, yes, sets the Property/@Id to the path of that file. Heath Stewart Technical Lead Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths From: Chris Gariepy Sent: Monday, July 23, 2007 1:37 PM To: Heath Stewart; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-devs] FileSearch on x64 Isn't the ComponentSearch Guid value an arbitrary ID in this case? The FileSearch sets the value of the SQLSERVER property based on the file version of sqlservr.exe. This isn't a file we're installing, it's the main SQL runtime which is required to already exist on the box. I tried searching on that guid on an x86 box were the test works and it wasn't found in the registry. Does it have some meaning I'm not familiar with? Chris From: Heath Stewart Sent: Monday, July 23, 2007 1:20 PM To: Chris Gariepy; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-devs] FileSearch on x64 Have you verified that the component GUID is the same for the 64-bit component? Heath Stewart Technical Lead Deployment Technologies Group, Microsoft http://blogs.msdn.com/heaths From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Gariepy Sent: Monday, July 23, 2007 12:45 PM To: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: [WiX-devs] FileSearch on x64 The following FileSearch element works as expected on x86 machines but it doesn't work on x64 machines, with 64bit SQL, even though the file version of sqlservr.exe appears to be the same. Does FileSearch not support x64? Is there a trick to make it work? Property Id=SQLSERVER ComponentSearch Id=SQLSERVER Guid=42171F06-AFD9-4AD9-956E-9B68326429DE Type=file FileSearch Id=SQLSERVER Name=sqlservr.exe MinVersion=9.0.2047.0 / /ComponentSearch /Property Thanks, Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] certificates and wix
Did you author the property? If you look at the Property element you can specify Secure=yes on it. You really shouldn't be taking insecure data like this to be installed in an elevated process, though. This is very dangerous. Heath Stewart Technical Lead Deployment Technologies Group, Microsoft http://blogs.msdn.com/heaths From: Gabriel Ghizila Sent: Tuesday, August 14, 2007 6:53 PM To: Heath Stewart Subject: RE: certificates and wix On wix-users I do not get answers too easy (some times I never get answers) and I hoped I can get a fix for today. I am specifying below the value I give to ROOTCERTNAME. I do not see any reference to SecureCustomProperties in the verbose log (I guess you refer to /lv parameter to msiexec) so I assume it does not get there. Thanks for help ;-G From: Heath Stewart Sent: Tuesday, August 14, 2007 6:41 PM To: Gabriel Ghizila Subject: RE: certificates and wix BCC'ing SetupSup. Questions about WiX should be directed to wix-users. More information can be found on http://wix. And not just because this is a WiX authoring question but also because the way certificates are installed uses a custom action written by/for WiX. Are you defining ROOTCERTNAME? Have you checked in a verbose log to make sure it is passed to the server. This property would have to be in the SecureCustomProperties property to be passed from the client (msiexec.exe on the command line, for example) to the server (the Windows Installer service that does the install work). Heath Stewart Technical Lead Deployment Technologies Group, Microsoft http://blogs.msdn.com/heaths From: Gabriel Ghizila Sent: Tuesday, August 14, 2007 6:31 PM To: Windows Installer Support (MS Internal) Subject: certificates and wix I am trying to use wix 2.0 to install a certificate using wix file. The code I have is not installing the external cer file whatever I do. Here is how my component looks like: Directory Id=TARGETDIR Name=SourceDir ... Component Id=RootCertificateComponent Guid=6ACC325C-7998-4890-99C2-14D9F03EE6C5 Condition ROOTCERTNAME /Condition Certificate Id=RootCertificate Name=[ROOTCERTNAME] Request=no Overwrite=yes CertificatePath=[ROOTCERTPATH] StoreLocation=localMachine StoreName=root / /Component ... /Directory Feature ... ... ComponentRef Id=RootCertificateComponent / ... Other componenets that get installed /Feature ROOTCERTPATH=c:\PATH\file.cer and ROOTCERTNAME=SomeName The certificate does not get installed in Certificates (Local Computer) - Trusted Root Certificate Authorities - Certificates or anywhere else but no error seems to be generated either. I guess I have trouble understanding what are the Name and CertificatePath supposed to do. The CertificatePath seems to be the file name with full path of the certificate file. The Name seems to be rather arbitrary. I have tried also with the Name as file name (file.cer) and CertificatePath as strictly the path (c:\PATH\). I use v2.0.5508.0 of wix and I am trying to install on Win2k3 server. Upgrading to 2.0.5606 I always get invalid parameter InstallCertificates: Error 0x80070057: Invalid Certificate.Attributes. InstallCertificates: Error 0x80070057: Failed to resolve certificate: RootCertificate which is a big step forward but I still can't figure out what is expected for the two. Thanks ;-G - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting Estimated Size and Version
Setting ARPSYSTEMCOMPONENT can make servicing very difficult. Read http://blogs.msdn.com/heaths/archive/tags/ARPSYSTEMCOMPONENT/default.aspx for a lot of the problems you'll encounter and some tips to work around them. To set the version that shows up in ARP if you are managing it yourself, set DisplayVersion (REG_SZ). Rob Mensching wrote: 1. Sure, hacks are always a good idea. 2. Oh, if you set ARPSYSTEMCOMPONENT then you are on your own. I haven't dug into the Uninstall key enough to know if/how to set the version. It is entirely possible that it is a MSI only thing in ARP. Ahn Ahn Liu wrote: Thanks for the reply. 1. Too bad about not being able to control it. Since our chainer just calls a bunch of other packages and doesn't actually install anything itself the size shown is only 7.6MB when in reality, it's over 3GB! Maybe I'll check with the Shell team to see if there's any hack around it. 2. I set product/@Version to 1.0.0.0 but the arp entry still shows it as blank... I'm setting ARPSYSTEMCOMPONENT to 1, so I imagine that's why it's not pulling the version from product/@version. I also set the windows\currentversion\uninstall\version and productversion field to 1.0.0.0 but that unfortunately does change the arp version field either. Any other ideas on this one? Thanks, Ahn AHn -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 11:13 PM To: Ahn Ahn Liu Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Setting Estimated Size and Version 1. ARPSIZE is set magically by ARP. There is no real way to control it. Raymond Chen (Master of all things Shell) had a fun blog entry about how ARP calculated the size it displayed there. The fact that it took him a couple paragraphs is telling. 2. AFAIK, the ARP Version is controlled by the Product/@Version (ProductVersion in MSI speak). PS: In case you didn't know, ARP is the Shell team's fault not the Windows Installer team's fault. Ahn Ahn Liu wrote: I was wondering if it was possible to set the size and version that shows up for a given program in ARP when I set ARPSYSTEMCOMPONENT to 1. For size, it seems like setting ARPSIZE or EstimatedSize has no effect. I'm also unsure how to set the Version. Does anybody have an idea? Thanks! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Token replacement in configuration files
Not currently, no. If you choose to develop one, be sure to reset the
modification timestamp back to the creation timestamp (or set the
creation timestamp to the modification timestamp) or you will not be
able to replace that file by default again since MSI default file
versioning rules won't replace modified files (even if a CA modified it,
which Windows Installer wouldn't know).
Mooney, Stephen wrote:
Hi,
I have a configuration file in which I need to fill in some values at
install time. Eg:
plugins:logging:output = ${LOGS_DIR}/log.txt;
Is token replacement possible in WiX / msi? Is is possible to replace
${LOGS_DIR} with a value natively in wix / msi?
Thanks,
Stephen Mooney
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Heath Stewart
Deployment Technology Group, Microsoft
http://blogs.msdn.com/heaths
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does MSI require JRE?
If you notice this for a particular product, that product may have a dependency on the JRE. But in general, no, Microsoft Windows Installer does not depend on the Sun Java Runtime Environment. Anidil wrote: I noticed when I initially tested MSI on a machine I was asked to install a JRE . I have not experienced this since and am wondering if there is any chance that the installer is dependent on a Jave runtme environment..please clarify. -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] heat.exe -scom produces incorrect regasm fragments for COM interop ?
What version of WiX are you using? The RegistryHarvester should be
handling empty leaf keys, but it may not have always been this way.
Looking at RegistrationServices (the class that both WiX and regasm.exe
use to register assemblies) Implemented Categories seems to be the
only empty key.
Jantzen, Andrej wrote:
Hello,
I tried to use heat.exe
heat.exe file -scom MyDotNetCOM.dll -out MyDotNetCOM.wxs
to generate a WiX fragment equivalent to the command
regasm MyDotNetCOM.dll /tlb
and noted that compared with execution of regasm command some things are
missing/suspect:
- the key HKCR\CLSID\{--SomeClassUUID--}\Implemented
Categories\{62C8FE65-4EBB-45E7-B440-6E39B2CDBF29}
is missing for all coclasses in my DLL (this entry marks coclasses
implemented by .NET assemblies)
- but the key
RegistryValue Root=HKCR Key=Component
Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29} Name=0 Value=.NET
Category Type=string Action=write /
is created, although, in my opinion, this is a global key managed by the
.NET framework.
Is this behavour correct?
Regards,
Andrej Jantzen
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Heath Stewart
Deployment Technology Group, Microsoft
http://blogs.msdn.com/heaths
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Need help to check if a file exists in the installation folder
Path should be a directory. Use INSTALLDIR without brackets (which is a property). You don't need a custom action. Justin Zhen Tu wrote: Hi there, I am having problem with my WIX installer and I wonder if there anyone can help me out. The problem is I need to check if this file “localappsetting.config” exists in the installation folder, copy a new file if it doesn’t exist otherwise ignore. Below is my code and it does work: Property Id=FILEEXISTS DirectorySearch Id=CheckFileDir Path=[INSTALLDIR] Depth=0 FileSearch Id=CheckFile Name=LocalAppSettings.config / /DirectorySearch /Property Feature Id='LocalAppSettingsTemplate' Level='1' ComponentRef Id='C_LocalAppSettings' / Condition Level=0FILEEXISTS/Condition /Feature I have read a post here said I need to schedule a Custom Action and I wonder if someone can point me an example on how to do it. Many thanks. Jusitn - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Design recommendations and best practice
One thing to consider is making it granular such that if you later patch you can patch more granular resources. If you refer to one Component, for example, everything in that fragment is pulled in. So put each component in a separate fragment. Group custom actions and their binary (if binary CAs) into separate fragments. Even put the ProductVersion property in a separate fragment so that you can use author a patch family to update the ProductVersion or not (constituting a minor upgrade patch if ProductVersion changes). Stas Klyachkovsky wrote: Hi there, I’ve decompiled my IS MSI and now I have one big .wxs file, which I want to fragment. Before I start, I want to gather WiX design best practice. Could somebody share or recommend any resources? Thanks, Stas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MultiPart Installer
You can condition your WiX source based on properties to pass into candle.exe. But because the product composition would be different, you should use different ProductCodes. This is important if you intend to patch the product later, as you don't want a single, all-inclusive patch to add everything back in if you don't want it, and there would otherwise be no other way to target a specific product with a specific patch - all traits that patch transform target would be exactly the same. Using different ProductCodes also avoids Windows Installer picking the wrong MSI out of the Installer cache and using that instead of the actual source MSI (if installing two different compositions on the same machine). nils_gate wrote: I am trying to create an installer, which has 4 components. In QC Version, I want to include all the 4 components. While in Final release, I want to include 1 of 4 components based on requirement. I can acheive this using Conditional Installation of a particular feature at installation time. But, in this case I have to include all the components into Installer Database. I want to conditionally include only required component into Installer Databse. I suppose using EmbeddedChainer, I can do this. Have any one done any hands on it? Please help Me N!ls -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall complete dialog
If you let Windows Installer handle ARP (actually, the ARP control panel queries MSI for information) then it isn't possible. ARP by default passes /qb+, IIRC, which will show a complete dialog but nothing you can control. You only can control full UI which ARP doesn't allow you to do by default. the only alternative is to set ARPSYSTEMCOMPONENT, but this can be very problematic especially if you plan to patch your product. See http://blogs.msdn.com/heaths/archive/tags/ARPSYSTEMCOMPONENT/default.aspx. Anidil wrote: Can anybody give an insight on creating an uninstall complete dialog after the application get uninstalled? -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to set Title in Summary Information Stream
It is hard-coded in Compiler.cs. fgc wrote: Hi all, I'm using WiX 2.0.5325.0 and have the following question: Is it possible to set the Title attribute in the msi Summary Information Stream? So far I have not found a way to do this. It works fine with the Subject, Author, Keywords and Comments. But when I open the summary information of a msi/msm created with WiX 2.0.5325.0 Title is always set to Installation Database. The Package tag does not seem to offer this... Regards, ACKH -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiXSqlExtension issue on Vista with UAC
Looks like the custom actions aren't attributed with Impersonate=no. Please file a bug on http://sf.net/projects/wix. Also, that is an older WiX version. When fixed you'll need to download updates from http://wix.sf.net/releases. Sajo Jacob wrote: I am using WiX 3.0.29.25 http://3.0.29.25, I am suspecting that the custom actions in WiXSqlExtension: CreateDatabase, DropDatabase, ExecuteSQLStrings and RollbackExecuteStrings are not getting deferred by default. When I attempt to uninstall the product from Vista with UAC turned on, the installer complains about not having permissions to remove the mdf specifically. I attempted the uninstall from an elevated command prompt and the uninstall completed successfully. Is there a solution to this? Jacob - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Nested msis
Nested installs are deprecated. Instead, create a new feature for each group of tools, and author the tool executables into separate components. Depending on the feature selection, the components will be installed accordingly. Martin MacPherson wrote: I am looking to create an installer that installs a number of tools each of which is an msi. I would like to make each a 'feature' so that the end user can choose which tools they wish to install. Has anyone got an tips for doing this? Can I use a customaction for each that is only executed if the end user chooses to install the feature. Any samples xml files would be greatly appreciated!! I found this article (http://support.microsoft.com/kb/306439) but am not sure whether a) this can be setup using wix b) there is an easier way? Thanks in advance, Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] question to Assembly=.net
App isolation doesn't really require the MsiAssembly* table values for managed assemblies (it does for native), but the additional benefit in WiX is that you can access bind variables for that assembly as documented in wix.chm. fgc wrote: Hi all, So far I know that setting the Assembly=.net attribute installs my assembly into the Global Assembly Cache. But why should I specify AssemblyApplication in addition to Assembly=.net? My understanding is that if I specify both attributes I end up with an installer that contains an MsiAssembly / MsiAssemblyName table and installs the assemblies into my installation directory structure, not into the GAC. Therefore the information in these two tables is not really required. Is there any special use case where it is recommended to do this? So far I treat all assemblies that are not installed into the GAC like any other file. Does it ever make sense to treat .NET assemblies different if they are not installed into the GAC? Thanks! -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LGHT0216 0x64D
Are you setting the minimum version as 310 or 301? It should be 301 because the version is 3.01, so 3 * 100 + 1 = 301. The documentation in wix.chm was incorrect for a time, but should be fixed in more recent builds. Zenko Klapko Jr. wrote: Hi, I've recently upgraded to Wix 3.0 and am having difficulty with light. Google results and the users mailing list confirm that I'm not alone and usually there is a quick fix to solve the problem (permissions, start a service, etc.) The suppress MSI/MSM validation works as a temporary fix but there must be a better solution. The full error message is: light.exe: error LGHT0216: An unexpected Win32 exception with error code 0x64D occured: This installation package cannot be installed by the Windows Installer Service. You must install a Windows service pack that contains a newer version of the Windows Installer Service. I'm an Administrator of my machine and the Windows Installer Service is currently turned to Automatic using the Local System account. Any suggestions for fixing the error? -Zenko -- I would rather be exposed to the inconveniences attending too much liberty than to those attending too small a degree of it. - Thomas Jefferson - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing .NET assemblies in GAC
The File element is necessary, but primarily serves as the source. Windows Installer delegates to fusion to install the assembly, and fusion does not allow for any other files that are not part of the assembly. This is the source of the error. If you want to have a copy of the file elsewhere (like for binding in VS) then you need to have a separate component and File element. If the @Source attribute points to the same file, more recent versions of WiX will only store one file in a cabinet (assuming they're in the same Media, of course) instead of storing multiple files. ArunKumar ArcotVijayaKumar wrote: 1. Does the component for installing a .net assembly in to GAC, should contain only the File element that places the assembly in to the GAC ? If I place some other File elements, like the corresponding XML files, Im getting an Error 1935. HRESULT: 0x80131043. It is my understanding that Wix/MSI assumes the other components to be part of assembly and tries to put them in GAC, and so the error. But why would wix/msi do this, thought there is no assembly manifest specified in the script ? 2. By having only the File element placing the assembly in to GAC in a component , I do succeed placing the assembly in GAC, but I do not see the assembly in the windows directory. Wix/Msi deletes the directory and assembly after placing them in the GAC. How will you place an assembly both in the directory as well as GAC ? 3.What is the use of AssemblyApplication attribute on File Element ? It is only as good as not specifying Assembly=.net attribute. 4. I have an .net assembly and corresponding xml file, that needs to be dropped inside a windows directory, and the assembly to be placed in GAC. My understanding was to do all these three inside a Component, as I consider them as single unit of operation.. Fragment DirectoryRef Id= v1.0 Component Id=Communication Guid =E176CE6C-B4E8-4EB1-8A3C-044F4A834CEC File Id =MyAssembly_GAC Assembly=.net KeyPath =yes Name =MyAssembly.dll Source =.\source\MyAssembly.dll/File File Id =MyAssembly.XML Name =MyAssembly.XML Source =.\source\MyAssembly.XML/File /Component /DirectoryRef /Fragment Apparently this wouldn’t work , give me an Error 1935. HRESULT: 0x80131043 , so what is the proffered or standard way of doing this ? I need the assembly both in a directory and GAC for compile and runtime references. Thanks for the help in advance. _*thanks *_* * *Arun* - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
