Re: [WiX-users] Bootstrap conditioned on OSbittage

[Hoover, Jacob]

My first question would be why.  What do you need to do that you can't at 
least allow your bundle be in the chain and let burn do its work before 
deferring to your final exe installer?

-Original Message-
From: Matt O'Connell [mailto:techsupport...@gmail.com] 
Sent: Wednesday, July 08, 2015 7:41 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bootstrap conditioned on OSbittage

Sorry guys can I get some advise on this one please?

I realise burn can't 'fire and forget' see 
http://www.joyofsetup.com/2013/07/05/burn-zero-one-or-n/
but what (free) methods are there available to do this? Can anyone reccommend 
something?

Alternatively is it possible to bundle (and conditionalise) the exes but hide 
the bundle's ARP entry and expose the third party exes ARP entries? If so could 
the user could use that to repair/uninstall so it effectively wouldn't appear 
that the package had been 'bundled'?

Many Thanks

On 17 June 2015 at 12:36, Matt O'Connell techsupport...@gmail.com wrote:

 I've got a third party exe with 2 versions to bootstrap based on OS 
 bittage, our current setup code only does this for MSIs. I've found 
 how to do this with burn bundle but don't need the bundleness of it as 
 per this 
 http://stackoverflow.com/questions/30010837/i-dont-want-install-a-boot
 strapper-project-itself What would you guys recommend for this use 
 case?

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you need 
to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setting Compatibility Mode on shortcut for all users

[Hoover, Jacob]

You might need to deploy a shim db, though you'd have to define the specific 
compatibly settings you need.  

https://technet.microsoft.com/en-us/library/dd837647(v=ws.10).aspx

https://technet.microsoft.com/en-us/library/dd837648(WS.10).aspx


-Original Message-
From: Chris Moxon [mailto:chris.mo...@eque2.com] 
Sent: Tuesday, July 07, 2015 8:41 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Setting Compatibility Mode on shortcut for all users

I just tried setting Windows 7 compatibility in the app manifest and removing 
the tick-box on the shortcut - but alas that makes our application fail.  It's 
using a third party ODBC driver that doesn't seem to work unless we have the 
tick-box selected on the short-cut.

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 06 July 2015 21:21
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Setting Compatibility Mode on shortcut for all users

Wouldn't the right way be to manifest the EXE declaring which version of 
Windows it is compatible with, and let the newer OS's decide if they need to 
shim the app?

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com]
Sent: Monday, July 06, 2015 3:11 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Setting Compatibility Mode on shortcut for all users

It might be works as designed. Raymond Chen appears adamant that it shouldn't 
be done in an install anyway:

http://blogs.msdn.com/b/oldnewthing/archive/2010/03/11/9976571.aspx
---
Phil Wilson


On Mon, Jul 6, 2015 at 9:52 AM, Chris Moxon chris.mo...@eque2.com wrote:
 I have a msi that has its InstallScope set to perMachine and it creates a 
 shortcut which is available to all the users:

 Directory Id=ProgramMenuFolder

Directory Id=CompanyShortcutsDir Name=My Company /

 /Directory


 Component Id=CMP_MainExeShortcut

Directory=CompanyShortcutsDir

Guid={B857CD9E---F2090C50C985}



   Shortcut Id=MyExeStartShortcut

 Name=My Product

 Description=$(var.WIX_PRODNAME)

 Target=[APPLICATIONFOLDER]MyApp.exe

 WorkingDirectory=APPLICATIONFOLDER

 Icon=my.ico /



   RemoveFolder Id=RemoveCompanyShortcutsDir

 On=uninstall /



   RegistryValue Root=HKCU

  Key=Software\MyCompany

  Name=MainExeShortcut

  Type=integer

  Value=1

  KeyPath=yes /

 /Component



 and the shortcut does indeed appear for all the users - so far so good !!

 But I also have this fragment of code:



 Component Id=CMP_MainExeShortcutCompat

   Directory=CompanyShortcutsDir

   Guid={C748B7C6---7CB1823774DC}





   RegistryValue Root=HKMU

  Key=SOFTWARE\Microsoft\Windows 
 NT\CurrentVersion\AppCompatFlags\Layers

  Name=[APPLICATIONFOLDER]MyApp.exe

  Type=string

  Value=~ WIN7RTM

  KeyPath=yes/

 /Component
 who's purpose is to set the Compatibility Mode on the shortcut to be 
 Windows 7 - but this only happens for the user that installed our product, 
 it doesn't get set on the shortcut for the other users who are likely to 
 login to the PC.
 Does anyone know how I can set this flag on the shortcut for all the users ?
 Many Thanks,
 Chris.


 If you've received this email by mistake, we're sorry for bothering you. It 
 may contain information that's confidential, so please delete it without 
 sharing it. And if you let us know, we can try to stop it from happening 
 again. Thank you.

 We may monitor any emails sent or received by us, or on our behalf. If we do, 
 this will be in line with relevant law and our own policies.

 Eque2 Limited. Registered in England at Freetrade Exchange, 37 Peter Street, 
 Manchester, M2 5GB. Registered number 08179642.
 --
  Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that 
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you need 
to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] how to add code signing to build script

[Hoover, Jacob]

The error you are getting is: FDIERROR_NOT_A_CABINET

(This would go after your last call to light.)

http://neilsleightholm.blogspot.com/2012/05/wix-burn-tipstricks.html

Signing a package

insignia -ib Setup.exe -o engine.exe
signtool engine.exe (extra parameters excluded for simplicity)
insignia -ab engine.exe Setup.exe -o Setup.exe
signtool Setup.exe

Though it's easier to use a wixproj and the MSBuild tasks, and then just 
override the targets.

-Original Message-
From: David Burson [mailto:david_bur...@ntm.org] 
Sent: Monday, July 06, 2015 1:01 PM
To: General discussion about the WiX toolset.
Subject: [WiX-users] how to add code signing to build script

Hi,

I’m brand new to code signing.  Just got my certificate through K Software, a 
Comodo reseller.  I tried adding a call to kSignCMD.exe at the end of my build 
script, and it appears to work:  the properties for my installer show my 
certificate, and the UAC prompt when I install also shows me as the publisher.

However, the installer fails.  The start of the log looks fine as far as I can 
see, but here’s how the log ends:

Apply begin
Creating a system restore point.
Created a system restore point.
Caching bundle from: 
'C:\Users\david\AppData\Local\Temp\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\.be\MapCreatorSetup-x64-1.1.3.exe'
 to: 'C:\ProgramData\Package 
Cache\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\MapCreatorSetup-x64-1.1.3.exe'
Registering bundle dependency provider: {e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}, 
version: 1.1.3.0 Acquiring container: WixAttachedContainer, copy from: 
C:\mc\MapCreatorSetup-x64-1.1.3.exe
Setting string variable 'WixBundleLastUsedSource' to value 'C:\mc\'
Error 0x80070001: Failed to extract all files from container, erf: 1:2:0 Error 
0x80070001: Failed to wait for operation complete.
Error 0x80070001: Failed to open container.
Error 0x80070001: Failed to open container: WixAttachedContainer.
Failed to extract payloads from container: WixAttachedContainer to working 
path: 
C:\Users\david\AppData\Local\Temp\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\F0BE7EF5275BEDA1781A0DC8690CC9EBB929A6A8,
 error: 0x80070001.
Error 0x80070001: Failed while caching, aborting execution.
Removed bundle dependency provider: {e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}
Removing cached bundle: {e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}, from path: 
C:\ProgramData\Package Cache\{e3cdbd3a-6ab1-4f6c-94b2-4f005172e581}\
Apply complete, result: 0x80070001, restart: None, ba requested restart:  No

I’ve examined this Insignia documentation:  
http://wixtoolset.org/documentation/manual/v3/overview/insignia.html but I 
don’t really understand what I’m supposed to do to get code signing to be part 
of my build script.  Here are what I assume is the pertinent information about 
my build script:

After my build script builds all the components and produces an .exe, it calls 
candle.exe on about a dozen .wxs files, representing various components such as 
localization, help file, license, and finally the actual product.

Next, it calls light.exe with the .wixobj’s produced in the previous steps, to 
create an msi.

Then it calls candle.exe on my bundle.wxs.

Finally, it calls light.exe on the bundle.wixobj.

Where in these steps should I insert call(s) to sign my code, and what should 
those calls look like?  Also, is there any command I can add to the script that 
will output whether code signing worked?

Thanks,
David

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you need 
to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setting Compatibility Mode on shortcut for all users

[Hoover, Jacob]

Wouldn't the right way be to manifest the EXE declaring which version of 
Windows it is compatible with, and let the newer OS's decide if they need to 
shim the app?

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Monday, July 06, 2015 3:11 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Setting Compatibility Mode on shortcut for all users

It might be works as designed. Raymond Chen appears adamant that it shouldn't 
be done in an install anyway:

http://blogs.msdn.com/b/oldnewthing/archive/2010/03/11/9976571.aspx
---
Phil Wilson


On Mon, Jul 6, 2015 at 9:52 AM, Chris Moxon chris.mo...@eque2.com wrote:
 I have a msi that has its InstallScope set to perMachine and it creates a 
 shortcut which is available to all the users:

 Directory Id=ProgramMenuFolder

Directory Id=CompanyShortcutsDir Name=My Company /

 /Directory


 Component Id=CMP_MainExeShortcut

Directory=CompanyShortcutsDir

Guid={B857CD9E---F2090C50C985}



   Shortcut Id=MyExeStartShortcut

 Name=My Product

 Description=$(var.WIX_PRODNAME)

 Target=[APPLICATIONFOLDER]MyApp.exe

 WorkingDirectory=APPLICATIONFOLDER

 Icon=my.ico /



   RemoveFolder Id=RemoveCompanyShortcutsDir

 On=uninstall /



   RegistryValue Root=HKCU

  Key=Software\MyCompany

  Name=MainExeShortcut

  Type=integer

  Value=1

  KeyPath=yes /

 /Component



 and the shortcut does indeed appear for all the users - so far so good !!

 But I also have this fragment of code:



 Component Id=CMP_MainExeShortcutCompat

   Directory=CompanyShortcutsDir

   Guid={C748B7C6---7CB1823774DC}





   RegistryValue Root=HKMU

  Key=SOFTWARE\Microsoft\Windows 
 NT\CurrentVersion\AppCompatFlags\Layers

  Name=[APPLICATIONFOLDER]MyApp.exe

  Type=string

  Value=~ WIN7RTM

  KeyPath=yes/

 /Component
 who's purpose is to set the Compatibility Mode on the shortcut to be 
 Windows 7 - but this only happens for the user that installed our product, 
 it doesn't get set on the shortcut for the other users who are likely to 
 login to the PC.
 Does anyone know how I can set this flag on the shortcut for all the users ?
 Many Thanks,
 Chris.


 If you've received this email by mistake, we're sorry for bothering you. It 
 may contain information that's confidential, so please delete it without 
 sharing it. And if you let us know, we can try to stop it from happening 
 again. Thank you.

 We may monitor any emails sent or received by us, or on our behalf. If we do, 
 this will be in line with relevant law and our own policies.

 Eque2 Limited. Registered in England at Freetrade Exchange, 37 Peter Street, 
 Manchester, M2 5GB. Registered number 08179642.
 --
  Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that 
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you need 
to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] QuickTime is installing when it is already installed.

[Hoover, Jacob]

Just a guess but...



util:RegistrySearch Root=HKLM
Key=SOFTWARE\Clients\Media\QuickTime Result=exists
Variable=QuickTimeFound64 Win64=yes /
util:RegistrySearch Root=HKLM
Key=SOFTWARE\Clients\Media\QuickTime Result=exists
Variable=QuickTimeFound32 Win64=no /


-Original Message-
From: garymonk [mailto:g...@gurudental.com] 
Sent: Monday, July 06, 2015 1:20 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] QuickTime is installing when it is already installed.

I cannot get this to work correctly. Here is the log...

[08B4:040C][2015-07-06T10:50:14]i000: Registry key not found. Key = 
'HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\QuickTime'
[08B4:040C][2015-07-06T10:50:14]i000: Setting numeric variable 
'QuickTimeFound64' to value 0
[08B4:040C][2015-07-06T10:50:14]i000: Registry key not found. Key = 
'HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\QuickTime'

My registry...

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/file/n7600799/Capture.png
 

My code...

util:RegistrySearch Root=HKLM
Key=HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\QuickTime Result=exists
Variable=QuickTimeFound64 Win64=yes /
util:RegistrySearch Root=HKLM
Key=HKEY_LOCAL_MACHINE\SOFTWARE\Clients\Media\QuickTime Result=exists
Variable=QuickTimeFound32 Win64=no /

Chain
PackageGroupRef Id=PackageGroup_NetFx35Redist/
PackageGroupRef Id=PackageGroup_NetFx40Redist/
PackageGroupRef Id=PackageGroup_SQLServer2012/

ExePackage Id=Package_QuickTime Cache=no
Compressed=$(var.Compressed)
  Description=Apple QuickTime 7
DownloadUrl=$(var.GuruDownloadRepo)/{2}
 
SourceFile=..\Prerequisites\QuickTimeInstaller.exe
  Name=Prerequisites\QuickTimeInstaller.exe
  Permanent=yes DisplayName=Apple QuickTime 7
  DetectCondition=QuickTimeFound64 AND 
QuickTimeFound32 /

The way I think this should work is that QuickTime32 is false and
QuickTime64 should be true, but as you can see from the log it still comes back 
as false.

I have tried including Wow6432Node in the 64bit path but it didn't make any 
difference.

I would appreciate any help!! 



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/QuickTime-is-installing-when-it-is-already-installed-tp7600756p7600799.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you need 
to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] how can I set InstallCondition based on whether my bundle is 32 or 64 bit?

[Hoover, Jacob]

1. Strange, though on a version I would compare it to a very.x.y.z

2. My way is the old way, and will fail if the product has been patched. 
Upgrade code should be more reliable.

3. Poke around from 
http://blogs.msdn.com/b/astebner/archive/2007/01/16/mailbag-how-to-detect-the-presence-of-the-vc-8-0-runtime-redistributable-package.aspx?Redirected=true
 I know it's the wrong version but he should have a post for the version you 
want.

4. Possible, but it would imply downloading the exe every time. You're also 
relying on their detection, which should be solid but it is wasted do/execution 
time.

Sent from my phone

On Jul 2, 2015, at 1:11 PM, David Burson 
david_bur...@ntm.orgmailto:david_bur...@ntm.org wrote:

oops -

3. “this site” is 
https://allthingsconfigmgr.wordpress.com/2013/12/17/visual-c-redistributables-made-simple/

4. “this post” is 
http://stackoverflow.com/questions/23832713/how-to-check-that-visual-c-2013-redistributable-is-already-installed-using-wix

On Jul 2, 2015, at 1:46 PM, David Burson 
david_bur...@ntm.orgmailto:david_bur...@ntm.orgmailto:david_bur...@ntm.org
 wrote:

Thanks Jacob,

Btw, I’m using WiX 3.9 R2, hoping to go to 3.10 when it is stable.

Your solution appears to work, but I have 4 questions about it:

1. The log is strange when I upgrade.  I installed version 1.1.4 of my app, 
then built version 1.1.5, and installed it.  In the log for the upgrade, the 
pertinent lines (I think) are, after detect begin:

Setting version variable 'VCInstalledx86 ' to value ’12.0.21005.0'

and a few lines down:

Plan begin, 3 packages, action: Install
Condition 'NOT VCInstalledx86' evaluates to true.

I would have expected  it to evaluate to false - so I’m not sure what’s going 
on?


2. In ProductSearch, I’m using the ProductCode attribute.  However, I notice in 
the WiX Toolset 
documentationhttp://wixtoolset.org/documentation/manual/v3/xsd/wix/productsearch.html,
 there is no ProductCode attribute for ProductSearch.  There is a required 
UpgradeCode.  Yet your solution works, so I assume the documentation is wrong?  
If so, should that be reported to someone?


3. I’m not clear what ProductCodes to use.  I’m using the 2013 versions.  I 
found this site, which for 2013 lists 2 guids for x64 and 2 for x86.  How can 
there be 2 product codes each?  What do I really need to check?


4. According to a comment on this post, it sounds like I don’t need to check at 
all - just run the appropriate vcredist, and it will do its own checking to see 
if it’s already there.  Is that true?


Also, in case it is useful to others, a few things I did to get this solution 
to build:

1. add attribute xmlns:util=http://schemas.microsoft.com/wix/UtilExtension” to 
the WiX element

2. delete the spaces in ? else ?

3. create an identical if..else at the same level as Chain for the 
ProductSearch’s, to get around this error:

error CNDL0203 : The Chain element contains an unsupported extension element 
'util:ProductSearch'.  The Chain element does not currently support extension 
elements. Is the util:ProductSearch element using the correct XML Namespace?

So in my Bundle element I have:

?if $(var.Platform) = x86 ?
util:ProductSearch Variable=VCInstalledx86  
ProductCode={13A4EE12-23EA-3371-91EE-EFB36DDFFF3E}/
?else?
util:ProductSearch Variable=VCInstalledx64  
ProductCode={929FBD26-9020-399B-9A7A-751D61F0B942}/
?endif?

Chain
?if $(var.Platform) = x86 ?
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe 
PerMachine=yes Permanent=yes Vital=yes Compressed=yes 
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalledx86/
?else?
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x64.exe 
PerMachine=yes Permanent=yes Vital=yes Compressed=yes 
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalledx64 /
?endif?

Thanks,
David

On Jul 1, 2015, at 5:49 PM, Hoover, Jacob 
jacob.hoo...@greenheck.commailto:jacob.hoo...@greenheck.commailto:jacob.hoo...@greenheck.commailto:jacob.hoo...@greenheck.com
 wrote:

You could use a preprocessor condition.  IE:

?if $(var.Bitness) = x86 ?
util:ProductSearch Variable=VCInstalled  ProductCode={}/
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x86.exe 
PerMachine=yes Permanent=yes Vital=yes Compressed=yes 
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalled/
? else ?
util:ProductSearch Variable=VCInstalled  ProductCode={}/
ExePackage SourceFile=$(var.KarteDir)\install\win\vcredist_x64.exe 
PerMachine=yes Permanent=yes Vital=yes Compressed=yes 
InstallCommand=/quiet /norestart InstallCondition=NOT VCInstalled /
?endif?



-Original Message-
From: David Burson [mailto:david_bur...@ntm.org]
Sent: Wednesday, July 01, 2015 2:37 PM
To: General discussion about the WiX toolset.
Subject: [WiX-users] how can I set InstallCondition based on whether my bundle 
is 32 or 64 bit?

Hi,

I have a single bundle.wxs I use when I’m creating either a 64-bit and a 32-bit 
installer for my app.  In my Chain, I have

Re: [WiX-users] QuickTime is installing when it is already installed.

[Hoover, Jacob]

It's an EXE package, so burn has no clue how to determine if it's installed or 
not.  Do you have a Reg/File/Msi search to determine if it's installed?  Also, 
I'd suggest using a specific variable for this.

Ex:
util:RegistrySearch Root=HKLM Key=SOFTWARE\Adobe\Adobe SVG Viewer\3.03 
Value=dir Variable=AdobeSvgViewerDirectory /
..
  ExePackage
Id=AdobeSVGViewer
...
DetectCondition=AdobeSvgViewerDirectory
InstallCondition=(VersionNT lt; v6.0 OR VersionNT64 lt; v6.0) AND 
NOT(AdobeSvgViewerDirectory) /
   /PackageGroup

-Original Message-
From: garymonk [mailto:g...@gurudental.com] 
Sent: Wednesday, July 01, 2015 12:50 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] QuickTime is installing when it is already installed.

I have a bundle that installs a number of prerequisites. One of those prereqs 
is QuickTime. 

Here is the code...
ExePackage Id=Package_QuickTime Cache=no Compressed=$(var.Compressed)
Description=Apple QuickTime 7
DownloadUrl=$(var.DownloadRepo)/{2}
SourceFile=..\Prerequisites\QuickTimeInstaller.exe
Name=Prerequisites\QuickTimeInstaller.exe
Permanent=yes DisplayName=Apple QuickTime 7
InstallCondition=NOT Installed /ExePackage

As you can see the install condition is NOT installed.

Why would QuickTime install even when the install condition says it should only 
be installed when it is not installed?

Thanks,
Gary



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/QuickTime-is-installing-when-it-is-already-installed-tp7600756.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that you need 
to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Auto-Generated GUIDs

[Hoover, Jacob]

http://www.joyofsetup.com/2009/12/31/simplifying-wix-component-authoring/


-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com] 
Sent: Thursday, June 18, 2015 8:16 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Auto-Generated GUIDs

From the link provided:


Correct where “goes” means “installs to”.

...

1. I found the implementation at `Uuid.NewUuid` in `src\tools\wix\Uuid.cs`.

2. Seems to be derived from the full KeyPath of the component. So as long as 
everything goes to the same place the GUID will not change.


I have read elsewhere in this forum, but I can't find the link now, that the 
'source' of a keypath file is a factor in the auto-generated guids, and I have 
experienced it being a factor.  However since you are using registry keys, I 
probably should not have added that general information.  I think both the full 
path of the keypath and the Id of the keypath, which may have been generated, 
are factors.  The generated guid is intended to be stable from build to build 
if the keypath and Id have not changed.

The sample posted leaves it to Wix to imply a KeyPath.   The chm indicates:
If KeyPath is not set to 'yes' for the Component or for a child Registry value 
or File, WiX will look at the child elements under the Component in sequential 
order and try to automatically select one of them as a key path.
Allowing WiX to automatically select a key path can be dangerous because adding 
or removing child elements under the Component can inadvertently cause the key 
path to change, which can lead to installation problems. 

you might want to specify the RegistryKey as the KeyPath, or use the 
one-resource-per-component pattern.



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

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

Re: [WiX-users] Windows Installer Cache - gone!

[Hoover, Jacob]

I'd also use external CAB's on all the MSI's you create so that your MSI's 
don't bloat the cache.

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com] 
Sent: Thursday, June 18, 2015 3:27 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Windows Installer Cache - gone!

Yeah, nothing to be done but to be clear  you might be unhappily surprised when 
the original MSI is requested during an upgrade because Windows Installer can't 
find the it in the cache.

Might want to stop deleting the cache. smile/

___
 FireGiant  |  Dedicated support for the WiX toolset  |  
http://www.firegiant.com/

-Original Message-
From: Walter Dexter [mailto:wfdex...@gmail.com] 
Sent: Thursday, June 18, 2015 10:26 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Windows Installer Cache - gone!

I don't do patches. Nobody does patches for this platform - it isn't worth the 
effort.

The MSIs aren't installed interactively - ever. Strictly Microsoft system 
management tools and our own home-grown extensions. We have the worst case of 
NIH syndrome ever.

Thanks for the feedback, mostly just wanted a sanity check from someone more 
experienced with this stuff that there's really nothing to be done. :)

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

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

Re: [WiX-users] Removing files as part of upgrade

[Hoover, Jacob]

If the app is modifying the files, the RemoveFIle should be in the MSI for the 
version that installed the file. The real question is why is your app modifying 
the installed files.  Could it not be changed to use the default file if an 
override didn't exist?  Then have the app copy the installed file to a 
per-user/per-machine common app folder, for the customizations?

If you are renaming files, as long as you follow the component rules, a major 
upgrade should remove the old file and apply the new one.  (IE, the old file 
and new file, should not share the same component ID.)

-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] 
Sent: Friday, June 12, 2015 10:48 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Removing files as part of upgrade

We have some applications which will be changing the actual files they install 
as they upgrade in the sense that new names will be used.

I notice that my default way of doing the upgrades does not *delete* the old 
ones. (I.e., creating a new WXS with the same upgrade code as the old one but 
with new components, etc.) What's the best way to go about doing this? Do I 
have to put in a RemoveFile for everything?? What if the directory changes?



Keith Douglas
Programmer Analyst | Programmeur analyste Questionnaire Development Services - 
CAI Social | Services de développement de questionnaires - IAO Social Jean 
Talon Building | Immeuble Jean-Talon / Floor | Étage 4 A-3 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-854-5589 Facsimile | Télécopieur 613-951-4674 
Government of Canada | Gouvernement du Canada 



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

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

Re: [WiX-users] Removing files as part of upgrade

[Hoover, Jacob]

* works well, and follows the component rules.

-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] 
Sent: Friday, June 12, 2015 12:32 PM
To: keith.doug...@statcan.gc.ca; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Removing files as part of upgrade

(Thanks to Rob's post, too.)

But: I am not sure why I read both the post, the WiX documentation (under 
Component), but it sounds like to me that the Guid attribute on Component is 
what is supposed to be stable, not the ComponentId.

Nevertheless, I have written a new mechanism for generating the ComponentIds 
for our front end, which will include the version of the package so when the 
product is upgraded we can generate a new one for each item.



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-854-5589 Facsimile | 
Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada 


-Original Message-
From: Douglas, Keith - CoSD/DSCo
Sent: June-12-15 12:03 PM
To: General discussion about the WiX toolset.
Subject: RE: Removing files as part of upgrade

Oh, you have to generate a new component ID? Is that the trick? I had forgotten 
that. Hm, that's going to be interesting for our front end thing to keep track 
of, since it makes componentids as it goes for everything so that the WXS can 
be automatically generated from a list of files and various rules and such.




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-854-5589 Facsimile | 
Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada 

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: June-12-15 11:57 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Removing files as part of upgrade

If the app is modifying the files, the RemoveFIle should be in the MSI for the 
version that installed the file. The real question is why is your app modifying 
the installed files.  Could it not be changed to use the default file if an 
override didn't exist?  Then have the app copy the installed file to a 
per-user/per-machine common app folder, for the customizations?

If you are renaming files, as long as you follow the component rules, a major 
upgrade should remove the old file and apply the new one.  (IE, the old file 
and new file, should not share the same component ID.)

-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca]
Sent: Friday, June 12, 2015 10:48 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Removing files as part of upgrade

We have some applications which will be changing the actual files they install 
as they upgrade in the sense that new names will be used.

I notice that my default way of doing the upgrades does not *delete* the old 
ones. (I.e., creating a new WXS with the same upgrade code as the old one but 
with new components, etc.) What's the best way to go about doing this? Do I 
have to put in a RemoveFile for everything?? What if the directory changes?



Keith Douglas
Programmer Analyst | Programmeur analyste Questionnaire Development Services - 
CAI Social | Services de développement de questionnaires - IAO Social Jean 
Talon Building | Immeuble Jean-Talon / Floor | Étage 4 A-3 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-854-5589 Facsimile | Télécopieur 613-951-4674 
Government of Canada | Gouvernement du Canada 



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

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

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

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

