from:"Blair"

in the v3.8 wix sources: src/ext/ca/inc/caSuffix.wxi (same directory as 
caSuffix.h)


That file is setup according to the way that the wix toolset itself is built, 
which doesn’t always translate into how most project using votive are expected 
to be built, so your version may vary.


However, from that file you can see that Suffix is an empty string for x86 
platforms, is “_x64” for x64 platforms, is “_ia64” for ia64 platforms, and is 
“_ARM” for arm platforms. ia64 was removed in v3.8. I don’t recall which 
version arm was added in.





Blair





From: Martin Clarke
Sent: ‎Saturday‎, ‎January‎ ‎25‎, ‎2014 ‎4‎:‎12‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Hi Phil,

Looks like a candidate - How would that caSuffix.h translate to a wxi file?
I've just pasted the contents into a file called caSuffix.wxi - I don't
think thats what I'm meant to have done.

I'm now getting an error: Undefined preprocessor variable '$(var.Suffix)'
in the Common_Platform.wxi file.

Include xmlns=http://schemas.microsoft.com/wix/2006/wi;

  ?include caSuffix.wxi ?

  Fragment

!-- print EULA functionality --

CustomAction Id=WixUIPrintEula$(var.Suffix) BinaryKey=
WixUIWixca$(var.Suffix) DllEntry=PrintEula Return=ignore Execute=
immediate /
  /Fragment
...
...


This suggests I need to figure out the value that is used for var.Suffix.
Does anyone know what I should be using?

Thanks in advance,
Martin




On 24 January 2014 16:38, Phill Hogland phogl...@rimage.com wrote:

 Is this what you are looking for?
 #if defined _WIN64
 #define PLATFORM_DECORATION(f) f ## L_64
 #elif defined ARM
 #define PLATFORM_DECORATION(f) f ## L_ARM
 #else
 #define PLATFORM_DECORATION(f) f
 #endif

 from src\ext\ca\inc\caSuffix.h



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/caSuffix-wxi-and-PrinEULA-tp7592038p7592045.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Strange permissions failure for EFI handling

Also all deferred actions that impersonate are different between UAC prompt and 
starting from an elevated prompt (in a similar fashion). Deferred actions that 
do not impersonate are identical in both scenarios.






Blair





From: Phil Wilson
Sent: ‎Saturday‎, ‎January‎ ‎25‎, ‎2014 ‎10‎:‎52‎ ‎AM
To: General discussion for Windows Installer XML toolset.





It would help if you gave some detail about the actual failure - MSI
installation fails isn't very informative. A verbose log might help
you too.

Running an MSI from an elevated prompt is not the same as UAC asking
for elevation. When run from an elevated prompt the UI and execute
sequences both run elevated. However the UAC prompt occurs at the
start of the execute sequence - the UI sequence won't be elevated, so
CAs there that require privilege will fail, and whether that is
reported depends on error reporting in the CA code.  As the saying
goes, there are three main reasons why installs fail: custom actions,
custom actions, and custom actions.
Phil Wilson


On Fri, Jan 24, 2014 at 2:52 PM, Mustafa Jamil
mustafa_ja...@hotmail.com wrote:
 Hello.
 I have a WiX MSI that installs a bootloader.  On EFI systems, it does so in 
 the EFI system partition.  On BIOS systems, it chainloads the new boot option 
 to the Windows Boot Manager (and so running bcdedit shows the new option).
 When I run my MSI on a BIOS system, everything works as expected. If I run 
 cmd as administrator and then install the MSI via msiexec, things work. If I 
 instead run cmd normally, or just double-click on the MSI, I'll get a UAC 
 prompt, and then things work as expected.
 For EFI, the story is different. On an EFI-installed system, if I run cmd as 
 administrator and then install the MSI via msiexec, things work.  But if I go 
 the UAC prompt route, my MSI installation fails.
 This is confusing. I thought there is no difference between running a command 
 explicitly as administrator, and running a command by accepting the UAC 
 prompt, but this clearly shows there is in fact a difference.
 Any ideas why I'm running into this behaviour?  Any ideas how I can fix this, 
 or at least debug it further?
 P.S. I use the Get/SetEnvironmentVariable API calls from my code to tweak the 
 EFI partition.  This requires the SeSystemEnvironmentPrivilege, which I do 
 set, so that's not the issue, AFAIK.
 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Making a symbolic link in an installer

I’ve done it from a deferred DLL CA using the CreateSymbolicLink() API before.






Blair





From: Scott Palmer
Sent: ‎Saturday‎, ‎January‎ ‎25‎, ‎2014 ‎5‎:‎32‎ ‎PM
To: General discussion for Windows Installer XML toolset.





runas seems to be useless for installer purposes.
For one:  I can't have a console window pop up where a user is forced to
enter their password.
Second: It may run as a particular user, but not with *all* of their
privileges, i.e. not as an Administrator.


I'll make it an open challenge.. I've spent a couple days trying.  If
anyone could confirm one way or the other, if it is possible or impossible
to create a symbolic link from an installer with nothing more than the
usually UAC prompt appearing.

Note that if you run msiexec as an administrator (from a Run as
Administrator command prompt), then everything works.  Obviously that
totally ruins the user experience and goes against the whole point of UAC.
 What is so scary about symbolic links that this is a privileged operation
anyway??!  It's particularly mysterious since once the symbolic link is
created your don't need any special privileges to delete it!


Regards,

Scott



On Fri, Jan 24, 2014 at 10:41 PM, Jeremiahf jeremi...@gmail.com wrote:

 Interesting... does it not work with removing the quotes from
 [$(var.linkDest)]' ? btw... I copied your line and there is an extra '
 after [$(var.linkDest)]. I pasted it in notepad and saw it more clear.

 Check this out.

 http://www.windows7home.net/how-to-create-symbolic-link-in-windows-7/

 use runas if you need to really need to rock the cmd.exe

 C:\runas /user:localmachinename\administrator cmd.exe /c mklink /D
 some_link_name  some_directory_path


 C:\runas /user:DomainName\AdministratorAccountName cmd

 ref from: C:\runas /user:DomainName\AdministratorAccountName cmd

 cheers



 On Fri, Jan 24, 2014 at 4:12 PM, Scott Palmer swpal...@gmail.com wrote:

  Can someone show me code that can successfully do it?
 
  I tried:
 
  CustomAction Id='Mklink' Directory=myDir
ExeCommand='[SystemFolder]cmd.exe /K mklink /D
 mylink
  [$(var.linkDest)]' Execute=deferred Impersonate=no /
 
  InstallExecuteSequence
  Custom Action=Mklink
  Before=InstallFinalize$needALinkForThisComp=3/Custom !-- runs at
  install of that Compoent Id --
 
  /InstallExecuteSequence
 
  I'm running on Windows 7
 
  The cmd window that pops up (titled: Administrator:
  C:\Windows\SysWOW64\cmd.exe) indicates that the System user doesn't have
  permission to make a symbolic link (thanks Microsoft!):
  You do not have sufficient privilege to perform this operation.
 
 
  Thanks,
 
  Scott
 
 
 --
  CenturyLink Cloud: The Leader in Enterprise Cloud Services.
  Learn Why More Businesses Are Choosing CenturyLink Cloud For
  Critical Workloads, Development Environments  Everything In Between.
  Get a Quote or Start a Free Trial Today.
 
 
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 



 --
 They may forget what you said but they will never forget how you made them
 feel. -- Anonymous

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https

Re: [WiX-users] Create a new custom step for a WixUI_Advanced installer

http://wixtoolset.org/documentation/manual/v3/wixui/wixui_customizations.html : 
Section “Inserting a custom dialog into a built-in dialog set”






Blair





From: Gustavo Martins
Sent: ‎Monday‎, ‎January‎ ‎27‎, ‎2014 ‎6‎:‎38‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Hi,


I’m evaluating Wix and I hope someone can give me some clarification on a 
question I have.

I have an installer configured using  WixUI_Advanced but I want to extend it by 
adding a new step to the middle of the setup process.


The idea is to have a new screen with two buttons, one of them invoking some 
custom C# code and the other for moving to the next workflow process.


Is this possible to implement? I read about custom actions, I also saw we can 
build our own setup screens, but I’m not sure if I can do this and hook it up 
to the WixUI_Advanced setup template.


Any ideas?


Thank you in advance,

Gustavo






Sent from Windows Mail
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Confused... when installing a 32/64 bit MSI using 1 product.wxs file [P]

In your conditions you probably want to use VersionNT64, not anything from the 
preprocessor.


The ?if…? is used to include/exclude WiX source code from your MSI/Bundle 
entirely.






Blair





From: StevenOgilvie
Sent: ‎Monday‎, ‎January‎ ‎27‎, ‎2014 ‎7‎:‎27‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Blair/Rob

is this statement correct:

So are you saying I should use: 
?if $(sys.BUILDARCH) = x64 ? and NOT ?if $(var.Platform) = x64 ? 

What about my wixlib where I have 2 files that have a 32 bit version and a
64 bit version what is the proper way to say 
32 bit file install on a 32 bit OS and 64 bit file install on a 64 bit OS
AND 32 bit file can be installed on 64 bit OS since the x86 MSI can be
installed on 64bit OS? 

Component Id=quot;cmp_Dllquot; Guid=quot;{lt;Some GUID}  
File Id=file_Dll KeyPath=yes
Source=$(var.SourcePath)\lib\x86\SomeFile.dll / 
Condition 
   ! [ CDATA [$(sys.BUILDARCH) = x64 AND $(sys.BUILDARCH) =
x86] ]  
  /Condition 
/Component 
  Component Id=quot;cmp_DLLl_x64quot; Guid=quot;{lt;Some
GUID} Win64=$(var.Win) 
File Id=file_Dll_x64 KeyPath=yes
Source=$(var.SourcePath)\lib\x64\SomeFile.dll / 
Condition 
   ! [CDATA [$(sys.BUILDARCH) = x64] ]  
  /Condition 
/Component 

Thanks 

Steve 



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Re-Confused-when-installing-a-32-64-bit-MSI-using-1-product-wxs-file-P-tp7591967p7592109.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and Bootstrapper

If your MSI package is always per-user, why wouldn’t you just retrieve and use 
the path of FOLDERID_UserProgramFiles instead of ProgramFilesFolder?






Blair





From: Sascha Sertel
Sent: ‎Monday‎, ‎January‎ ‎27‎, ‎2014 ‎10‎:‎58‎ ‎AM
To: General discussion for Windows Installer XML toolset.





With MSIINSTALLPERUSER=1 on Windows 7 and above the ProgramFilesFolder
location gets automatically rerouted to LocalAppDataFolder if running a
per-User install.

This MSDN article shows where all the folder locations point to in
per-machine vs. per-user installs:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd765197(v=vs.85).aspx

// Sascha



On Mon, Jan 27, 2014 at 8:46 AM, Rob Mensching r...@robmensching.com wrote:

 No. That's a per-machine location.

 -Original Message-
 From: Wesley Manning [mailto:wmann...@dynagen.ca]
 Sent: Monday, January 27, 2014 7:54 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
 Bootstrapper

 So per users can installer to C:\Program Files\ ?

 -Original Message-
 From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
 Sent: January-24-14 6:45 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
 Bootstrapper

 No I did not set ALLUSERS directly.


 On Fri, Jan 24, 2014 at 2:32 PM, Rob Mensching r...@robmensching.com
 wrote:

  Did you have ALLUSERS set the whole time as well?
 
  -Original Message-
  From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
  Sent: Friday, January 24, 2014 2:21 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
  Bootstrapper
 
  I always had Package/@InstallScope='perUser', that never changed.
 
  But the key thing for me to get it to work was MSIINSTALLPERUSER=1,
  without it I kept getting the insufficient privileges error both in
  the bundle and when running the stand-alone MSI.
 
  // Sascha
 
 
 
  On Fri, Jan 24, 2014 at 1:34 PM, Rob Mensching r...@robmensching.com
  wrote:
 
   Burn does lots of work to make this scenario work (per-machine
   prerequisites and one or more per-user packages). It's unique among
   bootstrappers because it does it in all the right user contexts and
   all that. I saw a follow up email from you on a fork of this thread
   that found the most important thing: You need to make sure your
   per-user package is truly per-user.  The easiest way to do that is
   to
  use:
   Package/@InstallScope='perUser'.
  
   -Original Message-
   From: Sascha Sertel [mailto:sascha.ser...@gmail.com]
   Sent: Friday, January 24, 2014 12:18 PM
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] dual-purpose installer (ALLUSERS=2) and
   Bootstrapper
  
   Let me clarify a bit to tell you what I'm trying to do, what I've
   tried, and what I thought isn't currently working:
  
   Goal: Build a WiX installer for my software which installs .NET
   Framework
   4.5.1 if needed, C++ Runtime if needed, and my software. My software
   needs to be installed per-user, i.e. it should go into
   AppData\Local, not Program Files.
  
   My understanding is
   - To accomplish my goal I need three components: .NET Framework
   4.5.1 package (provided by NetFx extension), C++ Runtime merge
   module, and MSI for my software
   - The two prerequisites needs to be installed on a per-machine
   (elevated) level, my software on a per-user level
  
   This is what I've tried:
   Attempt 1. Created a WiX bundle with two packages inside the Chain
  element:
   A PackageGroupRef for NetFx451Web, and an MsiPackage that includes
   my software as well as the C++ merge module.
   Problem: This wouldn't build because my software Package had
   InstallScope perUser but apparently the C++ merge module forced
   ALLUSERS=1 which conflicted with the perUser setting. This problem
   went away when I took the merge module out of the package.
  
   Attempt 2: Created a WiX bundle with three packages inside the Chain
   element: A PackageGroupRef for NetFx451Web, an MsiPackage for my C++
   Runtime merge module (InstallScope perMachine), and an MsiPackage
   for my software (InstallScope perUser).
   Problem: When running the resulting bundle it would prompt for
   elevation (which is fine), then install .NET Framework fine, then
   install the merge module fine, but throw an error for my perUser
   package: The installer has insufficient privileges to access this
   directory: C:\Program Files\product. The installation cannot
   continue. Log on as administrator or contact your system
 administrator.
  
   My software package uses a folder underneath ProgramFilesFolder as
   the target folder and I was expecting that on Win7 and up in a
   per-user install it automatically translates to LocalAppDataFolder
 instead.
  
   I thought from what I had gathered in this thread is that once the
   bundle gets

Re: [WiX-users] finding out what features are being installed

ADDLOCAL doesn’t have to be set. When costing is done in the UI sequence, the 
result of that costing will be placed into the family of properties that 
includes ADDLOCAL in order to communicate to the execute sequence which 
features are to be changed and how (which causes things like feature 
conditions, installlevel, and parent/child relationships between features to be 
ignored in the execute sequence’s costing). If none of those properties are set 
when the execute sequence starts costing, then those other means of determining 
what to do for each feature are used (as they would have been in the UI 
sequence).




If you want to know what the action and status of each feature are there are 
both APIs and a conditional syntax that will give them to you without having to 
depend on properties like ADDLOCAL. Look at pages like 
http://msdn.microsoft.com/library/aa368012.aspx (Access Prefixes section) when 
using the Condition type in the database (such as in the sequence tables) or 
when using the MsiEvaluateCondition() function in a CA, or more directly by 
using the MsiGetFeatureState() function in a CA.


Blair





From: Marek Mielcarek
Sent: ‎Monday‎, ‎January‎ ‎27‎, ‎2014 ‎3‎:‎06‎ ‎PM
To: General discussion for Windows Installer XML toolset.





To learn what features are being installed I try to examine ADDLOCAL which is a 
standard parameter that can be passed to MSI. I use the following line in my 
WiX xml to do that:
SetProperty Id=FEATURELIST Value=[ADDLOCAL] After=CostFinalize/

Then, inside InstallExecuteSequence element I am scheduling custom action which 
uses my local FEATURELIST property.

When I launch the installation with UI (although I have no dialogs), the 
FEATURELIST holds names of all features separated by comma. When I launch 
silent installation (i.e. use /qn switch) the value of FEATURELIST is blank.  
In both cases I do not specify ADDLOCAL, which instructs MSI to install all 
available features.

Why these 2 cases yield different values? I'd always expect the same behavior 
regardless of /qn switch. If that is not the right way, can somebody please 
suggest a reliable way of checking what features are being installed ?
Thank you

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Install busy executables at reboot - Windows 7

Are you doing a major upgrade or a recache/repair?

Are the files it was killing off in the same feature as other files that were 
changed? Remember that features are installed/repaired/removed as a unit.


Your verbose install logs should be telling you why it wanted to “replace” 
files that “didn’t change”. What do your logs have to say?






Blair





From: Walter Dexter
Sent: ‎Monday‎, ‎January‎ ‎27‎, ‎2014 ‎9‎:‎53‎ ‎PM
To: General discussion for Windows Installer XML toolset.





I believe that is only true for versioned files, although I may be mistaken.

In this particular case (properly versioned .Net 3.5 executables) they were
unchanged and should not have been replaced according to my, and your,
understanding of the rules. Despite that, Windows Installer was killing
them off. Perhaps it just shoots first and asks questions later unless told
to not terminate. I have no idea.


On Mon, Jan 27, 2014 at 7:17 PM, Nicolás Alvarez
nicolas.alva...@gmail.comwrote:

 2014-01-27 Walter Dexter wfdex...@gmail.com:
  Got it!
 
  I haven't worked out all the details but changing the MSIRMSHUTDOWN
  property to 0 makes it do what I wanted. Note that in this case the
 .exe
  files that I want to keep running aren't actually being modified. Our
  deployment folks just don't like to deal with distribution of patches;
  they'd rather send out a full MSI.

 Windows Installer only overwrites files that have changed; patch or no
 patch is irrelevant.

 --
 Nicolás


 --
 WatchGuard Dimension instantly turns raw network data into actionable
 security intelligence. It gives you real-time visual feedback on key
 security issues and trends.  Skip the complicated setup - simply import
 a virtual appliance and go from zero to informed in seconds.

 http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Install busy executables at reboot - Windows 7

Post a URL and we will interpret/educate on the interpretation thereof


Walter Dexter wfdex...@gmail.com wrote:

So far as the logs, I have yet to ever find anything I can make sense of in
an MSI log. I'm well aware that's my own deficiency but those things are
99.95% unintelligible to me.


On Tue, Jan 28, 2014 at 2:46 PM, Walter Dexter wfdex...@gmail.com wrote:

 In my case the installer is always run as quiet and there's no
 interactions with any user. Our goal is to slip in and deliver stuff
 without their noticing.

 I naively put everything in a single feature. it sounds like I would be
 better served to sort the files into features based on actual dependencies,
 so one feature might be a single .exe and any files it requires to run.


 On Tue, Jan 28, 2014 at 12:19 PM, Phil Wilson phildgwil...@gmail.comwrote:

  You could move files (strictly components) around, but in most
 installs the features are units of functionality and not random
 collections of assorted files. A feature is the user's unit of
 functionality that can be added or removed, and moving files out of
 one often requires other changes such as help and docs that say
 installing feature X gives you this functionality because it no
 longer does.

 As Blair says, look at the verbose log. In the absence of hard
 evidence that says what's really happening it seems premature to
 change feature content.
 ---
 Phil Wilson


 On Tue, Jan 28, 2014 at 5:44 AM, Walt Dexter wfdex...@gmail.com wrote:
  And there's the answer. They're all in the same feature.
 
  Can I move existing files between features in an upgrade? That would
 position me better the next time around.
 
 
 
 
 
  On Jan 28, 2014, at 4:36 AM, Blair Murri os...@live.com wrote:
 
  Are you doing a major upgrade or a recache/repair?
 
  Are the files it was killing off in the same feature as other files
 that were changed? Remember that features are installed/repaired/removed as
 a unit.
 
 
  Your verbose install logs should be telling you why it wanted to
 replace files that didn't change. What do your logs have to say?
 
 
 
 
 
 
  Blair
 
 
 
 
 
  From: Walter Dexter
  Sent: Monday, January 27, 2014 9:53 PM
  To: General discussion for Windows Installer XML toolset.
 
 
 
 
 
  I believe that is only true for versioned files, although I may be
 mistaken.
 
  In this particular case (properly versioned .Net 3.5 executables) they
 were
  unchanged and should not have been replaced according to my, and your,
  understanding of the rules. Despite that, Windows Installer was killing
  them off. Perhaps it just shoots first and asks questions later unless
 told
  to not terminate. I have no idea.
 
 
  On Mon, Jan 27, 2014 at 7:17 PM, Nicolás Alvarez
  nicolas.alva...@gmail.comwrote:
 
  2014-01-27 Walter Dexter wfdex...@gmail.com:
  Got it!
 
  I haven't worked out all the details but changing the MSIRMSHUTDOWN
  property to 0 makes it do what I wanted. Note that in this case the
  .exe
  files that I want to keep running aren't actually being modified. Our
  deployment folks just don't like to deal with distribution of
 patches;
  they'd rather send out a full MSI.
 
  Windows Installer only overwrites files that have changed; patch or no
  patch is irrelevant.
 
  --
  Nicolás
 
 
 
 --
  WatchGuard Dimension instantly turns raw network data into actionable
  security intelligence. It gives you real-time visual feedback on key
  security issues and trends.  Skip the complicated setup - simply
 import
  a virtual appliance and go from zero to informed in seconds.
 
 
 http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 --
  WatchGuard Dimension instantly turns raw network data into actionable
  security intelligence. It gives you real-time visual feedback on key
  security issues and trends.  Skip the complicated setup - simply import
  a virtual appliance and go from zero to informed in seconds.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
  WatchGuard Dimension instantly turns raw network data into actionable
  security intelligence. It gives you real-time visual feedback on key
  security issues and trends.  Skip the complicated setup - simply import
  a virtual appliance and go from zero to informed in seconds.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
  ___
  WiX

Re: [WiX-users] Making a symbolic link in an installer

Per machine installation with windows installer initiated UAC prompt accepted 
(so the action was running as SYSTEM). I'll ask how much I can share.


Scott Palmer swpal...@gmail.com wrote:

Without running msiexec as an Administrator?  If you have any code you can
share I would appreciate it.

Thanks,

Scott


On Tue, Jan 28, 2014 at 3:39 AM, Blair Murri os...@live.com wrote:

 I’ve done it from a deferred DLL CA using the CreateSymbolicLink() API
 before.


 Blair


 From: Scott Palmer
 Sent: ‎Saturday‎, ‎January‎ ‎25‎, ‎2014 ‎5‎:‎32‎ ‎PM
 To: General discussion for Windows Installer XML toolset.

 runas seems to be useless for installer purposes.
 For one:  I can't have a console window pop up where a user is forced to
 enter their password.
 Second: It may run as a particular user, but not with *all* of their
 privileges, i.e. not as an Administrator.

 I'll make it an open challenge.. I've spent a couple days trying.  If
 anyone could confirm one way or the other, if it is possible or impossible
 to create a symbolic link from an installer with nothing more than the
 usually UAC prompt appearing.

 Note that if you run msiexec as an administrator (from a Run as
 Administrator command prompt), then everything works.  Obviously that
 totally ruins the user experience and goes against the whole point of UAC.
  What is so scary about symbolic links that this is a privileged operation
 anyway??!  It's particularly mysterious since once the symbolic link is
 created your don't need any special privileges to delete it!


 Regards,

 Scott



 On Fri, Jan 24, 2014 at 10:41 PM, Jeremiahf jeremi...@gmail.com wrote:

  Interesting... does it not work with removing the quotes from
  [$(var.linkDest)]' ? btw... I copied your line and there is an extra '
  after [$(var.linkDest)]. I pasted it in notepad and saw it more clear.
 
  Check this out.
 
  http://www.windows7home.net/how-to-create-symbolic-link-in-windows-7/
 
  use runas if you need to really need to rock the cmd.exe
 
  C:\runas /user:localmachinename\administrator cmd.exe /c mklink /D
  some_link_name  some_directory_path
 
 
  C:\runas /user:DomainName\AdministratorAccountName cmd
 
  ref from: C:\runas /user:DomainName\AdministratorAccountName cmd
 
  cheers
 
 
 
  On Fri, Jan 24, 2014 at 4:12 PM, Scott Palmer swpal...@gmail.com
 wrote:
 
   Can someone show me code that can successfully do it?
  
   I tried:
  
   CustomAction Id='Mklink' Directory=myDir
 ExeCommand='[SystemFolder]cmd.exe /K mklink /D
  mylink
   [$(var.linkDest)]' Execute=deferred Impersonate=no /
  
   InstallExecuteSequence
   Custom Action=Mklink
   Before=InstallFinalize$needALinkForThisComp=3/Custom !-- runs at
   install of that Compoent Id --
  
   /InstallExecuteSequence
  
   I'm running on Windows 7
  
   The cmd window that pops up (titled: Administrator:
   C:\Windows\SysWOW64\cmd.exe) indicates that the System user doesn't
 have
   permission to make a symbolic link (thanks Microsoft!):
   You do not have sufficient privilege to perform this operation.
  
  
   Thanks,
  
   Scott

--
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] VB6 OCX And Harvest

Personally I think it should have been implemented that way but it wasn’t.






Blair





From: Graham Allwood
Sent: ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎10‎:‎34‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Thanks Blair.

That did the trick.

I was trying to use AdditionalOptions element in the HarvestFile 
command/element but this didn't work.

Graham

-Original Message-
From: Blair Murri [mailto:os...@live.com] 
Sent: 24 January 2014 06:04
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] VB6 OCX And Harvest

Add HarvestFileAdditionalOptions-svb6/HarvestFileAdditionalOptions to the 
first PropertyGroup in your WIXPROJ.






Blair





From: Graham Allwood
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎11‎:‎45‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Hi,

I have three VB6 components in a VB6 project I want to install and register. 
Two are ocx's and one is a dll. I see in the SDK Docs there is a -svb6 option 
for Harvest which I think I need to use. Is this right?

I am actually using MSBUILD and the Harvestfile element. There doesn't seem to 
be a property for the above option.

Does anyone know how to use HarvestFile with a VB6 COM dll?

Thanks for your help

Graham Allwood
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setup.exe cygwin question

Certainly it is possible using a custom BA from a bundle. Somewhat less so from 
an MSI. One big advantage of the bundle, however, is that the entire set of 
packages can be divided up between some arbitrary set of MSIs abstracted away 
from the end user (in fact, the most logical would be to have each package be 
an MSI). In fact, you might even be able to reuse your current UI in a custom 
bundle and save much of the redevelopment effort.


Not sure on the project leader part. What resources are available to such a 
leader (types and experience of developers/testers/PMs, etc.)?






Blair





From: BGINFO4X
Sent: ‎Friday‎, ‎January‎ ‎24‎, ‎2014 ‎7‎:‎25‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Dear Sirs.

Attending your experience, do you think that is possible to build an
installer like the traditional setup.exe installer from cygwin.com?

