date:20100331

Hi,

I'm testing this on my Vista development machine but in the end my 
application should run on all OSes starting with Win2k.
I have only one ServiceControl entry, but seems that the problem is not 
the service itself but the application that the service babysits, pls 
see my answer I just sent to Nick's email in the same thread (also 
contains the generated uninstall-log).
It's an uninstall, no upgrade.

Thanks a lot,
Viv


On 3/30/2010 10:19 PM, Wilson, Phil wrote:
 I explained that there was difference between Vista and previous OS versions 
 in ServiceControl behavior, and also that there may be a bug in Vista and 
 later when you have more than one ServiceControl action. However you didn't 
 say what OS you're actually using, or whether you have more than one 
 ServiceControl entry.

 Is it an upgrade? I know you refer to uninstall, but there's also a mention 
 of install/upgrade. If it is an upgrade, where is RemoveExistingProducts 
 sequenced?

 So being nitpicky, you're repeating the question without supplying any more 
 information, so the answer to Are you saying that I don't really have a way 
 to do this? I mean the user will have to either stop manually the service 
 before an uninstall/upgrade or to reboot the machine after an 
 uninstall/upgrade? depends on the OS you're using, and if you have more than 
 one ServiceControl entry.

 a) Doing the uninstall while taking a log might be useful (msiexec /x 
 {productcode} /l*vxpath to a text log file  ) because the list of files in 
 use should give you a better picture of the files involved (which may not be 
 simply your service exe) and whether the in-use is detected at 
 InstallValidate time or at file removal time (see b and c).

 b) Sloppy programming can be an issue if there are handles open anywhere that 
 refer to the service or the process being watched. Windows can't uninstall a 
 service if there are handles open to it.

 c) If ServiceControl isn't set to wait the service may not have actually 
 shut down by the time Windows tries to delete it, a timing race. Or If the 
 service shuts down but the process lingers then the process is still there at 
 file removal time requiring a reboot to delete.

 Phil Wilson


 -Original Message-
 From: Viv Coco [mailto:vcotirl...@hotmail.com]
 Sent: Tuesday, March 30, 2010 3:08 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] stop the service before uninstall

 Hi guys,

 I really don't want to be pushy but I need to find a solution for this:
 besides my application I also install a service that is babysitting my
 application, eg: restarts it when it crashes or whatever. When the
 product is uninstalled I get the message: The setup must update files
 or services that cannot be updated while the system is running. If you
 choose to continue, a reboot will be required to complete the setup.
 even though I specify that the service should be stopped when
 uninstalling (and the service will take care to also stop my application).

 [code]
 ServiceControl Id='MyServiceControl' Name='MyServiceForTest'
 Start='install' Stop='uninstall' Remove='uninstall'/
 [/code]

 If I manually stop the service before uninstalling everything works fine.
 How can I solve this problem? I can't really ask the users to manually
 stop the service before uninstalling or to reboot the machine on every
 upgrade. How can I force the shutting down of the service?

 Thx,
 Viv ;)

 On 3/29/2010 12:21 PM, Viv Coco wrote:

On pre-Vista (pre MSI 4.0) the ServiceControl entries aren't considered 
 for files-in-use situations. On Restart Manager systems with MSI 4.0 and 
 above, it does look at the ServiceControl table but there have been some 
 reports that it doesn't work with every entry in the ServiceControl table 
 and may be unreliable.


 Are you saying that I don't really have a way to do this? I mean the user 
 will have to either stop manually the service before an uninstall/upgrade or 
 to reboot the machine after an uninstall/upgrade?

 Thx,
 Viv



 On 3/26/2010 4:17 PM, Wilson, Phil wrote:

  
 On pre-Vista (pre MSI 4.0) the ServiceControl entries aren't considered for 
 files-in-use situations. On Restart Manager systems with MSI 4.0 and above, 
 it does look at the ServiceControl table but there have been some reports 
 that it doesn't work with every entry in the ServiceControl table and may 
 be unreliable.

 Start on install and stop on install? It does both. There is a StopServices 
 action early in the execute sequence that stops services. Later on (after 
 files have been installed/replaced) there's a StartServices action.

 Phil Wilson

 -Original Message-
 From: Viv coco [mailto:vcotirl...@hotmail.com]
 Sent: Friday, March 26, 2010 2:12 AM
 To: WiX
 Subject: [WiX-users] stop the service before uninstall


 Hi,



 My installer besides my application installs also a service which is the 
 babysitter for my application, eg takes care to

Re: [WiX-users] don't delete/overwrite a file during major upgrade


  Use a Component Condition on your RemoveFile so it doesn't get 
touched during major upgrades.

Thx, I'll do so.

Viv