Re: [WiX-users] Download Msi or Exe with Bundle

[Hoover, Jacob]

No, Update/@Location points to a feed, such as 
http://wixtoolset.org/releases/feed/v3.10

If you aren't writing a custom BA, there isn't built in support for 
self-updates in WixSdtBA (it's in the engine thought).  I do have my own 
fork/branch that has WixStdBA doing self-updates, which you could have a look 
at from https://github.com/jchoover/wix3/tree/develop-3.9-WixStdBA  If you do 
have your own MBA, you can see how the WixBA does updates at 
https://github.com/wixtoolset/wix3/blob/develop/src/Setup/WixBA/UpdateViewModel.cs
 

Once 3.10 has its first RC, I'll also be merging those changes into a 3.10 
branch of mine.

-Original Message-
From: Shal Philipp [mailto:luc2...@inbox.ru] 
Sent: Thursday, June 11, 2015 1:16 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Download Msi or Exe with Bundle

Thanks!

I looked up this possibility - to self-update Bundle. But didn't find anything 
specific. Here in manual is not many information:
http://wixtoolset.org/documentation/manual/v3/xsd/wix/update.html

Is there some tutorial how to make self-update Bundle which I didn't find?
Is the only thing i should do - is to put lastest Bundle on web and write link 
in Location attribute of Update element?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Download-Msi-or-Exe-with-Bundle-tp7600586p7600606.html
Sent from the wix-users mailing list archive at Nabble.com.

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

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

Re: [WiX-users] Signing issue with Burn installer

[Hoover, Jacob]

Because the burn.exe gets modified during the bundle build, so any signature on 
it would be invalidated. 

-Original Message-
From: Rajesh Nagpal [mailto:rnag...@microsoft.com] 
Sent: Tuesday, June 09, 2015 4:54 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Signing issue with Burn installer

Thanks Phill for the response!

Using quot;%(SignBundleEngine.FullPath)quot; and 
quot;%(SignBundle.FullPath)quot;  returned the same value.

I'll work on getting the right command line versions of sign tool but unless I 
resolve the above issue, it will not work.

Does the file generated by running insignia -ib is the same as 
burn.exe(checked-in under wix toolset x86 folder) or is this something 
different?

You mentioned that pre-signing burn.exe will not work. Can you explain why?

Shouldn't the signed version of my bundle extract this signed version of 
burn.exe and everything should work magically?

Regards,
Rajesh





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Signing-issue-with-Burn-installer-tp7600563p7600581.html
Sent from the wix-users mailing list archive at Nabble.com.

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

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

Re: [WiX-users] Remove InstallShield Bootstrapper MSI

[Hoover, Jacob]

And if they aren't helpful, if you know the ID behind the version you are 
trying to remove, you could query the ARP data for the uninstall string 
property UninstallString and try to invoke that.

On my machine, I have both MSI and EXE variants.  If the one you are trying to 
replace is a MSI, then it would be simple to do by adding that into your new 
MSI's Upgrade table.  If it's an EXE, it's going to be more custom logic. If 
your last InstallShield exe doesn't contain the entire payload, you may be able 
to automate it by using that EXE with the command line params to uninstall it.

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Thursday, June 04, 2015 12:34 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Remove InstallShield Bootstrapper MSI

Why not ask in an InstallShiekd forum how the InstallShield upgrade mechanism 
works in the context of an upgrade?
---
Phil Wilson


On Wed, Jun 3, 2015 at 10:22 PM, Johri, Mohit IN BLR STS 
mohit.jo...@siemens.com wrote:
 Hi All,

 Did anyone got into the same kind of issue, please help.

 Thanks  Regards,
 Mohit

 -Original Message-
 From: Johri, Mohit IN BLR STS [mailto:mohit.jo...@siemens.com]
 Sent: Wednesday, June 03, 2015 7:13 PM
 To: General discussion about the WiX toolset.
 Subject: [WiX-users] Remove InstallShield Bootstrapper MSI

 Hi All,

 I am creating a CustomBA which will replace the existing install shield 
 Bootstrapper( I don't really know what it's called).

 We are installing the same number of MSI as the install shield use to do, so 
 no problem in that.
 All the MSI entries in the ARP are removed, as we are making MSI's  
 Visible=no.

 Only the Custom BA entry is available in the ARP along with the Install 
 shield Bootstrapper entry, both having the same name.
 Is there a way to remove the older Installshield Bootstrapper entry using 
 CustomBA ?

 Thanks  Regards,
 Mohit

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

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

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

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

Re: [WiX-users] automatic selection perUser/perMachine installation

[Hoover, Jacob]

Yes.  Sorry I read this as you were trying to get a burn bundle to morph 
between per-user and per-machine.

It should be possible, but UAC brings in interesting challenges. A user could 
be an admin, but not ran elevated.  I'd start by looking at 
https://msdn.microsoft.com/en-us/library/aa370852(v=vs.85).aspx and see if you 
can schedule an action to set the default option in the UI, but the issue is 
typically the UI sequence is ran un-elevated.

-Original Message-
From: Carles Pina i Estany [mailto:car...@pina.cat] 
Sent: Thursday, June 04, 2015 10:15 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] automatic selection perUser/perMachine installation


Is BA a Bootstrapper Application (a .exe) in this context?

I wanted to avoid a Bootstrapper application and just deliver the .msi, with 
the sensible defaults (perMachine if the user is an administrator or perUser 
otherwise).

On Jun/04/2015, Hoover, Jacob wrote:
 Fairly certain that WixStdBA doesn't support this today. As for if you could 
 write a custom BA, and modify the plan to accomplish this, I'm not certain.  
 
 -Original Message-
 From: Carles Pina i Estany [mailto:car...@pina.cat]
 Sent: Thursday, June 04, 2015 6:36 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] automatic selection perUser/perMachine 
 installation
 
 
 Hi,
 
 I'm not sure if this is possible, I'd like something like:
 (I'm using WixUI_Advanced but I could change by something else if
 needed)
 
 If an Administrator installs the MSI: I'd like that gets installed, by 
 default, perMachine (and the Administrator could change it).
 
 If a non-administrator installs the MSI: by default the perUser option should 
 be selected: and the user could change it and the the UAC dialog will appear 
 when needed.
 
 Is this possible at all?
 References to this are appreciated, indeed.
 
 Regards,
 
 --
 Carles Pina i Estany
   Web: http://pinux.info || Blog: http://pintant.cat
   GPG Key 0x8CD5C157
 
 --
  ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
  ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
--
Carles Pina i Estany
Web: http://pinux.info || Blog: http://pintant.cat
GPG Key 0x8CD5C157

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

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

Re: [WiX-users] automatic selection perUser/perMachine installation

[Hoover, Jacob]

Fairly certain that WixStdBA doesn't support this today. As for if you could 
write a custom BA, and modify the plan to accomplish this, I'm not certain.  

-Original Message-
From: Carles Pina i Estany [mailto:car...@pina.cat] 
Sent: Thursday, June 04, 2015 6:36 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] automatic selection perUser/perMachine installation


Hi,

I'm not sure if this is possible, I'd like something like:
(I'm using WixUI_Advanced but I could change by something else if
needed)

If an Administrator installs the MSI: I'd like that gets installed, by default, 
perMachine (and the Administrator could change it).

If a non-administrator installs the MSI: by default the perUser option should 
be selected: and the user could change it and the the UAC dialog will appear 
when needed.

Is this possible at all?
References to this are appreciated, indeed.

Regards,

--
Carles Pina i Estany
Web: http://pinux.info || Blog: http://pintant.cat
GPG Key 0x8CD5C157

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

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

Re: [WiX-users] Burn: how to elevate BA? (Manifest for Burn Bootstrapper [Continue])

[Hoover, Jacob]

The BA should never modify machine state.  What happens when your BA modifies 
state during an update, but then the user aborts the update?  If you modify 
state, you have to restore it.  You would also need to persist the rollback 
info across reboot boundaries.

Windows Installer can be viewed as a pain, but it is that way for a reason.  
It's transactional, and ensures a consistent state.  To think it's easier to 
manage this state, than it is to just provide the MSI what it needs and let 
Windows Installer handle all the ugly little details, is short sighted.

-Original Message-
From: Jiri Tomek [mailto:katu...@volny.cz] 
Sent: Friday, May 29, 2015 1:48 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Burn: how to elevate BA? (Manifest for Burn 
Bootstrapper [Continue])

It's not fixed key. I use bootstrapper to gather various configuration 
information from user which are then used to configure product and not all of 
then are passed to MSIs. Adding logic to MSI to be able to get this information 
via MSI properties, parse it and then store it in registry is just unreasonably 
complex compared to few lines in .NET code in BS.
What I ended up doing is that I detect requirement for elevation in BS and I 
let BS start itself as elevated process using runas verb. I feel really bad 
about it but so far that is far more maintainable than pushing logic to MSI 
custom actions.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-how-to-elevate-BA-Manifest-for-Burn-Bootstrapper-Continue-tp6855345p7600495.html
Sent from the wix-users mailing list archive at Nabble.com.

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

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

Re: [WiX-users] Localization doesn't work from ARP

[Hoover, Jacob]

Or just compress the language files so they are included with the bundle.

-Original Message-
From: Johri, Mohit IN BLR STS [mailto:mohit.jo...@siemens.com] 
Sent: Wednesday, May 27, 2015 9:38 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Localization doesn't work from ARP

Hi Phill,

I have a customBA, which consumes the localization language file based on the 
language selected from the combobox in the UI, these files are stored into 
Localization folder as can be seen from the below code.

Payload Name=Localization\LGG\CustomBA\CustomBA.de 
SourceFile=..\..\Localization\LGG\CustomBA\CustomBA.de Compressed=no / 
Payload Name=Localization\LGG\CustomBA\CustomBA.en-US 
SourceFile=..\..\Localization\LGG\CustomBA\CustomBA.en-US Compressed=no /

These payload are actually outside the BootstrapperApplicationRef. Localization 
works fine, if I open the Setup.exe directly not from the ARP.
But my problem is that while clicking on the uninstall button from the ARP( 
Programs and Features), the Bootstrapper opens but localization doesn't work, I 
guess it because the language files are not cached.

Is there any way in which we can get these files cached so that localization 
works or some other way.

Thanks  Regards,
Mohit

-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Wednesday, May 27, 2015 7:01 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Localization doesn't work from ARP

My BA supports 13 cultures, and I am not seeing any problem when I use the ARP 
to launch my bundle.  What kind of BA did you create and how does your BA 
detect the culture?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Localization-doesn-t-work-from-ARP-tp7600421p7600460.html
Sent from the wix-users mailing list archive at Nabble.com.

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

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

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

Re: [WiX-users] Hiding UpgradeCode Attribute Warning

[Hoover, Jacob]

So in your cleanup efforts, why not cut ties with the old versions completely?  
Put it in a new and unique folder, and handle the common files.  I don't know 
if any of them use COM, the GAC,  or if you have access or the ability to 
request a rebuild of the application.  For COM, I'd suggest eliminating the 
inter-dependency of multiple versions (since it sounds like the rules of COM 
weren't followed for backwards compatibility) by using a manifest to do 
Reg-Free COM. If you need to add a manifest without rebuilding the application, 
mt.exe from the Windows SDK's can do that.

-Original Message-
From: Griesshammer, Christoph (GE Healthcare) 
[mailto:christoph.griessham...@ge.com] 
Sent: Tuesday, May 26, 2015 11:02 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning

Jacob,

I'm already sabotaged. The scenario is:

Another team developed an InstallShield package for an msi, and a Wise package 
for an exe. The packages didn't even match in what they were delivering (a 
headache in itself). They didn't follow the installer rules. What they did, was 
deliver to a temp directory, then ran a custom action .bat file to copy the 
files to a version directory within the main directory for the product. But 
there's also common files between versions, so there's logic about whether to 
replace those or not. Anyways, it breaks all the rules about how to specify 
components, so the installer has no idea of what files are actually there.

So there were so many installation defects, that now we had to come in to clean 
up their install. But we can't reuse GUIDs and their program doesn't even show 
up in the add/remove programs.

And just to make everything more fun, you can have multiple versions of the 
product installed at the same time.

It's causing a headache, because you can't do an upgrade, but we can't even 
follow normal rules of adding shared GUIDs to components between versions. We 
have resorted to completely removing the uninstall option if a legacy product 
is installed (ridiculous, right?).

So I need to suppress the upgrade, because the idea of an upgrade is really 
just an install of a different version.

If you have a way better way to go around this, please feel free to educate me. 
Because this is also my first WiX project, and I'm just working with what I got.

Christoph

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Tuesday, May 26, 2015 11:52 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning

Why would you want to intentionally sabotage yourself?  Provide an UpgradeCode, 
and just don't release any upgrades.   

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Tuesday, May 26, 2015 10:33 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning

Provide the UpgradeCode and suppress upgrades in the MajorUpgrade element.

--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise 
Notification Service Jack Henry  Associates, Inc.® | Lenexa, KS  66214 | Ext:  
431050 |jocoo...@jackhenry.com



-Original Message-
From: Griesshammer, Christoph (GE Healthcare) 
[mailto:christoph.griessham...@ge.com]
Sent: Tuesday, May 26, 2015 10:27 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Hiding UpgradeCode Attribute Warning

The e-mail below is from an external source.  Please do not open attachments or 
click links from an unknown or suspicious origin.

I am getting the following error for my project:

The Product/@UpgradeCode attribute was not found; it is strongly recommended to 
ensure that this product can be upgraded.

I am WELL aware of the following:

1)  You should always have an upgrade code, even if you don't plan on 
upgrading. But for this specific product, I am positive I do not want the 
upgrade code. We will never support an upgrade for this product, due to other 
incredibly obnoxious issues.

2)  This is a warning, not an error. Unfortunately, for releasing we MUST 
specify to treat warnings as errors, so I need to mitigate this error.

My question is, how do I suppress this error since it doesn't have an error 
code, just a message? Or is there anything to include in the code to mitigate 
the error?

Thank you,

Christoph Griesshammer
GE Healthcare IT
Software Engineer

E: christoph.griessham...@ge.commailto:christoph.griessham...@ge.com
http://www.gehealthcare.comhttp://www.gehealthcare.com/

116 Huntington Ave
Boston, MA, USA
02116-5744

GE Imagination at Work

--
One dashboard for servers and applications across Physical-Virtual-Cloud Widest 
out-of-the-box monitoring support with 50+ applications Performance metrics, 
stats and reports that give you Actionable Insights Deep dive visibility

Re: [WiX-users] Hiding UpgradeCode Attribute Warning

[Hoover, Jacob]

Why would you want to intentionally sabotage yourself?  Provide an UpgradeCode, 
and just don't release any upgrades.   

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com] 
Sent: Tuesday, May 26, 2015 10:33 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning

Provide the UpgradeCode and suppress upgrades in the MajorUpgrade element.

--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise 
Notification Service Jack Henry  Associates, Inc.® | Lenexa, KS  66214 | Ext:  
431050 |jocoo...@jackhenry.com



-Original Message-
From: Griesshammer, Christoph (GE Healthcare) 
[mailto:christoph.griessham...@ge.com]
Sent: Tuesday, May 26, 2015 10:27 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Hiding UpgradeCode Attribute Warning

The e-mail below is from an external source.  Please do not open attachments or 
click links from an unknown or suspicious origin.

I am getting the following error for my project:

The Product/@UpgradeCode attribute was not found; it is strongly recommended to 
ensure that this product can be upgraded.

I am WELL aware of the following:

1)  You should always have an upgrade code, even if you don't plan on 
upgrading. But for this specific product, I am positive I do not want the 
upgrade code. We will never support an upgrade for this product, due to other 
incredibly obnoxious issues.

2)  This is a warning, not an error. Unfortunately, for releasing we MUST 
specify to treat warnings as errors, so I need to mitigate this error.

My question is, how do I suppress this error since it doesn't have an error 
code, just a message? Or is there anything to include in the code to mitigate 
the error?

Thank you,

Christoph Griesshammer
GE Healthcare IT
Software Engineer

E: christoph.griessham...@ge.commailto:christoph.griessham...@ge.com
http://www.gehealthcare.comhttp://www.gehealthcare.com/

116 Huntington Ave
Boston, MA, USA
02116-5744

GE Imagination at Work

--
One dashboard for servers and applications across Physical-Virtual-Cloud Widest 
out-of-the-box monitoring support with 50+ applications Performance metrics, 
stats and reports that give you Actionable Insights Deep dive visibility with 
transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution is strictly prohibited. If you have received this message in 
error, please immediately advise the sender by reply email and delete all 
copies.


--
One dashboard for servers and applications across Physical-Virtual-Cloud Widest 
out-of-the-box monitoring support with 50+ applications Performance metrics, 
stats and reports that give you Actionable Insights Deep dive visibility with 
transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Hiding UpgradeCode Attribute Warning

[Hoover, Jacob]

To say that you don't' have time to do it right because the other team is too 
busy fixing bugs and adding features is planning to fail. If the application is 
using and deploying custom COM objects, reg-free is the only way you are going 
to be able to support multiple versions on the same machine. I would start by 
ignoring all of the existing installs, start fresh in a new folder. 

To support multiple versions, you'll need to auto-gen the UpgradeCode, and 
either auto-gen the component ID's, or change the paths so that the * 
component IDs get updated for each version.  You'll also need to deploy them 
to a version specific installation folder.


-Original Message-
From: Griesshammer, Christoph (GE Healthcare) 
[mailto:christoph.griessham...@ge.com] 
Sent: Tuesday, May 26, 2015 11:22 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning

We have most definitely considered that. But then comes the next issue. In 
order to make those changes, we need to make application changes. But we can't 
do that because the other team is so busy still fixing other defects and adding 
new features, that we can hardly coordinate enough time to talk about the 
installer, let alone talk about changing the application. Also, we have 
customers in the field that will be using the old version and new version on 
the same machine, so we can't make any changes to existing applications.

Christoph

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Tuesday, May 26, 2015 12:13 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning

So in your cleanup efforts, why not cut ties with the old versions completely?  
Put it in a new and unique folder, and handle the common files.  I don't know 
if any of them use COM, the GAC,  or if you have access or the ability to 
request a rebuild of the application.  For COM, I'd suggest eliminating the 
inter-dependency of multiple versions (since it sounds like the rules of COM 
weren't followed for backwards compatibility) by using a manifest to do 
Reg-Free COM. If you need to add a manifest without rebuilding the application, 
mt.exe from the Windows SDK's can do that.

-Original Message-
From: Griesshammer, Christoph (GE Healthcare) 
[mailto:christoph.griessham...@ge.com]
Sent: Tuesday, May 26, 2015 11:02 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning

Jacob,

I'm already sabotaged. The scenario is:

Another team developed an InstallShield package for an msi, and a Wise package 
for an exe. The packages didn't even match in what they were delivering (a 
headache in itself). They didn't follow the installer rules. What they did, was 
deliver to a temp directory, then ran a custom action .bat file to copy the 
files to a version directory within the main directory for the product. But 
there's also common files between versions, so there's logic about whether to 
replace those or not. Anyways, it breaks all the rules about how to specify 
components, so the installer has no idea of what files are actually there.

So there were so many installation defects, that now we had to come in to clean 
up their install. But we can't reuse GUIDs and their program doesn't even show 
up in the add/remove programs.

And just to make everything more fun, you can have multiple versions of the 
product installed at the same time.

It's causing a headache, because you can't do an upgrade, but we can't even 
follow normal rules of adding shared GUIDs to components between versions. We 
have resorted to completely removing the uninstall option if a legacy product 
is installed (ridiculous, right?).

So I need to suppress the upgrade, because the idea of an upgrade is really 
just an install of a different version.

If you have a way better way to go around this, please feel free to educate me. 
Because this is also my first WiX project, and I'm just working with what I got.

Christoph

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Tuesday, May 26, 2015 11:52 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning

Why would you want to intentionally sabotage yourself?  Provide an UpgradeCode, 
and just don't release any upgrades.   

-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: Tuesday, May 26, 2015 10:33 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Hiding UpgradeCode Attribute Warning

Provide the UpgradeCode and suppress upgrades in the MajorUpgrade element.

--
John Merryweather Cooper
Senior Software Engineer | Integration Development Group | Enterprise 
Notification Service Jack Henry  Associates, Inc.® | Lenexa, KS  66214 | Ext:  
431050 |jocoo...@jackhenry.com



-Original Message-
From: Griesshammer

Re: [WiX-users] R: Extend ProductSearch for working with Burn exe Package

[Hoover, Jacob]

I believe the confusion you are having stems from the usage of 
util:ProductSearch inside your BA. That search would mirror the functionality 
of the ProductSearch within a MSI, which only populates the Upgrade table in 
the MSI with the Upgrade code of a MSI.  Windows Installer only knows or cares 
about Windows Installer based installs, so it's going to use Msi* API's to 
query based on the upgrade code.

In short, util:ProductSearch is working as intended, but it isn't intended to 
work with a bundle upgrade code.



-Original Message-
From: Marco Tognacci [mailto:mark...@live.it] 
Sent: Sunday, May 17, 2015 4:10 PM
To: WiX - users
Subject: Re: [WiX-users] R: Extend ProductSearch for working with Burn exe 
Package

Is there any mistake in my code or is there a bug in the util:ProductSearch 
extension?How can I make this code working?Thanks

  From: mark...@live.it
  To: wix-users@lists.sourceforge.net
  Date: Wed, 13 May 2015 01:02:45 +0200
  Subject: Re: [WiX-users] R: Extend ProductSearch for working with 
  Burn exe Package
  
  I have used util:ProductSearch to detect condition for my BurnPackage, but 
  it doesn't work, I use the last official release 3.9R2, the variable 
  assigned is equal to 2 (absent) even if the package is installed (I can 
  check manually the registry and I can find the UpgradeCode of the package 
  in a variable BundleUpgradeCode inside the installed product sections)
  Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; 
  xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;Fragment  
util:ProductSearch UpgradeCode={----} 
  Variable=MyBurnPackage_Installed Result=state / PackageGroup 
  Id=MyBurnPackageGroup  ExePackage Id=MyBurnPackage Cache=no 
  Compressed=no Permanent=yes Vital=yes
  SourceFile=..\Externals\MyBurnPackage.exe Name=MyBurnPackage.exe
  DetectCondition=MyBurnPackage_Installed  2//PackageGroup  
  /Fragment  /Wix
  Is there any mistake in my code or is there a bug in the 
  util:ProductSearch extension?How can I make this code working?Thanks
  
   From: jocoo...@jackhenry.com
   To: wix-users@lists.sourceforge.net
   Date: Mon, 11 May 2015 12:52:57 +
   Subject: Re: [WiX-users] R: Extend ProductSearch for working with Burn
   exe Package
   
   I think there is some confusion.  1) util:ProductSearch works with 
   Burn/Bundle.  Whether it will do exactly what you want (as pointed out by 
   Phil) is another matter, but it does work.  2) the standard ProductSearch 
   is desiged to work in the WiX schema and is not suitable for Burn/Bundle. 
3) As is pointed out, there are very few limitations if you write a 
   custom BA.  That would be my recommendation too.
   
   --
   John Merryweather Cooper
   Senior Software Engineer | Integration Development Group | 
   Enterprise Notification Service Jack Henry  Associates, Inc.® | 
   Lenexa, KS  66214 | Ext:  431050 |jocoo...@jackhenry.com
   
   
   
   -Original Message-
   From: Marco Tognacci [mailto:mark...@live.it]
   Sent: Monday, May 11, 2015 2:06 AM
   To: General discussion about the WiX toolset.
   Subject: [WiX-users] R: Extend ProductSearch for working with Burn 
   exe Package
   
   I have user the Extension ProductSearch from UtilExtension, and this only 
   works for msi packages, any other suggestion?
   
   Inviata dal mio Windows Phone
   
   Da: Phill Hoglandmailto:phogl...@rimage.com
   Inviato: ‎09/‎05/‎2015 16:56
   A: 
   wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge
   .net
   Oggetto: Re: [WiX-users] Extend ProductSearch for working with 
   Burn exe Package
   
   ProductSearch element works only with msi package, is true of the 
   wix:ProductSearch (which can only be used in a msi context).  However in 
   another thread to answer your question John suggested that you look at 
   util:ProductSearch (which is a Bundle related WixExtension).
   
   I have not needed any of this when including a Burn bundle in a Burn 
   bundle.
   As others have responded, look at the RelatedBundle support already in 
   Burn.
   
   With regard to finding a Bundle from a non-wix application I have 
   previously detailed for you the approach that my legacy setup uses to to 
   find a child bundle (which relies on defining Bundle/@dep: ProviderKey, 
   getting the BundleId in the mba, and passing it to a chained MSI for 
   storage in a known location in the registry).  Also in other threads on 
   this issue Jacob has provided another approach related to using dutil 
   functions.
   
   I don't think that your current line of thinking, trying toextend a MSI 
   ProductSearch CA to work in Burn, is even possible.
   
   
   
   --
   View this message in context: 
   http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Exte
   nd-ProductSearch-for-working-with-Burn-exe-Package-tp7600271p76002
   72.html Sent from the 

Re: [WiX-users] Bootstrapper - Initializing phase very long

[Hoover, Jacob]

 Bundle log file would be much more telling of where the delay is.

-Original Message-
From: CALCEL Sebastien [mailto:sebastien.cal...@econocom-osiatis.com] 
Sent: Tuesday, May 12, 2015 7:58 AM
To: 'wix-users@lists.sourceforge.net'
Cc: BONNET Alexandre
Subject: [WiX-users] Bootstrapper - Initializing phase very long

Hi everyone,

We're struggling with a performance issue on our bootstrapper application.
Depends on the target machine (all with the same configuration), the init phase 
(when Initializing... is displayed) can be quick or very, very long (up to 10 
minutes !!)

This is odd, because we have another bootstrapper for another app, and 
everything is fine...

We can't find anything about this on the mailing list, nor on google.

Here our wxs :

?xml version=1.0 encoding=UTF-8?
Wix
  xmlns=http://schemas.microsoft.com/wix/2006/wi;
  xmlns:bal=http://schemas.microsoft.com/wix/BalExtension;
  xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;

  ?define version=5.0.0.0 ?
  ?define UpgradeCode={2B361216-3134-48D5-A0D3-FD12B47CF090} ? !--Upgrade 
code to use for EVEN release version (NEVER CHANGE)--
  !--?define UpgradeCode={2D355C2C-2A27-4203-83EE-8BA1186E1629} ?-- 
!--Upgrade code to use for ODD release version (ALWAYS CHANGE)--

   Bundle Name=TheApp Version=$(var.version) 
Manufacturer=TheManufacturer UpgradeCode=$(var.UpgradeCode) 
IconSourceFile=$(var.SolutionDir)Path\icon.ico
 BootstrapperApplicationRef 
