Re: [WiX-users] Default regsearch values and upgrading
OKI've changed the package ID to the question marks and tried changing the 3rd field in the product versionran the installer again and now I get... Another version of this product is already installed. Installation of this version cannot continue. . More googling for me today then. Russ -- View this message in context: http://www.nabble.com/Default-regsearch-values-and-upgrading-tf4611878.html#a13188779 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Component Guids - Version Changes
The bit in Derek's article under Here's how it works explains how it works. It computes the full target path for the single file in the component (multiple files are not supported). It then generates the GUID as a hash of the full target path. That means that as long as you don't change the target path, the component GUID should be stable. The GUIDs are generated at link time, by the binder. You can find this code in SetComponentGuids() in src\wix\Binder.cs. This is called by BindDatabase after localization variable substitution has occurred (in ResolveFields()). Any localized variables [i.e. !(loc.Name)] will be replaced before computing the hash and hence the GUID. You should consider carefully whether to include any of these in the path to an installed file for a generated GUID. Service packs should generally write to the same location as the RTM release so the GUIDs should be stable and allow a patch to be built. In side-by-side environments for new major releases you would get new GUIDs as you would probably expect. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laxmi Narsimha Rao Oruganti (SQL CE) Sent: 12 October 2007 08:00 To: wix-users@lists.sourceforge.net Cc: SQL Server CE Setup Team Subject: [WiX-users] Component Guids - Version Changes Hey WIX Users, I am using WIXv3 3.0.2921 build. And I am able to use automatic component guid generation as stated by Derek in: http://installing.blogspot.com/2006/09/automatically-generating-component.ht ml I also understand that this is a new feature in WIXv3 and may not be stable enough to use. I have the following questions regarding this: 1) As component guids are generated for every build, if I just do a candle+light twice on my WIX code with just same binaries I get two different guids. Am I right? 2) When are these guids generated? At compile time OR link time? Candle time or light time? Because, we have a fragment which is locale independent one and needs to carry the same GUID across all locale specific MSIs where this fragment is absorbed. Hence, I am ok if it generates at compile/candle time. Can someone confirm? 3) Can component guids change across service packs for the same binary? That is, to generate a patch I will have a RTM MSI and then SP1 MSI which I diff using MSP related tools to get a msp. Since, RTM MSI and SP1 MSI have different GUIDs for same component (but same component id) how the MSP gets effected? Thanks a lot. Thanks, Laxmi - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Default regsearch values and upgrading
So the only way I seem to be able to get this to work is to change the product guid as well as the package guid. that doesn't seem right but it seems to work -- View this message in context: http://www.nabble.com/Default-regsearch-values-and-upgrading-tf4611878.html#a13189207 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Digitally signing packages
The DigitalCertificate element is for: a) validating signatures on external cabinets (presumably built separately with makecab); b) (MSI 3.0 and later) indicating the set of certificates which are allowed to sign patches that can be installed on a per-machine installation by non-privileged users (e.g. in UAC scenarios on Windows Vista, or as Standard User on Windows XP). For a) you create a DigitalCertificate (or DigitalCertificateRef) element under the appropriate Media element; for b) you list it under the PatchCertificates element. The Certificate element is for installing a certificate to one of the user or machine stores on the computer. In WiX 3.0 this is part of the IIS schema (predominantly used for installing server SSL certificates) but can be used even if you're not installing a website, for example you might want to install a self-signed corporate root certificate if you don't want to pay the signing tax for intranet servers ;) I don't think WiX has direct support for signing MSI files for the Attachment Security dialogs introduced in Windows XP SP2. Feel free to suggest it on the SourceForge suggestion tracker, if not already there ;) -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Ridd Sent: 09 October 2007 08:10 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Digitally signing packages The wix schema seems to have support for digitally signing packages - the DigitalCertificate element, the DigitalCertificateRef element - but I can't see how they're meant to be used. Presumably light has to have access to the certificate's private key at some point, and it isn't clear to me from the docs how it gets this. It also isn't clear what format the certificate's SourceFile has to be in. Is there a list somewhere of what CAs Microsoft trusts to issue code- signing certs? We're willing to pay the Verisign tax, but would be happier paying someone else for a cert as long as it is trusted identically... Cheers, Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Default regsearch values and upgrading
sorted it. http://www.nabble.com/file/p13190669/eProject.wxs eProject.wxs -- View this message in context: http://www.nabble.com/Default-regsearch-values-and-upgrading-tf4611878.html#a13190669 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Digitally signing packages
On 13 Oct 2007, at 13:56, Mike Dimmick wrote: The DigitalCertificate element is for: a) validating signatures on external cabinets (presumably built separately with makecab); b) (MSI 3.0 and later) indicating the set of certificates which are allowed to sign patches that can be installed on a per-machine installation by non-privileged users (e.g. in UAC scenarios on Windows Vista, or as Standard User on Windows XP). For a) you create a DigitalCertificate (or DigitalCertificateRef) element under the appropriate Media element; for b) you list it under the PatchCertificates element. OK, thanks for clarifying that. Those aren't what I'm trying to do, so it looks like signtool's the way to go. The Certificate element is for installing a certificate to one of the user or machine stores on the computer. In WiX 3.0 this is part of the IIS schema (predominantly used for installing server SSL certificates) but can be used even if you're not installing a website, for example you might want to install a self-signed corporate root certificate if you don't want to pay the signing tax for intranet servers ;) I guessed the purpose of the Certificate element correctly then :-) I don't think WiX has direct support for signing MSI files for the Attachment Security dialogs introduced in Windows XP SP2. Feel free to suggest it on the SourceForge suggestion tracker, if not already there ;) I couldn't see one, so I added 1812933. Cheers, Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Component Guids - Version Changes
Hey Mike, Thanks for the reply. Here is what I observed: 1)You are right about compile time Vs link time. The guids are generated at link time 2)The GUID is pretty much stable (rather same) across all MSI where a fragment (locale independent) is used. However, I still think that for performance reasons, the GUID getting generated at compile time is better. Don't know with whom I can discuss this and understand more why it is generated at link time if there is any genuine reason. Derek, can you shed some light here? (Got your id from the below blog post) 3)Yes you are right, in SxS story the directory path would generally change and the new GUIDs automatically generated than the old ones. Thanks, Laxmi From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Saturday, October 13, 2007 5:14 PM To: Laxmi Narsimha Rao Oruganti (SQL CE); wix-users@lists.sourceforge.net Cc: SQL Server CE Setup Team Subject: RE: [WiX-users] Component Guids - Version Changes The bit in Derek's article under Here's how it works explains how it works. It computes the full target path for the single file in the component (multiple files are not supported). It then generates the GUID as a hash of the full target path. That means that as long as you don't change the target path, the component GUID should be stable. The GUIDs are generated at link time, by the binder. You can find this code in SetComponentGuids() in src\wix\Binder.cs. This is called by BindDatabase after localization variable substitution has occurred (in ResolveFields()). Any localized variables [i.e. !(loc.Name)] will be replaced before computing the hash and hence the GUID. You should consider carefully whether to include any of these in the path to an installed file for a generated GUID. Service packs should generally write to the same location as the RTM release so the GUIDs should be stable and allow a patch to be built. In side-by-side environments for new major releases you would get new GUIDs as you would probably expect. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laxmi Narsimha Rao Oruganti (SQL CE) Sent: 12 October 2007 08:00 To: wix-users@lists.sourceforge.net Cc: SQL Server CE Setup Team Subject: [WiX-users] Component Guids - Version Changes Hey WIX Users, I am using WIXv3 3.0.2921 build. And I am able to use automatic component guid generation as stated by Derek in: http://installing.blogspot.com/2006/09/automatically-generating-component.html I also understand that this is a new feature in WIXv3 and may not be stable enough to use. I have the following questions regarding this: 1)As component guids are generated for every build, if I just do a candle+light twice on my WIX code with just same binaries I get two different guids. Am I right? 2)When are these guids generated? At compile time OR link time? Candle time or light time? Because, we have a fragment which is locale independent one and needs to carry the same GUID across all locale specific MSIs where this fragment is absorbed. Hence, I am ok if it generates at compile/candle time. Can someone confirm? 3)Can component guids change across service packs for the same binary? That is, to generate a patch I will have a RTM MSI and then SP1 MSI which I diff using MSP related tools to get a msp. Since, RTM MSI and SP1 MSI have different GUIDs for same component (but same component id) how the MSP gets effected? Thanks a lot. Thanks, Laxmi - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Component Guids - Version Changes
Laxmi Narsimha Rao Oruganti (SQL CE) wrote: *2)*The GUID is pretty much stable (rather same) across all MSI where a fragment (locale independent) is used. However, I still think that for performance reasons, the GUID getting generated at compile time is better. Don't know with whom I can discuss this and understand more why it is generated at link time if there is any genuine reason. Why do you think it's faster to generate at compile time? The reason the GUIDs are generated at bind time is that only at bind time is there all the information needed to generate the GUID. Generating stable component relies on hashing the path, which is usually not known at compile time. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
