Re: [WiX-users] New file not installed
Sounds like you have sequenced RemoveExistingProducts towards the end of the execute sequence. I followed the tutorial InstallExecuteSequence RemoveExistingProducts After=InstallInitialize / /InstallExecuteSequence http://wix.tramontana.co.hu/tutorial/upgrades-and-modularization/replacing -ourselves Kurt -Original Message- From: jjbean [mailto:jonks2...@yahoo.co.uk] Sent: Wednesday, August 17, 2011 4:24 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] New file not installed Sounds like you have sequenced RemoveExistingProducts towards the end of the execute sequence. Correct? What happens if you sequence it early in the sequence so uninstall happens first? (that _should_ solve the problem) Is this new component in a feature whose state is not being migrated correctly by MigrateFeatureStates standard action? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/New-file-not -installed-tp6696061p6697454.html Sent from the wix-users mailing list archive at Nabble.com. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Undefined preprocessor variable error message - how to get preprocessor variables working?
If you add a reference to your WixExample01 project then you can use $(var.WixExample01.TargetFileName),etc throughout your WiX project -Original Message- From: Brad Smith [mailto:brads...@tpg.com.au] Sent: Thursday, August 18, 2011 6:38 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Undefined preprocessor variable error message - how to get preprocessor variables working? Hi I'm new to WIX so bear with me with this simple question. J Using VS2010 Votive, .NET 4, Wix 3.5 I'm in VS 2010 and I created a simple WPF project. Then I created a Wix project (in the same solution), and added a reference to my WPF project in my Wix project. All is good. But the pre-processor statements don't seem to resolve. For example the following line fails: File Id=WixExample01.exe Name=$(var.MySetup.TargetFileName) Source=$(var.MySetup.TargetPath) DiskId=1 KeyPath=yes / .however if I hard-code the path, it will build and work: File Id=WixExample01.exe Name=WixExample01.exe Source=..\..\..\WixExample01\bin\debug\WixExample01.exe DiskId=1 KeyPath=yes / How can I get the relative folders and filenames working? I read the documentation, but cannot seem to see what I'm doing wrong? Brad. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New file not installed
thank you for the instruction unfortunately this did not fix my problem Kurt -Original Message- From: Tobias S [mailto:tobias.s1...@gmail.com] Sent: Thursday, August 18, 2011 7:07 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed see http://wix.sourceforge.net/manual-wix3/wix_xsd_upgradeversion.htm for description of UpgradeVersion Element. Default for MigrateFeatures is yes so my recommendation is to overwrite it. At first glance you should do it in the UpgradeVersion element where you do the major upgrade: UpgradeVersion Minimum=5.3.0 IncludeMinimum=yes Maximum=$(var.BGProductVersion) IncludeMaximum=no Language=1033 Property=UPGRADEFOUND MigrateFeatures=no / btw: OnlyDetect=yes You are normally using this construct for downgrade prevention meaning when a newer version of product is already installed on system 2011/8/18 Kurt Jensen kurt.jen...@us.ophiropt.com: MigrateFeatures=no I searched WiX and MSDN for documentation and an example. -please- explain how to '...set MigrateFeatures=no...' Kurt -Original Message- From: Tobias S [mailto:tobias.s1...@gmail.com] Sent: Thursday, August 18, 2011 3:15 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed sorry, should be MigrateFeatures=no 2011/8/18 Tobias S tobias.s1...@gmail.com: Is this new component in a feature whose state is not being migrated correctly by MigrateFeatureStates standard action? Try to set MigrateFeatureState=no -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New file not installed
Interesting clue. The GUID and component are being created on-the-fly by
heat, maybe there is a problem. I will look into it.
-Original Message-
From: jjbean [mailto:jonks2...@yahoo.co.uk]
Sent: Thursday, August 18, 2011 1:42 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] New file not installed
Here's a clue:
MSI (c) (CC:18) [10:47:26:095]: Disallowing installation of component:
{CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3} since the same component with
higher versioned keyfile exists
...
...
MSI (s) (EC:18) [10:48:26:172]: Executing op:
ComponentRegister(ComponentId={CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3},KeyPa
th=C:\Program Files\Spiricon\BeamGage
Standard\Spiricon.Source.Gevicam.UI.dll,State=3,,Disk=1,SharedDllRefCount=
2,BinaryType=0)
SharedDllRefCount is 2, and this is a new dll? You did say that in an
earlier post didn't you?
The new dll should be in a new component with a unique GUID.
The log reads (although I'm probably not 100% accurate) as if you may have
reused an existing wix component to home a new dll. If this is the case,
do
not do this.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/New-file-not
-installed-tp6696061p6700572.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New file not installed
Thanks all. I missed the Disallowing installation of component. That
lead to finding where I had messed up.
Thanks again!
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, August 18, 2011 2:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] New file not installed
Spiricon.Source.Gevicam.UI.dll is not installed; there are a number of
things wrong here:
=
MSI (c) (CC:18) [10:47:26:095]: Disallowing installation of
component:{CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3} since the same component
with higher versioned keyfile exists
MSI (s) (EC:E8) [10:48:21:859]: Executing
op:FileRemove(,FileName=Spiricon.Source.Gevicam.UI.dll,,ComponentId={39177
13E-C01A-431E-A832-8E6F261CDBCE})
MSI (s) (EC:18) [10:48:26:172]: Executing
op:ComponentRegister(ComponentId={CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3},
KeyPath=C:\Program Files\Spiricon\BeamGage
Standard\Spiricon.Source.Gevicam.UI.dll,
=
The first and last log entries are saying that a file with the same
component id as Spiricon.Source.Gevicam.UI.dll is already installed with a
higher version , so it won't install it.
The middle log entry says you're removing Spiricon.Source.Gevicam.UI.dll,
and note that it has a different component ID.
It looks like you may have a file versioning issue because Windows is
deciding not to install the new one because a higher versioned one already
exists. However you also broke the sharing rules somehow because the two
Spiricon.Source.Gevicam.UI.dlls (in the old and the new inbstall) have
different component ids.
The story seems to be I'm not installing it because there's a higher
version already on the system and Nobody's using this Component guid any
more so I'm going to remove it
Phil Wilson
949-639-1680
-Original Message-
From: jjbean [mailto:jonks2...@yahoo.co.uk]
Sent: Thursday, August 18, 2011 12:42 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] New file not installed
Here's a clue:
MSI (c) (CC:18) [10:47:26:095]: Disallowing installation of component:
{CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3} since the same component with
higher versioned keyfile exists
...
...
MSI (s) (EC:18) [10:48:26:172]: Executing op:
ComponentRegister(ComponentId={CA4F7916-B9A9-5D6E-BD7A-98EFFC15AAA3},KeyPa
th=C:\Program Files\Spiricon\BeamGage
Standard\Spiricon.Source.Gevicam.UI.dll,State=3,,Disk=1,SharedDllRefCount=
2,BinaryType=0)
SharedDllRefCount is 2, and this is a new dll? You did say that in an
earlier post didn't you?
The new dll should be in a new component with a unique GUID.
The log reads (although I'm probably not 100% accurate) as if you may have
reused an existing wix component to home a new dll. If this is the case,
do
not do this.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/New-file-not
-installed-tp6696061p6700572.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
*** Confidentiality Notice: This e-mail, including any associated or
attached files, is intended solely for the individual or entity to which
it is addressed. This e-mail is confidential and may well also be legally
privileged. If you have received it in error, you are on notice of its
status. Please notify the sender immediately by reply e-mail and then
delete this message from your system. Please do not copy it or use it for
any purposes, or disclose its contents to any other person. This email
comes from a division of the Invensys Group, owned by Invensys plc, which
is a company registered in England and Wales with its registered office at
3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number
166023). For a list of European legal entities within the Invensys Group,
please go to
http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=
77.
You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail
recept...@invensys.com. This e-mail and any attachments thereto may be
subject to the terms of any agreements between Invensys (and/or its
subsidiaries and affiliates) and the recipient (and/or its subsidiaries
and affiliates).
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
[WiX-users] New file not installed
(not sure of exact terminology here since WiX is a part time task, please bear with me…) Have setup our installations to do an upgrade from version to version as follows: Upgrade Id=$(var.UpgradeCode) UpgradeVersion Minimum=$(var.BGProductVersion) IncludeMinimum=no OnlyDetect=yes Language=1033 Property=NEWPRODUCTFOUND / UpgradeVersion Minimum=5.3.0 IncludeMinimum=yes Maximum=$(var.BGProductVersion) IncludeMaximum=no Language=1033 Property=UPGRADEFOUND / /Upgrade In upgrading our software from v5.5 to v5.6 we are adding four new files. Three of the new files are installed, one of the files is not. In the log I see two RemoveFiles for two of the files, one of which is the missing file. Later on I see references to all four files – “no binary patches”, “ComponentRegister”. Nothing that singles out the missing file. Any ideas what I am missing here? Kurt Jensen Senior Software Engineer Ophir-Spiricon LLC The True Measure of Laser Performance™ -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New file not installed
somehow difficult to describe with few background information. what information do you need? Maybe take the Tramontana tutorial as starting point: yes, I am following the tutorial Are you handling the whole installer as major upgrade ? yes Did any of the assembly versions decrease ? this is a file that did not exist in the previous installation. there is no previous version. Kurt -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New file not installed
OnlyDetect=yes ??? You might also check a clean install to see if all four files get installed. yes, a clean install works. Do these files contain Version information yes, all files have strong names Is each file in its own Component? yes Kurt -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Wednesday, August 17, 2011 1:51 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed I'm used to Major upgrades removing the previous release(s) so only the newest major version shows in Add/Remove Programs. But, that probably won't work if you have OnlyDetect=yes. And maybe that's not what you want to do. You might also check a clean install to see if all four files get installed. If it doesn't work on a clean install then that's probably the first place to take a look. I'd suppose that is working, just an idea. Do these files contain Version information or are they version-less type of files? Is each file in its own Component? Just some thinking points. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Wednesday, August 17, 2011 12:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed somehow difficult to describe with few background information. what information do you need? Maybe take the Tramontana tutorial as starting point: yes, I am following the tutorial Are you handling the whole installer as major upgrade ? yes Did any of the assembly versions decrease ? this is a file that did not exist in the previous installation. there is no previous version. Kurt -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New file not installed
The OnlyDetect=yes... ok, thanks. this could bite us... and, no, this is not possible. the file does not exist in the earlier version so it cannot be in use. Are these GAC'ed or WinSxS'ed files? no what is so weird is that 3 of the new files install just fine, while this one file does not. and there is nothing in the log that indicates anything special or different about this one file. it is listed in the same way and along with the other three. -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Wednesday, August 17, 2011 3:06 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed I had a recent situation where a window with no title had the file in use that I was trying to replace. And the developers on that project hadn't changed the version so it went like this. 1. MSI detects file in use so schedules a reboot for that to be deleted. 2. MSI does a version check of the file and sees it's the same so decides it doesn't need to replace anything 3. MSI reboots system and deletes file from step #1 - resulting in no file The OnlyDetect=yes says to keep the product it is looking for. OnlyDetect=no says to not only detect but also remove the prior version(s). Are these GAC'ed or WinSxS'ed files? Have their versions all changed? If not this article might explain it. http://blogs.msdn.com/b/astebner/archive/2007/02/08/assemblies-may-be-mi ssing-from-the-gac-or-winsxs-cache-after-an-msi-major-upgrade.aspx -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Wednesday, August 17, 2011 1:20 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed OnlyDetect=yes ??? You might also check a clean install to see if all four files get installed. yes, a clean install works. Do these files contain Version information yes, all files have strong names Is each file in its own Component? yes Kurt -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Wednesday, August 17, 2011 1:51 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed I'm used to Major upgrades removing the previous release(s) so only the newest major version shows in Add/Remove Programs. But, that probably won't work if you have OnlyDetect=yes. And maybe that's not what you want to do. You might also check a clean install to see if all four files get installed. If it doesn't work on a clean install then that's probably the first place to take a look. I'd suppose that is working, just an idea. Do these files contain Version information or are they version-less type of files? Is each file in its own Component? Just some thinking points. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Wednesday, August 17, 2011 12:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] New file not installed somehow difficult to describe with few background information. what information do you need? Maybe take the Tramontana tutorial as starting point: yes, I am following the tutorial Are you handling the whole installer as major upgrade ? yes Did any of the assembly versions decrease ? this is a file that did not exist in the previous installation. there is no previous version. Kurt -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Publishing to GAC
sorry but did we run out of ideas? you say There's not really a lot of info... what info do you need? please ask. if I knew what info was pertinent then I might still be able to look for a solution. I searched bugs but could not find any related. I searched the web but could not find any related. searched and read extensively before posting the original question. been on this 3 days with no solution in sight. maybe someone remembers some issue or bug that relates but is titled differently. is there someone I can pay to help me solve this problem? I don't know where else to look. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Tuesday, May 10, 2011 3:25 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Publishing to GAC yes, two components with different guids and different directories as outlined in the suggested article and follow on articles - I read them all I will look closer from some aberration in the log file. guid= is just to make it more readable... there is a real guid in the actual code how do I copy and display MsiAssembly table of the MSI file for the assembly? here is what I see... Component_ = Spiricon.Interfaces.ConsoleService Feature_ = ProductgFeature File_Manifest = File_Application = Attribute = 0 Kurt -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Tuesday, May 10, 2011 3:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC There's not really a lot of info, but there are few things to look for. There won't be an error in the MSI log if Windows thinks it's doing the right thing, so don't just look for error. There might be entries about diallowing installation of component . that are relevant. If you're installing the file locally and also to the GAC you have two components with different guids, and different directories correct? Why have you got guid= in your component? I'm not quite sure of the full effect of this on assemblies, but this means that Windows Installer won't register the component, so it's not clear to me exactly what you'd see in the log for that. It would also make sense for you to assign guids to those components so that you can actually search the log and see what Windows has to say about them. Exactly what is the MsiAssembly table of the MSI file for the assembly? If it's going into the GAC there must be an entry for the assembly with a null File_Application column. Phil Wilson -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Tuesday, May 10, 2011 1:31 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC Just testing clean install for now -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Tuesday, May 10, 2011 2:27 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC I might have missed but does this happen during a clean install, upgrade or both? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Tuesday, May 10, 2011 1:05 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC I remember reading about that. double checked, the entry in MsiAssemblyName has a version we are at a loss as to how to track down the problem. there are no errors. any ideas? -Original Message- From: Jacques Eloff [mailto:repst...@gmail.com] Sent: Tuesday, May 10, 2011 12:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC Ahh, I found that when moving from WiX 2.0 to 3.0/3.5, the assembly file version wasn't written to the MsiAssemblyName table and it caused problems for us during upgrades. The solution in that case was just to add the -fv switch to Light, but that only solves upgrade issues. On Tue, May 10, 2011 at 8:41 AM, Kurt Jensen kurt.jen...@us.ophiropt.comwrote: yes, we set the Assembly=.net otherwise we would not get the log entry listing our assembly. the assembly is properly listed in the MsiAssembly table with attribute=0 we are converting a vs2008/wix3.0 project to vs2010/wix3.5. in the wix3.0 project we only install it to the GAC. in the new wix3.5 we install it both local and GAC. the source code for installing to the GAC is identical in both projects. DirectoryRef Id=CONSOLESERVICEDIRECTORY Component Id=Spiricon.Interfaces.ConsoleService Guid= File Source=$(var.Spiricon.Interfaces.ConsoleService.TargetPath) Assembly=.net KeyPath=yes / /Component /DirectoryRef note that CONSOLESERVICEDIRECTORY is never actually created Make sure that the assembly is signed. we are using strong naming but not code signing. same as in the wix3.0 project. surely we would see an entry in the log if there was a problem
Re: [WiX-users] Publishing to GAC
ok, here it is trimmed down to its essence. I created a new project, enabled the default component, added a dummy file, then added my GAC component. on running the MSI, Spiricon.Interfaces.ConsoleService.dll is not in the GAC ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=4dd987d3-2e96-4eeb-892a-bb016fe0905a Name=SetupProject1 Language=1033 Version=1.0.0.0 Manufacturer=SetupProject1 UpgradeCode=a9f3d24a-59f8-47f6-8efe-969980b94136 Package InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=media1.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLLOCATION Name=SetupProject1 !-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -- Component Id=ProductComponent Guid=9e33d5df-e36a-4a40-844b-bda6688801b0 File Source=$(var.ProjectDir)OSIBanner.JPG KeyPath=yes / !-- TODO: Insert files, registry keys, and other resources here. -- /Component Component Id=Spiricon.Interfaces.ConsoleService Guid=F23AAD89-8D5F-46c1-8792-C7988BEF6212 File Source=$(var.TargetDir)\Spiricon.Interfaces.ConsoleService.dll Assembly=.net KeyPath=yes / /Component /Directory /Directory /Directory Feature Id=ProductFeature Title=SetupProject1 Level=1 !-- TODO: Remove the comments around this ComponentRef element and the Component above in order to add resources to this installer. -- ComponentRef Id=ProductComponent / ComponentRef Id=Spiricon.Interfaces.ConsoleService / !-- Note: The following ComponentGroupRef is required to pull in generated authoring from project references. -- ComponentGroupRef Id=Product.Generated / /Feature /Product /Wix -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Wednesday, May 11, 2011 6:15 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Publishing to GAC sorry but did we run out of ideas? you say There's not really a lot of info... what info do you need? please ask. if I knew what info was pertinent then I might still be able to look for a solution. I searched bugs but could not find any related. I searched the web but could not find any related. searched and read extensively before posting the original question. been on this 3 days with no solution in sight. maybe someone remembers some issue or bug that relates but is titled differently. is there someone I can pay to help me solve this problem? I don't know where else to look. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Tuesday, May 10, 2011 3:25 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Publishing to GAC yes, two components with different guids and different directories as outlined in the suggested article and follow on articles - I read them all I will look closer from some aberration in the log file. guid= is just to make it more readable... there is a real guid in the actual code how do I copy and display MsiAssembly table of the MSI file for the assembly? here is what I see... Component_ = Spiricon.Interfaces.ConsoleService Feature_ = ProductgFeature File_Manifest = File_Application = Attribute = 0 Kurt -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Tuesday, May 10, 2011 3:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC There's not really a lot of info, but there are few things to look for. There won't be an error in the MSI log if Windows thinks it's doing the right thing, so don't just look for error. There might be entries about diallowing installation of component . that are relevant. If you're installing the file locally and also to the GAC you have two components with different guids, and different directories correct? Why have you got guid= in your component? I'm not quite sure of the full effect of this on assemblies, but this means that Windows Installer won't register the component, so it's not clear to me exactly what you'd see in the log for that. It would also make sense for you to assign guids to those components so that you can actually search the log and see what Windows has to say about them. Exactly what is the MsiAssembly table of the MSI file for the assembly? If it's going into the GAC there must be an entry for the assembly with a null
Re: [WiX-users] Publishing to GAC
a clue! we are moving our vs2008 solution to vs2010. all of our vs2008 assemblies are stuck at the last release v5.5.4127.3070. all of our vs2010 assemblies are set to the default v1.0.0.0. when I used the v5.5.4127.3070 assembly in the test (below) then it was installed in the GAC. if I rebuild the vs2010 as v1.1.0.0 then it is installed in the GAC apparently there is a bias against v1.0.0.0? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Wednesday, May 11, 2011 6:38 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Publishing to GAC ok, here it is trimmed down to its essence. I created a new project, enabled the default component, added a dummy file, then added my GAC component. on running the MSI, Spiricon.Interfaces.ConsoleService.dll is not in the GAC ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=4dd987d3-2e96-4eeb-892a-bb016fe0905a Name=SetupProject1 Language=1033 Version=1.0.0.0 Manufacturer=SetupProject1 UpgradeCode=a9f3d24a-59f8-47f6-8efe-969980b94136 Package InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=media1.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLLOCATION Name=SetupProject1 !-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -- Component Id=ProductComponent Guid=9e33d5df-e36a-4a40-844b-bda6688801b0 File Source=$(var.ProjectDir)OSIBanner.JPG KeyPath=yes / !-- TODO: Insert files, registry keys, and other resources here. -- /Component Component Id=Spiricon.Interfaces.ConsoleService Guid=F23AAD89-8D5F-46c1-8792-C7988BEF6212 File Source=$(var.TargetDir)\Spiricon.Interfaces.ConsoleService.dll Assembly=.net KeyPath=yes / /Component /Directory /Directory /Directory Feature Id=ProductFeature Title=SetupProject1 Level=1 !-- TODO: Remove the comments around this ComponentRef element and the Component above in order to add resources to this installer. -- ComponentRef Id=ProductComponent / ComponentRef Id=Spiricon.Interfaces.ConsoleService / !-- Note: The following ComponentGroupRef is required to pull in generated authoring from project references. -- ComponentGroupRef Id=Product.Generated / /Feature /Product /Wix -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Wednesday, May 11, 2011 6:15 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Publishing to GAC sorry but did we run out of ideas? you say There's not really a lot of info... what info do you need? please ask. if I knew what info was pertinent then I might still be able to look for a solution. I searched bugs but could not find any related. I searched the web but could not find any related. searched and read extensively before posting the original question. been on this 3 days with no solution in sight. maybe someone remembers some issue or bug that relates but is titled differently. is there someone I can pay to help me solve this problem? I don't know where else to look. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Tuesday, May 10, 2011 3:25 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Publishing to GAC yes, two components with different guids and different directories as outlined in the suggested article and follow on articles - I read them all I will look closer from some aberration in the log file. guid= is just to make it more readable... there is a real guid in the actual code how do I copy and display MsiAssembly table of the MSI file for the assembly? here is what I see... Component_ = Spiricon.Interfaces.ConsoleService Feature_ = ProductgFeature File_Manifest = File_Application = Attribute = 0 Kurt -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Tuesday, May 10, 2011 3:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC There's not really a lot of info, but there are few things to look for. There won't be an error in the MSI log if Windows thinks it's doing the right thing, so don't just look for error. There might be entries about diallowing installation of component . that are relevant. If you're installing the file locally and also
[WiX-users] missing assemblies referenced by Custom Action
now (all of a sudden...) something quit working we have a C# custom action that requires a couple of assemblies. in wix3.0 these assemblies were copied into the CustomAction.Install.WiX.CA.dll-# directory where the custom action was invoked. but now using winx3.5 it is failing because it cannot find these dependent assemblies. originally we were referencing the assemblies by Browse... but this did not work. changed to referencing the assembly projects. yesterday this worked. today it does not. what did I change? yes. actually I checked out some code that worked yesterday but today it does not. how do I reference assemblies needed by a C# custom action so that they are copied into the temporary directory when the custom action is invoked? -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding 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
Re: [WiX-users] missing assemblies referenced by Custom Action
Yes, the assemblies are referenced by project in the CA project set the build action to Content? do not know what this means... -Original Message- From: Dick Van den Brink [mailto:d_vandenbr...@live.com] Sent: Wednesday, May 11, 2011 8:35 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] missing assemblies referenced by Custom Action Did you add the dll to the CA project and set the build action to Content? From: kurt.jen...@us.ophiropt.com Date: Wed, 11 May 2011 08:27:10 -0600 To: wix-users@lists.sourceforge.net Subject: [WiX-users] missing assemblies referenced by Custom Action now (all of a sudden...) something quit working we have a C# custom action that requires a couple of assemblies. in wix3.0 these assemblies were copied into the CustomAction.Install.WiX.CA.dll-# directory where the custom action was invoked. but now using winx3.5 it is failing because it cannot find these dependent assemblies. originally we were referencing the assemblies by Browse... but this did not work. changed to referencing the assembly projects. yesterday this worked. today it does not. what did I change? yes. actually I checked out some code that worked yesterday but today it does not. how do I reference assemblies needed by a C# custom action so that they are copied into the temporary directory when the custom action is invoked? -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding 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 -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding 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 -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding 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
Re: [WiX-users] missing assemblies referenced by Custom Action
helps if you look in the right GAC... :( Note that for .NET 4.0 the GAC location is now: %windir%\Microsoft.NET\assembly\... -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Wednesday, May 11, 2011 9:01 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] missing assemblies referenced by Custom Action http://msdn.microsoft.com/en-us/library/0c6xyb66.aspx -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Wednesday, May 11, 2011 7:44 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] missing assemblies referenced by Custom Action Yes, the assemblies are referenced by project in the CA project set the build action to Content? do not know what this means... -Original Message- From: Dick Van den Brink [mailto:d_vandenbr...@live.com] Sent: Wednesday, May 11, 2011 8:35 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] missing assemblies referenced by Custom Action Did you add the dll to the CA project and set the build action to Content? From: kurt.jen...@us.ophiropt.com Date: Wed, 11 May 2011 08:27:10 -0600 To: wix-users@lists.sourceforge.net Subject: [WiX-users] missing assemblies referenced by Custom Action now (all of a sudden...) something quit working we have a C# custom action that requires a couple of assemblies. in wix3.0 these assemblies were copied into the CustomAction.Install.WiX.CA.dll-# directory where the custom action was invoked. but now using winx3.5 it is failing because it cannot find these dependent assemblies. originally we were referencing the assemblies by Browse... but this did not work. changed to referencing the assembly projects. yesterday this worked. today it does not. what did I change? yes. actually I checked out some code that worked yesterday but today it does not. how do I reference assemblies needed by a C# custom action so that they are copied into the temporary directory when the custom action is invoked? -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding 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 -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding 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 -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding 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 -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding 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 -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding 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
[WiX-users] Publishing to GAC
we publish one assembly to the GAC. we find the MsiPublishAssemblies action
in the log file. there is no error.
but the assembly does not appear in the GAC.
Action 7:17:10: MsiPublishAssemblies. Publishing assembly information
MSI (s) (F8:2C) [07:17:10:015]: Executing op:
AssemblyPublish(Feature=ProductFeature,Component={F23AAD89-8D5F-46C1-8792-C7988BEF6212}[~]2,AssemblyType=1,,AssemblyName=Spiricon.Interfaces.ConsoleService,version=1.0.0.0,culture=neutral,publicKeyToken=18293B57E84AEC4B,processorArchitecture=MSIL,)
MsiPublishAssemblies: Application Context:Global, Assembly
Name:Spiricon.Interfaces.ConsoleService,version=1.0.0.0,culture=neutral,publicKeyToken=18293B57E84AEC4B,processorArchitecture=MSIL
MSI (s) (F8:2C) [07:17:10:030]: Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing Product
Features,Template=Feature: [1])
any ideas how to find out what is wrong?
Kurt Jensen
Senior Software Engineer
Ophir-Spiricon LLC
www.ophiropt.com/photonics http://www.ophiropt.com/laser-measurement
The True Measure of Laser Performance™
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding 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
Re: [WiX-users] Publishing to GAC
I remember reading about that. double checked, the entry in
MsiAssemblyName has a version
we are at a loss as to how to track down the problem.
there are no errors.
any ideas?
-Original Message-
From: Jacques Eloff [mailto:repst...@gmail.com]
Sent: Tuesday, May 10, 2011 12:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Publishing to GAC
Ahh, I found that when moving from WiX 2.0 to 3.0/3.5, the assembly file
version wasn't written to the MsiAssemblyName table and it caused problems
for us during upgrades. The solution in that case was just to add the -fv
switch to Light, but that only solves upgrade issues.
On Tue, May 10, 2011 at 8:41 AM, Kurt Jensen
kurt.jen...@us.ophiropt.comwrote:
yes, we set the Assembly=.net otherwise we would not get the log entry
listing our assembly. the assembly is properly listed in the
MsiAssembly
table with attribute=0
we are converting a vs2008/wix3.0 project to vs2010/wix3.5. in the
wix3.0
project we only install it to the GAC. in the new wix3.5 we install it
both local and GAC. the source code for installing to the GAC is
identical in both projects.
DirectoryRef Id=CONSOLESERVICEDIRECTORY
Component Id=Spiricon.Interfaces.ConsoleService Guid=
File Source=$(var.Spiricon.Interfaces.ConsoleService.TargetPath)
Assembly=.net KeyPath=yes /
/Component
/DirectoryRef
note that CONSOLESERVICEDIRECTORY is never actually created
Make sure that the assembly is signed.
we are using strong naming but not code signing. same as in the wix3.0
project.
surely we would see an entry in the log if there was a problem?
-Original Message-
From: Jacques Eloff [mailto:repst...@gmail.com]
Sent: Tuesday, May 10, 2011 9:01 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Publishing to GAC
Did you set the Assembly attribute in the File element to .net?
File Assembly=.net KeyPath=yes Id=MyAssembly.dl
Name=MyAssembly.dll
ProcessorArchitecture=msil/
Also, as I recall, you need to create a separate directory for the GAC'd
assembly. So you would have two File elements for the assembly with
different parent directories. One to actually install it to disk, the
other
one to install it into the GAC.
Make sure that the assembly is signed. You can't install unsigned
assemblies
into the GAC.
Take a look at Aaron's blog as well:
http://blogs.msdn.com/b/astebner/archive/2007/06/21/3450539.aspx
Jacques
On Tue, May 10, 2011 at 7:46 AM, Kurt Jensen
kurt.jen...@us.ophiropt.comwrote:
we publish one assembly to the GAC. we find the MsiPublishAssemblies
action
in the log file. there is no error.
but the assembly does not appear in the GAC.
Action 7:17:10: MsiPublishAssemblies. Publishing assembly information
MSI (s) (F8:2C) [07:17:10:015]: Executing op:
AssemblyPublish(Feature=ProductFeature,Component={F23AAD89-8D5F-46C1-8792-
C7988BEF6212}[~]2,AssemblyType=1,,AssemblyName=Spiricon.Interfaces.Console
Service,version=1.0.0.0,culture=neutral,publicKeyToken=18293B57E84AEC
4B,processorArchitecture=MSIL,)
MsiPublishAssemblies: Application Context:Global, Assembly
Name:Spiricon.Interfaces.ConsoleService,version=1.0.0.0,culture=neutral
,publicKeyToken=18293B57E84AEC4B,processorArchitecture=MSIL
MSI (s) (F8:2C) [07:17:10:030]: Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing Product
Features,Template=Feature: [1])
any ideas how to find out what is wrong?
Kurt Jensen
Senior Software Engineer
Ophir-Spiricon LLC
www.ophiropt.com/photonics http://www.ophiropt.com/laser-measurement
The True Measure of Laser PerformanceT
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding 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
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding 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
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should
Re: [WiX-users] Publishing to GAC
Just testing clean install for now
-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
Sent: Tuesday, May 10, 2011 2:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Publishing to GAC
I might have missed but does this happen during a clean install, upgrade
or both?
-Original Message-
From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com]
Sent: Tuesday, May 10, 2011 1:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Publishing to GAC
I remember reading about that. double checked, the entry in
MsiAssemblyName has a version
we are at a loss as to how to track down the problem.
there are no errors.
any ideas?
-Original Message-
From: Jacques Eloff [mailto:repst...@gmail.com]
Sent: Tuesday, May 10, 2011 12:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Publishing to GAC
Ahh, I found that when moving from WiX 2.0 to 3.0/3.5, the assembly file
version wasn't written to the MsiAssemblyName table and it caused
problems
for us during upgrades. The solution in that case was just to add the
-fv
switch to Light, but that only solves upgrade issues.
On Tue, May 10, 2011 at 8:41 AM, Kurt Jensen
kurt.jen...@us.ophiropt.comwrote:
yes, we set the Assembly=.net otherwise we would not get the log
entry
listing our assembly. the assembly is properly listed in the
MsiAssembly
table with attribute=0
we are converting a vs2008/wix3.0 project to vs2010/wix3.5. in the
wix3.0
project we only install it to the GAC. in the new wix3.5 we install
it
both local and GAC. the source code for installing to the GAC is
identical in both projects.
DirectoryRef Id=CONSOLESERVICEDIRECTORY
Component Id=Spiricon.Interfaces.ConsoleService Guid=
File Source=$(var.Spiricon.Interfaces.ConsoleService.TargetPath)
Assembly=.net KeyPath=yes /
/Component
/DirectoryRef
note that CONSOLESERVICEDIRECTORY is never actually created
Make sure that the assembly is signed.
we are using strong naming but not code signing. same as in the
wix3.0
project.
surely we would see an entry in the log if there was a problem?
-Original Message-
From: Jacques Eloff [mailto:repst...@gmail.com]
Sent: Tuesday, May 10, 2011 9:01 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Publishing to GAC
Did you set the Assembly attribute in the File element to .net?
File Assembly=.net KeyPath=yes Id=MyAssembly.dl
Name=MyAssembly.dll
ProcessorArchitecture=msil/
Also, as I recall, you need to create a separate directory for the
GAC'd
assembly. So you would have two File elements for the assembly with
different parent directories. One to actually install it to disk, the
other
one to install it into the GAC.
Make sure that the assembly is signed. You can't install unsigned
assemblies
into the GAC.
Take a look at Aaron's blog as well:
http://blogs.msdn.com/b/astebner/archive/2007/06/21/3450539.aspx
Jacques
On Tue, May 10, 2011 at 7:46 AM, Kurt Jensen
kurt.jen...@us.ophiropt.comwrote:
we publish one assembly to the GAC. we find the
MsiPublishAssemblies
action
in the log file. there is no error.
but the assembly does not appear in the GAC.
Action 7:17:10: MsiPublishAssemblies. Publishing assembly
information
MSI (s) (F8:2C) [07:17:10:015]: Executing op:
AssemblyPublish(Feature=ProductFeature,Component={F23AAD89-8D5F-46C1-879
2-
C7988BEF6212}[~]2,AssemblyType=1,,AssemblyName=Spiricon.Interfaces.Conso
le
Service,version=1.0.0.0,culture=neutral,publicKeyToken=18293B57E84A
EC
4B,processorArchitecture=MSIL,)
MsiPublishAssemblies: Application Context:Global, Assembly
Name:Spiricon.Interfaces.ConsoleService,version=1.0.0.0,culture=neutr
al
,publicKeyToken=18293B57E84AEC4B,processorArchitecture=MSIL
MSI (s) (F8:2C) [07:17:10:030]: Executing op:
ActionStart(Name=PublishFeatures,Description=Publishing Product
Features,Template=Feature: [1])
any ideas how to find out what is wrong?
Kurt Jensen
Senior Software Engineer
Ophir-Spiricon LLC
www.ophiropt.com/photonics
http://www.ophiropt.com/laser-measurement
The True Measure of Laser PerformanceT
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding 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
--
Achieve unprecedented app performance and reliability
Re: [WiX-users] Publishing to GAC
yes, two components with different guids and different directories as outlined in the suggested article and follow on articles - I read them all I will look closer from some aberration in the log file. guid= is just to make it more readable... there is a real guid in the actual code how do I copy and display MsiAssembly table of the MSI file for the assembly? here is what I see... Component_ = Spiricon.Interfaces.ConsoleService Feature_ = ProductgFeature File_Manifest = File_Application = Attribute = 0 Kurt -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Tuesday, May 10, 2011 3:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC There's not really a lot of info, but there are few things to look for. There won't be an error in the MSI log if Windows thinks it's doing the right thing, so don't just look for error. There might be entries about diallowing installation of component . that are relevant. If you're installing the file locally and also to the GAC you have two components with different guids, and different directories correct? Why have you got guid= in your component? I'm not quite sure of the full effect of this on assemblies, but this means that Windows Installer won't register the component, so it's not clear to me exactly what you'd see in the log for that. It would also make sense for you to assign guids to those components so that you can actually search the log and see what Windows has to say about them. Exactly what is the MsiAssembly table of the MSI file for the assembly? If it's going into the GAC there must be an entry for the assembly with a null File_Application column. Phil Wilson -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Tuesday, May 10, 2011 1:31 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC Just testing clean install for now -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Tuesday, May 10, 2011 2:27 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC I might have missed but does this happen during a clean install, upgrade or both? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] Sent: Tuesday, May 10, 2011 1:05 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC I remember reading about that. double checked, the entry in MsiAssemblyName has a version we are at a loss as to how to track down the problem. there are no errors. any ideas? -Original Message- From: Jacques Eloff [mailto:repst...@gmail.com] Sent: Tuesday, May 10, 2011 12:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC Ahh, I found that when moving from WiX 2.0 to 3.0/3.5, the assembly file version wasn't written to the MsiAssemblyName table and it caused problems for us during upgrades. The solution in that case was just to add the -fv switch to Light, but that only solves upgrade issues. On Tue, May 10, 2011 at 8:41 AM, Kurt Jensen kurt.jen...@us.ophiropt.comwrote: yes, we set the Assembly=.net otherwise we would not get the log entry listing our assembly. the assembly is properly listed in the MsiAssembly table with attribute=0 we are converting a vs2008/wix3.0 project to vs2010/wix3.5. in the wix3.0 project we only install it to the GAC. in the new wix3.5 we install it both local and GAC. the source code for installing to the GAC is identical in both projects. DirectoryRef Id=CONSOLESERVICEDIRECTORY Component Id=Spiricon.Interfaces.ConsoleService Guid= File Source=$(var.Spiricon.Interfaces.ConsoleService.TargetPath) Assembly=.net KeyPath=yes / /Component /DirectoryRef note that CONSOLESERVICEDIRECTORY is never actually created Make sure that the assembly is signed. we are using strong naming but not code signing. same as in the wix3.0 project. surely we would see an entry in the log if there was a problem? -Original Message- From: Jacques Eloff [mailto:repst...@gmail.com] Sent: Tuesday, May 10, 2011 9:01 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Publishing to GAC Did you set the Assembly attribute in the File element to .net? File Assembly=.net KeyPath=yes Id=MyAssembly.dl Name=MyAssembly.dll ProcessorArchitecture=msil/ Also, as I recall, you need to create a separate directory for the GAC'd assembly. So you would have two File elements for the assembly with different parent directories. One to actually install it to disk, the other one to install it into the GAC. Make sure that the assembly is signed. You can't install unsigned assemblies into the GAC. Take a look at Aaron's blog as well: http://blogs.msdn.com/b/astebner/archive/2007
[WiX-users] Error LGHT0217
I am trying to build a very simple WiX project through our TFS 2010 build system. The project uses the default Product.wxs and contains only one component with one file. But I keep getting “error LGHT0217”. The linked WiX FAQ is of no use since I am not using any custom action and certainly not any script custom action. Here is the full error message: light.exe : error LGHT0217: Error executing ICE action 'ICE01'. 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.. [C:\Builds\10\BaseI\BeamGageWiX\Sources\BaseI\CodeBase\Installations\BeamGageWiX\Install.BeamGage.Standard.x86.WiX\Install.BeamGage.Standard.x86.WiX.wixproj] I tried searching the windows installer error but none of the answers apply to my situation (windows 7 64-bit) any ideas? -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error LGHT0217
found this blog post - http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/11/14/wix-projects-vs-tfs-2010-team-build.aspx whatever account is used to run the TFS Build must be a member of the local administrators group in order to the Internal Consistency Evaluators *From:* Kurt Jensen [mailto:kurt.jen...@us.ophiropt.com] *Sent:* Friday, May 06, 2011 7:19 AM *To:* 'wix-users@lists.sourceforge.net' *Subject:* Error LGHT0217 I am trying to build a very simple WiX project through our TFS 2010 build system. The project uses the default Product.wxs and contains only one component with one file. But I keep getting “error LGHT0217”. The linked WiX FAQ is of no use since I am not using any custom action and certainly not any script custom action. Here is the full error message: light.exe : error LGHT0217: Error executing ICE action 'ICE01'. 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.. [C:\Builds\10\BaseI\BeamGageWiX\Sources\BaseI\CodeBase\Installations\BeamGageWiX\Install.BeamGage.Standard.x86.WiX\Install.BeamGage.Standard.x86.WiX.wixproj] I tried searching the windows installer error but none of the answers apply to my situation (windows 7 64-bit) any ideas? -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Undefined preprocessor variable '$(var.Spiricon.FactoryManager.TargetPath)'
converting a v3.0 project to v3.5. on the command line I find the following. … dSpiricon.Export.TargetDir=E:\BaseI\CodeBase\Applications\Assemblies\ -dSpiricon.Export.TargetExt=.dll -dSpiricon.Export.TargetFileName=Spiricon.Export.dll -dSpiricon.Export.TargetName=Spiricon.Export -dSpiricon.Export.TargetPath=E:\BaseI\CodeBase\Applications\Assemblies\Spiricon.Export.dll -dSpiricon.Factory.Manager.Configuration=Debug -dSpiricon.Factory.Manager.FullConfiguration=Debug|AnyCPU -dSpiricon.Factory.Manager.Platform=AnyCPU -dSpiricon.Factory.Manager.ProjectDir=E:\BaseI\CodeBase\Applications\AllProject\Spiricon.Factory.Manager\ -dSpiricon.Factory.Manager.ProjectExt=.csproj -dSpiricon.Factory.Manager.ProjectFileName=Spiricon.Factory.Manager.csproj -dSpiricon.Factory.Manager.ProjectName=Spiricon.Factory.Manager -dSpiricon.Factory.Manager.ProjectPath=E:\BaseI\CodeBase\Applications\AllProject\Spiricon.Factory.Manager\Spiricon.Factory.Manager.csproj -dSpiricon.Factory.Manager.TargetDir=E:\BaseI\CodeBase\Applications\Assemblies\ -dSpiricon.Factory.Manager.TargetExt=.dll -dSpiricon.Factory.Manager.TargetFileName=Spiricon.Factory.Manager.dll -dSpiricon.Factory.Manager.TargetName=Spiricon.Factory.Manager -dSpiricon.Factory.Manager.TargetPath=E:\BaseI\CodeBase\Applications\Assemblies\Spiricon.Factory.Manager.dll -dSpiricon.Histogram.Manager.Configuration=Debug -dSpiricon.Histogram.Manager.FullConfiguration=Debug|AnyCPU -dSpiricon.Histogram.Manager.Platform=AnyCPU -dSpiricon.Histogram.Manager.ProjectDir=E:\BaseI\CodeBase\Applications\AllProject\Spiricon.Histogram.Manager\ -dSpiricon.Histogram.Manager.ProjectExt=.csproj – … obviously Spiricon.FactoryManager.TargetPath is defined. why is candle confused? Kurt Jensen Senior Software Engineer Ophir-Spiricon LLC -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Undefined preprocessor variable '$(var.Spiricon.FactoryManager.TargetPath)'
converting a v3.0 project to v3.5. on the command line I find the following. … dSpiricon.Export.TargetDir=E:\BaseI\CodeBase\Applications\Assemblies\ -dSpiricon.Export.TargetExt=.dll -dSpiricon.Export.TargetFileName=Spiricon.Export.dll -dSpiricon.Export.TargetName=Spiricon.Export -dSpiricon.Export.TargetPath=E:\BaseI\CodeBase\Applications\Assemblies\Spiricon.Export.dll -dSpiricon.Factory.Manager.Configuration=Debug -dSpiricon.Factory.Manager.FullConfiguration=Debug|AnyCPU -dSpiricon.Factory.Manager.Platform=AnyCPU -dSpiricon.Factory.Manager.ProjectDir=E:\BaseI\CodeBase\Applications\AllProject\Spiricon.Factory.Manager\ -dSpiricon.Factory.Manager.ProjectExt=.csproj -dSpiricon.Factory.Manager.ProjectFileName=Spiricon.Factory.Manager.csproj -dSpiricon.Factory.Manager.ProjectName=Spiricon.Factory.Manager -dSpiricon.Factory.Manager.ProjectPath=E:\BaseI\CodeBase\Applications\AllProject\Spiricon.Factory.Manager\Spiricon.Factory.Manager.csproj -dSpiricon.Factory.Manager.TargetDir=E:\BaseI\CodeBase\Applications\Assemblies\ -dSpiricon.Factory.Manager.TargetExt=.dll -dSpiricon.Factory.Manager.TargetFileName=Spiricon.Factory.Manager.dll -dSpiricon.Factory.Manager.TargetName=Spiricon.Factory.Manager -dSpiricon.Factory.Manager.TargetPath=E:\BaseI\CodeBase\Applications\Assemblies\Spiricon.Factory.Manager.dll -dSpiricon.Histogram.Manager.Configuration=Debug -dSpiricon.Histogram.Manager.FullConfiguration=Debug|AnyCPU -dSpiricon.Histogram.Manager.Platform=AnyCPU -dSpiricon.Histogram.Manager.ProjectDir=E:\BaseI\CodeBase\Applications\AllProject\Spiricon.Histogram.Manager\ -dSpiricon.Histogram.Manager.ProjectExt=.csproj – … obviously Spiricon.FactoryManager.TargetPath is defined. why is candle confused? (sorry if this got sent out twice. did not see a confirmation fromt eh first time…) -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Undefined preprocessor variable '$(var.Spiricon.FactoryManager.TargetPath)'
The full command line contains over 70 other projects with variable definitions all of which contain one or more . None of the other $(var.Spiricon.projectname.TargetPath) is listed as an error. -Original Message- From: Dick Van den Brink [mailto:d_vandenbr...@live.com] Sent: Tuesday, May 03, 2011 7:16 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Undefined preprocessor variable '$(var.Spiricon.FactoryManager.TargetPath)' I think it's confused because of the .. When I create a WiX project in Visual Studio and add a reference to a project called Test.Project.Then i need to change the reference name (in the package project) to TestProject in order to access the variables. From: kurt.jen...@us.ophiropt.com Date: Tue, 3 May 2011 06:56:26 -0600 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Undefined preprocessor variable '$(var.Spiricon.FactoryManager.TargetPath)' converting a v3.0 project to v3.5. on the command line I find the following. . dSpiricon.Export.TargetDir=E:\BaseI\CodeBase\Applications\Assemblies\ -dSpiricon.Export.TargetExt=.dll -dSpiricon.Export.TargetFileName=Spiricon.Export.dll -dSpiricon.Export.TargetName=Spiricon.Export -dSpiricon.Export.TargetPath=E:\BaseI\CodeBase\Applications\Assemblies \Spiricon.Export.dll -dSpiricon.Factory.Manager.Configuration=Debug -dSpiricon.Factory.Manager.FullConfiguration=Debug|AnyCPU -dSpiricon.Factory.Manager.Platform=AnyCPU -dSpiricon.Factory.Manager.ProjectDir=E:\BaseI\CodeBase\Applications\A llProject\Spiricon.Factory.Manager\ -dSpiricon.Factory.Manager.ProjectExt=.csproj -dSpiricon.Factory.Manager.ProjectFileName=Spiricon.Factory.Manager.cs proj -dSpiricon.Factory.Manager.ProjectName=Spiricon.Factory.Manager -dSpiricon.Factory.Manager.ProjectPath=E:\BaseI\CodeBase\Applications\ AllProject\Spiricon.Factory.Manager\Spiricon.Factory.Manager.csproj -dSpiricon.Factory.Manager.TargetDir=E:\BaseI\CodeBase\Applications\As semblies\ -dSpiricon.Factory.Manager.TargetExt=.dll -dSpiricon.Factory.Manager.TargetFileName=Spiricon.Factory.Manager.dll -dSpiricon.Factory.Manager.TargetName=Spiricon.Factory.Manager -dSpiricon.Factory.Manager.TargetPath=E:\BaseI\CodeBase\Applications\A ssemblies\Spiricon.Factory.Manager.dll -dSpiricon.Histogram.Manager.Configuration=Debug -dSpiricon.Histogram.Manager.FullConfiguration=Debug|AnyCPU -dSpiricon.Histogram.Manager.Platform=AnyCPU -dSpiricon.Histogram.Manager.ProjectDir=E:\BaseI\CodeBase\Applications \AllProject\Spiricon.Histogram.Manager\ -dSpiricon.Histogram.Manager.ProjectExt=.csproj - . obviously Spiricon.FactoryManager.TargetPath is defined. why is candle confused? Kurt Jensen Senior Software Engineer Ophir-Spiricon LLC -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Undefined preprocessor variable '$(var.Spiricon.FactoryManager.TargetPath)'
oops... you're right. the guys converting the projects to vs 2010 changed the project name... -Original Message- From: Helge Kruse [mailto:helge.kruse-nos...@gmx.net] Sent: Tuesday, May 03, 2011 12:53 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Undefined preprocessor variable '$(var.Spiricon.FactoryManager.TargetPath)' Am 03.05.2011 18:30, schrieb Kurt Jensen: The full command line contains over 70 other projects with variable definitions all of which contain one or more . None of the other $(var.Spiricon.projectname.TargetPath) is listed as an error. -dSpiricon.Factory.Manager.TargetPath=E:\BaseI\CodeBase\Applications\ A obviously Spiricon.FactoryManager.TargetPath is defined. why is candle confused? For me the variable is different from the define. I think Factory.Manager and FactoryManager are unrelated. to be read again: Factory.Manager FactoryManager Regards, Helge -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Japanese Windows 7 conundrum
Never mind. Apparently there was a previous installation that was messing things up. Install on a clean OS works fine. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, January 17, 2011 1:33 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Japanese Windows 7 conundrum I have an MSI that is not installing on the Japanese language version of Windows 7 32-bit. The MSI has not been internationalized. My software is installing to E:\ rather than C:\Program Files\. And then the custom actions are not being executed. In the log I see: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'E:\'. PROPERTY CHANGE: Modifying SystemFolder property. Its current value is 'C:\Windows\system32\'. Its new value: 'E:\System\'. PROPERTY CHANGE: Adding DriversFolder property. Its value is 'E:\System\Drivers\'. PROPERTY CHANGE: Modifying WindowsFolder property. Its current value is 'C:\Windows\'. Its new value: 'E:\Windows\'. PROPERTY CHANGE: Adding InfFolder property. Its value is 'E:\Windows\Inf\'. PROPERTY CHANGE: Modifying DesktopFolder property. Its current value is 'C:\Users\Public\Desktop\'. Its new value: 'E:\Desktop\'. PROPERTY CHANGE: Modifying ProgramFilesFolder property. Its current value is 'C:\Program Files\'. Its new value: 'E:\'. PROPERTY CHANGE: Adding SPIRICONDIRECTORY property. Its value is 'E:\Spiricon\'. PROPERTY CHANGE: Adding PYROCAMDIRECTORY property. Its value is 'E:\Spiricon\PyrocamKMDF\'. PROPERTY CHANGE: Adding i386DIRECTORY property. Its value is 'E:\Spiricon\PyrocamKMDF\i386\'. Anybody have any idea what the heck is going on? TIA. Kurt Jensen Senior Software Engineer Ophir-Spiricon www.ophiropt.com/laser-measurement http://www.ophiropt.com/laser-measurement The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Japanese Windows 7 conundrum
I have an MSI that is not installing on the Japanese language version of Windows 7 32-bit. The MSI has not been internationalized. My software is installing to E:\ rather than C:\Program Files\. And then the custom actions are not being executed. In the log I see: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'E:\'. PROPERTY CHANGE: Modifying SystemFolder property. Its current value is 'C:\Windows\system32\'. Its new value: 'E:\System\'. PROPERTY CHANGE: Adding DriversFolder property. Its value is 'E:\System\Drivers\'. PROPERTY CHANGE: Modifying WindowsFolder property. Its current value is 'C:\Windows\'. Its new value: 'E:\Windows\'. PROPERTY CHANGE: Adding InfFolder property. Its value is 'E:\Windows\Inf\'. PROPERTY CHANGE: Modifying DesktopFolder property. Its current value is 'C:\Users\Public\Desktop\'. Its new value: 'E:\Desktop\'. PROPERTY CHANGE: Modifying ProgramFilesFolder property. Its current value is 'C:\Program Files\'. Its new value: 'E:\'. PROPERTY CHANGE: Adding SPIRICONDIRECTORY property. Its value is 'E:\Spiricon\'. PROPERTY CHANGE: Adding PYROCAMDIRECTORY property. Its value is 'E:\Spiricon\PyrocamKMDF\'. PROPERTY CHANGE: Adding i386DIRECTORY property. Its value is 'E:\Spiricon\PyrocamKMDF\i386\'. Anybody have any idea what the heck is going on? TIA. Kurt Jensen Senior Software Engineer Ophir-Spiricon www.ophiropt.com/laser-measurement http://www.ophiropt.com/laser-measurement The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] verbose
For some unknown reason I am getting the wrong assembly into my MSI when the solution is built on my Team Foundation Server (TFS) build agent. To resolve this problem I would like to get a complete list of the files that are going into the MSI. I tried adding -v to the Compiler and Linker Tool Settings for the project in the solution. But I do not see this option on the command line in the log and I am not getting any more information. How can I get information detailing exactly which files are being included by candle and light? Kurt Jensen Senior Software Engineer Ophir-Spiricon Cell: 435-764-2122 Ph: 435-755-5429 Fax: 435-755-5454 www.ophiropt.com/laser-measurement http://www.ophiropt.com/laser-measurement kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] verbose
OK, well sort of...I had the wrong Configuration and Platform selected. Now I see -v on the candle and light command line. But, not seeing any more info than not verbose. I guess I am not quite sure what to expect here. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Tuesday, August 24, 2010 8:32 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] verbose For some unknown reason I am getting the wrong assembly into my MSI when the solution is built on my Team Foundation Server (TFS) build agent. To resolve this problem I would like to get a complete list of the files that are going into the MSI. I tried adding -v to the Compiler and Linker Tool Settings for the project in the solution. But I do not see this option on the command line in the log and I am not getting any more information. How can I get information detailing exactly which files are being included by candle and light? Kurt Jensen Senior Software Engineer Ophir-Spiricon Cell: 435-764-2122 Ph: 435-755-5429 Fax: 435-755-5454 www.ophiropt.com/laser-measurement http://www.ophiropt.com/laser-measurement kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] verbose
Never mind, I found the cause of the problem I am working on. Think about this verbose thing another time. Thanks for listening... :) -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Tuesday, August 24, 2010 9:32 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] verbose OK, well sort of...I had the wrong Configuration and Platform selected. Now I see -v on the candle and light command line. But, not seeing any more info than not verbose. I guess I am not quite sure what to expect here. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Tuesday, August 24, 2010 8:32 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] verbose For some unknown reason I am getting the wrong assembly into my MSI when the solution is built on my Team Foundation Server (TFS) build agent. To resolve this problem I would like to get a complete list of the files that are going into the MSI. I tried adding -v to the Compiler and Linker Tool Settings for the project in the solution. But I do not see this option on the command line in the log and I am not getting any more information. How can I get information detailing exactly which files are being included by candle and light? Kurt Jensen Senior Software Engineer Ophir-Spiricon Cell: 435-764-2122 Ph: 435-755-5429 Fax: 435-755-5454 www.ophiropt.com/laser-measurement http://www.ophiropt.com/laser-measurement kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Both Install and Uninstall Custom Actions calledduring install
No, this happens during a first time installation. P.S. We see MSI log data from CAInstall but no log data from CAUninstall. We verified that both were running by creating separate files during each call. Both files are created during one install. -Original Message- From: Blair [mailto:os...@live.com] Sent: Thursday, August 19, 2010 2:20 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Both Install and Uninstall Custom Actions calledduring install Were you performing a major upgrade? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, August 18, 2010 5:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Both Install and Uninstall Custom Actions called during install We have a C# assembly that contains methods called during install and uninstall. But, on Windows XP it appears that both actions are being called, CAInstall and later CAUninstall. How can this be? Here is the CustomAction and InstallExecuteSequence code CustomAction Id=CAInstall FileKey=$(var.CustomAction.Install.WiX.TargetName) DllEntry=CAInstall Impersonate=no Execute=deferred / CustomAction Id=CAUninstall FileKey=$(var.CustomAction.Install.WiX.TargetName) DllEntry=CAUninstall Impersonate=no Execute=deferred / InstallExecuteSequence Custom Action=CAInstall Before=InstallFinalizeNOT Installed/Custom Custom Action=CAUninstall Before=RemoveFilesInstalled/Custom /InstallExecuteSequence In task manager, we see two msiexec processes - one for the UI, one to do the work. We see a third pop up when running CAInstall. Then a fourth appears at the very end and appears to be running CAUninstall. Kurt Jensen Senior Software Engineer Ophir-Spiricon www.ophiropt.com/laser-measurement http://www.ophiropt.com/laser-measurement ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Both Install and Uninstall Custom Actions called during install
I changed the first InstallExecuteSequence to Custom Action=CAInstall After=InstallFilesNOT Installed/Custom Now each CA runs at the appropriate time. This seems like a bug somewhere. Who would be interested? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, August 19, 2010 7:04 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Both Install and Uninstall Custom Actionscalledduring install No, this happens during a first time installation. P.S. We see MSI log data from CAInstall but no log data from CAUninstall. We verified that both were running by creating separate files during each call. Both files are created during one install. -Original Message- From: Blair [mailto:os...@live.com] Sent: Thursday, August 19, 2010 2:20 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Both Install and Uninstall Custom Actions calledduring install Were you performing a major upgrade? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, August 18, 2010 5:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Both Install and Uninstall Custom Actions called during install We have a C# assembly that contains methods called during install and uninstall. But, on Windows XP it appears that both actions are being called, CAInstall and later CAUninstall. How can this be? Here is the CustomAction and InstallExecuteSequence code CustomAction Id=CAInstall FileKey=$(var.CustomAction.Install.WiX.TargetName) DllEntry=CAInstall Impersonate=no Execute=deferred / CustomAction Id=CAUninstall FileKey=$(var.CustomAction.Install.WiX.TargetName) DllEntry=CAUninstall Impersonate=no Execute=deferred / InstallExecuteSequence Custom Action=CAInstall Before=InstallFinalizeNOT Installed/Custom Custom Action=CAUninstall Before=RemoveFilesInstalled/Custom /InstallExecuteSequence In task manager, we see two msiexec processes - one for the UI, one to do the work. We see a third pop up when running CAInstall. Then a fourth appears at the very end and appears to be running CAUninstall. Kurt Jensen Senior Software Engineer Ophir-Spiricon www.ophiropt.com/laser-measurement http://www.ophiropt.com/laser-measurement ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Both Install and Uninstall Custom Actions called during install
We have a C# assembly that contains methods called during install and uninstall. But, on Windows XP it appears that both actions are being called, CAInstall and later CAUninstall. How can this be? Here is the CustomAction and InstallExecuteSequence code CustomAction Id=CAInstall FileKey=$(var.CustomAction.Install.WiX.TargetName) DllEntry=CAInstall Impersonate=no Execute=deferred / CustomAction Id=CAUninstall FileKey=$(var.CustomAction.Install.WiX.TargetName) DllEntry=CAUninstall Impersonate=no Execute=deferred / InstallExecuteSequence Custom Action=CAInstall Before=InstallFinalizeNOT Installed/Custom Custom Action=CAUninstall Before=RemoveFilesInstalled/Custom /InstallExecuteSequence In task manager, we see two msiexec processes - one for the UI, one to do the work. We see a third pop up when running CAInstall. Then a fourth appears at the very end and appears to be running CAUninstall. Kurt Jensen Senior Software Engineer Ophir-Spiricon www.ophiropt.com/laser-measurement http://www.ophiropt.com/laser-measurement ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Windows 7 Custom Action Registry problem
I have a custom action that needs to create entries in the registry under HKEY_LOCAL_MACHINE. The code is written in C# and uses Registry.LocalMachine.CreateSubKey(). I added some logging that tells me that the return value is not null and the custom action does not throw an exception. But the key is never created. What is really weird is that various functions are called that use OpenSubKey(). These functions also log correct return values and do not throw exceptions. But the key is never created. The custom action works fine in XP but fails in Windows 7. I am running the custom action with Impersonate=no. Kurt Jensen Senior Software Engineer Ophir-Spiricon www.Ophir-Spiricon.com http://www.ophir-spiricon.com/ ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows 7 Custom Action Registry problem
Have you set Execute=deferred on CustomAction and scheduled it between InstallInitialize and InstallFinalize ? yes and yes Are the installer and machine it is running on both 32-bit ? both are 64-bit. I am trying to create HKLM\Software\Spiricon\Version5\ - Spiricon or Version5 may not exist on the user's machine. I need HKLM because the keys contain information necessary for the program to run and applies to all users. The installer is required to have be an administrator because we are also installing device drivers. Perhaps it is virtualizing though the documentation says that this should not happen with 64-bit processes. I looked under HKCU and found \Software\Spiricon\Version5\ had been created but the string values we write were not there. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Thursday, July 01, 2010 9:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem There might be some registry redirection or virtualisation occurring. Have you set Execute=deferred on CustomAction and scheduled it between InstallInitialize and InstallFinalize ? Are the installer and machine it is running on both 32-bit ? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: 01 July 2010 16:33 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Windows 7 Custom Action Registry problem I have a custom action that needs to create entries in the registry under HKEY_LOCAL_MACHINE. The code is written in C# and uses Registry.LocalMachine.CreateSubKey(). I added some logging that tells me that the return value is not null and the custom action does not throw an exception. But the key is never created. What is really weird is that various functions are called that use OpenSubKey(). These functions also log correct return values and do not throw exceptions. But the key is never created. The custom action works fine in XP but fails in Windows 7. I am running the custom action with Impersonate=no. Kurt Jensen Senior Software Engineer Ophir-Spiricon www.Ophir-Spiricon.com http://www.ophir-spiricon.com/ ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users /pre BR style=font-size:4px; a href = http://www.sdl.com;img src=http://www.sdl.com/images/email logo_150dpi-01.png alt=www.sdl.com border=0//a BR font face=arial size=2 a href = http://www.sdl.com; style=color:005740; font-weight: boldwww.sdl.com/a BR BR font face=arial size=1 color=#736F6E bSDL PLC confidential, all rights reserved./b If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us.BR SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207.BR Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. /font -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows 7 Custom Action Registry problem
Yes, I have now added that. But in my CA I need to add, delete, and write values under that key. I am getting HKCU instead. Windows Installer does a fantastic job writing registry entries and removing them later on under all sorts of variable influences I don't know about under all sorts of variable influences. our experience is that Windows Installer works if it is done perfectly and in the correct order. our code is defensive and deals with installs and uninstalls that failed in the middle. in addition we also deal with terminating the app. the original reason for the custom action is the difficulty we encountered when trying to deal with installing and uninstalling a service. despite much reading, much searching, and much experimentation Windows Installer would never work for us. so we created our own solution. Why reinvent the wheel? because the learning curve to understand the wheel is higher. I tried to read the article at your link. I understand the problem. I read the solution. I honestly have no idea how the solution solves the problem. And, I have no idea where to look in order to understand the solution. also, this solution was developed by another less install oriented programmer for the original vsproj under VS2008. I moved the code as-is over to WiX on a 32-bit install and it worked. now we are adding a 64-bit install. if I change to having Windows Installer do the job then I really am reinventing the wheel from our perspective. . Custom actions that add temporary rows to built-in tables gives you the flexibility to deal with whatever is your reason for making a custom action that writes entries in the registry to begin with (assuming you can't do this some other way using component conditions, features, or some other basic elements of WiX). if I understood half of what you just said then maybe I would use it. but I am not an expert in MSI or WiX for that matter. if I had time and people I could become an expert. but...the other guys have finished their part. now they are all waiting for me to finish the install. this problem appears to be my last hurdle. if I could get the registry entry into the %$#^@* HKLM then I would be done. I thought it would be easier just to put all of the creation and management into the custom action. TIA for your help. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Thursday, July 01, 2010 11:01 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem I am trying to create HKLM\Software\Spiricon\Version5\ You can do that with simple RegistryValue and/or RegistryKey elements in WiX. Why do you need a Custom Action? 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: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: 01 July 2010 17:00 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem Have you set Execute=deferred on CustomAction and scheduled it between InstallInitialize and InstallFinalize ? yes and yes Are the installer and machine it is running on both 32-bit ? both are 64-bit. I am trying to create HKLM\Software\Spiricon\Version5\ - Spiricon or Version5 may not exist on the user's machine. I need HKLM because the keys contain information necessary for the program to run and applies to all users. The installer is required to have be an administrator because we are also installing device drivers. Perhaps it is virtualizing though the documentation says that this should not happen with 64-bit processes. I looked under HKCU and found \Software\Spiricon\Version5\ had been created but the string values we write were not there. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Thursday, July 01, 2010 9:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem There might be some registry redirection or virtualisation occurring. Have you set Execute=deferred on CustomAction and scheduled it between InstallInitialize and InstallFinalize ? Are the installer and machine it is running on both 32-bit ? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: 01 July 2010 16:33 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Windows 7 Custom Action Registry problem I have a custom action that needs to create entries in the registry under HKEY_LOCAL_MACHINE. The code is written in C# and uses
Re: [WiX-users] Windows 7 Custom Action Registry problem
That's it! So far I cannot find an equivalent in .NET but at least now I can track down the communication breakdown... Thanks to all! -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Thursday, July 01, 2010 11:23 AM To: General discussion for Windows Installer XML toolset. Cc: Kurt Jensen Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem also, this solution was developed by another less install oriented programmer for the original vsproj under VS2008. I moved the code as-is over to WiX on a 32-bit install and it worked. now we are adding a 64-bit install. if I change to having Windows Installer do the job then I really am reinventing the wheel from our perspective. Maybe your keys get redirected? Check HKLM\SOFTWARE\Wow6432Node\Spiricon\Version5. Maybe your values are there. If so, you need to add KEY_WOW64_64KEY to RegOpenKey (or whatever the .NET equivalent is). ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows 7 Custom Action Registry problem
yeah, I thought about that. it is a C# custom action built for the Any CPU platform running on a 64-bit OS in a 64-bit WiX install. I don't know how it could possibly be 32-bit. -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Thursday, July 01, 2010 1:22 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem that seems to indicate that your custom action is running as 32-bit, if you run them as 64-bit things should just work.. On Thu, Jul 1, 2010 at 10:09 PM, Kurt Jensen kurt.jen...@ophir-spiricon.com wrote: That's it! So far I cannot find an equivalent in .NET but at least now I can track down the communication breakdown... Thanks to all! -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Thursday, July 01, 2010 11:23 AM To: General discussion for Windows Installer XML toolset. Cc: Kurt Jensen Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem also, this solution was developed by another less install oriented programmer for the original vsproj under VS2008. I moved the code as-is over to WiX on a 32-bit install and it worked. now we are adding a 64-bit install. if I change to having Windows Installer do the job then I really am reinventing the wheel from our perspective. Maybe your keys get redirected? Check HKLM\SOFTWARE\Wow6432Node\Spiricon\Version5. Maybe your values are there. If so, you need to add KEY_WOW64_64KEY to RegOpenKey (or whatever the .NET equivalent is). ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows 7 Custom Action Registry problem
Could WiX be launching the CA as in 32-bit mode? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, July 01, 2010 1:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem yeah, I thought about that. it is a C# custom action built for the Any CPU platform running on a 64-bit OS in a 64-bit WiX install. I don't know how it could possibly be 32-bit. -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Thursday, July 01, 2010 1:22 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem that seems to indicate that your custom action is running as 32-bit, if you run them as 64-bit things should just work.. On Thu, Jul 1, 2010 at 10:09 PM, Kurt Jensen kurt.jen...@ophir-spiricon.com wrote: That's it! So far I cannot find an equivalent in .NET but at least now I can track down the communication breakdown... Thanks to all! -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Thursday, July 01, 2010 11:23 AM To: General discussion for Windows Installer XML toolset. Cc: Kurt Jensen Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem also, this solution was developed by another less install oriented programmer for the original vsproj under VS2008. I moved the code as-is over to WiX on a 32-bit install and it worked. now we are adding a 64-bit install. if I change to having Windows Installer do the job then I really am reinventing the wheel from our perspective. Maybe your keys get redirected? Check HKLM\SOFTWARE\Wow6432Node\Spiricon\Version5. Maybe your values are there. If so, you need to add KEY_WOW64_64KEY to RegOpenKey (or whatever the .NET equivalent is). ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows 7 Custom Action Registry problem
so, the WiX DTF is always 32-bit? even the 64-bit install? -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Thursday, July 01, 2010 2:16 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem Windows Installer does that, and it looks at the bitness of the code and (if necessary) launches a matching-bitness msiexec.exe process to call the Dll (which is how I think DTF CAs start up). That's why the only custom action type that has a run in 64-bit mode option is a script type because you can't tell from a script what bitness it should run with, unlike compiled binaries. Phil Wilson -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, July 01, 2010 1:00 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem Could WiX be launching the CA as in 32-bit mode? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, July 01, 2010 1:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem yeah, I thought about that. it is a C# custom action built for the Any CPU platform running on a 64-bit OS in a 64-bit WiX install. I don't know how it could possibly be 32-bit. -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Thursday, July 01, 2010 1:22 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem that seems to indicate that your custom action is running as 32-bit, if you run them as 64-bit things should just work.. On Thu, Jul 1, 2010 at 10:09 PM, Kurt Jensen kurt.jen...@ophir-spiricon.com wrote: That's it! So far I cannot find an equivalent in .NET but at least now I can track down the communication breakdown... Thanks to all! -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Thursday, July 01, 2010 11:23 AM To: General discussion for Windows Installer XML toolset. Cc: Kurt Jensen Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem also, this solution was developed by another less install oriented programmer for the original vsproj under VS2008. I moved the code as-is over to WiX on a 32-bit install and it worked. now we are adding a 64-bit install. if I change to having Windows Installer do the job then I really am reinventing the wheel from our perspective. Maybe your keys get redirected? Check HKLM\SOFTWARE\Wow6432Node\Spiricon\Version5. Maybe your values are there. If so, you need to add KEY_WOW64_64KEY to RegOpenKey (or whatever the .NET equivalent is). ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality
Re: [WiX-users] Windows 7 Custom Action Registry problem
Thanks! I think the real problem is that the CA is being launched as a 32-bit process (of course). now that I know the problem I have modified my application code to first look in the normal part of the registry, then look in Wow6432Node if the key is not found. that way it works on a 32-bit OS, on a 64-bit OS when the CA runs as a 32-bit process, and will continue to work if the CA some day starts running as a 64-bit process. thanks again for all the stimulation! -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Thursday, July 01, 2010 2:45 PM To: General discussion for Windows Installer XML toolset. Cc: Kurt Jensen Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem Here's one example how to do it with P/Invoke: http://www.roelvanlisdonk.nl/?p=915 Kurt Jensen kurt.jen...@ophir-spiricon.com wrote: That's it! So far I cannot find an equivalent in .NET but at least now I can track down the communication breakdown... Thanks to all! -Original Message- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Thursday, July 01, 2010 11:23 AM To: General discussion for Windows Installer XML toolset. Cc: Kurt Jensen Subject: Re: [WiX-users] Windows 7 Custom Action Registry problem also, this solution was developed by another less install oriented programmer for the original vsproj under VS2008. I moved the code as-is over to WiX on a 32-bit install and it worked. now we are adding a 64-bit install. if I change to having Windows Installer do the job then I really am reinventing the wheel from our perspective. Maybe your keys get redirected? Check HKLM\SOFTWARE\Wow6432Node\Spiricon\Version5. Maybe your values are there. If so, you need to add KEY_WOW64_64KEY to RegOpenKey (or whatever the .NET equivalent is). ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSI vs Windows 7 UAC
Thanks. I got confused and thought Impersonate=no was the default.
Good coding practice is to be explicit about key parameters, default
value or not. That took care of #2 #4.
I guess we all will now have to put up with #3.
#1 is the real failure and continues to fail. This looks like a serious
error in the WiX handling of custom actions. I understand only a
little. I know that custom actions, and any dependent assemblies, are
placed in a temporary directory with the name custom action dll file
name=#. Apparently this mechanism is failing under UAC in Windows 7.
I would guess that the directory creation and file copy are not being
elevated. This will fail if Program Files is read only to the current
user. This confuses me because the user is required to be an
administrator because we are installing drivers.
Also, there is a current bug where the directory is not removed after
the custom action is done.
Kurt
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Wednesday, June 09, 2010 6:06 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] MSI vs Windows 7 UAC
A couple of observations:
Add Impersonate=no to your CustomAction declarations. That attribute
defaults to yes. You are impersonating the installing user instead of
running those CAs as SYSTEM.
Normally custom actions are run from the Binary table instead of the
File
table, unless you also need them outside of your installation. DTF CAs
require write access to the directory that the DLL is run from. For CAs
run
from the Binary table, Windows Installer places them in a location
appropriate for the impersonation-level the CA will run at. For File
table
CAs, you have to ensure that. If a deferred CA is impersonating the
installing user, it will lose elevation if that wasn't supplied before
invoking MSI.
-Original Message-
From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com]
Sent: Wednesday, June 09, 2010 12:30 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSI vs Windows 7 UAC
1)
DirectoryRef Id=APPLICATIONDIRECTORY
Component Id=CustomAction.Install.WiX
Guid={5B6CBC69-4EA2-4648-A080-8D2027BAB081}
File Id=$(var.CustomAction.Install.WiX.TargetName)
Source=$(var.CustomAction.Install.WiX.TargetDir)$(var.CustomAction.Inst
all.WiX.TargetName).CA.dll /
/Component
/DirectoryRef
CustomAction Id=CAInstall
FileKey=$(var.CustomAction.Install.WiX.TargetName)
DllEntry=CAInstall Execute=commit /
CustomAction Id=CAUninstall
FileKey=$(var.CustomAction.Install.WiX.TargetName)
DllEntry=CAUninstall Execute=deferred /
InstallExecuteSequence
!-- Run CAInstall after InstallFiles only if the product was not
installed (i.e. do not run on uninstall) --
Custom Action=CAInstall Before=InstallFinalizeNOT
Installed/Custom
!-- Run CAInstall after InstallFiles only if the product was
installed (i.e. only run on uninstall) --
Custom Action=CAUninstall
Before=RemoveFilesInstalled/Custom
/InstallExecuteSequence
2)
DirectoryRef Id=PYROCAMDIRECTORY
Component Id=PyrocamIII
Guid=21324FF8-D573-4811-A7E8-DB9A58274EAD
File
Source=$(var.SolutionDir)..\..\Installations\Source\Pyrocam III Device
Driver 1.1.0.0\InstallII.exe /
/Component
/DirectoryRef
CustomAction Id=InstallII
Directory=PYROCAMDIRECTORY
ExeCommand=[PYROCAMDIRECTORY]InstallII.exe
Execute=deferred
Return=ignore /
InstallExecuteSequence
Custom Action=InstallII After=InstallFilesNOT
Installed/Custom
/InstallExecuteSequence
InstallExecuteSequence
Custom Action=ReenumPyrocam After=InstallFilesNOT
Installed/Custom
/InstallExecuteSequence
3,4) As I said, very annoying and looks unprofessional. The thought is
that there is something wrong with my installation which is why Windows
7 has to ask permission. This is a cause for concern and phone calls.
As a result, my supervisor and salesmen want no messages and no requests
for permission.
5) You can do all this in a plain MSI you just need to do it properly.
I would if I could. Please explain.
Kurt
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, June 09, 2010 11:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSI vs Windows 7 UAC
1 - Post the Custom Action WiX code. Could be a number of things.
2 - See 1.
3 - That's expected behaviour. Windows Installer won't request elevation
until it needs to which is when the InstallExecuteSequence starts (hence
anything needing elevation should be in the InstallExecuteSequence
between InstallInitialize InstallFinalize). It's never always
elevated unless you launch your msi from an elevated process e.g.
command prompt started with Run as Administrator or a bootstrapper
which requests elevation through a manifest. If you run
Re: [WiX-users] MSI vs Windows 7 UAC
OK. Duh. Forgot to add Impersonate=no to the #1 custom action... Now
it's good.
Brain is a little scrambled trying to come up to speed on Code Composer
and finish this stuff for Windows 7. Two wildly divergent tasks...
Thanks for all your help!!!
-Original Message-
From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com]
Sent: Thursday, June 10, 2010 7:06 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSI vs Windows 7 UAC
Thanks. I got confused and thought Impersonate=no was the default.
Good coding practice is to be explicit about key parameters, default
value or not. That took care of #2 #4.
I guess we all will now have to put up with #3.
#1 is the real failure and continues to fail. This looks like a serious
error in the WiX handling of custom actions. I understand only a
little. I know that custom actions, and any dependent assemblies, are
placed in a temporary directory with the name custom action dll file
name=#. Apparently this mechanism is failing under UAC in Windows 7.
I would guess that the directory creation and file copy are not being
elevated. This will fail if Program Files is read only to the current
user. This confuses me because the user is required to be an
administrator because we are installing drivers.
Also, there is a current bug where the directory is not removed after
the custom action is done.
Kurt
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Wednesday, June 09, 2010 6:06 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] MSI vs Windows 7 UAC
A couple of observations:
Add Impersonate=no to your CustomAction declarations. That attribute
defaults to yes. You are impersonating the installing user instead of
running those CAs as SYSTEM.
Normally custom actions are run from the Binary table instead of the
File
table, unless you also need them outside of your installation. DTF CAs
require write access to the directory that the DLL is run from. For CAs
run
from the Binary table, Windows Installer places them in a location
appropriate for the impersonation-level the CA will run at. For File
table
CAs, you have to ensure that. If a deferred CA is impersonating the
installing user, it will lose elevation if that wasn't supplied before
invoking MSI.
-Original Message-
From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com]
Sent: Wednesday, June 09, 2010 12:30 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSI vs Windows 7 UAC
1)
DirectoryRef Id=APPLICATIONDIRECTORY
Component Id=CustomAction.Install.WiX
Guid={5B6CBC69-4EA2-4648-A080-8D2027BAB081}
File Id=$(var.CustomAction.Install.WiX.TargetName)
Source=$(var.CustomAction.Install.WiX.TargetDir)$(var.CustomAction.Inst
all.WiX.TargetName).CA.dll /
/Component
/DirectoryRef
CustomAction Id=CAInstall
FileKey=$(var.CustomAction.Install.WiX.TargetName)
DllEntry=CAInstall Execute=commit /
CustomAction Id=CAUninstall
FileKey=$(var.CustomAction.Install.WiX.TargetName)
DllEntry=CAUninstall Execute=deferred /
InstallExecuteSequence
!-- Run CAInstall after InstallFiles only if the product was not
installed (i.e. do not run on uninstall) --
Custom Action=CAInstall Before=InstallFinalizeNOT
Installed/Custom
!-- Run CAInstall after InstallFiles only if the product was
installed (i.e. only run on uninstall) --
Custom Action=CAUninstall
Before=RemoveFilesInstalled/Custom
/InstallExecuteSequence
2)
DirectoryRef Id=PYROCAMDIRECTORY
Component Id=PyrocamIII
Guid=21324FF8-D573-4811-A7E8-DB9A58274EAD
File
Source=$(var.SolutionDir)..\..\Installations\Source\Pyrocam III Device
Driver 1.1.0.0\InstallII.exe /
/Component
/DirectoryRef
CustomAction Id=InstallII
Directory=PYROCAMDIRECTORY
ExeCommand=[PYROCAMDIRECTORY]InstallII.exe
Execute=deferred
Return=ignore /
InstallExecuteSequence
Custom Action=InstallII After=InstallFilesNOT
Installed/Custom
/InstallExecuteSequence
InstallExecuteSequence
Custom Action=ReenumPyrocam After=InstallFilesNOT
Installed/Custom
/InstallExecuteSequence
3,4) As I said, very annoying and looks unprofessional. The thought is
that there is something wrong with my installation which is why Windows
7 has to ask permission. This is a cause for concern and phone calls.
As a result, my supervisor and salesmen want no messages and no requests
for permission.
5) You can do all this in a plain MSI you just need to do it properly.
I would if I could. Please explain.
Kurt
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, June 09, 2010 11:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSI vs Windows 7 UAC
1 - Post the Custom Action WiX code. Could be a number
Re: [WiX-users] MSI vs Windows 7 UAC
I don't necessarily agree with the UAC design. For me it disrupts my thought process and workflow. After I click/double-click some action I am thinking about the task to be completed. Then some dialog pops up wanting me to stop and decide if I was the initiator. Or worse, if I want to allow some access whose consequences I really do not understand. I could play dumb and just click OK. But any dialog could be an indicator of something wrong. So I stop, think, then click OK. Now my workflow has been completely disrupted. And I'm trying to remember what I intended to do. Of course, it could just be me... It is more secure when used properly. But it annoys me enough to just turn it off. This is why -my- test of the installation worked just fine but QA found a problem...my fault for not restoring the default. And yes, we will be signing the MSI so that the error message is a little less scary. Thanks again! Kurt Jensen Senior Software Engineer Ophir-Spiricon Ph: 435-755-5429 Cell: 435-764-2122 www.ophir-spiricon.com kurt.jen...@ophir-spiricon.com The True Measure of Laser Performance(tm) -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Thursday, June 10, 2010 9:33 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSI vs Windows 7 UAC It's not a matter of putting up with #3, that's basic functionality of UAC Windows Installer on UAC systems. It won't elevate until it's good ready to do something which needs elevation. If it did always run msiexec permanently elevated there would be legions of people complaining about how insecure it is. FYI this isn't a new thing, it's been around since the release of Vista in January 2007. Just because you're used to the laziness that Windows XP/2000/NT4 allowed doesn't mean it was ever right or good or proper that you're now being forced to adhere to the guidelines instead of Microsoft simply asking you nicely to. BTW signing your MSI will make the UAC prompt look more friendly/less scary/more professional to your users. Last time we purchased a code signing certificate it cost us less than $200 for a 3 year certificate from Comodo (through author.tucows.com) but that was in early 2008 so prices/offers may have changed since then. 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: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: 10 June 2010 16:11 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSI vs Windows 7 UAC OK. Duh. Forgot to add Impersonate=no to the #1 custom action... Now it's good. Brain is a little scrambled trying to come up to speed on Code Composer and finish this stuff for Windows 7. Two wildly divergent tasks... Thanks for all your help!!! -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, June 10, 2010 7:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSI vs Windows 7 UAC Thanks. I got confused and thought Impersonate=no was the default. Good coding practice is to be explicit about key parameters, default value or not. That took care of #2 #4. I guess we all will now have to put up with #3. #1 is the real failure and continues to fail. This looks like a serious error in the WiX handling of custom actions. I understand only a little. I know that custom actions, and any dependent assemblies, are placed in a temporary directory with the name custom action dll file name=#. Apparently this mechanism is failing under UAC in Windows 7. I would guess that the directory creation and file copy are not being elevated. This will fail if Program Files is read only to the current user. This confuses me because the user is required to be an administrator because we are installing drivers. Also, there is a current bug where the directory is not removed after the custom action is done. Kurt -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, June 09, 2010 6:06 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] MSI vs Windows 7 UAC A couple of observations: Add Impersonate=no to your CustomAction declarations. That attribute defaults to yes. You are impersonating the installing user instead of running those CAs as SYSTEM. Normally custom actions are run from the Binary table instead of the File table, unless you also need them outside of your installation. DTF CAs require write access to the directory that the DLL is run from. For CAs run from the Binary table, Windows Installer places them in a location
Re: [WiX-users] MSI vs Windows 7 UAC
Yeah, I know. Somehow I managed to almost completely avoid Vista. And our previous installer was InstallShield 6.31. Now I'm up to my neck in MSI, WiX, and Windows 7. Some of this is just bruising from the learning curve. Glad there is someone out there who can see past the bruising... -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, June 10, 2010 11:51 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSI vs Windows 7 UAC Ironically enough, the point of the UAC *is* to disrupt your process and *force* you to think about what you are doing. If you just play dumb and click OK or if you just disable UAC, then you have made a choice and taken deliberate action to lower the security level offered by UAC. This is a change in behavior for most of us, but as Pally said, it doesn't make it wrong. You'll still need to play by the UAC rules when you are designing/authoring an installer for consumption by other parties, regardless of whether you agree with the UAC design or not. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, June 10, 2010 9:03 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSI vs Windows 7 UAC I don't necessarily agree with the UAC design. For me it disrupts my thought process and workflow. After I click/double-click some action I am thinking about the task to be completed. Then some dialog pops up wanting me to stop and decide if I was the initiator. Or worse, if I want to allow some access whose consequences I really do not understand. I could play dumb and just click OK. But any dialog could be an indicator of something wrong. So I stop, think, then click OK. Now my workflow has been completely disrupted. And I'm trying to remember what I intended to do. Of course, it could just be me... It is more secure when used properly. But it annoys me enough to just turn it off. This is why -my- test of the installation worked just fine but QA found a problem...my fault for not restoring the default. And yes, we will be signing the MSI so that the error message is a little less scary. Thanks again! Kurt Jensen Senior Software Engineer Ophir-Spiricon Ph: 435-755-5429 Cell: 435-764-2122 www.ophir-spiricon.com kurt.jen...@ophir-spiricon.com The True Measure of Laser Performance(tm) -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Thursday, June 10, 2010 9:33 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSI vs Windows 7 UAC It's not a matter of putting up with #3, that's basic functionality of UAC Windows Installer on UAC systems. It won't elevate until it's good ready to do something which needs elevation. If it did always run msiexec permanently elevated there would be legions of people complaining about how insecure it is. FYI this isn't a new thing, it's been around since the release of Vista in January 2007. Just because you're used to the laziness that Windows XP/2000/NT4 allowed doesn't mean it was ever right or good or proper that you're now being forced to adhere to the guidelines instead of Microsoft simply asking you nicely to. BTW signing your MSI will make the UAC prompt look more friendly/less scary/more professional to your users. Last time we purchased a code signing certificate it cost us less than $200 for a 3 year certificate from Comodo (through author.tucows.com) but that was in early 2008 so prices/offers may have changed since then. 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: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: 10 June 2010 16:11 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSI vs Windows 7 UAC OK. Duh. Forgot to add Impersonate=no to the #1 custom action... Now it's good. Brain is a little scrambled trying to come up to speed on Code Composer and finish this stuff for Windows 7. Two wildly divergent tasks... Thanks for all your help!!! -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, June 10, 2010 7:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSI vs Windows 7 UAC Thanks. I got confused and thought Impersonate=no was the default. Good coding practice
[WiX-users] MSI vs Windows 7 UAC
First I need some guidance. I have several problems which all appear related to dealing with UAC on Windows 7. But they may each require separate solutions. Should I post these separately? 1) On a Windows 7 computer with the default UAC setting, my installation appears to be failing because SFXCA fails to extract my custom action to a temporary directory. The relevant messages I get in the log are: SFXCA: Extracting custom action to temporary directory: C:\Program Files\Spiricon\BeamGage Standard\CustomAction.Install.WiX.CA.dll-9\ SFXCA: Failed to extract to temporary directory. Cabinet error code 11. CustomAction CAInstall returned actual error code 1603 This message is followed immediately by Rollback messages. 2) We use a program, written many years ago, that calls CM_Reenumerate_DevNode in order to simulate Find New Hardware. Originally I thought that this program was causing the install to fail but I removed it and found the failure described above. When I tried to just run it, UAC said it needed elevated privileges. When I ran it as administrator it appeared to execute without error. But, I keep an error message in the log as if it was not being run at elevated privileges. I thought deferred custom actions, and Impersonate=no, were executed with elevated privileges. Any ideas how I can debug this? 3) When I click through the installation dialogs, I always get a UAC dialog before the actual install starts. I always thought MSI was elevated and would just run. My MSI is not (yet) signed. Would this help? 4) I am using a third tool to install third part drivers. I run this tool three times. And three times I get a UAC dialog. This is not only annoying, it looks very unprofessional. This tool is run in a custom action. Again, I thought deferred custom actions were executed with elevated privileges. Please note that I am using WiX v3.0. TIA! Kurt Jensen Senior Software Engineer Ophir-Spiricon Ph: 435-755-5429 Cell: 435-764-2122 www.ophir-spiricon.com http://www.ophir-spiricon.com/ kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSI vs Windows 7 UAC
P.S. I have incorporated the tools in 2-4, without any of these problems, in our current installation using Visual Studio vdproj. Surely there is some setting I am missing but have not found yet. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, June 09, 2010 10:23 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] MSI vs Windows 7 UAC First I need some guidance. I have several problems which all appear related to dealing with UAC on Windows 7. But they may each require separate solutions. Should I post these separately? 1) On a Windows 7 computer with the default UAC setting, my installation appears to be failing because SFXCA fails to extract my custom action to a temporary directory. The relevant messages I get in the log are: SFXCA: Extracting custom action to temporary directory: C:\Program Files\Spiricon\BeamGage Standard\CustomAction.Install.WiX.CA.dll-9\ SFXCA: Failed to extract to temporary directory. Cabinet error code 11. CustomAction CAInstall returned actual error code 1603 This message is followed immediately by Rollback messages. 2) We use a program, written many years ago, that calls CM_Reenumerate_DevNode in order to simulate Find New Hardware. Originally I thought that this program was causing the install to fail but I removed it and found the failure described above. When I tried to just run it, UAC said it needed elevated privileges. When I ran it as administrator it appeared to execute without error. But, I keep an error message in the log as if it was not being run at elevated privileges. I thought deferred custom actions, and Impersonate=no, were executed with elevated privileges. Any ideas how I can debug this? 3) When I click through the installation dialogs, I always get a UAC dialog before the actual install starts. I always thought MSI was elevated and would just run. My MSI is not (yet) signed. Would this help? 4) I am using a third tool to install third part drivers. I run this tool three times. And three times I get a UAC dialog. This is not only annoying, it looks very unprofessional. This tool is run in a custom action. Again, I thought deferred custom actions were executed with elevated privileges. Please note that I am using WiX v3.0. TIA! Kurt Jensen Senior Software Engineer Ophir-Spiricon Ph: 435-755-5429 Cell: 435-764-2122 www.ophir-spiricon.com http://www.ophir-spiricon.com/ kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSI vs Windows 7 UAC
1)
DirectoryRef Id=APPLICATIONDIRECTORY
Component Id=CustomAction.Install.WiX
Guid={5B6CBC69-4EA2-4648-A080-8D2027BAB081}
File Id=$(var.CustomAction.Install.WiX.TargetName)
Source=$(var.CustomAction.Install.WiX.TargetDir)$(var.CustomAction.Inst
all.WiX.TargetName).CA.dll /
/Component
/DirectoryRef
CustomAction Id=CAInstall
FileKey=$(var.CustomAction.Install.WiX.TargetName)
DllEntry=CAInstall Execute=commit /
CustomAction Id=CAUninstall
FileKey=$(var.CustomAction.Install.WiX.TargetName)
DllEntry=CAUninstall Execute=deferred /
InstallExecuteSequence
!-- Run CAInstall after InstallFiles only if the product was not
installed (i.e. do not run on uninstall) --
Custom Action=CAInstall Before=InstallFinalizeNOT
Installed/Custom
!-- Run CAInstall after InstallFiles only if the product was
installed (i.e. only run on uninstall) --
Custom Action=CAUninstall
Before=RemoveFilesInstalled/Custom
/InstallExecuteSequence
2)
DirectoryRef Id=PYROCAMDIRECTORY
Component Id=PyrocamIII
Guid=21324FF8-D573-4811-A7E8-DB9A58274EAD
File
Source=$(var.SolutionDir)..\..\Installations\Source\Pyrocam III Device
Driver 1.1.0.0\InstallII.exe /
/Component
/DirectoryRef
CustomAction Id=InstallII
Directory=PYROCAMDIRECTORY
ExeCommand=[PYROCAMDIRECTORY]InstallII.exe
Execute=deferred
Return=ignore /
InstallExecuteSequence
Custom Action=InstallII After=InstallFilesNOT
Installed/Custom
/InstallExecuteSequence
InstallExecuteSequence
Custom Action=ReenumPyrocam After=InstallFilesNOT
Installed/Custom
/InstallExecuteSequence
3,4) As I said, very annoying and looks unprofessional. The thought is
that there is something wrong with my installation which is why Windows
7 has to ask permission. This is a cause for concern and phone calls.
As a result, my supervisor and salesmen want no messages and no requests
for permission.
5) You can do all this in a plain MSI you just need to do it properly.
I would if I could. Please explain.
Kurt
-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com]
Sent: Wednesday, June 09, 2010 11:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSI vs Windows 7 UAC
1 - Post the Custom Action WiX code. Could be a number of things.
2 - See 1.
3 - That's expected behaviour. Windows Installer won't request elevation
until it needs to which is when the InstallExecuteSequence starts (hence
anything needing elevation should be in the InstallExecuteSequence
between InstallInitialize InstallFinalize). It's never always
elevated unless you launch your msi from an elevated process e.g.
command prompt started with Run as Administrator or a bootstrapper
which requests elevation through a manifest. If you run your MSI with
basic or no UI you'll see the UAC prompt immediately since there's no
InstallUISequence being run.
4 - see 1 2.
Sounds to me like your vdproj is either scheduling stuff correctly or
(more likely) is taking the easy way out running everything always
fully elevated due to a manifest in its setup.exe. You can do all this
in a plain MSI you just need to do it properly.
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: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com]
Sent: 09 June 2010 17:54
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] MSI vs Windows 7 UAC
P.S. I have incorporated the tools in 2-4, without any of these
problems, in our current installation using Visual Studio vdproj.
Surely there is some setting I am missing but have not found yet.
-Original Message-
From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com]
Sent: Wednesday, June 09, 2010 10:23 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] MSI vs Windows 7 UAC
First I need some guidance. I have several problems which all appear
related to dealing with UAC on Windows 7. But they may each require
separate solutions. Should I post these separately?
1) On a Windows 7 computer with the default UAC setting, my installation
appears to be failing because SFXCA fails to extract my custom action to
a temporary directory. The relevant messages I get in the log are:
SFXCA: Extracting custom action to temporary directory: C:\Program
Files\Spiricon\BeamGage
Standard\CustomAction.Install.WiX.CA.dll-9\
SFXCA: Failed to extract to temporary directory. Cabinet error code
11.
CustomAction CAInstall returned actual error code 1603
[WiX-users] including the wrong include during tfsbuild
background: My solution can be built three ways in order to create three editions of the product. This is accomplished by specifying one of three command line parameters during the compile of one of our components. All other components query this one in order to find out which edition we are. In addition I have created three wixproj in order to build the installation for each of these editions. One project contains most of the wxs components. The other projects share these wxs files by adding them to the project as links. In order to differentiate the editions I define a project variable, BGProductName, in a file called BGInclude.wxi - one for each wixproj. The wxi is then included in some of the shared wxs in order to create directories, shortcuts, etc. This works fine when building from the IDE. In other words, the project specific wxi is included when each of the wixproj is built in the IDE. problem: Under TFSBuild the BGInclude.wxi residing in the same folder as the wxs files is being included for every wixproj. It should be including the wxi from the folder where the project resides. I probably need to investigate a lot more, but maybe someone has a quick insight into how this could 'fixed'. Kurt Jensen Senior Software Engineer Ophir-Spiricon Ph: 435-755-5429 Cell: 435-764-2122 www.ophir-spiricon.com http://www.ophir-spiricon.com/ kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] including the wrong include during tfsbuild
I'm going to try putting the project directory first in the include paths to see if that fixes it. Let y'all know the result. BTW. Did you know that changing the order of the include paths does not cause the wixproj to be checked out? I had to edit the wixproj by had to change the order. Running the build now... -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, May 27, 2010 11:45 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] including the wrong include during tfsbuild background: My solution can be built three ways in order to create three editions of the product. This is accomplished by specifying one of three command line parameters during the compile of one of our components. All other components query this one in order to find out which edition we are. In addition I have created three wixproj in order to build the installation for each of these editions. One project contains most of the wxs components. The other projects share these wxs files by adding them to the project as links. In order to differentiate the editions I define a project variable, BGProductName, in a file called BGInclude.wxi - one for each wixproj. The wxi is then included in some of the shared wxs in order to create directories, shortcuts, etc. This works fine when building from the IDE. In other words, the project specific wxi is included when each of the wixproj is built in the IDE. problem: Under TFSBuild the BGInclude.wxi residing in the same folder as the wxs files is being included for every wixproj. It should be including the wxi from the folder where the project resides. I probably need to investigate a lot more, but maybe someone has a quick insight into how this could 'fixed'. Kurt Jensen Senior Software Engineer Ophir-Spiricon Ph: 435-755-5429 Cell: 435-764-2122 www.ophir-spiricon.com http://www.ophir-spiricon.com/ kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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
Re: [WiX-users] including the wrong include during tfsbuild
Build failed. adding the wixproj path as the first Include Path did not help. Will do some more digging into the context... -Original Message- From: Kurt Jensen Sent: Thursday, May 27, 2010 3:47 PM To: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] including the wrong include during tfsbuild I'm going to try putting the project directory first in the include paths to see if that fixes it. Let y'all know the result. BTW. Did you know that changing the order of the include paths does not cause the wixproj to be checked out? I had to edit the wixproj by had to change the order. Running the build now... -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, May 27, 2010 11:45 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] including the wrong include during tfsbuild background: My solution can be built three ways in order to create three editions of the product. This is accomplished by specifying one of three command line parameters during the compile of one of our components. All other components query this one in order to find out which edition we are. In addition I have created three wixproj in order to build the installation for each of these editions. One project contains most of the wxs components. The other projects share these wxs files by adding them to the project as links. In order to differentiate the editions I define a project variable, BGProductName, in a file called BGInclude.wxi - one for each wixproj. The wxi is then included in some of the shared wxs in order to create directories, shortcuts, etc. This works fine when building from the IDE. In other words, the project specific wxi is included when each of the wixproj is built in the IDE. problem: Under TFSBuild the BGInclude.wxi residing in the same folder as the wxs files is being included for every wixproj. It should be including the wxi from the folder where the project resides. I probably need to investigate a lot more, but maybe someone has a quick insight into how this could 'fixed'. Kurt Jensen Senior Software Engineer Ophir-Spiricon Ph: 435-755-5429 Cell: 435-764-2122 www.ophir-spiricon.com http://www.ophir-spiricon.com/ kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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
Re: [WiX-users] The system cannot find the file 'Restrictions.wxi'with type 'include'.
Duh! I forgot about that. That was what I did to get the one project to build... Thanks Blair! -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, May 25, 2010 4:13 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] The system cannot find the file 'Restrictions.wxi'with type 'include'. No, not at all, but if you add the property IncludeSearchPaths that contains a semi-colon delimited list of paths to search for .wxi files to the wixproj that fails that might resolve the issue. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Tuesday, May 25, 2010 12:33 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The system cannot find the file 'Restrictions.wxi' with type 'include'. In my VS2008 solution I have three wixproj. One of these projects contains a file called Restrictions.wxi. The other two projects reference the existing Restrictions.wxi file as a link so that there is only one actual copy. One project referencing the file as a link compiles ok. Another project referencing the file as a link does not compile, The system cannot find the file 'Restrictions.wxi' with type 'include'. I have compared the two wixproj, the code for the link and include is the same. Any ideas why this is not working? This file contains code for restricting the operating system and requiring the user to be administrator. Perhaps there is another way to accomplish the same purpose...? Kurt ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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 -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] The system cannot find the file 'Restrictions.wxi' with type 'include'.
In my VS2008 solution I have three wixproj. One of these projects contains a file called Restrictions.wxi. The other two projects reference the existing Restrictions.wxi file as a link so that there is only one actual copy. One project referencing the file as a link compiles ok. Another project referencing the file as a link does not compile, The system cannot find the file 'Restrictions.wxi' with type 'include'. I have compared the two wixproj, the code for the link and include is the same. Any ideas why this is not working? This file contains code for restricting the operating system and requiring the user to be administrator. Perhaps there is another way to accomplish the same purpose...? Kurt ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msbuild command line parameters
E�ޭ��z�w�~D�nE�M4�/8��A�;�_ӝ5�к�,��{)yhq�A���]��4Ӏ�㾵���|�Nt�_B��3*�r���ƥ�5�P��@@�v ��...@�
��Ja��7�Mv�^�N:Ӿ���9�]} �5�*'�'���_6�QA�0t델� A�N��0���^�מz�HX�
�\��\��$~��r�]��4Ӏ�㾵���|�Nt�_B� s*�r���ƥ�ͻP} :�n9�uӽ�
��~4ׯ5�]B�/W(��!y� �眢`w�~D�nE�M4�/8��A�;�_ӝ5�н�|��{)yhq�u�n� CN�ێA� t�n� 1xߍ5��y]0 ��+��^rG�y�(�_6�QA�0t델� A�N��0���^�בuߞHX�
�\��\��$~��r�]��4Ӏ�㾵���|�Nt�_B��*�r���ƥ�ͻP} :�n9�uӽ�
��~4ׯ5�]x2�/W(��!y� �眢`w�~D�nE�M4�/8��A�;�_ӝ5�Ѐ ���{)yhq�A���]��4Ӏ�㾵���|�nt�...@�*�r���ƥ�ͻp}
:�n9�uӽ� ��~4ׯ5�μ���/W(��!y� �眢`w�~D�nE�M4�/8��A�;�_ӝ5�Ё
��{)yhq�u�n� CN�ێA� t�n� 1xߍ5��z����0 ��+��^rG�y�(�Z蘫��ʺ�Iz{ ��a��)w(�:zw�jWb�ˬ�*'~�֊wh��'�֥���0�h�[ ���ǫ�X���(�� ~��zw�grin
:) I was having the same problem with density. Glad we can find understanding.
I had to reverse the order of the DefineConstants with Condition otherwise,
when DefineConstants is empty, we end up with duplicates of
DefineDefaultConstants. Here is my new set of properties
PropertyGroup
!-- other properties --
BGBuildVersion Condition= '$(BGBuildVersion)' == ''
5.3./BGBuildVersion
DefaultDefineConstantsBGProductVersion=$(BGBuildVersion)/DefaultDefineConstants
DefineConstants Condition= '$(DefineConstants)' != ''
$(DefineConstants);$(DefaultDefineConstants)/DefineConstants
DefineConstants Condition= '$(DefineConstants)' == ''
$(DefaultDefineConstants)/DefineConstants
/PropertyGroup
This works fine in the IDE.
It still does not work for me via tfsbuild.proj. All I see on the command line
to candle is -dBG_STANDARD. If I remove DefineConstants from tfsbuild.proj
then I see -dDebug -dBGProductVersion=5.3..
Also we have gotten a bit sidetracked here. I have already figured out how to
pass BGProductName by using local wxi files. I kept on with the BGProductName
because it appears that I have two problems, 1) combining command line
parameters from tfsbuild.proj and wixproj, 2) passing a version number
generated in tfsbuild.proj into a wixproj.
The real problem is how to pass the build version into the wixproj. I want to
use a Version generated in tfsbuild.proj as the ProductVersion for my
installation. But, I am at a loss how to do this if tfsbuild will not let me
pass name=value. Should we work on one problem then the other or go at them
both at one time?
Kurt Jensen
Senior Software Engineer
Ophir-Spiricon
P.S. I removed the previous posts because it keeps saying Is being held
until the list moderator can review it for approval because Message has
implicit destination. But the moderator is not responding. I really hope
this goes through...
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.clearswift.com
**
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] cannot respond to a post
E�ޭ��z�w�~D�nE�M4�/8��A�;�_ӝ5�к�,��{)yhq�A���]��4Ӏ�㾵���|�Nt�_B��3*�r���ƥ�5�P��@@�v ��...@�
��Ja��7�Mv�^�N:Ӿ���9�]} �5�*'�'���_6�QA�0t델� A�N��0���^�מz�HX�
�\��\��$~��r�]��4Ӏ�㾵���|�Nt�_B� s*�r���ƥ�ͻP} :�n9�uӽ�
��~4ׯ5�]B�/W(��!y� �眢`w�~D�nE�M4�/8��A�;�_ӝ5�н�|��{)yhq�u�n� CN�ێA� t�n� 1xߍ5��y]0 ��+��^rG�y�(�_6�QA�0t델� A�N��0���^�בuߞHX�
�\��\��$~��r�]��4Ӏ�㾵���|�Nt�_B��*�r���ƥ�ͻP} :�n9�uӽ�
��~4ׯ5�]x2�/W(��!y� �眢`w�~D�nE�M4�/8��A�;�_ӝ5�Ѐ ���{)yhq�A���]��4Ӏ�㾵���|�nt�...@�*�r���ƥ�ͻp}
:�n9�uӽ� ��~4ׯ5�μ���/W(��!y� �眢`w�~D�nE�M4�/8��A�;�_ӝ5�Ё
��{)yhq�u�n� CN�ێA� t�n� 1xߍ5��z����0 ��+��^rG�y�(�Z蘫��ʺ�Iz{ ��a��)w(�:zw�jWb�ˬ�*'~�֊wh��'�֥���0�h�[ ���ǫ�X���(�� ~��zw�I've
tried multiple times to respond to a post, RE: [WiX-users] msbuild command
line parameters, without success. I even deleted all the previous stuff being
carried along. But every time I get a message saying that the message Is
being held until the list moderator can review it for approval because
Message has implicit destination.
But, it just sits there. The moderator is not responding.
What -exactly- does Message has implicit destination? Maybe I can fix the
post.
Kurt Jensen
Senior Software Engineer
Ophir-Spiricon
The True Measure of Laser Performance™
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.clearswift.com
**
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msbuild command line parameters
E�ޭ��z�w�~D�nE�M4�/8��A�;�_ӝ5�к�,��{)yhq�A���]��4Ӏ�㾵���|�Nt�_B��3*�r���ƥ�5�P��@@�v ��...@�
��Ja��7�Mv�^�N:Ӿ���9�]} �5�*'�'���_6�QA�0t델� A�N��0���^�מz�HX�
�\��\��$~��r�]��4Ӏ�㾵���|�Nt�_B� s*�r���ƥ�ͻP} :�n9�uӽ�
��~4ׯ5�]B�/W(��!y� �眢`w�~D�nE�M4�/8��A�;�_ӝ5�н�|��{)yhq�u�n� CN�ێA� t�n� 1xߍ5��y]0 ��+��^rG�y�(�_6�QA�0t델� A�N��0���^�בuߞHX�
�\��\��$~��r�]��4Ӏ�㾵���|�Nt�_B��*�r���ƥ�ͻP} :�n9�uӽ�
��~4ׯ5�]x2�/W(��!y� �眢`w�~D�nE�M4�/8��A�;�_ӝ5�Ѐ ���{)yhq�A���]��4Ӏ�㾵���|�nt�...@�*�r���ƥ�ͻp}
:�n9�uӽ� ��~4ׯ5�μ���/W(��!y� �眢`w�~D�nE�M4�/8��A�;�_ӝ5�Ё
��{)yhq�u�n� CN�ێA� t�n� 1xߍ5��z����0 ��+��^rG�y�(�Z蘫��ʺ�Iz{ ��a��)w(�:zw�jWb�ˬ�*'~�֊wh��'�֥���0�h�[ ���ǫ�X���(�� ~��zw�grin
:) I was having the same problem with density. Glad we can find understanding.
I had to reverse the order of the DefineConstants with Condition otherwise,
when DefineConstants is empty, we end up with duplicates of
DefineDefaultConstants. Here is my new set of properties
PropertyGroup
!-- other properties --
BGBuildVersion Condition= '$(BGBuildVersion)' == ''
5.3./BGBuildVersion
DefaultDefineConstantsBGProductVersion=$(BGBuildVersion)/DefaultDefineConstants
DefineConstants Condition= '$(DefineConstants)' != ''
$(DefineConstants);$(DefaultDefineConstants)/DefineConstants
DefineConstants Condition= '$(DefineConstants)' == ''
$(DefaultDefineConstants)/DefineConstants
/PropertyGroup
This works fine in the IDE.
It still does not work for me via tfsbuild.proj. All I see on the command line
to candle is -dBG_STANDARD. If I remove DefineConstants from tfsbuild.proj
then I see -dDebug -dBGProductVersion=5.3..
Also we have gotten a bit sidetracked here. I have already figured out how to
pass BGProductName by using local wxi files. I kept on with the BGProductName
because it appears that I have two problems, 1) combining command line
parameters from tfsbuild.proj and wixproj, 2) passing a version number
generated in tfsbuild.proj into a wixproj.
The real problem is how to pass the build version into the wixproj. I want to
use a Version generated in tfsbuild.proj as the ProductVersion for my
installation. But, I am at a loss how to do this if tfsbuild will not let me
pass name=value. Should we work on one problem then the other or go at them
both at one time?
Kurt Jensen
Senior Software Engineer
Ophir-Spiricon
The True Measure of Laser Performance™
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: Thursday, May 20, 2010 11:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] msbuild command line parameters
Sweet! That write-up was extremely useful! Steps 1-3 gave me the context I
needed. Thank you so very much! I was probably being dense.
The value passed in from tfsbuild.proj was getting overridden by the definition
in the *.wixproj which is why you got the results you got in 3). In MSBuild the
last definition of a property always wins. What you want to do is concatenate
the current value of DefineConstants (as specified in tfsbuild.proj) with the
default values you specify in *.wixproj.
Ok, here's what you want to do:
In tfsbuild.proj specify your DefineConstants like you were already doing:
SolutionToBuild
Include=$(BuildProjectFolderPath)/../../LBA/Source/AllProject/AllProject.sln
Targets/Targets
Properties
DefineConstants=BG_STANDARD;
OutDir=$(TeamBuildOutDir)BG_STANDARD\
/Properties
/SolutionToBuild
SolutionToBuild
Include=$(BuildProjectFolderPath)/../../LBA/Source/AllProject/AllProject.sln
Targets/Targets
Properties
DefineConstants=BG_PROFESSIONAL;
OutDir=$(TeamBuildOutDir)BG_PROFESSIONAL\
/Properties
/SolutionToBuild
In your *.wixproj define DefaultDefineConstants (in the first PropertyGroup).
It should include your values for WiXProductName and WiXProductVersion. Also
define DefineConstants (in the first PropertyGroup) twice using a Condition
attribute to check whether DefineConstants already had a value.
PropertyGroup
!-- other properties --
DefaultDefineConstantsWiXProductName=BeamGage
Standard;WiXProductVersion=$(WiXVersion)/DefaultDefineConstants
DefineConstants Condition= '$(DefineConstants)' == ''
$(DefaultDefineConstants)/DefineConstants
DefineConstants Condition= '$(DefineConstants)' != ''
$(DefineConstants);$(DefaultDefineConstants)/DefineConstants
/PropertyGroup
When $(DefineConstants) is not set then we set the new value of DefineConstants
to the value of DefaultDefineConstants.
When $(DefineConstants) is set (value provided by tfsbuild.proj) then we set
the new value of DefineConstants to include both the old value of
DefineConstants and the value of DefaultDefineConstants.
At this point we have the correct value of DefineConstants defined for
Release|x86 so we
Re: [WiX-users] msbuild command line parameters
References: b3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.localb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.localblu111-ds50bab6b2eb7cb593d01a6cd...@phx.gblb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.local1827ffb9db064245b9b10727dadf43401681556...@iwpmail1.corp.checkfree.comb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.local1827ffb9db064245b9b10727dadf434016815f0...@iwpmail1.corp.checkfree.comb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.local1827ffb9db064245b9b10727dadf434016815f1...@iwpmail1.corp.checkfree.com1827ffb9db064245b9b10727dadf434016815f1...@iwpmail1.corp.checkfree.comb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.local1827ffb9db064245b9b10727dadf434016815f1...@iwpmail1.corp.checkfree.comb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.localb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.local1827ffb9db064245b9b10727dadf43401681686...@iwpmail1.corp.checkfree.comB3835E125F4E 004C84761BA6 076f88050119c...@zion.spiricon.local 1827ffb9db064245b9b10727dadf43401681686...@iwpmail1.corp.checkfree.com From: Kurt Jensen kurt.jen...@ophir-spiricon.com To: wix-users@lists.sourceforge.net Z3JpbiA6KSBJIHdhcyBoYXZpbmcgdGhlIHNhbWUgcHJvYmxlbSB3aXRoIGRlbnNpdHkuICBHbGFk IHdlIGNhbiBmaW5kIHVuZGVyc3RhbmRpbmcuDQoNCkkgaGFkIHRvIHJldmVyc2UgdGhlIG9yZGVy IG9mIHRoZSBEZWZpbmVDb25zdGFudHMgd2l0aCBDb25kaXRpb24gb3RoZXJ3aXNlLCB3aGVuIERl ZmluZUNvbnN0YW50cyBpcyBlbXB0eSwgd2UgZW5kIHVwIHdpdGggZHVwbGljYXRlcyBvZiBEZWZp bmVEZWZhdWx0Q29uc3RhbnRzLiANCg0KVGhpcyB3b3JrcyBmaW5lIGluIHRoZSBJREUuDQoNCkl0 IHN0aWxsIGRvZXMgbm90IHdvcmsgZm9yIG1lIHZpYSB0ZnNidWlsZC5wcm9qLiAgQWxsIEkgc2Vl IG9uIHRoZSBjb21tYW5kIGxpbmUgdG8gY2FuZGxlIGlzICItZEJHX1NUQU5EQVJEIi4gIElmIEkg cmVtb3ZlIERlZmluZUNvbnN0YW50cyBmcm9tIHRmc2J1aWxkLnByb2ogdGhlbiBJIHNlZSAiLWRE ZWJ1ZyAtZEJHUHJvZHVjdFZlcnNpb249NS4zLjMzMzMiLg0KDQpBbHNvIHdlIGhhdmUgZ290dGVu IGEgYml0IHNpZGV0cmFja2VkIGhlcmUuICBJIGhhdmUgYWxyZWFkeSBmaWd1cmVkIG91dCBob3cg dG8gcGFzcyBCR1Byb2R1Y3ROYW1lIGJ5IHVzaW5nIGxvY2FsIHd4aSBmaWxlcy4gIEkga2VwdCBv biB3aXRoIHRoZSBCR1Byb2R1Y3ROYW1lIGJlY2F1c2UgaXQgYXBwZWFycyB0aGF0IEkgaGF2ZSB0 d28gcHJvYmxlbXMsIDEpIGNvbWJpbmluZyBjb21tYW5kIGxpbmUgcGFyYW1ldGVycyBmcm9tIHRm c2J1aWxkLnByb2ogYW5kIHdpeHByb2osIDIpIHBhc3NpbmcgYSB2ZXJzaW9uIG51bWJlciBnZW5l cmF0ZWQgaW4gdGZzYnVpbGQucHJvaiBpbnRvIGEgd2l4cHJvai4NCg0KVGhlIHJlYWwgcHJvYmxl bSBpcyBob3cgdG8gcGFzcyB0aGUgYnVpbGQgdmVyc2lvbiBpbnRvIHRoZSB3aXhwcm9qLiAgSSB3 YW50IHRvIHVzZSBhIFZlcnNpb24gZ2VuZXJhdGVkIGluIHRmc2J1aWxkLnByb2ogYXMgdGhlIFBy b2R1Y3RWZXJzaW9uIGZvciBteSBpbnN0YWxsYXRpb24uICBCdXQsIEkgYW0gYXQgYSBsb3NzIGhv dyB0byBkbyB0aGlzIGlmIHRmc2J1aWxkIHdpbGwgbm90IGxldCBtZSBwYXNzICJuYW1lPXZhbHVl Ii4gIFNob3VsZCB3ZSB3b3JrIG9uIG9uZSBwcm9ibGVtIHRoZW4gdGhlIG90aGVyIG9yIGdvIGF0 IHRoZW0gYm90aCBhdCBvbmUgdGltZT8NCg0KDQpLdXJ0IEplbnNlbg0KU2VuaW9yIFNvZnR3YXJl IEVuZ2luZWVyDQpPcGhpci1TcGlyaWNvbg0KDQpUaGUgVHJ1ZSBNZWFzdXJlIG9mIExhc2VyIFBl cmZvcm1hbmNl4oSiDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXN0cm8s IEVkd2luIEcuIChIaWxsc2Jvcm8pIFttYWlsdG86RWR3aW4uQ2FzdHJvQEZpc2Vydi5jb21dIA0K U2VudDogVGh1cnNkYXksIE1heSAyMCwgMjAxMCAxMTo0OCBBTQ0KVG86IEdlbmVyYWwgZGlzY3Vz c2lvbiBmb3IgV2luZG93cyBJbnN0YWxsZXIgWE1MIHRvb2xzZXQuDQpTdWJqZWN0OiBSZTogW1dp WC11c2Vyc10gbXNidWlsZCBjb21tYW5kIGxpbmUgcGFyYW1ldGVycw0KDQpTd2VldCEgVGhhdCB3 cml0ZS11cCB3YXMgZXh0cmVtZWx5IHVzZWZ1bCEgU3RlcHMgMS0zIGdhdmUgbWUgdGhlIGNvbnRl eHQgSSBuZWVkZWQuIFRoYW5rIHlvdSBzbyB2ZXJ5IG11Y2ghIEkgd2FzIHByb2JhYmx5IGJlaW5n IGRlbnNlLg0KDQpUaGUgdmFsdWUgcGFzc2VkIGluIGZyb20gdGZzYnVpbGQucHJvaiB3YXMgZ2V0 dGluZyBvdmVycmlkZGVuIGJ5IHRoZSBkZWZpbml0aW9uIGluIHRoZSAqLndpeHByb2ogd2hpY2gg aXMgd2h5IHlvdSBnb3QgdGhlIHJlc3VsdHMgeW91IGdvdCBpbiAzKS4gSW4gTVNCdWlsZCB0aGUg bGFzdCBkZWZpbml0aW9uIG9mIGEgcHJvcGVydHkgYWx3YXlzIHdpbnMuIFdoYXQgeW91IHdhbnQg dG8gZG8gaXMgY29uY2F0ZW5hdGUgdGhlIGN1cnJlbnQgdmFsdWUgb2YgRGVmaW5lQ29uc3RhbnRz IChhcyBzcGVjaWZpZWQgaW4gdGZzYnVpbGQucHJvaikgd2l0aCB0aGUgZGVmYXVsdCB2YWx1ZXMg eW91IHNwZWNpZnkgaW4gKi53aXhwcm9qLg0KDQpPaywgaGVyZSdzIHdoYXQgeW91IHdhbnQgdG8g ZG86DQoNCkluIHRmc2J1aWxkLnByb2ogc3BlY2lmeSB5b3VyIERlZmluZUNvbnN0YW50cyBsaWtl IHlvdSB3ZXJlIGFscmVhZHkgZG9pbmc6DQoNCjxTb2x1dGlvblRvQnVpbGQgSW5jbHVkZT0iJChC dWlsZFByb2plY3RGb2xkZXJQYXRoKS8uLi8uLi9MQkEvU291cmNlL0FsbFByb2plY3QvQWxsUHJv amVjdC5zbG4iPg0KICAgIDxUYXJnZXRzPjwvVGFyZ2V0cz4NCiAgICA8UHJvcGVydGllcz4NCiAg ICAgICAgRGVmaW5lQ29uc3RhbnRzPUJHX1NUQU5EQVJEOw0KICAgICAgICBPdXREaXI9JChUZWFt QnVpbGRPdXREaXIpQkdfU1RBTkRBUkRcDQogICAgPC9Qcm9wZXJ0aWVzPg0KPC9Tb2x1dGlvblRv QnVpbGQ+DQo8U29sdXRpb25Ub0J1aWxkIEluY2x1ZGU9IiQoQnVpbGRQcm9qZWN0Rm9sZGVyUGF0 aCkvLi4vLi4vTEJBL1NvdXJjZS9BbGxQcm9qZWN0L0FsbFByb2plY3Quc2xuIj4NCiAgICA8VGFy Z2V0cz48L1RhcmdldHM+DQogICAgPFByb3BlcnRpZXM+DQogICAgICAgIERlZmluZUNvbnN0YW50 cz1CR19QUk9GRVNTSU9OQUw7DQogICAgICAgIE91dERpcj0kKFRlYW1CdWlsZE91dERpcilCR19Q Uk9GRVNTSU9OQUxcDQogICAgPC9Qcm9wZXJ0aWVzPg0KPC9Tb2x1dGlvblRvQnVpbGQ+DQoNCklu IHlvdXIgKi53aXhwcm9qIGRlZmluZSBEZWZhdWx0RGVmaW5lQ29uc3RhbnRzIChpbiB0aGUgZmly c3QgUHJvcGVydHlHcm91cCkuIEl0IHNob3VsZCBpbmNsdWRlIHlvdXIgdmFsdWVzIGZvciBXaVhQ
Re: [WiX-users] msbuild command line parameters
References: b3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.localb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.localblu111-ds50bab6b2eb7cb593d01a6cd...@phx.gblb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.local1827ffb9db064245b9b10727dadf43401681556...@iwpmail1.corp.checkfree.comb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.local1827ffb9db064245b9b10727dadf434016815f0...@iwpmail1.corp.checkfree.comb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.local1827ffb9db064245b9b10727dadf434016815f1...@iwpmail1.corp.checkfree.com1827ffb9db064245b9b10727dadf434016815f1...@iwpmail1.corp.checkfree.comb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.local1827ffb9db064245b9b10727dadf434016815f1...@iwpmail1.corp.checkfree.comb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.localb3835e125f4e004c84761ba6076f88050119c...@zion.spiricon.local1827ffb9db064245b9b10727dadf43401681686...@iwpmail1.corp.checkfree.comB3835E125F4E 004C84761BA6 076f88050119c...@zion.spiricon.local 1827ffb9db064245b9b10727dadf43401681686...@iwpmail1.corp.checkfree.com From: Kurt Jensen kurt.jen...@ophir-spiricon.com To: wix-users@lists.sourceforge.net Z3JpbiA6KSBJIHdhcyBoYXZpbmcgdGhlIHNhbWUgcHJvYmxlbSB3aXRoIGRlbnNpdHkuICBHbGFk IHdlIGNhbiBmaW5kIHVuZGVyc3RhbmRpbmcuDQoNCkkgaGFkIHRvIHJldmVyc2UgdGhlIG9yZGVy IG9mIHRoZSBEZWZpbmVDb25zdGFudHMgd2l0aCBDb25kaXRpb24gb3RoZXJ3aXNlLCB3aGVuIERl ZmluZUNvbnN0YW50cyBpcyBlbXB0eSwgd2UgZW5kIHVwIHdpdGggZHVwbGljYXRlcyBvZiBEZWZp bmVEZWZhdWx0Q29uc3RhbnRzLiBIZXJlIGlzIG15IG5ldyBzZXQgb2YgcHJvcGVydGllcw0KDQo8 UHJvcGVydHlHcm91cD4NCiAgICA8IS0tIG90aGVyIHByb3BlcnRpZXMgLS0+ICAgIA0KICAgIDxC R0J1aWxkVmVyc2lvbiBDb25kaXRpb249IiAnJChCR0J1aWxkVmVyc2lvbiknID09ICcnICI+NS4z LjMzMzM8L0JHQnVpbGRWZXJzaW9uPg0KICAgIDxEZWZhdWx0RGVmaW5lQ29uc3RhbnRzPkJHUHJv ZHVjdFZlcnNpb249JChCR0J1aWxkVmVyc2lvbik8L0RlZmF1bHREZWZpbmVDb25zdGFudHM+DQog ICAgPERlZmluZUNvbnN0YW50cyBDb25kaXRpb249IiAnJChEZWZpbmVDb25zdGFudHMpJyAhPSAn JyAiPiQoRGVmaW5lQ29uc3RhbnRzKTskKERlZmF1bHREZWZpbmVDb25zdGFudHMpPC9EZWZpbmVD b25zdGFudHM+DQogICAgPERlZmluZUNvbnN0YW50cyBDb25kaXRpb249IiAnJChEZWZpbmVDb25z dGFudHMpJyA9PSAnJyAiPiQoRGVmYXVsdERlZmluZUNvbnN0YW50cyk8L0RlZmluZUNvbnN0YW50 cz4NCjwvUHJvcGVydHlHcm91cD4NCg0KVGhpcyB3b3JrcyBmaW5lIGluIHRoZSBJREUuDQoNCkl0 IHN0aWxsIGRvZXMgbm90IHdvcmsgZm9yIG1lIHZpYSB0ZnNidWlsZC5wcm9qLiAgQWxsIEkgc2Vl IG9uIHRoZSBjb21tYW5kIGxpbmUgdG8gY2FuZGxlIGlzICItZEJHX1NUQU5EQVJEIi4gIElmIEkg cmVtb3ZlIERlZmluZUNvbnN0YW50cyBmcm9tIHRmc2J1aWxkLnByb2ogdGhlbiBJIHNlZSAiLWRE ZWJ1ZyAtZEJHUHJvZHVjdFZlcnNpb249NS4zLjMzMzMiLg0KDQpBbHNvIHdlIGhhdmUgZ290dGVu IGEgYml0IHNpZGV0cmFja2VkIGhlcmUuICBJIGhhdmUgYWxyZWFkeSBmaWd1cmVkIG91dCBob3cg dG8gcGFzcyBCR1Byb2R1Y3ROYW1lIGJ5IHVzaW5nIGxvY2FsIHd4aSBmaWxlcy4gIEkga2VwdCBv biB3aXRoIHRoZSBCR1Byb2R1Y3ROYW1lIGJlY2F1c2UgaXQgYXBwZWFycyB0aGF0IEkgaGF2ZSB0 d28gcHJvYmxlbXMsIDEpIGNvbWJpbmluZyBjb21tYW5kIGxpbmUgcGFyYW1ldGVycyBmcm9tIHRm c2J1aWxkLnByb2ogYW5kIHdpeHByb2osIDIpIHBhc3NpbmcgYSB2ZXJzaW9uIG51bWJlciBnZW5l cmF0ZWQgaW4gdGZzYnVpbGQucHJvaiBpbnRvIGEgd2l4cHJvai4NCg0KVGhlIHJlYWwgcHJvYmxl bSBpcyBob3cgdG8gcGFzcyB0aGUgYnVpbGQgdmVyc2lvbiBpbnRvIHRoZSB3aXhwcm9qLiAgSSB3 YW50IHRvIHVzZSBhIFZlcnNpb24gZ2VuZXJhdGVkIGluIHRmc2J1aWxkLnByb2ogYXMgdGhlIFBy b2R1Y3RWZXJzaW9uIGZvciBteSBpbnN0YWxsYXRpb24uICBCdXQsIEkgYW0gYXQgYSBsb3NzIGhv dyB0byBkbyB0aGlzIGlmIHRmc2J1aWxkIHdpbGwgbm90IGxldCBtZSBwYXNzICJuYW1lPXZhbHVl Ii4gIFNob3VsZCB3ZSB3b3JrIG9uIG9uZSBwcm9ibGVtIHRoZW4gdGhlIG90aGVyIG9yIGdvIGF0 IHRoZW0gYm90aCBhdCBvbmUgdGltZT8NCg0KDQpLdXJ0IEplbnNlbg0KU2VuaW9yIFNvZnR3YXJl IEVuZ2luZWVyDQpPcGhpci1TcGlyaWNvbg0KDQpUaGUgVHJ1ZSBNZWFzdXJlIG9mIExhc2VyIFBl cmZvcm1hbmNl4oSiDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXN0cm8s IEVkd2luIEcuIChIaWxsc2Jvcm8pIFttYWlsdG86RWR3aW4uQ2FzdHJvQEZpc2Vydi5jb21dIA0K U2VudDogVGh1cnNkYXksIE1heSAyMCwgMjAxMCAxMTo0OCBBTQ0KVG86IEdlbmVyYWwgZGlzY3Vz c2lvbiBmb3IgV2luZG93cyBJbnN0YWxsZXIgWE1MIHRvb2xzZXQuDQpTdWJqZWN0OiBSZTogW1dp WC11c2Vyc10gbXNidWlsZCBjb21tYW5kIGxpbmUgcGFyYW1ldGVycw0KDQpTd2VldCEgVGhhdCB3 cml0ZS11cCB3YXMgZXh0cmVtZWx5IHVzZWZ1bCEgU3RlcHMgMS0zIGdhdmUgbWUgdGhlIGNvbnRl eHQgSSBuZWVkZWQuIFRoYW5rIHlvdSBzbyB2ZXJ5IG11Y2ghIEkgd2FzIHByb2JhYmx5IGJlaW5n IGRlbnNlLg0KDQpUaGUgdmFsdWUgcGFzc2VkIGluIGZyb20gdGZzYnVpbGQucHJvaiB3YXMgZ2V0 dGluZyBvdmVycmlkZGVuIGJ5IHRoZSBkZWZpbml0aW9uIGluIHRoZSAqLndpeHByb2ogd2hpY2gg aXMgd2h5IHlvdSBnb3QgdGhlIHJlc3VsdHMgeW91IGdvdCBpbiAzKS4gSW4gTVNCdWlsZCB0aGUg bGFzdCBkZWZpbml0aW9uIG9mIGEgcHJvcGVydHkgYWx3YXlzIHdpbnMuIFdoYXQgeW91IHdhbnQg dG8gZG8gaXMgY29uY2F0ZW5hdGUgdGhlIGN1cnJlbnQgdmFsdWUgb2YgRGVmaW5lQ29uc3RhbnRz IChhcyBzcGVjaWZpZWQgaW4gdGZzYnVpbGQucHJvaikgd2l0aCB0aGUgZGVmYXVsdCB2YWx1ZXMg eW91IHNwZWNpZnkgaW4gKi53aXhwcm9qLg0KDQpPaywgaGVyZSdzIHdoYXQgeW91IHdhbnQgdG8g ZG86DQoNCkluIHRmc2J1aWxkLnByb2ogc3BlY2lmeSB5b3VyIERlZmluZUNvbnN0YW50cyBsaWtl IHlvdSB3ZXJlIGFscmVhZHkgZG9pbmc6DQoNCjxTb2x1dGlvblRvQnVpbGQgSW5jbHVkZT0iJChC dWlsZFByb2plY3RGb2xkZXJQYXRoKS8uLi8uLi9MQkEvU291cmNlL0FsbFByb2plY3QvQWxsUHJv amVjdC5zbG4iPg0KICAgIDxUYXJnZXRzPjwvVGFyZ2V0cz4NCiAgICA8UHJvcGVydGllcz4NCiAg
Re: [WiX-users] msbuild command line parameters
Maybe someone should TFS again. Seems pretty obvious that part is broken. My tfsbuild.proj is pretty standard. I've only included the relevant sections. ItemGroup !-- SOLUTIONS The paths of the solutions to build. Paths can be server paths or local paths, but server paths relative to the location of this file are highly recommended. To add/delete solutions, edit this ItemGroup. For example, to add a solution MySolution.sln, add the following line: SolutionToBuild Include=$(BuildProjectFolderPath)/path/MySolution.sln / To change the order in which the solutions are built, modify the order in which the solutions appear below. To call a target (or targets) other than the default, add a metadata item named Targets. To pass custom properties to the solution, add a metadata item named Properties. For example, to call the targets MyCustomTarget1 and MyCustomTarget2, passing in properties Property1 and Property2, add the following: SolutionToBuild Include=$(BuildProjectFolderPath)/path/MySolution.sln TargetsMyCustomTarget1;MyCustomTarget2/Targets PropertiesProperty1=Value1;Property2=Value2/Properties /SolutionToBuild -- SolutionToBuild Include=$(BuildProjectFolderPath)/../../LBA/Source/AllProject/AllProject.sln Targets/Targets Properties DefineConstants=BG_STANDARD; OutDir=$(TeamBuildOutDir)BG_STANDARD\ /Properties /SolutionToBuild SolutionToBuild Include=$(BuildProjectFolderPath)/../../LBA/Source/AllProject/AllProject.sln Targets/Targets Properties DefineConstants=BG_PROFESSIONAL; OutDir=$(TeamBuildOutDir)BG_PROFESSIONAL\ /Properties /SolutionToBuild /ItemGroup ItemGroup !-- CONFIGURATIONS The list of configurations to build. To add/delete configurations, edit this value. For example, to add a new configuration, add the following lines: ConfigurationToBuild Include=Debug|x86 FlavorToBuildDebug/FlavorToBuild PlatformToBuildx86/PlatformToBuild /ConfigurationToBuild The Include attribute value should be unique for each ConfigurationToBuild node. -- ConfigurationToBuild Include=Release|Any CPU FlavorToBuildRelease/FlavorToBuild PlatformToBuildAny CPU/PlatformToBuild /ConfigurationToBuild /ItemGroup and someone asked that I include this target Target Name=BeforeBuild CreateProperty Value=BGProductName=BeamGage Standard;$(DefineConstants) Output TaskParameter=Value PropertyName=DefineConstants / /CreateProperty /Target I see BG_STANDARD passed to all the csproj and wixproj. But I still do not see BGProductName in the build log or on the command line. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, May 19, 2010 1:37 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters What does your TFS build file look like? I don't have TFS but I have used it in the past. I'll do the best I can. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, May 19, 2010 12:19 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters Yes, the definitions all have values. And yes, it works fine from the IDE. I too see -dWiXProductName=BeamGage Standard -dWiXProductVersion=5.3.3782 on the command line to candle when run from the IDE or via msbuild on my development machine. But, with the identical wixproj, neither of the -d appears on the command line to candle when run from msbuild under TFS. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, May 19, 2010 12:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters I see I wasn't clear about WiXProductVersion before. I wish I had the ability to edit email that was already sent... Anyways... WiXProductVersion doesn't have a value on the candle command line because $(WiXVersion) was not defined in my project file. I assume that WiXVersion is defined in your project file. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, May 19, 2010 11:29 AM To: General discussion
Re: [WiX-users] msbuild command line parameters
OK. I have a much easier repro scenario. I tried simply running msbuild on my tfsbuild.proj (after all this time I did not know you could do that...) And it failed in exactly the same way - DefineConstants in the wixproj are not included on the command line to candle. Unless a fix is coming this week I will have to find some other solution. I will repost my question that got no response. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, May 20, 2010 8:11 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters Maybe someone should TFS again. Seems pretty obvious that part is broken. My tfsbuild.proj is pretty standard. I've only included the relevant sections. ItemGroup !-- SOLUTIONS The paths of the solutions to build. Paths can be server paths or local paths, but server paths relative to the location of this file are highly recommended. To add/delete solutions, edit this ItemGroup. For example, to add a solution MySolution.sln, add the following line: SolutionToBuild Include=$(BuildProjectFolderPath)/path/MySolution.sln / To change the order in which the solutions are built, modify the order in which the solutions appear below. To call a target (or targets) other than the default, add a metadata item named Targets. To pass custom properties to the solution, add a metadata item named Properties. For example, to call the targets MyCustomTarget1 and MyCustomTarget2, passing in properties Property1 and Property2, add the following: SolutionToBuild Include=$(BuildProjectFolderPath)/path/MySolution.sln TargetsMyCustomTarget1;MyCustomTarget2/Targets PropertiesProperty1=Value1;Property2=Value2/Properties /SolutionToBuild -- SolutionToBuild Include=$(BuildProjectFolderPath)/../../LBA/Source/AllProject/AllProject.sln Targets/Targets Properties DefineConstants=BG_STANDARD; OutDir=$(TeamBuildOutDir)BG_STANDARD\ /Properties /SolutionToBuild SolutionToBuild Include=$(BuildProjectFolderPath)/../../LBA/Source/AllProject/AllProject.sln Targets/Targets Properties DefineConstants=BG_PROFESSIONAL; OutDir=$(TeamBuildOutDir)BG_PROFESSIONAL\ /Properties /SolutionToBuild /ItemGroup ItemGroup !-- CONFIGURATIONS The list of configurations to build. To add/delete configurations, edit this value. For example, to add a new configuration, add the following lines: ConfigurationToBuild Include=Debug|x86 FlavorToBuildDebug/FlavorToBuild PlatformToBuildx86/PlatformToBuild /ConfigurationToBuild The Include attribute value should be unique for each ConfigurationToBuild node. -- ConfigurationToBuild Include=Release|Any CPU FlavorToBuildRelease/FlavorToBuild PlatformToBuildAny CPU/PlatformToBuild /ConfigurationToBuild /ItemGroup and someone asked that I include this target Target Name=BeforeBuild CreateProperty Value=BGProductName=BeamGage Standard;$(DefineConstants) Output TaskParameter=Value PropertyName=DefineConstants / /CreateProperty /Target I see BG_STANDARD passed to all the csproj and wixproj. But I still do not see BGProductName in the build log or on the command line. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, May 19, 2010 1:37 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters What does your TFS build file look like? I don't have TFS but I have used it in the past. I'll do the best I can. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, May 19, 2010 12:19 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters Yes, the definitions all have values. And yes, it works fine from the IDE. I too see -dWiXProductName=BeamGage Standard -dWiXProductVersion=5.3.3782 on the command line to candle when run from the IDE or via msbuild on my development machine. But, with the identical wixproj, neither of the -d appears on the command line to candle when run from msbuild under TFS. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, May 19, 2010 12:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters I see I wasn't clear about WiXProductVersion before
[WiX-users] cannot respond to a post
I've tried multiple times to respond to a post, RE: [WiX-users] msbuild command line parameters, without success. I even deleted all the previous stuff being carried along. But every time I get a message saying that the message Is being held until the list moderator can review it for approval because Message has implicit destination. But, it just sits there. The moderator is not responding. What -exactly- does Message has implicit destination? Maybe I can fix the post. Kurt ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] cannot respond to a post
never mind...I guess...it worked sending to wix-users@lists.sourceforge.net but did not work replying to General discussion for Windows Installer XML toolset wix-users@lists.sourceforge.net -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, May 20, 2010 2:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] cannot respond to a post I've tried multiple times to respond to a post, RE: [WiX-users] msbuild command line parameters, without success. I even deleted all the previous stuff being carried along. But every time I get a message saying that the message Is being held until the list moderator can review it for approval because Message has implicit destination. But, it just sits there. The moderator is not responding. What -exactly- does Message has implicit destination? Maybe I can fix the post. Kurt ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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
Re: [WiX-users] cannot respond to a post
I take that back. I was trying to respond to a post when this problem occurred. After thinking that it was the email address, it's still not working. I posted another response to a different post and now it is hung up until the list moderator can review it for approval. Has the list gone crazy? If it has then you can't answer that questions. Great. I love mail lists... -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, May 20, 2010 2:37 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] cannot respond to a post never mind...I guess...it worked sending to wix-users@lists.sourceforge.net but did not work replying to General discussion for Windows Installer XML toolset wix-users@lists.sourceforge.net -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, May 20, 2010 2:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] cannot respond to a post I've tried multiple times to respond to a post, RE: [WiX-users] msbuild command line parameters, without success. I even deleted all the previous stuff being carried along. But every time I get a message saying that the message Is being held until the list moderator can review it for approval because Message has implicit destination. But, it just sits there. The moderator is not responding. What -exactly- does Message has implicit destination? Maybe I can fix the post. Kurt ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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 -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] cannot respond to a post
I've been trying for 3 hours to post a response to your last message about the msbuild command line problem. Every post comes back with message has implicit destination. I cannot see anything wrong according to your link. I'll keep trying the response... :( -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, May 20, 2010 3:20 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] cannot respond to a post FYI: I found this: What does message has implicit destination mean? http://wiki.list.org/pages/viewpage.action?pageId=4030676 Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Thursday, May 20, 2010 1:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] cannot respond to a post I've tried multiple times to respond to a post, RE: [WiX-users] msbuild command line parameters, without success. I even deleted all the previous stuff being carried along. But every time I get a message saying that the message Is being held until the list moderator can review it for approval because Message has implicit destination. But, it just sits there. The moderator is not responding. What -exactly- does Message has implicit destination? Maybe I can fix the post. Kurt ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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 -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msbuild command line parameters
I'm having trouble getting the build to behave right now... In the mean time, this was the source I was following http://www.ageektrapped.com/blog/setting-properties-for-wix-in-msbuild/ I am assuming that this worked at the time it was written. But now it does not work? -Original Message- From: Kurt Jensen Sent: Tuesday, May 18, 2010 2:41 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] msbuild command line parameters I'll try. It is being built under VS2008 and TFS2008. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Tuesday, May 18, 2010 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters Can you make a minimal *.wixproj that reproduces the problem? I don't see anything obvious in the information you've already shared. I just looked through the wix.targets and wix2010.targets files in case something is happening there that would account for what you are seeing but didn't find anything obvious either. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Tuesday, May 18, 2010 1:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters Good idea but still not appearing in the build log. Any more ideas out there? -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, May 17, 2010 10:14 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] msbuild command line parameters I haven't tested it, but I wonder if the whitespace is causing problems. What happens if you try: DefineConstantsWiXProductName=quot;BeamGage Professionalquot;;WiXProductVersion=$(WiXVersion)/DefineConstants Or: DefineConstantsquot;WiXProductName=BeamGage Professionalquot;;WiXProductVersion=$(WiXVersion)/DefineConstants ? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 3:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters The PropertyGroup code is as follows: PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Release|x86' OutputPathbin\$(Configuration)\/OutputPath IntermediateOutputPathobj\$(Configuration)\/IntermediateOutputPath DefineConstantsWiXProductName=BeamGage Professional;WiXProductVersion=$(WiXVersion);/DefineConstants /PropertyGroup I changed IntermediateOutputPath to obj\IntermediateOutputPath. The command line in the build log now specifies -out obj\IntermediateOutputPath\module.wixobj. That proves that the PropertyGroup containing DefineConstants is being executed. I should be seeing -dWixProductName= and -dWixProductVersion= on the command line. Any idea why the DefineConstants is not being passed to candle? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 3:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] msbuild command line parameters I'm trying to build my wixproj in msbuild. The solution ConfigurationToBuild is Release|Any CPU. Inside of my configuration the wixproj is built as Release|x86. In my wixproj I have a 'Release|x86' PropertyGroup that includes DefineConstants. But none of the DefineConstants are being included on the command line to candle during the build. The PropertyGroup and DefineConstants work fine in the IDE. In the build log I verified that the command line contains -dConfiguration=Release and -dPlatform=x86. Any idea how to get the wixproj DefineConstants passed to candle in msbuild? Kurt Jensen ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** --- - -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- - -- ___ WiX-users mailing list WiX-users
[WiX-users] sharing strings among components
Since using DefineConstants in msbuild appears to be a dead end, maybe someone can suggest another approach. Our VS2008 solution can be built for three different products - Standard, Professional, and Enterprise - depending on a compiler constant sent to each csproj and wixproj - BG_STANDARD, BG_PROFESSIONAL, and BG_ENTERPRISE respectively. I can configure this as separate SolutionToBuild with an appropriate DefineConstants and OutDir in tfsbuild.proj. I have created a separate wixproj for the installation of each of these. They all share common components some of which require the string name of the product in order to create directories, name shortcuts, etc. In the wixproj I used candle DefineConstants to set BGProductName=BeamGage Standard which is then accessed in the components as $(var.BGProductName). This works fine in the IDE but fails under msbuild as described in another recent thread. Any ideas how I can pass these strings from one main component to various other common components? Kurt Jensen Senior Software Engineer Ophir-Spiricon www.ophir-spiricon.com http://www.ophir-spiricon.com/ kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msbuild command line parameters
Repro is simple. From a default wixproj created in VS2008, I added the following PropertyGroup WixToolPath$(MSBuildProjectDirectory)\..\..\..\Installations\WiX\Windows Installer XML v3\bin\/WixToolPath WixTargetsPath$(WixToolPath)Wix.targets/WixTargetsPath WixTasksPath$(WixToolPath)wixtasks.dll/WixTasksPath IncludeSearchPaths /IncludeSearchPaths /PropertyGroup and PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Release|x86' OutputPathbin\$(Configuration)\/OutputPath IntermediateOutputPathobj\$(Configuration)\/IntermediateOutputPath DefineConstants WiXProductName=amp;quot;BeamGage Standardamp;quot;; WiXProductVersion=$(WiXVersion);/DefineConstants /PropertyGroup I am using WiX v3.0. When I run this wixproj under msbuild the DefineConstants are NOT included on the command line to candle. I have verified that the IntermediateOutputPath is processed. That was it. I was building our solution including a similar, previous wixproj that did not require the DefineConstants. I am at a dead end. I do not know what to do. Where else can I go for help? -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, May 19, 2010 9:39 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters I've successfully used DefineConstants before. I used it to provide external paths to locations I was harvesting. Of course, a repo would be nice. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, May 19, 2010 7:30 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters I'm having trouble getting the build to behave right now... In the mean time, this was the source I was following http://www.ageektrapped.com/blog/setting-properties-for-wix-in-msbuild/ I am assuming that this worked at the time it was written. But now it does not work? -Original Message- From: Kurt Jensen Sent: Tuesday, May 18, 2010 2:41 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] msbuild command line parameters I'll try. It is being built under VS2008 and TFS2008. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Tuesday, May 18, 2010 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters Can you make a minimal *.wixproj that reproduces the problem? I don't see anything obvious in the information you've already shared. I just looked through the wix.targets and wix2010.targets files in case something is happening there that would account for what you are seeing but didn't find anything obvious either. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Tuesday, May 18, 2010 1:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters Good idea but still not appearing in the build log. Any more ideas out there? -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, May 17, 2010 10:14 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] msbuild command line parameters I haven't tested it, but I wonder if the whitespace is causing problems. What happens if you try: DefineConstantsWiXProductName=quot;BeamGage Professionalquot;;WiXProductVersion=$(WiXVersion)/DefineConstants Or: DefineConstantsquot;WiXProductName=BeamGage Professionalquot;;WiXProductVersion=$(WiXVersion)/DefineConstants ? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 3:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters The PropertyGroup code is as follows: PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Release|x86' OutputPathbin\$(Configuration)\/OutputPath IntermediateOutputPathobj\$(Configuration)\/IntermediateOutputPath DefineConstantsWiXProductName=BeamGage Professional;WiXProductVersion=$(WiXVersion);/DefineConstants /PropertyGroup I changed IntermediateOutputPath to obj\IntermediateOutputPath. The command line in the build log now specifies -out obj\IntermediateOutputPath
Re: [WiX-users] msbuild command line parameters
: Project: WixProject1, Configuration: Release x86 - - C:\Program Files\Windows Installer XML v3\bin\candle.exe - dWixProductName=BeamGage Standard -dWiXProductVersion= - dDevEnvDir=C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\\ - dSolutionDir=C:\code\WixProject1\ -dSolutionExt=.sln - dSolutionFileName=WixProject1.sln -dSolutionName=WixProject1 - dSolutionPath=C:\code\WixProject1\WixProject1.sln -dConfiguration=Release - dOutDir=bin\Release\ -dPlatform=x86 - dProjectDir=C:\code\WixProject1\WixProject1\ -dProjectExt=.wixproj - dProjectFileName=WixProject1.wixproj -dProjectName=WixProject1 - dProjectPath=C:\code\WixProject1\WixProject1\WixProject1.wixproj - dTargetDir=C:\code\WixProject1\WixProject1\bin\Release\ -dTargetExt=.msi - dTargetFileName=WixProject1.msi -dTargetName=WixProject1 - dTargetPath=C:\code\WixProject1\WixProject1\bin\Release\WixProject1.msi -out obj\Release\Product.wixobj -arch x86 Product.wxs C:\Program Files\Windows Installer XML v3\bin\Light.exe - cultures:null -out C:\code\WixProject1\WixProject1\bin\Release\WixProject1.msi -pdbout C:\code\WixProject1\WixProject1\bin\Release\WixProject1.wixpdb obj\Release\Product.wixobj C:\code\WixProject1\WixProject1\Product.wxs(6,0): warning LGHT1079: The cabinet 'media1.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please add files to the cabinet or remove it. == Rebuild All: 1 succeeded, 0 failed, 0 skipped == I see them: -dWiXProductName=BeamGage Standard -dWiXProductVersion= Note that $(WiXVersion) in my project file so I would expect not to see a value on the command line. I assume you are defining the WiXVersion property in your project. I ran msbuild on the command line (I'll only show the output for the candle task for brevity): msbuild .\WixProject1.sln /t:rebuild /v:detailed Task Candle Command: C:\Program Files\Windows Installer XML v3\bin\candle.exe -dDebug - dWixProductName=BeamGage Standard -dWiXProductVersion= - dDevEnvDir=c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE -dSolutionDir=C:\code\WixProject1\ -dSolutionExt=.sln - dSolutionFileName=WixProject1.sln -dSolutionName=WixProject1 - dSolutionPath=C:\code\WixProject1\WixProjec t1.sln -dConfiguration=Debug -dOutDir=bin\Debug\ -dPlatform=x86 - dProjectDir=C:\code\WixProject1\WixProject1\ -dProjectExt=.wixproj - dProjectFileName=WixProject1.wixproj -dProje ctName=WixProject1 - dProjectPath=C:\code\WixProject1\WixProject1\WixProject1.wixproj - dTargetDir=C:\code\WixProject1\WixProject1\bin\Debug\ -dTargetExt=.msi - dTargetFileName=Wix Project1.msi -dTargetName=WixProject1 - dTargetPath=C:\code\WixProject1\WixProject1\bin\Debug\WixProject1.msi -out obj\Debug\Product.wixobj -arch x86 Product.wxs Microsoft (R) Windows Installer Xml Compiler version 3.0.5419.0 Copyright (C) Microsoft Corporation. All rights reserved. Product.wxs Done executing task Candle. msbuild .\WixProject1.sln /t:rebuild /v:detailed /p:Configuration=Release Task Candle Command: C:\Program Files\Windows Installer XML v3\bin\candle.exe - dWixProductName=BeamGage Standard -dWiXProductVersion= - dDevEnvDir=c:\Program Files\Microsoft Visual Studio 9.0\Comm on7\IDE -dSolutionDir=C:\code\WixProject1\ -dSolutionExt=.sln - dSolutionFileName=WixProject1.sln -dSolutionName=WixProject1 - dSolutionPath=C:\code\WixProject1\WixProject1.sln - dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 - dProjectDir=C:\code\WixProject1\WixProject1\ -dProjectExt=.wixproj - dProjectFileName=WixProject1.wixproj -dProjectNa me=WixProject1 - dProjectPath=C:\code\WixProject1\WixProject1\WixProject1.wixproj - dTargetDir=C:\code\WixProject1\WixProject1\bin\Release\ -dTargetExt=.msi - dTargetFileName=WixPr oject1.msi -dTargetName=WixProject1 - dTargetPath=C:\code\WixProject1\WixProject1\bin\Release\WixProject1.msi -out obj\Release\Product.wixobj -arch x86 Product.wxs Microsoft (R) Windows Installer Xml Compiler version 3.0.5419.0 Copyright (C) Microsoft Corporation. All rights reserved. Product.wxs Done executing task Candle. I see them here too: -dWiXProductName=BeamGage Standard -dWiXProductVersion= That's the behavior I expected. Am I missing something? Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, May 19, 2010 9:11 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters Repro is simple. From a default wixproj created in VS2008, I added the following PropertyGroup WixToolPath$(MSBuildProjectDirectory)\..\..\..\Installations\WiX
Re: [WiX-users] msbuild command line parameters
This looks promising. 1) Where does it would go? wixproj? wxs? tfsbuild.proj? 2) I am building the solution twice, can it be specified for each SolutionToBuild? -Original Message- From: Alex Ivanoff [mailto:alex.ivan...@shavlik.com] Sent: Tuesday, May 18, 2010 2:19 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters CreateProperty Value=WiXProductName=BeamGage Professional;WiXProductVersion=$(WiXVersion);$(DefineConstants) Output TaskParameter=Value PropertyName=DefineConstants / /CreateProperty -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] sharing strings among components
Sorry. I accidently responded to myself... Yes I did try it. But it did not work. Originally I was trying to go this way. But apparently msbuild has a problem with the wix property=value construct as described in this link. http://stackoverflow.com/questions/506687/defining-multiple-values-in-de fineconstants-in-msbuild-element That is why I am now looking DefineConstants in the wixproj -Original Message- From: Alex Ivanoff [mailto:alex.ivan...@shavlik.com] Sent: Wednesday, May 19, 2010 10:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] sharing strings among components Forgot to say that this needs to be in BeforeBuild target. -Original Message- From: Alex Ivanoff Sent: Wednesday, May 19, 2010 11:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] sharing strings among components Did you try my suggestion? CreateProperty Value=WiXProductName=BeamGage Professional;WiXProductVersion=$(WiXVersion);$(DefineConstants) Output TaskParameter=Value PropertyName=DefineConstants / /CreateProperty -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, May 19, 2010 09:44 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] sharing strings among components Since using DefineConstants in msbuild appears to be a dead end, maybe someone can suggest another approach. Our VS2008 solution can be built for three different products - Standard, Professional, and Enterprise - depending on a compiler constant sent to each csproj and wixproj - BG_STANDARD, BG_PROFESSIONAL, and BG_ENTERPRISE respectively. I can configure this as separate SolutionToBuild with an appropriate DefineConstants and OutDir in tfsbuild.proj. I have created a separate wixproj for the installation of each of these. They all share common components some of which require the string name of the product in order to create directories, name shortcuts, etc. In the wixproj I used candle DefineConstants to set BGProductName=BeamGage Standard which is then accessed in the components as $(var.BGProductName). This works fine in the IDE but fails under msbuild as described in another recent thread. Any ideas how I can pass these strings from one main component to various other common components? Kurt Jensen Senior Software Engineer Ophir-Spiricon www.ophir-spiricon.com http://www.ophir-spiricon.com/ kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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 -- ___ 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
Re: [WiX-users] sharing strings among components
That response may be ambiguous. I already have a DefineConstants in my Properties under SolutionToBuild. I added the CreateProperty under an existing BuildNumberOverrideTarget target. The existing DefineConstants appears in the buildlog and on the various command lines. The CreateProperty values are nowhere to be seen. Just for fun I will try putting CreateProperty under BeforeBuild and remove the existing DefineConstants. -Original Message- From: Kurt Jensen Sent: Wednesday, May 19, 2010 10:27 AM To: General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] sharing strings among components Sorry. I accidently responded to myself... Yes I did try it. But it did not work. Originally I was trying to go this way. But apparently msbuild has a problem with the wix property=value construct as described in this link. http://stackoverflow.com/questions/506687/defining-multiple-values-in-de fineconstants-in-msbuild-element That is why I am now looking DefineConstants in the wixproj -Original Message- From: Alex Ivanoff [mailto:alex.ivan...@shavlik.com] Sent: Wednesday, May 19, 2010 10:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] sharing strings among components Forgot to say that this needs to be in BeforeBuild target. -Original Message- From: Alex Ivanoff Sent: Wednesday, May 19, 2010 11:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] sharing strings among components Did you try my suggestion? CreateProperty Value=WiXProductName=BeamGage Professional;WiXProductVersion=$(WiXVersion);$(DefineConstants) Output TaskParameter=Value PropertyName=DefineConstants / /CreateProperty -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, May 19, 2010 09:44 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] sharing strings among components Since using DefineConstants in msbuild appears to be a dead end, maybe someone can suggest another approach. Our VS2008 solution can be built for three different products - Standard, Professional, and Enterprise - depending on a compiler constant sent to each csproj and wixproj - BG_STANDARD, BG_PROFESSIONAL, and BG_ENTERPRISE respectively. I can configure this as separate SolutionToBuild with an appropriate DefineConstants and OutDir in tfsbuild.proj. I have created a separate wixproj for the installation of each of these. They all share common components some of which require the string name of the product in order to create directories, name shortcuts, etc. In the wixproj I used candle DefineConstants to set BGProductName=BeamGage Standard which is then accessed in the components as $(var.BGProductName). This works fine in the IDE but fails under msbuild as described in another recent thread. Any ideas how I can pass these strings from one main component to various other common components? Kurt Jensen Senior Software Engineer Ophir-Spiricon www.ophir-spiricon.com http://www.ophir-spiricon.com/ kurt.jen...@ophir-spiricon.com mailto:kenneth.fer...@ophir-spiricon.com The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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 -- ___ 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
Re: [WiX-users] wixlib
I did try those. I have two component groups in the wixlib. I moved the component groups from being part of the project to the wixlib. But, candle gave an error. Of course, this morning it works fine... Maybe I forgot to build the wixlib. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Monday, May 17, 2010 5:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] wixlib The only thing I would add to that is that you need to add a ref to the fragments that you want to include in your main project. You could add PropertyRef or CustomActionRef or any of the other ref elements. These references are what includes the fragments into your main project. Try adding ComponentRef, ComponentGroupRef, FeatureRef, or FeatureGroupRef to your product.wxs to include the fragments that contain the components. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 4:00 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] wixlib Yes, I have created a separate WixLib project and added a reference. Now, how do I include the WixLib components so that I can reference them in the Feature? -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Monday, May 17, 2010 4:50 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] wixlib I assume that you found the Adding WiX References topic in the WiX help: http://wix.sourceforge.net/manual-wix3/votive_wix_references.htm The only thing I would add to that is that you need to add a ref to the fragments that you want to include in your main project. You could add PropertyRef or CustomActionRef or any of the other ref elements. These references are what includes the fragments into your main project. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 3:11 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] wixlib I'm trying to understand wixlib. I've spent an hour searching do, web, and archives. After I create a wixlib, how do I include it in my installation? Kurt Jensen ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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 --- --- ___ 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 -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msbuild command line parameters
Good idea but still not appearing in the build log. Any more ideas out there? -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, May 17, 2010 10:14 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] msbuild command line parameters I haven't tested it, but I wonder if the whitespace is causing problems. What happens if you try: DefineConstantsWiXProductName=quot;BeamGage Professionalquot;;WiXProductVersion=$(WiXVersion)/DefineConstants Or: DefineConstantsquot;WiXProductName=BeamGage Professionalquot;;WiXProductVersion=$(WiXVersion)/DefineConstants ? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 3:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters The PropertyGroup code is as follows: PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Release|x86' OutputPathbin\$(Configuration)\/OutputPath IntermediateOutputPathobj\$(Configuration)\/IntermediateOutputPath DefineConstantsWiXProductName=BeamGage Professional;WiXProductVersion=$(WiXVersion);/DefineConstants /PropertyGroup I changed IntermediateOutputPath to obj\IntermediateOutputPath. The command line in the build log now specifies -out obj\IntermediateOutputPath\module.wixobj. That proves that the PropertyGroup containing DefineConstants is being executed. I should be seeing -dWixProductName= and -dWixProductVersion= on the command line. Any idea why the DefineConstants is not being passed to candle? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 3:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] msbuild command line parameters I'm trying to build my wixproj in msbuild. The solution ConfigurationToBuild is Release|Any CPU. Inside of my configuration the wixproj is built as Release|x86. In my wixproj I have a 'Release|x86' PropertyGroup that includes DefineConstants. But none of the DefineConstants are being included on the command line to candle during the build. The PropertyGroup and DefineConstants work fine in the IDE. In the build log I verified that the command line contains -dConfiguration=Release and -dPlatform=x86. Any idea how to get the wixproj DefineConstants passed to candle in msbuild? Kurt Jensen ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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 -- ___ 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
Re: [WiX-users] msbuild command line parameters
I'll try. It is being built under VS2008 and TFS2008. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Tuesday, May 18, 2010 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters Can you make a minimal *.wixproj that reproduces the problem? I don't see anything obvious in the information you've already shared. I just looked through the wix.targets and wix2010.targets files in case something is happening there that would account for what you are seeing but didn't find anything obvious either. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Tuesday, May 18, 2010 1:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters Good idea but still not appearing in the build log. Any more ideas out there? -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, May 17, 2010 10:14 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] msbuild command line parameters I haven't tested it, but I wonder if the whitespace is causing problems. What happens if you try: DefineConstantsWiXProductName=quot;BeamGage Professionalquot;;WiXProductVersion=$(WiXVersion)/DefineConstants Or: DefineConstantsquot;WiXProductName=BeamGage Professionalquot;;WiXProductVersion=$(WiXVersion)/DefineConstants ? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 3:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] msbuild command line parameters The PropertyGroup code is as follows: PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Release|x86' OutputPathbin\$(Configuration)\/OutputPath IntermediateOutputPathobj\$(Configuration)\/IntermediateOutputPath DefineConstantsWiXProductName=BeamGage Professional;WiXProductVersion=$(WiXVersion);/DefineConstants /PropertyGroup I changed IntermediateOutputPath to obj\IntermediateOutputPath. The command line in the build log now specifies -out obj\IntermediateOutputPath\module.wixobj. That proves that the PropertyGroup containing DefineConstants is being executed. I should be seeing -dWixProductName= and -dWixProductVersion= on the command line. Any idea why the DefineConstants is not being passed to candle? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 3:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] msbuild command line parameters I'm trying to build my wixproj in msbuild. The solution ConfigurationToBuild is Release|Any CPU. Inside of my configuration the wixproj is built as Release|x86. In my wixproj I have a 'Release|x86' PropertyGroup that includes DefineConstants. But none of the DefineConstants are being included on the command line to candle during the build. The PropertyGroup and DefineConstants work fine in the IDE. In the build log I verified that the command line contains -dConfiguration=Release and -dPlatform=x86. Any idea how to get the wixproj DefineConstants passed to candle in msbuild? Kurt Jensen ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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 --- - -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- ___ WiX-users mailing list
[WiX-users] wixlib
I'm trying to understand wixlib. I've spent an hour searching do, web, and archives. After I create a wixlib, how do I include it in my installation? Kurt Jensen ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] msbuild command line parameters
The PropertyGroup code is as follows: PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Release|x86' OutputPathbin\$(Configuration)\/OutputPath IntermediateOutputPathobj\$(Configuration)\/IntermediateOutputPath DefineConstantsWiXProductName=BeamGage Professional;WiXProductVersion=$(WiXVersion);/DefineConstants /PropertyGroup I changed IntermediateOutputPath to obj\IntermediateOutputPath. The command line in the build log now specifies -out obj\IntermediateOutputPath\module.wixobj. That proves that the PropertyGroup containing DefineConstants is being executed. I should be seeing -dWixProductName= and -dWixProductVersion= on the command line. Any idea why the DefineConstants is not being passed to candle? -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 3:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] msbuild command line parameters I'm trying to build my wixproj in msbuild. The solution ConfigurationToBuild is Release|Any CPU. Inside of my configuration the wixproj is built as Release|x86. In my wixproj I have a 'Release|x86' PropertyGroup that includes DefineConstants. But none of the DefineConstants are being included on the command line to candle during the build. The PropertyGroup and DefineConstants work fine in the IDE. In the build log I verified that the command line contains -dConfiguration=Release and -dPlatform=x86. Any idea how to get the wixproj DefineConstants passed to candle in msbuild? Kurt Jensen ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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
Re: [WiX-users] wixlib
Yes, I have created a separate WixLib project and added a reference. Now, how do I include the WixLib components so that I can reference them in the Feature? -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Monday, May 17, 2010 4:50 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] wixlib I assume that you found the Adding WiX References topic in the WiX help: http://wix.sourceforge.net/manual-wix3/votive_wix_references.htm The only thing I would add to that is that you need to add a ref to the fragments that you want to include in your main project. You could add PropertyRef or CustomActionRef or any of the other ref elements. These references are what includes the fragments into your main project. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Monday, May 17, 2010 3:11 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] wixlib I'm trying to understand wixlib. I've spent an hour searching do, web, and archives. After I create a wixlib, how do I include it in my installation? Kurt Jensen ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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 -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Files with the same name
I have two similar problems 1) I want to install two files with the same name into two respective folders. The solution stores the same file under two different projects. The current vdproj installation references the two files and puts them into their separate folders. But light throws an error if it finds two files with the same name regardless of the directory or component. 2) I need to include files with the same name in the installation. Right now they go into win32 win64 folders then are manually loaded depending on the OS. We want to move to installing the appropriate DLL and automatic loading. I will probably install one or the other depending on 32- or 64-bit. But, again, light throws an error if any two fiules have the same name regardless of directory of component. How do I include two files with the same name? TIA Kurt ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Files with the same name
Thanks Will - I was confusing Id and Name and Source. Thanks Chad - You're right. The first problem has nothing to do with OS. I will have to study the 32- vs 64-bit problem some more. Kurt -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Wednesday, May 12, 2010 11:41 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Files with the same name Kurt - I have several files in one (huge) installer called web.config. Each is a completely different file internally and each in their own Directory and Component with unique GUID. What's the error message you are getting? What version of WiX? I think I've read on here that you can't write one installer that supports both 32-bit and 64-bit, but I might have misunderstood what others were saying. Or perhaps the attempt is leading to the problem? Chad -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, May 12, 2010 10:07 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Files with the same name I have two similar problems 1) I want to install two files with the same name into two respective folders. The solution stores the same file under two different projects. The current vdproj installation references the two files and puts them into their separate folders. But light throws an error if it finds two files with the same name regardless of the directory or component. 2) I need to include files with the same name in the installation. Right now they go into win32 win64 folders then are manually loaded depending on the OS. We want to move to installing the appropriate DLL and automatic loading. I will probably install one or the other depending on 32- or 64-bit. But, again, light throws an error if any two fiules have the same name regardless of directory of component. How do I include two files with the same name? TIA Kurt ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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 -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Integrating WiX Projects Into Daily Builds
I'm now trying to include my wixproj with the daily builds. But it is telling me it cannot find Microsoft.Deployment.WindowsInstaller when trying to build a custom action. I deployed the tools as described at http://wix.sourceforge.net/manual-wix3/daily_builds.htm. But now I am not sure what ...create a parallel directory tree... in step 5 really means. The structure I created is: my local directory Windows Installer XML v3 bin - contents of c:\Program Files\Windows Installer XML v3\bin contents of ...MSBuild\Microsoft\WiX\v[[Major]].[[Minor]] sdk - contents of c:\Program Files\Windows Installer XML v3\sdk ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Integrating WiX Projects Into Daily Builds
oops. Another assembly reference moment... I changed the reference to the file under my source control directory. Now it works fine. sorry 'bout that. -Original Message- From: Kurt Jensen [mailto:kurt.jen...@ophir-spiricon.com] Sent: Wednesday, May 12, 2010 1:40 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Integrating WiX Projects Into Daily Builds I'm now trying to include my wixproj with the daily builds. But it is telling me it cannot find Microsoft.Deployment.WindowsInstaller when trying to build a custom action. I deployed the tools as described at http://wix.sourceforge.net/manual-wix3/daily_builds.htm. But now I am not sure what ...create a parallel directory tree... in step 5 really means. The structure I created is: my local directory Windows Installer XML v3 bin - contents of c:\Program Files\Windows Installer XML v3\bin contents of ...MSBuild\Microsoft\WiX\v[[Major]].[[Minor]] sdk - contents of c:\Program Files\Windows Installer XML v3\sdk ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.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