Id=WixStandardBootstrapperApplication.RtfLicense
  bal:WixStandardBootstrapperApplication SuppressDowngradeFailure=no 
SuppressOptionsUI=yes ShowVersion=yes 
LicenseFile=$(var.SolutionDir)TheApp\License.rtf
  
LogoFile=$(var.SolutionDir)TheApp\icon.ico/
/BootstrapperApplicationRef

 Chain
  PackageGroupRef Id=NetFx45Redist/
  MsiPackage SourceFile=$(var.SolutionDir)ServiceSetup\ServiceSetup.msi 
Permanent=yes DisplayInternalUI=no Visible=yes /
  MsiPackage SourceFile=$(var.MultipleReportMsi.TargetDir)TheApp.msi 
Permanent=no DisplayInternalUI=yes Visible=no /
/Chain
   /Bundle
/Wix

If anyone could help us or at least give us a hint on where to search, that 
would be great!

Thanks in advance,

Sébastien.
--
One dashboard for servers and applications across Physical-Virtual-Cloud Widest 
out-of-the-box monitoring support with 50+ applications Performance metrics, 
stats and reports that give you Actionable Insights Deep dive visibility with 
transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to use RegistrySearch using a searching condition?

[Hoover, Jacob]

Custom Action or within your custom BA?

For the former I'd start with the functions from butil.cpp, though there still 
are future concerns about the potential for maintaining backwards and forwards 
compatibility.  

If you're doing this in a custom BA, have a look at the RelatedBundle element.

-Original Message-
From: Marco Tognacci [mailto:mark...@live.it] 
Sent: Thursday, May 07, 2015 2:21 PM
To: WiX - users
Subject: Re: [WiX-users] How to use RegistrySearch using a searching condition?

ProductSearch works only with msi packages, I need to have the same feature but 
with a Bundle Burn exe package,at this momento there is no extension for doing 
this so I 'm tring to search manually in the registry.


 From: jocoo...@jackhenry.com
 To: wix-users@lists.sourceforge.net
 Date: Thu, 7 May 2015 19:14:23 +
 Subject: Re: [WiX-users] How to use RegistrySearch using a searching 
 condition?
 
 See util:ProductSearch.
 
 --
 John Merryweather Cooper
 Senior Software Engineer | Integration Development Group | Enterprise 
 Notification Service Jack Henry  Associates, Inc.(r) | Lenexa, KS  
 66214 | Ext:  431050 |jocoo...@jackhenry.com
 
 
 
 -Original Message-
 From: Marco Tognacci [mailto:mark...@live.it]
 Sent: Thursday, May 7, 2015 2:04 PM
 To: WiX - users
 Subject: [WiX-users] How to use RegistrySearch using a searching condition?
 
 I need to search a registry key of this kind, where is present a GUID 
 with the ProductCode of an installed package that I don't know 
 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
 \{----}\
 I need to find the registry key based on the string defined inside it 
 with Name=BundleUpgradeCodeValue={MyUpgradeCode}
 where MyUpgradeCode is a fixed code that I Know.
 
 Is there any way for serarching all the registry key to search the one that 
 have inside a string BundleUpgradeCode={MyUpgradeCode} ???Is there any way 
 for serarch the registry key using a predicate or matching condition?
 Thanks. 
 --
  One dashboard for servers and applications across 
 Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ 
 applications Performance metrics, stats and reports that give you Actionable 
 Insights Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 NOTICE: This electronic mail message and any files transmitted with it 
 are intended exclusively for the individual or entity to which it is 
 addressed. The message, together with any attachment, may contain 
 confidential and/or privileged information.
 Any unauthorized review, use, printing, saving, copying, disclosure or 
 distribution is strictly prohibited. If you have received this message 
 in error, please immediately advise the sender by reply email and delete all 
 copies.
 
 
 --
  One dashboard for servers and applications across 
 Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 
 50+ applications Performance metrics, stats and reports that give you 
 Actionable Insights Deep dive visibility with transaction tracing 
 using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
One dashboard for servers and applications across Physical-Virtual-Cloud Widest 
out-of-the-box monitoring support with 50+ applications Performance metrics, 
stats and reports that give you Actionable Insights Deep dive visibility with 
transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Fade out?

[Hoover, Jacob]

This forum is for Windows Installer XML (WiX) related questions.  I suspect 
your intent was to contact the good folks  here 
https://www.wix.com/support/html5/forum/  .

-Original Message-
From: Jason Ohler [mailto:jasonoh...@gmail.com] 
Sent: Tuesday, May 05, 2015 11:26 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Fade out?

Hello. I want some text to appear, have it linger for a few seconds, and then 
have it disappear. There does not seem to be a way to do this with WIX tools at 
the moment, so I need some HMTL code or CSS code to do it. 
Does anyone have code that would do this?

And can anyone tell me why, when I put CSS code in the HTML editor, what 
results is simply showing the CSS code, rather than executing it? Thank you.
--
Jason
--
One dashboard for servers and applications across Physical-Virtual-Cloud Widest 
out-of-the-box monitoring support with 50+ applications Performance metrics, 
stats and reports that give you Actionable Insights Deep dive visibility with 
transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get security info for object

[Hoover, Jacob]

Seems relevant 
http://stackoverflow.com/questions/28588729/wix-msi-fails-when-setting-permissions-on-network-path-utilpermissionex

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: Tuesday, May 05, 2015 12:32 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get 
security info for object

If it's accessing a network share, will the local system account have 
permissions to the file?

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com]
Sent: Tuesday, May 05, 2015 11:20 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get 
security info for object

ERROR_ACCESS_DENIED. Permissions are such that not even the Windows Installer 
can access the file. SYSTEM removed?

_
 Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: Mohamed Yasir [mailto:yasirmohame...@gmail.com]
Sent: Monday, May 4, 2015 9:14 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get 
security info for object

Hi,

I have seen this in my MSI log files but not really sure what this means: 

MSI (s) (A8:C8) [08:52:32:880]: Hello, I'm your 32bit Elevated custom action 
server.
ExecSecureObjects:  Error 0x80070005: failed to get security info for
object: \\GBBED01FI01\HOME01\GBCO0101\My Documents\Visual Studio 
2010\Templates\ProjectTemplates\Visual C#\ CustomAction ExecSecureObjects 
returned actual error code 1603 (note this may not be 100% accurate if 
translation happened inside sandbox)

Regards,
Mohamed Yasir K

--
One dashboard for servers and applications across Physical-Virtual-Cloud Widest 
out-of-the-box monitoring support with 50+ applications Performance metrics, 
stats and reports that give you Actionable Insights Deep dive visibility with 
transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
One dashboard for servers and applications across Physical-Virtual-Cloud Widest 
out-of-the-box monitoring support with 50+ applications Performance metrics, 
stats and reports that give you Actionable Insights Deep dive visibility with 
transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get security info for object

[Hoover, Jacob]

If it's accessing a network share, will the local system account have 
permissions to the file?

-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com] 
Sent: Tuesday, May 05, 2015 11:20 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get 
security info for object

ERROR_ACCESS_DENIED. Permissions are such that not even the Windows Installer 
can access the file. SYSTEM removed?

_
 Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: Mohamed Yasir [mailto:yasirmohame...@gmail.com]
Sent: Monday, May 4, 2015 9:14 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ExecSecureObjects: Error 0x80070005 - failed to get 
security info for object

Hi,

I have seen this in my MSI log files but not really sure what this means: 

MSI (s) (A8:C8) [08:52:32:880]: Hello, I'm your 32bit Elevated custom action 
server.
ExecSecureObjects:  Error 0x80070005: failed to get security info for
object: \\GBBED01FI01\HOME01\GBCO0101\My Documents\Visual Studio 
2010\Templates\ProjectTemplates\Visual C#\ CustomAction ExecSecureObjects 
returned actual error code 1603 (note this may not be 100% accurate if 
translation happened inside sandbox)

Regards,
Mohamed Yasir K

--
One dashboard for servers and applications across Physical-Virtual-Cloud Widest 
out-of-the-box monitoring support with 50+ applications Performance metrics, 
stats and reports that give you Actionable Insights Deep dive visibility with 
transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSI packages download and Firewall/Proxy settings

[Hoover, Jacob]

So you are using WixStdBA or a custom BA?  Do you know what the 
filter/proxy/firewall is responding with?  What happens when you try to browse 
the exact same download link within the browser?


From: Mohamed Yasir [yasirmohame...@gmail.com]
Sent: Monday, April 13, 2015 3:42 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MSI packages download and Firewall/Proxy settings

Hi,

Could you please update any idea on this?

Regards,
Mohamed Yasir K



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-packages-download-and-Firewall-Proxy-settings-tp7599503p7599920.html
Sent from the wix-users mailing list archive at Nabble.com.

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSI packages download and Firewall/Proxy settings

[Hoover, Jacob]

If your browser is getting a 403 without ever prompting for authentication, 
then I'm at a loss as to what you'd expect WiX to be able to do.  If the server 
would respond with a 401/407 code, then the engine would prompt for 
credentials.  Are you sure you have the URL correct?  Is this firewall/proxy 
filtering the contents of web requests (and basically 403'ing any request for 
an exe or MSI)?

-Original Message-
From: Mohamed Yasir [mailto:yasirmohame...@gmail.com] 
Sent: Monday, April 13, 2015 6:12 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MSI packages download and Firewall/Proxy settings

Hi,

I am using Custom BA. While trying to browse downloadlink in browser, it shown 
below error.

Failed to load resource: the server responded with a status of 403 (Forbidden)

Regards,
Mohamed Yasir K





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-packages-download-and-Firewall-Proxy-settings-tp7599503p7599923.html
Sent from the wix-users mailing list archive at Nabble.com.

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own 
process in accordance with the BPMN 2 standard Learn Process modeling best 
practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ 
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to run exe with admin privileges by default?

[Hoover, Jacob]

Burn will elevate once, when it needs to. Why would you want to elevate on 
first run?  It's not good practice/design, and hacking the manifest on the 
bundle is definitely not something the toolset is going to support. (Read that 
as if you have any install issues, don't expect much help from here...)


-Original Message-
From: Aaron Newton [mailto:aaron.new...@gmail.com] 
Sent: Thursday, April 09, 2015 8:35 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] How to run exe with admin privileges by default?

Hello Mohamed,

There's an example of elevating privileges here:

http://stackoverflow.com/a/8721481/201648

Does that solve your problem?

Regards,
Aaron

On Thu, Apr 9, 2015 at 10:05 PM, Mohamed Yasir yasirmohame...@gmail.com
wrote:

 Hi,

 Could you please update any idea on this?

 Regards,
 Mohamed Yasir K



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-r
 un-exe-with-admin-privileges-by-default-tp7599864p7599871.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
  BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT 
 Develop your own process in accordance with the BPMN 2 standard Learn 
 Process modeling best practices with Bonita BPM through live exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own 
process in accordance with the BPMN 2 standard Learn Process modeling best 
practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ 
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using burn to download, unzip, install package

[Hoover, Jacob]

Not the best choice by the 3rd party vendor, but you can work around it with an 
exe pakage with multiple Payload elements inside...

ExePackage ...
Payload .../
Payload .../
Payload .../
All 208 of them...
/ExePackage

Just keep the relative paths the same as what the zip extracts to, and burn 
should cache them in that same structure.

-Original Message-
From: Leor Greenberger [mailto:maverick0...@yahoo.com] 
Sent: Thursday, April 02, 2015 1:42 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Using burn to download, unzip, install package

I guess the only issue is that when you extract their package, that in addition 
to the setup.exe file, there are 35 folders and 208 supporting files. I believe 
I misspoke when I said that I could use Burn to repackage this into a single 
file (because I would just run into the same issue I have now). I think I will 
need to use something else (I am not sure) to repackage it but also in a way 
where Burn is able to pass some command line switch arguments to the setup.exe 
file that is contained within.




- Original Message -
From: Hoover, Jacob jacob.hoo...@greenheck.com
To: General discussion about the WiX toolset. wix-users@lists.sourceforge.net
Cc: 
Sent: Thursday, April 2, 2015 2:21 PM
Subject: Re: [WiX-users] Using burn to download, unzip, install package

Or just download and extract their self-extracting installer, extract it, and 
place it on a web server you control (no need to bundle it).  Then in your 
bundle you just reference that payload.  You're still going to have to update 
your bundle when you decide to release/approve an updated version of their 
install with your application.

-Original Message-
From: Leor Greenberger [mailto:maverick0...@yahoo.com]
Sent: Thursday, April 02, 2015 1:15 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Using burn to download, unzip, install package

Maybe then what I can do is download their package, extract it, and create a 
separate Burn project to package, build and upload it to a server I control. 
The only downside is I would have to manually redo this whenever the 3rd party 
releases an updated package.




- Original Message -
From: Rob Mensching r...@firegiant.com
To: General discussion about the WiX toolset. wix-users@lists.sourceforge.net
Cc: 
Sent: Thursday, April 2, 2015 1:48 PM
Subject: Re: [WiX-users] Using burn to download, unzip, install package

I would let Burn do all the downloading but if you can't just create process 
the package, then you'll have to write something that can be create processed 
then do the multiple steps.

For example, how would Burn know what to do here? It's all custom... which 
basically comes down to Don't do that but you have to convince the 3rd party 
to improve their installation story.

_
Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: maverick02 maverick02 [mailto:maverick0...@yahoo.com]
Sent: Thursday, April 2, 2015 10:14 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Using burn to download, unzip, install package

Thank you Rob for the quick reply. Just to be clear, this package that I am 
bundling is not mine, but is provided by a 3rd party. It is also quite large 
(at about 70 MB) and so it would be nice if it would download only on demand 
when its not yet already installed. Are my options essentially:

1) Ship with the extracted setup.exe in the bundle.

or

2) Write a .NET library to perform the downloading, extraction, and 
installation?

Thanks.




- Original Message -
From: Rob Mensching r...@firegiant.com
To: General discussion about the WiX toolset. wix-users@lists.sourceforge.net
Cc: 
Sent: Thursday, April 2, 2015 12:51 PM
Subject: Re: [WiX-users] Using burn to download, unzip, install package

I'd consider shipping the setup.exe (and any support files) in the bundle 
without the archive wrapper.

_
Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: maverick02 maverick02 [mailto:maverick0...@yahoo.com]
Sent: Thursday, April 2, 2015 9:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Using burn to download, unzip, install package

Hi Everyone,


I am looking for some guidance on doing the following. I want to bundle a 
prerequisite package that can be downloaded from a url at install time. The 
problem is that this package comes as a self-extracting Winzip archive and if 
the installation is to be silent, I need to do it in two stages:
1. Extract the archive silently to a folder.
2. Run the extracted Setup.exe with some command line switches.


It's not clear to me how one would do this with Burn without having a .NET 
dependency. Any ideas?

Thanks.
Leor

Re: [WiX-users] Using burn to download, unzip, install package

[Hoover, Jacob]

Or just download and extract their self-extracting installer, extract it, and 
place it on a web server you control (no need to bundle it).  Then in your 
bundle you just reference that payload.  You're still going to have to update 
your bundle when you decide to release/approve an updated version of their 
install with your application.

-Original Message-
From: Leor Greenberger [mailto:maverick0...@yahoo.com] 
Sent: Thursday, April 02, 2015 1:15 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Using burn to download, unzip, install package

Maybe then what I can do is download their package, extract it, and create a 
separate Burn project to package, build and upload it to a server I control. 
The only downside is I would have to manually redo this whenever the 3rd party 
releases an updated package.




- Original Message -
From: Rob Mensching r...@firegiant.com
To: General discussion about the WiX toolset. wix-users@lists.sourceforge.net
Cc: 
Sent: Thursday, April 2, 2015 1:48 PM
Subject: Re: [WiX-users] Using burn to download, unzip, install package

I would let Burn do all the downloading but if you can't just create process 
the package, then you'll have to write something that can be create processed 
then do the multiple steps.

For example, how would Burn know what to do here? It's all custom... which 
basically comes down to Don't do that but you have to convince the 3rd party 
to improve their installation story.

_
Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: maverick02 maverick02 [mailto:maverick0...@yahoo.com]
Sent: Thursday, April 2, 2015 10:14 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Using burn to download, unzip, install package

Thank you Rob for the quick reply. Just to be clear, this package that I am 
bundling is not mine, but is provided by a 3rd party. It is also quite large 
(at about 70 MB) and so it would be nice if it would download only on demand 
when its not yet already installed. Are my options essentially:

1) Ship with the extracted setup.exe in the bundle.

or

2) Write a .NET library to perform the downloading, extraction, and 
installation?

Thanks.




- Original Message -
From: Rob Mensching r...@firegiant.com
To: General discussion about the WiX toolset. wix-users@lists.sourceforge.net
Cc: 
Sent: Thursday, April 2, 2015 12:51 PM
Subject: Re: [WiX-users] Using burn to download, unzip, install package

I'd consider shipping the setup.exe (and any support files) in the bundle 
without the archive wrapper.

_
Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: maverick02 maverick02 [mailto:maverick0...@yahoo.com]
Sent: Thursday, April 2, 2015 9:28 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Using burn to download, unzip, install package

Hi Everyone,


I am looking for some guidance on doing the following. I want to bundle a 
prerequisite package that can be downloaded from a url at install time. The 
problem is that this package comes as a self-extracting Winzip archive and if 
the installation is to be silent, I need to do it in two stages:
1. Extract the archive silently to a folder.
2. Run the extracted Setup.exe with some command line switches.


It's not clear to me how one would do this with Burn without having a .NET 
dependency. Any ideas?

Thanks.
Leor Greenberger

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and 

Re: [WiX-users] How does heat maintain consistent GUIDs?

[Hoover, Jacob]

I forget if it's the key path or not, but it uses the SHA checksum of a string 
based on a namespace GUID and the seed value.. Key path as the seed is very 
logical in that regards.

 On Mar 29, 2015, at 9:35 AM, John Cooper jocoo...@jackhenry.com wrote:
 
 I believe it uses an algorithm to generate the GUID based on the KeyPath, but 
 that's just from memory.
 
 --
 John Merryweather Cooper
 Senior Software Engineer | Integration Development Group | Continuing 
 Development
 Jack Henry  Associates, Inc.® | Lenexa, KS  66214 | Ext:  431050 
 |jocoo...@jackhenry.com
 
 
 
 -Original Message-
 From: Pat Blair [mailto:p...@daburu.net] 
 Sent: Sunday, March 29, 2015 9:12 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] How does heat maintain consistent GUIDs?
 
 I am curious to know how WiX keeps track of GUIDSs automatically generated 
 for files when we use HeatDirectory.
 
 For example, I have a project with the following in my .wixproj file...
 
 Target Name=BeforeBuild
PropertyGroup
  WixToolPathC:\SourceControl\WiX39\/WixToolPath
/PropertyGroup
HeatDirectory ToolPath=$(WixToolPath)
   Directory=C:\users\me\Desktop\SourceFiles
 
   ComponentGroupName=MyComponentGroup
   DirectoryRefId=INSTALLFOLDER
   AutogenerateGuids=true
   GenerateGuidsNow=false
   SuppressFragments=true
   SuppressRootDirectory=true
   PreprocessorVariable=var.SourceFilesDir
   OutputFile=Components.wxs /
  /Target
 
 If I set AutogenerateGuids=true, my output file contains components like
 this:
 
 Component Id=cmpA609F30B9E3AECCDEE4D779C8B7308ED Guid=*
File Id=fil314398091041DF4762128892E7C98AA7
 KeyPath=yes Source=$(var.SourceFilesDir)\Sample1.txt /
/Component
 
 I note that Component/@Guid=*.
 
 After generating the .MSI, I open it with Orca and see that the ComponentId 
 for each Component (for each file) is the same.
 
 If I change my HeatDirectory element so that AutogenerateGuids=false and 
 GenerateGuidsNow=true, the ComponentIds seem to change.
 
 If I understand correctly, this is how it should work and by using 
 AutogenerateGuids, my installers can track a given file from install to 
 install.  I also think I understand that the GUIDs will remain the same so 
 long as the file names and paths to which they are installed doesn't change, 
 so this approach will let me do minor upgrades because the installers can 
 tell that two versions of a file from two different installers are the same 
 component because the ComponentIDs match.
 
 But what I'm wondering is:  How are these consistent GUIDs that I get when I 
 use AutogenerateGuids=true remembered from build to build?  Are they 
 generated by some algorithm that will always produce the same GUID for a file 
 with a given name installed to a given directory, or are they stored 
 somewhere.  And if they are stored somewhere, where are they stored?
 
 I'm hoping this isn't a dumb question, but I feel like I need to understand 
 this before using the feature so I don't make mistakes based on an incomplete 
 comprehension of what's happening behind-the-scenes.
 
 Many thanks.
 --
 Dive into the World of Parallel Programming The Go Parallel Website, 
 sponsored by Intel and developed in partnership with Slashdot Media, is your 
 hub for all things parallel software development, from weekly thought 
 leadership blogs to news, videos, case studies, tutorials and more. Take a 
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 NOTICE: This electronic mail message and any files transmitted with it are 
 intended
 exclusively for the individual or entity to which it is addressed. The 
 message, 
 together with any attachment, may contain confidential and/or privileged 
 information.
 Any unauthorized review, use, printing, saving, copying, disclosure or 
 distribution 
 is strictly prohibited. If you have received this message in error, please 
 immediately advise the sender by reply email and delete all copies.
 
 
 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 

Re: [WiX-users] 3.7 vs. 3.9R2

[Hoover, Jacob]

You can't have them both installed at the same time, but they don't need to be 
installed in order to be able to build them.  My advice would be to upgrade to 
3.9R2, so you have the latest votive bits within Visual Studio, and use MSBuild 
to build your older applications with 3.7.

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


-Original Message-
From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] 
Sent: Friday, March 27, 2015 2:57 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] 3.7 vs. 3.9R2

Can WiX 3.7 and 3.9R2 live happily on the same machine? We're using 3.7 now but 
have a big project coming in where we should modernize a bit but not break some 
stuff ...



Keith Douglas
Programmer Analyst | Programmeur analyste Questionnaire Development Services - 
CAI Social | Services de développement de questionnaires - IAO Social Jean 
Talon Building | Immeuble Jean-Talon / Floor | Étage 4 A-3 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-854-5589 Facsimile | Télécopieur 613-951-4674 
Government of Canada | Gouvernement du Canada 



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Predicting Bootstrapper Cache Location

[Hoover, Jacob]

Did you define the property in you MSI and declare it as Secure?

Ex (with remember-me pattern in place):

Property Id=BUNDLEPROVIDERKEY Secure=yes
  RegistrySearch Id=FindBundleProviderKey Root=HKLM 
Key=SOFTWARE\$(var.ApplicationKeyPath) Name=BundleProviderKey Type=raw /
/Property
...
CustomAction Id=SaveCmdLineBUNDLEPROVIDERKEY 
Property=CMDLINE_BUNDLEPROVIDERKEY Value=[BUNDLEPROVIDERKEY] 
Execute=firstSequence /
CustomAction Id=SetFromCmdLineBUNDLEPROVIDERKEY 
Property=BUNDLEPROVIDERKEY Value=[CMDLINE_BUNDLEPROVIDERKEY] 
Execute=firstSequence /
...
  Custom Action='SaveCmdLineBUNDLEPROVIDERKEY' Before='AppSearch'/
  Custom Action='SetFromCmdLineBUNDLEPROVIDERKEY' 
After='AppSearch'CMDLINE_BUNDLEPROVIDERKEY/Custom

-Original Message-
From: Edwin Castro [mailto:egca...@gmail.com] 
Sent: Thursday, March 26, 2015 11:51 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Predicting Bootstrapper Cache Location

Jacob,

You mentioned something interesting that I can't get to work. I tried

Chain
  MsiPackage SourceFile=$(var.projectName.TargetPath)
MsiProperty Name=BUNDLEPROVIDERKEY Value=[WixBundleProviderKey]/
  /MsiPackage
/Chain

But BUNDLEPROVIDERKEY is always empty in the msi log.

Should I expect that to work?

--
Edwin  G. Castro


On Thu, Mar 26, 2015 at 7:52 AM, Hoover, Jacob jacob.hoo...@greenheck.com
wrote:

 To extend upon Phil's suggestion,
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-
 application-using-Bootstrapper-UI-Bundle-td7596579.html

 -Original Message-
 From: Phill Hogland [mailto:phogl...@rimage.com]
 Sent: Thursday, March 26, 2015 7:11 AM
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Predicting Bootstrapper Cache Location

 I described one approach in this  thread 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-Burn
 -managing-installed-products-after-initial-install-td7595346.html#a759
 5368
 
 .



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Predicti
 ng-Bootstrapper-Cache-Location-tp7599709p7599716.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
  Dive into the World of Parallel Programming The Go Parallel 
 Website, sponsored by Intel and developed in partnership with Slashdot 
 Media, is your hub for all things parallel software development, from 
 weekly thought leadership blogs to news, videos, case studies, 
 tutorials and more. Take a look and join the conversation now. 
 http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
  Dive into the World of Parallel Programming The Go Parallel 
 Website, sponsored by Intel and developed in partnership with Slashdot 
 Media, is your hub for all things parallel software development, from 
 weekly thought leadership blogs to news, videos, case studies, 
 tutorials and more. Take a look and join the conversation now. 
 http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




--
Edwin G. Castro
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades

[Hoover, Jacob]

If you just leave them alone WiX should generate stable GUID's for you assuming 
you don't rename them/change the paths( see -ag). I would not advise using heat 
for anything other than an initial generation of the WXS file.

-Original Message-
From: Tobias Markmann [mailto:tmarkm...@googlemail.com] 
Sent: Thursday, March 26, 2015 11:25 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with 
Upgrades

Hi Phil,

On Thu, Mar 26, 2015 at 4:22 PM, Phil Wilson phildgwil...@gmail.com wrote:

 An early sequencing of the upgrade (such as after InstallIntialize) is 
 more or less the same as uninstalling the old product then installing 
 the new one. Guids don't really matter much.

 After InstallExecute isn't like that. As an example: say every file 
 has a guid and a version or hash. The guid is reference counted up at 
 install time. Installing the new product after InstallExecute means 
 installing new files over old files following file replacement rules 
 (versions, hashes etc) and incrementing the ref count for the guids 
 being installed (which matters only for files in the same location).
 Then uninstall the old product, counting down its guid ref counts. If 
 all the files are the same and have matching guids then they all ref 
 count down to one and the files stay behind. If you don't follow 
 component rules then you install different guids even though they have 
 the same file name. When the old product is uninstalled those guids 
 count down to zero and the files are removed even though you just 
 installed them. Sometimes it helps to think of it all as installing 
 ref counted guids, not files, registry entries etc.  This may be what 
 you're seeing.

 So in this case there is no newer installation, there are only file 
 replacement rules, and guids that are no longer in use being deleted, 
 so the same guids must be used for the same files for this type of 
 upgrade to be successful.  The same is true of patches, minor 
 upgrades.


