[WiX-users] help

[Chinna Ganesh]

On 5/1/10, wix-users-requ...@lists.sourceforge.net <
wix-users-requ...@lists.sourceforge.net> wrote:
>
> Send WiX-users mailing list submissions to
>wix-users@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.sourceforge.net/lists/listinfo/wix-users
> or, via email, send a message with subject or body 'help' to
>wix-users-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
>wix-users-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WiX-users digest..."
>
>
> Today's Topics:
>
>   1. LGHT0048: The document element name "Wix" is invalid (wallywojo)
>   2. Re: LGHT0048: The document element name "Wix" is invalid
>  (Jim Williams)
>   3. Re: LGHT0048: The document element name "Wix" is invalid
>  (wallywojo)
>   4. Could WiX warn about this? (John Aldridge)
>   5. Re: Could WiX warn about this? (wallywojo)
>   6. Re: A new plan for WiX v3.5, introducing WiX v3.6
>  (John H. Bergman (XPedient Technologies))
>   7. Double entries in Add/Remove programs (Wix Mailing List)
>   8. Re: Double entries in Add/Remove programs (wallywojo)
>   9. Re: Double entries in Add/Remove programs (Wix Mailing List)
>
>
> --
>
> Message: 1
> Date: Fri, 30 Apr 2010 10:18:54 -0700 (PDT)
> From: wallywojo 
> Subject: [WiX-users] LGHT0048: The document element name "Wix" is
>invalid
> To: wix-users@lists.sourceforge.net
> Message-ID: <1272647934936-4986792.p...@n2.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> I searched and found a few matches with no replies. Can anyone assist when
> building with this
>
> E:\Users\\Documents\WiX Projects\DSMail\DSMail>light -o "Mail
> Test.msi
> " -ext WixUIExtension Product.wixobj SecuritySettings.wxs
> EncryptionSettings.wxs
> DLHServerSettings.wxs DigitalSafeConfigSettings.wxs DigitalIDRef.wxs
> ConfigureEmailSearching.wxs ConfigureDefaultLanguage.wxs
>
> gives this:
> Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> E:\Users\\Documents\WiX Projects\Mail\Mail\SecuritySettings.wxs :
> er
> ror LGHT0048 : The document element name 'Wix' is invalid.  A Windows
> Installer
> XML output file must use 'wixOutput' as the document element name.
>
> I try in VS with Votive and it causes VS to crash. Is there an issue with
> my
> environment or is something wrong within the SecuritySettings.wxs file?
>
> Thanks
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/LGHT0048-The-document-element-name-Wix-is-invalid-tp4986792p4986792.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
>
> --
>
> Message: 2
> Date: Fri, 30 Apr 2010 10:29:31 -0700
> From: Jim Williams 
> Subject: Re: [WiX-users] LGHT0048: The document element name "Wix" is
>invalid
> To: "General discussion for Windows Installer XML toolset."
>
> Cc: "wix-users@lists.sourceforge.net"
>
> Message-ID: 
> Content-Type: text/plain;   charset=us-ascii;
> format=flowed;  delsp=yes
>
> It looks like you are trying to link (light) WiX source files.
> Shouldn't you be using 'candle' to compile them first
>
> Jim Williams
>
> On Apr 30, 2010, at 10:18 AM, wallywojo  wrote:
>
> >
> > I searched and found a few matches with no replies. Can anyone
> > assist when
> > building with this
> >
> > E:\Users\\Documents\WiX Projects\DSMail\DSMail>light -o
> > "Mail
> > Test.msi
> > " -ext WixUIExtension Product.wixobj SecuritySettings.wxs
> > EncryptionSettings.wxs
> > DLHServerSettings.wxs DigitalSafeConfigSettings.wxs DigitalIDRef.wxs
> > ConfigureEmailSearching.wxs ConfigureDefaultLanguage.wxs
> >
> > gives this:
> > Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
> > Copyright (C) Microsoft Corporation. All rights reserved.
> >
> > E:\Users\\Documents\WiX Projects\Mail\Mail
> > \SecuritySettings.wxs :
> > er
> > ror LGHT0048 : The document element name 'Wix' is invalid.  A Windows
> > Installer
> > XML output file must use 'wixOutput' as the document element name.
> >
> > I try in VS with Votive and it causes VS to crash. Is there an issue
> > with my
> > environment or is something wrong within the SecuritySettings.wxs
> > file?
> >
> > Thanks
> > --
> > View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/LGHT0048-The-document-element-name-Wix-is-invalid-tp4986792p4986792.html
> > Sent from the wix-users mailing list archive at Nabble.com.
> >
> > ---
> > ---
> > ---
> > -
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> ---

Re: [WiX-users] How do you rollback an install after an error in custom action

[Robert Hermann]

I've got some  custom actions that creates some sql server functions and
create an xml config file as one of the last things that happens in an
install.

If an error occurs in the custom action, I need the install to roll
back,  basically to uninstall itself.

The sql server scripts are installed as text files. The custom actions
reads from the text files and then through an
Connection to the database, it executes the script commands.


Here is how it execute the custom actions:

  
  Not Installed AND
DATABASEALREADYEXISTS="FALSE"  
  Not Installed
  Installed



If I run the install with the After="InstallFinalize" , and the custom
action runs into an error I return the ActionResult.Failure.  I get the
wix dialog that says an error has occurred and the system has not been
modified.  
The system does get modified.

If I run the install with the After="InstallFiles" or
Before="InstallFinalize", the custom action runs into an error where the
scripts files have not been installed yet.

I realize I can always place the content of these scripts files into a
string array and do away with the files.

I would still have a problem though If something happened during config
file creation (CreateHTSServiceConfig). I still need the install to roll
itself back after all other files have been installed.   

Am I using the right approach, is there an event I can look for
Before="some event"  and if the custom action returns an error when
creating  the config file, have the install rollback ?

I do I need a new approach ?

Rob



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Double entries in Add/Remove programs

[Wix Mailing List]

In the log:

MSI (s) (9C:6C) [11:09:51:218]: Doing action: RemoveExistingProducts
MSI (s) (9C:6C) [11:09:51:218]: Note: 1: 2205 2:  3: ActionText 
Action 11:09:51: RemoveExistingProducts. Removing applications
Action start 11:09:51: RemoveExistingProducts.
MSI (s) (9C:6C) [11:09:51:228]: Note: 1: 2205 2:  3: Error 
MSI (s) (9C:6C) [11:09:51:228]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 22 
MSI (s) (9C:6C) [11:09:51:228]: Note: 1: 2205 2:  3: Error 
MSI (s) (9C:6C) [11:09:51:228]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 23 
MSI (s) (9C:6C) [11:09:51:228]: Note: 1: 2205 2:  3: Error 
MSI (s) (9C:6C) [11:09:51:228]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 16 
MSI (s) (9C:6C) [11:09:51:228]: Note: 1: 2205 2:  3: Error 
MSI (s) (9C:6C) [11:09:51:228]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 21 
Action ended 11:09:51: RemoveExistingProducts. Return value 1.

Where can I find out what the errors mean?

Not sure what you mean about getting the info.  Is there some way to dump
this from the msi file?