In the following url you can see the main screens.
http://x.cygwin.com/docs/ug/setup-cygwin-x-installing.html

I ask basically for the screens number 11, 13, 15, 16.  Do you think
that this is possible with WIX?

Does anyone would like to be the project leader of  such project?
cygwin community should agree with this.

I must admit that I can't build such project, I don't have the
necessary experience and knowledge.

Any recommendation is welcome.

Thanks for your time and regards.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] searching for a registry key without worrying about any values

You always control the registry key? Do it like the property remember pattern.






Blair





From: Sean Farrow
Sent: ‎Friday‎, ‎January‎ ‎24‎, ‎2014 ‎8‎:‎23‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Hi all,

I'm in the process of refactoring an installer I wrote a while ago.
I've got a situation where I need to check that a registry key exists (I'm not 
worried about any of the values). What is the best way of doing this and 
assigning it to a property? I thought about setting the property to an initial 
value say test, and as the default value is an empty string I could check to 
see whether the string is empty and hence the property has been set. Or, Will 
the Util extension help here? How can I set a variable value to a property?
I'm currently using a custom action to do this using RegOpenKey internally.
Any help appreciated.
Cheers
Sean.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Enabling platform features during install

from: http://msdn.microsoft.com/library/windows/desktop/hh825838.aspx


“You can develop applications by using the DISM API on any computer where you 
have installed the Windows® Assessment and Deployment Kit (Windows ADK).”



So, I interpret that as saying that you can’t statically link the DISM API and 
use it during an installation (unless you effectively make the ADK a 
prerequisite). That nixes it for my use cases.




Blair





From: Phill Hogland
Sent: ‎Friday‎, ‎January‎ ‎24‎, ‎2014 ‎8‎:‎49‎ ‎AM
To: General discussion for Windows Installer XML toolset.





I do not have the ADK or the path either.  And the API docs talk about
creating a 'application' which will modify /online images.  Here is a
sample:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh824804.aspx

I am preparing a CA to test pieces of this code relating to the query of a
feature status, as a test of the concept.  I am not quite ready to try and
compile it without or with the ADK, but I hope to have a better idea later
today after I work on some other issues. 



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Enabling-platform-features-during-install-tp7591862p7592047.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error Building WixProj from DevEnv Command Line [P]

If you are using VS11 you should be able to use MSBuild on the SLN files 
instead of devenv.exe (I haven’t noticed any non-MSBuild project types left in 
VS 2012, but maybe there are some).


You could probably replace those two calls with something like:


call C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild 
.\Services_Setup\Services_Setup.sln /t:Clean /p:Configuration=Debug 
/p:Platform=x86

call C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild 
.\Services_Setup\Services_Setup.sln /t:Build /p:Configuration=Debug 
/p:Platform=x86 /flp:LogFile=.\Build_Setup.log



Adjust as needed





-Blair





From: Steven Ogilvie
Sent: ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎5‎:‎29‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Classification: Public
We use TFS as our source repository so I get the setup source first then build 

set DevEnv=%DevEnvDir%devenv.exe
echo DevEnv=%DevEnv%
set MSBuild=msbuild.exe
echo MSBuild=%MSBuild%
set TF=%DevEnvDir%TF.exe
echo TF=%TF%

if $%DevEnv%$==$$ echo DevEnv not set
if $%DevEnv%$==$$ pause
if $%TF%$==$$ echo TF not set
if $%TF%$==$$ pause
if $%TF%$==$$ goto SKIPSOURCE

%TF% get $/Main/Setup /recursive /force /noprompt if ERRORLEVEL 1 echo error 
Getting $/Setup :SKIPSOURCE

call C:\Program Files (x86)\Microsoft Visual Studio 
11.0\Common7\IDE\devenv.exe .\Services_Setup\Services_Setup.sln /Clean

call C:\Program Files (x86)\Microsoft Visual Studio 
11.0\Common7\IDE\devenv.exe .\Services_Setup\Services_Setup.sln /BUILD 
DebugX86 /OUT .\Build_Setup.log

Steve

-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: January-20-14 10:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Error Building WixProj from DevEnv Command Line

dunno. I always use msbuild from the command line:


“FullPathToMSBuild.exe” /nologo /t:Rebuild “FullPathToSolutionFile”




DevEnv has always been a black box and has never been particularly build-box 
friendly.


You’ll have to use DevEnv on solutions containing projects that aren’t 
compatible with MSBuild, but there are fewer of those project types remaining 
with each new release of VS.




Blair





From: Dave Echols
Sent: ‎Wednesday‎, ‎January‎ ‎15‎, ‎2014 ‎10‎:‎47‎ ‎AM
To: General discussion for Windows Installer XML toolset.





I have a VS 2010 solution that contains 2 Wix projects for two different 
installs. I can compile/build the solution from within the Visual Studio IDE 
without errors. When I build the solution from the command line using 
DevEnv.exe, I get the following error on one of the projects...

MySetup.wixproj : error  : Catastrophic failure (Exception from HRESULT: 
0x8000 (E_UNEXPECTED))

One or more projects in the solution were not loaded correctly.
Please see the Output Window for details.

I am using the following command line to build the solution...

FullPathToDevEnv.exe /nologo /rebuild FullPathToSolutionFile

The other project in the solution builds without errors. I have examined each 
project file in a text editor and they are nearly identical, except for 
different files and different names/Guids. Any ideas on what might be causing 
this error and how I can make it go away?

Thanks in advance for any help.



David S. Echols
Senior Programmer

HA Architects  Engineers | www.ha-inc.comhttp://www.ha-inc.com
222 Central Park Ave., Suite 1200, Virginia Beach, Virginia 23462
d: (757) 213-6049 p: (757) 222-2010 f: (757) 222-2022

Follow Us: Twitterhttp://twitter.com/#!/hainctweets | 
Facebookhttp://www.facebook.com/HAArchitectsEngineers | 
LinkedInhttp://www.linkedin.com/company/ha-architects--engineers
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 



 
This message has been marked as Public by Steven Ogilvie on January-21-14 
8:16:55 AM.

The above classification labels were added to the message by TITUS Message 
Classification. For more information visit www.titus.com

Re: [WiX-users] Install fails on Win 7 w/UAC enabled

InstallPrivileges will work, but is deprecated (or at least should have been). 
InstallScope is preferred. There is no need to do both.






Blair





From: roberthyang
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎4‎:‎26‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Also look into Package/InstallScope, which might be more appropriate.


Gerry Reno wrote
 It looks like adding this to Package may do the trick:
 
 |InstallPrivileges=elevated|
 
 I'll try it and see.
 
 
 On 01/21/2014 08:21 PM, Gerry Reno wrote:
 I have a WIX installer built that installs fine on XP machines.

 When I go to install on Win 7 machines that have UAC enabled the install
 gets a Premature Failure and rolls back.

 How do I get the installer to install on these Win 7 machines without
 disabling UAC?





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Install-fails-on-Win-7-w-UAC-enabled-tp7591942p7591970.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Confused... when installing a 32/64 bit MSI using 1 product.wxs file

sys.BUILDARCH uses the value set via the MSBuild Platform property (x86 for 
32-bit intel, etc.) automatically with recent releases of WiX. And most of the 
time you don’t need to set the Win64 attribute because the same input (the 
-arch argument to candle) that sets the BUILDARCH value from the MSBuild 
property automatically sets the Win64 default to an appropriate value. (the 
released chm docs give the wrong source for this automatic setting).


If you use the var.Platform value you are at the mercy of it being set to 
something you don't expect.






Blair





From: StevenOgilvie
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎11‎:‎42‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Hello,

I use 1 product.wxs file at build time, the project file has different
configurations for X86 and X64 which allows me build 2 MSI's one for 32 bit
and one for 64 bit.

I have used these conditions but which one is correct?

?if $(sys.BUILDARCH) = x64 ?
  ?define Win=yes ?
  ?define PlatformProductName = $(var.ProductName) (64 bit) ?
  ?define PlatformProgramFilesFolder = ProgramFiles64Folder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec64?
  ?define PlatformQtExecCmdLine = QtExec64CmdLine?
  ?else ?
  ?define Win=no ?
  ?define PlatformProductName = $(var.ProductName) ?
  ?define PlatformProgramFilesFolder = ProgramFilesFolder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec?
  ?define PlatformQtExecCmdLine = QtExecCmdLine?
  ?endif ?

OR

?if $(var.Platform) = x64 ?
  ?define Win=yes ?
  ?define PlatformProductName = $(var.ProductName) (64 bit) ?
  ?define PlatformProgramFilesFolder = ProgramFiles64Folder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec64?
  ?define PlatformQtExecCmdLine = QtExec64CmdLine?
  ?else ?
  ?define Win=no ?
  ?define PlatformProductName = $(var.ProductName) ?
  ?define PlatformProgramFilesFolder = ProgramFilesFolder ?
  ?define PlatformCAQuietExecDLLEntry = CAQuietExec?
  ?define PlatformQtExecCmdLine = QtExecCmdLine?
  ?endif ?

As well some installs have 2 files, 1 for 32 bit and 1 for 64 bit and of
course I want the right one to be installed depending on the bitness of the
OS

i.e.:

32 bit file
Condition/Condition

64 bit file
Condition/Condition

thanks,

Steve



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Confused-when-installing-a-32-64-bit-MSI-using-1-product-wxs-file-tp7591962.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Windows Service Deployment - Installation Fails on Server 2003 but works elsewhere

Windows Installer a long time ago swallowed the actual error code and 
determined that this error message was the most likely cause of any failure to 
install/start a service. With time that’s been proven wrong, but as Raymond 
Chen would tell you about maintaining backward compatibility…


What you should always do when you see that message pop up is (with the box 
still up) open an elevated command prompt and do a “net start servicename” 
and see what error that returns. If it returns a time out check to see if its 
possible that the service executable had popped up a dialog/message box 
(possibly in the service desktop on vista/2008 and newer). One of those two 
will usually tell you what went wrong.






Blair





From: Palmer, Joel
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎7‎:‎14‎ ‎PM
To: General discussion for Windows Installer XML toolset.





* I use WiX 3.8 to create an installer for my Windows Service.  When it 
is run on my Server 2003 test box, I get this very unhelpful and generic 
message:
Verify that you have sufficient privileges to install system services.
I am logged in to an Admin account when I run the installer.  According to the 
installation log I am successful until it hits the main .exe of my project.  I 
install using LocalSystem and this works when I install to my dev box 
(Windows 7).  However, it fails when I attempt to install it onto my Windows 
2003 test server.  I already verified that the prerequisites (Framework 4.0, 
etc) exist on the box.  Any troubleshooting tips you can give me is 
appreciated.  Oy, my life for a good error message.
I can forward the windows installer logging if that is helpful.

Joel Palmer
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Enabling platform features during install

That directory does not exist on my Win8.1 box (where I have not yet installed 
the ADK). So, that can’t be the runtime requirement, unless the API cannot be 
used outside of generating ISOs/DVDs.






Blair





From: Phill Hogland
Sent: ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎6‎:‎45‎ ‎AM
To: General discussion for Windows Installer XML toolset.





I above been reading up on the dism api, and while I have not gotten very
far, one thing that confuses me is the requirement stated in the following
link of:
The binary files for your customized solutions must be saved in the same
directory as the DISM binaries installed by the Windows ADK. For example, if
you are running Windows 8 (x64) and the Windows ADK for Windows 8.1, your
customized solutions binaries must be located in c:\Program Files
(x86)\Windows Kits\8.1\Assessment and Deployment Kit\Deployment
Tools\amd64\DISM.

So if I want to develope a CA which calls the dism API, I assume that the CA
gets extracted to a folder in the %temp% location.  How does one comply with
the above requirement or does it even matter?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Enabling-platform-features-during-install-tp7591862p7591980.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] C# Custom Actions / SQL

If they are not in DTF then the WiX toolset doesn’t provide them. It’s assumed 
that most of what drove you to managed code would already be in the Framework 
so there isn’t the same level of need to invent the wheel.


Having said that, I like John’s reply. Cool system. I’ll have to remember that 
next time I’m faced with installers populating databases.






Blair





From: Levi Wilson
Sent: ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎6‎:‎37‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Being out of the WiX installer world for a handful of years, I was used to
writing all of my custom actions in C++. Getting back into this I noticed
that it is now acceptable to write them in C# and the DTF.

That being said, I have a custom action that is currently written in C++
that checks for the existence of a database as well as to verify if a
particular table exists. For that, I am using the sqlutil.lib to make that
easier. In C# custom actions, is there an equivalent or do most people just
use SqlConnection / SqlCommand out of the .NET framework?

Apologies if this is an obvious question, I just didn't want to re-invent
the wheel if WiX had a helper library to assist with this. I didn't see any
SQL related classes in DTF.

Thanks in advance,

Levi
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Confused... when installing a 32/64 bit MSI using 1 product.wxs file [P]

sys.BUILDARCH is the value of the -arch argument to candle, which Votive sets 
to the Platform property of the project during build (so it will reflect the 
build configuration, and if you build two MSIs with the same project will 
probably be different values for each one). It has NOTHING to do with the 
bitness of the developer’s box.


var.Platform is initially set by Votive to be the value of the Platform 
property (but if don’t use wixtargets it won’t be set for you) and could be 
redefined just about anywhere in the build process, including in WXI files you 
may include.






Blair





From: Carter Young
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎3‎:‎03‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Read my First Reply:

$(sys.BUILDARCH) should be used when determining Build time Components  
on the DEVELOPER MACHINE

$(var.Platform) should be used to determine the TARGET MACHINE'S  
bitness.  Your having a tough time here because $(sys.BUILDARCH) is  
always equal to $(var.Platform) on the DEVELOPER MACHINE.

Caveat: The above is always true unless setting the CPU Type in VS as  
Phil Stated.

Quoting Steven Ogilvie steven.ogil...@titus.com:

 Classification: Public
 Yes it was a pain in the a$$ to maintain two product.wxs files for  
 the same project. Blending them to one file has made work so much  
 easier.
 I have the configuration set in the wix project file to handle  
 whether it is an x86 debug/release or x64 debug/release build.

 The issue I have is I am not sure which is proper, using /if  
 $(sys.BUILDARCH) = 64 ? or using ?if $(var.Platform) = x64 ? for  
 setting variables for either x86/x64

 Same when installing a file for 32 bit or 64 bit (having 2 files but  
 need to install only one depending on the bitness of the MSI and OS)

 Thanks,

 Steve

 -Original Message-
 From: Phill Hogland [mailto:phogl...@rimage.com]
 Sent: January-22-14 4:53 PM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Confused... when installing a 32/64 bit MSI  
 using 1 product.wxs file

 The link provided by eyoung100 was helpful to me in packaging some  
 printer drivers, using a single MSI project with different build  
 configurations to produce x86 and x64 packages.  The bundle then  
 includes both packages and installs the one which is appropriate for  
 the architecture of the target system.  The two variations of this  
 approach that I took was:

 1) In the MSBuild project configurations section as displayed in  
 that link, add the following MSBuild property, which causes the  
 -arch flag to get set by the build process.
 InstallerPlatformx64/InstallerPlatform
 or
 InstallerPlatformx86/InstallerPlatform

 2) Since the printer driver that I install must have all of the files (both
 x86 and x64) 'pre-staged on the target system for the driver signing  
 signature to validate,  when building x86 the above  
 InstallerPlatform property causes all components to be marked for  
 x86, and when x64, all components are marked for x64.  This means  
 that the advice in the link to set the component attribute can be  
 ignored, as it will be done based on the InstallerPlatform (-arch)  
 flag.

 Also if the VS solution is used to do the build, and if projects use  
 the 'Any CPU' setting, when building this project it is necessary to  
 actually select x86 or x64 (or modify the project file so that one  
 of those outcomes is selected).  I have multiple projects which take  
 this approach.



 --
 View this message in context:  
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Confused-when-installing-a-32-64-bit-MSI-using-1-product-wxs-file-tp7591962p7591966.html
 Sent from the wix-users mailing list archive at Nabble.com.

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For  
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

  



  
 This message has been marked as Public by Steven  
 Ogilvie on January-22-14 5:47:47 PM.

 The above classification labels were added to the message by TITUS  
 Message Classification. For more information visit www.titus.com.

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX

Re: [WiX-users] VB6 OCX And Harvest

Add HarvestFileAdditionalOptions-svb6/HarvestFileAdditionalOptions to the 
first PropertyGroup in your WIXPROJ.






Blair





From: Graham Allwood
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎11‎:‎45‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Hi,

I have three VB6 components in a VB6 project I want to install and register. 
Two are ocx's and one is a dll. I see in the SDK Docs there is a -svb6 option 
for Harvest which I think I need to use. Is this right?

I am actually using MSBUILD and the Harvestfile element. There doesn't seem to 
be a property for the above option.

Does anyone know how to use HarvestFile with a VB6 COM dll?

Thanks for your help

Graham Allwood
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Managed bootstrapper on a PC without .NET framework 4.0

Share the contents of your config file for your BA


It is probably telling the stdba that you work with 3.5 so it doesn’t run the 
prereq on win7 (since 3.5 is included in win7), then the load fails because you 
require 4.x.






Blair





From: sky
Sent: ‎Thursday‎, ‎January‎ ‎23‎, ‎2014 ‎10‎:‎01‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Thanks for the reply. I set the value of WixMbaPrereqPackageId variable to
the id of dotnet 4.0 package included in my bundle. So it now runs well on a
Windows Xp PC where dotnet 4.0 is not installed. But it still doesn't run on
the Windows 7 PC where dotnet 4.0 is not installed. Log files of
installation on the two environments are as follows:

Windows Xp:
[0124:012C][2014-01-24T14:22:33]i001: Burn v3.8.1128.0, Windows v5.1 (Build
2600: Service Pack 3), path: ..., cmdline: ''
[0124:012C][2014-01-24T14:22:33]i000: Setting string variable 'WixBundleLog'
to value ...
[0124:012C][2014-01-24T14:22:33]i000: Setting string variable
'WixBundleOriginalSource' to value ...
[0124:012C][2014-01-24T14:22:33]i000: Setting string variable
'WixBundleName' to value ...
[0124:012C][2014-01-24T14:22:33]i000: Loading prerequisite bootstrapper
application because managed host could not be loaded, error: 0x8007007e
...
[00A4:07EC][2014-01-24T14:23:12]i301: Applying execute package: dotNetFX4.0,
action: Install, path: C:\Documents and Settings\All Users\Application
Data\Package
Cache\58DA3D74DB353AAD03588CBB5CEA8234166D8B99\dotNetFx40_Full_x86_x64.exe,
arguments: 'C:\Documents and Settings\All Users\Application Data\Package
Cache\58DA3D74DB353AAD03588CBB5CEA8234166D8B99\dotNetFx40_Full_x86_x64.exe
/q'
[0124:012C][2014-01-24T14:26:52]i319: Applied execute package: dotNetFX4.0,
result: 0x0, restart: None
[0124:012C][2014-01-24T14:26:52]i399: Apply complete, result: 0x0, restart:
None, ba requested restart:  No

Windows 7:
[0608:0C70][2014-01-24T14:26:21]i001: Burn v3.8.1128.0, Windows v6.1 (Build
7601: Service Pack 1), path: ..., cmdline: ''
[0608:0C70][2014-01-24T14:26:22]i000: Setting string variable 'WixBundleLog'
to value ...
[0608:0C70][2014-01-24T14:26:22]i000: Setting string variable
'WixBundleOriginalSource' to value ...
[0608:0C70][2014-01-24T14:26:22]i000: Setting string variable
'WixBundleName' to value ...
[0608:0C70][2014-01-24T14:26:22]i000: Loading managed bootstrapper
application.
[0608:0C70][2014-01-24T14:26:22]e000: Error 0x8013101b: Failed to create the
managed bootstrapper application.
[0608:0C70][2014-01-24T14:26:22]e000: Error 0x8013101b: Failed to create UX.
[0608:0C70][2014-01-24T14:26:22]e000: Error 0x8013101b: Failed to load UX.
[0608:0C70][2014-01-24T14:26:22]e000: Error 0x8013101b: Failed while running 

What could be the problem?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Managed-bootstrapper-on-a-PC-without-NET-framework-4-0-tp7592017p7592026.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] best way to handle su8pporting files

http://msdn.microsoft.com/library/aa368007.aspx


“ComponentId
A string GUID unique to this component, version, and language. 

Note that the letters of these GUIDs must be uppercase. Utilities such as 
GUIDGEN can generate GUIDs containing lowercase letters. The lowercase letters 
must be changed to uppercase to make these valid component code GUIDs.

If this column is null the installer does not register the component and the 
component cannot be removed or repaired by the installer. This might be 
intentionally done if the component is only needed during the installation, 
such as a custom action that cleans up temporary files or removes an old 
product. It may also be useful when copying data files to a user's computer 
that do not need to be registered.”



Components with a null ComponentId are only installed during initial 
installs/major upgrades and are otherwise “forgotten”. Thus, patches, minor 
updates, removals, etc. its as if they were never in the MSI. IIRC they also 
cannot be added by enabling a feature in a “change/modify” operation.


Also documented in ICE92.


Your files could be used that way if you will never need to do minor 
upgrades/patches/repairs involving those files. Otherwise the binary table 
would probably be a better bet.




Blair





From: Sean Farrow
Sent: ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎1‎:‎36‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Hi Phil,

The compile is done at install time--after the file is copied by executing a 
dos application.!
Is there any documentation regarding giving the component a null guid, what 
exactly does this do or perhaps not do maybe the right question to ask?
Cheers
Sean.
-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: 20 January 2014 23:09
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] best way to handle su8pporting files

You can put the file in the Binary table (maybe encrypted)  and stream
it out yourself, decrypting it. Or you can install it (encrypted) but
give the component a null guid so that it is not registered, and can
therefore be removed with a custom action or some other method after
its been used. Without knowing when you're doing that compile (at
install time? Some indeterminate time after it?) it's tricky to
recommend anything specific.

You won't be able to make the file secure because (as far as I know)
the compiler probably can't read encrypted files, so it would have to
be plain text for a brief time even if you shipped it encrypted and
decrypted it for the compile process. There is no way to hide it in
the MSI file because they are very transparent, but you could encrypt
it so it couldn't easily be deciphered using something like Orca.

Phil Wilson


On Mon, Jan 20, 2014 at 5:55 AM, Sean Farrow
sean.far...@seanfarrow.co.uk wrote:
 Hi,
 Yes, it is because of the integration. The compile process needs to be done 
 on the target machine.
 Cheers
 Sean.

 -Original Message-
 From: Wesley Manning [mailto:wmann...@dynagen.ca]
 Sent: 20 January 2014 13:18
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] best way to handle su8pporting files

 Why can't you just compile the source code beforehand and place the binary in 
 the installer?  It's because of the integration; you are compiling both 
 together?  Usually you can compile your software into an intermediate library 
 that the user can use and compile with their software.  Any change on doing 
 that?

 -Original Message-
 From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk]
 Sent: January-19-14 7:16 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] best way to handle su8pporting files
 Importance: High

 Hi All,
 I'm in a situation where I'm doing some work for a client integrating some 
 software we have written in to a piece of software they use.
 They haven't paid for the source, so leaving this behind is not an option.
 What I need to do is to copy the source file to the target machine, compile 
 this file and then remove the source file leaving the compiled binary.
 Given that RemoveFiles comes before InstallFiles in the InstallExecute 
 sequence what is the best way of doing this?
 Is there a mechanism for some form of support files in windows installer that 
 are copied to the users machine but not actually installed?
 Any help appreciated.
 Cheers
 Sean.
 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
 Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.8 Votive Drawing Error?

Please file a bug with that exact repro.


Thank you,



Blair





From: bwehking
Sent: ‎Monday‎, ‎January‎ ‎20‎, ‎2014 ‎11‎:‎50‎ ‎PM
To: General discussion for Windows Installer XML toolset.





I got it! 

Steps to reproduce in VS2013:
- Go to Tools-Options-Environment and choose Color theme Dark
- restart Visual Studio
- View the Paths property page of a .wixproj

Voila! It looks like the Paths page simply uses a wrong background color!
In the Dark theme _only_ the Paths page is grey and the text color is grey
as well! All the other pages are dark! 

I hope this helps.

Bernd



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-3-8-Votive-Drawing-Error-tp7591851p7591919.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FW: CertificatePath in Certificate element does not work

It appears that no one ever entered one. Today you go to http://wixtoolset.org/ 
and click on the red “File a bug” link, then enter a new bug. It will require 
you to setup an account on that site.


The new bug system doesn’t accept uploaded files (but the entries are in 
“Markdown” syntax) and you will see the results of what you type as you type 
it. Please describe the bug (much as you did in this email thread). You can 
demark the log output and your relevant authoring using the “code” syntax (so 
its easier to read). Also please provide links to your logs (please upload them 
somewhere you can make them public, then use the URL in the bug report). It 
also helps to have the version/build of your toolkit and any other information 
you feel may be relevant. We do a triage meeting just about every Thursday 
morning Pacific (US  Canada) time where all new entries are evaluated and 
assigned a release version (or release group), at which point its available for 
anyone to pick it up and fix it.


We love to have contributions, especially bug fixes and new feature work. If 
you are able to assist that way, you are most welcome but you will need to sign 
an agreement before we can accept your code. If you can contribute that way, 
you are invited to also join the wix-devs list, where you can ask for help, 
advice, and to have the agreement sent to you.


If you can’t make that type of contributions, that’s OK too, we also need the 
bug reports (and feature requests) to help us make this product better than 
ever (bug reports in email tend to get lost, as this one from 2 1/2 years ago 
did). And, of course, anyone can test the product in their own scenarios and 
build systems and let us know how we can improve that way as well.






Blair





From: MonteChristo
Sent: ‎Tuesday‎, ‎January‎ ‎21‎, ‎2014 ‎1‎:‎10‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Hi Blair,

This is the original link I was referring to in my message. It talks about a 
bug report.

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CertificatePath-in-Certificate-element-does-not-work-td6579192.html

I suppose no one bothered to file one. I’d be happy to file the report on 
http://wixtoolset.org/issues/, but what do you want me to include with the bug 
report? Your message was incomplete.

Regards,

Edgar

_

From: Blair Murri-3 [via Windows Installer XML (WiX) toolset] 
[mailto:ml-node+s687559n7591911...@n2.nabble.com]
Sent: Tuesday, January 21, 2014 5:18 AM
To: Knapp Edgar
Subject: Re: FW: CertificatePath in Certificate element does not work

The only certificate installation bug I found in the old sourceforge site was 
this: http://sourceforge.net/p/wix/bugs/1353/ and that one was marked fixed in 
2008 (it also describes a different bug with the same error code) and in the 
new system is found here: http://wixtoolset.org/issues/1768/.

The tracker” link below isn’t to a specific bug but to the “bugs” group on SF.