On 3/29/2010 1:14 PM, Pally Sandher wrote:
 What happens if your QA find bugs in your application? Do you fix those
 in the installer too?

 Use a Component Condition on your RemoveFile so it doesn't get touched
 during major upgrades. However the copy procedure Sascha explained to
 would be outside of the installation process. If you do it within the
 installer you're going to have the same problem as before.

 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 theVirtual 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: Viv Coco [mailto:vcotirl...@hotmail.com]
 Sent: 29 March 2010 11:09
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] don't delete/overwrite a file during major
 upgrade

 Hi,

 Can you install a default configuration file and then copy that to
 the user configuration if it doesn't exist?

 Well, I could do so, already thought about that, but unfortunately the
 application is already in QA so we are not allowed to change anything
 to it anymore so everything that is left has to be done through the
 installer. I know, bad decision, but unfortunately it's not my decision
 :(

 So my application needs a conf file to run correctly (MyApp.cfg) where
 the user has to set some entries (it's per machine, not per user). I was
 thinking to do like this: when installing the application I also put in
 the binary directory the MyApp.cfg.template so that the user has it for
 later reference and the same one put also under the name MyApp.cfg and
 at the end of installation through the msi to open the MyApp.conf file
 so that the user can right away set it as he needs. When he closes the
 modified conf file, installation is finished and application will run
 correctly. Is there a way to do this without getting into those
 headaches you were saying?

 Then just use RemoveFile to delete the config when your application
 is uninstalled.

 How can I do that? I mean how can I remove a file only when an real
 uninstall is done and not a major upgrade which also includes an
 uninstall before the new install?

 Thx,
 Viv


 On 3/29/2010 6:51 AM, Sascha Beaumont wrote:

 Letting the user modify installed files will cause significant
 headaches. Best solution, until you understand why, just don't do it.

 Can you install a default configuration file and then copy that to the
  

 user configuration if it doesn't exist? That way Windows Installer
 doesn't 'know' about the configuration file (except for the default
 one which shouldn't be modified) and so won't try to replace it on
 repair. Then just use RemoveFile to delete the config when your
 application is uninstalled.


 On Fri, Mar 26, 2010 at 8:08 PM, Viv cocovcotirl...@hotmail.com
  
 wrote:


  
 Hi,



 I read the WiX Tutorial from http://www.tramontana.co.hu/wix/ and

 there are some things I didn't understand or couldn't find and as I read
 that this is the best place for questions, I'll write them here, but for
 an easier followup I will write each question into a separat email. I
 appreciate your answers/help.

 When I install my application, along with the binaries, in the same

 directory a conf file is placed that the user can change as he needs.

 I would like for this conf file to not be deleted (or overwritten)

 when we do a major upgrade, but only when we remove the application
 completely from the computer, b/c otherwise the user needs to do the
 right settings in the conf file every time after an upgrade.

 In other words, for this conf file, I would like to have the

 following behaviour: when the product is upgraded (major upgrade which
 means first uninstall old version meaning deleting all installed files
 and then install a new version) the conf file should NOT be deleted  or
 overwritten. But if the user uninstalls our product, for instance from
 add/remove program, then b/c I want to clean everything I would like
 that conf file to be deleted. How could I have this behaviour?



 TIA,
 Viv


 _
 Hotmail: Trusted email with powerful SPAM protection.
 https://signup.live.com/signup.aspx?id=60969
 -
 -
 Download Intel(r) Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev

Re: [WiX-users] don't delete/overwrite a file during major upgrade

(Unfortunately it's easier said than done and took nearly two major
release cycles for the mindset to catch on here)

Yes, I know, I'm trying to get them understand that. Maybe I'll have
more luck for the next major release.

Thx,
Viv

On 3/30/2010 7:31 AM, Sascha Beaumont wrote:
If you can have the end-user customize the config file *before*
installing, you can create an MSI transform and install the modified
config file. Our customers need to customize a default config before
deploying across the network (desktop software) and so we use the
method I've described over at
http://stackoverflow.com/questions/319894/simplest-solution-to-replace-a-tiny-file-inside-an-msi

If you wanted to automate it then I'm sure you could put together some
bootstrap process that prompts the user for their choices, writes a
modified config file, wraps that up into an MST and CAB file and then
launches the MSI.

As a side note, setup *must* be considered part of the development
cycle. As soon as you have a working build, start on setup. That way
issues and problems like these are highlighted early and can be fixed
when there is still time. (Unfortunately it's easier said than done
and took nearly two major release cycles for the mindset to catch on
here)

Sascha

On Mon, Mar 29, 2010 at 9:08 PM, Viv Cocovcotirl...@hotmail.com wrote:

Hi,

Can you install a default configuration file and then copy that to
the user configuration if it doesn't exist?

Well, I could do so, already thought about that, but unfortunately the
application is already in QA so we are not allowed to change anything
to it anymore so everything that is left has to be done through the
installer. I know, bad decision, but unfortunately it's not my decision :(

So my application needs a conf file to run correctly (MyApp.cfg) where
the user has to set some entries (it's per machine, not per user). I was
thinking to do like this: when installing the application I also put in
the binary directory the MyApp.cfg.template so that the user has it for
later reference and the same one put also under the name MyApp.cfg and
at the end of installation through the msi to open the MyApp.conf file
so that the user can right away set it as he needs. When he closes the
modified conf file, installation is finished and application will run
correctly. Is there a way to do this without getting into those
headaches you were saying?

Then just use RemoveFile to delete the config when your application
is uninstalled.

How can I do that? I mean how can I remove a file only when an real
uninstall is done and not a major upgrade which also includes an
uninstall before the new install?

Thx,
Viv

On 3/29/2010 6:51 AM, Sascha Beaumont wrote:

Letting the user modify installed files will cause significant
headaches. Best solution, until you understand why, just don't do it.

Can you install a default configuration file and then copy that to the
user configuration if it doesn't exist? That way Windows Installer
doesn't 'know' about the configuration file (except for the default
one which shouldn't be modified) and so won't try to replace it on
repair. Then just use RemoveFile to delete the config when your
application is uninstalled.

On Fri, Mar 26, 2010 at 8:08 PM, Viv cocovcotirl...@hotmail.comwrote:

Hi,

I read the WiX Tutorial from http://www.tramontana.co.hu/wix/ and there
are some things I didn't understand or couldn't find and as I read that
this is the best place for questions, I'll write them here, but for an
easier followup I will write each question into a separat email. I
appreciate your answers/help.

When I install my application, along with the binaries, in the same
directory a conf file is placed that the user can change as he needs.
I would like for this conf file to not be deleted (or overwritten) when we
do a major upgrade, but only when we remove the application completely
from the computer, b/c otherwise the user needs to do the right settings
in the conf file every time after an upgrade.
In other words, for this conf file, I would like to have the following
behaviour: when the product is upgraded (major upgrade which means first
uninstall old version meaning deleting all installed files and then
install a new version) the conf file should NOT be deleted or
overwritten. But if the user uninstalls our product, for instance from
add/remove program, then b/c I want to clean everything I would like that
conf file to be deleted. How could I have this behaviour?

TIA,
Viv

_
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and

Re: [WiX-users] Upgrade mechanism

Hi,

It's actually a good idea to start with a version lower than I ever 
released, so I ended up doing like:

[code]
?define UpgradeCode = GUID?
?define CurrentVersion = 1.0.0?

Upgrade Id=$(var.UpgradeCode)
UpgradeVersion OnlyDetect=no Property=OLDAPPFOUND Minimum=0.0.1 
IncludeMinimum=yes Maximum=$(var.CurrentVersion) IncludeMaximum=no /
UpgradeVersion OnlyDetect=yes Property=NEWAPPFOUND 
Minimum=$(var.CurrentVersion) IncludeMinimum=yes /
/Upgrade
[/code]

Thanks a lot for the tip!
Viv

On 3/31/2010 12:36 AM, Curtis Jewell wrote:

 On Tue, 30 Mar 2010 13:12 +0200, Viv Cocovcotirl...@hotmail.com
 wrote:

 Hi all,

 I would like my application to be upgraded if a newer version is run. So
 the behaviour should be:  if the user tries to install the already
 installed version (meaning current version) or an older version, the
 installer should bail out with the message current or newer installed.
 The installer should run only if it's a newer version.

 For that I wrote the following:

 [code]
 Upgrade Id=$(var.UpgradeCode)
 UpgradeVersion Property=OLDAPPFOUND Minimum=1.0.0.0
 IncludeMinimum=yes Maximum=$(var.CurrentVersion) IncludeMaximum=no
 /
 UpgradeVersion Property=NEWAPPFOUND Minimum=$(var.CurrentVersion)
 IncludeMinimum=yes OnlyDetect=yes /
 /Upgrade
 [/code]

 This sounds perfect for when the CurrentVersion would be anything grater
 than 1.0.0.0, but for the version 1.0.0.0, meaning when I release my
 first version the Minimum and Maximum are the same 1.0.0.0 and in the
 first line I say IncludeMinimum=yeswhich means includes 1.0.0.0 but I
 also say IncludeMaximum=no which means exclude 1.0.0.0. Also, for
 this version (1.0.0.0) I will have both properties set (I think):
 OLDAPPFOUND and NEWAPPFOUND. Won't I get into troubles with this?
  
 I would say it would be best to set the minimum to a version lower than
 you ever released (0.0.1) to start with - and yes, I would include it.
 Start as you intend to finish.

 By the way, versions of msi files do not have a 4th portion, and will go
 from 0.0.0 up to 255.255.32767.

 --Curtis
 --
 Curtis Jewell
 swords...@csjewell.fastmail.us

 %DCL-E-MEM-BAD, bad memory
 -VMS-F-PDGERS, pudding between the ears

 [I use PC-Alpine, which deliberately does not display colors and pictures in 
 HTML mail]


 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users





--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrade mechanism

Hi Pally,

I actually wanted to have the upgrade code inside from my very first 
version, as this is the way suggested by the WiX tutorial (chapter 4.2):
Also note that this same installer works as a first time installer as 
well: if it founds a previous version, it will remove the previous 
version and install the current one. If it is run on a clean system, it 
will simply install the current application; there is no need to create 
separate upgrade and full installers.

So I ended up doing as Curtis suggested, pls see my answer to his email.

Thanks,
Viv

On 3/30/2010 1:33 PM, Pally Sandher wrote:
 You only need to put that code into your newer releases which will be
 doing the upgrading e.g. v1.0.0.1
 Your v1.0.0.0 has nothing to upgrade so the code isn't needed. I'd
 suggest commenting it out for your first release so you can add it back
 for subsequent releases.
 You may find that code doesn't pass ICE61 in your v1.0.0.0 due to
 clashing VersionMin/VersionMax. Your properties won't both be set as
 when the user installs this version there's nothing for Windows
 Installer to detect as an older version.

 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 theVirtual 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: Viv Coco [mailto:vcotirl...@hotmail.com]
 Sent: 30 March 2010 12:12
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] Upgrade mechanism

 Hi all,

 I would like my application to be upgraded if a newer version is run. So
 the behaviour should be:  if the user tries to install the already
 installed version (meaning current version) or an older version, the
 installer should bail out with the message current or newer installed.

 The installer should run only if it's a newer version.

 For that I wrote the following:

 [code]
 Upgrade Id=$(var.UpgradeCode)
 UpgradeVersion Property=OLDAPPFOUND Minimum=1.0.0.0
 IncludeMinimum=yes Maximum=$(var.CurrentVersion) IncludeMaximum=no
 /  UpgradeVersion Property=NEWAPPFOUND
 Minimum=$(var.CurrentVersion)
 IncludeMinimum=yes OnlyDetect=yes /  /Upgrade  [/code]

 This sounds perfect for when the CurrentVersion would be anything grater
 than 1.0.0.0, but for the version 1.0.0.0, meaning when I release my
 first version the Minimum and Maximum are the same 1.0.0.0 and in the
 first line I say IncludeMinimum=yeswhich means includes 1.0.0.0 but I
 also say IncludeMaximum=no which means exclude 1.0.0.0. Also, for
 this version (1.0.0.0) I will have both properties set (I think):
 OLDAPPFOUND and NEWAPPFOUND. Won't I get into troubles with this?

 Thx,
 Viv ;)

 
 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users





--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Bug with components which contain only XMLConfig elements?

Posting this in case anyone else runs into this  because I'm not sure
if this is a bug or expected behaviour.

I'm updating a plug-in installer to work with a new product which will
be imminently released. After (at least) 4 years of complaining the
developers of said product have caved in  finally moved from using a
.ini file installed alongside their product (under ProgramFilesFolder
which is lots of fun on UAC enabled systems) to supporting .addin files
under CommonAppDataFolder.

I have 3 new components, one places the .addin file (.addin files are
simple XML) in the right place, the other 2 modify a path within it
using XMLConfig.

The components look very much like the following:

DirectoryRef Id=_2011
  Component Id=_2011Addin DiskId=1 Guid=A-GUID
File Id=IESVE.addin Source=..\..\..\bin_release\IESVE.addin
/
  /Component
  Component Id=SetAddinPathx86 DiskId=1 Guid=ANOTHER-GUID
util:XmlConfig Id=SetIESVEaddinPathx86 File=[#IESVE.addin]
Action=create On=install ElementPath=/RevitAddIns/AddIn/Assembly
Node=value Value=[IESToolbar] /
  /Component
  Component Id=SetAddinPathx64 DiskId=1
Guid=YET-ANOTHER-GUID
util:XmlConfig Id=SetIESVEaddinPathx64 File=[#IESVE.addin]
Action=create On=install ElementPath=/RevitAddIns/AddIn/Assembly
Node=value Value=[IESToolbar_x64] /
  /Component
/DirectoryRef

When I build this I get 2 errors from ICE18, one for each of the
components containing XMLConfig Elements.

error LGHT0204: ICE18: KeyPath for Component: 'SetAddinPathx86' is
Directory: '_2011'. The Directory/Component pair must be listed in the
CreateFolders table.
error LGHT0204: ICE18: KeyPath for Component: 'SetAddinPathx64' is
Directory: '_2011'. The Directory/Component pair must be listed in the
CreateFolders table.

Looking at the MSI in InstEd! those 2 components do not have KeyPaths
set. I'm using WiX v3.0.5419.0  I've also run the MSI through the ICE
tests using the darice.cub from the v7.0 Windows Platform SDK which
gives the same error (as expected). I can work around this simply by
adding a RegistryValue to each component  setting it as the KeyPath for
those components but does anyone know if this is expected behaviour or a
bug with these types of components? If it's a bug let me know  I'll
submit it to the tracker on SourceForge.

Cheers,

Palbinder Sandher 
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to create a Patch?

http://wix.sourceforge.net/manual-wix3/patching.htm 

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: Carolina Zuqueto Amaral [mailto:carolina.ama...@conv.com.br] 
Sent: 30 March 2010 20:42
To: 'wix-users@lists.sourceforge.net'
Subject: [WiX-users] How to create a Patch?

Good Afternoon!

How to create a Patch?
I need to  updates  the database, to remove and to  insert programs, to
insert services in the IIS and others.

Grateful,

Carolina Zuqueto Amaral
carolina.ama...@conv.com.brmailto:carolina.ama...@conv.com.br
tel +55 21 2494-5476
cel +55 21 9524-7186




Confidencialidade: A informa??o contida nesta mensagem de e-mail,
incluindo quaisquer anexos, ? confidencial e est? reservada apenas ?
pessoa ou entidade para a qual foi endere?ada. Se voc? n?o ? o
destinat?rio ou a pessoa respons?vel por encaminhar esta mensagem ao
destinat?rio, voc? est?, por meio desta, notificado que n?o dever?
rever, retransmitir, imprimir, copiar, usar ou distribuir esta mensagem
de e-mail ou quaisquer anexos. Caso voc? tenha recebido esta mensagem
por engano, por favor, contate o remetente imediatamente e apague esta
mensagem de seu computador ou de qualquer outro banco de dados. Grato.

Confidentiality Notice: The information contained in this email message,
including any attachment, is confidential and is intended only for the
person or entity to which it is addressed. If you are neither the
intended recipient nor the employee or agent responsible for delivering
this message to the intended recipient, you are hereby notified that you
may not review, retransmit, convert to hard copy, copy, use or
distribute this email message or any attachments to it. If you have
received this email in error, please contact the sender immediately and
delete this message from any computer or other data bank. Thank you.

--
Download Intel#174; Parallel Studio Eval Try the new software tools for
yourself. Speed compiling, find bugs proactively, and fine-tune
applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Cleaning up directories other than the program directory

You're in the right area with that code. I do something similar for a
plug-in installer using the following:

DirectoryRef Id=CommonAppDataFolder
  Directory Id=A_Directory Name=A_Directory
Component Id=A_Component DiskId=1 Guid=A-GUID
  RemoveFile Id=Clean_A_Directory Name=* On=both/
  RemoveFolder Id=Remove_A_Directory On=both/
/Component
Directory Id=Another_Directory Name=Another_Directory
  Component Id=Another_Component DiskId=1
Guid=ANOTHER-GUID
RemoveFile Id=Clean_Another_Directory Name=*
On=both/
RemoveFolder Id=Remove_Another_Directory On=both/
  /Component
/Directory
  /Directory
/DirectoryRef

You may find it easier to build the Directory tree under AppDataFolder
first then inserting your Components with RemoveFile  RemoveFolder
Elements. The RemoveFile Elements with Name=* will empty the directory
of files so it can be deleted by the RemoveFolder Element (RemoveFolder
only removes empty directories). If you only want the directories to be
deleted on install change the On=both attributes to On=install in
the RemoveFile  RemoveFolder Elements (On=both deletes them on
install  uninstall).

Also AppDataFolder is the user-specific Roaming folder
(C:\Users\user.name\AppData\Roaming\ on Vista  later). To access
C:\ProgramData\ you need to use CommonAppDataFolder

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: William Newbery [mailto:firelan...@hotmail.co.uk] 
Sent: 30 March 2010 19:49
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Cleaning up directories other than the program
directory


My application keeps various files in the common app data directory
(C:\ProgramData\MyApp\ on Vista), and the users local and roaming
application directories. These are created by the application it's self
if they don't exist (Where applicable files are also created from
defaults in the main program directory, e.g. the settings.cfg file).

I want to make my installer be able to remove these directories on
install, however I'm not sure how to go about doing this.

I tried simply adding the following to my wxs file in the TARGETDIR
directory in the hope the installer would create, and thus delete it and
any contents on install/uninstall. However I got some error about a
RemoveFile table, I'm not even sure what this has to do with any file
table...

Directory Id='AppDataFolder'
Directory Id='MyAppDataFolder' Name='MyApp'

/Directory
/Directory

Is this along the right lines and I just need to work out what this
table thing is going on about, or am I going about this completely the
wrong way?
  
_
Send us your Hotmail stories and be featured in our newsletter
http://clk.atdmt.com/UKM/go/195013117/direct/01/

--
Download Intel#174; Parallel Studio Eval Try the new software tools for
yourself. Speed compiling, find bugs proactively, and fine-tune
applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode

RegSpy2 may be able to help. See
http://www.installsite.org/pages/en/msi/tips.htm about 1/3 down the
page. It'll output a .reg file which you run through tallow.exe to
output WiX code.

However I would ask the vendor of this adxloader.dll for support first.

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: Dave Brotherstone [mailto:dav...@pobox.com] 
Sent: 31 March 2010 06:42
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted,then we'll
get Error 2836 in Repair mode

On Wed, Mar 31, 2010 at 1:39 AM, little.forest
little.for...@ymail.comwrote:

 Hi All,


 I totally understand 'using regsvr32 in Wix' is not recommended. But 
 in this adxloader.dll case, we can't use tallow or heat to generate 
 fragments from the dll. This is not the problem of tallow or heat, but

 the problem of the dll. However, the dll can be registered manually by
using regsvr32.exe.
 So my question is: is there a way that we can collect the needed 
 registry information manually? If it's possible, then we can get rid
of regsvr32.


You can probably see the registry entries manually by watching regsvr32
in procmon (from sysinternals).  You'll need to convert the output to
WiX, but at least you'll see everything that is written.  Just set the
filter to procname=regsvr32, and only watch the registry.

Dave.

--
Download Intel#174; Parallel Studio Eval Try the new software tools for
yourself. Speed compiling, find bugs proactively, and fine-tune
applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Heat harvesting and fragment/component generation.

2010-03-31 Thread Richard Horsley

Previously, I have created installers in WiX by hand-writing the .wxs files 
myself, but I now have a fairly large folder structure (with lots of 
subfolders) to put into an installer, and I am trying to use heat.exe to 
harvest this for me. However the harvested file seems unnecessarily messy. Is 
there any way to get heat to place all files from the same subfolder within the 
same fragment/component, or is this not considered best practice?

Richard Horsley


 DISCLAIMER 

Please consider the environment before printing this e-mail.

This e-mail has been scanned for all known virus's but this is not a 
confirmation it is virus free.

This is an e-mail from EIC Limited (Company Reg: 1086295). The contents of this 
e-mail are confidential. EIC Limited do not accept responsibility for the 
accuracy or completeness of the contents of this e-mail as it has been 
transmitted over a public network. If you receive this e-mail in error please 
accept our apology. If this is the case we would be obliged if you would 
contact the sender and then delete this e-mail.

THIS E-MAIL AND / OR ANY REPLIES TO IT, AND ANY ATTACHMENTS MAY BE INTERCEPTED, 
COPIED OR MONITORED BY EIC LIMITED FOR THE PURPOSE OF MONITORING OR KEEPING 
RECORD OF ITS BUSINESS AND FOR THE PURPOSES SET OUT IN THE TELECOMMUNICATIONS 
(LAWFUL BUSINESS PRACTICES) (INTERCEPTION OF COMMUNICATIONS) REGULATIONS 2000.

All statements made in this e-mail are subject to contract. The contents are 
not to be regarded as a contractual offer or acceptance. The sender is not 
authorised to bind EIC Limited.

The views expressed in this e-mail are those of the sender and not necessarily 
those of EIC Limited.

 DISCLAIMER 

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] don't delete/overwrite a file during major upgrade

Hi,

While trying to do this I got into the problem of setting the correct 
condition. So in my case I want a specific file, that it's NOT installed 
by the installer, but later created by the user, to be deleted only on 
uninstalls - not upgrades, not repairs or modifies. What condition 
should I use? Is (NOT UPGRADINGPRODUCTCODE) enough or should I also 
combine it with REMOVE=ALL?

[code]
Component Id=MyRemoveConfFile Guid=GUID
RemoveFile Id=MyRemoveConf Name=*myapp.conf On=uninstall/
ConditionNOT UPGRADINGPRODUCTCODE/Condition
/Component
[/code]

Is this enough (having On=uninstall and (NOT UPGRADINGPRODUCTCODE))? 
Or the conditioning should be more extensive taking in account that it 
should happen only on real uninstall (not installs, not upgrades, not 
repairs or modifies)?

Thanks,
Viv


On 3/31/2010 10:42 AM, Viv Coco wrote:
 Use a Component Condition on your RemoveFile so it doesn't get
 touched during major upgrades.

 Thx, I'll do so.

 Viv

 On 3/29/2010 1:14 PM, Pally Sandher wrote:

 What happens if your QA find bugs in your application? Do you fix those
 in the installer too?

 Use a Component Condition on your RemoveFile so it doesn't get touched
 during major upgrades. However the copy procedure Sascha explained to
 would be outside of the installation process. If you do it within the
 installer you're going to have the same problem as before.

 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 theVirtual 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: Viv Coco [mailto:vcotirl...@hotmail.com]
 Sent: 29 March 2010 11:09
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] don't delete/overwrite a file during major
 upgrade

 Hi,

   Can you install a default configuration file and then copy that to
 the user configuration if it doesn't exist?

 Well, I could do so, already thought about that, but unfortunately the
 application is already in QA so we are not allowed to change anything
 to it anymore so everything that is left has to be done through the
 installer. I know, bad decision, but unfortunately it's not my decision
 :(

 So my application needs a conf file to run correctly (MyApp.cfg) where
 the user has to set some entries (it's per machine, not per user). I was
 thinking to do like this: when installing the application I also put in
 the binary directory the MyApp.cfg.template so that the user has it for
 later reference and the same one put also under the name MyApp.cfg and
 at the end of installation through the msi to open the MyApp.conf file
 so that the user can right away set it as he needs. When he closes the
 modified conf file, installation is finished and application will run
 correctly. Is there a way to do this without getting into those
 headaches you were saying?

   Then just use RemoveFile to delete the config when your application
 is uninstalled.

 How can I do that? I mean how can I remove a file only when an real
 uninstall is done and not a major upgrade which also includes an
 uninstall before the new install?

 Thx,
 Viv


 On 3/29/2010 6:51 AM, Sascha Beaumont wrote:

  
 Letting the user modify installed files will cause significant
 headaches. Best solution, until you understand why, just don't do it.

 Can you install a default configuration file and then copy that to the



  
 user configuration if it doesn't exist? That way Windows Installer
 doesn't 'know' about the configuration file (except for the default
 one which shouldn't be modified) and so won't try to replace it on
 repair. Then just use RemoveFile to delete the config when your
 application is uninstalled.


 On Fri, Mar 26, 2010 at 8:08 PM, Viv cocovcotirl...@hotmail.com


 wrote:

  


 Hi,



 I read the WiX Tutorial from http://www.tramontana.co.hu/wix/ and

  
 there are some things I didn't understand or couldn't find and as I read
 that this is the best place for questions, I'll write them here, but for
 an easier followup I will write each question into a separat email. I
 appreciate your answers/help.

  
 When I install my application, along with the binaries, in the same

  
 directory a conf file is placed that the user can change as he needs.

  
 I would like for this conf file to not be deleted (or overwritten)

  
 when we do a major upgrade, but only when we remove the application
 completely from the computer, b/c otherwise the user needs to do the
 right settings in the conf file every time after an upgrade.

  
 In other words, for this conf file, I would like to have the

  
 following behaviour: when the product is upgraded (major upgrade

[WiX-users] Deleting a file only when uninstalling - not installs, not upgrades, not repairs or modifies

Hi all,

I asked this question as part of another thread and then just noticed 
that it was not the right place as that thread was basically about smth 
else, so I'll ask this in a new thread here.

I would like a specific file, that it's NOT installed by the installer, 
but later created by the user, to be deleted only on uninstalls - not 
upgrades, not repairs or modifies. What condition should I use? Is (NOT 
UPGRADINGPRODUCTCODE) enough or should I also combine it with REMOVE=ALL?

[code]
Component Id=MyRemoveConfFile Guid=GUID
RemoveFile Id=MyRemoveConf Name=*myapp.conf On=uninstall/
ConditionNOT UPGRADINGPRODUCTCODE/Condition
/Component
[/code]

Is this enough (having On=uninstall and (NOT UPGRADINGPRODUCTCODE))? 
Or the conditioning should be more extensive taking in account that it 
should happen only on real uninstall (not installs, not upgrades, not 
repairs or modifies)?

TIA,
Viv


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat harvesting and fragment/component generation.

2010-03-31 Thread Tency Kuruvilla

try 
 
 heat.exe harvestType harvester arguments -out sourceFile.wxs
Supported harvesting types:
   dir  harvest a directory
   file harvest a file
   project  harvest outputs of a VS project
   website  harvest an IIS web site
Options:
   -ag  autogenerate component guids at compile time
   -gg  generate guids now
   -ke  keep empty directories
   -nologo  skip printing heat logo information
   -out specify output file (default: write to current directory)
   -pog:group
specify output group of VS project, one of:
Binaries,Symbols,Documents,Satellites,Sources,Content
  This option may be repeated for multiple output groups.
   -scomsuppress COM elements
   -sfrag   suppress fragments
   -sregsuppress registry harvesting
   -suidsuppress unique identifiers for files, components,  directories
   -swN   suppress all warnings or a specific message ID
(example: -sw1011 -sw1012)
   -swall   suppress all warnings (deprecated)
   -t:xsl  transform harvested output with XSL file
   -template:  use template, one of: fragment,module,product
   -v   verbose output
   -wx[N]   treat all warnings or a specific message ID as an error
(example: -wx1011 -wx1012)
   -wxall   treat all warnings as errors (deprecated)
   -? | -help  this help information
heat dir directory path  -out imp.wxs -template:product -scom -sreg -sfrag 
-gg -suid





From: Richard Horsley [mailto:richard.hors...@eicltd.com]
Sent: Wed 3/31/2010 1:46 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Heat harvesting and fragment/component generation.



Previously, I have created installers in WiX by hand-writing the .wxs files 
myself, but I now have a fairly large folder structure (with lots of 
subfolders) to put into an installer, and I am trying to use heat.exe to 
harvest this for me. However the harvested file seems unnecessarily messy. Is 
there any way to get heat to place all files from the same subfolder within the 
same fragment/component, or is this not considered best practice?

Richard Horsley


 DISCLAIMER 

Please consider the environment before printing this e-mail.

This e-mail has been scanned for all known virus's but this is not a 
confirmation it is virus free.

This is an e-mail from EIC Limited (Company Reg: 1086295). The contents of this 
e-mail are confidential. EIC Limited do not accept responsibility for the 
accuracy or completeness of the contents of this e-mail as it has been 
transmitted over a public network. If you receive this e-mail in error please 
accept our apology. If this is the case we would be obliged if you would 
contact the sender and then delete this e-mail.

THIS E-MAIL AND / OR ANY REPLIES TO IT, AND ANY ATTACHMENTS MAY BE INTERCEPTED, 
COPIED OR MONITORED BY EIC LIMITED FOR THE PURPOSE OF MONITORING OR KEEPING 
RECORD OF ITS BUSINESS AND FOR THE PURPOSES SET OUT IN THE TELECOMMUNICATIONS 
(LAWFUL BUSINESS PRACTICES) (INTERCEPTION OF COMMUNICATIONS) REGULATIONS 2000.

All statements made in this e-mail are subject to contract. The contents are 
not to be regarded as a contractual offer or acceptance. The sender is not 
authorised to bind EIC Limited.

The views expressed in this e-mail are those of the sender and not necessarily 
those of EIC Limited.

 DISCLAIMER 

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat harvesting and fragment/component generation.

2010-03-31 Thread Richard Horsley

This removes the fragments (I had tried suppressing the fragments already) but 
still generates one component per file. Is there any way to set component 
generation at folder level rather than at file level?

-Original Message-
From: Tency Kuruvilla [mailto:tency.kuruvi...@kcs.com.kw]
Sent: 31 March 2010 12:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Heat harvesting and fragment/component generation.

try

 heat.exe harvestType harvester arguments -out sourceFile.wxs Supported 
harvesting types:
   dir  harvest a directory
   file harvest a file
   project  harvest outputs of a VS project
   website  harvest an IIS web site
Options:
   -ag  autogenerate component guids at compile time
   -gg  generate guids now
   -ke  keep empty directories
   -nologo  skip printing heat logo information
   -out specify output file (default: write to current directory)
   -pog:group
specify output group of VS project, one of:
Binaries,Symbols,Documents,Satellites,Sources,Content
  This option may be repeated for multiple output groups.
   -scomsuppress COM elements
   -sfrag   suppress fragments
   -sregsuppress registry harvesting
   -suidsuppress unique identifiers for files, components,  directories
   -swN   suppress all warnings or a specific message ID
(example: -sw1011 -sw1012)
   -swall   suppress all warnings (deprecated)
   -t:xsl  transform harvested output with XSL file
   -template:  use template, one of: fragment,module,product
   -v   verbose output
   -wx[N]   treat all warnings or a specific message ID as an error
(example: -wx1011 -wx1012)
   -wxall   treat all warnings as errors (deprecated)
   -? | -help  this help information
heat dir directory path  -out imp.wxs -template:product -scom -sreg -sfrag 
-gg -suid

From: Richard Horsley [mailto:richard.hors...@eicltd.com]
Sent: Wed 3/31/2010 1:46 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Heat harvesting and fragment/component generation.

Previously, I have created installers in WiX by hand-writing the .wxs files 
myself, but I now have a fairly large folder structure (with lots of 
subfolders) to put into an installer, and I am trying to use heat.exe to 
harvest this for me. However the harvested file seems unnecessarily messy. Is 
there any way to get heat to place all files from the same subfolder within the 
same fragment/component, or is this not considered best practice?

Richard Horsley

 DISCLAIMER 

Please consider the environment before printing this e-mail.

This e-mail has been scanned for all known virus's but this is not a 
confirmation it is virus free.

This is an e-mail from EIC Limited (Company Reg: 1086295). The contents of this 
e-mail are confidential. EIC Limited do not accept responsibility for the 
accuracy or completeness of the contents of this e-mail as it has been 
transmitted over a public network. If you receive this e-mail in error please 
accept our apology. If this is the case we would be obliged if you would 
contact the sender and then delete this e-mail.

THIS E-MAIL AND / OR ANY REPLIES TO IT, AND ANY ATTACHMENTS MAY BE INTERCEPTED, 
COPIED OR MONITORED BY EIC LIMITED FOR THE PURPOSE OF MONITORING OR KEEPING 
RECORD OF ITS BUSINESS AND FOR THE PURPOSES SET OUT IN THE TELECOMMUNICATIONS 
(LAWFUL BUSINESS PRACTICES) (INTERCEPTION OF COMMUNICATIONS) REGULATIONS 2000.

All statements made in this e-mail are subject to contract. The contents are 
not to be regarded as a contractual offer or acceptance. The sender is not 
authorised to bind EIC Limited.

The views expressed in this e-mail are those of the sender and not necessarily 
those of EIC Limited.

 DISCLAIMER 

--
Download Intel#174; Parallel Studio Eval Try the new software tools for 
yourself. Speed compiling, find bugs proactively, and fine-tune applications 
for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 DISCLAIMER 

Please consider the environment before printing this e-mail.

This e-mail has been scanned for all known virus's but this is not a 
confirmation it is virus free.

This is an e-mail from EIC Limited (Company Reg: 1086295). The contents of this 
e-mail are confidential. EIC Limited do not accept responsibility for the 
accuracy or completeness of the contents of this e-mail as it has been 
transmitted over a public network. If you receive this e-mail in error please 
accept our

Re: [WiX-users] how to use heat to harvest VS projects

2010-03-31 Thread Neil Sleightholm

Afraid not that only gets the primary output not referenced assemblies.

Neil

Neil Sleightholm
n...@x2systems.com

On 30 Mar 2010, at 01:20, Bob Arnson b...@joyofsetup.com wrote:

 On 3/29/2010 3:56 PM, Neil Sleightholm wrote:
 I am afraid that is how heat works, it only finds the primary  
 output and
 no referenced assemblies. If you want the referenced assemblies  
 then you
 have to heat those projects or files independently.


 Or use the -pog switch, right?

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


 --- 
 --- 
 --- 
 -
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WiX 3.0: Bug in LIGHT

2010-03-31 Thread Markus Karg

We noticed that there must be a bug in LIGHT (WiX 3.0):

 

We used  

 

HEAT file my.ocx -out my.wxs

 

to create a Fragment from an OCX file, compiled it using CANDLE, then
tried to link it using LIGHT. LIGHT says that there is a duplicate in
that fragment, so we checked the fragment. In fact, there is no
duplicate:

 

Class Id={EF600D71-358F-11D1-8FD4-00AA00BD091C}
Context=InprocServer32 Description=Annotation Objects
ThreadingModel=both

   ProgId Id=AnnotationX.AnnList Description=Annotation Objects
/

   ProgId Id=AnnotationX.AnnList.1 Description=Annotation
Objects /

/Class

 

In fact, we can link it, if we remove one of that ProgId entries
(actually it plays no role which one). It seems as if LIGHT makes no
difference between AnnotationX.AnnList and AnnotationX.AnnList.1,
which is wrong, since obviously that are different entries.

 

What to do?

 

Thanks

Markus

 

 

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WiX 3.5: Error in HEAT

2010-03-31 Thread Markus Karg

We're using HEAT to create Fragments from files:

 

CD %PROGRAMFILES%\Windows Installer XML v3\bin

HEAT file EXCEL8.OLB -gg -out EXCEL8.wxs

 

That works pretty well as long as HEAT and EXCEL8.OLB are located in the
same folder.

 

But if they are not, both of the following commands will fail:

 

CD C:\

%PROGRAMFILES%\bin\HEAT file EXCEL8.OLB -gg -out EXCEL8.wxs

 

or

 

CD %PROGRAMFILES%\Windows Installer XML v3\bin

HEAT file C:\EXCEL8.OLB -gg -out EXCEL8.wxs

 

The result is always the same:

 

heat.exe : error HEAT0001 : The Value must not be NULL.

Parameter name: path

 

Exception Type: System.ArgumentNullException

 

Stack Trace:

   bei System.IO.Path.GetFullPathInternal(String path)

   bei System.IO.Path.GetFullPath(String path)

   bei
Microsoft.Tools.WindowsInstallerXml.HarvesterCore.ResolveFilePath(String
fileSource)

   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
teFile(IParentElement parentElement, File file)

   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
teElement(IParentElement parentElement, ISchemaElement element)

   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
teElement(IParentElement parentElement, ISchemaElement element)

   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
teElement(IParentElement parentElement, ISchemaElement element)

   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
teElement(IParentElement parentElement, ISchemaElement element)

   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
teElement(IParentElement parentElement, ISchemaElement element)

   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
teElement(IParentElement parentElement, ISchemaElement element)

   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
te(Wix wix)

   bei Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)

   bei Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bug with components which contain only XMLConfigelements?

2010-03-31 Thread David Watson

Hi,
This is expected behaviour, I have added a registry key with an
keypath=yes in components like this to assuage the ICE gods.

Some people also put a CreateFolder/ element in the component instead
but I like to be very explicit on what my keypaths are.

Dave

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: 31 March 2010 11:06
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Bug with components which contain only
XMLConfigelements?

Posting this in case anyone else runs into this  because I'm not sure
if this is a bug or expected behaviour.

I'm updating a plug-in installer to work with a new product which will
be imminently released. After (at least) 4 years of complaining the
developers of said product have caved in  finally moved from using a
.ini file installed alongside their product (under ProgramFilesFolder
which is lots of fun on UAC enabled systems) to supporting .addin files
under CommonAppDataFolder.

I have 3 new components, one places the .addin file (.addin files are
simple XML) in the right place, the other 2 modify a path within it
using XMLConfig.

The components look very much like the following:

DirectoryRef Id=_2011
  Component Id=_2011Addin DiskId=1 Guid=A-GUID
File Id=IESVE.addin Source=..\..\..\bin_release\IESVE.addin
/
  /Component
  Component Id=SetAddinPathx86 DiskId=1 Guid=ANOTHER-GUID
util:XmlConfig Id=SetIESVEaddinPathx86 File=[#IESVE.addin]
Action=create On=install ElementPath=/RevitAddIns/AddIn/Assembly
Node=value Value=[IESToolbar] /
  /Component
  Component Id=SetAddinPathx64 DiskId=1
Guid=YET-ANOTHER-GUID
util:XmlConfig Id=SetIESVEaddinPathx64 File=[#IESVE.addin]
Action=create On=install ElementPath=/RevitAddIns/AddIn/Assembly
Node=value Value=[IESToolbar_x64] /
  /Component
/DirectoryRef

When I build this I get 2 errors from ICE18, one for each of the
components containing XMLConfig Elements.

error LGHT0204: ICE18: KeyPath for Component: 'SetAddinPathx86' is
Directory: '_2011'. The Directory/Component pair must be listed in the
CreateFolders table.
error LGHT0204: ICE18: KeyPath for Component: 'SetAddinPathx64' is
Directory: '_2011'. The Directory/Component pair must be listed in the
CreateFolders table.

Looking at the MSI in InstEd! those 2 components do not have KeyPaths
set. I'm using WiX v3.0.5419.0  I've also run the MSI through the ICE
tests using the darice.cub from the v7.0 Windows Platform SDK which
gives the same error (as expected). I can work around this simply by
adding a RegistryValue to each component  setting it as the KeyPath for
those components but does anyone know if this is expected behaviour or a
bug with these types of components? If it's a bug let me know  I'll
submit it to the tracker on SourceForge.

Cheers,

Palbinder Sandher
Software Deployment  IT Administrator
T: +44 (0) 141 945 8500
F: +44 (0) 141 945 8501 

http://www.iesve.com
**Design, Simulate + Innovate with the Virtual Environment**
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP Email Disclaimer


--
Download Intel#174; Parallel Studio Eval Try the new software tools for
yourself. Speed compiling, find bugs proactively, and fine-tune
applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
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



--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Show Dialog from Custom Action

2010-03-31 Thread pmdarrow


I use the following to show an error message from my C# custom actions:

Record record = new Record();
record.FormatString = My Error;
session.Message(InstallMessage.Error |
(InstallMessage)System.Windows.Forms.MessageBoxIcon.Error |
(InstallMessage)System.Windows.Forms.MessageBoxButtons.OK, record);
-- 
View this message in context: 
http://n2.nabble.com/Show-Dialog-from-C-Custom-Action-tp4823643p4831674.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Uninstall removes shared startmenu shortcuts that are still in use

2010-03-31 Thread Colin Bradley

Hello all

 

I'm having trouble when uninstalling a product that has shared shortcuts
in the startmenu (Shared as in used in more than one product
configuration). It removes all shortcuts that were specific to the
uninstalling product (as well it should) but also removes shortcuts that
are still being used by others (but the files remain).

 

In the example I provide below, If Program1 and Program2 are installed,
when uninstalling Program1 shortcuts for Program1.exe and
SomeSharedThing.exe will be removed from the startmenu. I only want it
to remove the SomeSharedThing.exe shortcut if it is no longer in use.

 

Any help with this problem will be greatly appreciated.

 

Example of current implementation:

 

Program 1 WIX 

 

Component Id=Program1Exe
Guid={D63BC581-2EA0-4e3c-B395-93F3D63DF58E}

  File Id=Program1Exe

  Name=Program1.exe

  DiskId=1

  Vital=yes

  KeyPath=yes

Shortcut Id=Program1Exe

  Name=Program 1

  Advertise=yes

  Directory=ProgramMenuDir

  WorkingDirectory=INSTALLLOCATION

  Icon=Program1.exe

 

  Icon Id=Program1.exe SourceFile=Program1.exe /

/Shortcut

  /File

  !-- 

  Make sure the start-menu directory gets removed properly.

  Source:
http://blogs.technet.com/alexshev/archive/2008/02/20/from-msi-to-wix-par
t-10-shortcuts.aspx 

  --

  RemoveFolder Id=DeleteShortcutFolder

Directory=ProgramMenuDir

On=uninstall /

/Component

Component Id=SomeSharedThing
Guid={02F84320-8F1B-4aba-B021-4AC9181F2F39}

  File Id=SomeSharedThing

  Name=SomeSharedThing.exe

  DiskId=1

  Vital=yes

  KeyPath=yes

Shortcut Id=SomeSharedThing

   Name=Some Shared Thing

   Directory=ProgramMenuDir

   Advertise=yes

   Icon=SomeSharedThing.exe

 

  Icon Id=SomeSharedThing.exe
SourceFile=SomeSharedThing.exe /

/Shortcut

  /File

/Component

 

Program 2 WIX 

 

Component Id=Program2Exe
Guid={6382007A-4190-4c33-9C44-29BF84F91C7E}

  File Id= Program2Exe 

  Name= Program2.exe

  DiskId=1

  Vital=yes

  KeyPath=yes

Shortcut Id= Program2Exe 

  Name=Program 2

  Advertise=yes

  Directory=ProgramMenuDir

  WorkingDirectory=INSTALLLOCATION

  Icon= Program2.exe

 

  Icon Id= Program2.exe SourceFile= Program2.exe /

/Shortcut

  /File

  !-- 

  Make sure the start-menu directory gets removed properly.

  Source:
http://blogs.technet.com/alexshev/archive/2008/02/20/from-msi-to-wix-par
t-10-shortcuts.aspx 

  --

  RemoveFolder Id=DeleteShortcutFolder

Directory=ProgramMenuDir

On=uninstall /

/Component

Component Id=SomeSharedThing
Guid={02F84320-8F1B-4aba-B021-4AC9181F2F39}

  File Id=SomeSharedThing

  Name=SomeSharedThing.exe

  DiskId=1

  Vital=yes

  KeyPath=yes

Shortcut Id=SomeSharedThing

   Name=Some Shared Thing

   Directory=ProgramMenuDir

   Advertise=yes

   Icon=SomeSharedThing.exe

 

  Icon Id=SomeSharedThing.exe
SourceFile=SomeSharedThing.exe /

/Shortcut

  /File

/Component

 

I have used: RemoveFolder Id=DeleteShortcutFolder
Directory=ProgramMenuDir On=uninstall / to remove the shortcuts, I
imagine this is where my changes need to be?

 

Again, any help would be greatly appreciated,

 

Colin.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [Wix-users] Question regarding TARGETDIR INSTALLDIR

2010-03-31 Thread Bajpai, Ramit

We have the following directory structure wherein we want the Logs folder to be 
created at the same level as the Services folder.

 

Directory Id=TARGETDIR Name=SourceDir

  Directory Id=SERVICESDIR Name=Services

Directory Id=INSTALLDIR Name=Cmds

. . .

/Directory

  /Directory

  Directory Id=CANSERVICESLOGFILEDIR Name=Logs

Component Id=xxx Guid=----

  CreateFolder /

/Component

  /Directory

/Directory

Now what happens is, if the user runs the installer in Custom mode and chooses 
a different drive from what the installer picked up based on the information 
here:

http://msdn.microsoft.com/en-us/library/aa372064.aspx

http://msdn.microsoft.com/en-us/library/aa371372.aspx

The installer installs the application at the new location but still creates 
the Logs folder at the original location picked by the installer.

Lets take an example:

The installer picks INSTALLDIR as D:\Services\Cmds

The user changes it to C:\Services\Cmds

So, instead of creating the logs folder like this C:\Services\Logs, the 
installer still creates it at D:\Services\Logs

I know when the user picks a different location for installation it just 
changes the INSTALLDIR property to the new value but the TARGETDIR still points 
to the original destination. Shouldn’t picking the new INSTALLDIR should by 
default change the TARGETDIR? Atleast, it looks like a valid usecase to me, is 
this some kind of bug or is it designed to behave like this only?

Any help would be appreciated.

Thanks,

Ramit

Ramit Bajpai |CAN http://can.monster.com/  | Monster Worldwide 
http://www.monster.com/  | Direct: 978.823.2570 | Cell: 508.395.7037

 

 

NOTICE: 

 

This message, and any attachments, contain(s) information that may be 
confidential or protected by privilege from disclosure and is intended only for 
the individual or entity named above. No one else may disclose, copy, 
distribute or use the contents of this message for any purpose. Its 
unauthorized use, dissemination or duplication is strictly prohibited and may 
be unlawful. If you receive this message in error or you otherwise are not an 
authorized recipient, please immediately delete the message and any attachments 
and notify the sender.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [Wix-users] Question regarding TARGETDIR INSTALLDIR

The directory structure below must have a bug in it as it suggest that the Logs 
folder is a sibling to Services and not Cmds. Changing the INSTALLDIR property 
will only affect the location of the INSTALLDIR directory (Cmds in this case). 
If you want to INSTALLDIR to change the location of the Services directory with 
Cmds and Logs directories as children I would do the following:

Directory Id=TARGETDIR Name=SourceDir
Directory Id=INSTALLDIR Name=Services
Directory Id=CMDSDIR Name=Cmds
...
/Directory
Directory Id=LOGSDIR Name=Logs
...
/Directory
/Directory
/Directory

Of course, since both CMDSDIR and LOGSDIR are all uppercase (and thus public 
properties) you can specify different folders for them if desired by changing 
those properties.

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: Bajpai, Ramit [mailto:ramit.baj...@monster.com]
 Sent: Wednesday, March 31, 2010 9:06 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] [Wix-users] Question regarding TARGETDIR 
 INSTALLDIR
 
 We have the following directory structure wherein we want the Logs
 folder to be created at the same level as the Services folder.
 
 
 
 Directory Id=TARGETDIR Name=SourceDir
 
   Directory Id=SERVICESDIR Name=Services
 
 Directory Id=INSTALLDIR Name=Cmds
 
 . . .
 
 /Directory
 
   /Directory
 
   Directory Id=CANSERVICESLOGFILEDIR Name=Logs
 
 Component Id=xxx Guid=----
 
 
   CreateFolder /
 
 /Component
 
   /Directory
 
 /Directory
 
 Now what happens is, if the user runs the installer in Custom mode and
 chooses a different drive from what the installer picked up based on
 the information here:
 
 http://msdn.microsoft.com/en-us/library/aa372064.aspx
 
 http://msdn.microsoft.com/en-us/library/aa371372.aspx
 
 The installer installs the application at the new location but still
 creates the Logs folder at the original location picked by the
 installer.
 
 Lets take an example:
 
 The installer picks INSTALLDIR as D:\Services\Cmds
 
 The user changes it to C:\Services\Cmds
 
 So, instead of creating the logs folder like this C:\Services\Logs, the
 installer still creates it at D:\Services\Logs
 
 I know when the user picks a different location for installation it
 just changes the INSTALLDIR property to the new value but the TARGETDIR
 still points to the original destination. Shouldn’t picking the new
 INSTALLDIR should by default change the TARGETDIR? Atleast, it looks
 like a valid usecase to me, is this some kind of bug or is it designed
 to behave like this only?
 
 Any help would be appreciated.
 
 Thanks,
 
 Ramit
 
 Ramit Bajpai |CAN http://can.monster.com/  | Monster Worldwide
 http://www.monster.com/  | Direct: 978.823.2570 | Cell: 508.395.7037
 
 
 
 
 
 NOTICE:
 
 
 
 This message, and any attachments, contain(s) information that may be
 confidential or protected by privilege from disclosure and is intended
 only for the individual or entity named above. No one else may
 disclose, copy, distribute or use the contents of this message for any
 purpose. Its unauthorized use, dissemination or duplication is strictly
 prohibited and may be unlawful. If you receive this message in error or
 you otherwise are not an authorized recipient, please immediately
 delete the message and any attachments and notify the sender.
 
 ---
 ---
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Storing / Accessing Properties

2010-03-31 Thread Kerber, Cameron

Hi,

With install shield we used to store properties we wanted for later in an xml 
file and then install shield would read them in at the beginning of install.  
We didn't use a custom action to do this, it was a built in function with 
install shield.

I am looking for something similar with WiX.  Maybe using the Util extenision?




The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.5: Error in HEAT

2010-03-31 Thread sd

Is the problem that Wix (and heat) aren't in your path?

What I do is:

1. Start a command console
2. Type in path=%path%;C:\Program Files (x86)\Windows Installer XML v3\bin
3. cd to my DLL's location (in your case it would be your OLB file)
4. run heat.

Jeff




 We're using HEAT to create Fragments from files:



 CD %PROGRAMFILES%\Windows Installer XML v3\bin

 HEAT file EXCEL8.OLB -gg -out EXCEL8.wxs



 That works pretty well as long as HEAT and EXCEL8.OLB are located in the
 same folder.



 But if they are not, both of the following commands will fail:



 CD C:\

 %PROGRAMFILES%\bin\HEAT file EXCEL8.OLB -gg -out EXCEL8.wxs



 or



 CD %PROGRAMFILES%\Windows Installer XML v3\bin

 HEAT file C:\EXCEL8.OLB -gg -out EXCEL8.wxs



 The result is always the same:



 heat.exe : error HEAT0001 : The Value must not be NULL.

 Parameter name: path



 Exception Type: System.ArgumentNullException



 Stack Trace:

bei System.IO.Path.GetFullPathInternal(String path)

bei System.IO.Path.GetFullPath(String path)

bei
 Microsoft.Tools.WindowsInstallerXml.HarvesterCore.ResolveFilePath(String
 fileSource)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teFile(IParentElement parentElement, File file)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 te(Wix wix)

bei Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)

bei Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)

 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users





--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Storing / Accessing Properties

InstallShield provides this functionality via a custom action that was written 
by the InstallShield developers.

WiX does not currently ship with a standard custom action to ready property 
values from an XML file. If you want this functionality today, you'll need to 
write your own custom action to do so.

I think this would be a great feature enhancement. I would certainly use this 
feature if it existed.

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: Kerber, Cameron [mailto:cameron.ker...@philips.com]
 Sent: Wednesday, March 31, 2010 10:07 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Storing / Accessing Properties
 
 Hi,
 
 With install shield we used to store properties we wanted for later in
 an xml file and then install shield would read them in at the beginning
 of install.  We didn't use a custom action to do this, it was a built
 in function with install shield.
 
 I am looking for something similar with WiX.  Maybe using the Util
 extenision?
 
 
 
 
 The information contained in this message may be confidential and
 legally protected under applicable law. The message is intended solely
 for the addressee(s). If you are not the intended recipient, you are
 hereby notified that any use, forwarding, dissemination, or
 reproduction of this message is strictly prohibited and may be
 unlawful. If you are not the intended recipient, please contact the
 sender by return e-mail and destroy all copies of the original message.
 ---
 ---
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode

Thanks Dave.

I'll try that.

From: Dave Brotherstone dav...@pobox.com
To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net
Sent: Tue, March 30, 2010 10:42:16 PM
Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get  
Error 2836 in Repair mode

On Wed, Mar 31, 2010 at 1:39 AM, little.forest little.for...@ymail.comwrote:

 Hi All,

 I totally understand 'using regsvr32 in Wix' is not recommended. But in
 this adxloader.dll case, we can't use tallow or heat to generate fragments
 from the dll. This is not the problem of tallow or heat, but the problem of
 the dll. However, the dll can be registered manually by using regsvr32.exe.
 So my question is: is there a way that we can collect the needed registry
 information manually? If it's possible, then we can get rid of regsvr32.

You can probably see the registry entries manually by watching regsvr32 in
procmon (from sysinternals).  You'll need to convert the output to WiX, but
at least you'll see everything that is written.  Just set the filter to
procname=regsvr32, and only watch the registry.

Dave.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now
http://ca.toolbar.yahoo.com.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [Wix-users] Question regarding TARGETDIR INSTALLDIR

2010-03-31 Thread Bajpai, Ramit

Sorry, for the typo here is correct structure...

Directory Id=TARGETDIR Name=SourceDir

  Directory Id=SERVICESDIR Name=Services

Directory Id=INSTALLDIR Name=Cmds

. . .

/Directory

Directory Id=CANSERVICESLOGFILEDIR Name=Logs

Component Id=xxx Guid=----

  CreateFolder /

/Component

/Directory

  /Directory

  


/Directory

-Original Message-
From: Bajpai, Ramit [mailto:ramit.baj...@monster.com] 
Sent: Wednesday, March 31, 2010 12:06 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] [Wix-users] Question regarding TARGETDIR  INSTALLDIR

