Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
MSI doesn't write to RunOnce because it is a system service that came
installed in the operating system. Pretty much all bootstrappers/chainers
will write to RunOnce if they need to do a reboot and come back
afterwards. Burn goes one step further to ensure robustness and registers
up front.
We'll need to teach this anti-virus program about Burn. Fortunately big
programs, like Visual Studio, are using Burn and if it kills them I hope we
can muster some change.
On Wed, Jan 11, 2012 at 11:50 PM, NIkolaj Steensgaard n...@panorama9.comwrote:
On 01/11/2012 01:23 PM, Peter Hull wrote:
Hi Nikolaj!
Could you comment on whether your installer was signed (the bundle and
the actual engine which is unpacked out of it - see this link
https://sourceforge.net/mailarchive/forum.php?thread_name=CAHdHTVc1c2h3QuYsiXWcR8A1Xtk38Z3W2KCyAvuP3hMjYqKAiA%40mail.gmail.comforum_name=wix-users)
Yes the Bundle is signed with Thawte code signing certificate and also
the engine ( msi ) included is signed with same certificate.
I'm glad someone else has seen this problem, especially as you have more
control over your environment than I do!
Me 2 as it is quite a problem not being able to install a exe created
from Wix 3.6.
Does anyone have a Idea how to debug this issue ?
The MSI itself does not write to the RunOnce as far as i know
Peter
Date: Wed, 11 Jan 2012 12:16:37 +0100
From: n...@panorama9.com
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
We have built a EXE with Wix 3.6 beta which are detected by Trend Micro
as Malware behavior and
we are looking for the reason for this.
This is the log entry from Trend Micro
---
Malware behavior blocking Terminate Registry High
C:\Documents and Settings\administrator.ADTEST\Local
Settings\Temp\{044fc46d-90ff-4769-9c96-28a774dcbd7a}\.be\copy-yvxrlsay.iz2-P9Agent.exe
Write
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\{044fc46d-90ff-4769-9c96-28a774dcbd7a}
---
Snip from previous case:
---
Burn-based installers trigger Trend OfficeScan (v.10.5) when they write
to the RunOnce registry key.
The virus checker terminates the installer immediately.
---
We have a complete testing enviroment where we can tweak, monitor and
reproduce this error and are more than
willing to assist in debugging this issue.
Please let me know anything we can provide to debug and solve this
Regards
Nikolaj Steensgaard
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
complex
infrastructure or vast IT resources to deliver seamless, secure access
to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI
infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
virtually, Rob Mensching - http://RobMensching.com LLC
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
From: r...@robmensching.com We'll need to teach this anti-virus program about Burn. Fortunately big programs, like Visual Studio, are using Burn and if it kills them I hope we can muster some change. So are you saying we need to raise this as an issue with Trend Micro? Is the program that actually writes the registry always the same? (I'm a bit confused about what the stages are when a burn exe is run, particularly what the burn engine is and what the burn agent is) Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Signing the burn bootstrapper
To sign the bundle and bundle engine you need to add the following to your .wixproj: Add SignOutputtrue/SignOutput to a PropertyGroup Implement the targets like this: Target Name=SignBundleEngine SignFile TimestampUrl=... CertificateThumbprint=... SigningTarget=@(SignBundleEngine) / /Target Target Name=SignBundle SignFile TimestampUrl=... CertificateThumbprint=... SigningTarget=@(SignBundle) / /Target You need to put these _after_ the Import Project=$(WixTargetsPath) / Alternatively you can use Exec Command='signtool.exe sign ...' / for more control. There is also a SignContainers target but I don't know quite what it does. When buiding MSIs, to sign them you need to implement Target Name=SignMsi If you have external CABs then also implement Target Name=SignCabs The things you need to sign are in an itemgroup with the same name as the target (e.g. @(SignMsi)) Note that you can't use the SignFile task for this, as it will only sign exes and dlls. You have to use Exec Command=signtool sign ... / Hope that helps, Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version
When examining the files with an administrative install, the files in the two .msi files are definitely different. When I change the file size of the text file, the file is included in the patch. But if the file size is the same as the file size of the original file, it isn't included into the patch. As far as I can see now, torch.exe does the following: 1. If a file has a version (.exe, .dll), that version is checked to determine if the file has changed. 2. If a file has no version, it is simply checked if the file size has changed. If the size is unchanged, the file is considered as unchanged. This appears to me to be a bug in torch.exe. I would try to find and fix this bug in torch.exe now as I really need to reliably create patches. Besides this, I think that in Wix 3.6 Beta, the patch creation is broken (torch.exe or pyro.exe). When I apply the 3.6 toolset to the same files which successfully created a patch file with WIX 3.5, I get an warning about an empty cabinet. -Ursprüngliche Nachricht- Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Gesendet: Mittwoch, 11. Januar 2012 13:13 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version It all looks reasonable. I'd probably go back and examine the text file in the 2 MSIs that you're building the patch from. It could be a build problem. Do an administrative install of both MSIs and the version of the text file from each admin install. -Original Message- From: Ulrich Proeller [mailto:ulr...@prosa.biz] Sent: 11 January 2012 11:29 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version I think that the patch doesn't include this text file. At least ORCA shows only the file Szenariorechner.exe to be changed by the patch. The file Version.txt is marked as unchanged. -Ursprüngliche Nachricht- Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Gesendet: Mittwoch, 11. Januar 2012 12:21 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version I'd generate a verbose log while installing the patch to try and work out why the text file is not updated. The product version is just a property like any other and often seems not to be mentioned specially. That confused me when I wrote my first patch. -Original Message- From: Ulrich Proeller [mailto:ulr...@prosa.biz] Sent: 11 January 2012 11:00 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version Thank you, this helps me a huge step forward. Referencing the ProductVersion changes the version as desired. Is this written in any documentation/book and I have overlooked it? And I didn't know about the View Patch feature in Orca. This makes life a lot easier! My patch family now looks like this: PatchFamily Id='pfSzenariorechner' Version='1.2.7.0' Supersede='yes' ComponentRef Id=Szenariorechner / PropertyRef Id=ProductVersion/ ComponentRef Id=VersionFile / /PatchFamily However, the text file with the version string is still not replaced. This is a separate component, in the same component group as the managed assembly and both are in the same fragment. I read that it should be enough to reference one component in each fragment to trigger the inclusion of all components in that fragment. Nevertheless, even referencing it explicitly doesn't help. Below, you see the definition of the mentioned fragment: Fragment ComponentGroup Id=Szenariorechner Component Id=Szenariorechner Guid=c447f464-15ac-4dc3-8456-623197bd6a71 Directory=INSTALLFOLDER File Id=Szenariorechner.exe Name=$(var.Szenariorechner.TargetFileName) Vital='yes' Checksum='yes' AssemblyApplication='Szenariorechner.exe' Source=$(var.Szenariorechner.TargetPath) DiskId=1 Assembly='.net' KeyPath=yes netfx:NativeImage Id=ngen.Szenariorechner Platform=all Priority=1 AppBaseDirectory=INSTALLFOLDER/ /File File Id=Szenariorechner.exe.config Name=$(var.Szenariorechner.TargetFileName).config Vital='yes' Source=$(var.Szenariorechner.TargetPath).config DiskId=1 / File Id='Szenariorechner.ico' Name='Szenariorechner.ico' Vital='yes' Source='$(var.Szenariorechner.ProjectDir)Resources\favicon.ico' DiskId='1' / /Component Component Id='VersionFile' Guid='037d742c-583f-414b-acad-f99907a4b7d1' Directory=INSTALLFOLDER File Id=FILE_Version Source=$(var.Szenariorechner.TargetDir)Version.txt KeyPath=yes / /Component /ComponentGroup ComponentGroup Id='Shortcuts' . /ComponentGroup ComponentGroup Id=Telerik /ComponentGroup ComponentGroup Id=Misc
Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
On 01/12/2012 09:46 AM, Peter Hull wrote: From: r...@robmensching.com We'll need to teach this anti-virus program about Burn. Fortunately big programs, like Visual Studio, are using Burn and if it kills them I hope we can muster some change. So are you saying we need to raise this as an issue with Trend Micro? I have been trying to debug this issue to answer that exact question ! Is the program that actually writes the registry always the same? (I'm a bit confused about what the stages are when a burn exe is run, particularly what the burn engine is and what the burn agent is) I will explain the issue more detailed to better give insight in what we are seeing. For about year we have been deploying our software build with the WIX installer as a MSI package and have not seen this issue. To Months ago we created a Bundled version ( exe build with WIX 3.6 ) that checked for .net 3.51 + Win install 3.1 and installed if needed before installing our software Then we got reports from client's about this issue occurring The Bundled version is quite simple and only checks for the above mentioned software and downloads / installs if needed A complete AD with Trend Micro Office Scan were established to reproduce the error which we can. Some things that we so far have noticed : It only seem to occur on Windows XP for some reason. ( this machine already have the needed .net and Win install so it's not there installer that's creates the problem ) Our Code does not at anytime write or read from the RunOnce key Also as the previous reporter of this issue ( ID: 3431068 ) We will be trying to use SysInternals tools to get a debug of whats happening when the issue occurs, and post the result here. Hope this helps in explaining the issue we are seeing and we are more that happy to run any test's you suggest !!! Nik Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version
Can you verify this by producing a minimum test case ? Create an MSI with just 1 text file and an upgrade and a patch from that. It might help you narrow down what's going wrong. The .wixmst produced by torch is an xml file containing all the changes between the two inputs, even if they are not referenced by the patch wxs file. It might be worth looking through it for your text file name. It should be in there. -Original Message- From: Ulrich Proeller [mailto:ulr...@prosa.biz] Sent: 12 January 2012 09:34 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version When examining the files with an administrative install, the files in the two .msi files are definitely different. When I change the file size of the text file, the file is included in the patch. But if the file size is the same as the file size of the original file, it isn't included into the patch. As far as I can see now, torch.exe does the following: 1. If a file has a version (.exe, .dll), that version is checked to determine if the file has changed. 2. If a file has no version, it is simply checked if the file size has changed. If the size is unchanged, the file is considered as unchanged. This appears to me to be a bug in torch.exe. I would try to find and fix this bug in torch.exe now as I really need to reliably create patches. Besides this, I think that in Wix 3.6 Beta, the patch creation is broken (torch.exe or pyro.exe). When I apply the 3.6 toolset to the same files which successfully created a patch file with WIX 3.5, I get an warning about an empty cabinet. -Ursprüngliche Nachricht- Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Gesendet: Mittwoch, 11. Januar 2012 13:13 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version It all looks reasonable. I'd probably go back and examine the text file in the 2 MSIs that you're building the patch from. It could be a build problem. Do an administrative install of both MSIs and the version of the text file from each admin install. -Original Message- From: Ulrich Proeller [mailto:ulr...@prosa.biz] Sent: 11 January 2012 11:29 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version I think that the patch doesn't include this text file. At least ORCA shows only the file Szenariorechner.exe to be changed by the patch. The file Version.txt is marked as unchanged. -Ursprüngliche Nachricht- Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Gesendet: Mittwoch, 11. Januar 2012 12:21 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version I'd generate a verbose log while installing the patch to try and work out why the text file is not updated. The product version is just a property like any other and often seems not to be mentioned specially. That confused me when I wrote my first patch. -Original Message- From: Ulrich Proeller [mailto:ulr...@prosa.biz] Sent: 11 January 2012 11:00 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version Thank you, this helps me a huge step forward. Referencing the ProductVersion changes the version as desired. Is this written in any documentation/book and I have overlooked it? And I didn't know about the View Patch feature in Orca. This makes life a lot easier! My patch family now looks like this: PatchFamily Id='pfSzenariorechner' Version='1.2.7.0' Supersede='yes' ComponentRef Id=Szenariorechner / PropertyRef Id=ProductVersion/ ComponentRef Id=VersionFile / /PatchFamily However, the text file with the version string is still not replaced. This is a separate component, in the same component group as the managed assembly and both are in the same fragment. I read that it should be enough to reference one component in each fragment to trigger the inclusion of all components in that fragment. Nevertheless, even referencing it explicitly doesn't help. Below, you see the definition of the mentioned fragment: Fragment ComponentGroup Id=Szenariorechner Component Id=Szenariorechner Guid=c447f464-15ac-4dc3-8456-623197bd6a71 Directory=INSTALLFOLDER File Id=Szenariorechner.exe Name=$(var.Szenariorechner.TargetFileName) Vital='yes' Checksum='yes' AssemblyApplication='Szenariorechner.exe' Source=$(var.Szenariorechner.TargetPath) DiskId=1 Assembly='.net' KeyPath=yes netfx:NativeImage Id=ngen.Szenariorechner Platform=all Priority=1 AppBaseDirectory=INSTALLFOLDER/ /File File Id=Szenariorechner.exe.config Name=$(var.Szenariorechner.TargetFileName).config Vital='yes'
Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version
Examining the .wixmst confirms my suspicion: If the file size has changed, the file is marked as modified in the .wixmst, else the file has no such markup. -Ursprüngliche Nachricht- Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Gesendet: Donnerstag, 12. Januar 2012 10:51 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version Can you verify this by producing a minimum test case ? Create an MSI with just 1 text file and an upgrade and a patch from that. It might help you narrow down what's going wrong. The .wixmst produced by torch is an xml file containing all the changes between the two inputs, even if they are not referenced by the patch wxs file. It might be worth looking through it for your text file name. It should be in there. -Original Message- From: Ulrich Proeller [mailto:ulr...@prosa.biz] Sent: 12 January 2012 09:34 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version When examining the files with an administrative install, the files in the two .msi files are definitely different. When I change the file size of the text file, the file is included in the patch. But if the file size is the same as the file size of the original file, it isn't included into the patch. As far as I can see now, torch.exe does the following: 1. If a file has a version (.exe, .dll), that version is checked to determine if the file has changed. 2. If a file has no version, it is simply checked if the file size has changed. If the size is unchanged, the file is considered as unchanged. This appears to me to be a bug in torch.exe. I would try to find and fix this bug in torch.exe now as I really need to reliably create patches. Besides this, I think that in Wix 3.6 Beta, the patch creation is broken (torch.exe or pyro.exe). When I apply the 3.6 toolset to the same files which successfully created a patch file with WIX 3.5, I get an warning about an empty cabinet. -Ursprüngliche Nachricht- Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Gesendet: Mittwoch, 11. Januar 2012 13:13 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version It all looks reasonable. I'd probably go back and examine the text file in the 2 MSIs that you're building the patch from. It could be a build problem. Do an administrative install of both MSIs and the version of the text file from each admin install. -Original Message- From: Ulrich Proeller [mailto:ulr...@prosa.biz] Sent: 11 January 2012 11:29 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version I think that the patch doesn't include this text file. At least ORCA shows only the file Szenariorechner.exe to be changed by the patch. The file Version.txt is marked as unchanged. -Ursprüngliche Nachricht- Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Gesendet: Mittwoch, 11. Januar 2012 12:21 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version I'd generate a verbose log while installing the patch to try and work out why the text file is not updated. The product version is just a property like any other and often seems not to be mentioned specially. That confused me when I wrote my first patch. -Original Message- From: Ulrich Proeller [mailto:ulr...@prosa.biz] Sent: 11 January 2012 11:00 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version Thank you, this helps me a huge step forward. Referencing the ProductVersion changes the version as desired. Is this written in any documentation/book and I have overlooked it? And I didn't know about the View Patch feature in Orca. This makes life a lot easier! My patch family now looks like this: PatchFamily Id='pfSzenariorechner' Version='1.2.7.0' Supersede='yes' ComponentRef Id=Szenariorechner / PropertyRef Id=ProductVersion/ ComponentRef Id=VersionFile / /PatchFamily However, the text file with the version string is still not replaced. This is a separate component, in the same component group as the managed assembly and both are in the same fragment. I read that it should be enough to reference one component in each fragment to trigger the inclusion of all components in that fragment. Nevertheless, even referencing it explicitly doesn't help. Below, you see the definition of the mentioned fragment: Fragment ComponentGroup Id=Szenariorechner Component Id=Szenariorechner Guid=c447f464-15ac-4dc3-8456-623197bd6a71 Directory=INSTALLFOLDER File Id=Szenariorechner.exe
Re: [WiX-users] Patching
1. There are a couple of ways that might work for you. It depends if you have to stick with your current upgrade strategy or if you have an opportunity to alter it. Firstly, most people find that producing major upgrade MSIs is by far the easiest way to support upgrades. You cant apply these out of order though. This blog post describes your scenario http://blogs.msdn.com/b/heaths/archive/2006/06/14/cumulative-service-packs-wi th-minorupdatetargetrtm.aspx This also won't allow you to apply patches out of order. You can apply a later patch first but, being cumulative, the earlier patch is included. It does however simplify the problem of supporting a product with many possible combinations of patches involved. You could also create patches that target multiple versions of the MSI. That fits your requirement better but problem with those is that, if you produce many patches that can be applied in any order, the number of possible installed products that need to be targeted increases rapidly. This increases patch size and testing complexity. If the patches are independent and don't change the product version, that may not be a problem. I believe you could also create small updates that do not alter the product version and could be combined freely. As long as all your files are versioned and backwards compatible, then you could mix these freely and the MSI versioning rules would always ensure the highest is installed. The number of possible combinations you allow could grow quickly and will be inherently tricky to support. Finding the best solution is really only something you can decide, knowing what your constraints are. Whatever you decide on, you should definitely make some test patches. I also strongly recommend reading the MS whitepaper. Its long and dry but explains many ways in which you can use patching and has some example scenarios too. 3. I think heat automatically generates components in fragments unless you use the -sfrag switch. Torch works with all kinds of files. Windows Installer works best if your executable files have a version resource that specifies the file version but it'll will handle unversioned binaries too. -Original Message- From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] Sent: 11 January 2012 23:09 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patching Thanks for the information Peter. Some follow up: 1) In previous versions of our app, we distributed patches to the customer as a set of files in a zip that the customer simply unzips into the application directory. While this isn't ideal (because of the problems associated with uninstalling patches etc.) it is very flexible in that we can distribute any number of patches that are not dependant on each other, and the customer can install and test the features in any order. For example, If we deliver patch P1 and P2 to the customer in that order, they may decide to install P2 first because it requires a smaller test effort than P1. I'm not sure how I achieve the same using the MSI patching. Let's say we have 3 wixpdb files: mainprod.wixpdb, patch1.wixpdb, patch2.wixpdb. When release Patch1 we use the transform (mainprod-patch1). Then we release patch2 which is not dependant on patch1 so we use the transforms (mainprod-patch2 and patch1-patch2) to generate it. But that wouldn't work if the customer decided to install patch2 first and then patch1 would it? Might be that i'm missing something obvious here! 3) I think I prefer to segment my components into different fragments and use the wixpdb to generate the mappings as doing admin install is a bit of a pain and potentially more error prone for us. Does anyone know if there is an easy way to do this (eg, if I harvest files using heat for my initial release, can it generate a different fragment for each component?). Another question and potential issue I thought of: Most of the files we distribute are binary (PowerBuilder) files. Will torch be able to generate the transform correctly for these? thanks sanjay -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 11 January 2012 10:49 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching I'll try and answer this but it's best to seek some other opinions too. 1. The order of patch installation wont usually matter. When you create a patch, you target it at a particular version or even multiple versions (eg patched/upgraded installations) and MSI works out the right sequence. See the MS patching whitepaper at http://www.microsoft.com/download/en/details.aspx?id=19013 You do this by creating one or more transforms (diffs) with the torch tool and passing them when you create the patch with pyro. 2. The 4th version field of the MSI product version is ignored by Windows installer. You can use it for information but we don't - some APIs will retrieve the 4th field however. We
Re: [WiX-users] Run exe in BinaryTable from custom action dll
See this thread http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Extract-Binarie s-at-Install-Time-td2301189.html#a2314132 -Original Message- From: Naim Kingston [mailto:naim.kings...@ancamotion.com] Sent: 12 January 2012 05:35 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Run exe in BinaryTable from custom action dll Hey, I have a 3rd party executable to detect some hardware, and since it's a general purpose exe, not detecting the hardware isn't a condition that has the exe return a failure (I guess, to be expected and completely fair). So, in order to determine whether the hardware I'm looking for is present on the system, I need to be able to catch the output that this exe outputs to the standard output stream, so I'm trying to create a C# custom action dll to run the exe using System.Diagnostics.Process and redirect its output to a string where I can parse it to look for certain values to ensure the hardware is present and correctly configured. My problem is that the tool isn't going to be present on the system prior to installation, and actually isn't needed by the final product, only to determine the hardware state of the machine to make a decision on what to install (which will actually be one of two other msi files, but running multiple msi files is a problem for another day), so it's not going to be installed with the rest of the product. So, I've used the Binary tag to embed the exe into the installer, and I can run it directly via custom action, but how do I run it from a dll custom action? Can I somehow access it and run it while embedded? Or do I need to write it out to the temp folder, run it, and then delete it? And then, I need to set a variable or property so the data will be passed back to the installer from the dll custom action. But running the embedded exe from a custom action is what's giving me issues right now. Has anyone done anything like this before? I've tried googling for most of the day but haven't found anything particularly useful. -Naim - - RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Insignia in 3.6
From: r...@robmensching.com Date: Wed, 11 Jan 2012 07:55:13 -0800 That looks right. Please file a bug if the command-line help wasn't helpful. OK, bug 3472564. I've also attached a patch to the bug report - hopefully you can use it as a starting point at least. Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Signing the burn bootstrapper
Hi, I haven't started using burn yet - but I'd like to - and signing will be an issue for us. At the moment, I hand an unsigned MSI over to the release manager for signing. He is the only person with access to the certificate. Can we still do this with burn? From what I've seen of this discussion so far, I must sign as part of the build process - something that will cause us a bit of an issue. Is that right? -Nick -Original Message- From: Peter Hull [mailto:peterhul...@hotmail.com] Sent: 12 January 2012 08:58 To: WiX Users Subject: Re: [WiX-users] Signing the burn bootstrapper To sign the bundle and bundle engine you need to add the following to your .wixproj: Add SignOutputtrue/SignOutput to a PropertyGroup Implement the targets like this: Target Name=SignBundleEngine SignFile TimestampUrl=... CertificateThumbprint=... SigningTarget=@(SignBundleEngine) / /Target Target Name=SignBundle SignFile TimestampUrl=... CertificateThumbprint=... SigningTarget=@(SignBundle) / /Target You need to put these _after_ the Import Project=$(WixTargetsPath) / Alternatively you can use Exec Command='signtool.exe sign ...' / for more control. There is also a SignContainers target but I don't know quite what it does. When buiding MSIs, to sign them you need to implement Target Name=SignMsi If you have external CABs then also implement Target Name=SignCabs The things you need to sign are in an itemgroup with the same name as the target (e.g. @(SignMsi)) Note that you can't use the SignFile task for this, as it will only sign exes and dlls. You have to use Exec Command=signtool sign ... / Hope that helps, Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom action to search and replace text in a file?
Hi, I'm trying to find/replace text in an installed file without resorting to vbscript. It's not an XML or INI file. I've tried the TemplateFile action from the AppSecIn extensions on CodePlex, but it does not work in the way that I want. Does anybody have a C++ custom action dll for this they can share or point me to? Thanks, Dan -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
I would start by digitally signing your burn bundle. Most anti-virus software provides more leeway to signed executables. If your bundle is static, then you could also submit it to Trend Micro as a false positive. Most AV vendors will update their signatures to work around false positives in a timely manner. The RunOnce key, from what I read in Rob's response, is written to from the bundling framework of burn. It is done proactively rather than as needed. -Original Message- From: NIkolaj Steensgaard [mailto:n...@panorama9.com] Sent: Thursday, January 12, 2012 3:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068 On 01/12/2012 09:46 AM, Peter Hull wrote: From: r...@robmensching.com We'll need to teach this anti-virus program about Burn. Fortunately big programs, like Visual Studio, are using Burn and if it kills them I hope we can muster some change. So are you saying we need to raise this as an issue with Trend Micro? I have been trying to debug this issue to answer that exact question ! Is the program that actually writes the registry always the same? (I'm a bit confused about what the stages are when a burn exe is run, particularly what the burn engine is and what the burn agent is) I will explain the issue more detailed to better give insight in what we are seeing. For about year we have been deploying our software build with the WIX installer as a MSI package and have not seen this issue. To Months ago we created a Bundled version ( exe build with WIX 3.6 ) that checked for .net 3.51 + Win install 3.1 and installed if needed before installing our software Then we got reports from client's about this issue occurring The Bundled version is quite simple and only checks for the above mentioned software and downloads / installs if needed A complete AD with Trend Micro Office Scan were established to reproduce the error which we can. Some things that we so far have noticed : It only seem to occur on Windows XP for some reason. ( this machine already have the needed .net and Win install so it's not there installer that's creates the problem ) Our Code does not at anytime write or read from the RunOnce key Also as the previous reporter of this issue ( ID: 3431068 ) We will be trying to use SysInternals tools to get a debug of whats happening when the issue occurs, and post the result here. Hope this helps in explaining the issue we are seeing and we are more that happy to run any test's you suggest !!! Nik Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Possible bug in Lux
On 10-Jan-12 17:48, John Cooper wrote: Test NVPPTb.SetEditNetTcpBinding.Header failed with unknown operation. That's bad. But thanks for the repro! Can you file a bug on SF? -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Signing the burn bootstrapper
On 12-Jan-12 05:47, Nick Ball wrote: I haven't started using burn yet - but I'd like to - and signing will be an issue for us. At the moment, I hand an unsigned MSI over to the release manager for signing. He is the only person with access to the certificate. Can we still do this with burn? From what I've seen of this discussion so far, I must sign as part of the build process - something that will cause us a bit of an issue. Is that right? You can't just sign the final output; you have to sign the bits that make up the bundle. But you can make signing a separate project that uses WiX just to assemble the signed bits into a bundle. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Generated MSI Name
I see that it's set in the Designer as Output Name which is a MSBuild Property. Is there any way (other than having the build edit the .wixproj or copy/rename after the it's generated) to change the output MSI? Thanks Daniel P. Sniderman| Sr Consultant| Magenic MCSD.NET, MCTS: Team Foundation Server 2010 Administration 333 E. Butterfield Rd. Suite 100, Lombard, IL 60148 Mobile: 847-668-4882 | eFax 847-390-7810 magenic.com | dani...@magenic.commailto:dani...@magenic.com -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version
On 11-Jan-12 03:00, Ulrich Proeller wrote: The switch -sf in the pyro command was added the get rid of a duplicate key error. That's likely the root cause of your problem. Fix the underlying bug before trying workarounds. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Possible bug in Lux
Sure. I'll get on it right after lunch. -- John M. Cooper -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Thursday, January 12, 2012 8:39 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Possible bug in Lux On 10-Jan-12 17:48, John Cooper wrote: Test NVPPTb.SetEditNetTcpBinding.Header failed with unknown operation. That's bad. But thanks for the repro! Can you file a bug on SF? -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Possible bug in Lux
Bug is 3473007. -- John M. Cooper -Original Message- From: John Cooper Sent: Thursday, January 12, 2012 11:43 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Possible bug in Lux Sure. I'll get on it right after lunch. -- John M. Cooper -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Thursday, January 12, 2012 8:39 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Possible bug in Lux On 10-Jan-12 17:48, John Cooper wrote: Test NVPPTb.SetEditNetTcpBinding.Header failed with unknown operation. That's bad. But thanks for the repro! Can you file a bug on SF? -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Generated MSI Name
How do you want to generate your name? This will determine how we change OutputName. OutputName is just a MSBuild property but one that is used by all project types. I believe (but have not verified) that if you build your solution from the command line providing a different value for OutputName you'll end up with all of your projects in that solution with the same name. msbuild sample.sln /p:OutputName=GeneratedName /t:build You'll probably want to define a new custom property in your .wixproj so that you can change only the OutputName in the .wixproj. Project ... PropertyGroup ... SetupNameDefaultValue/SetupName OutputName$(SetupName)/OutputName ... /PropertyGroup ... /Project In the sample above I define a new property, SetupName, before OutputName. I use the value of SetupName as the value for OutputName. Note that you'll need to hand edit the .wixproj. Now we should be able to set SetupName on the command line to whatever generated name we want and not affect OutputName for any other projects. msbuild sample.sln /p:SetupName=GeneratedName /t:build This all assumes that the name is generated before the solution begins building. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Daniel Sniderman [mailto:dani...@magenic.com] Sent: Thursday, January 12, 2012 9:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Generated MSI Name I see that it's set in the Designer as Output Name which is a MSBuild Property. Is there any way (other than having the build edit the .wixproj or copy/rename after the it's generated) to change the output MSI? Thanks Daniel P. Sniderman| Sr Consultant| Magenic MCSD.NET, MCTS: Team Foundation Server 2010 Administration 333 E. Butterfield Rd. Suite 100, Lombard, IL 60148 Mobile: 847-668-4882 | eFax 847-390-7810 magenic.com | dani...@magenic.commailto:dani...@magenic.com -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Generated MSI Name
The name would probably include the Configuration and version information . However this would be part of a TFS 2010 Build - so passing an argument to MSBuild is supported. Thanks - this is very helpful. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, January 12, 2012 12:02 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Generated MSI Name How do you want to generate your name? This will determine how we change OutputName. OutputName is just a MSBuild property but one that is used by all project types. I believe (but have not verified) that if you build your solution from the command line providing a different value for OutputName you'll end up with all of your projects in that solution with the same name. msbuild sample.sln /p:OutputName=GeneratedName /t:build You'll probably want to define a new custom property in your .wixproj so that you can change only the OutputName in the .wixproj. Project ... PropertyGroup ... SetupNameDefaultValue/SetupName OutputName$(SetupName)/OutputName ... /PropertyGroup ... /Project In the sample above I define a new property, SetupName, before OutputName. I use the value of SetupName as the value for OutputName. Note that you'll need to hand edit the .wixproj. Now we should be able to set SetupName on the command line to whatever generated name we want and not affect OutputName for any other projects. msbuild sample.sln /p:SetupName=GeneratedName /t:build This all assumes that the name is generated before the solution begins building. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Daniel Sniderman [mailto:dani...@magenic.com] Sent: Thursday, January 12, 2012 9:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Generated MSI Name I see that it's set in the Designer as Output Name which is a MSBuild Property. Is there any way (other than having the build edit the .wixproj or copy/rename after the it's generated) to change the output MSI? Thanks Daniel P. Sniderman| Sr Consultant| Magenic MCSD.NET, MCTS: Team Foundation Server 2010 Administration 333 E. Butterfield Rd. Suite 100, Lombard, IL 60148 Mobile: 847-668-4882 | eFax 847-390-7810 magenic.com | dani...@magenic.commailto:dani...@magenic.com -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
On Thu, Jan 12, 2012 at 6:03 PM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: I would start by digitally signing your burn bundle. The bundle is already signed with a Thawte code signing certificate Most anti-virus software provides more leeway to signed executables. If your bundle is static, then you could also submit it to Trend Micro as a false positive. Most AV vendors will update their signatures to work around false positives in a timely manner. Yes, but our bundle is dynamic as the version of the software changes. The RunOnce key, from what I read in Rob's response, is written to from the bundling framework of burn. It is done proactively rather than as needed. So isn't that really the issue then ? Either should Trend Micro change there detection mechanism regarding the RunOnce key or the bundling framework of burn should change its default behavior . I have already tried to get in contact to Trend Micro through several channels without luck and have also submitted a request to get access to Reputation Service and Verification Portal (RSVP). Looking in the Trend Micro software there does'nt seem to be a way to turn the Malware detection feature -Original Message- From: NIkolaj Steensgaard [mailto:n...@panorama9.com] Sent: Thursday, January 12, 2012 3:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068 On 01/12/2012 09:46 AM, Peter Hull wrote: From: r...@robmensching.com We'll need to teach this anti-virus program about Burn. Fortunately big programs, like Visual Studio, are using Burn and if it kills them I hope we can muster some change. So are you saying we need to raise this as an issue with Trend Micro? I have been trying to debug this issue to answer that exact question ! Is the program that actually writes the registry always the same? (I'm a bit confused about what the stages are when a burn exe is run, particularly what the burn engine is and what the burn agent is) I will explain the issue more detailed to better give insight in what we are seeing. For about year we have been deploying our software build with the WIX installer as a MSI package and have not seen this issue. To Months ago we created a Bundled version ( exe build with WIX 3.6 ) that checked for .net 3.51 + Win install 3.1 and installed if needed before installing our software Then we got reports from client's about this issue occurring The Bundled version is quite simple and only checks for the above mentioned software and downloads / installs if needed A complete AD with Trend Micro Office Scan were established to reproduce the error which we can. Some things that we so far have noticed : It only seem to occur on Windows XP for some reason. ( this machine already have the needed .net and Win install so it's not there installer that's creates the problem ) Our Code does not at anytime write or read from the RunOnce key Also as the previous reporter of this issue ( ID: 3431068 ) We will be trying to use SysInternals tools to get a debug of whats happening when the issue occurs, and post the result here. Hope this helps in explaining the issue we are seeing and we are more that happy to run any test's you suggest !!! Nik Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Best Regards Nikolaj Steensgaard Panorama9 A/S Langebrogade 5 1411 Copenhagen K Phone: +45 7020 3565 Mobile: +45 2124 3040 n...@panorama9.com Panorama9 is an IT management platform that shows you everything you need to know about your assets, IT availability, security vulnerabilities, and non-compliant systems – from a single Dashboard that’s amazingly easy to monitor and interpret. Your organization can cut IT costs through improved uptime and as a cloud-based solution, there is no infrastructure to deploy or manage. For more information
[WiX-users] Copy Files from Bundle to Disk
Hey All, Is it possible to copy an .msi or .exe from within the bundle to the install location? I have a product included in my installer that I'd like to copy to the install location in case the user wishes to run that installer manually later. TIA, -- *Jammer* http://www.jammer.biz** -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
I have been working on a new install where a context menu is added to the Right-Click Menu within Internet Explorer. Everything I have read regarding this requires the key be added to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but the issue I have is that our installs are run as per-machine installs and this causes other users that login to not have this menu. Links to MSDN articles explaining context menu additions for Internet Explorer: http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx The wxs code is quite simple for this addition: RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName Value=[#FileID]/ RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName \Contexts Value=1/ Has anyone run into this or another issue where a per-machine install is performed but features or other items need to exist for all users in the above fashion? Thanks, Jon -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
The Registry element has a Root attribute that you can set to HKCU. If your program has an advertised shortcut you can use this to trigger resilency to complete the installation for each user who uses your app. It's an ugly story though like the old Office install that popped up every time you went to a new conference room and logged in. http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm Here's an alternative approach that avoids all that: http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-r epair-user-settings.html From: McCain, Jon jon.mcc...@inin.com Sent: Thursday, January 12, 2012 3:28 PM To: General discussion for Windows Installer XML toolset. (wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net Subject: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have been working on a new install where a context menu is added to the Right-Click Menu within Internet Explorer. Everything I have read regarding this requires the key be added to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but the issue I have is that our installs are run as per-machine installs and this causes other users that login to not have this menu. Links to MSDN articles explaining context menu additions for Internet Explorer: http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx The wxs code is quite simple for this addition: RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName Value=[#FileID]/ RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName \Contexts Value=1/ Has anyone run into this or another issue where a per-machine install is performed but features or other items need to exist for all users in the above fashion? Thanks, Jon -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
Or try applying the key to HKLM rather than HKCU in the first place. Many Windows settings can apply to either key to give you the flexibility of having each setting system-wide or per-user. On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.comwrote: The Registry element has a Root attribute that you can set to HKCU. If your program has an advertised shortcut you can use this to trigger resilency to complete the installation for each user who uses your app. It's an ugly story though like the old Office install that popped up every time you went to a new conference room and logged in. http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm Here's an alternative approach that avoids all that: http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-r epair-user-settings.html From: McCain, Jon jon.mcc...@inin.com Sent: Thursday, January 12, 2012 3:28 PM To: General discussion for Windows Installer XML toolset. (wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net Subject: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have been working on a new install where a context menu is added to the Right-Click Menu within Internet Explorer. Everything I have read regarding this requires the key be added to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but the issue I have is that our installs are run as per-machine installs and this causes other users that login to not have this menu. Links to MSDN articles explaining context menu additions for Internet Explorer: http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx The wxs code is quite simple for this addition: RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName Value=[#FileID]/ RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName \Contexts Value=1/ Has anyone run into this or another issue where a per-machine install is performed but features or other items need to exist for all users in the above fashion? Thanks, Jon -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
Then there's the case of Office AddIns that allowed either HKCU or HKLM in 2003, took away in 2007 ( and put it back with a hotfix and enabling registry value ) and really put it back in 2010 leaving one hell of a mess for us installer guys to deal with. So, yes, YMMV... in the event it really needs to be HKCU like the poster asserted then my response below will help. From: Dan Gough goug...@gmail.com Sent: Thursday, January 12, 2012 5:21 PM To: chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Or try applying the key to HKLM rather than HKCU in the first place. Many Windows settings can apply to either key to give you the flexibility of having each setting system-wide or per-user. On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.com wrote: The Registry element has a Root attribute that you can set to HKCU. If your program has an advertised shortcut you can use this to trigger resilency to complete the installation for each user who uses your app. It's an ugly story though like the old Office install that popped up every time you went to a new conference room and logged in. http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm Here's an alternative approach that avoids all that: http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-r epair-user-settings.html From: McCain, Jon jon.mcc...@inin.com Sent: Thursday, January 12, 2012 3:28 PM To: General discussion for Windows Installer XML toolset. (wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net Subject: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have been working on a new install where a context menu is added to the Right-Click Menu within Internet Explorer. Everything I have read regarding this requires the key be added to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but the issue I have is that our installs are run as per-machine installs and this causes other users that login to not have this menu. Links to MSDN articles explaining context menu additions for Internet Explorer: http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx The wxs code is quite simple for this addition: RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName Value=[#FileID]/ RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName \Contexts Value=1/ Has anyone run into this or another issue where a per-machine install is performed but features or other items need to exist for all users in the above fashion? Thanks, Jon -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Writing JDK version verification code, and Wix debugging tip
Wix MSI newbie here. My product requires JDK 1.6 installation, and I'm trying to come up with Wix code to verify the system has JDK 1.5 installed before proceeding installation of my product. I thought this would work: Property Id=JDKVER RegistrySearch Id=NetFramework20 Root=HKLM Key=SOFTWARE\JavaSoft\Java Development Kit Name=CurrentVersion Type=raw / /Property Condition Message=This application requires Java Developer Kit 1.5 (or higher). ![CDATA[Installed OR (JDKVER 1.5 )]] !-- test with 1.6, 1.7, 1.8, etc. will be added later. -- /Condition But this didn't work. Even if JDK 1.5 is installed, this message is displayed. Anybody has experience doing JDK version check? In an attempt to debug this, I wanted to display the value of property JDKVER, and inserted this code. This is a modified version of the code I've found in the Internet: CustomAction Id=ShowProperty Script=vbscript Execute=immediate ![CDATA[ MsgBox JDKVER = + Session.Property(JDKVER) ]] /CustomAction InstallExecuteSequence Custom Action=ShowProperty Before=InstallFinalizeTrue/Custom !-- Not Installed didn't work either. -- /InstallExecuteSequence But no popup came out. What am I doing wrong here? Thank you in advance. T. Kuro Kurosaka -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip
My memory of the way Java stores there version information in the registry isn't very friendly to MSI's RegLocator pattern. You might need a custom action. From: T. Kuro Kurosaka k...@basistech.com Sent: Thursday, January 12, 2012 6:21 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Writing JDK version verification code, and Wix debugging tip Wix MSI newbie here. My product requires JDK 1.6 installation, and I'm trying to come up with Wix code to verify the system has JDK 1.5 installed before proceeding installation of my product. I thought this would work: Property Id=JDKVER RegistrySearch Id=NetFramework20 Root=HKLM Key=SOFTWARE\JavaSoft\Java Development Kit Name=CurrentVersion Type=raw / /Property Condition Message=This application requires Java Developer Kit 1.5 (or higher). ![CDATA[Installed OR (JDKVER 1.5 )]] !-- test with 1.6, 1.7, 1.8, etc. will be added later. -- /Condition But this didn't work. Even if JDK 1.5 is installed, this message is displayed. Anybody has experience doing JDK version check? In an attempt to debug this, I wanted to display the value of property JDKVER, and inserted this code. This is a modified version of the code I've found in the Internet: CustomAction Id=ShowProperty Script=vbscript Execute=immediate ![CDATA[ MsgBox JDKVER = + Session.Property(JDKVER) ]] /CustomAction InstallExecuteSequence Custom Action=ShowProperty Before=InstallFinalizeTrue/Custom !-- Not Installed didn't work either. -- /InstallExecuteSequence But no popup came out. What am I doing wrong here? Thank you in advance. T. Kuro Kurosaka -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn bootstrapper administrator mode log file bug
I'm getting a strange bug where if I run a bootstrapper created with burn from an administrator command line prompt AND specify a log file, then the bootstrapper will hang before even opening up the UI. It's strange, running without a log file works fine from the administrator command line prompt, but attempting to use a log file causes it to hang and not return (for at least a couple of minutes). The bootstrapper in question is just to get used to burn and only installs 2 installers of 32kb each (a single, practically empty text file per installer). So, I'm assuming that's a bug of some sort? Is it already known? -Naim -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Signing the burn bootstrapper
Signing only the bundle would prove that it came from your organisation and hadn't been tampered with - would that be enough? When run it would unpack the unsigned burn engine and the unsigned MSIs. Does anyone know if that would show the user a warning (or multiple warnings?) Bob: would it be possible to have the burn engine signed (by Microsoft) in the released WiX 3.6 or have an option to specify the burn engine in the .wxs file - as I understand it you currently have to sign the burn engine every time the bundle is built, even though it's the same executable. Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
Date: Thu, 12 Jan 2012 20:56:15 +0100 From: n...@panorama9.com I would start by digitally signing your burn bundle. The bundle is already signed with a Thawte code signing certificate The reported file name looks more like it's the extracted engine than your bundle itself. Have you signed the engine. Either should Trend Micro change there detection mechanism regarding the RunOnce key or the bundling framework of burn should change its default behavior . From the Trend docs I saw it seemed to suggest that 'Malware Behaviour Monitoring' could be turned off (indeed, terminating programs like this was not the default) and also that signed executables were exempt. So it maybe is a bug in Trend that means it doesn't work as documented? The other thing is that other installers (InstallShield) don't seem to do this so does anyone understand how InstallShield handles the reboot issue? Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn: package ref-counting not working
Hi folks, as I read in the WiX 3.6 Beta release notes, burn does support package ref-counting now, which according to my understanding should guarantee, that shared packages are uninstalled only if all bundles sharing the packages were removed. Here is a little example: - install Bundle1(containing SharedPackage, Package1) - install Bundle2(containing SharedPackage, Package2) - uninstall Bundle1 -- results in removal of SharedPackage and Package1 I would expect that only Package1 gets removed. Am I just misunderstanding the feature or may I miss something in my bundle definitions? Best regards Christian -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-package-ref-counting-not-working-tp7183258p7183258.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