Otherwise the existing bug report never contained the error number.

I would suggest opening a new bug. Include your knowledge of the Overwrite 
attribute causing the error message. Also please include the with the bug 
report.

Blair


From: Knapp Edgar
Sent: ‎Wednesday‎, ‎January‎ ‎15‎, ‎2014 ‎11‎:‎42‎ ‎AM
To: General discussion for Windows Installer XML toolset.





This keeps getting returned for some reason.

-Original Message-
From: MonteChristo [mailto:[hidden 
email]/user/SendEmail.jtp?type=nodenode=7591911i=0]
Sent: Wednesday, January 15, 2014 8:35 PM
To: '[hidden email]/user/SendEmail.jtp?type=nodenode=7591911i=1'
Subject: Re: CertificatePath in Certificate element does not work

robmen wrote
 http://wix.sourceforge.net/ link on the right to the bug database:
 http://sourceforge.net/tracker/?group_id=105970atid=642714


 --
 virtually, Rob Mensching - http://RobMensching.com LLC
 --
 

Hi,

A brief summary of the problem: When iis:Certificate is used with 
CertificatePath=Some\Path\To\Cert.pfx and Overwrite=yes, installs fail with 
a rather misleading

InstallCertificates:  Error 0x80070057: Invalid Certificate.Attributes.
InstallCertificates:  Error 0x80070057: Failed to resolve certificate: 
SSL_Cerificate CustomAction InstallCertificates returned actual error code 1603 
(note this may not be 100% accurate if translation happened inside sandbox)

Turns out that Overwrite=yes is the culprit.

This bug has been reported and acknowledged long ago, but is still present in 
WiX 3.8. The quoted link to the bug database is a dead end. I just lost an 
entire afternoon to this because who would think that Overwrite=yes causes 
this failure, and then only when CertificatePath is used?

Would someone please supply an update on this bug and, if appropriate, a fresh 
link to its entry in the bug database?

Also, there is zero documentation on the semantics of the Overwrite

Re: [WiX-users] Fwd: Creating registry for an application installed outside the current directory structure in WIX file

And how do you intend to communicate that path into the MSI? And how will that 
path relate to the source path of the files before they have been added to the 
MSI when on other machines those files won’t exist yet?


I’m just trying to understand what your scenario is here to help guide you to a 
working solution.






Blair





From: Suvrajyoti Panda
Sent: ‎Monday‎, ‎January‎ ‎20‎, ‎2014 ‎10‎:‎51‎ ‎PM
To: General discussion for Windows Installer XML toolset.





I do intend, but for that scenario i am changing the path accordingly, 
using  %~d0\Installers path.

On 21-01-2014 11:07, Blair Murri wrote:
 And you don’t intend on installing them on any other machine?






 Blair





 From: Suvrajyoti Panda
 Sent: ‎Monday‎, ‎January‎ ‎20‎, ‎2014 ‎9‎:‎18‎ ‎PM
 To: General discussion for Windows Installer XML toolset.





 Hi Blair,

 I build them from the same machine at the same from another location.

 Regards,
 SuvraJyoti
 On 21-01-2014 09:48, Blair Murri wrote:
 You only install MSIs on the same machine you build those MSIs from?






 Blair





 From: Suvrajyoti Panda
 Sent: ‎Wednesday‎, ‎January‎ ‎15‎, ‎2014 ‎11‎:‎14‎ ‎PM
 To: General discussion for Windows Installer XML toolset.





 Thanks David that works.

 I have used as below:

 Property Id=SIMULATORPATH
DirectorySearch Id=SimulatortDir Depth=6
 Path=$(var.SimulatorSearchRoot) AssignToProperty=yes
FileSearch Id=StandaloneSimulator_exe
 Name=StandaloneSimulator.exe/
  /DirectorySearch
 /Property

 Adding to it, is there any way i can refer to the root directory of the
 current directory where the wix file is. My wix file is in the location
 D:\Project\ESI\PLTLPLO\trunk\releaseFiles\GameraInstaller, how can i
 refer to the root directory D:\. I want to use this value in the path
 attribute of DirectorySearch. If anyone has used the same please let me
 know.

 Regards,
 SuvraJyoti

 On 15-01-2014 20:53, David Watson wrote:
 If you are not shipping the simulator and it is already on the target 
 machine you can use a directory/file search to search the hard disk for it 
 then use the resulting property to set the registry value.

 See 
 http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/parentdirectorysearch.html


 -Original Message-
 From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
 Sent: 15 January 2014 11:51
 To: General discussion about the WiX toolset.
 Subject: [WiX-users] Fwd: Creating registry for an application installed 
 outside the current directory structure in WIX file

 Hi All,

 To add to the below issue, i understand that i could use a property that 
 includes the registry search. But issue here is that the application 
 StandaloneSimulator.exe is not something that has been installed on my 
 machine(i cannot find it under control panel). The 
 D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin exists as it has been 
 checked out from SVN.Please let me know in case there are any workarounds.


  Original Message 
 Subject:   Creating registry for an application installed outside the
 current directory structure in WIX file
 Date:  Wed, 15 Jan 2014 12:44:55 +0530
 From:  Suvrajyoti Panda suvrajyo...@contata.co.in
 To:General discussion about the WiX toolset.
 wix-users@lists.sourceforge.net



 Hi All,

 I am creating an wix installer. I want to create a registry entry whose 
 path is not under the directory structure created in the WIX file. Below is 
 what i intend to do:

 Directory Id='TARGETDIR' Name='SourceDir'
   Directory Id='Scheduler' Name=Scheduler
Directory Id='PLTLPLOGAMERA' Name=Pipeline Scheduler Gamera

 Component Id=x86RegEntGameraSimulatorPath
 Guid={C769AC98-A3D0-4CB4-939F-F396B49D4E5F} Win64=no
  RegistryValue Id=x86GameraSimulatorPathRegValue
 Root=HKLM Key=SOFTWARE\[Manufacturer]
 Name=$(var.standalonesimulatorRegName)
 *Value=D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin *Type=string /
/Component
Component Id=x64RegEntGameraSimulatorPath
 Guid={0ED0A7FC-DCB1-4C36-A39B-56F9F97A3A2C} Win64=yes
  RegistryValue Id=x64GameraSimulatorPathRegValue
 Root=HKLM Key=SOFTWARE\[Manufacturer]
 Name=$(var.standalonesimulatorRegName)
 Value=*D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin* Type=string /
/Component
/Directory
   /Directory
 /Directory

 The *Value *in the above keys is the path where an application 
 standalonesimulator.exe is installed.Please suggest if there is anyway 
 that i do not have to hardcode this path. I know i can use an include file 
 and fetch this path, but again that path will be harcoded in the include 
 file anyways.

 Regards,
 SuvraJyoti


 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud

Re: [WiX-users] Deleting files in a patch...

Null/empty component guid components are only installed in major upgrades. 
Patches are not typical major upgrades and those components are ignored (just 
as with all other maintenance transactions).


As it says: it cannot be removed or repaired. A patch is basically always “a 
repair” (after the view is upgraded by applying the patch).






Blair





From: Mita Patel
Sent: ‎Tuesday‎, ‎January‎ ‎14‎, ‎2014 ‎1‎:‎59‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Re: Deleting files in a patch.
Applying the same logic to a patch does not work.   
We set the component id for new files that do not need to be registered to 
null.   (to allow for  deletion in future patches)
Then apply the patch.  Resulting in the null component id files not getting 
installed.

Message: 6
Date: Tue, 14 Jan 2014 11:29:15 -0800
From: Phil Wilson phildgwil...@gmail.com
Subject: Re: [WiX-users] Deleting files in a patch...
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Message-ID:
CACZvpRZkcKk5z_XAk8ZdRchhJpcmwo1OH5+4AS5AuohBtXz=x...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1

It looks like you hijacked an existing discussion thread, so I'll start a new 
one. ...

Yes, that's the way it works. That might not be the best way to remove files if 
you decide you want them back later. An alternative is to make the component 
transitive and use a property to make the actual file be present or absent, so 
if you later decide you want the file present just set the property value. It 
can be tricky to make that work in all cases, such as adding/removing features, 
repair, patches etc because you need to preserve the property value that is 
keeping the file present or absent.

The msdn doc says the following for component id in the column table.
ComponentId -- If this column is null the installer does not register the 
component and the component cannot be removed or repaired by the installer.
This might be intentionally done if the component is only needed during the 
installation, such as a custom action that cleans up temporary files or removes 
an old product. It may also be useful when copying data files to a user's 
computer that do not need to be registered.

Does this mean in the full msi, components with null id will not be registered 
and if deleted then will  not put the msi in repair?  Which further indicates 
that at  patch time we can call a custom action to delete these components , 
and this will not throw the msi in repair mode?

Phil Wilson
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Creating registry for an application installed outside the current directory structure in WIX file

What is standalonesimulator.exe’s file id?






Blair





From: Suvrajyoti Panda
Sent: ‎Tuesday‎, ‎January‎ ‎14‎, ‎2014 ‎11‎:‎27‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Hi All,

I am creating an wix installer. I want to create a registry entry whose 
path is not under the directory structure created in the WIX file. Below 
is what i intend to do:

Directory Id='TARGETDIR' Name='SourceDir'
   Directory Id='Scheduler' Name=Scheduler
Directory Id='PLTLPLOGAMERA' Name=Pipeline Scheduler Gamera

 Component Id=x86RegEntGameraSimulatorPath 
Guid={C769AC98-A3D0-4CB4-939F-F396B49D4E5F} Win64=no
  RegistryValue Id=x86GameraSimulatorPathRegValue 
Root=HKLM Key=SOFTWARE\[Manufacturer] 
Name=$(var.standalonesimulatorRegName) 
*Value=D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin *Type=string /
/Component
Component Id=x64RegEntGameraSimulatorPath 
Guid={0ED0A7FC-DCB1-4C36-A39B-56F9F97A3A2C} Win64=yes
  RegistryValue Id=x64GameraSimulatorPathRegValue 
Root=HKLM Key=SOFTWARE\[Manufacturer] 
Name=$(var.standalonesimulatorRegName) 
Value=*D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin* Type=string /
/Component
/Directory
   /Directory
 /Directory

The *Value *in the above keys is the path where an application 
standalonesimulator.exe is installed.Please suggest if there is anyway 
that i do not have to hardcode this path. I know i can use an include 
file and fetch this path, but again that path will be harcoded in the 
include file anyways.

Regards,
SuvraJyoti
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error Building WixProj from DevEnv Command Line

dunno. I always use msbuild from the command line:


“FullPathToMSBuild.exe” /nologo /t:Rebuild “FullPathToSolutionFile”




DevEnv has always been a black box and has never been particularly build-box 
friendly.


You’ll have to use DevEnv on solutions containing projects that aren’t 
compatible with MSBuild, but there are fewer of those project types remaining 
with each new release of VS.




Blair





From: Dave Echols
Sent: ‎Wednesday‎, ‎January‎ ‎15‎, ‎2014 ‎10‎:‎47‎ ‎AM
To: General discussion for Windows Installer XML toolset.





I have a VS 2010 solution that contains 2 Wix projects for two different 
installs. I can compile/build the solution from within the Visual Studio IDE 
without errors. When I build the solution from the command line using 
DevEnv.exe, I get the following error on one of the projects...

MySetup.wixproj : error  : Catastrophic failure (Exception from HRESULT: 
0x8000 (E_UNEXPECTED))

One or more projects in the solution were not loaded correctly.
Please see the Output Window for details.

I am using the following command line to build the solution...

FullPathToDevEnv.exe /nologo /rebuild FullPathToSolutionFile

The other project in the solution builds without errors. I have examined each 
project file in a text editor and they are nearly identical, except for 
different files and different names/Guids. Any ideas on what might be causing 
this error and how I can make it go away?

Thanks in advance for any help.



David S. Echols
Senior Programmer

HA Architects  Engineers | www.ha-inc.comhttp://www.ha-inc.com
222 Central Park Ave., Suite 1200, Virginia Beach, Virginia 23462
d: (757) 213-6049 p: (757) 222-2010 f: (757) 222-2022

Follow Us: Twitterhttp://twitter.com/#!/hainctweets | 
Facebookhttp://www.facebook.com/HAArchitectsEngineers | 
LinkedInhttp://www.linkedin.com/company/ha-architects--engineers
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FW: CertificatePath in Certificate element does not work

The only certificate installation bug I found in the old sourceforge site was 
this: http://sourceforge.net/p/wix/bugs/1353/ and that one was marked fixed in 
2008 (it also describes a different bug with the same error code) and in the 
new system is found here: http://wixtoolset.org/issues/1768/.


The tracker” link below isn’t to a specific bug but to the “bugs” group on SF.


Otherwise the existing bug report never contained the error number.


I would suggest opening a new bug. Include your knowledge of the Overwrite 
attribute causing the error message. Also please include the with the bug 
report.






Blair





From: Knapp Edgar
Sent: ‎Wednesday‎, ‎January‎ ‎15‎, ‎2014 ‎11‎:‎42‎ ‎AM
To: General discussion for Windows Installer XML toolset.





This keeps getting returned for some reason.

-Original Message-
From: MonteChristo [mailto:edgar.kn...@sepura.com] 
Sent: Wednesday, January 15, 2014 8:35 PM
To: 'wix-users@lists.sourceforge.net'
Subject: Re: CertificatePath in Certificate element does not work

robmen wrote
 http://wix.sourceforge.net/ link on the right to the bug database:
 http://sourceforge.net/tracker/?group_id=105970atid=642714
 
 
 --
 virtually, Rob Mensching - http://RobMensching.com LLC
 --
 

Hi,

A brief summary of the problem: When iis:Certificate is used with 
CertificatePath=Some\Path\To\Cert.pfx and Overwrite=yes, installs fail with 
a rather misleading

InstallCertificates:  Error 0x80070057: Invalid Certificate.Attributes.
InstallCertificates:  Error 0x80070057: Failed to resolve certificate: 
SSL_Cerificate CustomAction InstallCertificates returned actual error code 1603 
(note this may not be 100% accurate if translation happened inside sandbox)

Turns out that Overwrite=yes is the culprit. 

This bug has been reported and acknowledged long ago, but is still present in 
WiX 3.8. The quoted link to the bug database is a dead end. I just lost an 
entire afternoon to this because who would think that Overwrite=yes causes 
this failure, and then only when CertificatePath is used?

Would someone please supply an update on this bug and, if appropriate, a fresh 
link to its entry in the bug database?

Also, there is zero documentation on the semantics of the Overwrite property. 

Thanks,

EK




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CertificatePath-in-Certificate-element-does-not-work-tp6579192p7591789.html
Sent from the wix-users mailing list archive at Nabble.com.




--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Fwd: Creating registry for an application installed outside the current directory structure in WIX file

You only install MSIs on the same machine you build those MSIs from?






Blair





From: Suvrajyoti Panda
Sent: ‎Wednesday‎, ‎January‎ ‎15‎, ‎2014 ‎11‎:‎14‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Thanks David that works.

I have used as below:

Property Id=SIMULATORPATH
 DirectorySearch Id=SimulatortDir Depth=6 
Path=$(var.SimulatorSearchRoot) AssignToProperty=yes
 FileSearch Id=StandaloneSimulator_exe 
Name=StandaloneSimulator.exe/
   /DirectorySearch
  /Property

Adding to it, is there any way i can refer to the root directory of the 
current directory where the wix file is. My wix file is in the location 
D:\Project\ESI\PLTLPLO\trunk\releaseFiles\GameraInstaller, how can i 
refer to the root directory D:\. I want to use this value in the path 
attribute of DirectorySearch. If anyone has used the same please let me 
know.

Regards,
SuvraJyoti

On 15-01-2014 20:53, David Watson wrote:
 If you are not shipping the simulator and it is already on the target machine 
 you can use a directory/file search to search the hard disk for it then use 
 the resulting property to set the registry value.

 See 
 http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/parentdirectorysearch.html


 -Original Message-
 From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
 Sent: 15 January 2014 11:51
 To: General discussion about the WiX toolset.
 Subject: [WiX-users] Fwd: Creating registry for an application installed 
 outside the current directory structure in WIX file

 Hi All,

 To add to the below issue, i understand that i could use a property that 
 includes the registry search. But issue here is that the application 
 StandaloneSimulator.exe is not something that has been installed on my 
 machine(i cannot find it under control panel). The 
 D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin exists as it has been 
 checked out from SVN.Please let me know in case there are any workarounds.


  Original Message 
 Subject:   Creating registry for an application installed outside the
 current directory structure in WIX file
 Date:  Wed, 15 Jan 2014 12:44:55 +0530
 From:  Suvrajyoti Panda suvrajyo...@contata.co.in
 To:General discussion about the WiX toolset.
 wix-users@lists.sourceforge.net



 Hi All,

 I am creating an wix installer. I want to create a registry entry whose path 
 is not under the directory structure created in the WIX file. Below is what i 
 intend to do:

 Directory Id='TARGETDIR' Name='SourceDir'
 Directory Id='Scheduler' Name=Scheduler
  Directory Id='PLTLPLOGAMERA' Name=Pipeline Scheduler Gamera

   Component Id=x86RegEntGameraSimulatorPath
 Guid={C769AC98-A3D0-4CB4-939F-F396B49D4E5F} Win64=no
RegistryValue Id=x86GameraSimulatorPathRegValue
 Root=HKLM Key=SOFTWARE\[Manufacturer]
 Name=$(var.standalonesimulatorRegName)
 *Value=D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin *Type=string /
  /Component
  Component Id=x64RegEntGameraSimulatorPath
 Guid={0ED0A7FC-DCB1-4C36-A39B-56F9F97A3A2C} Win64=yes
RegistryValue Id=x64GameraSimulatorPathRegValue
 Root=HKLM Key=SOFTWARE\[Manufacturer]
 Name=$(var.standalonesimulatorRegName)
 Value=*D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin* Type=string /
  /Component
  /Directory
 /Directory
   /Directory

 The *Value *in the above keys is the path where an application 
 standalonesimulator.exe is installed.Please suggest if there is anyway that 
 i do not have to hardcode this path. I know i can use an include file and 
 fetch this path, but again that path will be harcoded in the include file 
 anyways.

 Regards,
 SuvraJyoti


 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
 Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 SDL PLC confidential, all rights reserved.
 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.
 SDL PLC is a public limited company registered in England and Wales.  
 Registered number: 02675207.
 Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 
 7DY, UK.



 This message has been scanned for malware by Websense. www.websense.com

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses

Re: [WiX-users] Web Setup

When you use the property remember pattern, all packages that store/retrieve 
the property at the same location will “remember” the same value. If you need 
the two setups to have different values, you should consider using two 
different registry locations for your property remember pattern.






Blair





From: Tony Jose Mampilly
Sent: ‎Wednesday‎, ‎January‎ ‎15‎, ‎2014 ‎11‎:‎12‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Hi,

I have created 2 web setups in a similar manner. In installation UI, the
user can change the name of virtual directory if needed. By default it
displays the name I have given in CDATA. The first web installer works as
required, but problem comes on installation of second installer. During the
installation, the default virtual directory name displayed is fetched from
the first installer. Say I gave name of first virtual directory as 123, and
I need the name of second virtual directory as 345, but by default it
displays 123. We can change if we want, but I need it to be displayed
correctly. If I am uninstalling the first website, then it works fine.
Somebody please help me with this issue, its urgent. Any help appreciated
The codes can be accessed at
https://drive.google.com/folderview?id=0B1gCMqS-Y9BFcFVPaEFVZjQwdFkusp=sharing

Thank you

Regards
Tony
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Fwd: Creating registry for an application installed outside the current directory structure in WIX file

And you don’t intend on installing them on any other machine?






Blair





From: Suvrajyoti Panda
Sent: ‎Monday‎, ‎January‎ ‎20‎, ‎2014 ‎9‎:‎18‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Hi Blair,

I build them from the same machine at the same from another location.

Regards,
SuvraJyoti
On 21-01-2014 09:48, Blair Murri wrote:
 You only install MSIs on the same machine you build those MSIs from?






 Blair





 From: Suvrajyoti Panda
 Sent: ‎Wednesday‎, ‎January‎ ‎15‎, ‎2014 ‎11‎:‎14‎ ‎PM
 To: General discussion for Windows Installer XML toolset.





 Thanks David that works.

 I have used as below:

 Property Id=SIMULATORPATH
   DirectorySearch Id=SimulatortDir Depth=6
 Path=$(var.SimulatorSearchRoot) AssignToProperty=yes
   FileSearch Id=StandaloneSimulator_exe
 Name=StandaloneSimulator.exe/
 /DirectorySearch
/Property

 Adding to it, is there any way i can refer to the root directory of the
 current directory where the wix file is. My wix file is in the location
 D:\Project\ESI\PLTLPLO\trunk\releaseFiles\GameraInstaller, how can i
 refer to the root directory D:\. I want to use this value in the path
 attribute of DirectorySearch. If anyone has used the same please let me
 know.

 Regards,
 SuvraJyoti

 On 15-01-2014 20:53, David Watson wrote:
 If you are not shipping the simulator and it is already on the target 
 machine you can use a directory/file search to search the hard disk for it 
 then use the resulting property to set the registry value.

 See 
 http://wixtoolset.org/documentation/manual/v3/howtos/files_and_registry/parentdirectorysearch.html


 -Original Message-
 From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
 Sent: 15 January 2014 11:51
 To: General discussion about the WiX toolset.
 Subject: [WiX-users] Fwd: Creating registry for an application installed 
 outside the current directory structure in WIX file

 Hi All,

 To add to the below issue, i understand that i could use a property that 
 includes the registry search. But issue here is that the application 
 StandaloneSimulator.exe is not something that has been installed on my 
 machine(i cannot find it under control panel). The 
 D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin exists as it has been 
 checked out from SVN.Please let me know in case there are any workarounds.


  Original Message 
 Subject:   Creating registry for an application installed outside the
 current directory structure in WIX file
 Date:  Wed, 15 Jan 2014 12:44:55 +0530
 From:  Suvrajyoti Panda suvrajyo...@contata.co.in
 To:General discussion about the WiX toolset.
 wix-users@lists.sourceforge.net



 Hi All,

 I am creating an wix installer. I want to create a registry entry whose path 
 is not under the directory structure created in the WIX file. Below is what 
 i intend to do:

 Directory Id='TARGETDIR' Name='SourceDir'
  Directory Id='Scheduler' Name=Scheduler
   Directory Id='PLTLPLOGAMERA' Name=Pipeline Scheduler Gamera

Component Id=x86RegEntGameraSimulatorPath
 Guid={C769AC98-A3D0-4CB4-939F-F396B49D4E5F} Win64=no
 RegistryValue Id=x86GameraSimulatorPathRegValue
 Root=HKLM Key=SOFTWARE\[Manufacturer]
 Name=$(var.standalonesimulatorRegName)
 *Value=D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin *Type=string /
   /Component
   Component Id=x64RegEntGameraSimulatorPath
 Guid={0ED0A7FC-DCB1-4C36-A39B-56F9F97A3A2C} Win64=yes
 RegistryValue Id=x64GameraSimulatorPathRegValue
 Root=HKLM Key=SOFTWARE\[Manufacturer]
 Name=$(var.standalonesimulatorRegName)
 Value=*D:\Project\ESI\PFW\trunk\StandaloneSimulator\bin* Type=string /
   /Component
   /Directory
  /Directory
/Directory

 The *Value *in the above keys is the path where an application 
 standalonesimulator.exe is installed.Please suggest if there is anyway 
 that i do not have to hardcode this path. I know i can use an include file 
 and fetch this path, but again that path will be harcoded in the include 
 file anyways.

 Regards,
 SuvraJyoti


 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical 
 Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 SDL PLC confidential, all rights reserved.
 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.
 SDL PLC is a public limited company registered

Re: [WiX-users] Custom Action Build Error

2014-01-10 Thread Blair Murri

In both Windows Installer and in MSBuild all directory paths are always 
expected to end with the trailing backslash. In fact, if you look at all of the 
built-in properties for MSBuild all of the directory paths always end with the 
backslash.
 
The fact that your WixToolPath ends in a letter instead of the backslash caused 
your build error.
 
-Blair 
 
 From: bria...@gmail.com
 Date: Fri, 10 Jan 2014 11:23:26 -0500
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Custom Action Build Error
 
 Thanks, it is actually the file at C:\Program Files
 (x86)\MSBuild\Microsoft\WiX\v3.x\wix.ca.targets that needed updated.
 
 Brian
 
 Brian
 
 If you can't explain it simply, you don't understand it well enough.  -
 Albert Einstein
 
 
 On Fri, Jan 10, 2014 at 10:51 AM, Carter Young ecyo...@grandecom.netwrote:
 
  Try Editing wix.ca.targets to read
  CreateProperty Value=$(WixToolPath)\..\sdk\ Condition=
'$(WixSdkPath)' == '' 
 Output TaskParameter=Value PropertyName=WixSdkPath /
  /CreateProperty
 
  Looks like the Preprocessor Variable for $(WixToolPath) doesn't
  contain the last trailing slash for the path, then submit a Bug
  Request to the WiX Bugtracker and reference this Post, if and only if
  the fix works.
 
  If all goes well, the bug fix will reqire editing the preprocer
  variable to include the trailing slash.  Once that's done you can
  remove the manual edit we created from the targets file.
 
  Carter
 
  Quoting Brian Enderle bria...@gmail.com:
 
   When I attempt to build my CustomAction project Visual Studio exits with
  a
   code of 3.
  
   I have tracked the issue to the way wix.ca.targets references the path to
   MakeSfxCA.exe.  snip
 
 
 
  --
  CenturyLink Cloud: The Leader in Enterprise Cloud Services.
  Learn Why More Businesses Are Choosing CenturyLink Cloud For
  Critical Workloads, Development Environments  Everything In Between.
  Get a Quote or Start a Free Trial Today.
 
  http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today. 
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom Action Issue during MSI installation rollback

2014-01-10 Thread Blair Murri