We have the following directory structure wherein we want the Logs folder to be 
created at the same level as the Services folder.

 

Directory Id=TARGETDIR Name=SourceDir

  Directory Id=SERVICESDIR Name=Services

Directory Id=INSTALLDIR Name=Cmds

. . .

/Directory

  /Directory

  Directory Id=CANSERVICESLOGFILEDIR Name=Logs

Component Id=xxx Guid=----

  CreateFolder /

/Component

  /Directory

/Directory

Now what happens is, if the user runs the installer in Custom mode and chooses 
a different drive from what the installer picked up based on the information 
here:

http://msdn.microsoft.com/en-us/library/aa372064.aspx

http://msdn.microsoft.com/en-us/library/aa371372.aspx

The installer installs the application at the new location but still creates 
the Logs folder at the original location picked by the installer.

Lets take an example:

The installer picks INSTALLDIR as D:\Services\Cmds

The user changes it to C:\Services\Cmds

So, instead of creating the logs folder like this C:\Services\Logs, the 
installer still creates it at D:\Services\Logs

I know when the user picks a different location for installation it just 
changes the INSTALLDIR property to the new value but the TARGETDIR still points 
to the original destination. Shouldn’t picking the new INSTALLDIR should by 
default change the TARGETDIR? Atleast, it looks like a valid usecase to me, is 
this some kind of bug or is it designed to behave like this only?