Any ideas as to why the value might be wrong.  As I said in the first post,
this comes right from the help entry on how to do a major upgrade, and I
think I followed it correctly.  And the only thing I change after the first
install is the values I mentioned (for example, I don't touch the upgrade
code).

-Original Message-
From: wallywojo [mailto:wallyw...@gmail.com] 
Sent: Friday, April 30, 2010 1:26 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Double entries in Add/Remove programs


yeah, findrelatedproducts is before removeexistingproducts.

In the log, what do you have related to RemoveExistingProducts? This is a
side issue, the main issue is that the property associated with the Upgrade
entry has no value which means it is not finding a match. Sometimes for this
I will create a really simple vbscript file to check for the presence using
the info to get a quick test if your information is accurate like the
upgrade code and the version range.
-- 
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Double-entries
-in-Add-Remove-programs-tp4987063p4987704.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Building Patches With Pyro

[Stephen Reindl]

I've also had problems with embedded binary files (dynamic libraries,...)

Regards
Stephen

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Freitag, 30. April 2010 13:12
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Building Patches With Pyro

Usually this is caused by A/V software running on your build machine.

-Original Message-
From: Kyle Huey [mailto:ksh...@ufl.edu] 
Sent: Saturday, April 03, 2010 12:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Building Patches With Pyro

Hello All,

I'm using WIX 3.0 RTM to build patches for an MSI I've developed.  The MSIs
work great, and I can build a patch off of the .wixpdb files, but if I try
to create a patch off of an administrative installation of the MSIs pyro
fails.  See the following output:

$ pyro -v -delta patch.wixmsp -out patch.msp -t RTM patch.wixmst
Microsoft (R) Windows Installer Xml Patch Builder version 3.0.5419.0
Copyright (C) Microsoft Corporation. All rights reserved.

Updating file information.
Creating cabinet files.
Creating cabinet 'C:\Users\Kyle Huey\AppData\Local\Temp\taylsrel\#RTM.cab'.
Generating database.
C:\Users\Kyle Huey\AppData\Local\Temp\taylsrel\patch.msp : error PYRO0103 :
The
system cannot find the file 'C:\Users\Kyle
Huey\AppData\Local\Temp\taylsrel\patc
h.msp'.

If I use the -notidy flag the temporary directory has the generated CAB in
it as well as a patch.msp file.  Opening the patch.msp file in Orca fails
though.  Is this a known bug?  Does anyone have any ideas for what I can do
to work around it?

Thanks,

- Kyle

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


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Double entries in Add/Remove programs

[wallywojo]

yeah, findrelatedproducts is before removeexistingproducts.

In the log, what do you have related to RemoveExistingProducts? This is a
side issue, the main issue is that the property associated with the Upgrade
entry has no value which means it is not finding a match. Sometimes for this
I will create a really simple vbscript file to check for the presence using
the info to get a quick test if your information is accurate like the
upgrade code and the version range.
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Double-entries-in-Add-Remove-programs-tp4987063p4987704.html
Sent from the wix-users mailing list archive at Nabble.com.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Double entries in Add/Remove programs

[Wix Mailing List]

I was just using the example in the help file.  I don't call
FindRelatedProducts directly, I'm assuming it gets called before the Upgrade
actions do.  If not, how does one go about doing this?

-Original Message-
From: wallywojo [mailto:wallyw...@gmail.com] 
Sent: Friday, April 30, 2010 11:25 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Double entries in Add/Remove programs


Hi Dan to point out here that might get you in the right direction. If you
are trying a launch condition based on a product lookup you cannot use
FindRelatedProducts since that happens after the LaunchConditions action.
-- 
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Double-entries
-in-Add-Remove-programs-tp4987063p4987090.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Double entries in Add/Remove programs

[wallywojo]

Hi Dan to point out here that might get you in the right direction. If you
are trying a launch condition based on a product lookup you cannot use
FindRelatedProducts since that happens after the LaunchConditions action.
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Double-entries-in-Add-Remove-programs-tp4987063p4987090.html
Sent from the wix-users mailing list archive at Nabble.com.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Double entries in Add/Remove programs

[Wix Mailing List]

I looked at the thread in the archive, but it appears that this person
didn't resolve his issue (or at least didn't post when he did).  Here's what
I've got:

 







 



  

  





  



 

..

 

   

  



 

The InstallExecuteSequence if after the  list if that matters.

 

I install as above, everything works as it should. Then I change
Product/@Version, UpgradeVersion(OLDER.)/@Maximum and
UpgradeVersion(NEWER.)/@Minimum all to 0.02.0.

 

I install again, it installs and I have two entries in the Add/Remove table,
one for version 0.01.0 and one for 0.02.0. 

 

In the log for FindRelatedProducts I find:

 

MSI (c) (E0:BC) [11:09:30:281]: Doing action: FindRelatedProducts

MSI (c) (E0:BC) [11:09:30:281]: Note: 1: 2205 2:  3: ActionText 

Action 11:09:30: FindRelatedProducts. Searching for related applications

Action start 11:09:30: FindRelatedProducts.

Action ended 11:09:30: FindRelatedProducts. Return value 1.

 

MSI (s) (9C:6C) [11:09:50:357]: Doing action: FindRelatedProducts

MSI (s) (9C:6C) [11:09:50:357]: Note: 1: 2205 2:  3: ActionText 

Action 11:09:50: FindRelatedProducts. Searching for related applications

Action start 11:09:50: FindRelatedProducts.

MSI (s) (9C:6C) [11:09:50:357]: Skipping FindRelatedProducts action: already
done on client side

Action ended 11:09:50: FindRelatedProducts. Return value 0.

 

Which, given the other thread leads me to believe that FindRelatedProducts
isn't finding the prior install, but I can't for the life of me figure out
why.  Can anyone point me in the right direction here?

 

Thanks

 

Dan

 

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] A new plan for WiX v3.5, introducing WiX v3.6

[John H. Bergman (XPedient Technologies)]

This seems like a good and sound plan.  Will 3.5 be moved over to codeplex as 
well (or updated so the source build from a version control repository)?

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: Wednesday, April 28, 2010 11:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] A new plan for WiX v3.5, introducing WiX v3.6

I just posted a blog entry about changes to the WiX v3.5 plan:
http://robmensching.com/blog/posts/2010/4/28/Change-of-plans-for-WiX-v3.5.

This plan is based on feedback sent here (and other places) about getting a 
stable WiX toolset that supports Visual Studio 2010. It pains me to bump Burn 
again but the simple fact is Burn isn't going to be ready soon.

I also want to point out the plan to drop Visual Studio 2005 support from*WiX 
v3.6 *. We aren't fixing bugs in Votive for VS2005 any more and I know there 
were some big problems left. It seems that people have all moved to VS2008 and 
now VS2010.

As always, feedback is welcome.

--
virtually, Rob Mensching - http://RobMensching.com LLC
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Could WiX warn about this?

[wallywojo]

may not need anything additional, I am pretty sure that a Full MSI validation
would report this. Have you tried to validate the built MSI?
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Could-WiX-warn-about-this-tp4986969p4986987.html
Sent from the wix-users mailing list archive at Nabble.com.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Could WiX warn about this?