Most of the time if you can condition your custom actions on the action states 
of some related component you will have more reliability in all use cases.

 Date: Fri, 10 Jan 2014 11:22:29 -0800
 From: phildgwil...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Custom Action Issue during MSI installation rollback

 Looking at a complete verbose log may help. Otherwise there's not enough
 info here to say what's wrong. It doesn't help much to say that the CA is
 something like this. For example, what type is it? We could assume it's
 deferred, but it's better to know for a fact.

 1. I assume the V1 install has an uninstall CA to remove the driver. If so,
 at the end of REP of V1 there will be no driver on the system. Does it
 uninstall the driver?

 2. When V2 fails, has it installed the V2 version of the kernel driver?  If
 so, does it have a rollback custom action to remove it?  At the point where
 V2 fails we don't know whether there is a V2 kernel driver on the system or
 not, and if there is a rollback CA in V2 to uninstall it.

 Anyway the log will show the sequence of events and conditions that
 resulted in this situation so you should be able to why V1's re-install of
 the driver didn't happen. If it says the condition evaluated to false, it
 occurs to me that the re-install of V1 may actually be part of the rollback
 transaction, in which case you need a rollback CA to re-install the driver,
 not an install CA.  However I'm not sure of that - I forget the details of
 how that all hangs together.

 Phil Wilson

 On Thu, Jan 9, 2014 at 3:43 PM, Suryadeep Biswal surya6...@hotmail.comwrote:

  We ship a MSI which supports upgrades. We schedule the
  RemoveExistingProducts
  custom action after InstallInitialize using MajorUpgrade
  element –

  MajorUpgrade

  Schedule=afterInstallInitialize

  AllowDowngrades=yes /

  The MSI performs a variety of things including GACing,
  writing to registry and also includes a custom action which is used to
  install
  a kernel mode driver.

  We have been running into an issue in the following scenario
  -

  1.
  V1 MSI is installed first.

  2.
  V2 MSI is installed at a later point.

  a.   For
  cases, there is a bug in v2 MSI, we expect the MSI installation to roll
  back
  and finally leave the system with v1 installed.

  b.  We
  see everything rolling back to v1 (including the registry keys, file
  versions
  etc.) except for the kernel driver. After the previous rollback, we no
  longer
  see the kernel mode driver.

  In the log file, I did not see the custom action being run
  when v1 is reinstalled.

  InstallExecuteSequence for the custom action that
  installs the kernel driver looks something like this –

  Custom Action=InstallDrivers
  Before=WriteRegistryValues 

(NOT REMOVE) AND
  Privileged

  /Custom

  I am wondering if the conditions have something to do with
  this? I would appreciate any help in figuring out the root cause for this
  issue.

  Regards,

  Surya

  --
  CenturyLink Cloud: The Leader in Enterprise Cloud Services.
  Learn Why More Businesses Are Choosing CenturyLink Cloud For
  Critical Workloads, Development Environments  Everything In Between.
  Get a Quote or Start a Free Trial Today.

  http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today. 
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Chaining MSPs

2014-01-10 Thread Blair Murri

FYI: That feature request on SF now lives at http://wixtoolset.org/issues/3962/.

Date: Fri, 10 Jan 2014 13:35:30 -0800
From: kelly.gr...@toltech.net
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Chaining MSPs

robmen wrote
1. One include the original B and C MSIs *plus* the new B and C MSPs in
the updated Burn. Burn will only download the B and C MSIs if they are
missing and Burn will slipstream the MSPs when possible.

This seems to work and give me the desired behavior. Thanks!

I also just found this: Bundle Version and patching
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-Version-and-patching-td7579655.html#a7584962

which references Feature Request 725
http://sourceforge.net/p/wix/feature-requests/725/ . That is pretty much
the problem I was having.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Chaining-MSPs-tp7591695p7591702.html
Sent from the wix-users mailing list archive at Nabble.com.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Patching compressed VS uncompressed image?

2014-01-09 Thread Blair Murri

To help avoid prompts for source in patch-on-patch scenarios Windows 
Installer has been known to cache originals of files that are patched, but 
that behavior can be turned off. Maybe it is off for uncompressed sources?

 Date: Wed, 8 Jan 2014 13:40:48 -0800
 From: dtkob...@gmail.com
 To: WiX-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Patching compressed VS uncompressed image?

 My patches are whole file patches.

 There is no UI either in the patches either.

 I'll have to check out the hash table and see what files may mismatch.  It
 never mentions anything about the file it's trying to access, it just keeps
 mentioning the product it looking for.  About every 45 seconds the time out
 happens and starts the query again.  It just goes on and on and on until it
 decides to apply the patch.

 There are uninstallable patches as well.

 I would assume a compressed and uncompressed would behave the same.  I get
 why an uncompressed install might be different in that the files get
 unpacked in a temp directory for install which the uninstall doesn't need
 to do.  The non stop attempt to access source is what bugs me.  If you
 install from an administrative installation which is uncompressed and then
 apply my patch 1 and patch 2, I don't get this issue.  I now the MSI is
 marked as administrative installation and it has a reference to the
 external cab file, but what would make them behave different?  Are those
 entries enough to make it act this way?
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Activation of burn step by step

2014-01-09 Thread Blair Murri

Please tell us how we can improve this: 
http://wixtoolset.org/documentation/manual/v3/bundle/
 
 Date: Thu, 9 Jan 2014 00:04:47 -0800
 From: jessro...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Activation of burn step by step
 
 Need step by step directions to activate burn bootstrape
 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today. 
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstalling with application running

2014-01-09 Thread Blair Murri

Depends on the file locks. A binary that is simply loaded in a process can be 
moved/renamed and the directory it was originally in when it was loaded removed 
without disturbing the process, but if the process is holding other files in 
that same directory open with different kinds of file locks then the file 
move/rename returns a file in use error.
 
When Windows Installer moves a file (in preparation for removal) it moves it to 
a directory it owns (so that if it has to rollback it can reinstall by 
simply moving the file back). If the uninstall/upgrade is successful it then 
tries to delete the moved files, and if that fails then it marks them for 
removal during the next reboot.
 
That directory used by Windows Installer for moved files is usually named 
Config.Msi and is marked with both System and Hidden attributes, which would 
explain why explorer couldn't find the directory.
 
Blair
 
 From: simongustavs...@driveworks.co.uk
 To: wix-users@lists.sourceforge.net
 Date: Thu, 9 Jan 2014 10:13:10 +
 Subject: [WiX-users] Uninstalling with application running
 
 Good morning Wix users :)
 I've come across an instance where uninstalling our product while it is 
 running succeeds and leaves the application running. The Program Files 
 directory, ARP entry, all registry keys etc are all removed. Going into task 
 manager, right clicking the application and selecting Open file location 
 shows an error message similar to Could not find C:/config.msi 
 (paraphrasing from memory).
 Internally it has been reproduced on three different PCs, however, whenever 
 I've tried it myself Windows Installer always fails half way through with a 
 File in use error message, as I expect it to. Anyone know what's going on 
 here?
 Thanks
 Simon
 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today. 
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn not uninstalling MSI downloaded from URL

2014-01-08 Thread Blair Murri

This speaks to the best practice of always setting up your bundles so that they 
use the package hashes instead of signatures to validate that the correct 
package was retrieved.

 From: dan.mad...@quanser.com
 To: wix-users@lists.sourceforge.net
 Date: Tue, 7 Jan 2014 12:22:13 -0500
 Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL

 Hi Rob,

 I recognize that System Restore isn't a magic bullet, but it has been working 
 fairly well for me in this case. It turns out that the package cache was not 
 in a dirty state. Instead, I found out the wrong MSI was put online. The file 
 sizes were the same as was the Summary Information in Orca and UpgradeCode so 
 it wasn't immediately evident. The bootstrapper would download the online 
 version and then fail to register it because it was trying to register the 
 ProductCode GUID used when it was built while the downloaded MSI had a 
 different ProductCode. Hence, the registration failed because it could not 
 find the ProductCode in the list of installed products. However, it continued 
 with the install anyways without any warning given to the user.

 The net effect of this failed registration did not turn up until I attempted 
 to uninstall, in which case it decided (I think) that the product was not 
 installed (since it was using the wrong GUID) so no action was required other 
 than removing the cached MSI and bootstrapper. So the uninstall also 
 succeeded even though the product was actually left installed. Again, no 
 feedback to the user indicating failure and the ARP entry was removed, while 
 the files were left on the system.

 Moral of the story: always make sure the online MSI and local MSI used as the 
 SourceFile for the MsiPackage are absolutely identical. Obvious, but mistakes 
 are quite costly, potentially leaving users with no way to uninstall the 
 product from their machine without technical support.

 Thanks for your help.

 Dan

 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com] 
 Sent: Monday, January 06, 2014 4:39 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL

 System Restore isn't a system reset. I've never seen it work terribly well. 
 If you want system reset, use a VM and snapshots.

 The messages you are seeing are pretty suspect. They suggest the package 
 cache is constantly in a dirty state which shouldn't be happening with normal 
 install/uninstall. Anyway, the bundle log file should show why a package is 
 not being uninstalled.

 -Original Message-
 From: Daniel Madill [mailto:dan.mad...@quanser.com] 
 Sent: Monday, January 6, 2014 1:27 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL

 Hi,

 I don't think so. I don't have the packages as part of any other bundle. 
 Also, I can always install and uninstall fine if I put the MSIs on the local 
 filesystem, but never when it has to download the MSI from the URL. I've also 
 been using System Restore to put my system back in its original state. I 
 searched for the package code of the MSI in the registry after uninstall but 
 could not find it. However, just in case I did not look properly, where 
 should I expect to find the reference counts for the packages in the registry 
 and should I be looking for the package code from the summary information of 
 the MSI, the upgrade code or the component GUIDS (of which there are probably 
 13000 so I hope not).

 If I have the MSIs on the local filesystem then I do not get the Unable to 
 register source directory warning in the install log, nor do I get the 
 Detected partially cached package in the uninstall log. It is only when it 
 has to download the MSI from the URL that I get these warnings in the logs.

 I added Cache='yes' and 'CacheId' values but that didn't help. Is the fact I 
 use a relative path as part of the Name attribute a problem for downloaded 
 packages? It does appear to download and cache the MSI in the 
 C:\ProgramData\Package Cache folder after downloading it so I'm surprised by 
 the Detected partially cached package warning in the uninstall log.

 Is there anything else I can do to better debug the problem?

 Thanks.

 Dan

 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com]
 Sent: Monday, January 06, 2014 3:36 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Burn not uninstalling MSI downloaded from URL

 First guess: maybe the packages are being reference counted by another bundle 
 still on the machine.

 -Original Message-
 From: Daniel Madill [mailto:dan.mad...@quanser.com]
 Sent: Monday, January 6, 2014 12:24 PM
 To: WiX-users@lists.sourceforge.net
 Subject: [WiX-users] Burn not uninstalling MSI downloaded from URL

 Hi,

 I have a simple burn bundle that contains three packages: .NET, a 64-bit MSI 
 and an

Re: [WiX-users] Patching compressed VS uncompressed image?

2014-01-08 Thread Blair Murri