Thanks for this hint. I've opened the old version .msi and the new version .msi 
in Orca and indeed, the GUIDs were different for most files. As it happens our 
WiX code uses Heat to gather the list of files to install, which happens to 
generate the WiX XML for the components. We happen to use the options -nologo 
-gg -sfrag -suid -template fragment -dr ProgramFilesFolder
when calling heat.exe, and according to documentation -gg generates new GUIDs. 
This at least explains the current behavior.

Should I remove the -gg option parameter? Is there a way to have the GUID based 
on hash(project_name + filename_)?

Cheers,
Tobias
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Predicting Bootstrapper Cache Location

[Hoover, Jacob]

To extend upon Phil's suggestion, 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Updater-application-using-Bootstrapper-UI-Bundle-td7596579.html
  

-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com] 
Sent: Thursday, March 26, 2015 7:11 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Predicting Bootstrapper Cache Location

I described one approach in this  thread 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-Burn-managing-installed-products-after-initial-install-td7595346.html#a7595368
.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Predicting-Bootstrapper-Cache-Location-tp7599709p7599716.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with Upgrades

[Hoover, Jacob]

Sounds like you broke component rules somewhere...  Are your component ID's 
identical for the same files across MSI's?  Are you using  version info on the 
files in question, or is it falling back to timestamp and hash checking?

-Original Message-
From: Tobias Markmann [mailto:tmarkm...@googlemail.com] 
Sent: Thursday, March 26, 2015 7:08 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Keep Desktop Shortcuts and Pinned Task Bar Icons with 
Upgrades

Hi Rob,

On Thu, Mar 26, 2015 at 12:27 AM, Rob Mensching r...@firegiant.com wrote:

 Schedule your upgrade late and carefully adhere to the Component Rules.


Thanks for the hint. I googled a bit and read up things on MajorUpgrade 
scheduling [0] and Component Rules, including [1] and [2].

So I've tried scheduling the upgrade later. Specifically I've added 
Schedule=afterInstallExecute to the MajorUpgrade, see [4].

Now it seems to first overwrite the existing installation and then runs the 
uninstall process. The shortcut and pinned task bar icons are retained.
However the uninstall progress removes the overwritten files so that the 
shortcut points to a broken installation.

Why does it remove the now newer version installation files during uninstall?
I expected MSI to know that the files in the program folder are of a newer 
installation when it starts the uninstall process and only deletes files which 
haven't been replaced during installation.

Thanks in advance for any pointers and hints.

Cheers,
Tobias

[0]
http://wixtoolset.org/documentation/manual/v3/howtos/updates/major_upgrade.html
[1]
http://robmensching.com/blog/posts/2003/10/4/windows-installer-components-introduction/
[2] http://robmensching.com/blog/posts/2003/10/18/component-rules-101/
[3]
https://dl.dropboxusercontent.com/u/14672346/tmp/swift/swift_wix_install_msi_log.txt
[4]
https://github.com/swift/swift/blob/master/Swift/Packaging/WiX/Swift.wxs#L13
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [WIX]: Execute setup.exe from MSI package location (which is not packaged) using MSI.

[Hoover, Jacob]

Use burn...  Calling one installer from another installer is not supported.

https://msdn.microsoft.com/en-us/library/aa368010(v=vs.85).aspx

-Original Message-
From: Dileep S [mailto:dileep.sanamp...@gmail.com] 
Sent: Thursday, March 26, 2015 12:12 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] [WIX]: Execute setup.exe from MSI package location (which 
is not packaged) using MSI.

Hi All,

Execute setup.exe from MSI package location (which is not packaged) using MSI.

Step1: Created a c++ custom action to get the current directory and set the 
EXEPATH property.

Step2: Set the INSTALLDIR property to setup.exe parent folder path.

Step3: Added a custom action shown below to execute setup.exe.
CustomAction Id=InstallDRV Directory=INSTALLDIR  Execute=deferred
ExeCommand=[EXEPATH] -uninst $(var.ARGUMENT) Impersonate=no
Return=asyncNoWait /

Step4: In InstallExecuteSequence,
Custom Action=InstallDRV Before=InstallFilesNOT REMOVE ~= ALL/Custom

setup.exe is not running.

Please help me to solve this.

Regards,
Dileep
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Cannot install Wix - Wix39.exe

[Hoover, Jacob]

Do you have any antivirus/anti-malware software on the machine in question?  
Something is preventing LoadLibraryW from loading the UX from the temp folder.

-Original Message-
From: Sean Hall [mailto:r.sean.h...@gmail.com] 
Sent: Monday, March 23, 2015 9:00 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Cannot install Wix - Wix39.exe

The bundle extracts the BA DLL to %TEMP%\{BUNDLE_GUID}\.ba1.  My guess is that 
it's getting ERROR_ACCESS_DENIED (which is what 0x8007005 is) when doing the 
extraction.

On Mon, Mar 23, 2015 at 4:52 PM, ctludlow cludl...@gmail.com wrote:

 Trying to install Wix and I get the same failed log file for 
 wix38.exe, wix39.exe and wix40.exe.
 I also noticed that I can't run any setup.exe's that were created with wix.
 Visual Studio 2013 setup.exe gives me the same errors.
 Any one have any ideas on what to check on a system with this behavior?
 Tried installing as Administrator and from a command prompt that was 
 opened as Administrator.

 [19E4:1418][2015-03-23T12:32:38]i001: Burn v3.9.1208.0, Windows v6.1 
 (Build
 7601: Service Pack 1), path: C:\Download\Wix\wix39.exe, cmdline:
 '-burn.unelevated BurnPipe.{AA155F4B-A1C6-4E2D-8116-43D5C843B88A}
 {21A2F814-7C9E-4558-8B45-26A73880F63D} 9004 -l log.txt'
 [19E4:1418][2015-03-23T12:32:38]i000: Initializing string variable 
 'InstallFolder' to value '[ProgramFilesFolder]WiX Toolset v3.9'
 [19E4:1418][2015-03-23T12:32:38]i000: Setting string variable 
 'WixBundleLog'
 to value 'C:\Download\Wix\log.txt'
 [19E4:1418][2015-03-23T12:32:38]i000: Setting string variable 
 'WixBundleOriginalSource' to value 'C:\Download\Wix\wix39.exe'
 [19E4:1418][2015-03-23T12:32:38]i000: Setting string variable 
 'WixBundleOriginalSourceFolder' to value 'C:\Download\Wix\'
 [19E4:1418][2015-03-23T12:32:38]e000: Error 0x80070005: Failed to load 
 UX DLL.
 [19E4:1418][2015-03-23T12:32:38]e000: Error 0x80070005: Failed to load UX.
 [19E4:1418][2015-03-23T12:32:38]e000: Error 0x80070005: Failed while 
 running
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: InstallFolder = 
 C:\Program Files (x86)\WiX Toolset v3.9
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: ProgramFilesFolder = 
 C:\Program Files (x86)\
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: WixBundleAction = 4
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: WixBundleElevated = 1
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: WixBundleInstalled = 1
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: WixBundleLog = 
 C:\Download\Wix\log.txt
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: WixBundleManufacturer 
 = Outercurve Foundation
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: WixBundleName = WiX 
 Toolset
 v3.9.1208.0
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: 
 WixBundleOriginalSource = C:\Download\Wix\wix39.exe
 [19E4:1418][2015-03-23T12:32:38]i410: Variable:
 WixBundleOriginalSourceFolder = C:\Download\Wix\
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: WixBundleProviderKey = 
 {0f7c49f2-f5d2-4eaa-9de5-a274bdcbe6af}
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: WixBundleTag =
 [19E4:1418][2015-03-23T12:32:38]i410: Variable: WixBundleVersion =
 3.9.1208.0
 [19E4:1418][2015-03-23T12:32:38]e000: Error 0x80070005: Failed to run 
 per-user mode.
 [19E4:1418][2015-03-23T12:32:38]i007: Exit code: 0x80070005, 
 restarting: No



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Cannot-i
 nstall-Wix-Wix39-exe-tp7599681.html
 Sent from the wix-users mailing list archive at Nabble.com.


 --
  Dive into the World of Parallel Programming The Go Parallel 
 Website, sponsored by Intel and developed in partnership with Slashdot 
 Media, is your hub for all things parallel software development, from 
 weekly thought leadership blogs to news, videos, case studies, 
 tutorials and more. Take a look and join the conversation now. 
 http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is 

Re: [WiX-users] Prevent run of Custom action if product is installed.

[Hoover, Jacob]

Was there a reason you wrote a CA to remove the file? Would RemoveFile / not 
suffice?

 On Mar 23, 2015, at 10:53 AM, Nir Bar nir@panel-sw.com wrote:
 
 You can condition it on  REMOVE
 https://msdn.microsoft.com/en-us/library/aa371194%28v=vs.85%29.aspx  
 property instead of Installed.
 
 
 
 
 -
 Nir Bar 
 Freelance Developer 
 Mail: nir@panel-sw.com 
 Web: www.panel-sw.com 
   - C++ On Windows, Linux and Embedded Platforms 
   - WiX  InstallShield 
 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Prevent-run-of-Custom-action-if-product-is-installed-tp7599666p7599670.html
 Sent from the wix-users mailing list archive at Nabble.com.
 
 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Repair does not repair data files

[Hoover, Jacob]

You can tell windows installer to do it from the command line.

https://msdn.microsoft.com/en-us/library/aa371182(v=vs.85).aspx

a   Force all files to be reinstalled, regardless of checksum or version.

I think you can also use a custom action to set the REINSTALLMODE/REINSTALL 
properties from within the MSI, but I would be very careful when doing it.  Ex: 
http://ehc.ac/p/wix/mailman/message/20369655/

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Tuesday, March 17, 2015 12:01 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Repair does not repair data files

It's not repairing them because they've changed - they contain user entered 
data and Windows is typically reluctant to destoy user data.
I don't know of a way to fix your problem off the top of my head without you 
doing something explicit, such as actually removing the files and then doing 
the repair.
---
Phil Wilson


On Tue, Mar 17, 2015 at 5:20 AM, Даниил Мусиенко musie...@ascon.ru wrote:
 Hello,
 I made a installer with wix. It installs some executable and data files.
 If I change executable files and repair installation all changed files 
 will be replaced by original files.
 But if I change data files and press repair data files will not be 
 replaced by original files.

 So, how can I replace all files by original on repair action?
 I reed that I can set parameter to msiexec, but I want User to be able 
 to repair all files by click repair button in Add/Remove Programs 
 panel

 Thank you,

 Daniil Musienko
 ASCON


 --
  Dive into the World of Parallel Programming The Go Parallel 
 Website, sponsored by Intel and developed in partnership with Slashdot 
 Media, is your hub for all things parallel software development, from 
 weekly thought leadership blogs to news, videos, case studies, 
 tutorials and more. Take a look and join the conversation now. 
 http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] bizarre trying to install MSI but it thinks it is installed but can't find any references to it

[Hoover, Jacob]

Do you have the original logs from the bundle and service install MSI?

The only safe way to uninstall would be to modify the service install MSI (Use 
Orca or similar tool) to put an always false condition on the service uninstall 
portion.  But if Windows installer thinks the package is installed, then either 
you didn't change the upgrade/product code, or it actually is installed.  Is it 
possible the service control database was locked when the install happened? Not 
sure if Windows Installer does this, but it may be possible a reboot is needed 
for the install to complete.

Deleting the package cache is never the right way to handle it, at least until 
after the bundle is removed.

-Original Message-
From: Steve-Ogilvie [mailto:steven.ogil...@titus.com] 
Sent: Tuesday, March 17, 2015 9:15 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] bizarre trying to install MSI but it thinks it is 
installed but can't find any references to it

Hi all,

I have a client that is trying to install our product on one of their systems.

One of our MSI's (a service installer) is skipped when installing our product 
using the Bootstrapper, it runs the pre reqs, it runs our 1st install, skips 
the service install and tries to run our client install which fails because it 
verifies that our service has been installed (which it is
not) so the install rolls back :(

I checked HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall (and the 
Wow6432Node as well) and NONE of our installers are listed...

I deleted the \programdata\packagecache\our product guid

I run msiexec /i MSIname.msi and it comes up to maintenance mode and I try to 
remove but it fails since it is trying to close/uninstall our service with a 
custom action and it fails since the Service doesn't exist...

For some reason his system THINKS that particular MSI is installed...

I have tried running msiexec.exe /x MSIname.MSI and it fails

Questions:

1. how can i REMOVE this MSI from his system? running install/uninstall using 
cmd line fails 2. is my last resort is to use KILL MSI?
3. are there any other safe tools to use to remove a MSI from a system?

Any help would be much appreciated!!

Thanks,

Steve





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/bizarre-trying-to-install-MSI-but-it-thinks-it-is-installed-but-can-t-find-any-references-to-it-tp7599586.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Replace files added in minor upgrade

[Hoover, Jacob]

My question would be what is your baseline?  If ver 1 is your RTM release, all 
patches should be based off of it for easy cumulative patching.  If you are 
doing incremental patching, then 1.2 would require 1.1, and wouldn't supersede 
it.

Note: My experience with patching is limited, but this is my understanding of 
how it should be done. I've taken the easy route and jumped to burn, and I just 
use upgrades instead of patching to avoid a lot of complexity.

-Original Message-
From: Ramjot [mailto:ramjot.si...@hotmail.com] 
Sent: Friday, March 13, 2015 10:14 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Replace files added in minor upgrade

I added a new component to existing product using a minor upgrade. But when in 
next minor upgrade I try to update this files the update fails. I get the 
following message in upgrade installation logs :-

Component 'component Name' is added in both the superseded patch and 
superseding patch. No action taken for this component.

Just to make things clear here is the process

Ver 1 - MSI - installs file1, file2
Ver1.1 - First MSP - updates file1, file2 and adds file3
Ver1.2 - Second MSP - updates file1, file2 but fails to update file3 with the 
log given above
Ver1.3 - third MSP - updates file1, file2 but fails to update file3 with the 
same log as above I am using Wix 3.8 Toolset.

I have declared both patches as superseding PatchFamily Id='ProdPatchFamily' 
Version='$(var.productVersion)'
Supersede='yes' 

What am I doing wrong here? Or to support upgrade of file 3 I need to issue a 
major upgrade?

Thanks,
Ramjot



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Replace-files-added-in-minor-upgrade-tp7599551.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Reboots

[Hoover, Jacob]

I assume Rob was speaking of WcaDoDeferredAction.  If you are writing a CA in 
C, I would defiantly be using wcautil.lib as it provides a framework for 
handling native custom actions.

Ex:

EXPORT UINT __stdcall MyCA(MSIHANDLE hInstall)
{
HRESULT hr = S_OK;
UINT er = ERROR_SUCCESS;

hr = WcaInitialize(hInstall, MyCA);
ExitOnFailure(hr, Failed to initialize);

WcaLog(LOGMSG_STANDARD, Initialized.);

if (Foo()) {
hr = WcaSetProperty(Foo_Property, TEXT(Bar));
ExitOnFailure(hr, Failed to SetProperty for Foo); 
}
LExit:
er = SUCCEEDED(hr) ? ERROR_SUCCESS : ERROR_INSTALL_FAILURE;
return WcaFinalize(er);
}

-Original Message-
From: Ivanoff, Alex [mailto:alex.ivan...@shavlik.com] 
Sent: Thursday, March 12, 2015 2:25 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Reboots

Rob,

Can you be more specific? I am not that familiar with wcautil.lib.


-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com]
Sent: Thursday, March 12, 2015 12:08
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Reboots

MsiDoAction() on ScheduleReboot might work - I'm not sure if that's the 
underlying method that Rob is referring to.
---
Phil Wilson


On Wed, Mar 11, 2015 at 1:09 PM, Rob Mensching r...@firegiant.com wrote:
 wcautil.lib provides a mechanism to do that.

 _
  Short replies here. Complete answers over there: 
 http://www.firegiant.com/


 -Original Message-
 From: Ivanoff, Alex [mailto:alex.ivan...@shavlik.com]
 Sent: Wednesday, March 11, 2015 11:42 AM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] Reboots

 MsiSetMode does not seem to work when called from deferred custom action. So, 
 my question should have been How do I tell Windows Installer from deferred 
 custom action written in C that reboot is required?

 --
  Dive into the World of Parallel Programming The Go Parallel 
 Website, sponsored by Intel and developed in partnership with Slashdot 
 Media, is your hub for all things parallel software development, from 
 weekly thought leadership blogs to news, videos, case studies, 
 tutorials and more. Take a look and join the conversation now.
 http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] how to extract string from registry entry [P]

[Hoover, Jacob]

+1 for ShellExecute.

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Monday, March 09, 2015 11:44 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] how to extract string from registry entry [P]

As it says here:

http://wixtoolset.org/documentation/manual/v3/customactions/shellexec.html

it's more common to use a shell execute on a URL to launch the default program, 
if that works in your scenario.
---
Phil Wilson


On Mon, Mar 9, 2015 at 5:46 AM, Steven Ogilvie steven.ogil...@titus.com wrote:
 Classification: Public
 Why not use: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Apps Paths
 Chrome.exe and get the default value which is the path and exe 
 name Use Firefox.exe to get its path

 -Original Message-
 From: Namrata Kumari [mailto:namrata.kum...@aspiresys.com]
 Sent: March-09-15 8:36 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] how to extract string from registry entry

 I want to launch my application on default browser but getting extra content 
 in registry entry , how to extract exact values out from registry:
 Property Id=BROWSER
   RegistrySearch Id='DefaultBrowser' Type='raw' Root='HKCR'
 Key='http\shell\open\command' /
 /Property

 Getting registry entry :
 Firefox:  C:\Program Files (x86)\Mozilla Firefox\firefox.exe -osint -url 
 %1
 Chrome: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe -- %1

 Required Value ::
 Firefox:  C:\Program Files (x86)\Mozilla Firefox\firefox.exe
 Chrome: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe



 Is there any way to extract value as required in registry entry else 
 have to go with CA... hate that



 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/how-to-e
 xtract-string-from-registry-entry-tp7599505.html
 Sent from the wix-users mailing list archive at Nabble.com.

 --
  Dive into the World of Parallel Programming The Go Parallel 
 Website, sponsored by Intel and developed in partnership with Slashdot 
 Media, is your hub for all things parallel software development, from 
 weekly thought leadership blogs to news, videos, case studies, 
 tutorials and more. Take a look and join the conversation now. 
 http://goparallel.sourceforge.net/
 ___
 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 March-09-15 
 8:46:42 AM.

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

 --
  Dive into the World of Parallel Programming The Go Parallel 
 Website, sponsored by Intel and developed in partnership with Slashdot 
 Media, is your hub for all things parallel software development, from 
 weekly thought leadership blogs to news, videos, case studies, 
 tutorials and more. Take a look and join the conversation now. 
 http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] MSI packages download and Firewall/Proxy settings

[Hoover, Jacob]

Are you providing a valid HWND when calling Detect/Elevate/Apply?  The files 
the engine downloads are via WinInet, so they should use that config and should 
prompt for authentication if required.  If you are doing your own downloading 
inside of your BA, then I'd suggest you look at dlutil.cpp inside of dutil.

-Original Message-
From: Mohamed Yasir [mailto:yasirmohame...@gmail.com] 
Sent: Monday, March 09, 2015 2:07 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] MSI packages download and Firewall/Proxy settings

Hi Everyone, 

I am using Wix 3.9 and created a Custom bootstrapper application which 
downloads and installs the MSI packages. It is working fine. 

Some of the network download address restricted by Firewall or Proxy server.
So MSI pacakges download getting failed. In this type of cases I would like to 
get the credentials from the user and downloads the MSI packages using that 
credentials. 

Is this is possible in Wix cba? How to handle proxy with cache call backs and 
download packages?

Could you please share any idea about this? 

Thanks,
Mohamed Yasir K



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-packages-download-and-Firewall-Proxy-settings-tp7599503.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] 3.9 RC2 Installer Sitting at CA for a long time

[Hoover, Jacob]

I think he's speaking of the Wix install itself running.  I seem to remember 
the VS integration hunk being horrid and random as far as timing.  Did you have 
any instances of Visual Studio running while the installer is running? (I 
forget the command but I think we shell out to devenv to register / integrate.)

-Original Message-
From: Jeremiahf [mailto:jeremi...@gmail.com] 
Sent: Tuesday, March 03, 2015 3:19 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] 3.9 RC2 Installer Sitting at CA for a long time

as in Verbose log. :)

On Tue, Mar 3, 2015 at 3:17 PM, Jeremiahf jeremi...@gmail.com wrote:

 What is your CA code? logs?

 On Tue, Mar 3, 2015 at 3:02 PM, Tunney, Stephen 
 stephen.tun...@nuance.com
  wrote:

 :(

 Nothing else is running on the machine.

 Action   14:40:52:  RollbackCleanup.  Removing backup files

 I'm looking at SysInternals Process Explorer and nothing looks pegged:
 CPU is at 10%
 RAM is low
 disk I/O doesn't seem crazy either

 Log files are:
 WiX Toolset_v3.9.1208.0_20150303143601
 WiX Toolset_v3.9.1208.0_20150303143601_6_Wix
 WiX Toolset_v3.9.1208.0_20150303143601_7_Wix64
 WiX Toolset_v3.9.1208.0_20150303143601_8_msdk.msi
 WiX Toolset_v3.9.1208.0_20150303143601_9_nsdk2010.msi
 WiX Toolset_v3.9.1208.0_20150303143601_10_nsdk2013.msi
 WiX Toolset_v3.9.1208.0_20150303143601_11_votive.msi

 Is negative one really bad? :(

 Installing on Server 2012 R2 Standard.  I have VS 2013 Premium Update 
 4 installed on the machine as well.

 Thoughts on where I should look from here?

 -
 - Dive into the World of Parallel Programming The Go Parallel 
 Website, sponsored by Intel and developed in partnership with 
 Slashdot Media, is your hub for all things parallel software 
 development, from weekly thought leadership blogs to news, videos, 
 case studies, tutorials and more. Take a look and join the 
 conversation now. http://goparallel.sourceforge.net/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] using a custom action to read properties from a XML file

[Hoover, Jacob]

Or use Burn and a managed BA, where you can do it without a CA and pass it as a 
property to the MSI.

-Original Message-
From: Davis, Jeff [mailto:jda...@nanometrics.com] 
Sent: Friday, February 27, 2015 11:07 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] using a custom action to read properties from a XML 
file

Jeremiahf,

I like your approach.  I'll write the C# code to do what I want it to do and 
then figure out how to make it a CA.  Instead of trying to write a CA to do 
what I want.

Jeff


-Original Message-
From: Jeremiahf [mailto:jeremi...@gmail.com]
Sent: Thursday, February 26, 2015 6:49 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] using a custom action to read properties from a XML 
file

I've had to do this before. My method was to create an application to 
read/modify an XML file. Then took my code and turned it into a CA. Saved a lot 
of headache trying to debug what was going on. Also as John stated, scheduled 
the CA to execute first.

J

On Thu, Feb 26, 2015 at 5:37 PM, John Cooper jocoo...@jackhenry.com wrote:

 Ok, so, you'll need to run in the UI Sequence pretty early.

 Question, how does Va'lue set MAC_ID?  Normally, I would expect Value
 to be replaced by MAC_ID.

 You'll need to add an

 InstallUISequence

 Element with a Custom Action=your XML setter entry point here
 Before=LaunchConditions /

 What does your entry point look like?

 --
 John Merryweather Cooper
 Senior Software Engineer | Integration Development Group | Continuing 
 Development Jack Henry  Associates, Inc.® | Lenexa, KS  66214 | Ext:
 431050 | jocoo...@jackhenry.com

 -Original Message-
 From: Davis, Jeff [mailto:jda...@nanometrics.com]
 Sent: Thursday, February 26, 2015 5:27 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] using a custom action to read properties from 
 a XML file

 I have custom UI dialog that has a Text control that has the variable.
 When the MSI runs it should populate that field with the data read 
 from the XML.

 Control Type=MaskedEdit Id=MacID Width=270 Height=15
 X=52 Y=184 Property=MAC_ID  Text=[MACIDTemplate]   /
 Control Type=Text Id=MacIDLabel Width=36 Height=10 X=11
 Y=188 Text=MAC ID /



 -Original Message-
 From: John Cooper [mailto:jocoo...@jackhenry.com]
 Sent: Thursday, February 26, 2015 3:08 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] using a custom action to read properties from 
 a XML file

 Well, which sequence is the custom action running?  UI or Execute?  If 
 in the execute sequence, only public secure properties (properties in 
 all upper case with a Secure=yes attribute) will be visible in the 
 UI sequence.  If in the UI sequence, are you firing this from a button, or is
 it just scheduled?   If from a button, you're not going to get any
 logging.  Try scheduling in directly in UI so you can get some logging.

 --
 John Merryweather Cooper
 Senior Software Engineer | Integration Development Group | Continuing 
 Development Jack Henry  Associates, Inc.® | Lenexa, KS  66214 | Ext:
 431050 |jocoo...@jackhenry.com

 -Original Message-
 From: Davis, Jeff [mailto:jda...@nanometrics.com]
 Sent: Thursday, February 26, 2015 4:54 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] using a custom action to read properties from 
 a XML file

 Nothing happens.   The value does not get populated in the UI.  It still
 shows the default value of 0.

 But I am really just coding in the dark on this.  I'm not sure what I am
 doing and not even sure I have everything correct.   I just don't get the
 whole custom action concept and how properties get read and set?

 This was just a stab at what I thought would work.

 Jeff


 -Original Message-
 From: John Ludlow [mailto:john.ludlow...@gmail.com]
 Sent: Thursday, February 26, 2015 2:33 PM
 To: General discussion about the WiX toolset.
 Subject: Re: [WiX-users] using a custom action to read properties from 
 a XML file

 When you say not working, what do you mean exactly? Is it just not 
 calling your CA, not finding the file, not getting any results, or is 
 it throwing an exception?

 Here are some things you can try:

 Check whether there any evidence in the log that the custom action has 
 been called, and what the CustomActionData is. Also, put a few 
 session.Log calls in strategic places in the code to see where it's getting 
 to.

 Try writing similar code in a console application and seeing whether 
 it can load the XML file

 And of course, the real way :

 http://blog.torresdal.net/2008/10/26/wix-and-dtf-debug-a-managed-custo
 m-action-and-how-to-generate-an-msi-log/

 Here are some possible theories:

 If the custom action data is what you have there, I would suggest that 
 the relative path isn't being evaluated from where you think it would 
 be - you may need to use a property to build up a full path to the file.

 