[John Aldridge]

I've just made a mistake like the following simplified example

   
 
   
 
   

   
 
   
 
   

This is a 64 bit installer, which needs to install both the 32 and 64 
bit versions of a DLL in the respective system folders.

This all works fine until I come to do an administrative installation, 
at which point both DLLs unpack to the same location, with one 
overwriting the other.

I know (now!) that the solution is to give a Name attribute on the two 
Directory elements, e.g.

   
 :
   
 :

but would it be possible for WiX to warn me if I do something stupid 
like this?

-- 
Cheers,
John

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] LGHT0048: The document element name "Wix" is invalid

[wallywojo]

thanks Jim, yeah missed a small step with my custom dialogs.
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/LGHT0048-The-document-element-name-Wix-is-invalid-tp4986792p4986860.html
Sent from the wix-users mailing list archive at Nabble.com.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] LGHT0048: The document element name "Wix" is invalid

[Jim Williams]

It looks like you are trying to link (light) WiX source files.   
Shouldn't you be using 'candle' to compile them first

Jim Williams

On Apr 30, 2010, at 10:18 AM, wallywojo  wrote:

>
> I searched and found a few matches with no replies. Can anyone  
> assist when
> building with this
>
> E:\Users\\Documents\WiX Projects\DSMail\DSMail>light -o  
> "Mail
> Test.msi
> " -ext WixUIExtension Product.wixobj SecuritySettings.wxs
> EncryptionSettings.wxs
> DLHServerSettings.wxs DigitalSafeConfigSettings.wxs DigitalIDRef.wxs
> ConfigureEmailSearching.wxs ConfigureDefaultLanguage.wxs
>
> gives this:
> Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
> Copyright (C) Microsoft Corporation. All rights reserved.
>
> E:\Users\\Documents\WiX Projects\Mail\Mail 
> \SecuritySettings.wxs :
> er
> ror LGHT0048 : The document element name 'Wix' is invalid.  A Windows
> Installer
> XML output file must use 'wixOutput' as the document element name.
>
> I try in VS with Votive and it causes VS to crash. Is there an issue  
> with my
> environment or is something wrong within the SecuritySettings.wxs  
> file?
>
> Thanks
> -- 
> View this message in context: 
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/LGHT0048-The-document-element-name-Wix-is-invalid-tp4986792p4986792.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
> --- 
> --- 
> --- 
> -
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] LGHT0048: The document element name "Wix" is invalid

[wallywojo]

I searched and found a few matches with no replies. Can anyone assist when
building with this

E:\Users\\Documents\WiX Projects\DSMail\DSMail>light -o "Mail
Test.msi
" -ext WixUIExtension Product.wixobj SecuritySettings.wxs
EncryptionSettings.wxs
 DLHServerSettings.wxs DigitalSafeConfigSettings.wxs DigitalIDRef.wxs
ConfigureEmailSearching.wxs ConfigureDefaultLanguage.wxs

gives this:
Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0
Copyright (C) Microsoft Corporation. All rights reserved.

E:\Users\\Documents\WiX Projects\Mail\Mail\SecuritySettings.wxs :
er
ror LGHT0048 : The document element name 'Wix' is invalid.  A Windows
Installer
XML output file must use 'wixOutput' as the document element name.

I try in VS with Votive and it causes VS to crash. Is there an issue with my
environment or is something wrong within the SecuritySettings.wxs file?

Thanks
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/LGHT0048-The-document-element-name-Wix-is-invalid-tp4986792p4986792.html
Sent from the wix-users mailing list archive at Nabble.com.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Candle: Add new GUIDs to user specified locations atcompile time?

[Rob Mensching]

I know of no scenario where you'd want to do that. That's on reason why it
isn't made easy. 

On Fri, Apr 30, 2010 at 9:12 AM, Castro, Edwin G. (Hillsboro) <
edwin.cas...@fiserv.com> wrote:

> If you absolutely need to change the Product UpgradeCode on every build (Is
> this a good idea?), then you'll need to extend your build process to do it
> yourself. XML is relatively easy to change, especially in PowerShell.
> Executing something like the following could help:
>
> powershell -command "$wixFile = 'Product.wxs' ; $doc = [xml](Get-Content
> -Path $wixFile) ; $doc.Wix.Product.UpgradeCode =
> [System.Guid]::NewGuid().ToString() ; $doc.Save($wixFile)"
>
> 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: Pally Sandher [mailto:pally.sand...@iesve.com]
> > Sent: Friday, April 30, 2010 8:14 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Candle: Add new GUIDs to user specified
> > locations atcompile time?
> >
> > 
> > 
> >
> > Good luck with changing the UpgradeCode every time you build. You may
> > as
> > well just remove it instead as it's about as useful as a chocolate
> > fireguard with that requirement.
> >
> > 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 **
> > 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: jeff00seattle [mailto:jeff_tan...@earthlink.net]
> > Sent: 30 April 2010 16:02
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Candle: Add new GUIDs to user specified locations
> > atcompile time?
> >
> >
> > Hi
> >
> > Is there a way that a new GUID can be added to specific location within
> > WiX at compile time?
> >
> > I have created a common WiX file, and I want to add a new GUID upon
> > each
> > run
> > to:
> > * Product Id
> > * Product UpgradeCode
> > * Component Guid
> >
> > I read in one blob
> > http://johnmcfadyen.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c
> > =
> > BlogPart&partqs=cat%3DWiX
> > John McFadyens Windows Installer Blog  that using
> > "----" creates a new generated GUID
> > each
> > time the compiler runs. This ensures you are running with the rule of
> > creating a new package code for each iteration of your package.
> >
> > However, this did not work.
> >
> >
> > -
> > Thanks
> > Jeff in Seattle
> > --
> > View this message in context:
> > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Candle-
> > Add
> > -new-GUIDs-to-user-specified-locations-at-compile-time-
> > tp4986130p4986130
> > .html
> > Sent from the wix-users mailing list archive at Nabble.com.
>
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Candle: Add new GUIDs to user specified locations atcompile time?

[Castro, Edwin G. (Hillsboro)]

If you absolutely need to change the Product UpgradeCode on every build (Is 
this a good idea?), then you'll need to extend your build process to do it 
yourself. XML is relatively easy to change, especially in PowerShell. Executing 
something like the following could help:

powershell -command "$wixFile = 'Product.wxs' ; $doc = [xml](Get-Content -Path 
$wixFile) ; $doc.Wix.Product.UpgradeCode = [System.Guid]::NewGuid().ToString() 
; $doc.Save($wixFile)"

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: Pally Sandher [mailto:pally.sand...@iesve.com]
> Sent: Friday, April 30, 2010 8:14 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Candle: Add new GUIDs to user specified
> locations atcompile time?
> 
> 
> 
> 
> Good luck with changing the UpgradeCode every time you build. You may
> as
> well just remove it instead as it's about as useful as a chocolate
> fireguard with that requirement.
> 
> 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 **
> 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: jeff00seattle [mailto:jeff_tan...@earthlink.net]
> Sent: 30 April 2010 16:02
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Candle: Add new GUIDs to user specified locations
> atcompile time?
> 
> 
> Hi
> 
> Is there a way that a new GUID can be added to specific location within
> WiX at compile time?
> 
> I have created a common WiX file, and I want to add a new GUID upon
> each
> run
> to:
> * Product Id
> * Product UpgradeCode
> * Component Guid
> 
> I read in one blob
> http://johnmcfadyen.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c
> =
> BlogPart&partqs=cat%3DWiX
> John McFadyens Windows Installer Blog  that using
> "----" creates a new generated GUID
> each
> time the compiler runs. This ensures you are running with the rule of
> creating a new package code for each iteration of your package.
> 
> However, this did not work.
> 
> 
> -
> Thanks
> Jeff in Seattle
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Candle-
> Add
> -new-GUIDs-to-user-specified-locations-at-compile-time-
> tp4986130p4986130
> .html
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> ---
> -
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
> ---
> ---
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] unsuscribe