Any help would be appreciated.

Thanks,

Ramit

Ramit Bajpai |CAN http://can.monster.com/  | Monster Worldwide 
http://www.monster.com/  | Direct: 978.823.2570 | Cell: 508.395.7037

 

 

NOTICE: 

 

This message, and any attachments, contain(s) information that may be 
confidential or protected by privilege from disclosure and is intended only for 
the individual or entity named above. No one else may disclose, copy, 
distribute or use the contents of this message for any purpose. Its 
unauthorized use, dissemination or duplication is strictly prohibited and may 
be unlawful. If you receive this message in error or you otherwise are not an 
authorized recipient, please immediately delete the message and any attachments 
and notify the sender.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [Wix-users] Question regarding TARGETDIR INSTALLDIR

2010-03-31 Thread Bajpai, Ramit

That was a typo, I have structure similar to what you have suggested.

-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] 
Sent: Wednesday, March 31, 2010 12:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] [Wix-users] Question regarding TARGETDIR INSTALLDIR

The directory structure below must have a bug in it as it suggest that the Logs 
folder is a sibling to Services and not Cmds. Changing the INSTALLDIR property 
will only affect the location of the INSTALLDIR directory (Cmds in this case). 
If you want to INSTALLDIR to change the location of the Services directory with 
Cmds and Logs directories as children I would do the following:

Directory Id=TARGETDIR Name=SourceDir
Directory Id=INSTALLDIR Name=Services
Directory Id=CMDSDIR Name=Cmds
...
/Directory
Directory Id=LOGSDIR Name=Logs
...
/Directory
/Directory
/Directory

Of course, since both CMDSDIR and LOGSDIR are all uppercase (and thus public 
properties) you can specify different folders for them if desired by changing 
those properties.

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: Bajpai, Ramit [mailto:ramit.baj...@monster.com]
 Sent: Wednesday, March 31, 2010 9:06 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] [Wix-users] Question regarding TARGETDIR 
 INSTALLDIR

 We have the following directory structure wherein we want the Logs
 folder to be created at the same level as the Services folder.

 Directory Id=TARGETDIR Name=SourceDir

   Directory Id=SERVICESDIR Name=Services

 Directory Id=INSTALLDIR Name=Cmds

 . . .

 /Directory

   /Directory

   Directory Id=CANSERVICESLOGFILEDIR Name=Logs

 Component Id=xxx Guid=----

   CreateFolder /

 /Component

   /Directory

 /Directory

 Now what happens is, if the user runs the installer in Custom mode and
 chooses a different drive from what the installer picked up based on
 the information here:

 http://msdn.microsoft.com/en-us/library/aa372064.aspx

 http://msdn.microsoft.com/en-us/library/aa371372.aspx

 The installer installs the application at the new location but still
 creates the Logs folder at the original location picked by the
 installer.

 Lets take an example:

 The installer picks INSTALLDIR as D:\Services\Cmds

 The user changes it to C:\Services\Cmds

 So, instead of creating the logs folder like this C:\Services\Logs, the
 installer still creates it at D:\Services\Logs

 I know when the user picks a different location for installation it
 just changes the INSTALLDIR property to the new value but the TARGETDIR
 still points to the original destination. Shouldn’t picking the new
 INSTALLDIR should by default change the TARGETDIR? Atleast, it looks
 like a valid usecase to me, is this some kind of bug or is it designed
 to behave like this only?

 Any help would be appreciated.

 Thanks,

 Ramit

 Ramit Bajpai |CAN http://can.monster.com/  | Monster Worldwide
 http://www.monster.com/  | Direct: 978.823.2570 | Cell: 508.395.7037

 NOTICE:

 This message, and any attachments, contain(s) information that may be
 confidential or protected by privilege from disclosure and is intended
 only for the individual or entity named above. No one else may
 disclose, copy, distribute or use the contents of this message for any
 purpose. Its unauthorized use, dissemination or duplication is strictly
 prohibited and may be unlawful. If you receive this message in error or
 you otherwise are not an authorized recipient, please immediately
 delete the message and any attachments and notify the sender.

 ---
 ---
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net