Are your patches delta or whole file?

 Date: Wed, 8 Jan 2014 10:46:06 -0800
 From: phildgwil...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Patching compressed VS uncompressed image?

 It could be useful to examine the log where the patching accesses the
 network MSI to see what actually happens. Typical reasons include installed
 files that no longer match the cached MSI. For example the cached (MSI plus
 patches) has entries in the file table that say the version of the file on
 disk is one thing, but actually on disk it's something else. Windows
 doesn't know whether the patch should be applied until it repairs the
 install and gets the right file to do the version test. This is why
 version lying is a bad idea. Similar things happen with data files with
 mismatched file hashes.   That's about all I can think of right now.  If
 the patch is uninstallable the behavior is a bit different. The timeout is
 more like a network/TCP timeout - are the times the same or do they get
 larger after each failure?

 Does the patch have a UI? If it's trying to resolve the source inside the
 execute sequence it may not pop up a UI there, where I'd expect that it
 would in the UI sequence, assuming of course it knows that early that the
 source is required.

 Phil Wilson

 On Wed, Jan 8, 2014 at 7:47 AM, darenko6874 . dtkob...@gmail.com wrote:

  Can someone tell me why patching a uncompressed image requires the attempt
  to look for source?  I am not prompted asking for credentials, but the
  patch log shows it keeps looking for the original install location like
  this:

  Resolving source.
  MSI (s) (9C:30) [08:23:26:466]: User policy value 'SearchOrder' is 'nmu'
  MSI (s) (9C:30) [08:23:26:466]: User policy value 'DisableMedia' is 0
  MSI (s) (9C:30) [08:23:26:466]: Machine policy value 'AllowLockdownMedia'
  is 1
  MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Looking for sourcelist for
  product {F15CB215-59FA-4643-AE03-FDB6655BF13F}
  MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Adding
  {F15CB215-59FA-4643-AE03-FDB6655BF13F}; to potential sourcelist list
  (pcode;disk;relpath).
  MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Now checking product
  {F15CB215-59FA-4643-AE03-FDB6655BF13F}
  MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Attempting to use
  LastUsedSource from source list.
  MSI (s) (9C:30) [08:23:26:466]: SOURCEMGMT: Trying source

  \\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\.
  MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1314 2:

  \\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\
  MSI (s) (9C:30) [08:24:13:562]: ConnectToSource: CreatePath/CreateFilePath
  failed with: -2147483648 1314 -2147483648
  MSI (s) (9C:30) [08:24:13:562]: ConnectToSource (con't):
  CreatePath/CreateFilePath failed with: -2147483648 -2147483648
  MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: net source

  '\\dkwin8\E\reflection_wit15_trunk\installers\Alloy\release_base_uncomp608\x86\prod\2014\'
  is invalid.
  MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
  MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: Processing net source list.
  MSI (s) (9C:30) [08:24:13:562]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
  MSI (s) (9C:30) [08:24:13:562]: SOURCEMGMT: Processing media source list.
  MSI (s) (9C:30) [08:24:14:638]: Note: 1: 2203 2:  3: -2147287037
  MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Source is invalid due to
  missing/inaccessible package.
  MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
  MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Processing URL source list.
  MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
  MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2: -2147483647 3: 2014R1c.msi
  MSI (s) (9C:30) [08:24:14:638]: Note: 1: 1706 2:  3: 2014R1c.msi
  MSI (s) (9C:30) [08:24:14:638]: SOURCEMGMT: Failed to resolve source
  MSI (s) (9C:30) [08:24:14:638]: Failed to generate patch cache opcodes for:
  {F15CB215-59FA-4643-AE03-FDB6655BF13F} product
  MSI (s) (9C:30) [08:24:14:638]: Resolving source.
  ... and it seems to loop for hours.

  The cached MSI is on the machine as isn't missing.  I've read some other
  posts where this was the case.

  I see the Resolve source text, but I don't have the ResolveSource action in
  my MSI.  It continues to look with this same text until some time it
  decides to proceed with applying the patch.  It could take a few hours or a
  day and it finally applies successfully.

  To give some background, I am installing an uncompressed image (I built it
  uncompressed and it's not an administrative installation uncompress image)
  from a UNC path (mapped drive doesn't matter either).  I've then
  disconnected from that source (rebooted to make sure it can't connect).
   I've then created 2 patches.  Lets just say patch 1 and patch 2.  My first
  patch applies in less than 5 minutes.  My second

Re: [WiX-users] Unable to override SetProperty value with Edit Control value

2014-01-06 Thread Blair Murri

When you have more than two possible sources for a property's value, then you
will need some intermediate properties.

Here's how that works: At the start of the sequence, a property may have been
initialized with a variable either from the property table or from the command
(or, in the case of the execute sequence, the ui sequence). If a value wasn't
set (or in the case of the command line or ui sequence, was removed), then it
will start out not set (not in the list of properties with values).

Any attempt to set a property to a blank/empty value will remove that property
from the property list (so, reading a blank value and assigning that the
property will clear that property's value).

The SetProperty element schedules a custom action that sets a property to a
formatted value. If the condition is false, then the action will be skipped
(like any other action). At the time that action runs, if the condition is
true, it will set the property's value to the action's value. Walk the sequence
in order and see what is happening (I find it helps to open my MSIs in Orca to
walk the database, much like I look at source code walk the instruction
flow to see what I expect to happen as I write down what I expect all the
variables to be. Helps a lot when debugging some strange occurrence in my (or
anyone else's) code).

Now that you have more sources, you will need to catalog them, and set them one
at a time. However, given that it is easier to detect a property that hasn't
yet be set than it is to detect a property that has its default value, turn
your problem around.

First detect the possible values for your property from wherever they may be
(into intermediate properties). Then, pick the one that always overrides all
the rest of them, and set your property to that value. If your property is
still empty, then set it to the next most important version of itself, etc.
The last one you will attempt to set will be the default value. Each time, the
condition for setting the actual property will always be the same: Not
PropertyName.

An optimization I always do is I use the actual property name when setting the
first value (reduces the number if intermediate properties I need AND the first
assignment doesn't need a condition since I will always attempt it). If that
value is not the command-line, then I always reserve the public name that the
users see for the command-line and use a different internal name for the
actual property.

Hope that helps. Look up conditions, sequence tables, and properties on MSDN
for Windows Installer to understand more. Also, there's a great book out, a
great tutorial, and lots of information accessible via Bing/Google/etc., as
well as this user list.

-Blair

Date: Mon, 6 Jan 2014 07:48:21 -0800
From: tr...@outlook.com
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Unable to override SetProperty value with Edit
Control value

Thank you - that worked but I could use some help in understanding how/why.
How does setting the condition Not PROPSERVERHOSTNAME force the property
to be updated to the user override value on the backend when the xml file is
updated?

There's also one other kink I'm trying to figure out in regards to my
original question. I did simplify my code in the original question, but
what I'm actually trying to do is set a default value for a property, allow
the user to override that property value then store the value in the
registry and then load the property on subsequent upgrades. If I include
the condition you specified, then my Registry key now will never load
because PROPSERVERHOSTNAME already has a value of Sample. Any thoughts on
how I can get this to work?

Property Id=PROPSERVERHOSTNAME Value=Sample Secure=yes/

Property Id=PROP_REG_APPSERVER_HOSTNAME
RegistrySearch Id=REG_APPSERVER_NAME Root=HKLM Key=$(var.RegPath)
Name=APPSERVER_HOSTNAME Type=raw/
/Property
SetProperty Id=PROPSERVERHOSTNAME Value=[PROP_REG_APPSERVER_HOSTNAME]
After=AppSearchNot PROPSERVERHOSTNAME AND
PROP_REG_APPSERVER_HOSTNAME/SetProperty

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Unable-to-override-SetProperty-value-with-Edit-Control-value-tp7591569p7591593.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix

Re: [WiX-users] Unable to override SetProperty value with Edit Control value

2014-01-04 Thread Blair Murri

SetProperty Id=PROPSERVERHOSTNAME Value=Sample After=AppSearchNot 
PROPSERVERHOSTNAME/SetProperty

 Date: Thu, 2 Jan 2014 09:29:10 -0800
 From: tr...@outlook.com
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Unable to override SetProperty value with Edit Control   
 value

 I have a Property called PROPSERVERHOSTNAME which I use to update an Xml File
 (util:XmlFile).  This property is set via SetProperty but I also give the
 user the ability to override the default Property value by presenting the
 Property in an edit Control.  My problem is that when the Xml File gets
 updated, it always uses the value that was configured in the SetProperty
 code instead of what the user types in the edit Control.  What am I doing
 wrong?  If I comment out the SetProperty line of code, the Xml file
 successfully updates with the value from the Control's user input. 

 The simplified code (using WiX Toolset v3.8): 

 Property Id=PROPSERVERHOSTNAME Secure=yes/

 SetProperty Id=PROPSERVERHOSTNAME Value=Sample
 After=AppSearch/SetProperty

 Fragment
 UI
   Dialog
 ... 
 Control Id=CONTROL_LABEL_SERVERHOSTNAME Type=Text X=25 Y=73
 Width=325 Height=15 TabSkip=no Text=amp;Application Server
 Hostname: /
 Control Id=CONTROL_FIELD_SERVERHOSTNAME Type=Edit X=25 Y=85
 Width=325 Height=18 Property=PROPSERVERHOSTNAME Text={200}/  
 ... 
   /Dialog
 /UI
   /Fragment

 Feature...
 Component Id=COMP_WEBCONFIG Guid={63EB4480-6D1F-4891-B48B-7627E21A167B}
 Directory=FOLDER_WEB
 CreateFolder/
 util:XmlFile
 Id=ModifyConnectionString 
  Action=setValue 
  Permanent=yes 

 ElementPath=/configuration/CustomConfiguration/APIConfiguration 
  Name=hostname 
  File=[FOLDER_WEB]\Web.config 
  Value=[PROPSERVERHOSTNAME] 
  SelectionLanguage=XPath 
  Sequence=1 /
 /Component
 /Feature 

 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Unable-to-override-SetProperty-value-with-Edit-Control-value-tp7591569.html
 Sent from the wix-users mailing list archive at Nabble.com.

 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Strange log message and bad user experience - can't remove rbf file?

2014-01-04 Thread Blair Murri

I assume that some file(s) that you are removing or upgrading don't extend
Full Control to the account named SYSTEM, which is actually a requirement
of Windows Installer (and is the default of every single file and folder in a
fresh install of the operating system). It's possible that if the file was in
use when it was moved that it was moved preserving the rights it had in the
installation folder to not crash whatever process was still using it.

Look closely at the file permissions of the files you will be changing/removing
to see if there is some file that MSI will have trouble with.

Date: Thu, 2 Jan 2014 22:06:28 -0800
From: mr_gapea...@yahoo.com
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Strange log message and bad user experience - can't
remove rbf file?

This is still a problem. I noticed that this message in the log is the only
occurrence, and when it happens, install fails as described above.MSI (s)
(C0:84) [15:58:39:643]: Using source file security for destination. I'd like
to know just what this message means. MSI has installed the product, but it
is trying to remove the associated .rbf file, but it cannot.

--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Strange-log-message-and-bad-user-experience-can-t-remove-rbf-file-tp7585449p7591571.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [WIX]: ListView Control on WIX Custom UI

2013-12-27 Thread Blair Murri

I honestly don't know. Maybe there's a way to format the text of each line.

Most of my projects for almost ten years now don't use MSI's UI.

-Blair

Date: Fri, 27 Dec 2013 14:33:36 +0530
From: dileep.sanamp...@gmail.com
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] [WIX]: ListView Control on WIX Custom UI

Hi Blair,

Thank you for the information.

I have to display the Dialog UI dynamically as shown in below
'SampleDlg.jpg' file.

SampleDlg.jpghttps://docs.google.com/file/d/0B-yxrdSpoNNQVEdKWnRRU1VlbmM/edit?usp=drive_web

Is it possible to display on UI using WIX controls (not BA)?

If possible, please help me how to do this using WIX?

Thanks in advance...

On Tue, Dec 24, 2013 at 2:01 PM, Blair Murri os...@live.com wrote:

AFAIK listviews in MSI UI can only have one column + icon.

Date: Mon, 23 Dec 2013 14:52:11 +0530
From: dileep.sanamp...@gmail.com
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] [WIX]: ListView Control on WIX Custom UI

Dear All,

I want to create ListView control on WIX UI.

ListView contains 2 columns like Id, Name.

Could anyone help me on this?

Thanks in advance...

http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ListView Creation

You can do whatever UI you want with a BA in a bundle, or to a certain extend 
with an EmbeddedUI.
 
 Date: Tue, 24 Dec 2013 11:37:26 +0530
 From: wixak...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] ListView Creation
 
 Dear All,
 
 I want to create a Wix UI with ListView .
 ListView should contain the following: Name, No, pincode
 
 Any one please help me on this?
 
 Thanks in Advance...
 
 Anil
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [WIX]: ListView Control on WIX Custom UI

AFAIK listviews in MSI UI can only have one column + icon.
 
 Date: Mon, 23 Dec 2013 14:52:11 +0530
 From: dileep.sanamp...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] [WIX]: ListView Control on WIX Custom UI
 
 Dear All,
 
 I want to create ListView control on WIX UI.
 
 ListView contains 2 columns like Id, Name.
 
 Could anyone help me on this?
 
 Thanks in advance...
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Msi features control from own burn application.

Log?

 Date: Mon, 23 Dec 2013 12:34:41 +0300
 From: sergey.yuk...@visutechsystem.by
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Msi features control from own burn application.

 Hello.

 How to control features states from own burn application. I override 
 OnPlanMsiFeature method (EnableFeatureSelection=yes for target msi 
 package) and set *pRequestedState to BOOTSTRAPPER_FEATURE_STATE_LOCAL if 
 feature must be installed but can'and to 
 BOOTSTRAPPER_FEATURE_STATE_ABSENT if features must be absent. Feature 
 added successfully (property ADDLOCAL added), but removing isn't work.

 The best regards, Sergey Yukhno.

 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] TargetDir question

Extremely old documentation. This is newer:
http://wixtoolset.org/documentation/manual/v3/votive/votive_project_references.html

-Blair

From: bria...@gmail.com
Date: Mon, 23 Dec 2013 07:44:23 -0500
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] TargetDir question

I found a method to apply digital signature to a number of files before
building my MSI using the files found in MyProject/obj/Debug (or Release
based on my build preference).

When I build my MSI I have the following to include what should be the
signed file:

Component Id=LibraryDLL
File Id=LibraryDLL
Name=Library.dll
Source=$(var.Library.TargetDir)Library.dll
Vital=yes
KeyPath=yes/
/Component

After building and running the install I checked the file and it was NOT
signed. I checked the output in VS 2102 and the pre-processer variable
$(var.Library.TargetDir) is pulling the file from Library/bin/Library.dll.

I have found various references that say $(var.Library.TargetDir) should
point to Library/obj/Debug but that doesn't seem to be happening.

Am I calling this incorrectly or is the documentation incorrect? I found
the references at:
http://blogs.msdn.com/b/jrock/archive/2008/01/29/complete-list-of-candle-preprocessor-variables.aspx

Brian

If you can't explain it simply, you don't understand it well enough. -
Albert Einstein
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Adding a registry key to HKLM

In the one component it will probably be the other RegistryValue, in the other 
it will be the component's Directory
 
-Blair
 
 Date: Thu, 19 Dec 2013 13:06:06 -0800
 From: phogl...@rimage.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Adding a registry key to HKLM
 
 I don't mean to add any confusion to this thread, but I am curious.  If
 keypath=no in the above code, what is the keypath in this situation?
 
 
 

  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Where in the source does it handle the image control in the bootstrapper?

src/dutil/thmutil.cpp
 
 Date: Thu, 19 Dec 2013 14:36:30 -0800
 From: sogil...@msn.com
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Where in the source does it handle the image control in 
 the bootstrapper?
 
 Hi guys,
 
 I am using 3.7.
 
 I am trying to figure out where in the source I can change the behaviour of
 the Image:
  Image X=11 Y=11 Width=495 Height=60 ImageFile=Logo.png
 Visible=yes/
 
 to make it to back so the Title is in front:
  Text X=80 Y=11 Width=-11 Height=64 FontId=1 Visible=yes
 DisablePrefix=yes#(loc.Title)/Text
 
 I have changed the image to be a TopBanner.bmp but sometimes the title is in
 the background and I want it  to be in foreground 
 
 thanks,
 Steve
 
 
 
 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Where-in-the-source-does-it-handle-the-image-control-in-the-bootstrapper-tp7591448.html
 Sent from the wix-users mailing list archive at Nabble.com.
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn removes package it should not

Is this on XP or 2003, or on something newer?

 Date: Thu, 19 Dec 2013 23:53:54 -0500
 From: b...@joyofsetup.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Burn removes package it should not

 On 19-Dec-13 12:16, Wheeler, Blaine (DSHS/DCS) wrote:
  I expect to see the bundle install the upgraded msi and to leave the 
  unchanged package in place.  But Burn installs the upgrade and then removes 
  the unchanged package even through the InstallCondition for package #2 
  evaluates True

  From the log it looks like Burn 1.1 is triggering removal of Burn bundle 
  1.0 after installing the upgraded msi and taking out the unchanged 
  package.  It sounds like Issue #3643 but the text of the issue report 
  talks specifically about msi Upgrade table entries and not Burn
 Please post the complete Burn log. Reference counting should prevent the 
 uninstall of 1.0 from uninstalling the package.

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

 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Help passing properties to Rollback custom action.

RestoreDeprecatedFiles was scheduled right after InstallInitialize. When that 
was run during the immediate or writing the script, the 
RestoreDeprecatedFiles property didn't (yet) exist (was blank), so that is what 
gets passed to the CA. Later on you create the value, but it is never used.
 
You need to schedule SetRollbackData before RestoreDeprecatedFiles in the 
sequence. Since the values that SetRollbackData uses come from (I assume you 
are using DeleteDeprecatedFiles and not DeleteUserAdminDeprecatedFiles with the 
same attributes, based on your log) that action must come before 
SetRollbackData, which means you need that action to be After InstallInitialize 
instead of before InstallFinalize.
 
-Blair
 
 From: tyler.w.r...@accenture.com
 To: wix-users@lists.sourceforge.net
 Date: Fri, 20 Dec 2013 16:30:29 +
 Subject: [WiX-users] Help passing properties to Rollback custom action.
 
 Hello,
 
 I have a custom action that moves some deprecated files from an old 
 install to a temp directory during a major upgrade and I have another custom 
 action to move them back that runs only during roll back. I am having trouble 
 accessing the two properties set by the first custom action in my rollback 
 custom action every time I access the CustomActionData dictionary in my 
 rollback action it is empty even though in the MSI log I can clearly see it 
 got set to the proper values.
 
 Below are the custom action definitions:
 
   CustomAction 
 Id=DeleteUserAdminDeprecatedFiles BinaryKey=FileSearchCA 
 DllEntry=DeleteDeprecatedFiles Execute=immediate Return=check /
 
   CustomAction Id=RestoreDeprecatedFiles 
 BinaryKey=FileSearchCA DllEntry=RestoreDeprecatedFiles Execute=rollback 
 Return=ignore/
 
   CustomAction Id=SetRollbackData 
 Property=RestoreDeprecatedFiles 
 Value=RootDir=[DEPRECATEDFILESROOTDIR];TempDir=[DEPRECATEDTEMPORARYDIR] /
 
 Below is the scheduling of the actions:
 
  Custom Action=SetRollbackData 
 After=DeleteDeprecatedFiles
 OLD_VERSION_FOUND 
 OR
   !--Run if we are doing a major upgrade (msi - msi).--
 
 REMOVEINSTALLSHIELD
  /Custom
  Custom 
 Action=DeleteDeprecatedFiles Before=InstallFinalize
 OLD_VERSION_FOUND 
 OR
   !--Run if we are doing a major upgrade (msi - msi).--
 
 REMOVEINSTALLSHIELD   
 !--Run if we are upgrading installshield 
 instance.--
  /Custom
  Custom 
 Action=RestoreDeprecatedFiles After=InstallInitialize/
 
 Below are the relevant Log entries:
 
 MSI (s) (20:D4) [07:53:29:229]: Doing action: DeleteDeprecatedFiles
 Action 7:53:29: DeleteDeprecatedFiles.
 Action start 7:53:29: DeleteDeprecatedFiles.
 MSI (s) (20:2C) [07:53:29:237]: Invoking remote custom action. DLL: 
 C:\Windows\Installer\MSI2DDF.tmp, Entrypoint: DeleteDeprecatedFiles
 SFXCA: Extracting custom action to temporary directory: 
 C:\Windows\Installer\MSI2DDF.tmp-\
 SFXCA: Binding to CLR version v4.0.30319
 Calling custom action 
 FileSearchCA!FileSearchCA.FileSearchCA.DeleteDeprecatedFiles
 Starting UserAdmin delete deprecated files Custom Action.
 MSI (s) (20!A4) [07:53:29:413]: PROPERTY CHANGE: Adding 
 DEPRECATEDFILESROOTDIR property. Its value is 'C:\Program Files\Duck Creek 
 Technologies\ExampleUserAdmin\bin'.
 MSI (s) (20!A4) [07:53:29:417]: PROPERTY CHANGE: Adding 
 DEPRECATEDTEMPORARYDIR property. Its value is 
 'C:\Users\LMUser\AppData\Local\Temp\kg2s3d3v.vqo'.
 Action ended 7:53:29: DeleteDeprecatedFiles. Return value 1.
 MSI (s) (20:D4) [07:53:29:458]: Doing action: SetRollbackData
 Action 7:53:29: SetRollbackData.
 Action start 7:53:29: SetRollbackData.
 MSI (s) (20:D4) [07:53:29:465]: PROPERTY CHANGE: Adding 
 RestoreDeprecatedFiles property. Its value is 'RootDir=C:\Program Files\Duck 
 Creek 
 Technologies\ExampleUserAdmin\bin;TempDir=C:\Users\LMUser\AppData\Local\Temp\kg2s3d3v.vqo'.
 Action ended 7:53:29: SetRollbackData. Return value 1.
 MSI (s) (20:D4) [07:53:29:469]: Doing action: InstallFinalize
 Action 7:53:29: InstallFinalize.
 
 
 
 
 Rollback: RestoreDeprecatedFiles
 MSI (s) (20:D4) [07:55:19:904]: Executing op: 
 ActionStart(Name=RestoreDeprecatedFiles,,)
 MSI (s) (20:D4) [07:55:19:906]: Executing op: 
 CustomActionRollback(Action=RestoreDeprecatedFiles,ActionType=1345,Source

Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system

2013-12-19 Thread Blair Murri

It’s like I wrote: Windows Installer will first try to move files it intends on 
either replacing or deleting. If that succeeds, then the directory can then be 
removed (but only if empty).


Files that cannot be deleted (whether moved or not) are marked for deletion 
upon the next reboot if the transaction was successful. The mechanism for 
removing files either doesn’t support directories or Windows Installer doesn’t 
use it that way, and directories that couldn’t be removed before the reboot are 
orphaned by Windows Installer. It’s been that way for years, I’ve never seen a 
fix for it.


The only workarounds are to either only open files in such a way as to allow 
them to be either moved or deleted while they are open (executable binaries 
[DLL, EXE, etc.] are usually opened that way) or block uninstall from 
succeeding while the file is still in use, or simply accept that an empty 
directory, while not ideal, usually isn’t the end of the world. It takes 
essentially no disk space, for instance, and doesn’t generally prevent 
reinstallation from succeeding.






-Blair





From: Suvrajyoti Panda
Sent: ‎Wednesday‎, ‎December‎ ‎18‎, ‎2013 ‎8‎:‎40‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Yes it does exist after reboot as well.

On 18-12-2013 21:13, Hoover, Jacob wrote:
 Does it exist after a reboot?  I seem to remember windows installer being 
 smart enough to schedule some cleanup after reboot (if it couldn't do them 
 during uninstall).

 -Original Message-
 From: David Connet [mailto:d...@agilityrecordbook.com]
 Sent: Wednesday, December 18, 2013 8:25 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Uninstall by Installer not removing the path created 
 if that path is open on the system

 There is no way (that I know of) to delete a directory where something has an 
 open handle on that. The only way is to make sure all programs have stopped 
 and no open programs have that as their current directory.

 It's just like opening cmd.exe, cd'ing to a directory and trying to delete 
 that directory from explorer. Can't be done.

 Dave

 On 12/17/2013 10:50 PM, Suvrajyoti Panda wrote:
 Hi Phil,

 I modified the structure in my main WIX file as below:

 Directory Id='TARGETDIR' Name='SourceDir'
  Directory Id='EnergySolutionsConfig' Name=$(var.rootFolder)
  Component Id=parentOfAll
 Guid=22AD76A4-448E-41DB-85A0-A04E9774A466 KeyPath=yes
RemoveFolder Id= removeParent On=uninstall/
  /Component

 After installing i traversed to C:\Energy Solutions
 International\PFWService\config\access then uninstalled the path
 C:\Energy Solutions International\PFWService\ still exists, all the
 files are deleted though.

 On 17-12-2013 21:32, Phil Wilson wrote:
 Why not just try a RemoveFolder and see if it solves the problem?  It
 is the most likely solution, as suggested before.

 Phil Wilson


 On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda
 suvrajyo...@contata.co.in
 wrote:
 I just thought i needed to reiterate the issue for better clarity:

 Below is the directory structure in my source .wxs file:
  Directory Id='TARGETDIR' Name='SourceDir'
   Directory Id='EnergySolutionsConfig' Name=Energy Solution
 International
Directory Id='PFWServiceFolder' Name=PFWService
  Directory Id='CONFIG' Name=config
Component Id=x86RegEntPFWConfig
 Guid=5DAD9B46-43BB-42D2-91E9-F2248369AA68 Win64=no
  RegistryValue Id=x86PFWConfigRegValue Root=HKLM
 Key=SOFTWARE\[Manufacturer] Name=ConfigPath Value=[CONFIG]
 Type=string /
/Component
Component Id=x64RegEntPFWConfig
 Guid=57240178-4A44-4C6F-A11C-B4DE99573DE0 Win64=yes
  RegistryValue Id=x64PFWConfigRegValue Root=HKLM
 Key=SOFTWARE\[Manufacturer] Name=ConfigPath Value=[CONFIG]
 Type=string /
/Component
  /Directory
  /Directory
   /Directory
 /Directory

 The heat harvests directories from a location D:\Configrelease which
 has directories such as command_processors. The produces
 config.wxs file that has below structure:
 Fragment
 DirectoryRef Id=CONFIG
 Component Id=cmpC405575C36944E434C00DCE528FA79EA
 Guid={0EDAF860-B5C3-4C93-BDD7-EB1947D94749}
 File Id=fil62BA9BFC68F4D3C2DE913D9ABFEDC429
 KeyPath=yes Source=$(var.ConfigPath)\PFWConfiguration.xml /
 /Component
 Directory Id=dirB9FCE785B12AD5549EC71DC5DC66ED48
 Name=archives

 /Directory
 Directory Id=dirB8C0CFD798C8A57234B0C04A4E266B86
 Name=command_processors
 Component Id=cmpE03A5A54FF75ABF0FA6DA591BC4F3152
 Guid={F2158D98-1DC2-4348-89FC-65A2115084B6} KeyPath=yes
 CreateFolder /
 /Component

 After i run the installer, i browse to C:\Energy

Re: [WiX-users] Feature request

2013-12-17 Thread Blair Murri

After you file the feature request, please discuss it with us on wix-devs. I’m 
wondering if melt is the best place to rebase a wixpdb and I think we should 
discuss the use cases and workflows before you work on the changes.






-Blair





From: Bob Arnson
Sent: ‎Sunday‎, ‎December‎ ‎15‎, ‎2013 ‎8‎:‎51‎ ‎AM
To: General discussion for Windows Installer XML toolset.





On 12-Dec-13 14:52, Tunney, Stephen wrote:
 Can melt simply rebase the wixpdb if I were to point it to an already 
 existing melt output directory?  I basically don't want to have melt 
 re-output everything to the -x argument again.  Nothing on the help syntax 
 for 3.7 indicates a way of doing this.
It could. You can file a feature request at 
http://wixtoolset.org/issues/. Then you can send a pull request at 
https://wix.codeplex.com/sourcecontrol/list/contributions.

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


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WixFirewall CA

2013-12-17 Thread Blair Murri

That’s one of those hard ones, where we don’t know if things were different 
because that made them work or because someone messed them up. Most of the time 
it seems that it is more likely that they were changed to make them work, so 
that is what we usually err towards, but it would be perfectly reasonable to 
have a feature request to have the CA overwrite whatever may have been there 
before, as an opt-in thing.






-Blair





From: Graham Harwood
Sent: ‎Monday‎, ‎December‎ ‎16‎, ‎2013 ‎5‎:‎53‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Hi guys,

Probably a question for Bob (from reading previous mails. BTW great effort
on the release, thanks) and possibly only a point for clarification but
here goes..


My question is, what reason does the CA for the firewall not update an
application rule if one already exists?

I assumed this maybe because a setting might have been applied that we
don't want to overwrite. However, this may also be a problem in that the
install won't correct an incorrect setting.

We came across this in a scenario where a user installs a new version of
our product on Win7. The previous product used an older WiX that didn't
support profiles and so there were two rules, one for TCP and one for UDP.
It turns out the UDP rule wasn't uninstalled because it had been modified
so when the new install came along (Wix3.8, single application rule), the
install didn't insert the application rule for 'All' protocols because a
matching rule existed. The program wouldn't work over DCOM because the
application rule was still set to UDP.

Initially I thought this was because the firewall API indicates protocols
can only be updated by remove and re-add a rule to be modfied, but on
checking the WiX source for the CA it looks like it just skipped adding the
rule because it matched.

Should app rules always uninstall? Should new app rules always overwrite
any existing? Any thoughts?

Thanks
Graham
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system

2013-12-17 Thread Blair Murri

If a file being removed can’t be moved, then it will be marked for removal 
during reboot, and unfortunately the folder will then be left behind (because 
only file delete records are placed into the reboot sequence, not folders). 
After reboot there isn’t an installation left to run to cleanup any further.


Most of the time, files still in use can be moved (even if they are still 
loaded in other processes) and the folder is thus removed during the 
installation transaction (before the reboot) and the moved file is then removed 
as part of the reboot sequence.






-Blair





From: Suvrajyoti Panda
Sent: ‎Monday‎, ‎December‎ ‎16‎, ‎2013 ‎8‎:‎57‎ ‎PM
To: General discussion for Windows Installer XML toolset.





No Wesley, I have not used any create folder over here.

Regards,
SuvraJyoti

On 16-12-2013 20:03, Wesley Manning wrote:
 Did you use CreateFolder to create this directory?  If so I think you need to 
 use RemoveFolder to remove the folder.  Not sure about that though.

 -Original Message-
 From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
 Sent: December-16-13 12:37 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Uninstall by Installer not removing the path created 
 if that path is open on the system

 Hey Wesley,

 checked it on a reboot, that does not work. The structure is still there. Any 
 others suggestions guys?

 Regards,
 SuvraJyoti
 On 13-12-2013 20:13, Wesley Manning wrote:
 It might be removed on a reboot.  If you had folder open, then windows 
 installer can't uninstall it.  But I think it marks it for removal.  I know 
 for sure files have this behaviour but I'm not sure about folders.

 -Original Message-
 From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
 Sent: December-13-13 1:48 AM
 To: General discussion about the WiX toolset.
 Subject: [WiX-users] Uninstall by Installer not removing the path
 created if that path is open on the system

 Hi All,

 I just saw this behaviour. My installer creates the following :C:\Energy 
 Solutions International\PFWService\config, if this path is open and i run 
 the uninstall from control panel, then the path remains(C:\Energy Solutions 
 International\PFWService\config) although files under it is removed. Is it 
 expected behavior or incorrect. If incorrect what is the workaround for the 
 same.

 Regards,
 SuvraJyoti

 --
  Rapidly troubleshoot problems before they affect your
 business. Most IT organizations don't have a clear picture of how 
 application performance affects their revenue. With AppDynamics, you get 
 100% visibility into your Java,.NET,  PHP application. Start your 15-day 
 FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.c
 lktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 --
  Rapidly troubleshoot problems before they affect your
 business. Most IT organizations don't have a clear picture of how
 application performance affects their revenue. With AppDynamics, you
 get 100% visibility into your Java,.NET,  PHP application. Start your
 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.c
 lktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

mNo

--
Rapidly troubleshoot problems

Re: [WiX-users] Creating Registry Key

2013-12-15 Thread Blair Murri

Only with a custom action






-Blair





From: Suvrajyoti Panda
Sent: ‎Thursday‎, ‎December‎ ‎12‎, ‎2013 ‎9‎:‎51‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Hi All,

May be this is a trivial question to ask, but below is what i want to 
achieve:

I am creating registry entries as below in WIX source file:
Directory Id='TARGETDIR' Name='SourceDir'
   Directory Id='EnergySolutionsConfig' Name=Energy Solutions 
International
Directory Id='PFWServiceFolder' Name='PFWService'
  Directory Id='CONFIG' Name='config'
Component Id=x86RegEntPFWConfig 
Guid=5DAD9B46-43BB-42D2-91E9-F2248369AA68 Win64=no
  RegistryValue Id=x86PFWConfigRegValue Root=HKLM 
Key=SOFTWARE\[Manufacturer] Name=configPath *Value=[CONFIG]* 
Type=string /
  CreateFolder/
/Component
Component Id=x64RegEntPFWConfig 
Guid=57240178-4A44-4C6F-A11C-B4DE99573DE0 Win64=yes
  RegistryValue Id=x64PFWConfigRegValue Root=HKLM 
Key=SOFTWARE\[Manufacturer] Name=configPath *Value=[CONFIG]* 
Type=string /
  CreateFolder/
/Component
  /Directory
  /Directory
   /Directory
 /Directory
It creates the registry entry as :


Is it possible that the slash after config in the above path can be done 
away with and the key value is C:\Energy Solutions 
International\PFWService\config instead, or the one created is the 
correct one.

Regards,
SuvraJyoti
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] What does setting KeyPath attribute of the Component element to yes means?

2013-12-15 Thread Blair Murri

No. But directories can’t be versioned, so installation, repair and removal are 
only controlled by the component’s feature(s) state and action values and 
possibly the component’s own condition.






-Blair





From: uni
Sent: ‎Thursday‎, ‎December‎ ‎12‎, ‎2013 ‎9‎:‎16‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Hi,

 

 

In The Windows Installer's documents, It mentioned that

the Windows Installer determines whether the component's key file is
already installed before attempting to install the files of any component.
If the installer finds a file with the same name as the component's key file
installed in the target location, it compares the version, date, and
language of the two key files and uses file versioning rules to determine
whether to install the component provided by the package.

 

If the Component's KeyPath is set to yes, then the Directory of this
Component is used as the KeyPath. 

Does that means if the Directory of the Component is already exists, then
the component won't be installed?

 

Thanks,

 

Gauldoth

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Feature request

2013-12-14 Thread Blair Murri

I think rebasing a wixpdb is a great feature request. If it hasn't already been 
filed, please add one.






Blair





From: Tunney, Stephen
Sent: ‎Thursday‎, ‎December‎ ‎12‎, ‎2013 ‎11‎:‎57‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Hello all,

Ok, I finally have Pure WiX Patching working on my projects.  I have a small 
issue though.

Melting all of our RTM products takes about 35 minutes to complete.  What I 
have found is that if I zip up this collection of goodies and stick it on the 
network share ONCE, I can copy it down and I was trying to re-use that melted 
output (out folder + out pdb) for the pyro step.
But pyro complains that it cannot find the binaries in a path in the wixpdb.

The issue here really is that I'm running Jenkins in a cluster, and each node 
has a workspace root with a randomized piece, thanks to the perforce plugin.  
Not only that, some of the working drives have different drive letters, 
further complicating the issue.   This last point could be fixed by 
homogenizing the cluster but that's a lot of work.

For now, I'm simply melting the RTM installers every time, but this seems to be 
a massive waste of disk  CPU I/O.  My unzipping step for all of our 
installers takes about 11 minutes.  So the unzip process is MUCH faster.

My feature request at the end of the day is this:

Can melt simply rebase the wixpdb if I were to point it to an already 
existing melt output directory?  I basically don't want to have melt re-output 
everything to the -x argument again.  Nothing on the help syntax for 3.7 
indicates a way of doing this.

I have tried omitting the -x argument but it still takes 35 minutes to do the 
work.

Stephen Tunney
Nuance Communications, Inc.
Solutions Architect, Imaging Division
Waterloo, Ontario, Canada
stephen.tun...@nuance.commailto:stephen.tun...@nuance.com
519-880-7463  Office
NUANCE.COM
The experience speaks for itself (tm)

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to execute CA after path is applied

2013-12-07 Thread Blair Murri

Don't let the name Major Upgrade fool you. Major upgrades are the 
easiest/simplest to build/support/use way of using Windows Installer. They are 
called upgrades because a simple command upgrades the product to the newer 
version.
 
Minor and small upgrade/update are complex because they are intended to reduce 
the work Windows Installer will do to update the product, but most of the time 
a well designed major upgrade will be nearly just as efficient and will be much 
more stable.
 
Minor upgrades, small updates, and patching should always be considered 
advanced Windows Installer features. Major upgrades should be your starting 
point, and for the vast majority of products, will always be the superior 
choice.
 
-Blair
 
 Date: Fri, 6 Dec 2013 15:49:12 -0200
 From: nicolas.alva...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] How to execute CA after path is applied
 
 El viernes, 6 de diciembre de 2013, Smagin Alexander escribió:
 
  I do not want make a Major update due to it's difficult for end users.
  it's necessary to uninstall previous version and then install new one. I
  would want to run one file without special command line that make change
  only one or two files in a product. like a hot fix.
 
 
 
 A major upgrade doesn't require the user to manually uninstall the previous
 version. A major upgrade *automatically* uninstalls the previous version
 and then installs the new one. I don't see how that's difficult to end
 users.
 
 It's common to make every upgrade a major upgrade to avoid the inherent
 complexity of patching.
 
 
 -- 
 Nicolás
 --
 Sponsored by Intel(R) XDK 
 Develop, test and display web and hybrid apps with a single code base.
 Download it for free now!
 http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Define target folder and application shortcut through the command line.

2013-12-07 Thread Blair Murri

heat dir is intended to create a relocatable component group, but not the 
entire authoring. You need to tell it the identifier of the directory under 
which the root of the component group will be installed (or the identifier of 
the root directory if you specify suppressing the root directory) using the -dr 
argument. You can then add your shortcuts, etc to the produced WXS.

-Blair

 From: aybe@hotmail.com
 To: wix-users@lists.sourceforge.net
 Date: Sat, 7 Dec 2013 19:29:59 +0100
 Subject: [WiX-users] Define target folder and application shortcut through 
 the command line.

 Hi,
 Using heat.exe I would like to define the target folder where the application 
 will be installed as currently it is installed in the root folder c:\. 
 I've tried different switches such as -directoryid, -dr, -srd but without 
 much success.
 Here is my current command line :%WIX%\bin\heat dir ..\ -gg -out 
 .wxs -sfrag -cg cgtest -template product -t .xsl
 Additionally, do you know if it's possible to define a start menu group and 
 an application as well ?
 Thanks for your help !  
 --
 Sponsored by Intel(R) XDK 
 Develop, test and display web and hybrid apps with a single code base.
 Download it for free now!
 http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed

2013-12-05 Thread Blair Murri

From: http://msdn.microsoft.com/library/aa371168.aspx the meaning of the 
integer in the Root column:
 
The one missing enumeration represents either Machine and User, so 
HKey-(localMachine|currentUser) or HKMU.
 
Someone else expressed it this way: HKMU stands for either HKLM or HKCU 
depeding on setup type. 
(http://www.tech-archive.net/Archive/Visio/microsoft.public.visio.developer/2006-09/msg00048.html)
 
-Blair
 
 To: wix-users@lists.sourceforge.net
 From: d...@clearskysoftware.com
 Date: Wed, 4 Dec 2013 20:30:31 -0500
 Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 -   
 shortcuts   havechanged
 
 Thanks for info on HKMU.  I'll give it a try and suppress ICE57 on the 
 compile.
 
 Is HKMU a WiX thing or did I miss a Windows installer acronym meeting?
 
 Dave Williamson
 
 
 -Original Message-
 From: Hoover, Jacob jacob.hoo...@greenheck.com
 Sent: ‎12/‎4/‎2013 8:11 PM
 To: General discussion about the WiX toolset. 
 wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 -   shortcuts   
 havechanged
 
 HKMU is either HKLM or HKCU depending on if it's a per user or per machine 
 install.
 
   Note, I have disabled ICE57, as I am using HKMU registry resources for the 
 shortcuts. Windows Installer complains 
   about per-user data and a keypath that can be per-user or per-machine.
   
   There are numerous complaints about ICE57, the biggest from Rob M himself 
 saying they neglected to take the
   ALLUSERS property into account when creating it. While I could replace HKMU 
 with HKCU and avoid the ICE57,
   it would then leave behind these registry fragments if user A did the 
 install but user B did the uninstall.
 
 
 Ref: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE57-with-HKMU-td5795201.html
 
 -Original Message-
 From: Dave Williamson [mailto:d...@clearskysoftware.com] 
 Sent: Wednesday, December 04, 2013 6:56 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have 
 changed
 
 Yes there have been. That is why we held at 2.0 and didn't make the jump. We 
 recently ran across the issue where a msi built in 2.0 installs under program 
 files(x86) on x64 machines no matter what. So rather than beat that horse we 
 are putting the time into migrating.
 
 Dave Williamson
 Clear Sky Software
 http://www.clearskysoftware.com
 Support: 704-554-6300
 Sales: 704-568-5544
 
 
 -Original Message-
 From: Christopher Painter chr...@iswix.com
 Sent: ‎12/‎4/‎2013 7:07 PM
 To: General discussion about the WiX toolset. 
 wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net 
 wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have
 changed
 
 As I recall, there were major language changes from 2.0 to 3.0 and that 
 refactoring would be expected.  3.0 - 3.8 should generally be backwards 
 compatible though.
 
 
  From: Dave Williamson, Clear Sky Software d...@clearskysoftware.com
 Sent: Wednesday, December 04, 2013 4:50 PM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] WiX 2.0.5805.0 to WiX 3.8.1128.0 - shortcuts have changed
 
 Context is a migration of a WiX 2.0.5805.0 solution to WiX 3.8.1128.0.
 Seemed to be working through the compiler and linker errors one by one just 
 fine until I hit ICE38 regarding shortcuts.  There are 2 shortcuts created to 
 the same installed EXE.  One shortcut is in the start menu and the other is 
 on the desktop.  WiX 2.0 compiled MSIs install, uninstall, and major upgrade 
 with proper cleanup of the shortcuts just fine.  Now trying to tackle in WiX 
 3.8.
 
 error LGHT0204 : ICE38: Component component40 installs to user profile. 
 It's
 Key Path registry key must fall under HKCU.
 
 The message states that component40 installs to user profile.  Why does it 
 think that?  The directory it is within is not user specific and the overall 
 MSI is ALLUSERS=1.
 
 The following stackoverflow post looked promising but I'm not understanding 
 it yet.
 http://stackoverflow.com/questions/2058230/wix-create-non-advertised-shortcu
 
 t-for-all-users-per-machine
 
 And then another stackoverflow post
 http://stackoverflow.com/questions/17245832/wix-program-files-shortcut-for-p
 
 er-machine-install shows a shortcut as a child of the File.  But doesn't 
 really address the fact that a Directory/ needs to have a RemoveFolder/ 
 and RegistryValue/ which is HKCU.  Other posts have noted that if HKCU is 
 used then when another user uninstalls the registry entries are orphaned 
 under the other user and some state that when application is run as another 
 user it triggers a repair.  I dunno on this.  I also couldn't find what HKMU 
 was in the WiX help file or online other than Hubert Kairuki Memorial 
 University (something tells me that isn't relevant J ).
 
 Is it possible to have an ALLUSERS

Re: [WiX-users] Question about shortcuts

2013-12-05 Thread Blair Murri

Also large, complex programs place binaries in various different directories, 
so there can be no single convention as to the “install location” nor even a 
single “working directory” for those systems. As such, you are expected to 
establish your own conventions and stick to them as they apply to your project. 
The tools, which are made to scale, can’t enforce what small programs need at 
the expense of large programs.






-Blair





From: Phil Wilson
Sent: ‎Thursday‎, ‎December‎ ‎05‎, ‎2013 ‎8‎:‎05‎ ‎AM
To: General discussion for Windows Installer XML toolset.





WorkingDirectory is just a name that is closer to the name in the MSI
file's shortcut table - WkDir. It helps people see what's going on when the
names are similar, that's my assumption why they are similar.

INSTALLDIR is just a convention, TARGETDIR is the Windows Installer
directory which is the parent of this, generally the application folder
configurable by the user. As far as I recall, INSTALLDIR is just the same
id as used in the pre-Windows Installer InstallShield projects and happens
to have been used ever since. Others can be used. Because there's nothing
special about it (unless WiX wants to make it special) it's just a property
that may or may not be used, so how can it be validated?  If you don't use
INSTALLDIR, do you have a directory name for the folder where the target of
the shortcut is installed? Unless you used TARGETDIR or the files are in a
standard installer folder, there must have been a directory target defined
for the files.

Phil Wilson


On Thu, Dec 5, 2013 at 6:10 AM, keith.doug...@statcan.gc.ca wrote:

 Several of our packages use unadvertised shortcuts to point to various
 files in their installation. However, I have learned that we were setting
 the WorkingDirectory attribute wrong for them (because I had to replace
 one for an application where WorkingDirectory matters). I had followed the
 how-to in the documentation and failed to realize that INSTALLDIR was a
 user-defined constant, not a Windows Installer or WIX constant; I had
 consequently never actually defined it anywhere. Should there be a
 validation of this attribute? I now find it funny that an undefined ID will
 work here. It seems to simply put in the empty string, which is harmless,
 but ... I see WixCop does this when it is run. I guess I wonder why there,
 not in (say) light?

 Also, is there any particular reason why the attribute is called
 WorkingDirectory and the UI in Explorer uses Start In? One of my
 colleagues wondered about that.


 Keith Douglas
 Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6
 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6
 keith.doug...@statcan.gc.ca
 Telephone | Téléphone 613-951-4405
 Facsimile | Télécopieur 613-951-1966
 Government of Canada | Gouvernement du Canada




 --
 Sponsored by Intel(R) XDK
 Develop, test and display web and hybrid apps with a single code base.
 Download it for free now!

 http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [WIX]: Display UAC message while launching MSI

Windows Installer is designed to work with UAC by delaying the UAC prompt as 
long as possible. There is no way to alter that without bootstrapping the MSI.


Normally that shouldn’t matter because immediate custom actions should never be 
changing anything on the computer. It’s only an issue in the extremely few 
cases where non-elevated code cannot read something it needs access in order to 
set properties in the installation session.






-Blair





From: dileep s
Sent: ‎Tuesday‎, ‎December‎ ‎03‎, ‎2013 ‎10‎:‎46‎ ‎PM
To: General discussion for Windows Installer XML toolset.





Hi All,

How to display UAC message while launching MSI?

Currently, I am getting UAC message after Install action done in MSI.

Anyone please help me on this?

Thanks in advance...
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to compile build wix by myself

The DevBundle branch doesn’t have any of the tools that crashed for you. 
There’s no build directory created in the DevBundle branch either. It has an 
SLN file you can load into Visual Studio (if you have WiX installed already) or 
build using MSBuild (also requires WiX available) that contains just one 
WIXPROJ. Are you really sure you are actually in the DevBundle branch?


Simple way out: under src\packages, just open each folder and install what you 
find there.






-Blair





From: Smagin Alexander
Sent: ‎Tuesday‎, ‎December‎ ‎03‎, ‎2013 ‎8‎:‎08‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Blair, thank you for slarification.
But when I start building DevBundle, GenerateWixInclude.exe and docfromxsd.exe 
have crashed. 

There are exceptions which generated during building. Do you know how to fix 
them?

Sorry for russian error messages, I can translate if it's necessary.

d:\Install\Wix\DevBundle\build\debug\x86\GenerateWixInclude.exe -nologo 
custommsierrors.h d:\Install\Wix\DevBundle\build\d
ebug\inc\caerr.wxi
Необработанное исключение: System.IO.FileLoadException: Невозможно загрузить 
файл или сборку GenerateWixInclude, Version=3.0.0
.0, Culture=neutral, PublicKeyToken=36e4ce08b8ecfb17 или один из зависимых от 
них компонентов. Сбой при проверке правильности
строгого имени. (Исключение из HRESULT: 0x8013141A)
Имя файла: GenerateWixInclude, Version=3.0.0.0, Culture=neutral, 
PublicKeyToken=36e4ce08b8ecfb17 --- System.Security.Securit
yException: Сбой при проверке правильности строгого имени. (Исключение из 
HRESULT: 0x8013141A)
Ошибкой завершилась сборка со следующим параметром Zone:
MyComputer
d:\Install\Wix\DevBundle\build\debug\x86\docfromxsd.exe -out 
d:\Install\Wix\DevBundle\build\obj\debug\x86\chm\documents\xsd
..\libs\dutil\xsd\thmutil.xsd ..\tools\wix\Xsd\wix.xsd 
..\tools\wix\Xsd\wixloc.xsd ..\ext\BalExtension\wixext\Xsd\bal.x
sd ..\ext\ComPlusExtension\wixext\xsd\complus.xsd 
..\ext\DependencyExtension\wixext\Xsd\Dependency.xsd ..\ext\DifxAppExte
nsion\wixext\Xsd\difxapp.xsd 
..\ext\FirewallExtension\wixext\Xsd\firewall.xsd 
..\ext\GamingExtension\wixext\Xsd\gaming.xsd
..\ext\IIsExtension\wixext\xsd\iis.xsd 
..\ext\MsmqExtension\wixext\xsd\msmq.xsd 
..\ext\NetFxExtension\wixext\Xsd\netfx.xs
d ..\ext\PSExtension\wixext\xsd\ps.xsd 
..\ext\SqlExtension\wixext\Xsd\sql.xsd 
..\ext\TagExtension\wixext\Xsd\tag.xsd ..
\ext\UtilExtension\wixext\Xsd\util.xsd ..\ext\VSExtension\wixext\xsd\vs.xsd 
..\ext\lux\wixext\Xsd\lux.xsd
Необработанное исключение: System.IO.FileLoadException: Невозможно загрузить 
файл или сборку DocFromXsd, Version=3.0.0.0, Cult
ure=neutral, PublicKeyToken=36e4ce08b8ecfb17 или один из зависимых от них 
компонентов. Сбой при проверке правильности строгого
имени. (Исключение из HRESULT: 0x8013141A)
Имя файла: DocFromXsd, Version=3.0.0.0, Culture=neutral, 
PublicKeyToken=36e4ce08b8ecfb17 --- System.Security.SecurityExcepti
on: Сбой при проверке правильности строгого имени. (Исключение из HRESULT: 
0x8013141A)
Ошибкой завершилась сборка со следующим параметром Zone:
MyComputer  
Thanks,
Alex.

Вторник,  3 декабря 2013, 15:13 UTC от Blair Murri os...@live.com:
You will need to first install .Net Framework 3.5, recent versions of Visual 
Studio (2010 or newer), then build and install the DevBundle branch (you can 
remove the DevBundle installer if you wish, all the components it installs are 
marked permanent). If you install multiple versions of VS, it is recommended 
to install them in chronological order (personal experience) with their latest 
service packs.

Build instructions are (more-or-less) described here (the prerequisites 
described are most easily obtained by following my previous instructions):  
http://wixtoolset.org/documentation/manual/v3/wixdev/building_wix.html
 
The biggest missing piece from the above documentation pages is that 
tools\OneTimeWixBuildInitialization.proj must be built using MSBuild from an 
elevated command prompt at least once on any given build/dev box before you 
can build the rest of the toolset (otherwise you will get build errors 
starting early on). Also, it is best to build the entire toolset from the root 
of the sources (after having built that one project file elevated) before you 
descend into sub directories to work/build individual portions. Running the 
developer command prompts for Visual Studio usually isn't necessary, although 
MSBuild isn't usually in the path. You'll need the v4 MSBuild, which you can 
add your path yourself, use the developer command prompt, prepend the MSBuild 
calls with the path to the tool, or create your own alias/batch file to call 
the tool.

-Blair

From: Smagin Alexander
Sent: ‎Tuesday‎, ‎December‎ ‎03‎, ‎2013 ‎6‎:‎31‎ ‎AM
To: General discussion for Windows Installer XML toolset.

Hi people,
I want to compile wix from source code, but I didn't find any readme files 
how to comlipe wix.

Could any one give suggestions which tools are used and where I can read anout

Re: [WiX-users] [WIX]: Hiding Bootstrapper UI

Search the archives of this mail list






-Blair





From: dileep s
Sent: ‎Wednesday‎, ‎December‎ ‎04‎, ‎2013 ‎1‎:‎24‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Hi All,

How do I prevent the Bootstrapper.exe after triggering MSI?

Is there any solution to hide the Bootstrapper main UI until MSI is
progressing?

Thanks in advance...
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Splash Screen

Just curious: MSDN says that LoadBitmap() is deprecated, and to use LoadImage() 
instead. I wonder if that makes a difference with the BMP version used.


Would you mind opening a bug? I would like to test this scenario out.






-Blair





From: wdh61
Sent: ‎Tuesday‎, ‎December‎ ‎03‎, ‎2013 ‎12‎:‎43‎ ‎PM
To: General discussion for Windows Installer XML toolset.





OK, here's the real answer.  Gimp and ImageMagik output a bmp in bmp version
4 format.  ImageMagik does that as well but can also output version 3
format.  The resulting version 3 file will display in the installer.  So,
bmp splash screen files have to be version 3 format.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Splash-Screen-tp7590775p7591117.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to compile build wix by myself

I didn’t miss it. I mentioned it in the paragraph starting “The biggest missing 
piece”.


Discussing the other question should be in a different thread, but the short 
answer is: that isn’t quite the model used with burn. Query the archives of 
this list for details (I suggest using the query string “bundle”). Much was 
discussed this year. There are other bootstrappers that are closer to that 
model.






-Blair





From: Smagin Alexander
Sent: ‎Wednesday‎, ‎December‎ ‎04‎, ‎2013 ‎3‎:‎22‎ ‎AM
To: General discussion for Windows Installer XML toolset.





It was my mistake , I have tried building wix instead of the DevBundle.
I download, compile and install the DevBundle, but the errors with building wix 
are present, that I mentioned below. 

The following actions (here is the source  
http://sourceforge.net/mailarchive/message.php?msg_id=31536281 ) fix the 
problems with compilation
Build from elevated prompt once:
msbuild .\tools\OneTimeWixBuildInitialization.proj
Then you can build from unelevated. My guess is that you missed the 64-bit or 
32-bit signing validation disabling.

Now I have another question, or I should create a new thread?

How to create a simple setup.exe which just verifies some components and 
execute msi file that is placed near the setup.exe

Thanks,
Alex.

Среда,  4 декабря 2013, 9:11 UTC от Blair Murri os...@live.com:
The DevBundle branch doesn’t have any of the tools that crashed for you. 
There’s no build directory created in the DevBundle branch either. It has an 
SLN file you can load into Visual Studio (if you have WiX installed already) 
or build using MSBuild (also requires WiX available) that contains just one 
WIXPROJ. Are you really sure you are actually in the DevBundle branch?


Simple way out: under src\packages, just open each folder and install what you 
find there.

-Blair

From: Smagin Alexander
Sent: ‎Tuesday‎, ‎December‎ ‎03‎, ‎2013 ‎8‎:‎08‎ ‎AM
To: General discussion for Windows Installer XML toolset.


Blair, thank you for slarification.
But when I start building DevBundle, GenerateWixInclude.exe and docfromxsd.exe 
have crashed. 

There are exceptions which generated during building. Do you know how to fix 
them?

Sorry for russian error messages, I can translate if it's necessary.

d:\Install\Wix\DevBundle\build\debug\x86\GenerateWixInclude.exe -nologo 
custommsierrors.h d:\Install\Wix\DevBundle\build\d
ebug\inc\caerr.wxi
Необработанное исключение: System.IO.FileLoadException: Невозможно загрузить 
файл или сборку GenerateWixInclude, Version=3.0.0
.0, Culture=neutral, PublicKeyToken=36e4ce08b8ecfb17 или один из зависимых от 
них компонентов. Сбой при проверке правильности
строгого имени. (Исключение из HRESULT: 0x8013141A)
Имя файла: GenerateWixInclude, Version=3.0.0.0, Culture=neutral, 
PublicKeyToken=36e4ce08b8ecfb17 --- System.Security.Securit
yException: Сбой при проверке правильности строгого имени. (Исключение из 
HRESULT: 0x8013141A)
Ошибкой завершилась сборка со следующим параметром Zone:
MyComputer
d:\Install\Wix\DevBundle\build\debug\x86\docfromxsd.exe -out 
d:\Install\Wix\DevBundle\build\obj\debug\x86\chm\documents\xsd
..\libs\dutil\xsd\thmutil.xsd ..\tools\wix\Xsd\wix.xsd 
..\tools\wix\Xsd\wixloc.xsd ..\ext\BalExtension\wixext\Xsd\bal.x
sd ..\ext\ComPlusExtension\wixext\xsd\complus.xsd 
..\ext\DependencyExtension\wixext\Xsd\Dependency.xsd ..\ext\DifxAppExte
nsion\wixext\Xsd\difxapp.xsd 
..\ext\FirewallExtension\wixext\Xsd\firewall.xsd 
..\ext\GamingExtension\wixext\Xsd\gaming.xsd
..\ext\IIsExtension\wixext\xsd\iis.xsd 
..\ext\MsmqExtension\wixext\xsd\msmq.xsd 
..\ext\NetFxExtension\wixext\Xsd\netfx.xs
d ..\ext\PSExtension\wixext\xsd\ps.xsd 
..\ext\SqlExtension\wixext\Xsd\sql.xsd 
..\ext\TagExtension\wixext\Xsd\tag.xsd ..
\ext\UtilExtension\wixext\Xsd\util.xsd ..\ext\VSExtension\wixext\xsd\vs.xsd 
..\ext\lux\wixext\Xsd\lux.xsd
Необработанное исключение: System.IO.FileLoadException: Невозможно загрузить 
файл или сборку DocFromXsd, Version=3.0.0.0, Cult
ure=neutral, PublicKeyToken=36e4ce08b8ecfb17 или один из зависимых от них 
компонентов. Сбой при проверке правильности строгого
имени. (Исключение из HRESULT: 0x8013141A)
Имя файла: DocFromXsd, Version=3.0.0.0, Culture=neutral, 
PublicKeyToken=36e4ce08b8ecfb17 --- System.Security.SecurityExcepti
on: Сбой при проверке правильности строгого имени. (Исключение из HRESULT: 
0x8013141A)
Ошибкой завершилась сборка со следующим параметром Zone:
MyComputer 
Thanks,
Alex.

Вторник,  3 декабря 2013, 15:13 UTC от Blair Murri  os...@live.com :
You will need to first install .Net Framework 3.5, recent versions of Visual 
Studio (2010 or newer), then build and install the DevBundle branch (you can 
remove the DevBundle installer if you wish, all the components it installs 
are marked permanent). If you install multiple versions of VS, it is 
recommended to install them in chronological order (personal experience) with 
their latest service packs.

Build instructions are (more-or-less) described here

Re: [WiX-users] Some questions about CostFinalize. It spends too much time.

You can’t skip CostFinalize, but if you don’t use the “built-in” Windows 
Installer UI, you can skip the “UI sequence” (by doing your UI outside of MSI, 
say in a bootstrapper).


Windows Installer is a declarative, transactional system, and it compares your 
desired state against the system’s current state in order to generate a “plan” 
of what needs to be reinstalled vs. what should be left alone as well as how to 
rollback from any application failures. That discovery time is what you are 
seeing, and is the “tax” from all the stability goodness that Windows Installer 
gives you.






-Blair





From: mailc...@163.com
Sent: ‎Wednesday‎, ‎December‎ ‎04‎, ‎2013 ‎3‎:‎21‎ ‎AM
To: General discussion for Windows Installer XML toolset.






Hi all，
I have a problem with wix.
There are about 3000 files in my msi and it is about 500M. When I run it at 
first time, it is quickly. But if the program was already installed in the 
computer, when I run another msi (the same msi, but build again) it will spend 
too much time on the prepare dialog. It shows Please wait while the setip 
wizard prepares to guide you through the installation.  Computing space 
requirements.  and the next button is disabled. It is about more than one 
minute!!
I get the setup log. It shows CostFinalize action spend about more than one 
minute to scan the files in the disk .
The msi sdk said:
The CostFinalize action must be executed before starting any user interface 
sequence which allows the user to view or modify Feature table selections or 
directories.

So, can i skip this step or CostFinalize action do not spend so much time??


Thanks.
Cyan



mailc...@163.com
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Deferred CustomAction Impersonate=y/n / vs. elevation

2013-12-03 Thread Blair Murri

msidbCustomActionTypeNoImpersonate in the Type column of the CustomAction table.
 
http://msdn.microsoft.com/library/aa368069.aspx
 
-Blair
 
 Date: Tue, 3 Dec 2013 07:43:08 -0500
 From: yellowjacketl...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Deferred CustomAction Impersonate=y/n / vs.  
 elevation
 
 Thanks.
 
 What flag/option get set in Windows Installer tables when @Impersonate is
 set to 'no'?
 
 
 On Mon, Dec 2, 2013 at 11:35 PM, Blair Murri os...@live.com wrote:
 
  @Impersonate='yes' is the default, so you do need to turn off
  impersonation by explicitly saying no.
 
  -Blair
 
   Date: Mon, 2 Dec 2013 15:32:58 -0500
   From: yellowjacketl...@gmail.com
   To: wix-users@lists.sourceforge.net
   Subject: [WiX-users] Deferred CustomAction Impersonate=y/n / vs.
   elevation
  
   I have a deferred custom action that is failing **UNLESS** I launch the
   install Run as Administrator.  Any ideas why this is happening?
  
   Package InstallerVersion=500 InstallPrivileges=elevated .../
  
   CustomAction Id=CustomInstall Execute=deferred Return=check
   DllEntry=Install  BinaryKey=MyCustomActions /
  
   InstallExecuteSequence
 ...
 Custom Action=CustomInstall Before=InstallServicesNOT
   Installed/Custom
 ...
   /InstallExecuteSequence
  
  
   Do I need to add the 'Impersonate=no' attribute to make this work (is
   _assume_ yes is the default)?
  
   From the logs...
  
   ...
   MSI (c) (D4:60) [19:24:20:051]: Machine policy value 'DisableMsi' is 1
   MSI (c) (D4:60) [19:24:20:051]: Machine policy value
   'AlwaysInstallElevated' is 0
   MSI (c) (D4:60) [19:24:20:051]: User policy value 'AlwaysInstallElevated'
   is 0
   MSI (c) (D4:60) [19:24:20:051]: Running product
   '{BACFF966-3CEF-4CD7-BE12-D8F6D89D2BE3}' with user privileges. DisableMsi
   policy is set to or defaulted to 1. This is the client and the user does
   not have full admin token. Evaulation is delayed until after credentials
   provided. This install could still be blocked
   ...
   MSI (c) (D4:60) [19:24:20:067]: Note: 1: 2262 2: AdminProperties 3:
   -2147287038
   MSI (c) (D4:60) [19:24:20:067]: Machine policy value
   'AlwaysInstallElevated' is 0
   MSI (c) (D4:60) [19:24:20:067]: User policy value 'AlwaysInstallElevated'
   is 0
   MSI (c) (D4:60) [19:24:20:067]: Running product
   '{BACFF966-3CEF-4CD7-BE12-D8F6D89D2BE3}' with user privileges. DisableMsi
   policy is set to or defaulted to 1. This is the client and the user does
   not have full admin token. Evaulation is delayed until after credentials
   provided. This install could still be blocked
   ...
   MSI (s) (D8:88) [19:24:24:247]: MSI_LUA: Credential Request return = 0x0
   MSI (s) (D8:88) [19:24:24:247]: MSI_LUA: Elevated credential consent
   provided. Install will run elevated
   ...
   MSI (s) (D8:88) [19:24:24:247]: Note: 1: 2262 2: AdminProperties 3:
   -2147287038
   MSI (s) (D8:88) [19:24:24:247]: Machine policy value
   'AlwaysInstallElevated' is 0
   MSI (s) (D8:88) [19:24:24:247]: User policy value 'AlwaysInstallElevated'
   is 0
   MSI (s) (D8:88) [19:24:24:247]: Product installation will be elevated
   because user provided elevated credentials and product is being installed
   per-machine.
   MSI (s) (D8:88) [19:24:24:247]: Running product
   '{BACFF966-3CEF-4CD7-BE12-D8F6D89D2BE3}' with elevated privileges:
  Product
   is assigned.
   ...
   MSI (s) (D8:88) [19:24:24:310]: MSI_LUA: Setting AdminUser property to 1
   because this is the client or the user has already permitted elevation
   MSI (s) (D8:88) [19:24:24:310]: PROPERTY CHANGE: Adding AdminUser
  property.
   Its value is '1'.
   MSI (s) (D8:88) [19:24:24:310]: MSI_LUA: Setting MsiRunningElevated
   property to 1 because the install is already running elevated.
   MSI (s) (D8:88) [19:24:24:310]: PROPERTY CHANGE: Adding
  MsiRunningElevated
   property. Its value is '1'.
   MSI (s) (D8:88) [19:24:24:310]: PROPERTY CHANGE: Adding Privileged
   property. Its value is '1'.
   ...
   Action 19:24:25: CustomInstall.
   MSI (s) (D8:88) [19:24:25:261]: Executing op:
  
  CustomActionSchedule(Action=CustomInstall,ActionType=1025,Source=BinaryData,Target=Install,CustomActionData=CERTPROPERTY=*.
   mydomain.net;)
   MSI (s) (D8:88) [19:24:25:261]: Creating MSIHANDLE (51) of type 790536
  for
   thread 4488
   MSI (s) (D8:E8) [19:24:25:261]: Invoking remote custom action. DLL:
   C:\Windows\Installer\MSIBD8F.tmp, Entrypoint: Install
   MSI (s) (D8!F4) [19:24:25:277]: Creating MSIHANDLE (52) of type 790531
  for
   thread 1268
   SFXCA: Extracting custom action to temporary directory:
   C:\Users\SomeUser\AppData\Local\Temp\MSIBD8F.tmp-\
   MSI (s) (D8!F4) [19:24:25:277]: Closing MSIHANDLE (52) of type 790531 for
   thread 1268
   MSI (s) (D8!F4) [19:24:25:308]: Creating MSIHANDLE (53) of type 790531
  for
   thread 1268
   SFXCA: Binding to CLR version v4.0.30319
   ...
   19:24:25.464--MSI.Install -- Exception
  System.ComponentModel.Win32Exception

Re: [WiX-users] How to compile build wix by myself

2013-12-03 Thread Blair Murri

You will need to first install .Net Framework 3.5, recent versions of Visual 
Studio (2010 or newer), then build and install the DevBundle branch (you can 
remove the DevBundle installer if you wish, all the components it installs are 
marked permanent). If you install multiple versions of VS, it is recommended 
to install them in chronological order (personal experience) with their latest 
service packs.

Build instructions are (more-or-less) described here (the prerequisites 
described are most easily obtained by following my previous instructions): 
http://wixtoolset.org/documentation/manual/v3/wixdev/building_wix.html
 
The biggest missing piece from the above documentation pages is that 
tools\OneTimeWixBuildInitialization.proj must be built using MSBuild from an 
elevated command prompt at least once on any given build/dev box before you can 
build the rest of the toolset (otherwise you will get build errors starting 
early on). Also, it is best to build the entire toolset from the root of the 
sources (after having built that one project file elevated) before you descend 
into sub directories to work/build individual portions. Running the developer 
command prompts for Visual Studio usually isn't necessary, although MSBuild 
isn't usually in the path. You'll need the v4 MSBuild, which you can add your 
path yourself, use the developer command prompt, prepend the MSBuild calls with 
the path to the tool, or create your own alias/batch file to call the tool.






-Blair





From: Smagin Alexander
Sent: ‎Tuesday‎, ‎December‎ ‎03‎, ‎2013 ‎6‎:‎31‎ ‎AM
To: General discussion for Windows Installer XML toolset.





Hi people,
I want to compile wix from source code, but I didn't find any readme files how 
to comlipe wix.

Could any one give suggestions which tools are used and where I can read anout 
it?

Thanks,
Alex.

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] wixtoolset.org popups

2013-12-03 Thread Blair Murri

I saw them yesterday as well. I’m not seeing them this morning, though.






-Blair





From: Christopher Painter
Sent: ‎Tuesday‎, ‎December‎ ‎03‎, ‎2013 ‎6‎:‎28‎ ‎AM
To: General discussion for Windows Installer XML toolset., General discussion 
for Windows Installer XML toolset.







I don't see it in Chrome but I do see it in IE.   I see it on multiple 
computers including clean snapshotted VM's so I don't think I'm infected on 
my end. 

At this point I'm thinking either this is intentional or the site has been 
hacked.   


 From: John Ludlow john.ludlow...@gmail.com
Sent: Tuesday, December 03, 2013 8:17 AM
To: General discussion about the WiX toolset. 
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] wixtoolset.org popups

I'm not seeing any adverts. On Chrome I do have AdBlockerPlus, but it
didn't report a blocked popup, and when I disabled it and refreshed I
didn't see anything.

Of course, it might be that you're hitting a different server than I am.

On 3 December 2013 13:44, Christopher Painter chr...@iswix.com wrote:


 Is anyone else getting popup advertisements on wixtoolset.org?
 Advertisements from infinityads are what I'm seeing.


 

--
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into 
your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of 
AppDynamics
 Pro!
 
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk


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


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 

Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics 
Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk


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

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Fwd: Getting error notification when running .msi Installer

Was your command prompt elevated? Do you need to make your custom action 
deferred with impersonation turned off?
 
-Blair
 
 Date: Mon, 2 Dec 2013 19:53:13 +0530
 From: suvrajyo...@contata.co.in
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Fwd: Getting error notification when running .msi
 Installer
 
 
 Please let me know if someone has any idea on this.
 
  Original Message 
 Subject:  Getting error notification when running .msi Installer
 Date: Mon, 02 Dec 2013 11:02:25 +0530
 From: Suvrajyoti Panda suvrajyo...@contata.co.in
 To:   General discussion about the WiX toolset. 
 wix-users@lists.sourceforge.net
 
 
 
 Hi All,
 
 I have created a .msi installer using WIX. When i execute the installer 
 through command line it installs the application without any error 
 messages but when it i do it through clicking the setup that gets 
 created: MyWebSetup.msi, i am getting the below error message. There is 
 no error that gets logged in the log file though. I am not able to see 
 errors in the log file as well.
 
 
 When i looked into the event viewer i am seeing this message below:Product:
 /Pipeline Framework Service Client -- Error 1722. There is a problem 
 with this Windows Installer package. A program run as part of the setup 
 did not finish as expected. Contact your support personnel or package 
 vendor. Action MakeWepApp40, location: 
 C:\EnergySolutionsInternational\PipelineFrameworkService\PFWWebSite\, 
 command: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe 
 -norestart -s W3SVC/1/ROOT/PFWServiceApplication /
 
 And in my product.wxs file i have the below entries:
 !-- .NET Framework 3.0 SP 1 must be installed --
  Property Id=FRAMEWORKBASEPATH
  RegistrySearch Id=FindFrameworkDir Root=HKLM 
 Key=SOFTWARE\Microsoft\.NETFramework Name=InstallRoot Type=raw/
  /Property
 
  Property Id=ASPNETREGIIS 
  DirectorySearch Path=[FRAMEWORKBASEPATH] Depth=4 
 Id=FindAspNetRegIis
  FileSearch Name=aspnet_regiis.exe MinVersion=4.0.0/
  /DirectorySearch
  /Property
 
  !-- Switch ASP.NET to version 4.0 --
CustomAction Id=MakeWepApp40 Directory=MYWEBWEBSITE 
 ExeCommand=[ASPNETREGIIS] -norestart -s W3SVC/1/ROOT/[WEB_APP_NAME]  
 Return=check
  Not Installed
/CustomAction
 
  InstallExecuteSequence
  Custom Action=MakeWepApp40 
 After=InstallFinalizeASPNETREGIIS AND NOT Installed/Custom
  /InstallExecuteSequence
 
  !-- Specify UI --
 
  UIRef Id=MyWebUI /
 
 I am not able to figure here though what the problem is. Could you guys 
 please help me on this, i am stuck here. Please let me know if any other 
 input is required.
 
 Regards,
 SuvraJyoti
 
 
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [WIX]: How to trigger my MSI file when I select install option in Wix Custom Bootstrapper UI

Create a couple of methods and add them to your .def file. The protototypes of 
them are as follows:


extern C HRESULT WINAPI BootstrapperApplicationCreate(
__in IBootstrapperEngine* pEngine,
__in const BOOTSTRAPPER_COMMAND* pCommand,
__out IBootstrapperApplication** ppApplication
);


extern C void WINAPI BootstrapperApplicationDestroy();

and your .def file should name them the same (so they don’t get decorated) upon 
export.




You return your BA class instance in the ppApplication argument, and you use 
the pEngine argument to call the engine.


-Blair






From: Nicolás Alvarez
Sent: ‎Monday‎, ‎December‎ ‎02‎, ‎2013 ‎9‎:‎35‎ ‎AM
To: General discussion for Windows Installer XML toolset.





2013/12/2 dileep s dileep.sanamp...@gmail.com:
 On Mon, Dec 2, 2013 at 1:21 PM, Blair Murri os...@live.com wrote:
 I was referring to the code in SampleDLL.dll. I assume you are not
 creating your UI in DllMain(). There is a method that you export where your
 UI is created that Burn calls.

 Hi Blair,

 The following code is in SampleDLL.dll
 DLL Main() in c++ custom action project:

 switch(ulReason)
 {
 Case DLL_PROCESS_ATTACH:
 {
   int ret = ::DialogBoxParam(hInst, MAKEINTRESOURCE(IDD_DIALOG1), 0,
 DlgProc,0);
 }

 break;

 }

I never even used Burn, but from Blair's message, I guess that's your
problem: you're starting your UI from DllMain. You should instead
create your UI from IBootstrapperApplication::OnStartup which Burn
will call at the correct moment. See
http://wixtoolset.org/documentation/manual/v3/bundle/ba/bootstrapper_application_interface.html

Interestingly, I searched for 'DllMain' on the web and the second
result was a blog post titled Don’t do anything in DllMain… Please

-- 
Nicolás

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Signing bundles - changes needed to each bundle wixproj

I don’t believe there’s a preference to one over the other. Each has its own 
costs and risks. Whichever works better in your environment. MSBuild is 
flexible in that regard. (What I do with my clients tends to vary based on the 
client’s needs and customs).






-Blair





From: John Ludlow
Sent: ‎Monday‎, ‎December‎ ‎02‎, ‎2013 ‎9‎:‎49‎ ‎AM
To: General discussion for Windows Installer XML toolset.





I see - that was the impression I got from the documentation, but I tend to
prefer to stay out of those because any changes to the .wixprojs are
relatively hidden, and we'd have to do the change for each bundle .wixproj
(and probably each MSI .wixproj). Given the hidden nature, it's easy to
forget (and more than a little cumbersome to implement each change).

We could partially solve this using tools to mandate that this change was
done before checkin, but we'd have to write a check for that tool. It's not
difficult, but if we don't need to do it then we'd rather not. Similarly,
we could write tools to auto-fix this - again, not difficult, but if we
don't need to do it then we'd rather not.

Ideally, however, the wix targets that come out of the box would have this
already.

I was wondering whether there's a reason why editing the .wixproj is
preferred over CustomAfterWixTargets. If Visual Studio did a better job of
exposing the underlying msbuild code then I'd just tweak the .msbuild file,
but given how cumbersome it is, I'd rather avoid this if I can help it.




On 2 December 2013 16:52, Rob Mensching r...@robmensching.com wrote:

 You could do that. I tend to add an explicit .props/.targets file to the
 .wixprojs myself but you have options with MSBuild.

 Documentation improvements are always appreciated.

 -Original Message-
 From: John Ludlow [mailto:john.ludlow...@gmail.com]
 Sent: Monday, December 2, 2013 8:07 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Signing bundles - changes needed to each bundle
 wixproj

 Hi Rob,

 How would this be invoked from the build? Your message prompted some
 digging, and I found CustomAfterWixTargets. Would you recommend setting
 this to the path to my own msbuild .targets file, and providing the SignXXX
 targets in there?

 I tried this and it seemed to work.

 If this is best practice, it would be worth updating the documentation to
 this effect.


 On 2 December 2013 14:52, Rob Mensching r...@robmensching.com wrote:

  Generally, I've seen people use the instructions to check the WiX
  toolset into their build process and provide a standard
  .props/.targets file for encapsulating all the custom logic for their
 build.
 
  -Original Message-
  From: John Ludlow [mailto:john.ludlow...@gmail.com]
  Sent: Monday, December 2, 2013 4:23 AM
  To: General discussion for Windows Installer XML toolset.
  Subject: [WiX-users] Signing bundles - changes needed to each bundle
  wixproj
 
  Hi,
 
  We're writing an installer using a bundle to chain two MSIs together.
  The bundle should be signed (we generally sign installers and EXEs and
 DLLs).
  Currently, we're using WiX 3.6 (we currently use Visual Studio 2008,
  and
  3.7 didn't support that version of Visual Studio).
 
  We've discovered the 0x80004005 error described here:
 
  http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-3-7-
  Burn-error-0x80004005-Failed-to-extract-all-files-from-container-td758
  7152.html
 
  However, the fix for this seems to be to tweak the project files. This
  is not a preferred solution for us, as over the next year we will be
  creating a significant number of these as we adopt this technology for
  some of our existing installers. Since any tweaks to the projects are
  hidden (they require right clicking the project, choosing Edit... and
  effectively unloading the project from the solution). We'd have to
  remember to do that each time we create a bundle, and I'd rather not
 have that point of failure.
 
  I'm planning on using insignia.exe to extract engine.exe, sign it and
  then import it. However, it's been suggested this is also less than
  ideal (though it's better than having to remember to tweak a project
 file).
 
  I was wondering whether this is improved in later versions of WiX. I
  imagine it would be pretty simple for WiX to include this
  functionality in the default .wixproj project template, meaning we
  don't have to remember to do it ourselves. If this is the case, would
 this also support timestamping?
 
  Or are there any other inventive solutions for solving this issue?
 
  Thanks
 
  John
 
  --
   Rapidly troubleshoot problems before they affect your
  business. Most IT organizations don't have a clear picture of how
  application performance affects their revenue. With AppDynamics, you
  get 100% visibility into your Java,.NET,  PHP application. Start your
  15-day FREE TRIAL of AppDynamics Pro!
  http

Re: [WiX-users] UI Tricks - Double Dialog still required? :(

tab a lot?
 
dividing controls across dialogs is the only solution I know of...
 
 From: stephen.tun...@nuance.com
 To: wix-users@lists.sourceforge.net
 Date: Mon, 2 Dec 2013 17:58:15 +
 Subject: [WiX-users] UI Tricks - Double Dialog still required? :(
 
 Hey guys,
 
 Just got myself into a bit of an issue here where the publish and condition 
 values for controls are not evaluated until control focus has changed within 
 an MSI UI.
 
 Other than the dreaded double dialog fix, is there anything else I can do?
 
 Background:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/UI-Edit-Box-not-updating-td5077648.html
 double dialog fix proposed here:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Combobox-not-refreshing-td1511419.html#a1513311
 
 Thanks guys,
 Stephen
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Deferred CustomAction Impersonate=y/n / vs. elevation

@Impersonate='yes' is the default, so you do need to turn off impersonation 
by explicitly saying no.
 
-Blair
 
 Date: Mon, 2 Dec 2013 15:32:58 -0500
 From: yellowjacketl...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Deferred CustomAction Impersonate=y/n / vs.  
 elevation
 
 I have a deferred custom action that is failing **UNLESS** I launch the
 install Run as Administrator.  Any ideas why this is happening?
 
 Package InstallerVersion=500 InstallPrivileges=elevated .../
 
 CustomAction Id=CustomInstall Execute=deferred Return=check
 DllEntry=Install  BinaryKey=MyCustomActions /
 
 InstallExecuteSequence
   ...
   Custom Action=CustomInstall Before=InstallServicesNOT
 Installed/Custom
   ...
 /InstallExecuteSequence
 
 
 Do I need to add the 'Impersonate=no' attribute to make this work (is
 _assume_ yes is the default)?
 
 From the logs...
 
 ...
 MSI (c) (D4:60) [19:24:20:051]: Machine policy value 'DisableMsi' is 1
 MSI (c) (D4:60) [19:24:20:051]: Machine policy value
 'AlwaysInstallElevated' is 0
 MSI (c) (D4:60) [19:24:20:051]: User policy value 'AlwaysInstallElevated'
 is 0
 MSI (c) (D4:60) [19:24:20:051]: Running product
 '{BACFF966-3CEF-4CD7-BE12-D8F6D89D2BE3}' with user privileges. DisableMsi
 policy is set to or defaulted to 1. This is the client and the user does
 not have full admin token. Evaulation is delayed until after credentials
 provided. This install could still be blocked
 ...
 MSI (c) (D4:60) [19:24:20:067]: Note: 1: 2262 2: AdminProperties 3:
 -2147287038
 MSI (c) (D4:60) [19:24:20:067]: Machine policy value
 'AlwaysInstallElevated' is 0
 MSI (c) (D4:60) [19:24:20:067]: User policy value 'AlwaysInstallElevated'
 is 0
 MSI (c) (D4:60) [19:24:20:067]: Running product
 '{BACFF966-3CEF-4CD7-BE12-D8F6D89D2BE3}' with user privileges. DisableMsi
 policy is set to or defaulted to 1. This is the client and the user does
 not have full admin token. Evaulation is delayed until after credentials
 provided. This install could still be blocked
 ...
 MSI (s) (D8:88) [19:24:24:247]: MSI_LUA: Credential Request return = 0x0
 MSI (s) (D8:88) [19:24:24:247]: MSI_LUA: Elevated credential consent
 provided. Install will run elevated
 ...
 MSI (s) (D8:88) [19:24:24:247]: Note: 1: 2262 2: AdminProperties 3:
 -2147287038
 MSI (s) (D8:88) [19:24:24:247]: Machine policy value
 'AlwaysInstallElevated' is 0
 MSI (s) (D8:88) [19:24:24:247]: User policy value 'AlwaysInstallElevated'
 is 0
 MSI (s) (D8:88) [19:24:24:247]: Product installation will be elevated
 because user provided elevated credentials and product is being installed
 per-machine.
 MSI (s) (D8:88) [19:24:24:247]: Running product
 '{BACFF966-3CEF-4CD7-BE12-D8F6D89D2BE3}' with elevated privileges: Product
 is assigned.
 ...
 MSI (s) (D8:88) [19:24:24:310]: MSI_LUA: Setting AdminUser property to 1
 because this is the client or the user has already permitted elevation
 MSI (s) (D8:88) [19:24:24:310]: PROPERTY CHANGE: Adding AdminUser property.
 Its value is '1'.
 MSI (s) (D8:88) [19:24:24:310]: MSI_LUA: Setting MsiRunningElevated
 property to 1 because the install is already running elevated.
 MSI (s) (D8:88) [19:24:24:310]: PROPERTY CHANGE: Adding MsiRunningElevated
 property. Its value is '1'.
 MSI (s) (D8:88) [19:24:24:310]: PROPERTY CHANGE: Adding Privileged
 property. Its value is '1'.
 ...
 Action 19:24:25: CustomInstall.
 MSI (s) (D8:88) [19:24:25:261]: Executing op:
 CustomActionSchedule(Action=CustomInstall,ActionType=1025,Source=BinaryData,Target=Install,CustomActionData=CERTPROPERTY=*.
 mydomain.net;)
 MSI (s) (D8:88) [19:24:25:261]: Creating MSIHANDLE (51) of type 790536 for
 thread 4488
 MSI (s) (D8:E8) [19:24:25:261]: Invoking remote custom action. DLL:
 C:\Windows\Installer\MSIBD8F.tmp, Entrypoint: Install
 MSI (s) (D8!F4) [19:24:25:277]: Creating MSIHANDLE (52) of type 790531 for
 thread 1268
 SFXCA: Extracting custom action to temporary directory:
 C:\Users\SomeUser\AppData\Local\Temp\MSIBD8F.tmp-\
 MSI (s) (D8!F4) [19:24:25:277]: Closing MSIHANDLE (52) of type 790531 for
 thread 1268
 MSI (s) (D8!F4) [19:24:25:308]: Creating MSIHANDLE (53) of type 790531 for
 thread 1268
 SFXCA: Binding to CLR version v4.0.30319
 ...
 19:24:25.464--MSI.Install -- Exception System.ComponentModel.Win32Exception
 (0x80004005): Binding failed, see log file for details
 ...
 
 
 
 -- 
 Tony
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Signing bundles - changes needed to each bundle wixproj

At one time at MSFT (don't know if it is still the case) the machine that did 
codesigning for (most? all?) teams worldwide was solely located in (IIRC) 
Puerto Rico, and the files had to be securely electronically transported there, 
signed, and securely transported back, by a system owned by the group managing 
production signing (despite most build servers being in Redmond, Washington). 
Direct access to the signtool tool wasn't of any use in that case.
 
At my current client, there is no official signing in any build leg that 
developers have direct access to. You tell them where your files are and they 
sign them. They sign everything before the packaging step of the build, but 
they have to script signing things that are contained by other things built 
during packaging, like external cabs any everything we stick into a bundle.
 
Seems like everyone does it differently. Maybe we should take a poll to see if 
there is any one majority way that we could optimize for, but even inside of 
MSFT it had to be done differently for production signing and internal 
only-test signing.
 
-Blair
 
 Date: Mon, 2 Dec 2013 22:08:16 +
 From: john.ludlow...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Signing bundles - changes needed to each bundle  
 wixproj
 
 Fair enough. I guess we have it set up quite simply - a cert in a folder on
 the file server with restricted access. This is imported into the
 certificate store on the build machine by the build and selected by sha1
 hash when calling signtool. We also timestamp.
 
 Therefore simply providing a path to signtool, the sha1 and the
 timestamping url via properties would work for us - that seems like a
 sensible default which could be overridden
 
 Thanks
 On 2 Dec 2013 18:24, Rob Mensching r...@robmensching.com wrote:
 
  My experience is that you really want your private key under lock and key.
  I heard the room with the private key at MSFT had a hand print reader. Even
  the WiX toolset submits our binaries off to a signing service to get
  signed. Never saw two organizations implement signing the same way. sigh/
 
  -Original Message-
  From: John Ludlow [mailto:john.ludlow...@gmail.com]
  Sent: Monday, December 2, 2013 10:09 AM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] Signing bundles - changes needed to each bundle
  wixproj
 
  I suppose that's a good point, Rob - there's lots of ways to sign stuff.
  We tend to go to the signtool method (actually a specific version of
  signtool for reasons I can't remember) and I kind of figured that would be
  the
  (ahem) generically preferred method of signing things that WiX cares about.
 
  Anyway, thanks for your help.
 
 
  On 2 December 2013 17:59, Rob Mensching r...@robmensching.com wrote:
 
   Ditto.
  
   And if you come up with a way to set these targets by default
   correctly for the multitude of ways for signing binaries, we'd love to
   discuss it on wix-devs.
  
   -Original Message-
   From: Blair Murri [mailto:os...@live.com]
   Sent: Monday, December 2, 2013 9:53 AM
   To: General discussion for Windows Installer XML toolset.
   Subject: Re: [WiX-users] Signing bundles - changes needed to each
   bundle wixproj
  
   I don't believe there's a preference to one over the other. Each has
   its own costs and risks. Whichever works better in your environment.
   MSBuild is flexible in that regard. (What I do with my clients tends
   to vary based on the client's needs and customs).
  
  
  
  
  
  
   -Blair
  
  
  
  
  
   From: John Ludlow
   Sent: Monday, December 02, 2013 9:49 AM
   To: General discussion for Windows Installer XML toolset.
  
  
  
  
  
   I see - that was the impression I got from the documentation, but I
   tend to prefer to stay out of those because any changes to the
   .wixprojs are relatively hidden, and we'd have to do the change for
   each bundle .wixproj (and probably each MSI .wixproj). Given the
   hidden nature, it's easy to forget (and more than a little cumbersome to
  implement each change).
  
   We could partially solve this using tools to mandate that this change
   was done before checkin, but we'd have to write a check for that tool.
   It's not difficult, but if we don't need to do it then we'd rather
   not. Similarly, we could write tools to auto-fix this - again, not
   difficult, but if we don't need to do it then we'd rather not.
  
   Ideally, however, the wix targets that come out of the box would have
   this already.
  
   I was wondering whether there's a reason why editing the .wixproj is
   preferred over CustomAfterWixTargets. If Visual Studio did a better
   job of exposing the underlying msbuild code then I'd just tweak the
   .msbuild file, but given how cumbersome it is, I'd rather avoid this if
  I can help it.
  
  
  
  
   On 2 December 2013 16:52, Rob Mensching r...@robmensching.com wrote:
  
You could do that. I tend to add an explicit .props

Re: [WiX-users] Help migrating Serial number during upgrade

Another way is to set the @Execute attribute of the CustomAction element to the 
value firstSequence. Then you don't need to condition it nor create additional 
source files.

 Date: Tue, 3 Dec 2013 13:43:22 +1100
 From: goodridge@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Help migrating Serial number during upgrade

 To have it in both but execute once, a yourself tool is an include file in
 both sequences. You'll probably find there are other CA that should just be
 executed the once e.g.
  ?include SharedExecuteActions.wxi ?

 Then in SharedExecuteActions.wxi place a CA that has the condition NOT
 SECONDSEQUENCE so it is only executed once:
Custom Action=MyCA Before=FindRelatedProducts
   ![CDATA[NOT SECONDSEQUENCE]]
/Custom

 warm regards

 Rob Goodridge

 On Tue, Dec 3, 2013 at 6:22 AM, Hoover, Jacob 
 jacob.hoo...@greenheck.comwrote:

  Since the serial number is user data I would expect it to
  persist after uninstall. If this is a per machine install I'd expect the
  file to live under CommonAppData in a Mfg/App sub folder. As such, the only
  need for a CA is to read this data on major upgrade (if you really think
  the installer should be the one prompting for a serial number).  To be
  honest, I'd go with the recommended approach of the installer only doing
  the installing, and the registration happening upon first run of the
  application.

  That being said, if you really need this inside your installer, I
  wouldn't move the license file but rather I'd have a CA for reading all the
  info out of the file. Schedule this CA early in your sequence (have it in
  both but schedule it to only run once) and have it populate Secure and
  Hidden properties that would then be used to populate your dialog in the UI.

  -Original Message-
  From: tyler.w.r...@accenture.com [mailto:tyler.w.r...@accenture.com]
  Sent: Monday, December 02, 2013 12:41 PM
  To: wix-users@lists.sourceforge.net
  Subject: [WiX-users] Help migrating Serial number during upgrade

  Hello,

  I have been tasked with creating a custom action that will migrate
  the user's serial number during a major upgrade. I have a custom action
  that runs before RemoveExisting that moves the license file, but my problem
  is that we have a custom dialog if ran in GUI mode that prompts for the
  serial. Since this runs before my custom action it shows up blank.

  My question is will I need to use two custom actions one in the UI
  sequence and another in the InstallExecute sequence or is there a way I can
  just use one custom action and solve both cases.

  Tyler Reid | Operations and Infrastructure | Accenture Software | PC
  Insurance
  1807 Jones Street | Bolivar, MO 65613| USA
  Office: +cc.xxx.xxx. | Fax: 417.777.3792
  E-Mail: tyler.w.r...@accenture.commailto:tyler.w.r...@accenture.com |
  www.accenture.com/pcsoftwarehttp://www.accenture.com/pcsoftware

  This message is for the designated recipient only and may contain
  privileged, proprietary, or otherwise confidential information. If you have
  received it in error, please notify the sender immediately and delete the
  original. Any other use of the e-mail by you is prohibited.

  Where allowed by local law, electronic communications with Accenture and
  its affiliates, including e-mail and instant messaging (including content),
  may be scanned by our systems for the purposes of information security and
  assessment of internal compliance with Accenture policy.

  __

  www.accenture.com

  --
  Rapidly troubleshoot problems before they affect your business. Most IT
  organizations don't have a clear picture of how application performance
  affects their revenue. With AppDynamics, you get 100% visibility into your
  Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
  Pro!
  http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users

  --
  Rapidly troubleshoot problems before they affect your business. Most IT
  organizations don't have a clear picture of how application performance
  affects their revenue. With AppDynamics, you get 100% visibility into your
  Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
  Pro!
  http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [WIX]: How to trigger my MSI file when I select install option in Wix Custom Bootstrapper UI

how did you load your BA?

 Date: Fri, 29 Nov 2013 11:07:37 +0530
 From: dileep.sanamp...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] [WIX]: How to trigger my MSI file when I select 
 install option in Wix Custom Bootstrapper UI

 Hi Blair,

 Thank you for the information..

 Can you give some example to call the BootStrapper Install action using
 PFN_BOOTSTRAPPER_APPLICATION_CREATE method .

 Please help me...

 Thanks in advance

 On Thu, Nov 28, 2013 at 2:20 PM, Blair Murri os...@live.com wrote:

  When your PFN_BOOTSTRAPPER_APPLICATION_CREATE method (prototyped in the
  IBootstrapperApplication.h file) was called that you used to create your
  UI, you were passed an IBootstrapperEngine pointer. You call the engine
  methods directly on that interface pointer (which is defined in the
  IBootstrapperEngine.h file).

  WixStdBA.dll is a BA that the toolset provides, but by writing your own
  you don't use it (except in the case where you are writing a managed BA) so
  it is never loaded if you are using your own BA.

  If you are looking for example C++ code, you could look at the sources to
  WixStdBA, because that is a BA written in C++. Another example is the
  WixExtBA project on codeplex. There may be others as well (although most
  examples I've seen are managed code instead of native code).

  -Blair

   Date: Thu, 28 Nov 2013 12:43:53 +0530
   From: dileep.sanamp...@gmail.com
   To: wix-users@lists.sourceforge.net
   Subject: Re: [WiX-users] [WIX]: How to trigger my MSI file when I select
  install option in Wix Custom Bootstrapper UI

   Hi Blair,

   Thank you for the information.

   Is there any examples in c++ to call Detect, then Plan, and then Apply on
   the engine.

   We need to load the WixStdBA.dll and call the functions? or any other
  way?

   Please help me to solve this.

   Thanks in advance..

  --
  Rapidly troubleshoot problems before they affect your business. Most IT
  organizations don't have a clear picture of how application performance
  affects their revenue. With AppDynamics, you get 100% visibility into your
  Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
  Pro!
  http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users

 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX v3.8 released! [P]

Only via using the technique documented here: 
http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html
 
 From: steven.ogil...@titus.com
 To: wix-users@lists.sourceforge.net
 Date: Thu, 28 Nov 2013 16:48:26 +
 Subject: Re: [WiX-users] WiX v3.8 released! [P]
 
 Classification: Public
 Awesome news Rob...
 
 Can two versions of WIX co-exist on a build machine? i.e. 3.7 and 3.8
 
 Thanks,
 
 Steve
 
 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com]
 Sent: November-28-13 11:39 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] WiX v3.8 released!
 
 WiX v3.8 released: http://wixtoolset.org/releases/v3.8/stable
 
 Read more about it here: 
 http://robmensching.com/blog/posts/2013/11/28/wix-v3.8-released
 
 A big thank you to all the new contributors that helped make this the best 
 release of the WiX toolset yet.
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
  
 
 
 
  
 This message has been marked as Public by Steven Ogilvie on November-28-13 
 11:48:25 AM.
 
 The above classification labels were added to the message by TITUS Message 
 Classification. For more information visit www.titus.com.
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Cannot create patch using 3.7/3.8 when original MSI built with 3.5

alternately: 
http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html

 Date: Fri, 29 Nov 2013 14:25:22 +1100
 From: goodridge@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Cannot create patch using 3.7/3.8 when original MSI  
 built with 3.5

  Torch.exe -nologo -p -xi PATCHCHK_en-us.wixpdb \PATCHCHK_en-us.wixpdb
  -out \PATCHCHK.wixmst

  error TRCH0279 : The table definition of 'WixVariable' in the target
  database does not match the table definition in the updated database. A
  transform requires that the target database schema match the updated
  database schema.

  We supply a development tool which uses WiX to deploy applications. Its
  used by 100's of development shops in many situations. Hence this issue is
  stopping us upgrading the WiX version because it would stop them being able
  to patch an application that's already been released.

  Is it possible to use a backward compatibility flag - e.g. set WixVariable
  to 3.5?

  Alternatively, can 3.8 be installed without uninstalling 3.5?

  warm regards

  Rob Goodridge

 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrades

When Burn installs a newer MSI that MSI should still generally remove older 
versions of itself (#1 reason: your customers may not do what you expect).
 
Having said that, if an MSI does what is expected, then the older MSI will be 
removed as part of its upgrade. When the older bundle is then removed, it will 
find that the MSI it had installed is no longer installed, and it will remove 
its cache of that MSI as it removes itself, thus completing its cleanup.
 
Does that make more sense? (I didn't search the older parts of this 
conversation, so there may be something I'm missing...)
 
 Date: Thu, 28 Nov 2013 13:39:39 -0500
 From: michael.ogil...@pixelink.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Upgrades
 
 Hello Phil,
 
 Thanks for the info.
 
 From the log files it looks like it uninstalls the stuff twice.
 
 From the install logs of the MSI it goes through the uninstall then the
 install then it looks like Burn also uninstalls the old version.
 
 just does not make sense.
 
 Thank you,
 Michael Ogilvie
 
 
 
 -Original Message-
 From: Phill Hogland [mailto:phogl...@rimage.com] 
 Sent: Wednesday, November 27, 2013 10:54 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Upgrades
 
 Generally yes, although you might not specify all of those attributes.
 Each
 MSI needs some information instructing it how to process upgrades, which
 is
 independent of how the MSI is launched, as part of a bundle chain or
 directly.
 
 
 
 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Upgrades-t
 p7590978p7590984.html
 Sent from the wix-users mailing list archive at Nabble.com.
 
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into
 your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of
 AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clk
 trk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Little major/minor-update problem with burn / msi

Do msiBlock and msiOld share the same ProductCode?
Is that ProductCode (or any ProductCode) also shared by msiNew?
Do all three share the same UpgradeCode?
Does msiOld have any code to guard against it being the source of a downgrade?

 From: i...@tobias-erichsen.de
 To: wix-users@lists.sourceforge.net
 Date: Sun, 1 Dec 2013 05:43:19 +
 Subject: [WiX-users] Little major/minor-update problem with burn / msi

 Hi everyone,

 I have a little problem with my burn / msi installer:

 My old MSI-installer has been replaced by a burn-package that includes
 multiple MSIs (as one of the components that was a merge-module the old MSI
 is now in use by 3rd parties as well).

 Unfortunately - due to my lack of knowledge at that time - I did not include
 a MajorUpgrade element in my old MSI.

 To remedy this, I have tried the following approach:

 My old MSI (msiOld) is uninstalled via my new MSI (msiNew).  I want to
 install a second MSI (msiBlock) after msiNew to block any future
 installation of my msiOld to not mess up my new (and future) installation(s).

 Unfortunately, burn sees the msiOld and when msiBlock is scheduled it is
 scheduled as a minor install because burn thinks that msiOld is still on
 the system even though it has been uninstalled by msiNew.

 Is there any way that I can force burn to still install msiBlock as a major
 install?  Or is there any way to tell burn that it needs to re-evaluate what
 is installed on the system after msiNew has been installed (and thus msiOld
 uninstalled) prior to installing msiBlock?

 Best regards,
 Tobias
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] wix37.exe - offline installation

Bugs discussed on these lists remain on these lists unless tracked, and the 
only way it will be tracked is if someone enters the bug into the tracking 
system. The best person to enter an issue into the tracking system is the 
person that discovers the bug, not necessarily the person who proclaims it to 
be a bug. The proclamation is a help to the issue reporter, letting them know 
it should be logged so that attention can be turned to providing a fix (or even 
better, so that person feels that they are invited to provide a fix, if they 
feel they are able).
 
Between answering several messages and the next time we triage, we may not 
remember that we discussed any particular issue, especially if it wasn't added 
to the issue tracker. That is how things slip through.
 
Jens, please enter this bug in the issue tracker on the wixtoolset.org site.
 
-Blair
 
 From: jens.teutenb...@t-online.de
 To: wix-users@lists.sourceforge.net
 Date: Sun, 1 Dec 2013 10:04:10 +0100
 Subject: Re: [WiX-users] wix37.exe - offline installation
 
 No, but Rob Mensching himself wrote Well there is the bug then. as an 
 answer of my question.
 Because of that I thought that it will be fixed.
 
 -Ursprüngliche Nachricht- 
 From: Nicolás Alvarez
 Sent: Saturday, November 30, 2013 6:10 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] wix37.exe - offline installation
 
 Did you ever report it in the bug tracker?
 
 El sábado, 30 de noviembre de 2013, Jens Teutenberg escribió:
 
  The bug still exists in the released new version 3.8!
 
  -Ursprüngliche Nachricht-
  From: Rob Mensching
  Sent: Friday, October 18, 2013 6:36 PM
  To: General discussion about the WiX toolset.
  Subject: Re: [WiX-users] wix37.exe - offline installation
 
  Well there is the bug then.
 
 
  On Fri, Oct 18, 2013 at 2:31 AM, Pally Sandher
  pally.sand...@iesve.comwrote:
 
   You are correct, it's the web installer.
   The full redistributable is named dotNetFx40_Full_x86_x64.exe  is 48.1
  MB
   in size.
  
   Looking at the source for the WiX installer, in
   \src\Setup\Bundle\Bundle.wxs it contains the following:
  
   Chain
   PackageGroupRef Id='NetFx40Web' /
  
   So /layout will always pull the web installer it seems.
  
   Palbinder Sandher
   Software Platform Engineer
   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: Sean Hall [mailto:rhal...@hotmail.com]
   Sent: 17 October 2013 16:26
   To: General discussion about the WiX toolset.
   Subject: Re: [WiX-users] wix37.exe - offline installation
  
   Sounds like a bug then.  I just ran wix37.exe /layout ., and
   redist\dotNetFx40_Full_setup.exe is only 869 KB which leads me to 
   believe
   that it's the web installer.  This is WiX 3.7.1224.0.
  
   Sean
  
From: r...@robmensching.com
Date: Thu, 17 Oct 2013 08:07:25 -0700
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] wix37.exe - offline installation
   
 dotNetFx40_Full_setup.exe is the full installer, not the web
installer. If you do /layout, that should give you everything you need
to
burn a CD and install via sneaker-net.
   
   
On Thu, Oct 17, 2013 at 6:37 AM, Sean Hall rhal...@hotmail.com
  wrote:
   
 Download the .NET 4 full offline installer yourself?
 http://www.microsoft.com/en-us/download/details.aspx?id=17718

 Sean

  From: jens.teutenb...@t-online.de
  To: wix-users@lists.sourceforge.net
  Date: Thu, 17 Oct 2013 15:30:26 +0200
  Subject: [WiX-users] wix37.exe - offline installation
 
  I used wix37.exe /layout to get an offline installer.
  That's worked fine.
  But the folder redist contains the file
  dotNetFx40_Full_setup.exe
 which is a web installer.
  Because of that it isn't possible to install wix37.exe without 
  an
 internet connection.
  Is there any solution to get a real offline installer?
 

 
 
 
 -- 
 Nicolás
 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics 
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Little major/minor-update problem with burn / msi




If msiOld has no guard at all, then it will potentially install itself on top 
of anything, no matter what you do. All you can do is reduce its vectors of 
installation.
 
If someone presents your msiOld via MSI double-click, you can prevent its 
installation by having another MSI with the same ProductCode installed, which 
is what you appear to be attempting to do. However, if either a somewhat 
knowledgeable user or a somewhat smart bootstrapper assists the user, then your 
msiBlock can be replaced with msiOld by adding REINSTALL to the commandline 
(and including the v in REINSTALLMODE), thwarting your efforts, unless the 
bootstrapper extracts the ProductVersion of the installed msiBlock and compares 
it to the ProductVersion of the attempted msiOld. Installing msiBlock, however, 
will never be a Major Upgrade, because by definition, major upgrades cannot 
share the ProductCode. You may be confusing tools by having a different 
UpgradeCode between msiBlock and msiOld (normally they would share the same 
UpgradeCode). It makes sense to use a different UpgradeCode between msiNew and 
the other MSIs (because you don't want even newer msiNew's to remove msiBlo
 ck). So, if you want to continue to block what you still can block, my 
recommendation is to give msiBlock the following values: productIdA, 
upgradeIdA, and a reasonably large ProductVersion (255.255.32767). You will 
need to include in msiBlock every component and feature in msiOld (using the 
very same component/feature tree used by oldMsi), but you can make every one of 
those components transitive and give them a condition of 0 (the number zero). 
You may need to include zero-byte files for each of the files in msiBlock 
(named the same as in msiOld), and you may also need to provide the same 
registry entries as well (although you can probably drop all custom actions 
that aren't involved with determining directory paths). If all of that is too 
much, my alternate recommendation is to simply instruct users to not reinstall 
msiOld, and if/when they do, to have them remove it and then repair msiNew. At 
the end of the day, you will probably be telling them to do that anyway (when 
they ci
 rcumvent your attempts to block them from doing so).
-Blair
 From: i...@tobias-erichsen.de
 To: wix-users@lists.sourceforge.net
 Date: Sun, 1 Dec 2013 15:16:03 +
 Subject: Re: [WiX-users] Little major/minor-update problem with burn / msi
 
 msiOld: productIdA, upgradeIdA
 msiNew: productIdB (*), upgradeIdB
 msiBlock: productIdA, upgradeIdC
 
 The problem is that msiOld does not have any guard and that is why
 I want to install some kind of (invisible) blocking-installer.
 
 I cannot change the msiOld (because it is out in the open), but
 I have all possibilities to change msiNew  msiBlock.
 
 It is no solution though to fix it by changing msiNew, as the merge-Module
 is used in two different products (msiOld1  msiOld2) so I cannot use
 msiNew (because there will be msiNew1  msiNew2) to block the old install...
 
  Do msiBlock and msiOld share the same ProductCode?
  Is that ProductCode (or any ProductCode) also shared by msiNew?
  Do all three share the same UpgradeCode?
  Does msiOld have any code to guard against it being the source of a 
  downgrade?
 
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [WIX]: How to trigger my MSI file when I select install option in Wix Custom Bootstrapper UI

I was referring to the code in SampleDLL.dll. I assume you are not creating 
your UI in DllMain(). There is a method that you export where your UI is 
created that Burn calls.

 Date: Mon, 2 Dec 2013 12:59:01 +0530
 From: dileep.sanamp...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] [WIX]: How to trigger my MSI file when I select 
 install option in Wix Custom Bootstrapper UI

 Hi Blair,

 I have created the C++ custom action project.
 Created Dialog Resource file.
 Created functions in C++ custom action DLL Main() to load the resource.
 Build C++ custom action project.

 Then, Added custom action dll into Bundle.wxs file.

 BootstrapperApplication Id =MyCustomBootStrapperID

 Payload SourceFile=D:\SampleDLL.dll/

 /BootstrapperApplication

 Chain

 MsiPackage SourceFile=.\Setup.msi DisplayInternalUI=yes Id=
 SetupPackageId Cache=yes Visible=no/

 /Chain

 Using the above, I can able to load the UI.

 I have not getting any clue to use that burn install actions.

 Thanks in advance.

 On Sun, Dec 1, 2013 at 2:43 PM, Blair Murri os...@live.com wrote:

  how did you load your BA?

   Date: Fri, 29 Nov 2013 11:07:37 +0530
   From: dileep.sanamp...@gmail.com
   To: wix-users@lists.sourceforge.net
   Subject: Re: [WiX-users] [WIX]: How to trigger my MSI file when I select
  install option in Wix Custom Bootstrapper UI

   Hi Blair,

   Thank you for the information..

   Can you give some example to call the BootStrapper Install action using
   PFN_BOOTSTRAPPER_APPLICATION_CREATE method .

   Please help me...

   Thanks in advance

   On Thu, Nov 28, 2013 at 2:20 PM, Blair Murri os...@live.com wrote:

When your PFN_BOOTSTRAPPER_APPLICATION_CREATE method (prototyped in the
IBootstrapperApplication.h file) was called that you used to create
  your
UI, you were passed an IBootstrapperEngine pointer. You call the engine
methods directly on that interface pointer (which is defined in the
IBootstrapperEngine.h file).

WixStdBA.dll is a BA that the toolset provides, but by writing your own
you don't use it (except in the case where you are writing a managed
  BA) so