Re: [WiX-users] how to auto-update like ClickOnce in WIX

[Hoover, Jacob]

Still not supported directly in the toolset but it doesn't take much to do it.  
I have a modified WixStdBA here 
https://github.com/jchoover/wix3/tree/develop-3.9-WixStdBA

If you are using your own BA, you can model it after the changes I made to 
Wix's own BA in src/Setup/WixBA/UpdateViewModel.cs

As for the application triggering the update, you can create a stub DLL to 
expose the methods inside of butil.cpp (part of dutil.lib). 

https://www.mail-archive.com/wix-users@lists.sourceforge.net/msg65066.html


-Original Message-
From: Kurt Schenk [mailto:kurt.sch...@microsoft.com] 
Sent: Friday, February 27, 2015 9:32 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] how to auto-update like ClickOnce in WIX

Hi

Is there an update to the information that Rob shared on Feb 2014? What is 
possible today?

http://sourceforge.net/p/wix/mailman/message/31962990/
It's not hard but there is nothing built into WiX toolset today to do it. 
There is a feature under development to do self-update for bundles that could 
help a lot building an auto-update system.

You just have to connect a few more dots today

Thanks,


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing the Visual Studio Redistributable from within MSI Failing

[Hoover, Jacob]

Use Burn to install the prerequisites.  There is no proper way of doing a 
nested/concurrent install from within a single MSI.

Concurrent Installs - 
https://msdn.microsoft.com/en-us/library/aa368010%28v=vs.85%29.aspx?f=255MSPPError=-2147217396
Windows Installer Best Practices - 
https://msdn.microsoft.com/en-us/library/windows/desktop/bb204770(v=vs.85).aspx


-Original Message-
From: Sarvagya Pant [mailto:sarvagya.p...@gmail.com] 
Sent: Tuesday, February 24, 2015 10:58 PM
To: General discussion about the WiX toolset.
Subject: [WiX-users] Installing the Visual Studio Redistributable from within 
MSI Failing

I am attempting to install the dependency of my program
*vcredist_x86_2008.exe* and *vcredist_x86_2010.exe* from my msi before it 
attempts to install the program itself. I have following piece of code.

Binary Id=SetupCA
SourceFile=..\..\ext_library\SetupCA\SetupCA\bin\Release\SetupCA.CA.dll/Binary
Id=VCREDIST_2008_FILE
SourceFile=..\..\ext_library\vcredist_x86_2008.exe /Binary 
Id=VCREDIST_2010_FILE
SourceFile=..\..\ext_library\vcredist_x86_2010.exe /CustomAction 
Id=VCREDIST_2008 BinaryKey=VCREDIST_2008_FILE ExeCommand=/q:a
Execute=immediate Return=check /CustomAction Id=VCREDIST_2010
BinaryKey=VCREDIST_2010_FILE ExeCommand=/q /norestart
Execute=immediate Return=check /CustomAction Id=WRITEFILETODISK 
Execute=immediate BinaryKey=SetupCA
DllEntry=WriteFileToDisk /CustomAction Id=ResidueRemove
Execute=immediate BinaryKey=SetupCA DllEntry=DeleteResidue
/InstallExecuteSequence
  Custom Action=WRITEFILETODISK Before=InstallFinalizeNOT 
Installed/Custom
  Custom Action=ResidueRemove After=InstallFinalizeInstalled/Custom
  Custom Action=VCREDIST_2008 Before=CostInitializeNOT Installed/Custom
  Custom Action=VCREDIST_2010 Before=CostInitializeNOT 
Installed/Custom/InstallExecuteSequence

I have two other custom actions *WRITEFILETODISK*, which will get the 
parameters passed to installer and write config in file, and *ResidueRemove* 
that is to be run on uninstallation, which has to remove leftovers if any.
Installing the msi using /l*v mode, I get the following:

Error 1721. There is a problem with this Windows Installer package. A program 
required for this install to complete could not be run.
Contact your support personnel or package vendor. Action:
VCREDIST_2008, location: C:\Windows\Installer\MSIA422.tmp, command:
/q:a
MSI (s) (D8:30) [10:14:20:867]: Note: 1: 2205 2:  3: Error
MSI (s) (D8:30) [10:14:20:867]: Note: 1: 2228 2:  3: Error 4:
SELECT `Message` FROM `Error` WHERE `Error` = 1709
MSI (s) (D8:30) [10:14:20:867]: Product: LogPointAgent -- Error 1721. There 
is a problem with this Windows Installer package. A program required for this 
install to complete could not be run.
Contact your support personnel or package vendor. Action:
VCREDIST_2008, location: C:\Windows\Installer\MSIA422.tmp, command:
/q:a

Isn't this the proper way of installing another exe from msi? please correct it 
if I'm wrong.

--
*sarvagya*
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installation doesn't progress at all

[Hoover, Jacob]

We don't really have enough information to do anything... Since this problem is 
only happening intermittently, it's difficult to diagnose.  Are you 100% 
certain you are calling plan? (Might want to log that from your BA to make sure 
you really are.)

-Original Message-
From: Balaji R [mailto:ji4all...@gmail.com] 
Sent: Thursday, February 19, 2015 2:47 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Installation doesn't progress at all

Hi,

Any update on the above issue ?

Thanks,
Balaji



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installation-doesn-t-progress-at-all-tp7599147p7599281.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] burn bootstrapper access -lang as a property or variab le

[Hoover, Jacob]

I assume you are using WixStdBA and not your own BA? If so, looking at the Wix4 
source the lang command line parsing is done from within WixStdBA and not the 
engine.  Sadly, it's not creating a variable (thought it would seem to be a 
valid feature request).

Inside of WixStandardBootstrapperApplication.cpp, in method ProcessCommandLine, 
simply adding 

hr = m_pEngine-SetVariableString(lang, 
*psczLanguage);
BalExitOnFailure(hr, Failed to set lang variable.);

After the parsing of the lang parameter should do it.

It would be something I could see being logged as a feature on 
http://wixtoolset.org/issues/. In the meantime, you could always do your own 
compile.

-Original Message-
From: runel_kr...@juno.com [mailto:runel_kr...@juno.com] 
Sent: Tuesday, February 17, 2015 12:30 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] burn bootstrapper access -lang as a property or variab 
le

I'm afraid the provided link hasn't helped me solve my problem. I am trying to 
get the bootstrapper and the MSI to both be translated into the same language. 
When the user enters the -lang 1046 as a command line parameter for the 
bootstrapper, the bootstrapper is correctly switching to the localized 
1046\thm.wxl and 1046\license.rtf. But I can't seem to figure out how to get 
access to the selected language so that I can perform the correct transform on 
the MSI. It would be nice if I could just access the -lang value directly, but 
I was not able to find a way to do this.  (I have tested both the bootstrapper 
localization and the MSI transforms. Both localizations work when called 
explicitly so I know it is just a matter of finding the right way to select the 
transform.) After failing to get access to the -lang argument, I tried was to 
create all my localized strings in the bootstrapper and pass them into the MSI 
as properties.MsiPackage Id=msi_English SourceFile=../Installer/bin/$
 (var.Configuration)/en-us/app.msi DisplayInternalUI=yes/   MsiProperty 
Name=String1 Value=!(loc.String1)/ /MsiPackage This failed because it 
appears the !(loc.String1) in the MsiProperty doesn't use the localized string, 
it uses the default string. I also tried using a localized string as the 
install condition, but had the same problem. The default string is used, not 
the localized one. MsiPackage Id=msi_English 
SourceFile=../Installer/bin/$(var.Configuration)/en-us/app.msi 
DisplayInternalUI=yes InstallCondition=(NOT !(loc.Language) = 
quot;1046quot;)/ MsiPackage Id=msi_Portuguese 
SourceFile=../Installer/bin/$(var.Configuration)/en-us/app.msi 
DisplayInternalUI=yes InstallCondition=(!(loc.Language) = 
quot;1046quot;)   Payload Id=pt_mst 
SourceFile=../Installer/bin/$(var.Configuration)/en-us/pt-br.mst/   
MsiProperty Name=TRANSFORMS Value=pt-br.mst/ /MsiPackage Thanks again.

Protect what matters
Floods can happen anywhere. Learn your risk and find an agent today.
http://thirdpartyoffers.juno.com/TGL3131/54e388bd7c3438bd4883st03vuc
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Using a WiX Selection Tree control, when I select Feature 1, I want Feature 2 to be selected automatically

[Hoover, Jacob]

Shouldn't it be

[-] All Features
[x] Feature 1 (requires Feature 2)
[x] Feature 2
[x] Feature 3

And

Feature Id=ProductFeature Title=All Features Display=expand 
Level=1
  Feature Id=Feature1 ConfigurableDirectory=APPLICATIONFOLDER
   Title=Feature 1 (requires Feature 2) Level=1
ComponentRef Id=file1.txt /
Feature Id=Feature2 ConfigurableDirectory=APPLICATIONFOLDER
 Title=Feature 2 Level=1
  ComponentRef Id=file2.txt /
  Condition 
Level=1MsiSelectionTreeSelectedFeature=Feature1/Condition
/Feature
  /Feature
  Feature Id=Feature3 ConfigurableDirectory=APPLICATIONFOLDER
   Title=Feature 3 Level=2
ComponentRef Id=file3.txt /
  /Feature
/Feature

(Not certain on the need/usage for Feature/@Level here.)
-Original Message-
From: Gary Henry [mailto:gary.he...@microfocus.com] 
Sent: Friday, February 13, 2015 4:28 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Using a WiX Selection Tree control, when I select Feature 
1, I want Feature 2 to be selected automatically

I have three features in a Selection Tree control.  I would like Feature 2 and 
3 to be independently selected and installed but if Feature 1 is selected to be 
installed I want Feature 2 to be automatically selected since Feature 1 depends 
on it.  When my Selection Tree is displayed I see:

[-] All Features
[x] Feature 1 (requires Feature 2)
[x] Feature 2
[x] Feature 3

Where [-] represents the icon for Will be installed on local hard drive
and [x] represents the icon for Entire feature will be unavailable.

When I select Feature 1 to be installed I see:

[-] All Features
[-] Feature 1 (requires Feature 2)
[x] Feature 2
[x] Feature 3

But when I select Feature 1, I want Feature 2 to be selected automatically so 
it would look like this:

[-] All Features
[-] Feature 1 (requires Feature 2)
[-] Feature 2
[x] Feature 3

I don't want Feature 3 to be automatically selected since it is not required by 
Feature 1.  Is there a way to do this?  This seems like a simple problem but I 
could not find any documentation or examples on how to do this.  I have tried 
to use a condition within Feature2 like the following but the condition never 
gets tested since only Feature 1 was selected:

Feature Id=ProductFeature Title=All Features Display=expand 
Level=1
  Feature Id=Feature1 ConfigurableDirectory=APPLICATIONFOLDER
   Title=Feature 1 (requires Feature 2) Level=2
ComponentRef Id=file1.txt /
  /Feature
  Feature Id=Feature2 ConfigurableDirectory=APPLICATIONFOLDER
   Title=Feature 2 Level=2
ComponentRef Id=file2.txt /
Condition 
Level=1MsiSelectionTreeSelectedFeature=Feature1/Condition
  /Feature
  Feature Id=Feature3 ConfigurableDirectory=APPLICATIONFOLDER
   Title=Feature 3 Level=2
ComponentRef Id=file3.txt /
  /Feature
/Feature

If only Feature 1 is selected, is there a way to tell it to set the Level 
attribute of Feature2 to 1 so that Feature 2 in the Selection Tree displays the 
icon showing it will be installed also?  If trying to set the Level attribute 
of Feature2 is not the right approach, is there another method I can use to 
accomplish the behavior I desire?

Here is my full program if you want to try it:

?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
   Product Id=41788c15-290e-426f-934e-e5b3bf875013 
Name=WixUI_FeatureTree
   Language=1033 Version=1.0.0.0 
Manufacturer=WixUI_FeatureTree
   UpgradeCode=5f5d4f80-96f5-4060-a718-539b547d8a29
  Package InstallerVersion=200 Compressed=yes 
/
  Media Id=1 Cabinet=media1.cab EmbedCab=yes 
/
  ?define FeatureTree=1?
UIRef Id=MyWixUI_FeatureTree /

  Directory Id=TARGETDIR Name=SourceDir
 Directory Id=ProgramFilesFolder
Directory 
Id=APPLICATIONFOLDER Name=WixUI_FeatureTree
/Directory
 /Directory
  /Directory

  DirectoryRef Id=APPLICATIONFOLDER
  Component Id=file1.txt Guid=FEBD6C0C-1BDF-413C-B7B1-A4E18AC7A6FA
File Id=file1.txt Source=file1.txt KeyPath=yes 
Checksum=yes/
  /Component
  Component Id=file2.txt Guid=FEBD6C0C-1BDF-413C-B7B1-A4E18AC7A6FB
File Id=file2.txt Source=file2.txt KeyPath=yes 
Checksum=yes/
  /Component
  Component Id=file3.txt Guid=FEBD6C0C-1BDF-413C-B7B1-A4E18AC7A6FC
File Id=file3.txt Source=file3.txt 

Re: [WiX-users] [WIX]: UAC message display behavior in WIX

[Hoover, Jacob]

The EXE and the MSI should behave the same way.  You shouldn't get a UAC prompt 
until you click Install on a burn bundle.  This is standard behavior of MSI 
packages which you can't change, and if you were using a bundle you'd be hard 
pressed to get the bundle to elevate early. 

-Original Message-
From: Dileep S [mailto:dileep.sanamp...@gmail.com] 
Sent: Monday, February 09, 2015 2:52 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] [WIX]: UAC message display behavior in WIX

Dear All,

I have created a MSI package using WIX script.

UAC (User Account Control) dialog message displayed after click on 'Install' 
button in MSI UI?

UAC message in not displaying while launching MSI package.

For EXE: UAC - UI - Installation
For MSI:  UI - UAC - Installation.

Please let me know is this MSI behavior using WIX (or) Is default behavior of 
Windows Installer?

Thanks in advance...
--
Dive into the World of Parallel Programming. The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Custom action System.IO.DirectoryNotFoundException on second Installation

[Hoover, Jacob]

Is the file/directory in use when the delete was attempted?  Is there a reason 
you have to delete the file instead of just overwriting it?  Have you pondered 
using a RemoveFile element to explicitly remove the files you are creating in 
your CA on uninstall?

-Original Message-
From: Sarvagya Pant [mailto:sarvagya.p...@gmail.com] 
Sent: Wednesday, February 04, 2015 1:25 AM
To: General discussion about the WiX toolset.
Subject: [WiX-users] Custom action System.IO.DirectoryNotFoundException on 
second Installation

I have been making a Wix Installer that is supposed to install the contents and 
fetches the parameters passed in terminal and create files. ie.
msiexec /i installer.msi /l*v out.log IPADDRESS=1.1.1.1 will create a file 
lpa.config.

I have following wix file and custom action file.

WIX:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=* Name=CustomWixInstallerWithCustomAction
Language=1033 Version=1.0.0.0 Manufacturer=LogPoint
UpgradeCode=ba9015b9-027f-4451-adb2-e38f9168a850
Package InstallerVersion=200 Compressed=yes
InstallScope=perMachine /

MajorUpgrade DowngradeErrorMessage=A newer version of [ProductName] 
is already installed. /
MediaTemplate EmbedCab=yes /

Feature Id=ProductFeature
Title=CustomWixInstallerWithCustomAction Level=1
ComponentGroupRef Id=ProductComponents /
/Feature
/Product

Fragment
Directory Id=TARGETDIR Name=SourceDir
Directory Id=WindowsVolume
Directory Id=INSTALLFOLDER Name=lpaa /
/Directory
/Directory
/Fragment

Fragment
ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER
  Component Id=SomeRandomEXE
File Source
=G:\SarVaGYa\myworkspace\LatestLpa\lpa\lpa_c\build_win\src\lpa\Release\lpa.exe
/
  /Component
/ComponentGroup
Binary Id=SetupCA  SourceFile=G:\visual studio 
stuffs\SetupCA\SetupCA\bin\Release\SetupCA.CA.dll/
CustomAction Id=WRITEFILETODISK Execute=immediate
BinaryKey=SetupCA DllEntry=WriteFileToDisk /
InstallExecuteSequence
  Custom Action=WRITEFILETODISK Sequence=2NOT Installed AND NOT 
PATCH/Custom
/InstallExecuteSequence
/Fragment
/Wix

and the Custom Action File

namespace SetupCA
{

public class CustomActions
{

[CustomAction]
public static ActionResult WriteFileToDisk(Session session)
{

session.Log(Entering WriteFileToDisk);
string ipAddress = session[IPADDRESS];
string productCode = session[ProductCode];
string ssl = session[SSL];
string compression = session[COMP];
string config_path = C:\\lpaa\\;
string temp = @
{{
 logpoint_ip : {0},
ssl : {1},
compression : {2}
}};
if (string.IsNullOrEmpty(ssl))
{
ssl = False;
}
if (string.IsNullOrEmpty(compression))
{
compression = True;
}
string config = string.Format(temp, ipAddress,ssl,compression);
session.Log(Config Generated from property is:  + config);
try
{
System.IO.Directory.Delete(config_path, true); //Recursive 
delete content inside LogPointAgent Folder
}
catch (Exception e)
{
session.Log(LogPointAgent Directory Deletion Unsuccessful.
Exception:  + e.ToString());
}
try
{
System.IO.Directory.CreateDirectory(config_path);
}
catch (Exception e)
{
session.Log(LogPointAgent Directory Creation Unsuccessful.
Exception:  + e.ToString());
}

//try
//{
//System.IO.File.Delete(config_path + lpa.config);
//}
//catch (Exception e)
//{
//session.Log(Config File Deletion Unsuccessful Exception:
 + e.ToString());
//}
try
{
System.IO.File.WriteAllText(config_path + lpa.config, config);
}
catch (Exception e)
{
session.Log(Config File Writing Unsuccessful. Exception: 
+ e.ToString());
}
try
{
System.IO.File.WriteAllText(config_path + productcode.txt, 
productCode);
}
catch (Exception e)
{
session.Log(Product Code Writing Unsuccessful. Exception:
 + e.ToString());
}
session.Log(Confile file is written);
session.Log(Product Code file is written);
return ActionResult.Success;
}
}
}

The installer works fine when it is freshly installed but if I uninstall it, it 
will have residues productcode.txt and lpa.config as it was not installed by 
installer. If after uninstalling and 

Re: [WiX-users] Wix 3.9 Burn - Error 0x80070570: Failed to extract all files from container, erf: 1:4:0

[Hoover, Jacob]

0x80070570 = The file or directory is corrupted and unreadable.

Did you have your user verify that the digital signature of the bundle they 
downloaded was intact and valid? Are you using WixStdBA or your own BA? Are the 
files by chance Encrypted and/or Compressed (by the operating system)?

-Original Message-
From: Leo Woods [mailto:l.wo...@kublasoftware.com] 
Sent: Monday, February 02, 2015 2:02 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix 3.9 Burn - Error 0x80070570: Failed to extract all 
files from container, erf: 1:4:0

Hi All,

 

I'm using Wix and Burn to install my application, along with .Net 4.0 if 
needed.  Both are included with the installer (nothing downloaded from the 
web).  This all works fine on our computers (Windows 8.1, 7  XP).

 

But we've deployed a handful of these and two people have already given us a 
log reporting the same error

 

[01CC:10F8][2015-02-01T09:39:17]i336: Acquiring container:
WixAttachedContainer, copy from:
C:\Programas\product-name-2015-trial-setup.exe

[01CC:10F8][2015-02-01T09:39:17]i000: Setting string variable 
'WixBundleLastUsedSource' to value 'C:\Programas\'

[01CC:08FC][2015-02-01T09:39:17]e000: Error 0x80070570: Failed to extract all 
files from container, erf: 1:4:0

[01CC:10F8][2015-02-01T09:39:17]e000: Error 0x80070570: Failed to begin and 
wait for operation.

[01CC:10F8][2015-02-01T09:39:17]e000: Error 0x80070570: Failed to extract
payload: a0 from container: WixAttachedContainer

[01CC:10F8][2015-02-01T09:39:17]e312: Failed to extract payloads from
container: WixAttachedContainer to working path:
C:\Users\John\AppData\Local\Temp\{a52da92d-6b4f-4e80-aedb-198f3e8a009b}\2089
BF363D3539B111EA2D21C78FA210F667D524, error: 0x80070570.

 

On the other hand, we've had several successful installs, so obviously only 
some set-ups have this problem.  It's enough to be a serious concern for us, as 
we're a low-volume business.

 

I've read a lot online about bad signing causing this problem, so I've
checked this.   I've double-signed properly with insignia, and I've checked
on my own computer that the engine is still signed when it's extracted to 
Package Cache.  It is.

 

Basically I have no idea.  The closest post I've found was this one - 

 

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Burn-gt-Er
ror-0x80070570-Failed-to-extract-all-files-from-container-erf-1-4-0-td759540
6.html

 

. this same error, but fixed by moving the installer to the desktop.  One of 
our users was installing from their desktop and they still get this error, so I 
guess it's not quite the same.

 

Any help would be very greatly appreciated!

 

Leo

--
Dive into the World of Parallel Programming. The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Preventing msi file from being directly executed by a user?

[Hoover, Jacob]

+1 for this method.

The BA can do initial validation, pass the valid key to the MSI as a property. 
Your application still needs to do a sanity check on startup to ensure it's 
valid, but at least application startup checks are a bit harder to defeat.

-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Monday, January 26, 2015 5:04 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Preventing msi file from being directly executed by a 
user?

A very simplistic way to do it would be to add a LaunchCondition to your MSI 
which the bootstrapper provides.
Something like
Condition Message=[ProductName] can only be installed using the 
executable. Exit and run the executable to 
install![CDATA[VALIDPRODUCTKEY]]/Condition
In your MSI and something like
  MsiPackage Id=mypackage SourceFile=mypackage.msi Compressed=no 
Vital=yes
MsiProperty Name= VALIDPRODUCTKEY  Value=1 /
  /MsiPackage
In your bundle should do it.

This is easily defeated by anyone who opens the MSI up using Orca/InstEd! but 
it'll stop the vast majority.

If you want to be really friendly to sysadmins who might want to push the MSI 
silently to their users, send the product key itself (as in change the 'Value' 
in the above example from 1 to the variable you use to store the entered 
product key) from bootstrapper to MSI  have the MSI add the registry entries 
or write the key file or whatever registration steps the application looks for 
(assuming your application does look for a valid product key  your entire 
licensing model doesn't depend on a single very easily defeated installation 
check).

Palbinder Sandher
Software Platform Engineer 
T:   +44 (0)141 945 8500
F:   +44 (0)141 945 8501
http://www.iesve.com 

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: David Connet [mailto:d...@agilityrecordbook.com]
Sent: 23 January 2015 15:53
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Preventing msi file from being directly executed by a 
user?

On 1/22/2015 10:33 PM, sky wrote:
 I'm now using burn cumstom bootstrapper application, and in my custom 
 ba there is a step for validating product key. But since my msi file 
 is external to the bootstrapper, anyone can install msi file directly 
 without entering a product key. How can I prevent the msi file from 
 being executed directly? (other than embedding the msi file into 
 bootstrapper or adding custom action for product key validation to the 
 msi)

Personally, I wouldn't worry. I'd just make sure the application refuses to run 
without a key. (If no key, it brings up a dialog to enter one before the app 
runs)

Dave


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming. The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] FW: Burn error with document folder on network location (works fine running only the msi)

[Hoover, Jacob]

Is this a per-user or per-machine install? 

If it's per user, the install should not be elevated and it should run in the 
same context as the logged in user.  If it's a per-machine install, then it 
will be elevated but it shouldn't be writing out required files to a per-user 
Documents folder. 

It may be easier/more-reliable to put this in a standard location as a template 
and on first run of the application copy it to the documents folder. That way 
if the user corrupts or deletes the file, the next run of the application can 
copy down the template.

-Original Message-
From: Marco Tognacci [mailto:mark...@live.it] 
Sent: Monday, January 26, 2015 2:24 PM
To: WiX - users
Subject: [WiX-users] FW: Burn error with document folder on network location 
(works fine running only the msi)

I have changed the code for using XmlConfig instead of XmlFile, but the result 
is the same:The file is installed correctly but when the XmlFile or the 
XmlConfig try to access the file to change an elment of the xml fileit report 
an error that say that it can't find the Drive on network, and the setup 
fail.Any other way to try?It could be that when I install the setup run as 
another administrator user (different from the current user) so it can't see 
the network location as it is specific for the current user ???This problem is 
blocking me, and I can't find a working way with WiX for doing this 
installation.Thanks for any support.


 From: mark...@live.it
 To: wix-users@lists.sourceforge.net
 Date: Fri, 23 Jan 2015 00:44:26 +0100
 Subject: Re: [WiX-users] Burn error with document folder on network 
 location (works fine running only the msi)
 
 I have changed the code for using XmlConfig instead of XmlFile, but the 
 result is the same:The file is installed correctly but when the XmlFile or 
 the XmlConfig try to access the file to change an elment of the xml fileit 
 report an error that say that it can't find the Drive on network, and the 
 setup fail.
 Any other way to try?
 It could be that when I install the setup run as another administrator user 
 (different from the current user) so it can't see the network location as it 
 is specific for the current user ???
 This problem is blocking me, and I can't find a working way with WiX for 
 doing this installation.Thanks for any support.
 
 
 
  Date: Sat, 3 Jan 2015 10:21:43 -0700
  From: nickra...@hotmail.com
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] Burn error with document folder on network 
  location (works fine running only the msi)
  
  Okay, so it sounds like you want to:
  
  1. Install the file to the Documents folder 2. Edit the file in 
  place after it's been installed
  
  I've often seen people posting about having problems using XmlFile. 
  I have always used the XmlConfig element instead and haven't had any 
  problems. You might get less trouble by switching.
  
  Can you show the XmlFile that you're using? Something might stand out.
  
  
  
  --
  View this message in context: 
  http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-e
  rror-with-document-folder-on-network-location-works-fine-running-onl
  y-the-msi-tp7598703p7598711.html Sent from the wix-users mailing 
  list archive at Nabble.com.
  
  
  -- Dive into the World of Parallel Programming! The Go 
  Parallel Website, sponsored by Intel and developed in partnership 
  with Slashdot Media, is your hub for all things parallel software 
  development, from weekly thought leadership blogs to news, videos, 
  case studies, tutorials and more. Take a look and join the 
  conversation now. http://goparallel.sourceforge.net 
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
  New Year. New Location. New Benefits. New Data Center in 
 Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
  