Re: [WiX-users] Storing / Accessing Properties

2010-03-31 Thread Kerber, Cameron

Yeah no biggie.  I just didn't want to reinvent the wheel.

-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: Wednesday, March 31, 2010 1:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Storing / Accessing Properties

InstallShield provides this functionality via a custom action that was written 
by the InstallShield developers.

WiX does not currently ship with a standard custom action to ready property 
values from an XML file. If you want this functionality today, you'll need to 
write your own custom action to do so.

I think this would be a great feature enhancement. I would certainly use this 
feature if it existed.

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: Kerber, Cameron [mailto:cameron.ker...@philips.com]
 Sent: Wednesday, March 31, 2010 10:07 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Storing / Accessing Properties

 Hi,

 With install shield we used to store properties we wanted for later in
 an xml file and then install shield would read them in at the beginning
 of install.  We didn't use a custom action to do this, it was a built
 in function with install shield.

 I am looking for something similar with WiX.  Maybe using the Util
 extenision?



 
 The information contained in this message may be confidential and
 legally protected under applicable law. The message is intended solely
 for the addressee(s). If you are not the intended recipient, you are
 hereby notified that any use, forwarding, dissemination, or
 reproduction of this message is strictly prohibited and may be
 unlawful. If you are not the intended recipient, please contact the
 sender by return e-mail and destroy all copies of the original message.
 ---
 ---
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode

Thanks Palbinder.


Actually we asked the vendor first, but they told us sorry, we don't support 
Wix...

Anyways, here I have another question about the conditions:
1. What is the conditions if I'd like to run the custom action in both 'fresh 
install' and 'Repair'? Is there something like this? -
Not Installed OR Repair=1 
2. What is the conditions if I'd like to fun the custom action in 
'uninstallation' only? Is this correct? -
Remove=ALL
3. Also, What's the condition for 'fresh install' only?

For the 2nd one, it doesn't work. Well, the custom action didn't run in 'fresh 
install' or 'Repair', but it didn't run in 'Uninstallation/Remove', either. 
What is the correct condition for that case?

Thanks.




From: Pally Sandher pally.sand...@iesve.com
To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net
Sent: Wed, March 31, 2010 3:38:43 AM
Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get  
Error 2836 in Repair mode

RegSpy2 may be able to help. See
http://www.installsite.org/pages/en/msi/tips.htm about 1/3 down the
page. It'll output a .reg file which you run through tallow.exe to
output WiX code.

However I would ask the vendor of this adxloader.dll for support first.

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: Dave Brotherstone [mailto:dav...@pobox.com] 
Sent: 31 March 2010 06:42
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted,then we'll
get Error 2836 in Repair mode

On Wed, Mar 31, 2010 at 1:39 AM, little.forest
little.for...@ymail.comwrote:

 Hi All,


 I totally understand 'using regsvr32 in Wix' is not recommended. But 
 in this adxloader.dll case, we can't use tallow or heat to generate 
 fragments from the dll. This is not the problem of tallow or heat, but

 the problem of the dll. However, the dll can be registered manually by
using regsvr32.exe.
 So my question is: is there a way that we can collect the needed 
 registry information manually? If it's possible, then we can get rid
of regsvr32.


You can probably see the registry entries manually by watching regsvr32
in procmon (from sysinternals).  You'll need to convert the output to
WiX, but at least you'll see everything that is written.  Just set the
filter to procname=regsvr32, and only watch the registry.

Dave.

--
Download Intel® Parallel Studio Eval Try the new software tools for
yourself. Speed compiling, find bugs proactively, and fine-tune
applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



  __
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  
Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [Wix-users] Question regarding TARGETDIR INSTALLDIR

With this structure you can specify the location of the Services directory 
using SERVICESDIR. Doing so will change both Cmds and Logs to be rooted under 
SERVICESDIR. You can't change the location of Logs by specifying INSTALLDIR 
because INSTALLDIR applies only to Cmds.

Msiexec /I file.msi INSTALLDIR=C:\Custom\Directory\Services\Cmds

The command line above only changes the location of INSTALLDIR. If you want to 
change the location of Logs then you also need to specify CANSERVICESLOGFILEDIR:

Msiexec /I file.msi INSTALLDIR=C:\Custom\Directory\Services\Cmds 
CANSERVICESLOGFILEDIR=C:\Custom\Directory\Services\Logs

Alternatively you can specify SERVICESDIR if the default directory names of 
Cmds and Logs are acceptable:

Msiexec /I file.msi SERVICESDIR=C:\Custom\Directory\Services

If you want the user to specify INSTALLDIR and then use the parent directory to 
also contain Logs, then you'll need to write a custom action to parse 
INSTALLDIR and set CANSERVICESLOGFILEDIR appropriately.

In my opinion, that's too many ways to do it. I would allow the user to specify 
the location of the Services directory (and call that INSTALLDIR) and create 
the subdirectories with hardcoded names:

Directory Id=TARGETDIR Name=SourceDir
Directory Id=INSTALLDIR Name=Services
Directory Id=CmdsDir Name=Cmds
...
/Directory
Directory Id=LogsDir Name=Logs
...
/Directory
/Directory
/Directory

This way the installer always creates folders called Cmds and Logs under a 
directory that can be specified by the user as INSTALLDIR:

Msiexec /I file.msi INSTALLDIR=C:\Custom\Directory\Services

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: Bajpai, Ramit [mailto:ramit.baj...@monster.com]
 Sent: Wednesday, March 31, 2010 11:12 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] [Wix-users] Question regarding TARGETDIR 
 INSTALLDIR
 
 Sorry, for the typo here is correct structure...
 
 Directory Id=TARGETDIR Name=SourceDir
 
   Directory Id=SERVICESDIR Name=Services
 
 Directory Id=INSTALLDIR Name=Cmds
 
 . . .
 
 /Directory
 
   Directory Id=CANSERVICESLOGFILEDIR Name=Logs
 
   Component Id=xxx Guid=----
 
 
 CreateFolder /
 
   /Component
 
   /Directory
 
   /Directory
 
 
 
 
 /Directory
 
 -Original Message-
 From: Bajpai, Ramit [mailto:ramit.baj...@monster.com]
 Sent: Wednesday, March 31, 2010 12:06 PM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] [Wix-users] Question regarding TARGETDIR 
 INSTALLDIR
 
 We have the following directory structure wherein we want the Logs
 folder to be created at the same level as the Services folder.
 
 
 
 Directory Id=TARGETDIR Name=SourceDir
 
   Directory Id=SERVICESDIR Name=Services
 
 Directory Id=INSTALLDIR Name=Cmds
 
 . . .
 
 /Directory
 
   /Directory
 
   Directory Id=CANSERVICESLOGFILEDIR Name=Logs
 
 Component Id=xxx Guid=----
 
 
   CreateFolder /
 
 /Component
 
   /Directory
 
 /Directory
 
 Now what happens is, if the user runs the installer in Custom mode and
 chooses a different drive from what the installer picked up based on
 the information here:
 
 http://msdn.microsoft.com/en-us/library/aa372064.aspx
 
 http://msdn.microsoft.com/en-us/library/aa371372.aspx
 
 The installer installs the application at the new location but still
 creates the Logs folder at the original location picked by the
 installer.
 
 Lets take an example:
 
 The installer picks INSTALLDIR as D:\Services\Cmds
 
 The user changes it to C:\Services\Cmds
 
 So, instead of creating the logs folder like this C:\Services\Logs, the
 installer still creates it at D:\Services\Logs
 
 I know when the user picks a different location for installation it
 just changes the INSTALLDIR property to the new value but the TARGETDIR
 still points to the original destination. Shouldn’t picking the new
 INSTALLDIR should by default change the TARGETDIR? Atleast, it looks
 like a valid usecase to me, is this some kind of bug or is it designed
 to behave like this only?
 
 Any help would be appreciated.
 
 Thanks,
 
 Ramit
 
 Ramit Bajpai |CAN http://can.monster.com/  | Monster Worldwide
 http://www.monster.com/  | Direct: 978.823.2570 | Cell: 508.395.7037
 
 
 
 
 
 NOTICE:
 
 
 
 This message, and any attachments, contain(s) information that may be
 confidential or protected by privilege from disclosure and is intended
 only for the individual or entity named above. No one else may
 disclose, copy, distribute or use the contents of this message for any
 purpose. Its unauthorized use,

[WiX-users] setting user account for Scheduled task

2010-03-31 Thread banda


Hi 


I have a created a wix package to install schedule tasks in windows server.
Once tasks are installed successfully, task should run on particular user
account. 

How can I set the user account info to the scheduled task from wix package?

Thanks,
Srinivas

-- 
View this message in context: 
http://n2.nabble.com/setting-user-account-for-Scheduled-task-tp4832792p4832792.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] stop the service before uninstall

2010-03-31 Thread Wilson, Phil

There isn't a built-in way to tell the uninstall that the ServiceControl that 
stops the service is going to shut down your app. That means you'll need to use 
an uninstall custom action to close down the app - I think WiX has one called 
CloseApp or something. You'd sequence this before InstallValidate, which is 
where the in-use situations are detected.  You also need a way to tell your 
service to switch off its monitoring, and use that in a custom action at 
uninstall time. I've seen this kind of situation before. There are times when 
these services need to be told to stop their monitoring, such as upgrades, 
patches, uninstalls, and when to start again. The way I've seen this done is 
that a registry entry is created/altered, and before the service does whatever 
it's going to do it checks the registry entry, so in your case the service 
wouldn't monitor the app. So your uninstall would, in this order. 

1. Have an uninstall custom action that writes a stop monitoring registry 
item for the service. 
2. A uninstall custom action (CloseApp?) that shuts down your app. 

InstallValidate finds no files in use and proceeds to stop services, uninstall 
files etc. 

3. Custom action to delete the stop monitoring registry item. 


Phil Wilson 


-Original Message-
From: Viv Coco [mailto:vcotirl...@hotmail.com] 
Sent: Wednesday, March 31, 2010 3:34 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] stop the service before uninstall

Forgot to mention: as my application is started by the service it runs 
in the service context which means they both don't run in the context of 
the current user, but as SYSTEM. Also my application doesn't have a 
window (it's a winmain application but with 
EntryPointSymbol=mainCRTStartup).

I think the uninstaller checks at the beginning of the uninstalling 
process which binaries are in use and b/c MyApp.exe is at that point 
running I get the reboot message. If I could tell the installer to check 
the files in use at a later point, after the service was stopped (b/c at 
that point MyApp.exe is also not running anymore) I could get rid of 
this reboot-message. Can I schedule this check at a later point?

Thx,
Viv

On 3/31/2010 10:25 AM, Viv Coco wrote:
  When, during the uninstall process, are you getting the error? Is it
 happening during the RemoveFiles action?

 If I have correctly read the log file, happens during the 
 InstallValidate (I checked in the log file the Doing action: and 
 InstallValidate  is the last one before the message is shown).

 But in the log file I noticed that it's not my service that actually 
 produces the problem, but my application. I have an application 
 (MyApp.exe) that runs endlessly and is babysit by a service 
 (MyServiceWatchdog.exe): when the service is started my application is 
 started, when the service is stopped my application is stopped (the 
 service takes care of startig/stopiing my application) .
 So in the (un)installer I said that the service must be stopped when 
 uninstalling which will actually stop also my application (b/c my 
 service will also kill my app when stopping).

 I'm not sure if I understood correctly but what I think happens is: 
 the uninstaller checks the files and sees that my application 
 (MyApp.exe) is running and there is no event scheduled to stop it, so 
 it shows the reboot message. But actually MyApp.exe will be stopped 
 once the service is stopped.
 Is there a way to tell the uninstaller that? I can't kill MyApp.exe 
 from the uninstaller b/c if the service is not yet stopped when 
 MyApp.exe is killed, the service will restart again MyApp.exe.

  If so, you might try adding the Wait=yes attribute to your 
 ServiceControl so that it waits for it to stop
 the service before moving on to remove files. It may be that the SCM is
 taking too long and the installer need to give it time to complete. 
 Just a
 guess, though.

 I tried with the Wait attribute but didn't change the behavior.

  Could you provide a log?

 sure, see attached. I saved the log as soon as I got the reboot message.

 Thanks a lot!
 Viv



 On 3/30/2010 1:55 PM, Nick Ramirez wrote:
 When, during the uninstall process, are you getting the error? Is it
 happening during the RemoveFiles action? If so, you might try adding the
 Wait=yes attribute to your ServiceControl so that it waits for it 
 to stop
 the service before moving on to remove files. It may be that the SCM is
 taking too long and the installer need to give it time to complete. 
 Just a
 guess, though. Could you provide a log?


 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev


 ___