it is never loaded if you are using your own BA.

If you are looking for example C++ code, you could look at the sources
  to
WixStdBA, because that is a BA written in C++. Another example is the
WixExtBA project on codeplex. There may be others as well (although
  most
examples I've seen are managed code instead of native code).

-Blair

 Date: Thu, 28 Nov 2013 12:43:53 +0530
 From: dileep.sanamp...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] [WIX]: How to trigger my MSI file when I
  select
install option in Wix Custom Bootstrapper UI

 Hi Blair,

 Thank you for the information.

 Is there any examples in c++ to call Detect, then Plan, and then
  Apply on
 the engine.

 We need to load the WixStdBA.dll and call the functions? or any other
way?

 Please help me to solve this.

 Thanks in advance..

  --
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into
  your
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of
  AppDynamics
Pro!

  http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

  --
   Rapidly troubleshoot problems before they affect your business. Most IT
   organizations don't have a clear picture of how application performance
   affects their revenue. With AppDynamics, you get 100% visibility into
  your
   Java,.NET,  PHP application. Start your 15-day FREE TRIAL of
  AppDynamics Pro!

  http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
   ___
   WiX-users mailing list
   WiX-users@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wix-users

  --
  Rapidly troubleshoot problems before they affect your business. Most IT
  organizations don't have a clear picture of how application performance
  affects their revenue. With AppDynamics, you get 100% visibility into your
  Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
  Pro!
  http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk

Re: [WiX-users] util:XmlFile hide logging of sensitive information

That bug now lives here: http://wixtoolset.org/issues/3859/
 
 From: ilir...@gmail.com
 Date: Wed, 27 Nov 2013 11:07:14 +0100
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] util:XmlFile hide logging of sensitive information
 
 Updating MSI sounds really hack-y way to do it, either way i found the bug
 report http://sourceforge.net/p/wix/bugs/3163/ so hopefully will be fixed
 soon :) Thanks
 
 
 On Tue, Nov 26, 2013 at 1:53 PM, Blair Murri os...@live.com wrote:
 
  The CustomAction tag inside of the UtilExtension for the deferred portion
  of the XmlFile custom action doesn't have the HideTarget attribute set. I
  thought there was an issue opened on that at some point, but I don't recall
  right now.
 
  You could update the MSI post-binding to set that bit in the custom action
  attributes.
 
   From: ilir...@gmail.com
   Date: Tue, 26 Nov 2013 12:30:11 +0100
   To: wix-users@lists.sourceforge.net
   Subject: [WiX-users] util:XmlFile hide logging of sensitive information
  
   Hi,
  
   I'm using util:XmlFile to change a connection string in a file and a
   Password is involved which i would like to hide or not log.
  
   util:XmlFile Id=XML_File.exe.config
   File=[Dir_File]File.exe.config
  ElementPath=//configuration/connectionStrings/add[\[]@name='ABC'[\]]
   Action=setValue
  Name=connectionString
  Sequence=1
   Value=User ID=user;Password='[PASSWORD]';
   /util:XmlFile
  
   I also added:
   Property Id=ExecXmlFile Hidden=yes /Property
   Property Id=PASSWORD Hidden=yes Secure=yes /
  
   But still there is one line that is being logged and would appreciate any
   help:
  
   MSI (s) (F8:8C) [11:43:03:072]: Executing op:
   ActionStart(Name=ExecXmlFile,,)
   MSI (s) (F8:8C) [11:43:03:074]: Executing op:
  
  CustomActionSchedule(Action=ExecXmlFile,ActionType=3073,Source=BinaryData,Target=ExecXmlFile,CustomActionData=2€0€C:\Program
  
  Files\ABC\File.exe.config€3€0€//configuration/connectionStrings/add[@name='ABC']€connectionString€User
   ID=user;Password='q9h581)D3]';)
  
  --
   Shape the Mobile Experience: Free Subscription
   Software experts and developers: Be at the forefront of tech innovation.
   Intel(R) Software Adrenaline delivers strategic insight and game-changing
   conversations that shape the rapidly evolving mobile landscape. Sign up
  now.
  
  http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
   ___
   WiX-users mailing list
   WiX-users@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
  --
  Shape the Mobile Experience: Free Subscription
  Software experts and developers: Be at the forefront of tech innovation.
  Intel(R) Software Adrenaline delivers strategic insight and game-changing
  conversations that shape the rapidly evolving mobile landscape. Sign up
  now.
  http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RegistrySearch/@Win64 bug?