--
Dive into the World of Parallel Programming. The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/

Re: [WiX-users] Problem with DetectCondition

[Hoover, Jacob]

Actually I responded too fast, they do align you just have mixed case.

NET4FrameworkInstalled != NET4FrameWorkInstalled

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: Thursday, January 15, 2015 10:25 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Problem with DetectCondition

NET4FrameWork != NET4FrameworkInstalled != NET4FrameWorkInstalled

Ensure the Variable and the DetectCondition are exactly the same. Your logs 
don't align with your definition...


-Original Message-
From: Lutz Andersohn [mailto:landers...@gmail.com] 
Sent: Thursday, January 15, 2015 10:05 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problem with DetectCondition

I have a problem with the DetectCondition in ExePackage: I do not understand 
why my condition is evaluated he way it is. Below is the code and log file. My 
problem is, the variable NET4FrameworkInstalled is correctly assigned the value 
1, however DetectCondition for the .NET package using this variable is 
evaluated to False. Same thing happens for all 4 packages I am trying to check. 
Does anybody know how to fix this?

Thanks

code:
?xml version=1.0?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
xmlns:bal=http://schemas.microsoft.com/wix/BalExtension;
xmlns:netfx=http://schemas.microsoft.com/wix/NetFxExtension;
  Fragment
!--checking for VideoCapture installation--
 util:RegistrySearch Id=VideoCapX
Variable=VideoCapXInstalled
Root=HKCR
Key=VIDEOCAPX.VideoCapXCtrl.1\
Result=exists
   /
 util:RegistrySearch Id=VideoCapXAlt
Variable=VideoCapXAltInstalled
Root=HKLM

Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\VideoCapX
control_is1\
Result=exists
   /
 util:RegistrySearch Id=USB4
Variable=USB4Installed
Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\US
Digital USB4 Software\
Result=exists
   /
 util:RegistrySearch Id=ICImagingRuntime
Variable=ICImagingRunTimeInstalled
Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\IC
Imaging Control ActiveX Runtime_is1\
Result=exists
   /
 util:RegistrySearch Id=ICImagingFull
Variable=ICImagingFullInstalled
Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\IC
Imaging Control 3.2_is1\
Result=exists
   /
 util:RegistrySearch Id=NET4FrameWork
Variable=NET4FrameworkInstalled
Root=HKLM
Key=SOFTWARE\Microsoft\.NETFramework\v4.0.30319\
Result=exists
   /

PackageGroup Id=MyExePackage
ExePackage
  SourceFile=..\Prerequisites\dotNetFx40_Full_x86_x64.exe
  DetectCondition=NET4FrameWorkInstalled/
ExePackage
  SourceFile=..\Prerequisites\vcdxstp.exe
  DetectCondition=VideoCapX/
  ExePackage
  SourceFile=..\Prerequisites\ic_3.2_activex_runtime_setup.exe
  DetectCondition=(ICImagingRuntime) OR (ICImagingFull) /
ExePackage
  SourceFile=..\Prerequisites\USB4_Setup_34.EXE
  DetectCondition=USB4 /
/PackageGroup
  /Fragment
/Wix




Log File:
[0FD8:13C0][2015-01-15T09:32:07]i001: Burn v3.9.1006.0, Windows v6.1 (Build
7601: Service Pack 1), path:
C:\Users\andersl\Downloads\PicturePerfectPackage(1).exe, cmdline:
'-burn.unelevated BurnPipe.{9B965B2D-0BF8-43FC-A5AB-6DCEE20BD99F}
{0FB63523-103C-44A7-8479-B0BE79AFBD72} 4200 '
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting string variable 'WixBundleLog' to 
value 'C:\Users\andersl\AppData\Local\Temp\Setup_20150115093207.log'
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting string variable 
'WixBundleOriginalSource' to value 
'C:\Users\andersl\Downloads\PicturePerfectPackage(1).exe'
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting string variable 
'WixBundleOriginalSourceFolder' to value 'C:\Users\andersl\Downloads\'
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting string variable 'WixBundleName' 
to value ''
[0FD8:1024][2015-01-15T09:32:07]i000: Setting version variable 
'WixBundleFileVersion' to value '1.0.0.0'
[0FD8:13C0][2015-01-15T09:32:07]i100: Detect begin, 7 packages
[0FD8:13C0][2015-01-15T09:32:07]i000: Registry key not found. Key = 
'SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\IC Imaging Control 
3.2_is1\'
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting numeric variable 
'ICImagingFullInstalled' to value 0
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting numeric variable 
'ICImagingRunTimeInstalled' to value 1
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting numeric variable 
'NET4FrameworkInstalled' to value 1
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting numeric variable 'USB4Installed' 
to value 1
[0FD8:13C0][2015-01-15T09:32:07

Re: [WiX-users] Problem with DetectCondition

[Hoover, Jacob]

NET4FrameWork != NET4FrameworkInstalled != NET4FrameWorkInstalled

Ensure the Variable and the DetectCondition are exactly the same. Your logs 
don't align with your definition...


-Original Message-
From: Lutz Andersohn [mailto:landers...@gmail.com] 
Sent: Thursday, January 15, 2015 10:05 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problem with DetectCondition

I have a problem with the DetectCondition in ExePackage: I do not understand 
why my condition is evaluated he way it is. Below is the code and log file. My 
problem is, the variable NET4FrameworkInstalled is correctly assigned the value 
1, however DetectCondition for the .NET package using this variable is 
evaluated to False. Same thing happens for all 4 packages I am trying to check. 
Does anybody know how to fix this?

Thanks

code:
?xml version=1.0?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
xmlns:bal=http://schemas.microsoft.com/wix/BalExtension;
xmlns:netfx=http://schemas.microsoft.com/wix/NetFxExtension;
  Fragment
!--checking for VideoCapture installation--
 util:RegistrySearch Id=VideoCapX
Variable=VideoCapXInstalled
Root=HKCR
Key=VIDEOCAPX.VideoCapXCtrl.1\
Result=exists
   /
 util:RegistrySearch Id=VideoCapXAlt
Variable=VideoCapXAltInstalled
Root=HKLM

Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\VideoCapX
control_is1\
Result=exists
   /
 util:RegistrySearch Id=USB4
Variable=USB4Installed
Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\US
Digital USB4 Software\
Result=exists
   /
 util:RegistrySearch Id=ICImagingRuntime
Variable=ICImagingRunTimeInstalled
Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\IC
Imaging Control ActiveX Runtime_is1\
Result=exists
   /
 util:RegistrySearch Id=ICImagingFull
Variable=ICImagingFullInstalled
Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\IC
Imaging Control 3.2_is1\
Result=exists
   /
 util:RegistrySearch Id=NET4FrameWork
Variable=NET4FrameworkInstalled
Root=HKLM
Key=SOFTWARE\Microsoft\.NETFramework\v4.0.30319\
Result=exists
   /

PackageGroup Id=MyExePackage
ExePackage
  SourceFile=..\Prerequisites\dotNetFx40_Full_x86_x64.exe
  DetectCondition=NET4FrameWorkInstalled/
ExePackage
  SourceFile=..\Prerequisites\vcdxstp.exe
  DetectCondition=VideoCapX/
  ExePackage
  SourceFile=..\Prerequisites\ic_3.2_activex_runtime_setup.exe
  DetectCondition=(ICImagingRuntime) OR (ICImagingFull) /
ExePackage
  SourceFile=..\Prerequisites\USB4_Setup_34.EXE
  DetectCondition=USB4 /
/PackageGroup
  /Fragment
/Wix




Log File:
[0FD8:13C0][2015-01-15T09:32:07]i001: Burn v3.9.1006.0, Windows v6.1 (Build
7601: Service Pack 1), path:
C:\Users\andersl\Downloads\PicturePerfectPackage(1).exe, cmdline:
'-burn.unelevated BurnPipe.{9B965B2D-0BF8-43FC-A5AB-6DCEE20BD99F}
{0FB63523-103C-44A7-8479-B0BE79AFBD72} 4200 '
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting string variable 'WixBundleLog' to 
value 'C:\Users\andersl\AppData\Local\Temp\Setup_20150115093207.log'
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting string variable 
'WixBundleOriginalSource' to value 
'C:\Users\andersl\Downloads\PicturePerfectPackage(1).exe'
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting string variable 
'WixBundleOriginalSourceFolder' to value 'C:\Users\andersl\Downloads\'
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting string variable 'WixBundleName' 
to value ''
[0FD8:1024][2015-01-15T09:32:07]i000: Setting version variable 
'WixBundleFileVersion' to value '1.0.0.0'
[0FD8:13C0][2015-01-15T09:32:07]i100: Detect begin, 7 packages
[0FD8:13C0][2015-01-15T09:32:07]i000: Registry key not found. Key = 
'SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\IC Imaging Control 
3.2_is1\'
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting numeric variable 
'ICImagingFullInstalled' to value 0
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting numeric variable 
'ICImagingRunTimeInstalled' to value 1
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting numeric variable 
'NET4FrameworkInstalled' to value 1
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting numeric variable 'USB4Installed' 
to value 1
[0FD8:13C0][2015-01-15T09:32:07]i000: Registry value not found. Key = 
'SOFTWARE\Microsoft\VisualStudio\11.0\VC\Runtimes\x64\', Value = '(null)'
[0FD8:13C0][2015-01-15T09:32:07]i000: Registry value not found. Key = 
'SOFTWARE\Microsoft\VisualStudio\11.0\VC\Runtimes\x86\', Value = '(null)'
[0FD8:13C0][2015-01-15T09:32:07]i000: Setting numeric variable 
'VideoCapXInstalled' to 

Re: [WiX-users] Dark a WiX StdBA or MBA?

[Hoover, Jacob]

Seems like an awful lot of work for something that you could do up front. You 
could modify the process to build a QA and a Production MSI at the same time 
early in the process. Potentially building the QA MSI, then signing the 
binaries and building the RTM/production MSI.

-Original Message-
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com] 
Sent: Tuesday, January 13, 2015 11:08 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Dark a WiX StdBA or MBA?

Amazing!  Ok, second part of my question is this:

Can I inject a replacement msi/msp payload?  What tool would I use then?

My scenario is that we are looking to change our signing strategy into a manner 
that more efficiently uses our existing payloads rather than a recompile of our 
installers and bootstrapper.
New scenario is this

Get Gold RTM Candidate signed with internal development keys.
Dark the bootstrapper - Get MSIs/MSPs
Use Windows Installer APIs to aquire binaries from each, and 
extract
Sign+Timstamp those
Use Windows Installer APIs to re-insert binaries for each
Sign+Timestamp updated MSIs/MSPs
Use ??? to update bootstrapper payload(s)
Sign+Timestamp updated bootstrapper.
Release to the world


This is a generic approach (IMHO) that can be used universally and can 
facilitate proper code signing and strong naming (PKI) infrastructure for 
enterprise development houses.

Any insight would be amazing!

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


-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com] 
Sent: January-13-15 11:43 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Dark a WiX StdBA or MBA?

Yes.  Dark can be used to extract the payload.

--
John Merryweather Cooper
Senior Software Engineer | Enterprise Service Applications | Continuing 
Development Jack Henry  Associates, Inc.® | Lenexa, KS  66214 | Ext:  431050 
|jocoo...@jackhenry.com



-Original Message-
From: Tunney, Stephen [mailto:stephen.tun...@nuance.com]
Sent: Tuesday, January 13, 2015 9:35 AM
To: General discussion about the WiX toolset.
Subject: [WiX-users] Dark a WiX StdBA or MBA?

Can a BA be processed by a dark or melt type application?
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended exclusively for the individual or entity to which it is addressed. The 
message, together with any attachment, may contain confidential and/or 
privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution is strictly prohibited. If you have received this message in 
error, please immediately advise the sender by reply email and delete all 
copies.


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet

Re: [WiX-users] Elevating custom bootstrapper application

[Hoover, Jacob]

BA's should not modify machine state. Why not property drive your MSI which is 
installing the config file, and use a custom action (XmlFile, XmlConfig) to 
modify it?

-Original Message-
From: Yari Serve [mailto:se...@my-horizon.de] 
Sent: Monday, January 05, 2015 7:34 AM
To: 'General discussion about the WiX toolset.'
Subject: [WiX-users] Elevating custom bootstrapper application

Hello,

 

I've written a custom WPF bootstrapper application and I need to modify some 
config files inside the install dir after installation. For easier editing, I 
want to use the custom BA instead of the WixUtils.

 

Now this works without a problem with UAC disabled, though a disabled UAC 
throws an AccessDeniedException and does not allow me to modify said files (due 
to the files being installed in the restricted C:\Program Files\ folder).

 

I've read around and tried using an application manifest for the BA (with using 
requestedExecutionLevel level=requireAdministrator uiAccess=false
/), setting the InstallScope to perMachine and InstallPrivileges to 
elevated for my packages inside my bundle chain, as well as setting 
ForcePerMachine to yes for all MsiPackages inside my chain.

 

The installation DOES get elevated (the UAC prompt pops up), however the custom 
BA itself does not get elevated... 

 

How can I do that?

 

Thank you.

--
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored 
by Intel and developed in partnership with Slashdot Media, is your hub for all 
things parallel software development, from weekly thought leadership blogs to 
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] 1 as the progress message at the end of an install

[Hoover, Jacob]

Look for it in the logs, to see where it's happening.  Odds are someone (is 
this a MSI you are building) customized their MSI definition with a 
ProgressText element.

-Original Message-
From: victorwhiskey [mailto:victorhwhis...@yahoo.com] 
Sent: Wednesday, December 17, 2014 3:39 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] 1 as the progress message at the end of an install

Thanks Phil,

So the only way to get rid of it is to recompile wix with the fix?

Thanks


Phil Wilson wrote
 That text is a template from the WiX ActionText for copying the files, 
 it might be for the InstallFiles action. It should be a template with 
 parameter number in square brackets, maybe not exactly this: File:[1], 
 Directory:[9], Size:[6] but similar. To get to the point, I'd guess 
 that the parameter number is not is square brackets so you get the 
 number 1.
 ---
 Phil Wilson
 
 
 On Mon, Dec 15, 2014 at 9:58 PM, victorwhiskey lt;

 victorhwhiskey@

 gt; wrote:
 Hello,

 I've been wondering this for awhile now. I'm showing the progress 
 during the install as well as the files that are being installed. At 
 the end of the install, where the file name should be shown it always 
 shows a 1 at the end of the install.

 What does this mean and is there a way to not show that?

 Thanks in advance



 --
 View this message in context:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/1-as-th
 e-progress-message-at-the-end-of-an-install-tp7598595.html
 Sent from the wix-users mailing list archive at Nabble.com.

 -
 - Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT 
 Server from Actuate! Instantly Supercharge Your Business Reports and 
 Dashboards with Interactivity, Sharing, Native Excel Exports, App 
 Integration  more Get technology previously reserved for 
 billion-dollar corporations, FREE 
 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg
 .clktrk ___
 WiX-users mailing list
 

 WiX-users@.sourceforge

 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
  Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT 
 Server from Actuate! Instantly Supercharge Your Business Reports and 
 Dashboards with Interactivity, Sharing, Native Excel Exports, App 
 Integration  more Get technology previously reserved for 
 billion-dollar corporations, FREE 
 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.
 clktrk ___
 WiX-users mailing list

 WiX-users@.sourceforge

 https://lists.sourceforge.net/lists/listinfo/wix-users





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/1-as-the-progress-message-at-the-end-of-an-install-tp7598595p7598622.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Launch Application on Exit - with Elevated Privileges

[Hoover, Jacob]

Configure on first run is a common pattern with some installs.  

One question I have is if it always needs to be elevated.  Is the configuration 
tool a separate executable than the application? Does it provide any value when 
in low privilege mode?  If it's yes to the first and no to the second, you 
could manifest the tool to have the OS auto elevate and avoid having to do an 
additional button click.

Is there a reason for needing elevation at all, or could the application store 
its configuration info in the CommonAppData\App Name\ folder and be modifiable 
by all without elevation.


-Original Message-
From: Marc Beaudry [mailto:mbeau...@matrox.com] 
Sent: Tuesday, December 16, 2014 9:53 AM
To: 'General discussion about the WiX toolset.'
Subject: Re: [WiX-users] Launch Application on Exit - with Elevated Privileges

Nick,

It's not a script, but a configuration tool/Application with UI.   

Thanks for the input, it is very appreciated.
Marc

-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com]
Sent: December-15-2014 12:51 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Launch Application on Exit - with Elevated Privileges

Should you do this at all? Run a configuration script after the installation?
In most cases, you shouldn't. It should be part of the install. Collect all the 
data you need for the configuration during the UI portion of the install and 
then use that data in deferred custom actions during the execute sequence.



--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Launch-Applica
tion-on-Exit-with-Elevated-Privileges-tp7598584p7598586.html
Sent from the wix-users mailing list archive at Nabble.com.


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Unable to select radio buttons in Hyperlink Theme

[Hoover, Jacob]

Have you tried BS_AUTORADIOBUTTON instead of BS_RADIOBUTTON for your HexStyle?

#define BS_RADIOBUTTON  0x0004L
#define BS_AUTORADIOBUTTON  0x0009L



-Original Message-
From: garymonk [mailto:g...@gurudental.com] 
Sent: Friday, December 12, 2014 11:57 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Unable to select radio buttons in Hyperlink Theme

I don't have anything like that coded. I'm new to WIX and I wasn't aware that I 
needed to do any coding. That's not a problem if someone could explain to me, 
or point me to some documentation, on how to do it.

Thanks,
Gary



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Unable-to-select-radio-buttons-in-Hyperlink-Theme-tp7598537p7598559.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setup bootstrapper fails if root certificate cannot be validated

[Hoover, Jacob]

Why not disable the cert check in your bundle?  You can still sign your content.


SuppressSignatureVerification 

By default, a Bundle will use the hash of a package to verify its contents. If 
this attribute is explicitly set to no and the package is signed with an 
Authenticode signature the Bundle will verify the contents of the package using 
the signature instead. Therefore, the default for this attribute could be 
considered to be yes. It is unusual for yes to be the default of an 
attribute. In this case, the default was changed in WiX v3.9 after experiencing 
real world issues with Windows verifying Authenticode signatures. Since the 
Authenticode signatures are no more secure than hashing the packages directly, 
the default was changed.  


-Original Message-
From: Matthew J. Bobowski [mailto:mjb8...@hotmail.com] 
Sent: Friday, December 12, 2014 4:38 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Setup bootstrapper fails if root certificate cannot be 
validated

I know this has been asked before, but is it possible for a WiX-generated 
bootstrapper to ignore issues when installing digitally signed files. Error 
0x800b010a - An internal certificate chaining error has occurred.

 

This error can happen if the root certificate is not known. Apparently there 
are two workarounds. Connect the computer to the Internet or manually install 
the Update for Root Certificates on Windows XP (KB931125).

http://www.microsoft.com/en-us/download/details.aspx?id=35945

 

Before I hear - Microsoft dropped support for XP what do you think you're 
doing? Or Just connect your computer to the Internet.  Let me explain that 
this is for Windows XP Embedded and Windows Embedded Standard 2009 - both of 
which are still supported by Microsoft and will be into the future.
And connecting to the Internet apparently does not help for Windows Embedded. 
Also, adding rootsupd.exe to the bootstrapper does not help of course, because 
we're in a chicken and egg scenario. The verification of certificate happens 
during the cache and before the first chained package.

 

I would rather not provide a bootstrapper that cannot handle this, or at least 
be able to strap the update for root certificates first - with the WiX 
bootstrapper!

 

 

Thanks,

-Matt

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX toolset EXE Wrapper installer with no files

[Hoover, Jacob]

Don't do nested/concurrent installs.  If your MSI has prerequisites, create a 
bundle and install them in the chain before your MSI is installed.

http://msdn.microsoft.com/en-us/library/aa368010(v=vs.85).aspx

Concurrent Installations, also called Nested Installations, is a deprecated 
feature of the Windows Installer. Applications installed with concurrent 
installations can eventually fail because they are difficult for customers to 
service correctly. Do not use concurrent installations to install products that 
are intended to be released to the public. 

-Original Message-
From: js [mailto:js280...@gmail.com] 
Sent: Wednesday, December 10, 2014 1:17 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX toolset EXE Wrapper installer with no files

I have a simple working EXE wrapper in WIX but I don't like that I have to add 
at least one file for it to work and I can't seem to find a way to not add 
files to it, is it even possible?

?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product
Package Compressed=yes InstallerVersion=301/
Media Id=1 Cabinet=media1.cab EmbedCab=yes /
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Directory Id=MyProgramDir Name=MyInstaller
Single unwanted dummy component here
/Directory
/Directory
/Directory
Binary Id=MYEXE SourceFile=Installer.exe /
CustomAction Id=RunInstaller BinaryKey=MYEXE ExeCommand=
Impersonate=no Execute=deferred Return=asyncNoWait /   
InstallExecuteSequence 
Custom Action=RunInstaller Before=InstallFinalize 
NOT Installed
/Custom 
/InstallExecuteSequence 
Feature Id=ProductFeature Level=1
Single unwanted dummy component ref here
/Feature
/Product
/Wix 



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-toolset-EXE-Wrapper-installer-with-no-files-tp7598515.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Install condition is not being set in options dialog

[Hoover, Jacob]

Have you tried adding Overridable=true ?

-Original Message-
From: garymonk [mailto:g...@gurudental.com] 
Sent: Wednesday, December 10, 2014 2:24 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Install condition is not being set in options dialog

If I set the variable INSTALLSERVER to 1

Variable Name=INSTALLSERVER Value=1/

Then the checkbox is checked and the server install starts, but if I check the 
checkbox in the options dialog it does not set the variable to 1.


garymonk wrote
 I have modified the RtfLicense theme to include a checkbox. The name 
 of the checkbox is the same name as the variable name that I use in 
 the install condition. When I execute the bundle and check the 
 checkbox the variable is always false.
 
 bundle.was...
 Variable Name=INSTALLSERVER /
 
 Chain
   
 ExePackage Cache=no
   InstallCondition=INSTALLSERVER
   Description=SQL Server and Server Bundle
   Id=GuruServer
   SourceFile=ServerSQLBundle.exe
   
 /ExePackage
 RtfTheme.xml
 Page Name=Options
 
 Text X=11 Y=80 Width=-11 Height=30 FontId=2
 DisablePrefix=yes
 #(loc.OptionsHeader)
 /Text
 
 Text X=11 Y=120 Width=-11 Height=30 FontId=3
 DisablePrefix=yes
 #(loc.OptionsDescription)
 /Text
 
*
 Checkbox Name=INSTALLSERVER X=11 Y=166 Width=260 Height=17
 TabStop=yes FontId=3
 Install Guru Server
 /Checkbox
*

 Button Name=OptionsOkButton X=229 Y=-11 Width=75 Height=23
 TabStop=yes FontId=0
 #(loc.OptionsOkButton)
 /Button
   
 Button Name=InstallButton X=314 Y=-11 Width=75 Height=23
 TabStop=yes FontId=0
 #(loc.InstallInstallButton)
 /Button
   
 Button Name=WelcomeCancelButton X=404 Y=-11 Width=75 Height=23
 TabStop=yes FontId=0
 #(loc.InstallCloseButton)
 /Button
 
 /Page
 Thanks,
 Gary





--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Install-condition-is-not-being-set-in-options-dialog-tp7598513p7598518.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX toolset EXE Wrapper installer with no files

[Hoover, Jacob]

After the fact I noticed you were trying to create a shim of sorts to have a 
MSI launch an EXE based install.  I can only assume you are using Group Policy 
software deployment, which requires a MSI based install instead of an exe based 
install.

I don't think you're required to have a file, it could be a registry entry.

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: Wednesday, December 10, 2014 1:26 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] WiX toolset EXE Wrapper installer with no files

Don't do nested/concurrent installs.  If your MSI has prerequisites, create a 
bundle and install them in the chain before your MSI is installed.

http://msdn.microsoft.com/en-us/library/aa368010(v=vs.85).aspx

Concurrent Installations, also called Nested Installations, is a deprecated 
feature of the Windows Installer. Applications installed with concurrent 
installations can eventually fail because they are difficult for customers to 
service correctly. Do not use concurrent installations to install products that 
are intended to be released to the public. 

-Original Message-
From: js [mailto:js280...@gmail.com]
Sent: Wednesday, December 10, 2014 1:17 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WiX toolset EXE Wrapper installer with no files

I have a simple working EXE wrapper in WIX but I don't like that I have to add 
at least one file for it to work and I can't seem to find a way to not add 
files to it, is it even possible?

?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product
Package Compressed=yes InstallerVersion=301/
Media Id=1 Cabinet=media1.cab EmbedCab=yes /
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Directory Id=MyProgramDir Name=MyInstaller
Single unwanted dummy component here
/Directory
/Directory
/Directory
Binary Id=MYEXE SourceFile=Installer.exe /
CustomAction Id=RunInstaller BinaryKey=MYEXE ExeCommand=
Impersonate=no Execute=deferred Return=asyncNoWait /   
InstallExecuteSequence 
Custom Action=RunInstaller Before=InstallFinalize 
NOT Installed
/Custom 
/InstallExecuteSequence 
Feature Id=ProductFeature Level=1
Single unwanted dummy component ref here
/Feature
/Product
/Wix 



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-toolset-EXE-Wrapper-installer-with-no-files-tp7598515.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/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 create a feature set that installs an msi and a bundle exe

[Hoover, Jacob]

Two options that come to mind are:

  Two bundles, one for the client, and one for the server. 

  A single Bundle which conditionally installs the server components. Use a 
check box on the install or options page (you'll need a custom theme if your 
using WixStdBA) tied to a burn variable to determine if the SQL Server/Server 
install is needed. If your check box is named the same as the variable, it 
should update the variable when the user changes the state.  You can then use 
the variable in ExePackage/@InstallCondition and MsiPackage/@InstallCondition 
to determine if your bundle needs to install the server/server prerequisites.


-Original Message-
From: garymonk [mailto:g...@gurudental.com] 
Sent: Monday, December 08, 2014 11:50 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to create a feature set that installs an msi and a 
bundle exe

I have an application that consists of two components, a client and a server.
The client will always get installed and the server is optional. If the server 
is selected to be installed SQL Server also needs to be installed as a prereq.

I have created a separate msi for the client. For the server I created a 
bundle. I have tested both of these and they install properly.

Now I would like to create a new msi with a feature set that when the client is 
selected it executes the client msi and when both are selected it executes both 
the msi and the server bundle exe.  

I was unable to get any help when I asked this in August. Is this possible and 
does anyone have an example?