Re: [WiX-users] WiX 3.5: Error in HEAT

2010-03-31 Thread Mike Carlson (DEV DIV)

Also, what version of the tools are you running? Have you tried 3.0 RTM or a 
recent 3.5 weekly release?

-Original Message-
From: s...@pacaccess.com [mailto:s...@pacaccess.com] 
Sent: Wednesday, March 31, 2010 10:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX 3.5: Error in HEAT

Is the problem that Wix (and heat) aren't in your path?

What I do is:

1. Start a command console
2. Type in path=%path%;C:\Program Files (x86)\Windows Installer XML v3\bin
3. cd to my DLL's location (in your case it would be your OLB file)
4. run heat.

Jeff




 We're using HEAT to create Fragments from files:



 CD %PROGRAMFILES%\Windows Installer XML v3\bin

 HEAT file EXCEL8.OLB -gg -out EXCEL8.wxs



 That works pretty well as long as HEAT and EXCEL8.OLB are located in the
 same folder.



 But if they are not, both of the following commands will fail:



 CD C:\

 %PROGRAMFILES%\bin\HEAT file EXCEL8.OLB -gg -out EXCEL8.wxs



 or



 CD %PROGRAMFILES%\Windows Installer XML v3\bin

 HEAT file C:\EXCEL8.OLB -gg -out EXCEL8.wxs



 The result is always the same:



 heat.exe : error HEAT0001 : The Value must not be NULL.

 Parameter name: path



 Exception Type: System.ArgumentNullException



 Stack Trace:

bei System.IO.Path.GetFullPathInternal(String path)

bei System.IO.Path.GetFullPath(String path)

bei
 Microsoft.Tools.WindowsInstallerXml.HarvesterCore.ResolveFilePath(String
 fileSource)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teFile(IParentElement parentElement, File file)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 teElement(IParentElement parentElement, ISchemaElement element)

bei
 Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Muta
 te(Wix wix)

bei Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)

bei Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)

 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users





--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] setting user account for Scheduled task

2010-03-31 Thread Wilson, Phil

Does scheduled tasks mean the Task Scheduler interface?  Most people doing 
this use the standard ITaskScheduler interface (example at 
http://www.codeproject.com/KB/system/taskscheduler.aspx, docs at 
http://msdn.microsoft.com/en-us/library/aa381811(VS.85).aspx ) and this 
includes methods for setting account name and password, either at creation time 
or later by modifying the task.  

I don't think there's a WiX extension for this, but there might be. 

Phil Wilson 


-Original Message-
From: banda [mailto:srinivas.ba...@igate.com] 
Sent: Wednesday, March 31, 2010 11:53 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] setting user account for Scheduled task


Hi 


I have a created a wix package to install schedule tasks in windows server.
Once tasks are installed successfully, task should run on particular user
account. 

How can I set the user account info to the scheduled task from wix package?

Thanks,
Srinivas

-- 
View this message in context: 
http://n2.nabble.com/setting-user-account-for-Scheduled-task-tp4832792p4832792.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
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 Portland House, Bressenden Place, London, 
SW1E 5BF (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 7821 3848 or e-mail 
inet.hqhelpd...@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).



--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Version of WiX that groks .NET 4.0 assemblies?

2010-03-31 Thread Dan Thompson (SBS)

We are upgrading our toolset to use .NET 4.0, but I found that light.exe 
failed, because it thought that a particular file was not a valid assembly. Not 
surprising, since light.exe probably uses standard reflection APIs, and can't 
grok a .NET 4.0 binary. Has anyone started building WiX for .NET 4.0?

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Conditions for Uninstall/Remove Only

How can I create conditions for a custom action to run for Uninstall/Remove 
only?


If I use condition 'Installed' then the CA runs in Repair mode.
If I use condition 'Remove=ALL' then the CA doesn't run in Repair, but it 
doesn't run in Uninstall/Remove either.

Thanks.


  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now
http://ca.toolbar.yahoo.com.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditions for Uninstall/Remove Only

2010-03-31 Thread Wilson, Phil

That's because property names are case sensitive and the actual name is REMOVE. 

Phil Wilson 

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Wednesday, March 31, 2010 3:55 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Conditions for Uninstall/Remove Only

How can I create conditions for a custom action to run for Uninstall/Remove 
only?

If I use condition 'Installed' then the CA runs in Repair mode.
If I use condition 'Remove=ALL' then the CA doesn't run in Repair, but it 
doesn't run in Uninstall/Remove either.

Thanks.

  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now
http://ca.toolbar.yahoo.com.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
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 Portland House, Bressenden Place, London, 
SW1E 5BF (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 7821 3848 or e-mail 
inet.hqhelpd...@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).

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] read a file + advertise

2010-03-31 Thread lewisv


I don't want to rely on my end users to tell me certain installation
settings. So i decided to make a xml file that that is located in the same
dir as the msi, i then read and parse with custom action, and write those
settings to my users computer. 

I just ran into an issue, i was using advertised shortcut, and when a brand
new user tries to run the application ( the app has been installed, but this
user has not run it) it runs the cached msi file. Which of course does not
have the xml file with it. So my settings are all screwed up.

I figure i can remove the advertise, and that should work. But is there
another way. 
Am i doing this the correct way overall?

-- 
View this message in context: 
http://n2.nabble.com/read-a-file-advertise-tp4834153p4834153.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditions for Uninstall/Remove Only

Thanks Phil!

That works. Sorry, I didn't pay attention on that.

From: Wilson, Phil phil.wil...@invensys.com
To: General discussion for Windows Installer XML toolset. 
wix-users@lists.sourceforge.net
Sent: Wed, March 31, 2010 4:17:59 PM
Subject: Re: [WiX-users] Conditions for Uninstall/Remove Only

That's because property names are case sensitive and the actual name is REMOVE. 

Phil Wilson 

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Wednesday, March 31, 2010 3:55 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Conditions for Uninstall/Remove Only

How can I create conditions for a custom action to run for Uninstall/Remove 
only?

If I use condition 'Installed' then the CA runs in Repair mode.
If I use condition 'Remove=ALL' then the CA doesn't run in Repair, but it 
doesn't run in Uninstall/Remove either.

Thanks.

  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now
http://ca.toolbar.yahoo.com.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
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 Portland House, Bressenden Place, London, 
SW1E 5BF (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 7821 3848 or e-mail
 inet.hqhelpd...@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).

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

  __
Get a sneak peak at messages with a handy reading pane with All new Yahoo! 
Mail: http://ca.promos.yahoo.com/newmail/overview2/
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] read a file + advertise

You'd have this problem even if you weren't using the xml file and instead 
provided the property values via the command line. You'll probably want to 
store the property values in the registry and use RegistrySearch to get the 
saved values.

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: lewisv [mailto:le...@nitorco.com]
 Sent: Wednesday, March 31, 2010 4:39 PM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] read a file + advertise
 
 
 I don't want to rely on my end users to tell me certain installation
 settings. So i decided to make a xml file that that is located in the
 same
 dir as the msi, i then read and parse with custom action, and write
 those
 settings to my users computer.
 
 I just ran into an issue, i was using advertised shortcut, and when a
 brand
 new user tries to run the application ( the app has been installed, but
 this
 user has not run it) it runs the cached msi file. Which of course does
 not
 have the xml file with it. So my settings are all screwed up.
 
 I figure i can remove the advertise, and that should work. But is there
 another way.
 Am i doing this the correct way overall?
 
 --
 View this message in context: http://n2.nabble.com/read-a-file-
 advertise-tp4834153p4834153.html
 Sent from the wix-users mailing list archive at Nabble.com.
 
 ---
 ---
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] how to use heat to harvest VS projects

On 3/31/2010 8:41 AM, Neil Sleightholm wrote:
 Afraid not that only gets the primary output not referenced assemblies.


Aren't they in the content output group?

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


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bug with components which contain only XMLConfig elements?

On 3/31/2010 6:06 AM, Pally Sandher wrote:
 gives the same error (as expected). I can work around this simply by
 adding a RegistryValue to each component  setting it as the KeyPath for
 those components but does anyone know if this is expected behaviour or a
 bug with these types of components?

Keypaths must be resources MSI knows about. XmlConfig isn't.g So yes, 
another resource is a good idea, or including XmlConfig only in another 
component with a known keypath (e.g., a file you're modifying with 
XmlConfig).

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


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WixUI_InstallDir suggests wrong Program Files directory for norwegian version of Windows

On 3/30/2010 9:11 AM, Trond Andersen wrote:
 Directory Id=ProgramFilesFolder


ProgramFilesFolder provides the default. Check a verbose log to see what 
MSI thinks the Program Files folder is named.

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


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode

On 3/31/2010 2:31 PM, little.forest wrote:
 Actually we asked the vendor first, but they told us sorry, we don't support 
 Wix...


They don't have to support WiX, just MSI.

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


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.0: Bug in LIGHT

On 3/31/2010 8:55 AM, Markus Karg wrote:
 tried to link it using LIGHT. LIGHT says that there is a duplicate in
 that fragment, so we checked the fragment. In fact, there is no
 duplicate:


What's the exact error message?

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


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Version of WiX that groks .NET 4.0 assemblies?

On 3/31/2010 6:50 PM, Dan Thompson (SBS) wrote:
 We are upgrading our toolset to use .NET 4.0, but I found that light.exe 
 failed, because it thought that a particular file was not a valid assembly. 
 Not surprising, since light.exe probably uses standard reflection APIs, and 
 can't grok a .NET 4.0 binary. Has anyone started building WiX for .NET 4.0?


Grab the latest WiX v3.5 build.

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


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX, Votive, installed files and incremental builds

On 3/31/2010 4:07 AM, Michael Bednarek wrote:
 However, what about keeping track of additional files like config files, text 
 files, etc for your application?

There's nothing in WiX to communicate with build systems about the 
payloads. Feel free to file a feature request -- or implement it! -- it 
would be a good feature.

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


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] read a file + advertise

2010-03-31 Thread lewisv


Ok, i can save the data that is in my xml in the registry. But i will need to
do that only the first time. 
How do i determine, if this is a first time install ( where i need to read
the xml file) for an advertise install where i need to read the registry. 

Should i just have my custom action check the registry first? If i do that,
what will happen on an uninstall/re-install. I need to to re-read the xml
file then.

Should i always write to the registry also, even if the values are already
there?

-- 
View this message in context: 
http://n2.nabble.com/read-a-file-advertise-tp4834153p4834819.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] netfx:NativeImage action issues