[Pratik Mehta]

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Candle: Add new GUIDs to user specified locations atcompile time?

[Pally Sandher]

Good luck with changing the UpgradeCode every time you build. You may as
well just remove it instead as it's about as useful as a chocolate
fireguard with that requirement.

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 **
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: jeff00seattle [mailto:jeff_tan...@earthlink.net] 
Sent: 30 April 2010 16:02
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Candle: Add new GUIDs to user specified locations
atcompile time?


Hi

Is there a way that a new GUID can be added to specific location within
WiX at compile time?

I have created a common WiX file, and I want to add a new GUID upon each
run
to:
* Product Id
* Product UpgradeCode
* Component Guid

I read in one blob
http://johnmcfadyen.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=
BlogPart&partqs=cat%3DWiX
John McFadyens Windows Installer Blog  that using
"----" creates a new generated GUID each
time the compiler runs. This ensures you are running with the rule of
creating a new package code for each iteration of your package.

However, this did not work.


-
Thanks
Jeff in Seattle
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Candle-Add
-new-GUIDs-to-user-specified-locations-at-compile-time-tp4986130p4986130
.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Candle: Add new GUIDs to user specified locations at compile time?

[jeff00seattle]

Hi

Is there a way that a new GUID can be added to specific location within WiX
at compile time?

I have created a common WiX file, and I want to add a new GUID upon each run
to:
* Product Id
* Product UpgradeCode
* Component Guid

I read in one blob 
http://johnmcfadyen.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=BlogPart&partqs=cat%3DWiX
John McFadyens Windows Installer Blog  that using
"----" creates a new generated GUID each
time the compiler runs. This ensures you are running with the rule of
creating a new package code for each iteration of your package.

However, this did not work.


-
Thanks
Jeff in Seattle
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Candle-Add-new-GUIDs-to-user-specified-locations-at-compile-time-tp4986130p4986130.html
Sent from the wix-users mailing list archive at Nabble.com.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] TFS 2010, Network Service and ICE validation

[Alex Ivanoff]

It is: InstallShield works in the same configuration.


-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] 
Sent: Friday, April 30, 2010 00:36
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] TFS 2010, Network Service and ICE validation

I would suggest opening a bug/support case with the team build guys :) It 
doesn't sound like this is a WiX bug...


On Thu, Apr 29, 2010 at 11:59 PM, Will Sullivan  wrote:
> This is going to start hitting big, as people encounter ICE validation 
> failures on a team build.
>
> Apparently, what's going on is that the default account used by 2010 team 
> build, Network Service, is unable to interact with msiexec.exe.
>
> Unfortunately, there is NO decent solution to this available (as far as I can 
> search) on the interwebs.  The only viable solution is to change the build 
> account (one moron suggests adding Network Service to the admins group, ffs).
>
> Can someone who understands the security permissions needed provide an 
> official answer to this problem?
> --
>  ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Registry on 64bit XP vs Win7

[Pally Sandher]

Yes because using Custom Actions to circumvent Windows Installer
functions never caused anyone any problems.
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/UAC-issue-
td4947851.html 

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 **
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: Albert At School [mailto:alb...@de-notenbalk.nl] 
Sent: 30 April 2010 15:40
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Registry on 64bit XP vs Win7

There is a way; use a CA which checks what OS you're running on (x86 or
x64) and then use the registry redirection flags or functions to inform
the registry redirector to use the correct registry.
Note that these functions only work on x64 OSses (they do work in x86
exeutables on x64 OS).
Not sure for WinXP x64 however but I assume that'll work as well.

If I am not mistaken the technique as described is used in our open
source CA as well; look into the source and maybe it'll set you on the
correct path
:)

You can found it here: http://madbutcher.dyndns.org/snippets/SQLMsiCA

Regards,

Albert van Peppen

- Original Message -
From: "Pally Sandher" 
To: "General discussion for Windows Installer XML toolset." 

Sent: Friday, April 30, 2010 12:32 PM
Subject: Re: [WiX-users] Registry on 64bit XP vs Win7


> Build an x64 package to write to x64 areas of the registry. You can't
do
> it in an x86 package. Nothing to do with WiX, Windows Installer
> limitation.
>
> 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 **
> 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: Yu, Brian [mailto:b...@easyscreen.com]
> Sent: 30 April 2010 10:40
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Registry on 64bit XP vs Win7
>
> Hi there
>
>
>
> I found by testing that in 64 bit XP, the registry path is somehow
> different
>
> It should be hklm/SOFTWARE but now becomes hklm/SOFTWARE/wow6432
>
>
>
> How do I get WIX to selectively install into the right paths depending
> on whether it's XP or Win7
>
>
>
> Brian
>
>
> _
> This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are
> incorporated under the laws of England and Wales (company no. 05677531
> and VAT registration no. 872810613). Our registered office is at 155
> Bishopsgate, London EC2M 3TQ. This e-mail and/or any attached
documents
> may contain privileged and confidential information and should only be
> read by those persons to whom this e-mail is addressed. Use by other
> than intended recipients is prohibited. If you are not the addressee,
> you must not copy, distribute, disclose or use any of the information
in
> it. If you have received it in error, please delete it and immediately
> notify the sender. EASYSCREEN reserves the right to monitor all e-mail
> messages passing through its network. As we cannot guarantee the
> genuineness, accuracy or completeness of the information contained in
> this message, the statements set forth are not legally binding.
>

> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>

--
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users 



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Registry on 64bit XP vs Win7

[Albert At School]

There is a way; use a CA which checks what OS you're running on (x86 or x64) 
and then use the registry redirection flags or functions to inform the 
registry redirector to use the correct registry.
Note that these functions only work on x64 OSses (they do work in x86 
exeutables on x64 OS).
Not sure for WinXP x64 however but I assume that'll work as well.

If I am not mistaken the technique as described is used in our open source 
CA as well; look into the source and maybe it'll set you on the correct path 
:)

You can found it here: http://madbutcher.dyndns.org/snippets/SQLMsiCA

Regards,

Albert van Peppen

- Original Message - 
From: "Pally Sandher" 
To: "General discussion for Windows Installer XML toolset." 

Sent: Friday, April 30, 2010 12:32 PM
Subject: Re: [WiX-users] Registry on 64bit XP vs Win7