If not does anyone have any suggestions?

Thanks for the help,
Gary



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-create-a-feature-set-that-installs-an-msi-and-a-bundle-exe-tp7598468.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] effects of not using authenticode digitally signed wix msi build output

[Hoover, Jacob]

It's only a few lines in your wixproj, and it gives you Lua patching and the 
certainty that the payload hasn't been altered.

 On Nov 20, 2014, at 9:14 PM, zoo ob1 o...@outlook.com wrote:
 
 Anyone have pointer to good article explaining impacts of not using
 authenticode digitally signed wix msi build output?
 
 
 
 I ask because in my organization we are debating the relevance of doing this
 on wix authored msi build output that will only ever be used on internal
 devices and servers.  
 
 
 
 My thinking is that msi doesn't really do anything to block you from running
 a non-authenticode digitally signed msi installer and so unless the internal
 device or server owner is looking at the file properties and stopping if
 they don't see a digital signature then what does it buy you adding and
 maintaining extra automated build complexity to do so.
 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] effects of not using authenticode digitally signed wix msi build output

[Hoover, Jacob]

http://msdn.microsoft.com/en-us/library/aa372388(v=vs.85).aspx

-Original Message-
From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] 
Sent: Friday, November 21, 2014 8:59 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] effects of not using authenticode digitally signed wix 
msi build output

Lua patching?

--
Nicolás

2014-11-21 11:50 GMT-03:00 Hoover, Jacob jacob.hoo...@greenheck.com:

 It's only a few lines in your wixproj, and it gives you Lua patching 
 and the certainty that the payload hasn't been altered.

  On Nov 20, 2014, at 9:14 PM, zoo ob1 o...@outlook.com wrote:
 
  Anyone have pointer to good article explaining impacts of not using 
  authenticode digitally signed wix msi build output?
 
 
 
  I ask because in my organization we are debating the relevance of 
  doing
 this
  on wix authored msi build output that will only ever be used on 
  internal devices and servers.
 
 
 
  My thinking is that msi doesn't really do anything to block you from
 running
  a non-authenticode digitally signed msi installer and so unless the
 internal
  device or server owner is looking at the file properties and 
  stopping if they don't see a digital signature then what does it buy 
  you adding and maintaining extra automated build complexity to do so.
 

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] use of $(var.Platform) and $(var.SolutionDir)

[Hoover, Jacob]

You can always define them:

DefineConstants$(DefineConstants);Platform=$(Platform);SolutionDir=$(SolutionDir);
 /DefineConstants

-Original Message-
From: zoo ob1 [mailto:o...@outlook.com] 
Sent: Thursday, November 20, 2014 2:44 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] use of $(var.Platform) and $(var.SolutionDir)

Use of $(var.Platform) and $(var.SolutionDir) in my wix sources is generating 
the following compiler errors.  

 

Undefined preprocessor variable '$(var.Platform)'.

Undefined preprocessor variable '$(var.SolutionDir)'.

 

Search hits reference
http://wixtoolset.org/documentation/manual/v3/votive/votive_project_referenc
es.html  suggesting it's still supported.

 

Any insights on if that support was dropped in v4 vs13 ide build story or 
replaced by a different syntax? 

 

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] use of $(var.Platform) and $(var.SolutionDir)

[Hoover, Jacob]

Yes, and ensure the Debug/Release variants don't have it without the 
$(DefineConstants); part.

-Original Message-
From: zoo ob1 [mailto:o...@outlook.com] 
Sent: Thursday, November 20, 2014 3:08 PM
To: 'General discussion about the WiX toolset.'
Subject: Re: [WiX-users] use of $(var.Platform) and $(var.SolutionDir)

Thanks for response.   

So I just add that element to my setupproject.wixproj xml in the default, 
non-configuration/platform condition controlled, PropertyGroup?

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Thursday, November 20, 2014 12:52 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] use of $(var.Platform) and $(var.SolutionDir)

You can always define them:

DefineConstants$(DefineConstants);Platform=$(Platform);SolutionDir=$(Solut
ionDir); /DefineConstants

-Original Message-
From: zoo ob1 [mailto:o...@outlook.com]
Sent: Thursday, November 20, 2014 2:44 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] use of $(var.Platform) and $(var.SolutionDir)

Use of $(var.Platform) and $(var.SolutionDir) in my wix sources is generating 
the following compiler errors.  

 

Undefined preprocessor variable '$(var.Platform)'.

Undefined preprocessor variable '$(var.SolutionDir)'.

 

Search hits reference
http://wixtoolset.org/documentation/manual/v3/votive/votive_project_referenc
es.html  suggesting it's still supported.

 

Any insights on if that support was dropped in v4 vs13 ide build story or 
replaced by a different syntax? 

 


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] SOURCEMGMT: Failed to resolve source MainEngineThread is returning 1612

[Hoover, Jacob]

Is the GUID in the log the same as the product code of the MSI you are trying 
to install? (IE, is the MSI already installed on his machine?) If so, you may 
need to recache the package, then do an uninstall.

Is this MSI a pre-user install? If so you could dig into the registry 
(HKCU\Software\Microsoft\Installer\Products\*\SourceList



-Original Message-
From: David Fritch [mailto:dfri...@ldschurch.org] 
Sent: Wednesday, November 19, 2014 10:59 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] SOURCEMGMT: Failed to resolve source MainEngineThread is 
returning 1612

There is a user in Turkey that gets the following error simply by double 
clicking on the .msi to install a program: The installation source for this 
product is not available.  Verify that the source exists and that you can 
access it.

He is the only user that I know of that is having this problem (of hundreds of 
users).  I believe he may have corrupted something about his environment. 
I don't know all of the details, but I know he is using Windows 7 and has 
recently tried to manually migrate a lot of data from one user to another user; 
this is not the only thing he has had errors with.

I had him turn on verbose logging and this is what I get.  I would greatly 
appreciate any direction on how to even diagnose what the problem is or 
approaches to try and resolve his problem.

=== Verbose logging started: 11/19/2014  1:42:26  Build type: SHIP UNICODE
5.00.7601.00  Calling process: C:\Windows\System32\msiexec.exe === MSI (c) 
(5C:40) [01:42:26:658]: Font created.  Charset: Req=0, Ret=0, Font:
Req=MS Shell Dlg, Ret=MS Shell Dlg

MSI (c) (5C:40) [01:42:26:658]: Font created.  Charset: Req=0, Ret=0, Font:
Req=MS Shell Dlg, Ret=MS Shell Dlg

MSI (c) (5C:F4) [01:42:26:668]: Resetting cached policy values MSI (c) (5C:F4) 
[01:42:26:668]: Machine policy value 'Debug' is 0 MSI (c) (5C:F4) 
[01:42:26:668]: *** RunEngine:
   *** Product:
C:\Users\DC\Downloads\LDSTradosStudioPlugin_6.4.msi
   *** Action: 
   *** CommandLine: ** MSI (c) (5C:F4) [01:42:26:668]: 
Machine policy value 'DisableUserInstalls'
is 0
MSI (c) (5C:F4) [01:42:26:670]: User policy value 'SearchOrder' is 'nmu'
MSI (c) (5C:F4) [01:42:26:670]: User policy value 'DisableMedia' is 0 MSI (c) 
(5C:F4) [01:42:26:670]: Machine policy value 'AllowLockdownMedia' is
1
MSI (c) (5C:F4) [01:42:26:670]: SOURCEMGMT: Looking for sourcelist for product 
{2CF25F13-12F8-4B54-AC62-0F29F54E4F54}
MSI (c) (5C:F4) [01:42:26:670]: SOURCEMGMT: Adding 
{2CF25F13-12F8-4B54-AC62-0F29F54E4F54}; to potential sourcelist list 
(pcode;disk;relpath).
MSI (c) (5C:F4) [01:42:26:670]: SOURCEMGMT: Now checking product 
{2CF25F13-12F8-4B54-AC62-0F29F54E4F54}
MSI (c) (5C:F4) [01:42:26:670]: Note: 1: 2718 2:
{2CF25F13-12F8-4B54-AC62-0F29F54E4F54}
MSI (c) (5C:F4) [01:42:26:670]: SOURCEMGMT: Failed to resolve source MSI (c) 
(5C:F4) [01:42:26:670]: MainEngineThread is returning 1612 === Verbose logging 
stopped: 11/19/2014  1:42:26 ===



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/SOURCEMGMT-Failed-to-resolve-source-MainEngineThread-is-returning-1612-tp7598095.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] SOURCEMGMT: Failed to resolve source MainEngineThread is returning 1612

[Hoover, Jacob]

+1 for InstEd, it just seems easier to use for me.

-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com] 
Sent: Wednesday, November 19, 2014 12:47 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] SOURCEMGMT: Failed to resolve source MainEngineThread 
is returning 1612

You can look in the MSI file for the ProductCode in the Property table. If 
you're new to this, get hold of Orca from the Windows SDK/Kit. It's useful to 
see inside MSI files. Instead maybe useful also.
---
Phil Wilson


On Wed, Nov 19, 2014 at 10:35 AM, David Fritch dfri...@ldschurch.org wrote:
 Thanks for your comments.

 It looks like I cannot find the value 2CF25F13-12F8-4B54-AC62-0F29F54E4F54
 in my .wxs file.  I am guessing it is a mistake to leave the Product Id=*
 as an asterisk?  (I inherited this file from a previous developer and 
 am
 still very new to WiX.)

 Is the GUID in the log the same as the product code of the MSI you 
 are trying to install? (IE, is the MSI already installed on his machine?)
 [David] He had a previous version of the product installed on his machine.
 I believe he installed it while he was using his original windows 
 user.  He is now trying to upgrade the product using his new windows 
 user.  He saw the error when we were just trying to upgrade the 
 package.  He then uninstalled the older version and tried to run the 
 6.4 installer again with the same error.

 If so, you may need to recache the package, then do an uninstall.
 [David] What are the steps to recache a package?  I will certainly 
 lookup the steps on my own as well.

 Is this MSI a pre-user install
 [David] Do you mean 'per-user' install?  If so, then yes we install 
 all of the components to a directory within LocalAppDataFolder.  
 However, I am wondering if this warning that appears when I build the 
 installer may be affecting it as a true 'per-user' install.  For example,  
 error LGHT0204 :
 ICE38: Component TRADOS_PLUGINS installs to user profile. It must use 
 a registry key under HKCU as its KeyPath, not a file.

 Here is some of the XML from the .wxs file:

 Directory Id=TARGETDIR Name=SourceDir
   Directory Id=LocalAppDataFolder
 Directory Id=SDL Name=SDL
   Directory Id=SDLTradosStudio Name=SDL Trados Studio
 Directory Id=Ver11 Name=11
   Directory Id=Plugins Name=Plugins
 Directory Id=APPLICATIONROOTDIRECTORY Name=Packages /
   /Directory
 /Directory
   /Directory
 /Directory
   /Directory
 /Directory

 DirectoryRef Id=APPLICATIONROOTDIRECTORY
   Component Id=TRADOS_PLUGINS
 Guid=f80ba0d3-4385-4a11-a79f-682a715e8eed KeyPath=yes
 File Id=Lds.Psd.Lp.Trados.ScriptureTranslator.sdlplugin
 Source=LDSScriptureTranslator\Version
 5\Signed\Lds.Psd.Lp.Trados.ScriptureTranslator.sdlplugin /
 ...
   /Component
 /DirectoryRef




 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/SOURCEMG
 MT-Failed-to-resolve-source-MainEngineThread-is-returning-1612-tp75980
 95p7598108.html Sent from the wix-users mailing list archive at 
 Nabble.com.

 --
  Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT 
 Server from Actuate! Instantly Supercharge Your Business Reports and 
 Dashboards with Interactivity, Sharing, Native Excel Exports, App 
 Integration  more Get technology previously reserved for 
 billion-dollar corporations, FREE 
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.
 clktrk ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net

Re: [WiX-users] Problems upgrading to WiX 3.9

[Hoover, Jacob]

Uggh,
  Looks like a bug to me.  The DLL's in question have no extension, so when 
they were migrated to 3.9 on GitHub it seems the CRLF conversion in git mangled 
the DLL. 

-Original Message-
From: Majcica, Mario [mailto:mario.majc...@bakerhughes.com] 
Sent: Tuesday, November 18, 2014 2:35 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Problems upgrading to WiX 3.9

Isn't it part of VSExtension?

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Monday, November 17, 2014 18:00
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Problems upgrading to WiX 3.9

The problem is with your custom action.  The DLL which exports ExportTempHxDs, 
does it have any dependencies (ex: VC runtime)?

-Original Message-
From: Majcica, Mario [mailto:mario.majc...@bakerhughes.com]
Sent: Monday, November 17, 2014 6:44 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problems upgrading to WiX 3.9

Dear all,

I upgraded our project from WiX 3.7 to the latest 3.9 version.
I do have a problem however.

Although the msi is created correctly I do get the installation failing with 
the following error in the log:

Error 1723. There is a problem with this Windows Installer package. A DLL 
required for this install to complete could not be run. Contact your support 
personnel or package vendor.  Action 
CA_ExportTempHxDs.3643236F_FC70_11D3_A536_0090278A1BB8, entry: ExportTempHxDs, 
library: C:\windows\Installer\MSIC69F.tmp

In my Product.wxs I do find the following

  Directory Id=JsProgramFilesFolder Name=Program Files
Directory Id=CommonFilesFolder Name=Common Files
  Directory Id=MSShared.3643236F_FC70_11D3_A536_0090278A1BB8 
Name=Microsoft Shared
Directory Id=D_Help Name=Help
  Component Id=Bogus_HHRegCA_component 
Guid={07C0C968-85D1-11D4-A53F-0090278A1BB8} KeyPath=yes
CreateFolder Directory=D_Help /
  /Component
/Directory
  /Directory
/Directory
  /Directory

I haven't wrote this part of the installer and I do think is used for 
publishing help files.

If I use Wix 3.7 this works just well.

Any idea?

Thanks

Mario Majcica

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] why do I have to install twice to make things happen?

[Hoover, Jacob]

What's the condition on your custom action? What does the log file on the 
initial install look like? 

-Original Message-
From: jason.small...@bt.com [mailto:jason.small...@bt.com] 
Sent: Tuesday, November 18, 2014 11:00 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] why do I have to install twice to make things happen?

Hi,

I have created a Wix installer with a custom action.

However, I need to run the installer twice (without uninstalling inbetween) for 
the custom action to work.

Any ideas why?

I thought that I may have not properly uninstalled the application properly. I 
used the Control Panel. Is there a registry setting I can remove which will 
make my application be fully uninstalled from Windows.

Thanks
Jason

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] why do I have to install twice to make things happen?

[Hoover, Jacob]

That's the definition of the CA, but where is it scheduled? Judging from the 
name of the CA, it's modifying a payload the installer deploys.  Since your CA 
is modifying machine state, it should be a deferred CA and you should provide a 
rollback/uninstall CA as well. (That's more than likely the root of your 
problem, but until we can see your install execute sequence, it's just a hunch.)

To get verbose logs, use /l*v path to log when calling msiexec.  
Ex: msiexec /l*v %TEMP%\debug.log /I foo.msi

-Original Message-
From: jason.small...@bt.com [mailto:jason.small...@bt.com] 
Sent: Tuesday, November 18, 2014 11:10 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

My entry looks like this

CustomAction Id=ConfigureClientAction
  Return=check
  Execute=immediate
  BinaryKey=ConfigureClient
  DllEntry=EncryptConfigFile /

The action does a ActionResult.Success 

I am no expert on Wix so I don't know how to find the log file!

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 18 November 2014 17:04
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

What's the condition on your custom action? What does the log file on the 
initial install look like? 

-Original Message-
From: jason.small...@bt.com [mailto:jason.small...@bt.com]
Sent: Tuesday, November 18, 2014 11:00 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] why do I have to install twice to make things happen?

Hi,

I have created a Wix installer with a custom action.

However, I need to run the installer twice (without uninstalling inbetween) for 
the custom action to work.

Any ideas why?

I thought that I may have not properly uninstalled the application properly. I 
used the Control Panel. Is there a registry setting I can remove which will 
make my application be fully uninstalled from Windows.

Thanks
Jason

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] why do I have to install twice to make things happen?

[Hoover, Jacob]

If the uninstall has removed it's entry in ARP, you're as clean as clean gets. 
When developing CA's that modify machine state, I'd highly recommend using a VM 
for your testing.

Is this config file inside the MSI, or is it a companion file passed along with 
the MSI? If it's the latter and you can't do this work on first run of the 
application, I'd schedule the CA early and then use a semi-custom action to add 
a CopyFile record during installation. It gets more complex when you start 
thinking about repair/upgrade/uninstall scenarios.

-Original Message-
From: jason.small...@bt.com [mailto:jason.small...@bt.com] 
Sent: Tuesday, November 18, 2014 11:27 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

FYI - the custom action reads and modifies a configuration file that is 
supplied as part of the installation. So, all the custom action needs to run, 
is that file to have been put in the application folder.

-Original Message-
From: Smallman,AJ,Jason,JTA19 R
Sent: 18 November 2014 17:22
To: General discussion about the WiX toolset.
Subject: RE: [WiX-users] why do I have to install twice to make things happen?

Oh, here it is

InstallExecuteSequence
  Custom Action=ConfigureClientAction Before=InstallFinalize  /
/InstallExecuteSequence

Once I fix the problem, how do I go back to a clean state in my system i.e. 
guarantee that the uninstall has worked?


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 18 November 2014 17:19
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

That's the definition of the CA, but where is it scheduled? Judging from the 
name of the CA, it's modifying a payload the installer deploys.  Since your CA 
is modifying machine state, it should be a deferred CA and you should provide a 
rollback/uninstall CA as well. (That's more than likely the root of your 
problem, but until we can see your install execute sequence, it's just a hunch.)

To get verbose logs, use /l*v path to log when calling msiexec.  
Ex: msiexec /l*v %TEMP%\debug.log /I foo.msi

-Original Message-
From: jason.small...@bt.com [mailto:jason.small...@bt.com]
Sent: Tuesday, November 18, 2014 11:10 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

My entry looks like this

CustomAction Id=ConfigureClientAction
  Return=check
  Execute=immediate
  BinaryKey=ConfigureClient
  DllEntry=EncryptConfigFile /

The action does a ActionResult.Success 

I am no expert on Wix so I don't know how to find the log file!

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 18 November 2014 17:04
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

What's the condition on your custom action? What does the log file on the 
initial install look like? 

-Original Message-
From: jason.small...@bt.com [mailto:jason.small...@bt.com]
Sent: Tuesday, November 18, 2014 11:00 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] why do I have to install twice to make things happen?

Hi,

I have created a Wix installer with a custom action.

However, I need to run the installer twice (without uninstalling inbetween) for 
the custom action to work.

Any ideas why?

I thought that I may have not properly uninstalled the application properly. I 
used the Control Panel. Is there a registry setting I can remove which will 
make my application be fully uninstalled from Windows.

Thanks
Jason

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] why do I have to install twice to make things happen?

[Hoover, Jacob]

Use a deferred custom action, and use an auxiliary SetProperty custom action to 
assign the properties that are needed by it.

http://wix.tramontana.co.hu/tutorial/events-and-actions/at-a-later-stage

http://stackoverflow.com/questions/11233267/how-to-pass-customactiondata-to-a-customaction-using-wix

Note: Because you are modifying the config file, windows installer is going to 
see the file as modified and more than likely is not going to remove it on 
uninstall. Ass a RemoveFile entry to explicitly remove the file to ensure the 
uninstall cleanly removes it. You will also want to condition your deferred CA 
to only run when you want it to. 

-Original Message-
From: jason.small...@bt.com [mailto:jason.small...@bt.com] 
Sent: Tuesday, November 18, 2014 12:20 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

What is the best combination of Execute= and CustomAction to allow me to 
alter a file after it has been placed in a folder?

-Original Message-
From: David Connet [mailto:d...@agilityrecordbook.com]
Sent: 18 November 2014 18:09
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

The problem is that your CA is immediate. So when you run, the file hasn't been 
installed yet - they're installed during the deferred phase.
Dave

 
  From: jason.small...@bt.com jason.small...@bt.com
 To: wix-users@lists.sourceforge.net
 Sent: Tuesday, November 18, 2014 9:26 AM
 Subject: Re: [WiX-users] why do I have to install twice to make things happen?
   
FYI - the custom action reads and modifies a configuration file that is 
supplied as part of the installation. So, all the custom action needs to run, 
is that file to have been put in the application folder.

-Original Message-
From: Smallman,AJ,Jason,JTA19 R
Sent: 18 November 2014 17:22
To: General discussion about the WiX toolset.
Subject: RE: [WiX-users] why do I have to install twice to make things happen?

Oh, here it is
    
    InstallExecuteSequence
      Custom Action=ConfigureClientAction Before=InstallFinalize  /
    /InstallExecuteSequence

Once I fix the problem, how do I go back to a clean state in my system i.e. 
guarantee that the uninstall has worked?


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 18 November 2014 17:19
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

That's the definition of the CA, but where is it scheduled? Judging from the 
name of the CA, it's modifying a payload the installer deploys.  Since your CA 
is modifying machine state, it should be a deferred CA and you should provide a 
rollback/uninstall CA as well. (That's more than likely the root of your 
problem, but until we can see your install execute sequence, it's just a hunch.)

To get verbose logs, use /l*v path to log when calling msiexec.
Ex: msiexec /l*v %TEMP%\debug.log /I foo.msi

-Original Message-
From: jason.small...@bt.com [mailto:jason.small...@bt.com]
Sent: Tuesday, November 18, 2014 11:10 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

My entry looks like this

    CustomAction Id=ConfigureClientAction
      Return=check
      Execute=immediate
      BinaryKey=ConfigureClient
      DllEntry=EncryptConfigFile /

The action does a ActionResult.Success 

I am no expert on Wix so I don't know how to find the log file!

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 18 November 2014 17:04
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] why do I have to install twice to make things happen?

What's the condition on your custom action? What does the log file on the 
initial install look like? 

-Original Message-
From: jason.small...@bt.com [mailto:jason.small...@bt.com]
Sent: Tuesday, November 18, 2014 11:00 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] why do I have to install twice to make things happen?

Hi,

I have created a Wix installer with a custom action.

However, I need to run the installer twice (without uninstalling inbetween) for 
the custom action to work.

Any ideas why?

I thought that I may have not properly uninstalled the application properly. I 
used the Control Panel. Is there a registry setting I can remove which will 
make my application be fully uninstalled from Windows.

Thanks
Jason

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id

Re: [WiX-users] InstallUISequence not working when kept out of product

[Hoover, Jacob]

You'd only need one reference to an object inside the fragment for the entire 
fragment to be included.

A more common approach I've used is to have a fragment per CA, and then use a 
property ref to pull it into the product.  

Ex:
  Fragment
Condition Message=This application requires Microsoft Visual C++ Runtime 
2010 SP1. Please install Microsoft Visual C++ Runtime 2010 SP1 then run this 
installer again.
  ![CDATA[Installed OR VC2010SP1]]
/Condition
Property Id=VC2010SP1 Secure=yes/
CustomAction Id=VC2010SP1InstalledCA BinaryKey=Prerequisites 
DllEntry=VC2010SP1InstalledCA Return=check Execute=firstSequence /
InstallUISequence
  Custom Action=VC2010SP1InstalledCA After=AppSearchNOT 
Installed/Custom
/InstallUISequence
InstallExecuteSequence
  Custom Action=VC2010SP1InstalledCA After=AppSearchNOT 
Installed/Custom
/InstallExecuteSequence
  /Fragment

And then in the product:
PropertyRef Id=VC2010SP1/

-Original Message-
From: ssmsam [mailto:ssmcs...@gmail.com] 
Sent: Monday, November 17, 2014 1:15 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] InstallUISequence not working when kept out of 
product

Ah!! Thanks Phill. 
I figured out that we have got 300 CAs in our product. So, the Product.wxs file 
looks horribly huge bcoz of these CustomActionRef.. 

Can i keep all CustomActionRefs in other file's fragment?

Regards,
Sampat



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/InstallUISequence-not-working-when-kept-out-of-product-tp7597976p7597983.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problems upgrading to WiX 3.9

[Hoover, Jacob]

The problem is with your custom action.  The DLL which exports ExportTempHxDs, 
does it have any dependencies (ex: VC runtime)?

-Original Message-
From: Majcica, Mario [mailto:mario.majc...@bakerhughes.com] 
Sent: Monday, November 17, 2014 6:44 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problems upgrading to WiX 3.9

Dear all,

I upgraded our project from WiX 3.7 to the latest 3.9 version.
I do have a problem however.

Although the msi is created correctly I do get the installation failing with 
the following error in the log:

Error 1723. There is a problem with this Windows Installer package. A DLL 
required for this install to complete could not be run. Contact your support 
personnel or package vendor.  Action 
CA_ExportTempHxDs.3643236F_FC70_11D3_A536_0090278A1BB8, entry: ExportTempHxDs, 
library: C:\windows\Installer\MSIC69F.tmp

In my Product.wxs I do find the following

  Directory Id=JsProgramFilesFolder Name=Program Files
Directory Id=CommonFilesFolder Name=Common Files
  Directory Id=MSShared.3643236F_FC70_11D3_A536_0090278A1BB8 
Name=Microsoft Shared
Directory Id=D_Help Name=Help
  Component Id=Bogus_HHRegCA_component 
Guid={07C0C968-85D1-11D4-A53F-0090278A1BB8} KeyPath=yes
CreateFolder Directory=D_Help /
  /Component
/Directory
  /Directory
/Directory
  /Directory

I haven't wrote this part of the installer and I do think is used for 
publishing help files.

If I use Wix 3.7 this works just well.

Any idea?

Thanks

Mario Majcica

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] InstallUISequence not working when kept out of product

[Hoover, Jacob]

I'd have all 3 CA's in a fragment, one for install, one for uninstall, and one 
for rollback.  Schedule them in the fragment. (If you have multiple CA's for 
the same purpose, then it would make sense to have them in the same fragment.)  
You'd only need one property ref to pull in all 3.  

I do wonder why you have so many CA's.

-Original Message-
From: ssmsam [mailto:ssmcs...@gmail.com] 
Sent: Monday, November 17, 2014 11:08 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] InstallUISequence not working when kept out of 
product

Yeah!! its very clear now!!

If we have 10 CAs(if all are defered, then 10 install C.As, then 10 un-install 
CAs and then 10 RollBack C.A ) so it comes to 30 C.As in total. 

So if i keep each C.A in separate .wxs (Eg. *VC2010SP1InstalledCA.wxs* in ur
case) then i have to include *3 * N PropertyRef* into the product. (*N being 
the number of such defered C.As*) .

