Re: [WiX-users] WiX 3.6 MergeModule creation regression?
Hello Rob,
here is a minimal mergemodule showing the error:
?xml version=1.0 encoding=UTF-8 ?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Module Id=MergeModule Language=1033 Version=1.0.0.0
Package Id={SomeGUID} Manufacturer=ACME InstallerVersion=200
/
Directory Id=TARGETDIR Name=SourceDir
Directory Id=CommonFilesFolder /
/Directory
DirectoryRef Id=CommonFilesFolder
Directory Id=ComStaHelper Name=ACME
Directory Id=ComStaHelperComSta Name=ComStaHelper
Component Id=cComSTAHelper SharedDllRefCount=yes
File Id=ComSTAHelper Name=ComSTAHelper.dll
Source=ComSTAHelper.dll KeyPath=yes Checksum=yes /
/Component
/Directory
/Directory
/DirectoryRef
/Module
/Wix
W:\tmp\CommonFiles.wxs(14) : error LGHT0231 : The component
'cComSTAHelper.63744358_CA08_4563_B039_4BE7181B668E' has a key file with
path 'TARGETDIR\acme\comsta
helper\comstahelper.dll'. Since this path is not rooted in one of the
standard directories (like ProgramFilesFolder), this component does not fit
the criteria
for having an automatically generated guid. (This error may also occur if
a path contains a likely standard directory such as nesting a directory
with name Co
mmon Files under ProgramFilesFolder.)
Kind regards
Dirk
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Having trouble installing a native assembly in SxS
Hi all,
I am having trouble installing a native assembly in WinSxS. Here's what I
did:
I created a simple native code dll (just let VC2010 create one for me,
really)
I have self-signed a certificate, pktextract gives me this on it:
Microsoft (R) Side-By-Side Public Key Token Extractor 1.1.3.0
Copyright (C) Microsoft Corporation 2000-2002. All Rights Reserved
Certificate: SxS Test Cert - 2048 bits long
publicKeyToken=750e4397f64dcd89
I used signtool to sign the dll. I did not timestamped it, and that shows
when I look at dll properties.
I created a manifest for my assembly using mt.exe:
?xml version=1.0 encoding=UTF-8 standalone=yes?
assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0
assemblyIdentity name=TestDLL processorArchitecture=x86
publicKeyToken=750e4397f64dcd89 type=win32 version=1.0.0.1/
assemblyIdentity
file name=TestDll.dll hashalg=SHA1 hash=
7c8ed87e6403c4fa5eec429b4be4b9bd417b2ac3
asmv2:hash xmlns:asmv2=urn:schemas-microsoft-com:asm.v2 xmlns:dsig=
http://www.w3.org/2000/09/xmldsig#;
dsig:Transformsdsig:Transform Algorithm=
urn:schemas-microsoft-com:HashTransforms.Identity/dsig:Transform/
dsig:Transforms
dsig:DigestMethod Algorithm=http://www.w3.org/2000/09/xmldsig#sha1
/dsig:DigestMethod
dsig:DigestValuexrzo5LYc4y1QcGVGVbLPpWRKQLs=/dsig:DigestValue
/asmv2:hash
/file
/assembly
Manifest creation gave me this *.cdf:
[CatalogHeader]
Name=TestDLL.dll.cat
ResultDir=.\Debug
[CatalogFiles]
HASHTestDLL.dll.manifest=TestDLL.dll.manifest
TestDLL.dll.manifest=TestDLL.dll.manifest
Using makecat, I created a cat file from the *.cdf above, and I signed it
in the same way I signed the dll itself.
I have the following wix:
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Product Id=4C725A4B-7E5A-4502-B2E9-F72B25CC8D51 Name=TestProduct
Language=1033 Version=0.0.0.1 Manufacturer=WixEdit UpgradeCode=
A214B501-6CAB-4736-B43F-C46256D69440
Package Description=Test file in a Product Comments=Simple test
InstallerVersion=200 Compressed=yes /
Media Id=1 Cabinet=simple.cab EmbedCab=yes /
Directory Id=TARGETDIR Name=SourceDir
Component Id=TestDLL Guid=6DC0F277-B9BF-4115-8B3A-CEDB2323FD5D
File Id=TestDLL.dll Name=TestDLL.dll Source=
..\Debug\TestDLL.dll AssemblyManifest=TestDLL.dll.Manifest KeyPath=yes
Vital=yes Assembly=win32 /
File Id=TestDLL.dll.Manifest Name=TestDLL.dll.Manifest Source
=..\Debug\TestDLL.dll.manifest Vital=yes /
File Id=TestDLL.dll.cat Name=TestDLL.dll.cat Source=
..\Debug\TestDLL.dll.cat Vital=yes /
/Component
/Directory
Feature Id=DefaultFeature Title=Main Feature Level=1
ComponentRef Id=TestDLL /
/Feature
UI /
UIRef Id=WixUI_Minimal /
/Product
/Wix
I can build an *.msi from there, but when I try to install, I get an error
(captured by running the msi install from WixEdit):
MSI (s) (C4:60) [13:31:42:678]: Executing op:
SourceListRegisterLastUsed(SourceProduct=4C725A4B-7E5A-4502-B2E9-F72B25CC8D51,LastUsedSource=\Test\WiX\)
MSI (s) (C4:60) [13:31:42:678]: Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (s) (C4:60) [13:31:42:680]: Specifed source is already in a list.
MSI (s) (C4:60) [13:31:42:681]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (C4:60) [13:31:42:681]: Adding new sources is allowed.
MSI (s) (C4:60) [13:31:42:682]: Set LastUsedSource to:
...\Test\WiX\.
MSI (s) (C4:60) [13:31:42:684]: Set LastUsedType to: n.
MSI (s) (C4:60) [13:31:42:685]: Set LastUsedIndex to: 1.
MSI (s) (C4:60) [13:31:42:686]: Executing op:
End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=296896)
MSI (s) (C4:60) [13:31:42:743]: Assembly Error:An HRESULT could not be
translated to a corresponding Win32 error code.
MSI (s) (C4:60) [13:31:42:745]: Note: 1: 1935 2:
6DC0F277-B9BF-4115-8B3A-CEDB2323FD5D 3: 0x800736FD 4: IAssemblyCacheItem
5: Commit 6:
TestDLL,version=1.0.0.1,type=win32,processorArchitecture=x86,publicKeyToken=750e4397f64dcd89
MSI (s) (C4:60) [13:31:42:746]: Assembly Error (sxs): Please look into
Component Based Servicing Log located at -253369224ndir\logs\cbs\cbs.log
to get more diagnostic information.
MSI (s) (C4:60) [13:31:42:747]: Note: 1: 2205 2: 3: Error
MSI (s) (C4:60) [13:31:42:749]: Note: 1: 2228 2: 3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1935
When I look at CBS log, I see:
2012-10-15 13:41:34, Info CSI003b Performing 3
operations; 3 are not lock/unlock and follow:
Stage (1): flags: 8 app: [TestDLL, Version = 1.0.0.1, pA =
PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope neutral,
PublicKeyToken = {l:8 b:750e4397f64dcd89}, Type = [l:10{5}]win32,
TypeName neutral, PublicKey neutral]) comp: TestDLL, Version = 1.0.0.1, pA
= PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope neutral,
PublicKeyToken = {l:8 b:750e4397f64dcd89}, Type =
Re: [WiX-users] Patch issue
Hi Kajal Thank you for your email. Unfortunately the mst has already been released to our customers. We are now trying to release the msp patch and it is not patching the file. So we are trying to see how we can now fix the problem (so that the msp updates the file correctly) caused by the released mst. Thanks Uma- -Original Message- From: Kajal Kumar Biswas [mailto:kbis...@adobe.com] Sent: Sunday, October 14, 2012 10:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch issue When the mst is applied, the msi cache is not updated with the file version at the end of the installation and hence during patching the file is not updated. What you can do this try creating the mst correctly, such that it does not update the file version in the file table. Can you let me know how exactly you are trying to create the mst file? -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: Sunday, October 14, 2012 3:52 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Patch issue Hi I have a patching issue I need help with. Version 10.1 of my msi installs a dll with version 10.1.0. This is the also the version listed in the File table of the msi for this dll. This msi is the English setup. I have embedded msts in this msi that localizes the dialogs for this msi. There was a problem with this mst, so when this mst is applied over the setup msi, the version of this dll in the File table is removed. (The dll installed on the machine is OK, it is just the File table of the msi that has the version removed when you apply the mst). I now have an msp for this Version 10.1 that increments the dll to 10.1.1. I am finding that when the localized msi is installed (with the mst that removes the file version in the file table), and when the msp is applied over this, the dll is not patched. How can I fix the msp so that the file is successfully patched in this scenario? Thanks! Uma Harano -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Elevation of Bootstrapper Application
Hi. We are trying to keep some state alongside our bundle about which packages have been chosen for installation. The solution we envisioned was to put some registry entries within HKLM, but this fails on Windows 7 (and probably Vista) due to HKLM requiring admin privileges. We could work around this issue by writing to HKCU, but that would cause issues if another user ran the uninstallation (for instance) later. Is it possible to elevate the bootstrapper application in some way, so that we can write to HKLM? As a sideline question, does Burn store any information about what packages has been installed for later retrieval or persist any of the variables set during the installation on its own (if using a custom BA)? Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch issue
Use the version lying technique: Change the version of this FileId to 10.1.1 in your patch upgrade image by editing the msi in orca. Then re-build the patch pointing to your edited MSI. When the patch installs on top of the localised version it won't matter that the transform has removed this attribute in the actual local MSI being upgraded. Patching only looks at the file table version changes at the time the patch was created. I.E. the patch 'thinks': this FileId was version incremented when I was built so i'll happily apply the transform to it. (Make sure your actual file verison matches your edits otherwise you'll get request for source issues on repair). On 15/10/2012 13:03, Uma Harano wrote: Unfortunately the mst has already been released to our customers. We are now trying to release the msp patch and it is not patching the file. So we are trying to see how we can now fix the problem (so that the msp updates the file correctly) caused by the released mst. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Elevation of Bootstrapper Application
How are you setting the values? Burn automatically prompts to elevate if it detects an MSI that is set to all users but you can also set this with MsiPackage/@ForcePerMachine. Neil Hi. We are trying to keep some state alongside our bundle about which packages have been chosen for installation. The solution we envisioned was to put some registry entries within HKLM, but this fails on Windows 7 (and probably Vista) due to HKLM requiring admin privileges. We could work around this issue by writing to HKCU, but that would cause issues if another user ran the uninstallation (for instance) later. Is it possible to elevate the bootstrapper application in some way, so that we can write to HKLM? As a sideline question, does Burn store any information about what packages has been installed for later retrieval or persist any of the variables set during the installation on its own (if using a custom BA)? Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] VS2008 issue after update to v3.7
Don’t know why but after I ran this start /wait devenv.exe /setup /log %TEMP%vssetup.log devenv.exe /log %TEMP%vsrun.log to try and capture a log file I was able to open wixproj again in Visual studio but I cannot add my custom BA anymore :( It states it's not a valid wix extension but it has not changed since it was working before this issue. Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, October 13, 2012 11:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Does v3.6 work? If so, then this is a bug in v3.7. Definitely possible since the build system was radically improved in v3.7. If so, then please file a bug with as much information as possible. On Thu, Oct 11, 2012 at 12:06 PM, Steven Ogilvie steven.ogil...@titus.comwrote: Ya sorry my bad If you have tried uninstalling WIX 3.x and VS2008 then re installing VS2008 and then WIX 3.x Don't forget 3.7 is not a released product it is beta... STeve -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: October-11-12 2:56 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Doesn't one need VS2010 to support .NET 4 anyway? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du | Canada -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: October-11-12 2:54 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Hello, I don't have an option for 4 only 3.51, 3.0 and 2.0 Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Steven Ogilvie [mailto:steven.ogil...@titus.com] Sent: Thursday, October 11, 2012 2:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 In New Project dialog choose .NET Framework 4 instead of 3.51 See if that helps Steve -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: October-11-12 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Hello, In VS2008 I go to create a new Project and choose the Windows Installer XML types and if I try to create a new project from any of the templates I get that error. Images: http://www.files.pixelink.com/temp/error.bmp http://www.files.pixelink.com/temp/VS2008.bmp Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Steven Ogilvie [mailto:steven.ogil...@titus.com] Sent: Thursday, October 11, 2012 2:16 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Hey Michael, I presume you mean your product.wxs file? Create a new WIX setup project, does the first two lines look like your bundle file? I.e. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Steve Ogilvie -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: October-11-12 2:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 I have tried to repair my VS2008 pro and I have also tried repairing the v3.7 install. Still does not work. I have even uninstalled v3.7 and installed 3.6 again and it still does not work. V3.7 did something to my vs2008 Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: Thursday, October 11, 2012 1:50 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] VS2008 issue after
Re: [WiX-users] Patch issue
You could try making it a companion file in your patch. So, the installation state of a companion file depends not on its own file version, but on the version of its companion parent. Hence the mst removing the version no. will become ineffective. -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: Monday, October 15, 2012 5:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch issue Hi Kajal Thank you for your email. Unfortunately the mst has already been released to our customers. We are now trying to release the msp patch and it is not patching the file. So we are trying to see how we can now fix the problem (so that the msp updates the file correctly) caused by the released mst. Thanks Uma- -Original Message- From: Kajal Kumar Biswas [mailto:kbis...@adobe.com] Sent: Sunday, October 14, 2012 10:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch issue When the mst is applied, the msi cache is not updated with the file version at the end of the installation and hence during patching the file is not updated. What you can do this try creating the mst correctly, such that it does not update the file version in the file table. Can you let me know how exactly you are trying to create the mst file? -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: Sunday, October 14, 2012 3:52 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Patch issue Hi I have a patching issue I need help with. Version 10.1 of my msi installs a dll with version 10.1.0. This is the also the version listed in the File table of the msi for this dll. This msi is the English setup. I have embedded msts in this msi that localizes the dialogs for this msi. There was a problem with this mst, so when this mst is applied over the setup msi, the version of this dll in the File table is removed. (The dll installed on the machine is OK, it is just the File table of the msi that has the version removed when you apply the mst). I now have an msp for this Version 10.1 that increments the dll to 10.1.1. I am finding that when the localized msi is installed (with the mst that removes the file version in the file table), and when the msp is applied over this, the dll is not patched. How can I fix the msp so that the file is successfully patched in this scenario? Thanks! Uma Harano -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch issue
Thanks! I will try this. On Oct 15, 2012, at 5:46 AM, Kajal Kumar Biswas kbis...@adobe.com wrote: You could try making it a companion file in your patch. So, the installation state of a companion file depends not on its own file version, but on the version of its companion parent. Hence the mst removing the version no. will become ineffective. -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: Monday, October 15, 2012 5:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch issue Hi Kajal Thank you for your email. Unfortunately the mst has already been released to our customers. We are now trying to release the msp patch and it is not patching the file. So we are trying to see how we can now fix the problem (so that the msp updates the file correctly) caused by the released mst. Thanks Uma- -Original Message- From: Kajal Kumar Biswas [mailto:kbis...@adobe.com] Sent: Sunday, October 14, 2012 10:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch issue When the mst is applied, the msi cache is not updated with the file version at the end of the installation and hence during patching the file is not updated. What you can do this try creating the mst correctly, such that it does not update the file version in the file table. Can you let me know how exactly you are trying to create the mst file? -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: Sunday, October 14, 2012 3:52 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Patch issue Hi I have a patching issue I need help with. Version 10.1 of my msi installs a dll with version 10.1.0. This is the also the version listed in the File table of the msi for this dll. This msi is the English setup. I have embedded msts in this msi that localizes the dialogs for this msi. There was a problem with this mst, so when this mst is applied over the setup msi, the version of this dll in the File table is removed. (The dll installed on the machine is OK, it is just the File table of the msi that has the version removed when you apply the mst). I now have an msp for this Version 10.1 that increments the dll to 10.1.1. I am finding that when the localized msi is installed (with the mst that removes the file version in the file table), and when the msp is applied over this, the dll is not patched. How can I fix the msp so that the file is successfully patched in this scenario? Thanks! Uma Harano -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your
Re: [WiX-users] Patch issue
Hi Matt The edited msi that the msp targets does the correct 10.1.1 version. But the msp is still not patching it. I will try the companion file idea that Kajal explained. Thanks! On Oct 15, 2012, at 5:32 AM, Matt O'Connell techsupport...@gmail.com wrote: Use the version lying technique: Change the version of this FileId to 10.1.1 in your patch upgrade image by editing the msi in orca. Then re-build the patch pointing to your edited MSI. When the patch installs on top of the localised version it won't matter that the transform has removed this attribute in the actual local MSI being upgraded. Patching only looks at the file table version changes at the time the patch was created. I.E. the patch 'thinks': this FileId was version incremented when I was built so i'll happily apply the transform to it. (Make sure your actual file verison matches your edits otherwise you'll get request for source issues on repair). On 15/10/2012 13:03, Uma Harano wrote: Unfortunately the mst has already been released to our customers. We are now trying to release the msp patch and it is not patching the file. So we are trying to see how we can now fix the problem (so that the msp updates the file correctly) caused by the released mst. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Elevation of Bootstrapper Application
The values are set by our custom Managed Bootstrapper Application via the standard .NET Registry API, and not by any of the included packages. Since the information to be stored is on the bundle-level (which packages are selected for installation), it can't be moved into an MSI. I have attempted using IBurnEngine-Elevate(), but as far as I can see (and as I expect from it being a method of the engine), that does not give the managed bootstrapper application process elevated privileges. Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: 15. oktober 2012 14:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Elevation of Bootstrapper Application How are you setting the values? Burn automatically prompts to elevate if it detects an MSI that is set to all users but you can also set this with MsiPackage/@ForcePerMachine. Neil Hi. We are trying to keep some state alongside our bundle about which packages have been chosen for installation. The solution we envisioned was to put some registry entries within HKLM, but this fails on Windows 7 (and probably Vista) due to HKLM requiring admin privileges. We could work around this issue by writing to HKCU, but that would cause issues if another user ran the uninstallation (for instance) later. Is it possible to elevate the bootstrapper application in some way, so that we can write to HKLM? As a sideline question, does Burn store any information about what packages has been installed for later retrieval or persist any of the variables set during the installation on its own (if using a custom BA)? Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway --- --- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ___ ___ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ___ ___ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Elevation of Bootstrapper Application
I looked at doing something similar and decided it was easier to write the values in an MSI. My logic was that I didn't want to write until the install had actually started and by that time the installer was already running elevated. I am not familiar with the managed BA to know if you can write your values after the install has started. Neil The values are set by our custom Managed Bootstrapper Application via the standard .NET Registry API, and not by any of the included packages. Since the information to be stored is on the bundle-level (which packages are selected for installation), it can't be moved into an MSI. I have attempted using IBurnEngine-Elevate(), but as far as I can see (and as I expect from it being a method of the engine), that does not give the managed bootstrapper application process elevated privileges. Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: 15. oktober 2012 14:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Elevation of Bootstrapper Application How are you setting the values? Burn automatically prompts to elevate if it detects an MSI that is set to all users but you can also set this with MsiPackage/@ForcePerMachine. Neil Hi. We are trying to keep some state alongside our bundle about which packages have been chosen for installation. The solution we envisioned was to put some registry entries within HKLM, but this fails on Windows 7 (and probably Vista) due to HKLM requiring admin privileges. We could work around this issue by writing to HKCU, but that would cause issues if another user ran the uninstallation (for instance) later. Is it possible to elevate the bootstrapper application in some way, so that we can write to HKLM? As a sideline question, does Burn store any information about what packages has been installed for later retrieval or persist any of the variables set during the installation on its own (if using a custom BA)? Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway --- --- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ___ ___ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ___ ___ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Broken links on WiX web site
Ah - sorry I didn't realize the Sourceforge bug database covered the web site, too. Ticket filed. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Sunday, October 14, 2012 03:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Broken links on WiX web site We do, can you please file a bug? On Fri, Oct 12, 2012 at 9:15 AM, James Johnston johnstonj@inn- soft.comwrote: Hi, The page at: http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm contains some broken links. Specifically, WixUI_Mondo and WixUI_Minimal are broken (404 Not Found). Not sure who maintains the web site so I'm writing to this list... -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn ARP reports wrong size
This is true up until you patch the bundle. I know externally applying the MSP causes the size to be incorrect. I would have to test it again to see if putting a bundle with a MSP on top of a bundle also caused the issue. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, October 13, 2012 10:23 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn ARP reports wrong size Burn currently shows the size of your chain (including the cached packages). On Fri, Oct 12, 2012 at 2:52 AM, rowbot jamesnrow...@yahoo.co.uk wrote: I have the same issue... anyone any ideas? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-ARP -reports-wrong-size-tp6964175p7581303.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn ARP reports wrong size
What do you mean patch the bundle? Burn uses the sizes of the packages contained inside it to calculate the sizes in ARP. On Mon, Oct 15, 2012 at 7:16 AM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: This is true up until you patch the bundle. I know externally applying the MSP causes the size to be incorrect. I would have to test it again to see if putting a bundle with a MSP on top of a bundle also caused the issue. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, October 13, 2012 10:23 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn ARP reports wrong size Burn currently shows the size of your chain (including the cached packages). On Fri, Oct 12, 2012 at 2:52 AM, rowbot jamesnrow...@yahoo.co.uk wrote: I have the same issue... anyone any ideas? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-ARP -reports-wrong-size-tp6964175p7581303.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.6 MergeModule creation regression?
Awesome, can you create a bug with that information in it? We tend to lose
issues only reported via email.
On Sun, Oct 14, 2012 at 11:09 PM, Dirk Ziegelmeier d...@ziegelmeier.netwrote:
Hello Rob,
here is a minimal mergemodule showing the error:
?xml version=1.0 encoding=UTF-8 ?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Module Id=MergeModule Language=1033 Version=1.0.0.0
Package Id={SomeGUID} Manufacturer=ACME InstallerVersion=200
/
Directory Id=TARGETDIR Name=SourceDir
Directory Id=CommonFilesFolder /
/Directory
DirectoryRef Id=CommonFilesFolder
Directory Id=ComStaHelper Name=ACME
Directory Id=ComStaHelperComSta Name=ComStaHelper
Component Id=cComSTAHelper SharedDllRefCount=yes
File Id=ComSTAHelper Name=ComSTAHelper.dll
Source=ComSTAHelper.dll KeyPath=yes Checksum=yes /
/Component
/Directory
/Directory
/DirectoryRef
/Module
/Wix
W:\tmp\CommonFiles.wxs(14) : error LGHT0231 : The component
'cComSTAHelper.63744358_CA08_4563_B039_4BE7181B668E' has a key file with
path 'TARGETDIR\acme\comsta
helper\comstahelper.dll'. Since this path is not rooted in one of the
standard directories (like ProgramFilesFolder), this component does not fit
the criteria
for having an automatically generated guid. (This error may also occur if
a path contains a likely standard directory such as nesting a directory
with name Co
mmon Files under ProgramFilesFolder.)
Kind regards
Dirk
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
virtually,
Rob Mensching
http://RobMensching.com LLC
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Elevation of Bootstrapper Application
Neil is correct. The BA is not elevated because it does not rollback but the package installs do. If you just want to store settings for your BA, you can set Variables and mark them Persist='yes' and Burn will remember them for you. That sounds like it might be more applicable for you anyway. On Mon, Oct 15, 2012 at 6:45 AM, Neil Sleightholm n...@x2systems.comwrote: I looked at doing something similar and decided it was easier to write the values in an MSI. My logic was that I didn't want to write until the install had actually started and by that time the installer was already running elevated. I am not familiar with the managed BA to know if you can write your values after the install has started. Neil The values are set by our custom Managed Bootstrapper Application via the standard .NET Registry API, and not by any of the included packages. Since the information to be stored is on the bundle-level (which packages are selected for installation), it can't be moved into an MSI. I have attempted using IBurnEngine-Elevate(), but as far as I can see (and as I expect from it being a method of the engine), that does not give the managed bootstrapper application process elevated privileges. Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: 15. oktober 2012 14:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Elevation of Bootstrapper Application How are you setting the values? Burn automatically prompts to elevate if it detects an MSI that is set to all users but you can also set this with MsiPackage/@ForcePerMachine. Neil Hi. We are trying to keep some state alongside our bundle about which packages have been chosen for installation. The solution we envisioned was to put some registry entries within HKLM, but this fails on Windows 7 (and probably Vista) due to HKLM requiring admin privileges. We could work around this issue by writing to HKCU, but that would cause issues if another user ran the uninstallation (for instance) later. Is it possible to elevate the bootstrapper application in some way, so that we can write to HKLM? As a sideline question, does Burn store any information about what packages has been installed for later retrieval or persist any of the variables set during the installation on its own (if using a custom BA)? Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway --- --- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ___ ___ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ___ ___ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today
Re: [WiX-users] Possible performance issues
The Burn log file has timestamps for just about every action. Can you share the log file? On Mon, Oct 15, 2012 at 7:00 AM, Jansson mattias.jans...@lyen.se wrote: Hi all, We are developing a burn bootstrapper application and have encountered performance issues on some machines. On those machines, the setup takes about seven seconds before the UI is even requested, but it should be noted that the worst scenarios were produced after a reboot. We have tried to pinpoint what the reason is. Also a greatly simplified package (containing a 2.5 mb msi with only Run() with detect() and plan() followed by a messagebox that when pressed triggers apply()) suffers from these problems. Has anyone suffered from similar problems? Has anyone any clue on which parameters that can affect performance or what tools that can be useful for our troubleshooting (so far, we have used logging, process monitor, testing on different computers and removal of dependencies)? Best Regards, Mattias -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-performance-issues-tp7581346.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Elevation of Bootstrapper Application
you can set Variables and mark them Persist='yes' and Burn will remember them for you. Am I correct that it remembers them for Uninstall/Repair but there is no way to recall them if you do an upgrade? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 15 October 2012 17:50 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Elevation of Bootstrapper Application Neil is correct. The BA is not elevated because it does not rollback but the package installs do. If you just want to store settings for your BA, you can set Variables and mark them Persist='yes' and Burn will remember them for you. That sounds like it might be more applicable for you anyway. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] VS2008 issue after update to v3.7
Sounds like the registration didn't finish correctly for VS2008. I'll try to put together a repro machine and see if it is a one off or if WiX's setup is missing something. For the second issue, are you trying to add a Reference to your Custom BA from a .wixproj? If so, it is possible that the reference is added as an Extension reference and is trying to load your Custom BA as a toolset extension, which it is not, of course. Take a look at your failing project and see if the references look fishy. On Mon, Oct 15, 2012 at 5:32 AM, Michael Ogilvie michael.ogil...@pixelink.com wrote: Don’t know why but after I ran this start /wait devenv.exe /setup /log %TEMP%vssetup.log devenv.exe /log %TEMP%vsrun.log to try and capture a log file I was able to open wixproj again in Visual studio but I cannot add my custom BA anymore :( It states it's not a valid wix extension but it has not changed since it was working before this issue. Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, October 13, 2012 11:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Does v3.6 work? If so, then this is a bug in v3.7. Definitely possible since the build system was radically improved in v3.7. If so, then please file a bug with as much information as possible. On Thu, Oct 11, 2012 at 12:06 PM, Steven Ogilvie steven.ogil...@titus.comwrote: Ya sorry my bad If you have tried uninstalling WIX 3.x and VS2008 then re installing VS2008 and then WIX 3.x Don't forget 3.7 is not a released product it is beta... STeve -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: October-11-12 2:56 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Doesn't one need VS2010 to support .NET 4 anyway? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du | Canada -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: October-11-12 2:54 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Hello, I don't have an option for 4 only 3.51, 3.0 and 2.0 Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Steven Ogilvie [mailto:steven.ogil...@titus.com] Sent: Thursday, October 11, 2012 2:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 In New Project dialog choose .NET Framework 4 instead of 3.51 See if that helps Steve -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: October-11-12 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Hello, In VS2008 I go to create a new Project and choose the Windows Installer XML types and if I try to create a new project from any of the templates I get that error. Images: http://www.files.pixelink.com/temp/error.bmp http://www.files.pixelink.com/temp/VS2008.bmp Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Steven Ogilvie [mailto:steven.ogil...@titus.com] Sent: Thursday, October 11, 2012 2:16 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Hey Michael, I presume you mean your product.wxs file? Create a new WIX setup project, does the first two lines look like your bundle file? I.e. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Steve Ogilvie -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: October-11-12 2:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue
Re: [WiX-users] Elevation of Bootstrapper Application
It remembers them for a specific Bundle. There is not currently a mechanism to get to the state of another Bundle (I think there is a feature request open to enable that). On Mon, Oct 15, 2012 at 10:10 AM, Neil Sleightholm n...@x2systems.comwrote: you can set Variables and mark them Persist='yes' and Burn will remember them for you. Am I correct that it remembers them for Uninstall/Repair but there is no way to recall them if you do an upgrade? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 15 October 2012 17:50 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Elevation of Bootstrapper Application Neil is correct. The BA is not elevated because it does not rollback but the package installs do. If you just want to store settings for your BA, you can set Variables and mark them Persist='yes' and Burn will remember them for you. That sounds like it might be more applicable for you anyway. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn ARP reports wrong size
If one either applies a bundle and then in an external process releases a MSP to patch the component. I thought I saw this happen on XP if I installed the RTM bundle, and then released an updated bundle with the original content and a MSP. Applying a MSP without the bundle I can see causing some issues, but applying the bundle one would think should work. When I went to try this, it seems that Windows XP is just wrong. Installing the base bundle reports a grossly undersized install (4.8 MB) instead of the ~884MB that would be expected. Windows 7 reports the correct values on initial install, but I don't have time to try the RTM install + Patch. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 11:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn ARP reports wrong size What do you mean patch the bundle? Burn uses the sizes of the packages contained inside it to calculate the sizes in ARP. On Mon, Oct 15, 2012 at 7:16 AM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: This is true up until you patch the bundle. I know externally applying the MSP causes the size to be incorrect. I would have to test it again to see if putting a bundle with a MSP on top of a bundle also caused the issue. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, October 13, 2012 10:23 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn ARP reports wrong size Burn currently shows the size of your chain (including the cached packages). On Fri, Oct 12, 2012 at 2:52 AM, rowbot jamesnrow...@yahoo.co.uk wrote: I have the same issue... anyone any ideas? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-A RP -reports-wrong-size-tp6964175p7581303.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixManagedBootstrapperApplicationHost and .NET 2.0
What does your BootstrapperCore.config file look like? Does it correctly indicate the v2 NETFX should be used? On Mon, Oct 15, 2012 at 2:18 AM, Igor Brejc igor.br...@gmail.com wrote: Hi, I have a simple problem: I've written a managed bootstrapper (WiX v3.6) written in .NET 2.0. On my developer machine (I have .NET 2.0 up to 4.0 installed), everything works fine - my bootstrapper runs and installs. Now I'm testing in on an Win XP (with only .NET 2.0 installed), I always get the Microsoft .NET Framework Required... screen. I've tried different things, like: - Using RegistrySearch to find the .NET 2.0 key and then using this as a condition in ExePackage. The key is there in the registry. - Using standard properties like NETFRAMEWORK20 as conditions. - Playing with .exe.config file, setting thinks like supportedRuntime, supportedFramework, runtimeVersion etc. I've been really struggling with this, read through all of the docs, googled for it, tried a million things, and none of them seem to work - .NET 2.0 doesn't seem to get detected. All the samples I found on the web use .NET 3.5 or 4.0 as an example and I cannot get it work with 2.0. So my questions are: 1. What is the right procedure for setting .NET 2.0 as a minimum requirement? The minimum bare essentials in the .WXS, .config etc? 2. Alternatively: is there a way to turn off the whole .NET detection thing in the bootstrapper? Any help would be _greatly_ appreciated! Thanks, Igor Brejc -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] VS2008 issue after update to v3.7
Hello, Thanks Rob, does the wix reference need to be in the Wix toolset directory? I tried adding it there and I was able to reference it. Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:13 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Sounds like the registration didn't finish correctly for VS2008. I'll try to put together a repro machine and see if it is a one off or if WiX's setup is missing something. For the second issue, are you trying to add a Reference to your Custom BA from a .wixproj? If so, it is possible that the reference is added as an Extension reference and is trying to load your Custom BA as a toolset extension, which it is not, of course. Take a look at your failing project and see if the references look fishy. On Mon, Oct 15, 2012 at 5:32 AM, Michael Ogilvie michael.ogil...@pixelink.com wrote: Don’t know why but after I ran this start /wait devenv.exe /setup /log %TEMP%vssetup.log devenv.exe /log %TEMP%vsrun.log to try and capture a log file I was able to open wixproj again in Visual studio but I cannot add my custom BA anymore :( It states it's not a valid wix extension but it has not changed since it was working before this issue. Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, October 13, 2012 11:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Does v3.6 work? If so, then this is a bug in v3.7. Definitely possible since the build system was radically improved in v3.7. If so, then please file a bug with as much information as possible. On Thu, Oct 11, 2012 at 12:06 PM, Steven Ogilvie steven.ogil...@titus.comwrote: Ya sorry my bad If you have tried uninstalling WIX 3.x and VS2008 then re installing VS2008 and then WIX 3.x Don't forget 3.7 is not a released product it is beta... STeve -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: October-11-12 2:56 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Doesn't one need VS2010 to support .NET 4 anyway? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du | Canada -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: October-11-12 2:54 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Hello, I don't have an option for 4 only 3.51, 3.0 and 2.0 Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Steven Ogilvie [mailto:steven.ogil...@titus.com] Sent: Thursday, October 11, 2012 2:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 In New Project dialog choose .NET Framework 4 instead of 3.51 See if that helps Steve -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: October-11-12 2:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Hello, In VS2008 I go to create a new Project and choose the Windows Installer XML types and if I try to create a new project from any of the templates I get that error. Images: http://www.files.pixelink.com/temp/error.bmp http://www.files.pixelink.com/temp/VS2008.bmp Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Steven Ogilvie [mailto:steven.ogil...@titus.com] Sent:
Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode
Having the update URL come from outside the Bundle would be a very large security gap. Essentially, any Bundle could be used to launch any other random Bundle. That's not right. There is certainly work that could be done in the wixstdba to support bundle self-update but I don't think passing the update URL via the command-line is the right way to do that. smile/ On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning wmann...@dynagen.ca wrote: Sorry, for (1) I meant I don't want to do it from a custom BA. I want to do it by calling the bundle from the application software that my bundle installs. I know for wixstba you provide /uninstall and /repair commands. I use wixstba for my bundle so it would be nice if there was an /upgrade command line option in wixstba where I pass the URL of the update and the bundle downloads and installs it. Is this something that you guys can do for version 3.7? Thanks for the info on UninstallKey in the registry. I actually forgot about that. I see it has a BundleCachePath value so I can use that to call my bundle. All I need is for the wixstba to have a command line argument to do an upgrade. Questions 2 and 3 are moot now. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: October 14, 2012 12:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode 1. I don't quite understand the question. The bundle self-update feature allows a BA to check the internet and tell the engine that there is a newer version of itself and to download then launch that instead. It is not clear to me what the command-line has to do with it. 2. Bundles are registered in ARP (aka: Program and Features, aka: the UninstallKey). That's how you can click on the Uninstall button in ARP and Burn launches to remove the bundle. You can search for it that way if you want. 3. Again, the self-update happens inside a Burn bundle. It isn't driven from a command-line argument. I may just be confused by not understanding your first question. You always have the Bundle. It's cached. That's how ARP works. On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning wmann...@dynagen.ca wrote: Hi, have some questions about wixstba: (1) Wix 3.7 bundle self update feature: Is it possible (or any plans to make it possible) to run from the command line? You would need to run the bundle exe (thus have to know where its located). There is already -uninstall, -repair, etc. (2) Since Windows installer is part of the operating system it is possible to install/uninstall/repair by running msiexec /x ProductCode. You don't need to have the MSi file or know where it is on the computer. Is there something similar for bundles? This question is really about burn in general. (3) Similar to (2) above but for the wix 3.7 self update feature: give an upgrade code and URL and have it download and upgrade the bundle. Is this possible? I was hoping to have our software update itself / show its own install progress UI so the user doesn't have to use the bundle for that (they may not have the bundle anymore). The bundle would only be used to install our software on a clean computer or if user goes to ARP they can interact with the bundle. I see in Wix37\src\burn\Samples there is an example on how to get progress from burn. I could write code to download the burn exe myself but burn can already download updates so... Wes -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: October-12-12 1:15 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Broken links on WiX web site Hi, The page at: http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm contains some broken links. Specifically, WixUI_Mondo and WixUI_Minimal are broken (404 Not Found). Not sure who maintains the web site so I'm writing to this list... Best regards, James Johnston -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data
Re: [WiX-users] Some in burn wixstba similar to msiexec /xProductCode
Does v3.6 have the bundle self-update feature or only v3.7? Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /xProductCode Having the update URL come from outside the Bundle would be a very large security gap. Essentially, any Bundle could be used to launch any other random Bundle. That's not right. There is certainly work that could be done in the wixstdba to support bundle self-update but I don't think passing the update URL via the command-line is the right way to do that. smile/ On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning wmann...@dynagen.ca wrote: Sorry, for (1) I meant I don't want to do it from a custom BA. I want to do it by calling the bundle from the application software that my bundle installs. I know for wixstba you provide /uninstall and /repair commands. I use wixstba for my bundle so it would be nice if there was an /upgrade command line option in wixstba where I pass the URL of the update and the bundle downloads and installs it. Is this something that you guys can do for version 3.7? Thanks for the info on UninstallKey in the registry. I actually forgot about that. I see it has a BundleCachePath value so I can use that to call my bundle. All I need is for the wixstba to have a command line argument to do an upgrade. Questions 2 and 3 are moot now. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: October 14, 2012 12:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode 1. I don't quite understand the question. The bundle self-update feature allows a BA to check the internet and tell the engine that there is a newer version of itself and to download then launch that instead. It is not clear to me what the command-line has to do with it. 2. Bundles are registered in ARP (aka: Program and Features, aka: the UninstallKey). That's how you can click on the Uninstall button in ARP and Burn launches to remove the bundle. You can search for it that way if you want. 3. Again, the self-update happens inside a Burn bundle. It isn't driven from a command-line argument. I may just be confused by not understanding your first question. You always have the Bundle. It's cached. That's how ARP works. On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning wmann...@dynagen.ca wrote: Hi, have some questions about wixstba: (1) Wix 3.7 bundle self update feature: Is it possible (or any plans to make it possible) to run from the command line? You would need to run the bundle exe (thus have to know where its located). There is already -uninstall, -repair, etc. (2) Since Windows installer is part of the operating system it is possible to install/uninstall/repair by running msiexec /x ProductCode. You don't need to have the MSi file or know where it is on the computer. Is there something similar for bundles? This question is really about burn in general. (3) Similar to (2) above but for the wix 3.7 self update feature: give an upgrade code and URL and have it download and upgrade the bundle. Is this possible? I was hoping to have our software update itself / show its own install progress UI so the user doesn't have to use the bundle for that (they may not have the bundle anymore). The bundle would only be used to install our software on a clean computer or if user goes to ARP they can interact with the bundle. I see in Wix37\src\burn\Samples there is an example on how to get progress from burn. I could write code to download the burn exe myself but burn can already download updates so... Wes -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: October-12-12 1:15 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Broken links on WiX web site Hi, The page at: http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm contains some broken links. Specifically, WixUI_Mondo and WixUI_Minimal are broken (404 Not Found). Not sure who maintains the web site so I'm writing to this list... Best regards, James Johnston -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost
Re: [WiX-users] Some in burn wixstba similar to msiexec /xProductCode
New feature in v3.7: http://robmensching.com/blog/posts/2012/8/21/Enter-WiX-v3.7-toolset On Mon, Oct 15, 2012 at 10:29 AM, Michael Ogilvie michael.ogil...@pixelink.com wrote: Does v3.6 have the bundle self-update feature or only v3.7? Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /xProductCode Having the update URL come from outside the Bundle would be a very large security gap. Essentially, any Bundle could be used to launch any other random Bundle. That's not right. There is certainly work that could be done in the wixstdba to support bundle self-update but I don't think passing the update URL via the command-line is the right way to do that. smile/ On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning wmann...@dynagen.ca wrote: Sorry, for (1) I meant I don't want to do it from a custom BA. I want to do it by calling the bundle from the application software that my bundle installs. I know for wixstba you provide /uninstall and /repair commands. I use wixstba for my bundle so it would be nice if there was an /upgrade command line option in wixstba where I pass the URL of the update and the bundle downloads and installs it. Is this something that you guys can do for version 3.7? Thanks for the info on UninstallKey in the registry. I actually forgot about that. I see it has a BundleCachePath value so I can use that to call my bundle. All I need is for the wixstba to have a command line argument to do an upgrade. Questions 2 and 3 are moot now. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: October 14, 2012 12:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode 1. I don't quite understand the question. The bundle self-update feature allows a BA to check the internet and tell the engine that there is a newer version of itself and to download then launch that instead. It is not clear to me what the command-line has to do with it. 2. Bundles are registered in ARP (aka: Program and Features, aka: the UninstallKey). That's how you can click on the Uninstall button in ARP and Burn launches to remove the bundle. You can search for it that way if you want. 3. Again, the self-update happens inside a Burn bundle. It isn't driven from a command-line argument. I may just be confused by not understanding your first question. You always have the Bundle. It's cached. That's how ARP works. On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning wmann...@dynagen.ca wrote: Hi, have some questions about wixstba: (1) Wix 3.7 bundle self update feature: Is it possible (or any plans to make it possible) to run from the command line? You would need to run the bundle exe (thus have to know where its located). There is already -uninstall, -repair, etc. (2) Since Windows installer is part of the operating system it is possible to install/uninstall/repair by running msiexec /x ProductCode. You don't need to have the MSi file or know where it is on the computer. Is there something similar for bundles? This question is really about burn in general. (3) Similar to (2) above but for the wix 3.7 self update feature: give an upgrade code and URL and have it download and upgrade the bundle. Is this possible? I was hoping to have our software update itself / show its own install progress UI so the user doesn't have to use the bundle for that (they may not have the bundle anymore). The bundle would only be used to install our software on a clean computer or if user goes to ARP they can interact with the bundle. I see in Wix37\src\burn\Samples there is an example on how to get progress from burn. I could write code to download the burn exe myself but burn can already download updates so... Wes -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: October-12-12 1:15 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Broken links on WiX web site Hi, The page at: http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm contains some broken links. Specifically, WixUI_Mondo and WixUI_Minimal are broken (404 Not Found). Not sure who maintains the web site so I'm writing to this list... Best regards, James Johnston
Re: [WiX-users] Some in burn wixstba similar to msiexec/xProductCode
Thanks, I will try updating again and hopefully I don't have more issues Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec/xProductCode New feature in v3.7: http://robmensching.com/blog/posts/2012/8/21/Enter-WiX-v3.7-toolset On Mon, Oct 15, 2012 at 10:29 AM, Michael Ogilvie michael.ogil...@pixelink.com wrote: Does v3.6 have the bundle self-update feature or only v3.7? Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /xProductCode Having the update URL come from outside the Bundle would be a very large security gap. Essentially, any Bundle could be used to launch any other random Bundle. That's not right. There is certainly work that could be done in the wixstdba to support bundle self-update but I don't think passing the update URL via the command-line is the right way to do that. smile/ On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning wmann...@dynagen.ca wrote: Sorry, for (1) I meant I don't want to do it from a custom BA. I want to do it by calling the bundle from the application software that my bundle installs. I know for wixstba you provide /uninstall and /repair commands. I use wixstba for my bundle so it would be nice if there was an /upgrade command line option in wixstba where I pass the URL of the update and the bundle downloads and installs it. Is this something that you guys can do for version 3.7? Thanks for the info on UninstallKey in the registry. I actually forgot about that. I see it has a BundleCachePath value so I can use that to call my bundle. All I need is for the wixstba to have a command line argument to do an upgrade. Questions 2 and 3 are moot now. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: October 14, 2012 12:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode 1. I don't quite understand the question. The bundle self-update feature allows a BA to check the internet and tell the engine that there is a newer version of itself and to download then launch that instead. It is not clear to me what the command-line has to do with it. 2. Bundles are registered in ARP (aka: Program and Features, aka: the UninstallKey). That's how you can click on the Uninstall button in ARP and Burn launches to remove the bundle. You can search for it that way if you want. 3. Again, the self-update happens inside a Burn bundle. It isn't driven from a command-line argument. I may just be confused by not understanding your first question. You always have the Bundle. It's cached. That's how ARP works. On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning wmann...@dynagen.ca wrote: Hi, have some questions about wixstba: (1) Wix 3.7 bundle self update feature: Is it possible (or any plans to make it possible) to run from the command line? You would need to run the bundle exe (thus have to know where its located). There is already -uninstall, -repair, etc. (2) Since Windows installer is part of the operating system it is possible to install/uninstall/repair by running msiexec /x ProductCode. You don't need to have the MSi file or know where it is on the computer. Is there something similar for bundles? This question is really about burn in general. (3) Similar to (2) above but for the wix 3.7 self update feature: give an upgrade code and URL and have it download and upgrade the bundle. Is this possible? I was hoping to have our software update itself / show its own install progress UI so the user doesn't have to use the bundle for that (they may not have the bundle anymore). The bundle would only be used to install our software on a clean computer or if user goes to ARP they can interact with the bundle. I see in Wix37\src\burn\Samples there is an example on how to get progress from burn. I could write code to download the burn exe myself but burn can already download updates
Re: [WiX-users] Some in burn wixstba similar to msiexec/xProductCode
3.7 is in a development/potentially unstable state, so I wouldn't upgrade to 3.7 for a production deployment as of yet. -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: Monday, October 15, 2012 12:45 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec/xProductCode Thanks, I will try updating again and hopefully I don't have more issues Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec/xProductCode New feature in v3.7: http://robmensching.com/blog/posts/2012/8/21/Enter-WiX-v3.7-toolset On Mon, Oct 15, 2012 at 10:29 AM, Michael Ogilvie michael.ogil...@pixelink.com wrote: Does v3.6 have the bundle self-update feature or only v3.7? Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /xProductCode Having the update URL come from outside the Bundle would be a very large security gap. Essentially, any Bundle could be used to launch any other random Bundle. That's not right. There is certainly work that could be done in the wixstdba to support bundle self-update but I don't think passing the update URL via the command-line is the right way to do that. smile/ On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning wmann...@dynagen.ca wrote: Sorry, for (1) I meant I don't want to do it from a custom BA. I want to do it by calling the bundle from the application software that my bundle installs. I know for wixstba you provide /uninstall and /repair commands. I use wixstba for my bundle so it would be nice if there was an /upgrade command line option in wixstba where I pass the URL of the update and the bundle downloads and installs it. Is this something that you guys can do for version 3.7? Thanks for the info on UninstallKey in the registry. I actually forgot about that. I see it has a BundleCachePath value so I can use that to call my bundle. All I need is for the wixstba to have a command line argument to do an upgrade. Questions 2 and 3 are moot now. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: October 14, 2012 12:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode 1. I don't quite understand the question. The bundle self-update feature allows a BA to check the internet and tell the engine that there is a newer version of itself and to download then launch that instead. It is not clear to me what the command-line has to do with it. 2. Bundles are registered in ARP (aka: Program and Features, aka: the UninstallKey). That's how you can click on the Uninstall button in ARP and Burn launches to remove the bundle. You can search for it that way if you want. 3. Again, the self-update happens inside a Burn bundle. It isn't driven from a command-line argument. I may just be confused by not understanding your first question. You always have the Bundle. It's cached. That's how ARP works. On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning wmann...@dynagen.ca wrote: Hi, have some questions about wixstba: (1) Wix 3.7 bundle self update feature: Is it possible (or any plans to make it possible) to run from the command line? You would need to run the bundle exe (thus have to know where its located). There is already -uninstall, -repair, etc. (2) Since Windows installer is part of the operating system it is possible to install/uninstall/repair by running msiexec /x ProductCode. You don't need to have the MSi file or know where it is on the computer. Is there something similar for bundles? This question is really about burn in general. (3) Similar to (2) above but for the wix 3.7 self update feature: give an upgrade code and URL and have it download and upgrade the bundle. Is this possible? I was hoping to have our software update itself / show its own install progress UI so the user doesn't have to use the bundle for
Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode
Very True. I was thinking that there would not be a security issue if you check the UpgradeCode on the downloaded bundle before installing but anybody could make a bundle with my upgrade code. :) Maybe you could support it only in cases were the bundle is signed? You could check that the signature from both bundles come from the same company once downloaded. Is this reasonable? And/or add a URL attribute for wixstba in the wix project that gets compiled and that only allow checks for updates from this URL or based off this URL??? Anyways I was trying to take the easy route but looks like going to have to implement my own BA. :) Thanks. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: October-15-12 2:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode Having the update URL come from outside the Bundle would be a very large security gap. Essentially, any Bundle could be used to launch any other random Bundle. That's not right. There is certainly work that could be done in the wixstdba to support bundle self-update but I don't think passing the update URL via the command-line is the right way to do that. smile/ On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning wmann...@dynagen.ca wrote: Sorry, for (1) I meant I don't want to do it from a custom BA. I want to do it by calling the bundle from the application software that my bundle installs. I know for wixstba you provide /uninstall and /repair commands. I use wixstba for my bundle so it would be nice if there was an /upgrade command line option in wixstba where I pass the URL of the update and the bundle downloads and installs it. Is this something that you guys can do for version 3.7? Thanks for the info on UninstallKey in the registry. I actually forgot about that. I see it has a BundleCachePath value so I can use that to call my bundle. All I need is for the wixstba to have a command line argument to do an upgrade. Questions 2 and 3 are moot now. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: October 14, 2012 12:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode 1. I don't quite understand the question. The bundle self-update feature allows a BA to check the internet and tell the engine that there is a newer version of itself and to download then launch that instead. It is not clear to me what the command-line has to do with it. 2. Bundles are registered in ARP (aka: Program and Features, aka: the UninstallKey). That's how you can click on the Uninstall button in ARP and Burn launches to remove the bundle. You can search for it that way if you want. 3. Again, the self-update happens inside a Burn bundle. It isn't driven from a command-line argument. I may just be confused by not understanding your first question. You always have the Bundle. It's cached. That's how ARP works. On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning wmann...@dynagen.ca wrote: Hi, have some questions about wixstba: (1) Wix 3.7 bundle self update feature: Is it possible (or any plans to make it possible) to run from the command line? You would need to run the bundle exe (thus have to know where its located). There is already -uninstall, -repair, etc. (2) Since Windows installer is part of the operating system it is possible to install/uninstall/repair by running msiexec /x ProductCode. You don't need to have the MSi file or know where it is on the computer. Is there something similar for bundles? This question is really about burn in general. (3) Similar to (2) above but for the wix 3.7 self update feature: give an upgrade code and URL and have it download and upgrade the bundle. Is this possible? I was hoping to have our software update itself / show its own install progress UI so the user doesn't have to use the bundle for that (they may not have the bundle anymore). The bundle would only be used to install our software on a clean computer or if user goes to ARP they can interact with the bundle. I see in Wix37\src\burn\Samples there is an example on how to get progress from burn. I could write code to download the burn exe myself but burn can already download updates so... Wes -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: October-12-12 1:15 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Broken links on WiX web site Hi, The page at: http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm contains some broken links. Specifically, WixUI_Mondo and WixUI_Minimal are broken (404 Not Found). Not sure who maintains the web site so I'm writing to this list... Best
Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode
Yes, all true. None implemented yet. smile/ On Mon, Oct 15, 2012 at 11:05 AM, Wesley Manning wmann...@dynagen.cawrote: Very True. I was thinking that there would not be a security issue if you check the UpgradeCode on the downloaded bundle before installing but anybody could make a bundle with my upgrade code. :) Maybe you could support it only in cases were the bundle is signed? You could check that the signature from both bundles come from the same company once downloaded. Is this reasonable? And/or add a URL attribute for wixstba in the wix project that gets compiled and that only allow checks for updates from this URL or based off this URL??? Anyways I was trying to take the easy route but looks like going to have to implement my own BA. :) Thanks. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: October-15-12 2:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode Having the update URL come from outside the Bundle would be a very large security gap. Essentially, any Bundle could be used to launch any other random Bundle. That's not right. There is certainly work that could be done in the wixstdba to support bundle self-update but I don't think passing the update URL via the command-line is the right way to do that. smile/ On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning wmann...@dynagen.ca wrote: Sorry, for (1) I meant I don't want to do it from a custom BA. I want to do it by calling the bundle from the application software that my bundle installs. I know for wixstba you provide /uninstall and /repair commands. I use wixstba for my bundle so it would be nice if there was an /upgrade command line option in wixstba where I pass the URL of the update and the bundle downloads and installs it. Is this something that you guys can do for version 3.7? Thanks for the info on UninstallKey in the registry. I actually forgot about that. I see it has a BundleCachePath value so I can use that to call my bundle. All I need is for the wixstba to have a command line argument to do an upgrade. Questions 2 and 3 are moot now. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: October 14, 2012 12:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode 1. I don't quite understand the question. The bundle self-update feature allows a BA to check the internet and tell the engine that there is a newer version of itself and to download then launch that instead. It is not clear to me what the command-line has to do with it. 2. Bundles are registered in ARP (aka: Program and Features, aka: the UninstallKey). That's how you can click on the Uninstall button in ARP and Burn launches to remove the bundle. You can search for it that way if you want. 3. Again, the self-update happens inside a Burn bundle. It isn't driven from a command-line argument. I may just be confused by not understanding your first question. You always have the Bundle. It's cached. That's how ARP works. On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning wmann...@dynagen.ca wrote: Hi, have some questions about wixstba: (1) Wix 3.7 bundle self update feature: Is it possible (or any plans to make it possible) to run from the command line? You would need to run the bundle exe (thus have to know where its located). There is already -uninstall, -repair, etc. (2) Since Windows installer is part of the operating system it is possible to install/uninstall/repair by running msiexec /x ProductCode. You don't need to have the MSi file or know where it is on the computer. Is there something similar for bundles? This question is really about burn in general. (3) Similar to (2) above but for the wix 3.7 self update feature: give an upgrade code and URL and have it download and upgrade the bundle. Is this possible? I was hoping to have our software update itself / show its own install progress UI so the user doesn't have to use the bundle for that (they may not have the bundle anymore). The bundle would only be used to install our software on a clean computer or if user goes to ARP they can interact with the bundle. I see in Wix37\src\burn\Samples there is an example on how to get progress from burn. I could write code to download the burn exe myself but burn can already download updates so... Wes -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: October-12-12 1:15 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Broken links on WiX web site Hi, The page at: http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm
[WiX-users] Just upgraded to v3.6.3303.0 and now can't build...
Hey all, Just upgraded and tried to rebuild my VS2010 wix project. Cleaned up a few warnings and now it compiles clean... _except_ for the following error: candle.exe(0,0): error CNDL0001: Cannot set column 'SecureObject' with a null value because this is a required field. The error output leaves a lot to be desired: 1. What source file is causing this? 2. What table does the column belong too? The full candle command is (some names changed to protect the innocent): candle.exe -sw1008 -sw1009 -v -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=C:\..snip..\MyProject\\ -dProjectExt=.wixproj -dProjectFileName=MyProject.wixproj -dProjectName=MyProject -dProjectPath=C:\ ..snip..\MyProject.wixproj -dTargetDir=C:\ ...snip..\MyProject\bin\Release\\ -dTargetExt=.msi -dTargetFileName=MyProject.msi -dTargetName=MyProject -dTargetPath=C:\ ...snip..\MyProject\bin\Release\MyProject.msi -out obj\Release\ -arch x86 -ext C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixNetFxExtension.dll -ext C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUtilExtension.dll -ext C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUIExtension.dll -ext C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixIIsExtension.dll Application.wxs CustomDialogs.wxs ErrorText.wxs Files.wxs MicrosoftAssemblies.wxs MyAssemblies.wxs MyCustomActionDefinitions.wxs MyEventLog.wxs MyRegistry.wxs I've been through every Property .. element and removed Secure=yes but this has not helped. I've reviewed this bug: http://sourceforge.net/p/wix/bugs/2941/ and its original posting (http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-projects- fail-to-build-after-upgrading-to-v3-6-2914-0-td7559640.html) but my project is not suppressing .wixpdb output (even tried turning it on and then off). Does anyone have any suggestions on what I can do to move past this problem? Any suggestions on how to gather more output from candle to get a clue as to the origin of the problem? Thanks! Rob -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build...
Runing the candle command from a command line window yields additional exception output. As a side note, any ideas why wouldn't the exception details be captured as part of the build output when invoked from VS2010 (sure would have saved me a ton of time)? Here's the output: Exception Type: System.InvalidOperationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object value) at Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParsePermissio nExElement(XmlNode node, String objectId, String componentId, Boolean win64, Str ing tableName) at Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement, XmlElemen t element, String keyPath, String[] contextValues) at Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement, XmlElemen t element, String[] contextValues) at Microsoft.Tools.WindowsInstallerXml.CompilerCore.ParseExtensionElement(Sou rceLineNumberCollection sourceLineNumbers, XmlElement parentElement, XmlElement element, String[] contextValues) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseRegistryKeyElement(XmlNo de node, String componentId, Int32 root, String parentKey, Boolean win64Componen t, String possibleKeyPath) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseComponentElement(XmlNode node, ComplexReferenceParentType parentType, String parentId, String parentLang uage, Int32 diskId, String directoryId, String srcPath) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseDirectoryRefElement(XmlN ode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseFragmentElement(XmlNode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseWixElement(XmlNode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.Compile(XmlDocument source) at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args) So... it looks like perhaps the problem is in ParsePemissionExElement. Assuming this is complaining about util:PermissionsEx ... element I'm left little better off. I use this in quite a few places and they all follow the same pattern: util:PermissionEx User=Guests GenericRead=yes Read=yes GenericExecute=yes / util:PermissionEx User=Users GenericRead=yes Read=yes GenericExecute=yes / util:PermissionEx User=Everyone GenericRead=yes Read=yes GenericExecute=yes / util:PermissionEx User=Administrators GenericAll=yes / util:PermissionEx User=CREATOR OWNER GenericAll=yes / Commenting out every util:PermissionEx .. element allows the build to succeed. Adding back a single util:PermissionEx User=Administrators GenericAll=yes / causes the build to fail with the Cannot set column 'SecureObject' with a null value because this is a required field error. I have a reference to util (C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUtilExtension.dll) and I have included the namespace: Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Has util:PermissionEx .. been dropped from 3.6? Any suggestions? Regards, Rob -Original Message- From: Robert MacFadyen [mailto:rmacfad...@rmtrack.com] Sent: October-15-12 9:53 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build... Hey all, Just upgraded and tried to rebuild my VS2010 wix project. Cleaned up a few warnings and now it compiles clean... _except_ for the following error: candle.exe(0,0): error CNDL0001: Cannot set column 'SecureObject' with a null value because this is a required field. The error output leaves a lot to be desired: 1. What source file is causing this? 2. What table does the column belong too? The full candle command is (some names changed to protect the innocent): candle.exe -sw1008 -sw1009 -v -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=C:\..snip..\MyProject\\ -dProjectExt=.wixproj -dProjectFileName=MyProject.wixproj -dProjectName=MyProject -dProjectPath=C:\ ..snip..\MyProject.wixproj -dTargetDir=C:\ snip..\MyProject\bin\Release\\ -dTargetExt=.msi -dTargetFileName=MyProject.msi -dTargetName=MyProject -dTargetPath=C:\ snip..\MyProject\bin\Release\MyProject.msi -out obj\Release\ -arch x86 -ext C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixNetFxExtension.dll -ext C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUtilExtension.dll -ext C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUIExtension.dll -ext C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixIIsExtension.dll Application.wxs CustomDialogs.wxs ErrorText.wxs Files.wxs MicrosoftAssemblies.wxs MyAssemblies.wxs MyCustomActionDefinitions.wxs MyEventLog.wxs MyRegistry.wxs I've been through every Property .. element and removed Secure=yes but this has not helped. I've reviewed this bug:
Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build... Resolved
Hey all,
More details...
The problem seems to be restricted to RegistryKey .. elements with a child
util:PermisionEx ...
Here's some pre 3.6 code that was fine:
Component Id=RegistryValues Guid={.. hah ...}
RegistryKey Action=create Root=HKLM Key=SOFTWARE\blah\blah
util:PermissionEx User=Administrators GenericAll=yes /
util:PermissionEx User=[My_USERID] Domain=[My_DOMAIN]
GenericAll=yes /
util:PermissionEx User=NetworkService GenericAll=yes /
/RegistryKey
/Component
This generates the following warning:
The RegistryKey/@Action attribute has been deprecated. In most cases, you
can simply omit @Action. If you need to force Windows Installer to create
an empty key or recursively delete the key, use the ForceCreateOnInstall or
ForceDeleteOnUninstall attributes instead.
Believing the In most cases, you can simply omit @Action. I removed
action:
Component Id=RegistryValues Guid={.. hah ...}
RegistryKey Root=HKLM Key=SOFTWARE\blah\blah
util:PermissionEx User=Administrators GenericAll=yes /
util:PermissionEx User=[MyUSERID] Domain=[MyDOMAIN]
GenericAll=yes /
util:PermissionEx User=NetworkService GenericAll=yes /
/RegistryKey
/Component
And bang... I get the error Cannot set column 'SecureObject' with a null
value because this is a required field.
Adding ForceCreateOnInstall=yes resolves the problem.
It would be nice if exceptions that occur during parsing/compiling/linking
were trapped and reported better. It took a lot of effort to track down that
the problem was caused by a simple change to remove a warning (a change that
was explicitly recommend by the warning message itself).
Regards,
Rob
-Original Message-
From: Robert MacFadyen [mailto:rmacfad...@rmtrack.com]
Sent: October-15-12 10:35 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build...
Runing the candle command from a command line window yields additional
exception output. As a side note, any ideas why wouldn't the exception
details be captured as part of the build output when invoked from VS2010
(sure would have saved me a ton of time)?
Here's the output:
Exception Type: System.InvalidOperationException
Stack Trace:
at
Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object
value)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParsePermissio
nExElement(XmlNode node, String objectId, String componentId, Boolean win64,
Str ing tableName)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S
ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement,
XmlElemen t element, String keyPath, String[] contextValues)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S
ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement,
XmlElemen t element, String[] contextValues)
at
Microsoft.Tools.WindowsInstallerXml.CompilerCore.ParseExtensionElement(Sou
rceLineNumberCollection sourceLineNumbers, XmlElement parentElement,
XmlElement element, String[] contextValues)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseRegistryKeyElement(XmlNo
de node, String componentId, Int32 root, String parentKey, Boolean
win64Componen t, String possibleKeyPath)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseComponentElement(XmlNode
node, ComplexReferenceParentType parentType, String parentId, String
parentLang uage, Int32 diskId, String directoryId, String srcPath)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseDirectoryRefElement(XmlN
ode node)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseFragmentElement(XmlNode
node)
at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseWixElement(XmlNode
node)
at Microsoft.Tools.WindowsInstallerXml.Compiler.Compile(XmlDocument
source)
at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args)
So... it looks like perhaps the problem is in ParsePemissionExElement.
Assuming this is complaining about util:PermissionsEx ... element I'm left
little better off. I use this in quite a few places and they all follow the
same pattern:
util:PermissionEx User=Guests GenericRead=yes Read=yes
GenericExecute=yes /
util:PermissionEx User=Users GenericRead=yes Read=yes
GenericExecute=yes /
util:PermissionEx User=Everyone GenericRead=yes Read=yes
GenericExecute=yes /
util:PermissionEx User=Administrators GenericAll=yes /
util:PermissionEx User=CREATOR OWNER GenericAll=yes /
Commenting out every util:PermissionEx .. element allows the build to
succeed.
Adding back a single util:PermissionEx User=Administrators
GenericAll=yes / causes the build to fail with the Cannot set column
'SecureObject' with a null value because this is a required field error.
I have a reference to util (C:\Program Files (x86)\WiX Toolset
v3.6\bin\\WixUtilExtension.dll) and I have included the namespace:
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build... Resolved
Obviously. Please file a bug so the next person benefits.
On Mon, Oct 15, 2012 at 8:09 PM, Robert MacFadyen rmacfad...@rmtrack.comwrote:
Hey all,
More details...
The problem seems to be restricted to RegistryKey .. elements with a
child
util:PermisionEx ...
Here's some pre 3.6 code that was fine:
Component Id=RegistryValues Guid={.. hah ...}
RegistryKey Action=create Root=HKLM Key=SOFTWARE\blah\blah
util:PermissionEx User=Administrators GenericAll=yes /
util:PermissionEx User=[My_USERID] Domain=[My_DOMAIN]
GenericAll=yes /
util:PermissionEx User=NetworkService GenericAll=yes /
/RegistryKey
/Component
This generates the following warning:
The RegistryKey/@Action attribute has been deprecated. In most cases, you
can simply omit @Action. If you need to force Windows Installer to create
an empty key or recursively delete the key, use the ForceCreateOnInstall or
ForceDeleteOnUninstall attributes instead.
Believing the In most cases, you can simply omit @Action. I removed
action:
Component Id=RegistryValues Guid={.. hah ...}
RegistryKey Root=HKLM Key=SOFTWARE\blah\blah
util:PermissionEx User=Administrators GenericAll=yes /
util:PermissionEx User=[MyUSERID] Domain=[MyDOMAIN]
GenericAll=yes /
util:PermissionEx User=NetworkService GenericAll=yes /
/RegistryKey
/Component
And bang... I get the error Cannot set column 'SecureObject' with a null
value because this is a required field.
Adding ForceCreateOnInstall=yes resolves the problem.
It would be nice if exceptions that occur during parsing/compiling/linking
were trapped and reported better. It took a lot of effort to track down
that
the problem was caused by a simple change to remove a warning (a change
that
was explicitly recommend by the warning message itself).
Regards,
Rob
-Original Message-
From: Robert MacFadyen [mailto:rmacfad...@rmtrack.com]
Sent: October-15-12 10:35 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't
build...
Runing the candle command from a command line window yields additional
exception output. As a side note, any ideas why wouldn't the exception
details be captured as part of the build output when invoked from VS2010
(sure would have saved me a ton of time)?
Here's the output:
Exception Type: System.InvalidOperationException
Stack Trace:
at
Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object
value)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParsePermissio
nExElement(XmlNode node, String objectId, String componentId, Boolean
win64,
Str ing tableName)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S
ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement,
XmlElemen t element, String keyPath, String[] contextValues)
at
Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S
ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement,
XmlElemen t element, String[] contextValues)
at
Microsoft.Tools.WindowsInstallerXml.CompilerCore.ParseExtensionElement(Sou
rceLineNumberCollection sourceLineNumbers, XmlElement parentElement,
XmlElement element, String[] contextValues)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseRegistryKeyElement(XmlNo
de node, String componentId, Int32 root, String parentKey, Boolean
win64Componen t, String possibleKeyPath)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseComponentElement(XmlNode
node, ComplexReferenceParentType parentType, String parentId, String
parentLang uage, Int32 diskId, String directoryId, String srcPath)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseDirectoryRefElement(XmlN
ode node)
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseFragmentElement(XmlNode
node)
at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseWixElement(XmlNode
node)
at Microsoft.Tools.WindowsInstallerXml.Compiler.Compile(XmlDocument
source)
at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args)
So... it looks like perhaps the problem is in ParsePemissionExElement.
Assuming this is complaining about util:PermissionsEx ... element I'm
left
little better off. I use this in quite a few places and they all follow the
same pattern:
util:PermissionEx User=Guests GenericRead=yes Read=yes
GenericExecute=yes /
util:PermissionEx User=Users GenericRead=yes Read=yes
GenericExecute=yes /
util:PermissionEx User=Everyone GenericRead=yes Read=yes
GenericExecute=yes /
util:PermissionEx User=Administrators GenericAll=yes /
util:PermissionEx User=CREATOR OWNER GenericAll=yes /
Commenting out every util:PermissionEx .. element allows the build to
succeed.
Adding back a single util:PermissionEx User=Administrators
GenericAll=yes / causes the build to fail with the Cannot set column
'SecureObject' with