> Build an x64 package to write to x64 areas of the registry. You can't do
> it in an x86 package. Nothing to do with WiX, Windows Installer
> limitation.
>
> 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 **
> 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: Yu, Brian [mailto:b...@easyscreen.com]
> Sent: 30 April 2010 10:40
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Registry on 64bit XP vs Win7
>
> Hi there
>
>
>
> I found by testing that in 64 bit XP, the registry path is somehow
> different
>
> It should be hklm/SOFTWARE but now becomes hklm/SOFTWARE/wow6432
>
>
>
> How do I get WIX to selectively install into the right paths depending
> on whether it's XP or Win7
>
>
>
> Brian
>
>
> _
> This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are
> incorporated under the laws of England and Wales (company no. 05677531
> and VAT registration no. 872810613). Our registered office is at 155
> Bishopsgate, London EC2M 3TQ. This e-mail and/or any attached documents
> may contain privileged and confidential information and should only be
> read by those persons to whom this e-mail is addressed. Use by other
> than intended recipients is prohibited. If you are not the addressee,
> you must not copy, distribute, disclose or use any of the information in
> it. If you have received it in error, please delete it and immediately
> notify the sender. EASYSCREEN reserves the right to monitor all e-mail
> messages passing through its network. As we cannot guarantee the
> genuineness, accuracy or completeness of the information contained in
> this message, the statements set forth are not legally binding.
> 
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users 


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Display UI Dialog from custom action dll

[vunder]

How to display UI dialog from C++ custom action? I found function
MsiPreviewDialog(). It need a handle to the preview. I Found
MsiEnableUIPreview() function, whitch need a handle to database. I try to
get database handle from MsiGetActiveDatabase() and MsiOpenDatabase() and it
was allways 0.

P.S. Custom action call's in  context.

  !(loc.CheckIBRunning)




  NOT Installed




-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Display-UI-Dialog-from-custom-action-dll-tp4985420p4985420.html
Sent from the wix-users mailing list archive at Nabble.com.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] error CNDL0200

[Blair]

If you drop the path and extension, candle.exe and light.exe will both look
in the same directory as they are in. Thus, ' -ext WixUtilExtension ' should
be sufficient.

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Tuesday, April 06, 2010 7:50 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] error CNDL0200

Tell candle.exe where to find WiXUtilExtension.dll like it says.

Adding ' -ext "C:\Program Files\Windows Installer XML
v3\bin\WixUtilExtension.dll" ' should work assuming you have WiX v3.0
installed to the default location on a 32-bit O/S.

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 **
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: 05 April 2010 17:35
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] error CNDL0200

Hi,

When I run this commond:

candle.exe -dVersion=1.1
"C:\Dev\usr\carolina.amaral\PatchCreation\Product\Product\Product.wxs"
-out "C:\Dev\usr\carolina.amaral\PatchCreation\1.1\Product.wixobj

The following error occurs:

error CNDL0200 : The Component element contains an unhandled extension
element 'Util:XmlFile'.  Please ensure that the extension for elements
in the 'http://schemas.microsoft.com/wix/UtilExtension' namespace has
been provided.

How I resolve it?




-

Code:


http://schemas.microsoft.com/wix/2006/wi";
 xmlns:Util="http://schemas.microsoft.com/wix/UtilExtension"; >

  







  

  







  

  





  



  

  





-

Tranks,

Carolina Zuqueto Amaral
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® 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


--

[WiX-users] FW: On managing dependency hell with WiX and C#

[Blair]

Did you get any resolution on this?

Many of the problems you are describing look to me like the kinds of things
that happen when the component rules are violated. No amount of
hacks/workarounds cleans up the mess in that case.

Some questions: which build of the wix toolset are you using? How are you
generating your component guids? Are you generating your installer code as
part of your build, and if so, how?

Principally what has to happen (for the component rules) is that each file
should generally be in its own component, that component's GUID should be
stable (only change if the file either moves or is renamed) from build to
build, and the FileVersion of the files should also change build-to-build
(.NET uses AssemblyVersion, not FileVersion, for strong-name matching, so
that shouldn't be hard to do). For GUID generation, I recommend '*' since
the code automatically follows the above rules for stability relative to
filename and directory, but that requires WiX 3.x. Also, don't change your
directory layouts from build to build without thinking about them a lot
first.

For 32-bit/64-bit: create two MSIs and only install the MSI corresponding to
each platform. An x64 MSI can place anything exactly where you want it on
any x64 platform, and an x86 MSI will place things exactly where 32-bit code
can/will find it.

-Original Message-
From: Thomas C. Corelis [mailto:t...@xlotus.net] 
Sent: Monday, April 05, 2010 2:33 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] On managing dependency hell with WiX and C#

Hi everyone,

 

I posted the following question originally at Stack Overflow (here:
http://tinyurl.com/yb6n9qb) and it was suggested I bring it up here:

 

"We are on the eve of product launch, and at the last minute I am being
bombarded with crash reports that appear to be related to our installer,
which is a WiX3 project with separate outputs for x86 and x64 builds.
These have been an ongoing problem that I always thought were fixed,
only to find out that they were still lurking.

 

"The product itself is a collection of binaries that communicate with
each other via .Net remoting, including a Windows Service and a small
COM component that is loaded as an addon in another app. The service
runs as SYSTEM, the COM piece runs in a low-rights context, while the
other pieces run in normal user contexts. Other pieces include an
third-party COM object library DLL and a shared DLL with the .net
Remoting interfaces.

 

"I've observed flat-out weird behavior with MSI, particularly on version
upgrades. Between MS' anal strong-name implementation (specifically, the
exact version check before loading a given assembly), a documented
WiX/MSI bug that sees critical files erased on upgrades (essentially, if
a file in the upgrade MSI has the same version number as the existing
install, that file is deleted), and having to work around Wow64
virtualization (x86 MSI can only write to registry/HD locations via
Wow64, yet x64 MSIs cannot run on x86 computers...), I am about ready to
trash the whole thing and port it over to a different install system
(NSIS maybe?).

 

"What I am looking for on tips + tricks, techniques, or suggestions on
how to properly do things so that I am not fighting with Windows
Installer's twisted sense of logic. I am tired of fighting with
WiX/MSI/Windows Installer. All it needs to do is place files and
registry keys where I tell it to, upgrade them when appropriate, and
don't delete anything until the user uninstalls, preferably without
hacks. Instead, dependencies are deleted willy-nilly, much code is
duplicated, and my app is throwing up a whole bunch of weird,
uncatchable 'assembly not found' exceptions.

 

"I am particularly interested in 'best practices' and examples regarding
shared and dependency DLLs, and any tips on making sure if a file needs
to go to GAC, that it actually goes to the GAC and stays there until it
is appropriate to remove it."

 

I have specific examples I can provide if needed, but to be honest the
code on my end has been rewritten so many times that I am not sure how
useful such things are. I would love to re-simplify the master wxs file,
as right now it is quite large and has a fair amount of duplication due
to the need for separate x86 and x86/x64 support. I've tried spinning
out various pieces into merge modules, placing required files in GAC,
placing required in the install folders... and every time, I run in to
problems with the users' upgrade process.

 

Thanks!

 

Tom


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

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

[dB .]