1). Wouldnt it make Product.wxs look huge??
2). If i include InstallUISequence ny where, it should add an entry to that 
respective msi table. Why dont it ? 

Please share your thoughts.

Regards,
Sampat









--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/InstallUISequence-not-working-when-kept-out-of-product-tp7597976p7598008.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [SPAM] Re: InstallUISequence not working when kept out of product

[Hoover, Jacob]

I'd also vote for using a semi-custom action where possible, in which at 
runtime you modify the MSI DB to schedule changes.  With this approach, the 
existing transactional behaviors come for free. Ref: 
http://www.joyofsetup.com/2007/07/01/semi-custom-actions/

-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com] 
Sent: Monday, November 17, 2014 12:11 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] [SPAM] Re: InstallUISequence not working when kept out 
of product

As I was/am learning wix, particularly as I converted from IS to wix and needed 
to write a CAs for some printer driver configuration, I found it helpful to 
study the WixExtensions, and particularly the WixGamingExtension was helpful.  
These also demonstrate using an immeadiate custom action to schedule defered 
CAs handle install, uninstall, and rollback.



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/InstallUISequence-not-working-when-kept-out-of-product-tp7597976p7598018.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! 
Instantly Supercharge Your Business Reports and Dashboards with Interactivity, 
Sharing, Native Excel Exports, App Integration  more Get technology previously 
reserved for billion-dollar corporations, FREE 
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WIX Installation fails to Install Certificate to Root Certification Authorities for Some machines

[Hoover, Jacob]

This might be a regression, though I haven't dug to history to see if it was 
intentionally changed back.

Ref: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Certificate-install-to-local-machine-fails-with-code-26352-td1121050.html

From the current certutil.cpp

if (!::CertAddCertificateContextToStore(hStore, pCertContext, 
CERT_STORE_ADD_REPLACE_EXISTING, NULL))
{
ExitWithLastError(hr, Failed to add certificate to the store.);
}

And from the linked thread the suggestion was:

To fix this, you should just be able to change the calls in the IIS 
extension source (scacertexec.cpp and scacert.cpp) to 
CertAddCertificateContextToStore.  Instead of using 
CERT_STORE_ADD_REPLACE_EXISTING, you can use 
CERT_STORE_ADD_USE_EXISTING.  This updates the current cert instead of 
duplicating it, and the test case detailed above should pass.  You will 
notice that the certificate will be listed in both the registry and 
group policy physical stores, but I don't think there's anything we can 
do about that.


-Original Message-
From: KaburagiS [mailto:skabur...@ntst.com] 
Sent: Friday, November 14, 2014 9:27 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WIX Installation fails to Install Certificate to Root 
Certification Authorities for Some machines

We have created a WIX installation MSI that installs certificates to machine 
store. It installs a root certificate (GoDaddy Class 2 Certification
Authority) to the Trusted Root Certification Authorities. It works for most of 
machines, but it fails some machines. We suspected the group policy 
restrictions( http://technet.microsoft.com/en-us/library/cc754841.aspx), but 
the change did not resolve the problem. Below is a WIX definition and a portion 
of the log file that shows where the error occurs.

DirectoryRef Id=ApplicationDirectory

  Component Id=G.Root.Cert Guid={C6672075-1BFB-4158-86B4-8DD6D26BBC12}
CreateFolder /


iis:Certificate Id=GoDaddy.Class2.Certificate
 Name=GoDaddy Class 2 Certificate
 Request=no
 StoreLocation=localMachine
 StoreName=root
 Overwrite=no
 BinaryKey=GoDaddy.Class2.Binary
 /

  /Component
MSI (s) (B4:08) [11:58:21:952]: Executing op:
CustomActionSchedule(Action=RollbackAddMachineCertificate,ActionType=11521,Source=BinaryData,Target=**,CustomActionData=**)
MSI (s) (B4:08) [11:58:21:953]: Executing op:
ActionStart(Name=AddMachineCertificate,,) Action 11:58:21:
AddMachineCertificate. MSI (s) (B4:08) [11:58:21:953]: Executing op:
CustomActionSchedule(Action=AddMachineCertificate,ActionType=11265,Source=BinaryData,Target=**,CustomActionData=**)
MSI (s) (B4:40) [11:58:21:980]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI3EE3.tmp, Entrypoint: AddMachineCertificate MSI (s)
(B4:D0) [11:58:21:981]: Generating random cookie. MSI (s) (B4:D0)
[11:58:21:982]: Created Custom Action Server with PID 9920 (0x26C0). MSI (s)
(B4:90) [11:58:22:042]: Running as a service. MSI (s) (B4:90)
[11:58:22:043]: Hello, I'm your 32bit Elevated custom action server.
AddMachineCertificate: Deleting certificate that begin with friendly name:
GoDaddy Class 2 Certificate_wixCert_ AddMachineCertificate: Adding
certificate: GoDaddy Class 2 Certificate_wixCert_1 AddMachineCertificate:
Error 0x80070005: Failed to add certificate to the store. MSI (s) (B4!0C)
[11:58:22:173]: Note: 1: 2205 2: 3: Error MSI (s) (B4!0C) [11:58:22:173]:
Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 26352 The 
installer has encountered an unexpected error installing this package.
This may indicate a problem with this package. The error code is 26352. The 
arguments are: -2147024891, , MSI (s) (B4!0C) [11:58:27:816]: Note: 1: 2205
2: 3: Error MSI (s) (B4!0C) [11:58:27:816]: Note: 1: 2228 2: 3: Error 4:
SELECT Message FROM Error WHERE Error = 1709 MSI (s) (B4!0C) [11:58:27:816]:
Product: Netsmart VR BA Prerequisites -- The installer has encountered an 
unexpected error installing this package. This may indicate a problem with this 
package. The error code is 26352. The arguments are: -2147024891, ,

AddMachineCertificate: Error 0x80070005: Failed to install certificate.
AddMachineCertificate: Error 0x80070005: Failed to install per-machine 
certificate. CustomAction AddMachineCertificate returned actual error code
1603 (note this may not be 100% accurate if translation happened inside
sandbox) Action ended 11:58:27: InstallFinalize. Return value 3. MSI (s)
(B4:08) [11:58:27:961]: User policy value 'DisableRollback' is 0 MSI (s)
(B4:08) [11:58:27:962]: Machine policy value 'DisableRollback' is 0 MSI (s)
(B4:08) [11:58:27:972]: Executing op:
Header(Signature=1397708873,Version=500,Timestamp=1163681610,LangId=1033,Platform=0,ScriptType=2,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)

We are puzzled as to what causes this problem. If you have any idea as to what 

Re: [WiX-users] [SPAM] Re: WixStdBA launches 32-bit msiexec.exe for a 64-bit MsiPackage

[Hoover, Jacob]

What is the bitness of your CA DLL?  Just a stab in the dark but you might need 
to have it compiled twice, once as 32 and once as 64, and have the respective 
MSI package use the right CA DLL.


-Original Message-
From: Rob Mensching [mailto:r...@firegiant.com] 
Sent: Friday, November 14, 2014 9:53 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] [SPAM] Re: WixStdBA launches 32-bit msiexec.exe for a 
64-bit MsiPackage

Custom actions are hosted by Windows Installer in a separate custom action host 
process based on custom action type.

_
 Short replies here. Complete answers over there: http://www.firegiant.com/


-Original Message-
From: Ryan Waller [mailto:rwal...@microsoft.com] 
Sent: Friday, November 14, 2014 7:43 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] [SPAM] Re: WixStdBA launches 32-bit msiexec.exe for a 
64-bit MsiPackage

Yes, Orca Summary shows it with Platform x64.

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Major Upgrade : Conditional uninstallation on even version number

[Hoover, Jacob]

For what it's worth, I recently proposed adding this to WixStdBA, but we 
haven't had time yet to discuss it.


 On Nov 13, 2014, at 3:27 AM, CALCEL Sebastien 
 sebastien.cal...@econocom-osiatis.com wrote:
 
 Thanks for your answer Jacob.
 I ended on same conclusion about the custom BA.
 
 -Message d'origine-
 De : Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
 Envoyé : jeudi 6 novembre 2014 15:53
 À : General discussion about the WiX toolset.
 Cc : FAURE Helian
 Objet : Re: [WiX-users] Major Upgrade : Conditional uninstallation on even 
 version number
 
 I've got a similar requirement.  In order to only conditionally uninstall, 
 each major upgrade needs to have a new upgrade code and product code. In my 
 use case the application will only be installed by a bundle, so I can add a 
 related bundle with an action of detect and conditionally request the 
 uninstall of the related bundle (in my case I want a check box on the UI, and 
 let the user decide if they wish to remove the older version).  This will 
 allow multiple versions of an application to peacefully co-exist (unique 
 component id's, unique install folders).
 
 Either way, I believe to get the functionality you want will require a custom 
 BA (I don't think a BA function DLL has all the callbacks in that you would 
 need to just augment WixStdBA).
 
 -Original Message-
 From: CALCEL Sebastien [mailto:sebastien.cal...@econocom-osiatis.com] 
 Sent: Thursday, November 06, 2014 4:34 AM
 To: 'wix-users@lists.sourceforge.net'
 Cc: FAURE Helian
 Subject: [WiX-users] Major Upgrade : Conditional uninstallation on even 
 version number
 
 Hello everyone,
 
 I would like to know if there is a mean to make the uninstallation of 
 previous versions conditional in the case of a Major Upgrade.
 
 Here's the context :
 
 We recently migrated our application setup from the VS 2008 MSI project.
 We now have a WiX installer project for the app and a bootstrapper project 
 which embed the output MSI of the first one plus dependencies.
 
 Now our client asks us to prevent older versions of the app to be removed if 
 the current installation version number is uneven.
 
 In resume :
 4.0.3 = no older versions uninstallation.
 4.2.0 = older versions uninstall.
 
 Could someone tells me if this is possible ? And if it is, how do do so ?
 
 Here's the beginning of the app installer wxs  :
 
 Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
 
  ?define FullMaintVersion=!(bind.FileVersion.AppMainFolder_App) ?
  ?define version=4.3.0 ?
  ?define UpgradeCode={509102D1-A560-4552-A115-8C27D82DEB86} ?
 
  Product Id={3ADE095D-AAE3-4DA7-A872-AFDB7A8BFDA2}
   Name=App 4.3.0
   Version=$(var.version)
   Language=1036
   Manufacturer=APCbyS
   UpgradeCode=$(var.UpgradeCode)
 
Package Id=* Description=Maint2Install 4.3.0 Keywords=Installer 
 InstallerVersion=200 Compressed=yes InstallScope=perMachine /
 
InstallExecuteSequence
  Custom Action=SetCustomActionDataValue After=InstallFiles /
  Custom Action=LaunchOlderExe After=SetCustomActionDataValue /
  !--RemoveExistingProducts 
 After='InstallInitialize'PREVIOUSFOUND/RemoveExistingProducts--
/InstallExecuteSequence
 
Media Id=1 Cabinet='data.cab' EmbedCab='yes'/
 
 Thanks in advance,
 
 Sébastien.
 
 
 --
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Change MSI Package Install/Uninstall Order

[Hoover, Jacob]

Why? By design the chain is always in reverse order when uninstalling.

 On Nov 13, 2014, at 7:37 AM, Saravanan periyasa...@syncfusion.com wrote:
 
 Hi All,
 
 I am using Wix 3.9. Created installer using custom Boostrapper application.
 I need some clarification about MSIPackage execution sequence. 
 
 My Bundle\Chain having,
 
 Chain
 
  MsiPackage DisplayInternalUI=no Id=SampleMSIPackage1  Compressed=no
 SourceFile=D:\MSI\SamplePackage1.msi Visible=no  ForcePerMachine=yes
 Permanent=no Vital=yes EnableFeatureSelection=yes /
 
  MsiPackage DisplayInternalUI=no Id=SampleMSIPackage2  Compressed=no
 SourceFile=D:\MSI\SamplePackage2.msi Visible=no  ForcePerMachine=yes
 Permanent=no Vital=yes EnableFeatureSelection=yes /
 
  MsiPackage DisplayInternalUI=no Id=SampleMSIPackage3  Compressed=no
 SourceFile=D:\MSI\SamplePackage3.msi Visible=no  ForcePerMachine=yes
 Permanent=no Vital=yes EnableFeatureSelection=yes /
 /Chain
 
 On Installation, MSI installed in following sequence,
 SamplePackage1.msi
 SamplePackage2.msi
 SamplePackage3.msi
 
 On Uninstallation, msi called reverse order of installation order. That is
 last installed MSI(SamplePackage3) called first.
 
 But I need to change the sequence in uninstall. I need to execute all MSI
 packages in installed order.
 
 Is it possible? Can you please share any idea on this?
 
 Regards,
 Saravanan
 
 
 
 
 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Change-MSI-Package-Install-Uninstall-Order-tp7597904.html
 Sent from the wix-users mailing list archive at Nabble.com.
 
 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem during uninstall !

[Hoover, Jacob]

Script based ca's are unreliable at best. Odds are your vbs script is failing 
on uninstall.

Logs would verify this, and you can use orca to condition the script not to run 
on uninstall. From there you should be able to uninstall the existing installs 
(you may have to tell windows installer to re-cache the package first).

Sent from my iPhone

 On Nov 13, 2014, at 9:05 AM, Fabrice MAUPIN fmau...@iback.fr wrote:
 
 Hi everybody,
 
 
 
 When I try to uninstall my application, this message appears :
 
 
 
 There is a problem with this Windows Installer Package.
 
 
 
 A script required for this install to complete could not be run.
 
 
 
 Contact your support personnel or package vendor.
 
 
 
 
 
 For information my application is installed with a MSI package.
 
 
 
 The package is generated under Eclipse / ANT / WIX.
 
 
 
 The process of installation of my application is correctly made, no error
 message.
 
 
 
 
 
 *** I desactivate my anti-virus (AVAST 2015) to verify behaviors with
 blocking scripts :  it's always the same problem.
 
 
 
 
 
 You will find the attached WXS file for more details.
 
 
 
 
 
 Any ideas ?
 
 
 
 Thanks,
 
 
 
 Fabrice
 
 
 
 ---
 L'absence de virus dans ce courrier électronique a été vérifiée par le 
 logiciel antivirus Avast.
 http://www.avast.com
 config.txt
 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Active directory browser

[Hoover, Jacob]

Or create a custom MBA and use the existing framework bits from .Net. Then you 
can just property drive the MSI.

 On Nov 12, 2014, at 5:01 PM, Bruce Cran br...@cran.org.uk wrote:
 
 I don't know if it would be any use, but Apache has a suite of AD/LDAP 
 tools/libraries at http://directory.apache.org/studio/ .
 
 -- 
 Bruce
 
 On Nov 11, 2014, at 10:12 PM, pezmannen pezman...@gmail.com wrote:
 
 My setup includes several dialogs where you need to specify different Active
 Directory accounts. For now, they are all free text and it's pretty easy to
 miss spell. I found Msiext (http://dblock.github.io/msiext/) but was
 wondering if there is something out there that can be used without starting
 compiling cpp-code?
 
 Thanks
 
 
 
 --
 View this message in context: 
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Active-directory-browser-tp7597858.html
 Sent from the wix-users mailing list archive at Nabble.com.
 
 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Language packs difference causing installation to fail.

[Hoover, Jacob]

Sounds like you are using a CA to modify security.  Computer group names, even 
builtin's, are localized so your CA would need to take this into account.  If 
your using a framework provided CA, then please identify the relevant fragments.

-Original Message-
From: MartinInstall [mailto:martin.l...@matrixteam.com] 
Sent: Monday, November 10, 2014 2:36 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Language packs difference causing installation to fail.

I am trying to install software on computer with a Finnish language pack.

Both computers are running windows 7 and the installer works fine on US English 
computers.

It seems that the Users group is in Finnish and the error I get is, “An error 
occurred while applying security settings. Users is not a valid user or group”.

Does anyone have a work around or suggestions?

Thanks,
Martin




--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Language-packs-difference-causing-installation-to-fail-tp7597833.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Language packs difference causing installation to fail.

[Hoover, Jacob]

ALLUSERS is a standard property.  I did just look on a Chinese XP VM, and it 
does have a Users group.  However, on a Spanish Vista VM, it's not in English.

Are you doing anything special with security settings?  Can you post the 
verbose log file?

-Original Message-
From: MartinInstall [mailto:martin.l...@matrixteam.com] 
Sent: Monday, November 10, 2014 3:46 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Language packs difference causing installation to fail.

Thanks for the quick reply,

I am not using any custom actions.

I am assuming that the  Property Id=ALLUSERS Value=1 / is relying on the 
Users group to be present.

On the target computer, we did not find a Users group, only the Finish word for 
Users.

I am sure this is a common scenario for people writing software intended for 
the global market.

Any other suggestions?



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Language-packs-difference-causing-installation-to-fail-tp7597833p7597835.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing DirectX9 Components within a perUser MSI

[Hoover, Jacob]

1) Remove the CA from your MSI.
2) Create a bundle including DX9 and your MSI in the chain.

http://wixtoolset.org/documentation/manual/v3/bundle/

http://wixtoolset.org/documentation/manual/v3/bundle/wixstdba/

WixStdBA comes with the toolset, and you can use it for basic installs, but if 
you need to customize the user experience a lot, you may have to write your own 
BA.

-Original Message-
From: Paul Finkiewicz [mailto:p...@mvsengineering.com] 
Sent: Wednesday, November 05, 2014 4:04 PM
To: 'General discussion about the WiX toolset.'
Subject: Re: [WiX-users] Installing DirectX9 Components within a perUser MSI

Yes, DirectX9 is a prerequisite to my app.

I suppose I'm down to 1 option other than having end users installing
DirectX9 themselves.

How do I go about changing my code to include your burn option?

Regards,
Paul
*** Email Confidentiality Notice ***


-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Wednesday, November 05, 2014 1:19 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Installing DirectX9 Components within a perUser MSI

You won't be able to force a 3rd party installer to change scope very easily, 
especially in the case of an EXE based installation (nor would I
recommend doing so).   What exactly are you trying to do?  If DirectX is a
prerequisite to your software, use burn to install it in the chain before your 
MSI.  If your simply trying to wrap the DX setup in a MSI (maybe for legacy AD 
deployment??) then you're on your own as far as MS supporting it.  Concurrent 
installs are bad.

Ref: http://msdn.microsoft.com/en-us/library/aa368010(v=vs.85).aspx



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

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

Re: [WiX-users] Major Upgrade : Conditional uninstallation on even version number

[Hoover, Jacob]

I've got a similar requirement.  In order to only conditionally uninstall, each 
major upgrade needs to have a new upgrade code and product code. In my use 
case the application will only be installed by a bundle, so I can add a related 
bundle with an action of detect and conditionally request the uninstall of the 
related bundle (in my case I want a check box on the UI, and let the user 
decide if they wish to remove the older version).  This will allow multiple 
versions of an application to peacefully co-exist (unique component id's, 
unique install folders).

Either way, I believe to get the functionality you want will require a custom 
BA (I don't think a BA function DLL has all the callbacks in that you would 
need to just augment WixStdBA).

-Original Message-
From: CALCEL Sebastien [mailto:sebastien.cal...@econocom-osiatis.com] 
Sent: Thursday, November 06, 2014 4:34 AM
To: 'wix-users@lists.sourceforge.net'
Cc: FAURE Helian
Subject: [WiX-users] Major Upgrade : Conditional uninstallation on even version 
number

Hello everyone,

I would like to know if there is a mean to make the uninstallation of previous 
versions conditional in the case of a Major Upgrade.

Here's the context :

We recently migrated our application setup from the VS 2008 MSI project.
We now have a WiX installer project for the app and a bootstrapper project 
which embed the output MSI of the first one plus dependencies.

Now our client asks us to prevent older versions of the app to be removed if 
the current installation version number is uneven.

In resume :
4.0.3 = no older versions uninstallation.
4.2.0 = older versions uninstall.

Could someone tells me if this is possible ? And if it is, how do do so ?

Here's the beginning of the app installer wxs  :

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

  ?define FullMaintVersion=!(bind.FileVersion.AppMainFolder_App) ?
  ?define version=4.3.0 ?
  ?define UpgradeCode={509102D1-A560-4552-A115-8C27D82DEB86} ?

  Product Id={3ADE095D-AAE3-4DA7-A872-AFDB7A8BFDA2}
   Name=App 4.3.0
   Version=$(var.version)
   Language=1036
   Manufacturer=APCbyS
   UpgradeCode=$(var.UpgradeCode)

Package Id=* Description=Maint2Install 4.3.0 Keywords=Installer 
InstallerVersion=200 Compressed=yes InstallScope=perMachine /

InstallExecuteSequence
  Custom Action=SetCustomActionDataValue After=InstallFiles /
  Custom Action=LaunchOlderExe After=SetCustomActionDataValue /
  !--RemoveExistingProducts 
After='InstallInitialize'PREVIOUSFOUND/RemoveExistingProducts--
/InstallExecuteSequence

Media Id=1 Cabinet='data.cab' EmbedCab='yes'/

Thanks in advance,

Sébastien.


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

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

Re: [WiX-users] Installing DirectX9 Components within a perUser MSI

[Hoover, Jacob]

You won't be able to force a 3rd party installer to change scope very easily, 
especially in the case of an EXE based installation (nor would I recommend 
doing so).   What exactly are you trying to do?  If DirectX is a prerequisite 
to your software, use burn to install it in the chain before your MSI.  If your 
simply trying to wrap the DX setup in a MSI (maybe for legacy AD deployment??) 
then you're on your own as far as MS supporting it.  Concurrent installs are 
bad.

Ref: http://msdn.microsoft.com/en-us/library/aa368010(v=vs.85).aspx



-Original Message-
From: Paul Finkiewicz [mailto:p...@mvsengineering.com] 
Sent: Wednesday, November 05, 2014 3:12 PM
To: 'General discussion about the WiX toolset.'
Subject: Re: [WiX-users] Installing DirectX9 Components within a perUser MSI

I'm suggesting it is a permissions issue because it works on my machine with
elevated permissions. The problem is on a PC that is limited.

I checked the log on the problem PC and get this:

Product: MYProduct -- Error 1721. There is a problem with this Windows
Installer package. A program required for this install to complete could not
be run. Contact your support personnel or package vendor. Action:
InstallDirectX, location: C:\Users\LocalUser\AppData\Local\VNet
Beta\DirectX9\dxsetup.exe, command: /silent


-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com] 
Sent: Wednesday, November 05, 2014 12:53 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Installing DirectX9 Components within a perUser MSI

Is the install log showing anything helpful? You say it's a permissions
issue.




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

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

Re: [WiX-users] How to suppress the StdBA Bootstrapper UI

[Hoover, Jacob]

1) Not what it was designed to do. Instead of trying to fight burn, why not try 
to embrace it.  Create a single unified user experience in the BA, and then 
property drive your MSI's silently.

2) I believe the splash is hidden after detect completes. Instead of trying to 
embed valuable information in the splash screen, why not display it in the 
welcome dialog of WixStdBA?

WiX (including WixStdBA) is open source, so if you really want to make the 
changes you can. 

-Original Message-
From: ssmsam [mailto:ssmcs...@gmail.com] 
Sent: Monday, November 03, 2014 7:51 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to suppress the StdBA Bootstrapper UI

Hi,

I have chained a single msi package(with DisplayInternalUI option being
true)  inside the StdBA using wix 3.9 toolset. My questions are as follows,

1). Can we *suppress the small StdBA UI* which will be displayed in the 
background till the installation of chained msi completes.? In this case we had 
to click finish on msi setupcomplete dialog and on StdBA finish dialog.

2). We are displaying splash screen for our product on triggering StdBA. The 
time that this splash screen stays is very changing on different runs and also 
on our test VM Machines.
In my laptop it comes and vanishes like a lightening. 
We have included some info about version,name , release etc on splash screen so 
that customers can have a quick look at it. 

So is there any way to make it stay for particular amount of time, say for 5 
secs. ?

Regards,
Sampat



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-suppress-the-StdBA-Bootstrapper-UI-tp7597705.html
Sent from the wix-users mailing list archive at Nabble.com.

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

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

Re: [WiX-users] How To Detect Visual C++ 2012 X64 RunTime In Wix Bootstrapper Project

[Hoover, Jacob]

http://blogs.msdn.com/b/astebner/archive/2010/05/05/10008146.aspx

Scroll down and read through the comments for the 2012/x64 product codes, not 
certain if there is a reg check you can do that is update safe.

-Original Message-
From: Hippias Lesser [mailto:lesser.hipp...@gmail.com] 
Sent: Tuesday, November 04, 2014 3:32 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How To Detect Visual C++ 2012 X64 RunTime In Wix 
Bootstrapper Project

 want to detect If Visual C++ 2012 X64 RunTime is installed or not.

There is samples and Registery keys sample for Visual C++ 2010 But I can not 
figure out for C++ 2012 X64 RunTime registery search key .

So How To Detect Visual C++ 2012 X64 RunTime In Wix Bootstrapper Project?
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

Re: [WiX-users] Installation Directory not getting cleaned up on un-installation

[Hoover, Jacob]

Basically saying the same thing here... Don't use RegAsm from your installer.  
Use RegAsm on your build machine, then heat the tlb file and capture the 
registry info to be included in your installer.  You probably need to deploy 
the TLB files with your installer as well.

-Original Message-
From: Renan Lefeuvre [mailto:r.lefeu...@ag2l.fr] 
Sent: Monday, November 03, 2014 11:11 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Installation Directory not getting cleaned up on 
un-installation

Maybe i'm wrong but tlb files and respective dlls are embedded in your 
installer.

So you have them somewhere before generating the installer.

If you parse your tlb files with heat, you will generate the wxs file with 
necessary registry entries. It's the same thing for respective dlls.

What I did in my Wix project was calling heat before generating the installer.

When the installer is executed the tlb and dll files are registered 
automatically without running regasm.exe

Regards,

Renan

-Message d'origine-
De : ssmsam [mailto:ssmcs...@gmail.com] Envoyé : lundi 3 novembre 2014 17:31 À 
: wix-users@lists.sourceforge.net Objet : Re: [WiX-users] Installation 
Directory not getting cleaned up on un-installation

Hi Renan, fyodork

Thanks for your thoughts. 
To use heat on tlb files, tlb files must be passed to heat to generate a 
component. I will not be having tlb files till the installation completes.

By your thought what i understand is,
Execute the RegAsm.exe, in command prompt, on dll to get the respective dlls 
and then run heat over them??

Please correct me if i am wrong.

regards,
Sampat



--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installation-Directory-not-getting-cleaned-up-on-un-installation-tp7597662p7597680.html
Sent from the wix-users mailing list archive at Nabble.com.

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

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

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