[WiX-users] error while merging 2 msi into one
*My wxs file content is given below:* ?xml version=1.0 encoding=utf-8? !-- # This comment is generated by WixEdit, the specific commandline # arguments for the WiX Toolset are stored here. candleArgs: E:\4thDec\16thDec\GGG.wxs -out E:\4thDec\16thDec\GGGk.wixobj -ext C:\Program Files\WiX Toolset v3.8\bin\WixBalExtension.dll lightArgs: E:\4thDec\16thDec\GGGk.wixobj -out GGGk.msi -ext C:\Program Files\WiX Toolset v3.8\bin\WixBalExtension.dll -- Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:bal=http://schemas.microsoft.com/wix/BalExtension; Bundle Name=Awesome Software Version=1.0.0.0 Manufacturer=Awesome Company Copyright=(c) All rights reserved. UpgradeCode=25565291-ED76-47F3-985E-81896E1DCDF6 Chain MsiPackage Id=pack1 SourceFile=E:\RND_FOR_MSI\uscreen\Wiz.msi / MsiPackage Id=pack2 After=pack1 SourceFile=E:\RND_FOR_MSI\uscreen\UScreenCapture.msi / /Chain /Bundle /Wix * It is giving my these errors whenever i run wixedit--* candle.exe : error CNDL0001 : The 'bootstrapperApplicationData' attribute is not declared. Exception Type: System.Xml.Schema.XmlSchemaException Stack Trace: at System.Xml.XmlValidatingReaderImpl.InternalValidationCallback(Object sender, ValidationEventArgs e) at System.Xml.Schema.BaseValidator.SendValidationEvent(XmlSchemaException e, XmlSeverityType severity) at System.Xml.Schema.BaseValidator.SendValidationEvent(XmlSchemaException e) at System.Xml.Schema.XsdValidator.ValidateStartElement() at System.Xml.Schema.XsdValidator.ProcessElement(Object particle) at System.Xml.Schema.XsdValidator.ValidateElement() at System.Xml.Schema.XsdValidator.Validate() at System.Xml.XmlValidatingReaderImpl.ProcessCoreReaderEvent() at System.Xml.XmlValidatingReaderImpl.Read() at System.Xml.XmlValidatingReader.Read() at Microsoft.Tools.WindowsInstallerXml.TableDefinitionCollection.Parse(XmlReader reader) at Microsoft.Tools.WindowsInstallerXml.TableDefinitionCollection.Load(XmlReader reader, Boolean suppressSchema) at Microsoft.Tools.WindowsInstallerXml.WixExtension.LoadTableDefinitionHelper(Assembly assembly, String resourceName) at Microsoft.Tools.WindowsInstallerXml.Extensions.BalExtension.get_TableDefinitions() at Microsoft.Tools.WindowsInstallerXml.Compiler.AddExtension(WixExtension extension) at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args) - Finished Error in candle With Regards Gaurav -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
There is no way (that I know of) to delete a directory where something
has an open handle on that. The only way is to make sure all programs
have stopped and no open programs have that as their current directory.
It's just like opening cmd.exe, cd'ing to a directory and trying to
delete that directory from explorer. Can't be done.
Dave
On 12/17/2013 10:50 PM, Suvrajyoti Panda wrote:
Hi Phil,
I modified the structure in my main WIX file as below:
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='EnergySolutionsConfig' Name=$(var.rootFolder)
Component Id=parentOfAll
Guid=22AD76A4-448E-41DB-85A0-A04E9774A466 KeyPath=yes
RemoveFolder Id= removeParent On=uninstall/
/Component
After installing i traversed to C:\Energy Solutions
International\PFWService\config\access then uninstalled the path
C:\Energy Solutions International\PFWService\ still exists, all the
files are deleted though.
On 17-12-2013 21:32, Phil Wilson wrote:
Why not just try a RemoveFolder and see if it solves the problem? It is
the most likely solution, as suggested before.
Phil Wilson
On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda suvrajyo...@contata.co.in
wrote:
I just thought i needed to reiterate the issue for better clarity:
Below is the directory structure in my source .wxs file:
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='EnergySolutionsConfig' Name=Energy Solution
International
Directory Id='PFWServiceFolder' Name=PFWService
Directory Id='CONFIG' Name=config
Component Id=x86RegEntPFWConfig
Guid=5DAD9B46-43BB-42D2-91E9-F2248369AA68 Win64=no
RegistryValue Id=x86PFWConfigRegValue Root=HKLM
Key=SOFTWARE\[Manufacturer] Name=ConfigPath Value=[CONFIG]
Type=string /
/Component
Component Id=x64RegEntPFWConfig
Guid=57240178-4A44-4C6F-A11C-B4DE99573DE0 Win64=yes
RegistryValue Id=x64PFWConfigRegValue Root=HKLM
Key=SOFTWARE\[Manufacturer] Name=ConfigPath Value=[CONFIG]
Type=string /
/Component
/Directory
/Directory
/Directory
/Directory
The heat harvests directories from a location D:\Configrelease which has
directories such as command_processors. The produces config.wxs file
that has below structure:
Fragment
DirectoryRef Id=CONFIG
Component Id=cmpC405575C36944E434C00DCE528FA79EA
Guid={0EDAF860-B5C3-4C93-BDD7-EB1947D94749}
File Id=fil62BA9BFC68F4D3C2DE913D9ABFEDC429
KeyPath=yes Source=$(var.ConfigPath)\PFWConfiguration.xml /
/Component
Directory Id=dirB9FCE785B12AD5549EC71DC5DC66ED48
Name=archives
/Directory
Directory Id=dirB8C0CFD798C8A57234B0C04A4E266B86
Name=command_processors
Component Id=cmpE03A5A54FF75ABF0FA6DA591BC4F3152
Guid={F2158D98-1DC2-4348-89FC-65A2115084B6} KeyPath=yes
CreateFolder /
/Component
After i run the installer, i browse to C:\Energy Solutions
International\PFWService\config\command_processors and keep this path
open, and then uninstall the directory structure that does not get
removed is C:\Energy Solutions International\PFWService.
Is it because of the CreateFolder in the config.wxs(as Wesley had
suggest) file that heat creates that i am facing this issue. If so what
is the way out. Hope i have explained the situation better this time,
apologies if i created any confusion.
Regards,
SuvraJyoti
On 17-12-2013 14:27, Suvrajyoti Panda wrote:
Hey Blair,
The scenario you have mentioned in the first para of your response is
exactly what is happening. So is there no way that we can handle the
folder removal on uninstall even if that path is open, or this is a
known issue?
Regards,
SuvraJyoti
On 17-12-2013 14:14, Blair Murri wrote:
If a file being removed can’t be moved, then it will be marked for
removal during reboot, and unfortunately the folder will then be left
behind (because only file delete records are placed into the reboot
sequence, not folders). After reboot there isn’t an installation left to
run to cleanup any further.
Most of the time, files still in use can be moved (even if they are
still loaded in other processes) and the folder is thus removed during the
installation transaction (before the reboot) and the moved file is then
removed as part of the reboot sequence.
-Blair
From: Suvrajyoti Panda
Sent: Monday, December 16, 2013 8:57 PM
To: General discussion for Windows Installer XML toolset.
No Wesley, I have not used any create folder over here.
Regards,
SuvraJyoti
On 16-12-2013 20:03, Wesley Manning wrote:
Did you use CreateFolder to create this directory? If so I think you
need to use RemoveFolder to remove the folder. Not sure about that though.
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Does it exist after a reboot? I seem to remember windows installer being smart
enough to schedule some cleanup after reboot (if it couldn't do them during
uninstall).
-Original Message-
From: David Connet [mailto:d...@agilityrecordbook.com]
Sent: Wednesday, December 18, 2013 8:25 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
if that path is open on the system
There is no way (that I know of) to delete a directory where something has an
open handle on that. The only way is to make sure all programs have stopped and
no open programs have that as their current directory.
It's just like opening cmd.exe, cd'ing to a directory and trying to delete that
directory from explorer. Can't be done.
Dave
On 12/17/2013 10:50 PM, Suvrajyoti Panda wrote:
Hi Phil,
I modified the structure in my main WIX file as below:
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='EnergySolutionsConfig' Name=$(var.rootFolder)
Component Id=parentOfAll
Guid=22AD76A4-448E-41DB-85A0-A04E9774A466 KeyPath=yes
RemoveFolder Id= removeParent On=uninstall/
/Component
After installing i traversed to C:\Energy Solutions
International\PFWService\config\access then uninstalled the path
C:\Energy Solutions International\PFWService\ still exists, all the
files are deleted though.
On 17-12-2013 21:32, Phil Wilson wrote:
Why not just try a RemoveFolder and see if it solves the problem? It
is the most likely solution, as suggested before.
Phil Wilson
On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda
suvrajyo...@contata.co.in
wrote:
I just thought i needed to reiterate the issue for better clarity:
Below is the directory structure in my source .wxs file:
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='EnergySolutionsConfig' Name=Energy Solution
International
Directory Id='PFWServiceFolder' Name=PFWService
Directory Id='CONFIG' Name=config
Component Id=x86RegEntPFWConfig
Guid=5DAD9B46-43BB-42D2-91E9-F2248369AA68 Win64=no
RegistryValue Id=x86PFWConfigRegValue Root=HKLM
Key=SOFTWARE\[Manufacturer] Name=ConfigPath Value=[CONFIG]
Type=string /
/Component
Component Id=x64RegEntPFWConfig
Guid=57240178-4A44-4C6F-A11C-B4DE99573DE0 Win64=yes
RegistryValue Id=x64PFWConfigRegValue Root=HKLM
Key=SOFTWARE\[Manufacturer] Name=ConfigPath Value=[CONFIG]
Type=string /
/Component
/Directory
/Directory
/Directory
/Directory
The heat harvests directories from a location D:\Configrelease which
has directories such as command_processors. The produces
config.wxs file that has below structure:
Fragment
DirectoryRef Id=CONFIG
Component Id=cmpC405575C36944E434C00DCE528FA79EA
Guid={0EDAF860-B5C3-4C93-BDD7-EB1947D94749}
File Id=fil62BA9BFC68F4D3C2DE913D9ABFEDC429
KeyPath=yes Source=$(var.ConfigPath)\PFWConfiguration.xml /
/Component
Directory Id=dirB9FCE785B12AD5549EC71DC5DC66ED48
Name=archives
/Directory
Directory Id=dirB8C0CFD798C8A57234B0C04A4E266B86
Name=command_processors
Component Id=cmpE03A5A54FF75ABF0FA6DA591BC4F3152
Guid={F2158D98-1DC2-4348-89FC-65A2115084B6} KeyPath=yes
CreateFolder /
/Component
After i run the installer, i browse to C:\Energy Solutions
International\PFWService\config\command_processors and keep this
path open, and then uninstall the directory structure that does not
get removed is C:\Energy Solutions International\PFWService.
Is it because of the CreateFolder in the config.wxs(as Wesley had
suggest) file that heat creates that i am facing this issue. If so
what is the way out. Hope i have explained the situation better this
time, apologies if i created any confusion.
Regards,
SuvraJyoti
On 17-12-2013 14:27, Suvrajyoti Panda wrote:
Hey Blair,
The scenario you have mentioned in the first para of your response
is exactly what is happening. So is there no way that we can handle
the folder removal on uninstall even if that path is open, or this
is a known issue?
Regards,
SuvraJyoti
On 17-12-2013 14:14, Blair Murri wrote:
If a file being removed can't be moved, then it will be marked for
removal during reboot, and unfortunately the folder will then be
left behind (because only file delete records are placed into the
reboot sequence, not folders). After reboot there isn't an
installation left to run to cleanup any further.
Most of the time, files still in use can be moved (even if they
are
still loaded in other processes) and the folder is thus removed
during the installation transaction (before the reboot) and the
Re: [WiX-users] Adding a registry key to HKLM
Yes of course WiX supports writing to HKLM, so where are you at this point? Using HKMU? HKLM? It just works, and if it doesn't then something is going wrong but you're not supplying any extra information to let anyone figure out why it's not working. Are you seeing an elevation prompt during the install, or otherwise making sure that the install is elevated? Are you sure the component is being installed? Have you looked at a verbose log? Phil Wilson On Tue, Dec 17, 2013 at 9:42 PM, Nicolás Alvarez nicolas.alva...@gmail.comwrote: Why are you reposting your question after merely 2 hours? This is free volunteer support, have some patience. -- Nicolás 2013/12/17 Shyam Kannam shyam.kan...@hotmail.com: Could someone help me on this? Does WiX allows to write registry entries to HKLM? Even it is mentioned as a per machine scope, it ignores it. -Original Message- From: Shyam Kannam [mailto:shyam.kan...@hotmail.com] Sent: Tuesday, December 17, 2013 1:51 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding a registry key to HKLM Tried HKMU - but the key is just ignored. Key is not created neither in HKLM nor in HKCU. This is the same behavior with HKLM. Logs also doesn’t give me any hint on why it is getting ignored. Sent from Windows Mail From: Phil Wilson Sent: Tuesday, December 17, 2013 1:50 PM To: wix-users@lists.sourceforge.net P.S. IMO you don't need HKMU because you should split that component, but if your HKMU is going into HKCU then you're probably not doing an elevated per machine install. You're probably per user. Phil Wilson On Tue, Dec 17, 2013 at 1:33 PM, Shyam Kannam shyam.kan...@hotmail.com wrote: Thanks Jacob for the response. I still didn’t have success. With the below code, I don’t have any warnings. But the key is created only when it is give is ‘HKCU’. Both ‘HKLM’ or ‘HKMU’ seems ignored (don’t see the key created after installation). Any help on this would be appreciated. All I need is to place one registry key under HKLM. ComponentGroup Id=REGISTRYENTRIES Directory=INSTALLFOLDER Component Id=CMPRegistryEntries Guid=069E2626-1217-10D4-6D17-B720D5DFEA7D RegistryKey Root=HKMU Key=Software\Microsoft\Spectrum RegistryValue Name=installed Value=1 Type=integer / RegistryValue Name=SpectrumPackageVersion Value=$(var.MSIPACKAGEVERSION) Type=string / /RegistryKey /Component /ComponentGroup !-- program menu items -- ComponentGroup Id=PROGRAMMENUSHORTCUT Directory=INSTALLFOLDER Component Id=CMPApplicationStartMenuShortcut Guid=13269471-FC6F-40E6-B7BF-02CDB3395A11 Shortcut Id=UninstallDriver Name=!(loc.Uninstall) Description=!(loc.UninstallDescription) Target=[System64Folder]msiexec.exe Arguments=/x [ProductCode] Icon=PackageIcon / RemoveFolder Id=PROGRAMMENUDIR On=uninstall/ /Component /ComponentGroup Sent from Windows Mail From: Hoover, Jacob Sent: Tuesday, December 17, 2013 1:27 PM To: wix-users@lists.sourceforge.net http://robmensching.com/blog/posts/2007/4/27/how-to-create-an-uninstal l-shortcut-and-pass-all-the If it were me... and your install is per-machine, use HKMU and then suppress the one invalid ICE message. ( http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE57-wi th-HKMU-tt5795201.html#a5796717 ) But really, why is it a requirement for this RegistryKey be associated with the shortcut, which shouldn't have anything to do with a service (IE, can't they be two components). -Original Message- From: Shyam Kannam [mailto:shyam.kan...@hotmail.com] Sent: Tuesday, December 17, 2013 1:23 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding a registry key to HKLM I’m running into issues to add couple registry keys to HKLM hive. This is a requirement for the project to add the key to HKLM as they can be accessed from a local system service. HKCU is not accessible from a local system service. When I use the code below, I’m getting ICE errors. Tried different ways to avoid the error, but unable to see the key under HKLM created after installation. I think I’m missing some basic here. error LGHT0204: ICE38: Component CMPApplicationStartMenuShortcut installs to user profile. It's KeyPath registry key must fall under HKCU. error LGHT0204: ICE43: Component CMPApplicationStartMenuShortcut has non-advertised shortcuts. It's KeyPath registry key should fall under HKCU. error LGHT0204: ICE57: Component 'CMPApplicationStartMenuShortcut' has both per-user and per-machine data with a per-machine KeyPath. !-- program menu items -- ComponentGroup Id=PROGRAMMENUSHORTCUT Directory=PROGRAMMENUDIR2 Component Id=CMPApplicationStartMenuShortcut
[WiX-users] Signing all DLLs and EXEs in project
Is there a way I can sign all the DLLs and EXEs in my project using WiX via signtool? I was hoping there might be something available in the @Component element that would allow me to selectively sign DLL/EXE files so that I could avoid signing DLLs that I did not create. Brian If you can't explain it simply, you don't understand it well enough. - Albert Einstein -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Signing all DLLs and EXEs in project
Not today. Something considering for v4 (maybe). -Original Message- From: Brian Enderle [mailto:bria...@gmail.com] Sent: Wednesday, December 18, 2013 11:22 AM To: General discussion about the WiX toolset. Subject: [WiX-users] Signing all DLLs and EXEs in project Is there a way I can sign all the DLLs and EXEs in my project using WiX via signtool? I was hoping there might be something available in the @Component element that would allow me to selectively sign DLL/EXE files so that I could avoid signing DLLs that I did not create. Brian If you can't explain it simply, you don't understand it well enough. - Albert Einstein -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Signing all DLLs and EXEs in project
There are specific targets that need to be overridden to sign CABs, Burn, and MSIs. In the general case (which is MsBuild and NOT WiX): 1) you need to create a signtool MsBuild Tool Task; 2) create an MsBuild Item Group list of the pathnames you want to sign; 3) pass the ItemGroup to the MsBuild Tool Task above with appropriate parameters for the signing cert, password etc. There are a lot of ways to sign. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Brian Enderle [mailto:bria...@gmail.com] Sent: Wednesday, December 18, 2013 1:22 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Signing all DLLs and EXEs in project Is there a way I can sign all the DLLs and EXEs in my project using WiX via signtool? I was hoping there might be something available in the @Component element that would allow me to selectively sign DLL/EXE files so that I could avoid signing DLLs that I did not create. Brian If you can't explain it simply, you don't understand it well enough. - Albert Einstein -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Signing all DLLs and EXEs in project
Make sure you set the number of files in the item group to under 1000, there is a limit to the length of the command line that signtool (and windows) will accept :) Stephen Tunney Nuance Communications, Inc. Solutions Architect, Imaging Division Waterloo, Ontario, Canada stephen.tun...@nuance.com 519-880-7463Office NUANCE.COM The experience speaks for itself T -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: December-18-13 2:29 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Signing all DLLs and EXEs in project There are specific targets that need to be overridden to sign CABs, Burn, and MSIs. In the general case (which is MsBuild and NOT WiX): 1) you need to create a signtool MsBuild Tool Task; 2) create an MsBuild Item Group list of the pathnames you want to sign; 3) pass the ItemGroup to the MsBuild Tool Task above with appropriate parameters for the signing cert, password etc. There are a lot of ways to sign. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Brian Enderle [mailto:bria...@gmail.com] Sent: Wednesday, December 18, 2013 1:22 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Signing all DLLs and EXEs in project Is there a way I can sign all the DLLs and EXEs in my project using WiX via signtool? I was hoping there might be something available in the @Component element that would allow me to selectively sign DLL/EXE files so that I could avoid signing DLLs that I did not create. Brian If you can't explain it simply, you don't understand it well enough. - Albert Einstein -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding a registry key to HKLM
Hi Phil, It's still doesn't work for me. I don't get an elevated prompt but an untrusted warning - as the package wasn't signed. I tried running the installer from an elevated command prompt - but the result is the same. I didn't see much of a difference in the verbose log as well from HKCU and HKLM Root tests. The component gets installed when it is HKCU, but when I keep either HKMU or HKLM, it is totally ignored and doesn't write the key to registry. Do I need to set any property for getting an elevated command prompt? Any suggestions would be helpful. Property Id=ALLUSERS Value=1 Admin=yes/ ComponentGroup Id=REGISTRYENTRIES Directory=INSTALLFOLDER Component Id=CMPRegistryEntries Guid=069E2626-1217-10D4-6D17-B720D5DFEA7D RegistryKey Root=HKLM Key=Software\Microsoft\Spectrum RegistryValue Name=installed Value=1 Type=integer KeyPath=no/ RegistryValue Name=SpectrumPackageVersion Value=$(var.MSIPACKAGEVERSION) Type=string / /RegistryKey /Component /ComponentGroup -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: Wednesday, December 18, 2013 8:22 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding a registry key to HKLM Yes of course WiX supports writing to HKLM, so where are you at this point? Using HKMU? HKLM? It just works, and if it doesn't then something is going wrong but you're not supplying any extra information to let anyone figure out why it's not working. Are you seeing an elevation prompt during the install, or otherwise making sure that the install is elevated? Are you sure the component is being installed? Have you looked at a verbose log? Phil Wilson On Tue, Dec 17, 2013 at 9:42 PM, Nicolás Alvarez nicolas.alva...@gmail.comwrote: Why are you reposting your question after merely 2 hours? This is free volunteer support, have some patience. -- Nicolás 2013/12/17 Shyam Kannam shyam.kan...@hotmail.com: Could someone help me on this? Does WiX allows to write registry entries to HKLM? Even it is mentioned as a per machine scope, it ignores it. -Original Message- From: Shyam Kannam [mailto:shyam.kan...@hotmail.com] Sent: Tuesday, December 17, 2013 1:51 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding a registry key to HKLM Tried HKMU - but the key is just ignored. Key is not created neither in HKLM nor in HKCU. This is the same behavior with HKLM. Logs also doesnt give me any hint on why it is getting ignored. Sent from Windows Mail From: Phil Wilson Sent: Tuesday, December 17, 2013 1:50 PM To: wix-users@lists.sourceforge.net P.S. IMO you don't need HKMU because you should split that component, but if your HKMU is going into HKCU then you're probably not doing an elevated per machine install. You're probably per user. Phil Wilson On Tue, Dec 17, 2013 at 1:33 PM, Shyam Kannam shyam.kan...@hotmail.com wrote: Thanks Jacob for the response. I still didnt have success. With the below code, I dont have any warnings. But the key is created only when it is give is HKCU. Both HKLM or HKMU seems ignored (dont see the key created after installation). Any help on this would be appreciated. All I need is to place one registry key under HKLM. ComponentGroup Id=REGISTRYENTRIES Directory=INSTALLFOLDER Component Id=CMPRegistryEntries Guid=069E2626-1217-10D4-6D17-B720D5DFEA7D RegistryKey Root=HKMU Key=Software\Microsoft\Spectrum RegistryValue Name=installed Value=1 Type=integer / RegistryValue Name=SpectrumPackageVersion Value=$(var.MSIPACKAGEVERSION) Type=string / /RegistryKey /Component /ComponentGroup !-- program menu items -- ComponentGroup Id=PROGRAMMENUSHORTCUT Directory=INSTALLFOLDER Component Id=CMPApplicationStartMenuShortcut Guid=13269471-FC6F-40E6-B7BF-02CDB3395A11 Shortcut Id=UninstallDriver Name=!(loc.Uninstall) Description=!(loc.UninstallDescription) Target=[System64Folder]msiexec.exe Arguments=/x [ProductCode] Icon=PackageIcon / RemoveFolder Id=PROGRAMMENUDIR On=uninstall/ /Component /ComponentGroup Sent from Windows Mail From: Hoover, Jacob Sent: Tuesday, December 17, 2013 1:27 PM To: wix-users@lists.sourceforge.net http://robmensching.com/blog/posts/2007/4/27/how-to-create-an-unins tal l-shortcut-and-pass-all-the If it were me... and your install is per-machine, use HKMU and then suppress the one invalid ICE message. ( http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE57 -wi th-HKMU-tt5795201.html#a5796717 ) But really, why is it a requirement for this RegistryKey be associated with the shortcut, which shouldn't have anything to do with a service (IE, can't they be
Re: [WiX-users] Signing all DLLs and EXEs in project
If you can explain how do you want to sign the dll I can try to create wix
extension for you
something like
Component Directory=FeatureA1
yourNameSpace:SignKeyPathFile=yes
Guid={87DFBD51-5DA7-46D2-9FB5-8A602A87EA71}
Id=ComponentAA1.txt
File KeyPath=yes
Source=Content\FeatureA\FeatureA1\ComponentAA1\ComponentAA1.txt/
/Component
/Feature
Tomer Dror
SmartPlant Explorer Development Manager.
Intergraph Corporation.
Intergraph Israel.
Nesher 36881 - 4, Hacharoshet St.
P: +972 (4) 8779191-1222
Skype:tomer.dee
http://www.intergraph.com
.
From: Rob Mensching [r...@robmensching.com]
Sent: Wednesday, December 18, 2013 9:26 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Signing all DLLs and EXEs in project
Not today. Something considering for v4 (maybe).
-Original Message-
From: Brian Enderle [mailto:bria...@gmail.com]
Sent: Wednesday, December 18, 2013 11:22 AM
To: General discussion about the WiX toolset.
Subject: [WiX-users] Signing all DLLs and EXEs in project
Is there a way I can sign all the DLLs and EXEs in my project using WiX via
signtool?
I was hoping there might be something available in the @Component element that
would allow me to selectively sign DLL/EXE files so that I could avoid signing
DLLs that I did not create.
Brian
If you can't explain it simply, you don't understand it well enough. - Albert
Einstein
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance affects
their revenue. With AppDynamics, you get 100% visibility into your Java,.NET,
PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Signing all DLLs and EXEs in project
If you're signing more than a dozen or so files in one pass, you've got bigger problems. :) Besides which, like many build-related tasks, signing is an activity best done in the same project generating the binary. Now, this isn't the Microsoft way in use when I left SCX in 2010. But I doubt very much whether very many of you would like to write a script to recurse over every output in your golden build (including many that couldn't be signed) . . . and hand it off to another team who does nothing but signing. That being said, it's a very custom activity. It needs to mesh with how your group/company/corporation does it. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Tunney, Stephen [mailto:stephen.tun...@nuance.com] Sent: Wednesday, December 18, 2013 1:46 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Signing all DLLs and EXEs in project Make sure you set the number of files in the item group to under 1000, there is a limit to the length of the command line that signtool (and windows) will accept :) Stephen Tunney Nuance Communications, Inc. Solutions Architect, Imaging Division Waterloo, Ontario, Canada stephen.tun...@nuance.com 519-880-7463Office NUANCE.COM The experience speaks for itself T -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: December-18-13 2:29 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Signing all DLLs and EXEs in project There are specific targets that need to be overridden to sign CABs, Burn, and MSIs. In the general case (which is MsBuild and NOT WiX): 1) you need to create a signtool MsBuild Tool Task; 2) create an MsBuild Item Group list of the pathnames you want to sign; 3) pass the ItemGroup to the MsBuild Tool Task above with appropriate parameters for the signing cert, password etc. There are a lot of ways to sign. -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Brian Enderle [mailto:bria...@gmail.com] Sent: Wednesday, December 18, 2013 1:22 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Signing all DLLs and EXEs in project Is there a way I can sign all the DLLs and EXEs in my project using WiX via signtool? I was hoping there might be something available in the @Component element that would allow me to selectively sign DLL/EXE files so that I could avoid signing DLLs that I did not create. Brian If you can't explain it simply, you don't understand it well enough. - Albert Einstein -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
Re: [WiX-users] Signing all DLLs and EXEs in project
You'll have to correctly handle the case where a binary cannot be signed
because it has references to unsigned assemblies. We run into this all the
time with our UI controls.
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: Dror, Tomer [mailto:tomer.d...@intergraph.com]
Sent: Wednesday, December 18, 2013 1:44 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Signing all DLLs and EXEs in project
If you can explain how do you want to sign the dll I can try to create wix
extension for you
something like
Component Directory=FeatureA1
yourNameSpace:SignKeyPathFile=yes
Guid={87DFBD51-5DA7-46D2-9FB5-8A602A87EA71}
Id=ComponentAA1.txt
File KeyPath=yes
Source=Content\FeatureA\FeatureA1\ComponentAA1\ComponentAA1.txt/
/Component
/Feature
Tomer Dror
SmartPlant Explorer Development Manager.
Intergraph Corporation.
Intergraph Israel.
Nesher 36881 - 4, Hacharoshet St.
P: +972 (4) 8779191-1222
Skype:tomer.dee
http://www.intergraph.com
.
From: Rob Mensching [r...@robmensching.com]
Sent: Wednesday, December 18, 2013 9:26 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Signing all DLLs and EXEs in project
Not today. Something considering for v4 (maybe).
-Original Message-
From: Brian Enderle [mailto:bria...@gmail.com]
Sent: Wednesday, December 18, 2013 11:22 AM
To: General discussion about the WiX toolset.
Subject: [WiX-users] Signing all DLLs and EXEs in project
Is there a way I can sign all the DLLs and EXEs in my project using WiX via
signtool?
I was hoping there might be something available in the @Component element that
would allow me to selectively sign DLL/EXE files so that I could avoid signing
DLLs that I did not create.
Brian
If you can't explain it simply, you don't understand it well enough. - Albert
Einstein
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance affects
their revenue. With AppDynamics, you get 100% visibility into your Java,.NET,
PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance affects
their revenue. With AppDynamics, you get 100% visibility into your Java,.NET,
PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance affects
their revenue. With AppDynamics, you get 100% visibility into your Java,.NET,
PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
Re: [WiX-users] Signing all DLLs and EXEs in project
I guess the OP is talking about native binaries, not .NET assemblies
since he mentioned signtool - sn is the .NET signing tool.
--
Bruce
On 12/18/2013 1:23 PM, John Cooper wrote:
You'll have to correctly handle the case where a binary cannot be signed
because it has references to unsigned assemblies. We run into this all the
time with our UI controls.
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.®
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: Dror, Tomer [mailto:tomer.d...@intergraph.com]
Sent: Wednesday, December 18, 2013 1:44 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Signing all DLLs and EXEs in project
If you can explain how do you want to sign the dll I can try to create wix
extension for you
something like
Component Directory=FeatureA1
yourNameSpace:SignKeyPathFile=yes
Guid={87DFBD51-5DA7-46D2-9FB5-8A602A87EA71}
Id=ComponentAA1.txt
File KeyPath=yes
Source=Content\FeatureA\FeatureA1\ComponentAA1\ComponentAA1.txt/
/Component
/Feature
Tomer Dror
SmartPlant Explorer Development Manager.
Intergraph Corporation.
Intergraph Israel.
Nesher 36881 - 4, Hacharoshet St.
P: +972 (4) 8779191-1222
Skype:tomer.dee
http://www.intergraph.com
.
From: Rob Mensching [r...@robmensching.com]
Sent: Wednesday, December 18, 2013 9:26 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Signing all DLLs and EXEs in project
Not today. Something considering for v4 (maybe).
-Original Message-
From: Brian Enderle [mailto:bria...@gmail.com]
Sent: Wednesday, December 18, 2013 11:22 AM
To: General discussion about the WiX toolset.
Subject: [WiX-users] Signing all DLLs and EXEs in project
Is there a way I can sign all the DLLs and EXEs in my project using WiX via
signtool?
I was hoping there might be something available in the @Component element
that would allow me to selectively sign DLL/EXE files so that I could avoid
signing DLLs that I did not create.
Brian
If you can't explain it simply, you don't understand it well enough. -
Albert Einstein
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are
intended
exclusively for the individual or entity to which it is addressed. The
message,
together with any attachment, may contain confidential and/or privileged
information.
Any unauthorized review, use, printing, saving, copying, disclosure or
distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100%
Re: [WiX-users] Signing all DLLs and EXEs in project
On 12/18/2013 1:21 PM, John Cooper wrote: If you're signing more than a dozen or so files in one pass, you've got bigger problems. :) Besides which, like many build-related tasks, signing is an activity best done in the same project generating the binary. +1. Unless you're talking about signing custom action DLLs, then signing is best done before the packaging/installer task. -- Bruce -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSI veteran - using WiX
I believe for that you would typically create a new .wxs file containing: Fragment UI Id=YourErrors ... /UI /Fragment The UI fragment can be referenced from either your Product or another UI element. UIRef Id=YourErrors/ see: http://wixtoolset.org/documentation/manual/v3/xsd/wix/uiref.html Also, it's worth noting that any time you reference anything from a fragment, the entire contents of that fragment will get pulled in. Since you are using VisualStudio, all the .wxs sources in the project will be built and references will work between different files. Hope that helps, -Dave -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-veteran-using-WiX-tp7591415p7591424.html Sent from the wix-users mailing list archive at Nabble.com. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Signing all DLLs and EXEs in project
I think the OP is talking about all binaries, period. It's an aside I guess, but signtool is for certificate signing and sn.exe is for strong naming of assemblies - I have no idea why strong naming turned into signing because they are rather different. Strong named assemblies can reference only other strong named assemblies - this is not a certificate signing restriction. So he wants to run signtool.exe on all binaries to get them certificate signed, whether they are strongly named assemblies or not. Phil Wilson On Wed, Dec 18, 2013 at 12:51 PM, Bruce Cran br...@cran.org.uk wrote: On 12/18/2013 1:21 PM, John Cooper wrote: If you're signing more than a dozen or so files in one pass, you've got bigger problems. :) Besides which, like many build-related tasks, signing is an activity best done in the same project generating the binary. +1. Unless you're talking about signing custom action DLLs, then signing is best done before the packaging/installer task. -- Bruce -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Hey David,
Thanks for the confirmation.I just checked after reboot as well, but
that does not happen. Anyways thanks again.
Regards,
SuvraJyoti
On 18-12-2013 19:54, David Connet wrote:
There is no way (that I know of) to delete a directory where something
has an open handle on that. The only way is to make sure all programs
have stopped and no open programs have that as their current directory.
It's just like opening cmd.exe, cd'ing to a directory and trying to
delete that directory from explorer. Can't be done.
Dave
On 12/17/2013 10:50 PM, Suvrajyoti Panda wrote:
Hi Phil,
I modified the structure in my main WIX file as below:
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='EnergySolutionsConfig' Name=$(var.rootFolder)
Component Id=parentOfAll
Guid=22AD76A4-448E-41DB-85A0-A04E9774A466 KeyPath=yes
RemoveFolder Id= removeParent On=uninstall/
/Component
After installing i traversed to C:\Energy Solutions
International\PFWService\config\access then uninstalled the path
C:\Energy Solutions International\PFWService\ still exists, all the
files are deleted though.
On 17-12-2013 21:32, Phil Wilson wrote:
Why not just try a RemoveFolder and see if it solves the problem? It is
the most likely solution, as suggested before.
Phil Wilson
On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda suvrajyo...@contata.co.in
wrote:
I just thought i needed to reiterate the issue for better clarity:
Below is the directory structure in my source .wxs file:
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='EnergySolutionsConfig' Name=Energy Solution
International
Directory Id='PFWServiceFolder' Name=PFWService
Directory Id='CONFIG' Name=config
Component Id=x86RegEntPFWConfig
Guid=5DAD9B46-43BB-42D2-91E9-F2248369AA68 Win64=no
RegistryValue Id=x86PFWConfigRegValue Root=HKLM
Key=SOFTWARE\[Manufacturer] Name=ConfigPath Value=[CONFIG]
Type=string /
/Component
Component Id=x64RegEntPFWConfig
Guid=57240178-4A44-4C6F-A11C-B4DE99573DE0 Win64=yes
RegistryValue Id=x64PFWConfigRegValue Root=HKLM
Key=SOFTWARE\[Manufacturer] Name=ConfigPath Value=[CONFIG]
Type=string /
/Component
/Directory
/Directory
/Directory
/Directory
The heat harvests directories from a location D:\Configrelease which has
directories such as command_processors. The produces config.wxs file
that has below structure:
Fragment
DirectoryRef Id=CONFIG
Component Id=cmpC405575C36944E434C00DCE528FA79EA
Guid={0EDAF860-B5C3-4C93-BDD7-EB1947D94749}
File Id=fil62BA9BFC68F4D3C2DE913D9ABFEDC429
KeyPath=yes Source=$(var.ConfigPath)\PFWConfiguration.xml /
/Component
Directory Id=dirB9FCE785B12AD5549EC71DC5DC66ED48
Name=archives
/Directory
Directory Id=dirB8C0CFD798C8A57234B0C04A4E266B86
Name=command_processors
Component Id=cmpE03A5A54FF75ABF0FA6DA591BC4F3152
Guid={F2158D98-1DC2-4348-89FC-65A2115084B6} KeyPath=yes
CreateFolder /
/Component
After i run the installer, i browse to C:\Energy Solutions
International\PFWService\config\command_processors and keep this path
open, and then uninstall the directory structure that does not get
removed is C:\Energy Solutions International\PFWService.
Is it because of the CreateFolder in the config.wxs(as Wesley had
suggest) file that heat creates that i am facing this issue. If so what
is the way out. Hope i have explained the situation better this time,
apologies if i created any confusion.
Regards,
SuvraJyoti
On 17-12-2013 14:27, Suvrajyoti Panda wrote:
Hey Blair,
The scenario you have mentioned in the first para of your response is
exactly what is happening. So is there no way that we can handle the
folder removal on uninstall even if that path is open, or this is a
known issue?
Regards,
SuvraJyoti
On 17-12-2013 14:14, Blair Murri wrote:
If a file being removed can’t be moved, then it will be marked for
removal during reboot, and unfortunately the folder will then be left
behind (because only file delete records are placed into the reboot
sequence, not folders). After reboot there isn’t an installation left to
run to cleanup any further.
Most of the time, files still in use can be moved (even if they are
still loaded in other processes) and the folder is thus removed during the
installation transaction (before the reboot) and the moved file is then
removed as part of the reboot sequence.
-Blair
From: Suvrajyoti Panda
Sent: Monday, December 16, 2013 8:57 PM
To: General discussion for Windows Installer XML toolset.
No Wesley, I have not used any create folder over here.
Re: [WiX-users] Uninstall by Installer not removing the path created if that path is open on the system
Yes it does exist after reboot as well.
On 18-12-2013 21:13, Hoover, Jacob wrote:
Does it exist after a reboot? I seem to remember windows installer being
smart enough to schedule some cleanup after reboot (if it couldn't do them
during uninstall).
-Original Message-
From: David Connet [mailto:d...@agilityrecordbook.com]
Sent: Wednesday, December 18, 2013 8:25 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
if that path is open on the system
There is no way (that I know of) to delete a directory where something has an
open handle on that. The only way is to make sure all programs have stopped
and no open programs have that as their current directory.
It's just like opening cmd.exe, cd'ing to a directory and trying to delete
that directory from explorer. Can't be done.
Dave
On 12/17/2013 10:50 PM, Suvrajyoti Panda wrote:
Hi Phil,
I modified the structure in my main WIX file as below:
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='EnergySolutionsConfig' Name=$(var.rootFolder)
Component Id=parentOfAll
Guid=22AD76A4-448E-41DB-85A0-A04E9774A466 KeyPath=yes
RemoveFolder Id= removeParent On=uninstall/
/Component
After installing i traversed to C:\Energy Solutions
International\PFWService\config\access then uninstalled the path
C:\Energy Solutions International\PFWService\ still exists, all the
files are deleted though.
On 17-12-2013 21:32, Phil Wilson wrote:
Why not just try a RemoveFolder and see if it solves the problem? It
is the most likely solution, as suggested before.
Phil Wilson
On Tue, Dec 17, 2013 at 5:16 AM, Suvrajyoti Panda
suvrajyo...@contata.co.in
wrote:
I just thought i needed to reiterate the issue for better clarity:
Below is the directory structure in my source .wxs file:
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='EnergySolutionsConfig' Name=Energy Solution
International
Directory Id='PFWServiceFolder' Name=PFWService
Directory Id='CONFIG' Name=config
Component Id=x86RegEntPFWConfig
Guid=5DAD9B46-43BB-42D2-91E9-F2248369AA68 Win64=no
RegistryValue Id=x86PFWConfigRegValue Root=HKLM
Key=SOFTWARE\[Manufacturer] Name=ConfigPath Value=[CONFIG]
Type=string /
/Component
Component Id=x64RegEntPFWConfig
Guid=57240178-4A44-4C6F-A11C-B4DE99573DE0 Win64=yes
RegistryValue Id=x64PFWConfigRegValue Root=HKLM
Key=SOFTWARE\[Manufacturer] Name=ConfigPath Value=[CONFIG]
Type=string /
/Component
/Directory
/Directory
/Directory
/Directory
The heat harvests directories from a location D:\Configrelease which
has directories such as command_processors. The produces
config.wxs file that has below structure:
Fragment
DirectoryRef Id=CONFIG
Component Id=cmpC405575C36944E434C00DCE528FA79EA
Guid={0EDAF860-B5C3-4C93-BDD7-EB1947D94749}
File Id=fil62BA9BFC68F4D3C2DE913D9ABFEDC429
KeyPath=yes Source=$(var.ConfigPath)\PFWConfiguration.xml /
/Component
Directory Id=dirB9FCE785B12AD5549EC71DC5DC66ED48
Name=archives
/Directory
Directory Id=dirB8C0CFD798C8A57234B0C04A4E266B86
Name=command_processors
Component Id=cmpE03A5A54FF75ABF0FA6DA591BC4F3152
Guid={F2158D98-1DC2-4348-89FC-65A2115084B6} KeyPath=yes
CreateFolder /
/Component
After i run the installer, i browse to C:\Energy Solutions
International\PFWService\config\command_processors and keep this
path open, and then uninstall the directory structure that does not
get removed is C:\Energy Solutions International\PFWService.
Is it because of the CreateFolder in the config.wxs(as Wesley had
suggest) file that heat creates that i am facing this issue. If so
what is the way out. Hope i have explained the situation better this
time, apologies if i created any confusion.
Regards,
SuvraJyoti
On 17-12-2013 14:27, Suvrajyoti Panda wrote:
Hey Blair,
The scenario you have mentioned in the first para of your response
is exactly what is happening. So is there no way that we can handle
the folder removal on uninstall even if that path is open, or this
is a known issue?
Regards,
SuvraJyoti
On 17-12-2013 14:14, Blair Murri wrote:
If a file being removed can't be moved, then it will be marked for
removal during reboot, and unfortunately the folder will then be
left behind (because only file delete records are placed into the
reboot sequence, not folders). After reboot there isn't an
installation left to run to cleanup any further.
Most of the time, files still in use can be moved (even if they
are
still loaded in other