We ended up just (writing) using a deferred CA from http://msiext.codeplex.com 
with a condition.

Uninstalling
Uninstalling

dB. @ dblock.org 
Moscow|Geneva|Seattle|New York



-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Friday, April 30, 2010 5:57 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Deleting a file only when uninstalling - not installs, 
not upgrades, not repairs or modifies

Unless the transient flag is set on a component, conditions for that
component are only evaluated upon installation of that component.

I think a little illustration here of what happens during installs,
upgrades, and removals will help you understand.

Initial installation: component with GUID in MSI-1 is selected for
installation based on condition WHATEVER-2.

Repair: File will not be deleted, but may or may not be rewritten, depending
on several factors including the REINSTALLMODE variable and characteristics
of the file itself (is it versioned or not, timestamp and/or hash  or size
mismatches, etc.).

Upgrade (with "early" RemoveExistingProducts): Uninstall transaction is run
using cached/stripped MSI-1, then Install transaction is run using MSI-2.
Thus, the file will be deleted during the removal operation and then
possibly written during the installation operation based on condition
WHATEVER-2.

Upgrade (with "late" RemoveExistingProducts): Install transaction is run
using MSI-2, then Uninstall transaction is run using cached/stripped MSI-1.
As long as the file is from a component with the exact same GUID in both
MSIs the file will not be deleted during the uninstall portion if the
condition WHATEVER-2 requests installation, but the file may or may not be
overwritten (see Repair above).

Removal: File will be deleted, unless the component was marked Permanent.

Using the transient flag allows for removals during repairs, but can't
prevent removals during uninstall operations.

-Original Message-
From: Viv Coco [mailto:vcotirl...@hotmail.com] 
Sent: Wednesday, March 31, 2010 4:09 AM
To: General discussion for Windows Installer XML toolset.
Subject: [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]


NOT UPGRADINGPRODUCTCODE

[/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® 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 mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Common Standard Protection: Prevent common programs from running files from the Temp folder Action blocked: Execute

[Blair]

MSI runs external (exe) custom actions in the temporary folder. It may be
possible to change the TEMP environment variable, but it must be changed
before the MSI service starts and it must be changed for the SYSTEM user,
and McAfee in that circumstance will probably prevent files in that new
folder from running.

WiX supplies elements/actions to create and deploy Event Logs. Do they not
work for you?

-Original Message-
From: Lingaraj Mishra [mailto:lingaraj.mis...@rave-tech.com] 
Sent: Monday, April 05, 2010 12:09 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Common Standard Protection: Prevent common programs
from running files from the Temp folder Action blocked: Execute

Hi users

 

I have created a Custom Action to invoke a .exe
CreateWBCustomLog.exe.(This exe will create Event Log folder while
installation)

 





 

This works fine and CreateWBCustomLog.exe executed succesfully for all
the system except one of the system where McAfee is installed.

 

While installing on above system it is noted that standard SOE McAfee
installation blocks files executing from Temp folder. 

 

"Common Standard Protection: Prevent common programs from running files
from the Temp folder Action blocked: Execute"

 

Here ExeCommand have [MyInstallationRootPath] which is provided from a
Config file as "C:\Test."

 

Any idea why Wix is executing this exe from Temp Folder if so how to
overcome this issue.

 

Please help.

 

Thanks

Raj

 


Disclaimer :-

"This communication contains information which is confidential and may also
be 
legally privileged.It is for the exclusive use of the intended recipient/s.

If you are not the intended recipient of this mail, please delete it
immediately and notify the
sender on +91 22 6660 6600 or by return e-mail confirming such deletion. Any
use, distribution, 
disclosure or copying this electronic mail except by its intended recipient
may be unlawful.

Rave has scanned this email for viruses but does not accept any
responsibility once this email 
has been transmitted."



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


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Building Patches With Pyro

[Blair]

Usually this is caused by A/V software running on your build machine.

-Original Message-
From: Kyle Huey [mailto:ksh...@ufl.edu] 
Sent: Saturday, April 03, 2010 12:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Building Patches With Pyro

Hello All,

I'm using WIX 3.0 RTM to build patches for an MSI I've developed.  The MSIs
work great, and I can build a patch off of the .wixpdb files, but if I try
to create a patch off of an administrative installation of the MSIs pyro
fails.  See the following output:

$ pyro -v -delta patch.wixmsp -out patch.msp -t RTM patch.wixmst
Microsoft (R) Windows Installer Xml Patch Builder version 3.0.5419.0
Copyright (C) Microsoft Corporation. All rights reserved.

Updating file information.
Creating cabinet files.
Creating cabinet 'C:\Users\Kyle Huey\AppData\Local\Temp\taylsrel\#RTM.cab'.
Generating database.
C:\Users\Kyle Huey\AppData\Local\Temp\taylsrel\patch.msp : error PYRO0103 :
The
system cannot find the file 'C:\Users\Kyle
Huey\AppData\Local\Temp\taylsrel\patc
h.msp'.

If I use the -notidy flag the temporary directory has the generated CAB in
it as well as a patch.msp file.  Opening the patch.msp file in Orca fails
though.  Is this a known bug?  Does anyone have any ideas for what I can do
to work around it?

Thanks,

- Kyle

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


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] AppSearch

[Blair]

Example code that isn't working please? How many rows are in your Signature 
table?

There is no way to control the order that the rows in the Signature table are 
evaluated, but for each row there, the order of the other tables should be as 
documented.

-Original Message-
From: Szentpali Janos [mailto:ia...@easynet.ro] 
Sent: Thursday, April 01, 2010 10:34 AM
To: WiX
Subject: [WiX-users] AppSearch

Hello,

I created an MSI and transform for it that uses the AppSearch action. All the
AppSearch related data (AppSearch, DrLocator, RegLocator and Signature tables)
is in the transform. What I wanted to do is find a path in the registry and
than check that a file exists in that path. So it was vital for the RegLocator
to be executed first and than the DrLocator/Signature tables. The MSDK says:

"The AppSearch action searches for file signatures using the CompLocator table
first, the RegLocator table next, then the IniLocator table, and finally the
DrLocator table."

So in theory everything should be OK, but in practice it is not. After turning
on verbose logging I discovered that for whatever reason the
DrLocator/Signature tables were parsed first and only after that the RegLocator
table. Because of that the DrLocator had no valid path in which to search for
the file. Of course the LaunchConditions were never met. If I moved the
RegLocator data into the MSI than what the SDK said became true. But not when I
had everything in the transform. To be more clear: the row from AppSearch
relating to the RegLocator record was defined in the MSI, the AppSearch
relating to the DrLocator and Signature records were defined in the transform.
I did not experiment to find out what happened if all the AppSearch records
were defined in the MSI.

Does anyone know where could I find an explanation to this behavior? I mean why
is the order of parsing the AppSearch related tables not kept when applied from
the transform and it is when read from the tables? Is there a way to explicitly
enforce the order?
-- 
Szentpáli János

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


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Prevent deinstallation

[Blair]

An MSP can be marked as "uninstallable" which would mean the only way to
remove the patch is to remove the product it modifies.

-Original Message-
From: Markus Karg [mailto:k...@quipsy.de] 
Sent: Thursday, April 01, 2010 3:20 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Prevent deinstallation