The -arch command-line argument is what sets the default value of @Win64 on 
things like the RegistrySearch and Component elements, not the 
Package/@Platform attribute.

That is a doc bug. Please file it so we get it corrected.

-Blair

 Date: Wed, 27 Nov 2013 19:46:10 +0200
 From: igor@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] RegistrySearch/@Win64 bug?

 Hello,

 RegistrySearch/@Win64 documentation at
 http://wixtoolset.org/documentation/manual/v3/xsd/wix/registrysearch.html
  says:

 The default value depends on the value of the Package/@Platform attribute:
 if the @Platform attribute value is 'x86', the default @Win64 attribute
 value is 'no'; otherwise, the default value is 'yes'.

 But my tests with WIX 3.6.3303 showed that default is always 'no'
 regardless of Package/@Platform attribute value. For example I have
 Package/@Platform
 value 'x64' and RegistrySearch element without @Win64 attribute. I compile
 msi and check its content with Orca. RegLocator table contains record
 corresponding to my RegistrySearch element but its Type does
 not contain msidbLocatorType64bit set.

 Is this bug in WiX or bug in the schema reference? Or maybe I missing
 something?

 Thanks,
 Igor
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] info about VSProjectOutput

I don't recognize it but a Bing search turned up this page:
http://portals.altiris.com/portals/13/sdk/smp%207.0/SolutionDev/UnderstandingAndCreatingInstallationsUsingWIX.html

-Blair

Date: Thu, 28 Nov 2013 11:12:21 +0530
From: subrat.w...@gmail.com
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] info about VSProjectOutput

Hi,

I can see some VSProjectOutput nodes in my wix file. I can't find any
documentation on this node. Can anybody please tell me what this is and why
it is used?

Thanks,
syd
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [WIX]: How to trigger my MSI file when I select install option in Wix Custom Bootstrapper UI

When your PFN_BOOTSTRAPPER_APPLICATION_CREATE method (prototyped in the 
IBootstrapperApplication.h file) was called that you used to create your UI, 
you were passed an IBootstrapperEngine pointer. You call the engine methods 
directly on that interface pointer (which is defined in the 
IBootstrapperEngine.h file).
 
WixStdBA.dll is a BA that the toolset provides, but by writing your own you 
don't use it (except in the case where you are writing a managed BA) so it is 
never loaded if you are using your own BA.
 
If you are looking for example C++ code, you could look at the sources to 
WixStdBA, because that is a BA written in C++. Another example is the WixExtBA 
project on codeplex. There may be others as well (although most examples I've 
seen are managed code instead of native code).
 
-Blair
 
 Date: Thu, 28 Nov 2013 12:43:53 +0530
 From: dileep.sanamp...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] [WIX]: How to trigger my MSI file when I select 
 install option in Wix Custom Bootstrapper UI
 
 Hi Blair,
 
 Thank you for the information.
 
 Is there any examples in c++ to call Detect, then Plan, and then Apply on
 the engine.
 
 We need to load the WixStdBA.dll and call the functions? or any other way?
 
 Please help me to solve this.
 
 Thanks in advance..
 
 
 
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [WIX]: How to trigger my MSI file when I select install option in Wix Custom Bootstrapper UI

You call Detect, then Plan, and then Apply on the engine. How you intersperse 
those calls with what you show when in your UI is ultimately up to you.
 
 Date: Tue, 26 Nov 2013 11:55:54 +0530
 From: dileep.sanamp...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] [WIX]: How to trigger my MSI file when I select install 
 option in Wix Custom Bootstrapper UI
 
 Hi All,
 
 I have created custom UI in C++.
 
 I was able to display my custom UI in WIX BootStrapper application.
 
 In custom UI, I have two options like install, Exit.
 
 
 BootstrapperApplication Id =MyCustomBootStrapperID
 
 Payload SourceFile=D:\SampleDLL.dll/
 
 /BootstrapperApplication
 
 Chain
 
 MsiPackage SourceFile=.\Setup.msi DisplayInternalUI=yes Id=
 SetupPackageId Cache=yes Visible=no/
 
 /Chain
 
 
 
 How to trigger my MSI file when I select install option in Wix Custom
 Bootstrapper UI?
 
 Anyone please help me on this?
 
 
 
 Thanks in Advance...
 --
 Shape the Mobile Experience: Free Subscription
 Software experts and developers: Be at the forefront of tech innovation.
 Intel(R) Software Adrenaline delivers strategic insight and game-changing 
 conversations that shape the rapidly evolving mobile landscape. Sign up now. 
 http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] util:XmlFile hide logging of sensitive information

The CustomAction tag inside of the UtilExtension for the deferred portion of 
the XmlFile custom action doesn't have the HideTarget attribute set. I thought 
there was an issue opened on that at some point, but I don't recall right now.
 
You could update the MSI post-binding to set that bit in the custom action 
attributes.
 
 From: ilir...@gmail.com
 Date: Tue, 26 Nov 2013 12:30:11 +0100
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] util:XmlFile hide logging of sensitive information
 
 Hi,
 
 I'm using util:XmlFile to change a connection string in a file and a
 Password is involved which i would like to hide or not log.
 
 util:XmlFile Id=XML_File.exe.config
 File=[Dir_File]File.exe.config
ElementPath=//configuration/connectionStrings/add[\[]@name='ABC'[\]]
 Action=setValue
Name=connectionString
Sequence=1
 Value=User ID=user;Password='[PASSWORD]';
 /util:XmlFile
 
 I also added:
 Property Id=ExecXmlFile Hidden=yes /Property
 Property Id=PASSWORD Hidden=yes Secure=yes /
 
 But still there is one line that is being logged and would appreciate any
 help:
 
 MSI (s) (F8:8C) [11:43:03:072]: Executing op:
 ActionStart(Name=ExecXmlFile,,)
 MSI (s) (F8:8C) [11:43:03:074]: Executing op:
 CustomActionSchedule(Action=ExecXmlFile,ActionType=3073,Source=BinaryData,Target=ExecXmlFile,CustomActionData=2€0€C:\Program
 Files\ABC\File.exe.config€3€0€//configuration/connectionStrings/add[@name='ABC']€connectionString€User
 ID=user;Password='q9h581)D3]';)
 --
 Shape the Mobile Experience: Free Subscription
 Software experts and developers: Be at the forefront of tech innovation.
 Intel(R) Software Adrenaline delivers strategic insight and game-changing 
 conversations that shape the rapidly evolving mobile landscape. Sign up now. 
 http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX 3.7: iis:WebAddress IP=* works, but generates different .config entries...

From what I can see poking around the * should not have been dropped...
 
 Date: Mon, 25 Nov 2013 13:57:26 -0500
 From: yellowjacketl...@gmail.com
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] WiX 3.7: iis:WebAddress IP=* works,but generates 
 different .config entries...
 
 I created a website using this pattern...
 
 iis:WebSite Id=Site1WebSite Description=$(var.Site1)
 Directory=SITE1DIR AutoStart=yes SiteId=5002 StartOnInstall=yes
 iis:WebApplication Id=Site1App Name=$(var.Site1)
 WebAppPool=Site1AppPool/
 iis:WebAddress Id=Site1AllUnassigned IP=* Port=80
 Header=$(var.Site1)[ENV_DNS_SUFFIX]/
 /iis:WebSite
 
 When I open IIS Manager, I noticed that he bindings display differently
 than when I manually create a website.  The binding string created through
 the UI is *:80:header, whereas the WiX generated binding string is
 :80:header (no asterisk).
 
 Any reason why this is happening?  I haven't noticed anything not working,
 but I've only performed the most basic of post install testing.
 
 
 Here is IIS's config file for the two sites (site1 == WiX, site2=manual
 binding setup)
 
 site name=site1 id=5002 serverAutoStart=true
  application path=/ applicationPool=site1
   virtualDirectory path=/ physicalPath=C:\testfolder\Sites\site1 /
  /application
  bindings
   binding protocol=http bindingInformation=:80:site1.localhost /
  /bindings
 /site
 site name=site2 id=5003 serverAutoStart=true
  application path=/ applicationPool=site2
   virtualDirectory path=/ physicalPath=C:\testfolder\Sites\site2 /
  /application
  bindings
   binding protocol=http bindingInformation=*:80:site2.localhost /
  /bindings
 /site
 
 -- 
 Tony
 --
 Shape the Mobile Experience: Free Subscription
 Software experts and developers: Be at the forefront of tech innovation.
 Intel(R) Software Adrenaline delivers strategic insight and game-changing 
 conversations that shape the rapidly evolving mobile landscape. Sign up now. 
 http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] DTF managed custom action - session.doAction

Between InstallInitialize and InstallFinalize all deferred actions are written 
into the installation script (along with the properties named after them at the 
same moment in time). When any of the InstallExecute, InstallExecuteAgain, and 
InstallFinalize actions run, they run the script from wherever it last was to 
the end of what's been written up to that point.
 
Thus, the sequence of the deferred actions is always the order they are written 
into the script (which is the order they are run when the script is being 
written), and the timing is always during one of the three actions I mentioned 
above.
 
-Blair
 
 From: jens.teutenb...@t-online.de
 To: wix-users@lists.sourceforge.net
 Date: Tue, 26 Nov 2013 19:54:07 +0100
 Subject: [WiX-users] DTF managed custom action - session.doAction
 
 I wrote a immediate custom action and a deferred custom action.
 The immediate custom action will be executed after InstallFiles and the 
 deferred custom action is executed with the command “session.doAction” in the 
 immediate custom action.
 When in the sequence the deferred custom action is executed?
 Is it possible to define the position in the sequence?
 --
 Rapidly troubleshoot problems before they affect your business. Most IT 
 organizations don't have a clear picture of how application performance 
 affects their revenue. With AppDynamics, you get 100% visibility into your 
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] DTF managed custom action - temporary file