Well, the problem is actually less that we want to prevent *files* from
getting removed (the module itself is not a file but a once-run
proprietary script that removes itself as soon as it successfully
terminated) but that we want to prevent (a) the uninstall button
produces any kind of error message (e. g. it does not find the
self-erased file), and (b) our hotline falls into a trap when checking
for installed modules using the system control panel, not seeing the
module anymore there.

Also, the modules are only dependent of the main product, but must be
independent of other modules.

So this sounds as if .msp is *not* the solution then?

> -Original Message-
> From: Richard Horsley [mailto:richard.hors...@eicltd.com]
> Sent: Donnerstag, 1. April 2010 12:05
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Prevent deinstallation
> 
> Theoretically yes, they will be able to remove the patch from
"Programs
> and Features" if they click on "View installed updates", however, if
> you create the patch correctly, removing it will not actually remove
> the patched files. I have a patch process that works in this way. It
> should be noted though, that if you create any further patches that
> rely on the original being installed first, the user will have to be
> aware of the upgrade path.
> 
> -Original Message-
> From: Markus Karg [mailto:k...@quipsy.de]
> Sent: 01 April 2010 10:58
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Prevent deinstallation
> 
> In theorey we could, but:
> 
> Will this solve the problem?
> 
> Will the user be able to see that the module was installed?
> 
> > -Original Message-
> > From: Richard Horsley [mailto:richard.hors...@eicltd.com]
> > Sent: Donnerstag, 1. April 2010 11:42
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Prevent deinstallation
> >
> > Could you create an .msp to patch the original installer to add
these
> > files?
> >
> > -Original Message-
> > From: Markus Karg [mailto:k...@quipsy.de]
> > Sent: 01 April 2010 10:30
> > To: General discussion for Windows Installer XML toolset.
> > Subject: [WiX-users] Prevent deinstallation
> >
> > We have to write a .msi to install modules into a preinstalled
> > software.
> >
> >
> >
> > The problem is that once the module is installed, it can never get
> > uninstalled, as it modifies some software-internal structures in a
> way
> > that makes it impossible to undo.
> >
> >
> >
> > So, we have to prevent that somebody goes into the system control
> > panel,
> > selects the module, and presses "uninstall".
> >
> >
> >
> > Can we do that using WiX?
> >
> >
> >
> >
>
---
> > ---
> > 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
> >
> >  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.
> >
> > #

Re: [WiX-users] Registry on 64bit XP vs Win7

[Pally Sandher]

Build an x64 package to write to x64 areas of the registry. You can't do
it in an x86 package. Nothing to do with WiX, Windows Installer
limitation.

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 **
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: Yu, Brian [mailto:b...@easyscreen.com] 
Sent: 30 April 2010 10:40
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Registry on 64bit XP vs Win7

Hi there

 

I found by testing that in 64 bit XP, the registry path is somehow
different

It should be hklm/SOFTWARE but now becomes hklm/SOFTWARE/wow6432

 

How do I get WIX to selectively install into the right paths depending
on whether it's XP or Win7

 

Brian


_
This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are
incorporated under the laws of England and Wales (company no. 05677531
and VAT registration no. 872810613). Our registered office is at 155
Bishopsgate, London EC2M 3TQ. This e-mail and/or any attached documents
may contain privileged and confidential information and should only be
read by those persons to whom this e-mail is addressed. Use by other
than intended recipients is prohibited. If you are not the addressee,
you must not copy, distribute, disclose or use any of the information in
it. If you have received it in error, please delete it and immediately
notify the sender. EASYSCREEN reserves the right to monitor all e-mail
messages passing through its network. As we cannot guarantee the
genuineness, accuracy or completeness of the information contained in
this message, the statements set forth are not legally binding.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[Blair]

I believe you shouldn't include the quote characters in your PATH statement.

-Original Message-
From: Markus Karg [mailto:k...@quipsy.de] 
Sent: Thursday, April 01, 2010 12:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX 3.5: Error in HEAT

WiX is release 3.0

Your proposal does not work, see here:

C:\>SET PATH=%PATH%;"C:\Programme\Windows Installer XML v3\bin"

C:\>HEAT file EXCEL8.OLB -gg -out EXCEL8.wxs
Microsoft (R) Windows Installer Xml Toolset Harvester version 3.0.5419.0
Copyright (C) Microsoft Corporation. All rights reserved.

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.MutateFi
le(IParentElement parentElement, File file)
   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateEl
ement(IParentElement parentElement, ISchemaElement element)
   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateEl
ement(IParentElement parentElement, ISchemaElement element)
   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateEl
ement(IParentElement parentElement, ISchemaElement element)
   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateEl
ement(IParentElement parentElement, ISchemaElement element)
   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateEl
ement(IParentElement parentElement, ISchemaElement element)
   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.MutateEl
ement(IParentElement parentElement, ISchemaElement element)
   bei
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Mutate(W
ix wix)
   bei Microsoft.Tools.WindowsInstallerXml.Mutator.Mutate(Wix wix)
   bei Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args)

C:\>


> -Original Message-
> From: Mike Carlson (DEV DIV) [mailto:mica...@microsoft.com]
> Sent: Mittwoch, 31. März 2010 23:01
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] WiX 3.5: Error in HEAT
> 
> 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 s 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(Strin
> g
> > fileSource)
> >
> >bei
> >
> Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Mut
> a
> > teFile(IParentElement parentElement, File file)
> >
> >bei
> >
> Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Mut
> a
> > teElement(IParentElement parentElement, ISchemaElement element)
> >
> >bei
> >
> Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Mut
> a
> > teElement(IParentElement parentElement, ISchemaElement element)
> >
> >bei
> >
> Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Mut
> a
> > teElement(IParentElement parentElement, ISchemaElement element)
> >
> >bei
> >
> Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Mut
> a
> > teElement(IParentElement parentElement, ISchemaElement element)
> >
> >bei
> >
> Microsoft.Tools.WindowsInstallerXml.Extensions.UtilHarvesterMutator.Mut

Re: [WiX-users] Registry on 64bit XP vs Win7

[Simon Dahlbacka]

It is the correct path, as long as your executable is running as 32bit
on a 64bit system. Registry redirection is at play
(http://msdn.microsoft.com/en-us/library/aa384232%28VS.85%29.aspx)

On Fri, Apr 30, 2010 at 12:39 PM, Yu, Brian  wrote:
> Hi there
>
>
>
> I found by testing that in 64 bit XP, the registry path is somehow
> different
>
> It should be hklm/SOFTWARE but now becomes hklm/SOFTWARE/wow6432
>
>
>
> How do I get WIX to selectively install into the right paths depending
> on whether it's XP or Win7
>
>
>
> Brian
>
>
> _
> This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are 
> incorporated under the laws of England and Wales (company no. 05677531 and 
> VAT registration no. 872810613). Our registered office is at 155 Bishopsgate, 
> London EC2M 3TQ. This e-mail and/or any attached documents may contain 
> privileged and confidential information and should only be read by those 
> persons to whom this e-mail is addressed. Use by other than intended 
> recipients is prohibited. If you are not the addressee, you must not copy, 
> distribute, disclose or use any of the information in it. If you have 
> received it in error, please delete it and immediately notify the sender. 
> EASYSCREEN reserves the right to monitor all e-mail messages passing through 
> its network. As we cannot guarantee the genuineness, accuracy or completeness 
> of the information contained in this message, the statements set forth are 
> not legally binding.
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] TFS 2010, Network Service and ICE validation

[Will Sullivan]

Well, it is not a bug, technically.  It's a security issue.  The problem is 
that there is no documentation.  I'd think someone in here might know how the 
wix build tasks interact with msiexec and what security issues may be 
involved...

-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] 
Sent: Friday, April 30, 2010 1:36 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] TFS 2010, Network Service and ICE validation

I would suggest opening a bug/support case with the team build guys :)
It doesn't sound like this is a WiX bug...


On Thu, Apr 29, 2010 at 11:59 PM, Will Sullivan  wrote:
> This is going to start hitting big, as people encounter ICE validation 
> failures on a team build.
>
> Apparently, what's going on is that the default account used by 2010 team 
> build, Network Service, is unable to interact with msiexec.exe.
>
> Unfortunately, there is NO decent solution to this available (as far as I can 
> search) on the interwebs.  The only viable solution is to change the build 
> account (one moron suggests adding Network Service to the admins group, ffs).
>
> Can someone who understands the security permissions needed provide an 
> official answer to this problem?
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[Blair]

I'm assuming Program1 and Program2 have different ProductCode values. It
would appear to me that the shared shortcut should be left behind as you
expect given the code you present. RemoveFolder will not remove any
non-empty folders, so that isn't what is deleting the shortcut.

Generate a verbose log during uninstall to see what it does around the
RemoveShortcuts action and in the script. Also look to see what it says
about the SomeSharedThing component's state in that log.

-Original Message-
From: Colin Bradley [mailto:colinbrad...@driveworks.co.uk] 
Sent: Wednesday, March 31, 2010 9:18 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Uninstall removes shared startmenu shortcuts that are
still in use

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 

 



  



 

  



  

  

  





  



 

  



  



 

Program 2 WIX 

 



  



 

  



  

  

  





  



 

  



  



 

I have used:  to remove the shortcuts, I
imagine this is where my changes need to be?

 

Again, any help would be greatly appreciated,

 

Colin.


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


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Registry on 64bit XP vs Win7

[Yu, Brian]

Hi there

 

I found by testing that in 64 bit XP, the registry path is somehow
different

It should be hklm/SOFTWARE but now becomes hklm/SOFTWARE/wow6432

 

How do I get WIX to selectively install into the right paths depending
on whether it's XP or Win7

 

Brian


_
This e-mail was sent to you by EASYSCREEN LIMITED (EASYSCREEN). We are 
incorporated under the laws of England and Wales (company no. 05677531 and VAT 
registration no. 872810613). Our registered office is at 155 Bishopsgate, 
London EC2M 3TQ. This e-mail and/or any attached documents may contain 
privileged and confidential information and should only be read by those 
persons to whom this e-mail is addressed. Use by other than intended recipients 
is prohibited. If you are not the addressee, you must not copy, distribute, 
disclose or use any of the information in it. If you have received it in error, 
please delete it and immediately notify the sender. EASYSCREEN reserves the 
right to monitor all e-mail messages passing through its network. As we cannot 
guarantee the genuineness, accuracy or completeness of the information 
contained in this message, the statements set forth are not legally binding.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[Blair]

Unless the transient flag is set on a component, conditions for that
component are only evaluated upon installation of that component.

I think a little illustration here of what happens during installs,
upgrades, and removals will help you understand.

Initial installation: component with GUID in MSI-1 is selected for
installation based on condition WHATEVER-2.

Repair: File will not be deleted, but may or may not be rewritten, depending
on several factors including the REINSTALLMODE variable and characteristics
of the file itself (is it versioned or not, timestamp and/or hash  or size
mismatches, etc.).

Upgrade (with "early" RemoveExistingProducts): Uninstall transaction is run
using cached/stripped MSI-1, then Install transaction is run using MSI-2.
Thus, the file will be deleted during the removal operation and then
possibly written during the installation operation based on condition
WHATEVER-2.

Upgrade (with "late" RemoveExistingProducts): Install transaction is run
using MSI-2, then Uninstall transaction is run using cached/stripped MSI-1.
As long as the file is from a component with the exact same GUID in both
MSIs the file will not be deleted during the uninstall portion if the
condition WHATEVER-2 requests installation, but the file may or may not be
overwritten (see Repair above).

Removal: File will be deleted, unless the component was marked Permanent.

Using the transient flag allows for removals during repairs, but can't
prevent removals during uninstall operations.

-Original Message-
From: Viv Coco [mailto:vcotirl...@hotmail.com] 
Sent: Wednesday, March 31, 2010 4:09 AM
To: General discussion for Windows Installer XML toolset.
Subject: [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]


NOT UPGRADINGPRODUCTCODE

[/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® 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 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

[Blair]

Do not ever create custom actions and call regsvr32.exe from MSI/WiX. In WiX
2.0, use the SelfRegCost attribute of the File element to cause MSI to
perform the actions of regsvr32.exe on your behalf in a way that works with
repairs, upgrades, patches, as well as installs and uninstalls.

Of course, if you possibly can, avoid self-registration at all costs. Use
the SelfRegCost attribute when you can't avoid it due to problems as you
have described in this thread. And don't use/create custom actions when MSI
already has built-in actions that will perform the activities you are
attempting.

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Wednesday, March 31, 2010 11:31 AM
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

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 
To: General discussion for Windows Installer XML toolset.

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 **
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
wrote:

> 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 IntelR 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 IntelR 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 ExplorerR 8 - Faster, safer, easier.  Optimized for Yahoo!
Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune appl

Re: [WiX-users] Avoid install on removable drives

[Sanjay Rao]

this C++ custom action can check drive type.
use a C++ custom action and display a error message if drive is not valid.

//char AppPath[_MAX_PATH];
char appName[_MAX_PATH];
char appDir[_MAX_PATH];
char appDrive[_MAX_PATH];
_splitpath_s( cPath, appDrive, _MAX_PATH, appDir, _MAX_PATH, 
appName, _MAX_PATH, NULL, 0 );

UINT drivetype = GetDriveType(appDrive);
if(drivetype == DRIVE_FIXED)
{
MsiSetProperty (hInstall, "DRIVEALLOWED", "1");
}
else
{
MsiSetProperty (hInstall, "DRIVEALLOWED", "0");
}


Andy.Kruger wrote:
> Anybody???
>
> -
> Andy
> MSI Developer
> Schneider Electric
>   




--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] eser bolat

[sujanakar reddy]

http://www.freidesignberlin.de/home.php
  
_
South Cinema This Decade
http://entertainment.in.msn.com/southcinemathisdecade/
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Avoid install on removable drives

[Andy.Kruger]

Anybody???

-
Andy
MSI Developer
Schneider Electric
-- 
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Avoid-install-on-removable-drives-tp711163p4984485.html
Sent from the wix-users mailing list archive at Nabble.com.

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users