Re: [WiX-users] COM+ registration help
I'll see if I can make a simple repro first and try and come up with some ideas. dmm - can you raise a defect so this is not lost? Any thoughts how to fix it? I hope we don't have to do the whole marshalling to a separate process that DTF does just to handle COM+ registration. That will be expensive. On Wed, Mar 20, 2013 at 2:44 PM, Neil Sleightholm n...@x2systems.comwrote: I have had a look at the WiX code and my suspicion is that it loads which ever version of the .NET framework is in the msiexec process space, so if .NET 2.0 (or 3.5) was first then that is how it loads the COM+ assembly therefore if yours if .NET 4.0 is won't work. I am not sure how that could be fixed. Could you try starting your msi and then using something like process explorer to see what version of .NET is loaded in the same process space as you msi? -Original Message- From: DexterSinister [mailto:dma...@nt4hire.com] Sent: 20 March 2013 21:23 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] COM+ registration help Yes, Neil ... RegSvcs works fine for either version of the DLL, installs fine ... uninstalls fine ... Weird, eh? I'm going to take a look at the ComPlus extension code to see if I can find any obvious reason why it's not working ... not familiar territory, but I may as well give it a shot ... Thanks, -dmm -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/COM-registr ation-help-tp7584402p7584501.html Sent from the wix-users mailing list archive at Nabble.com. - - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix v3.7 on win2008r2
Thanks for the answer. I have already enabled the .NET framework in the Management Console. Regards Michael Date: Thu, 21 Mar 2013 16:19:12 + From: Pally Sandher pally.sand...@iesve.com Subject: Re: [WiX-users] wix v3.7 on win2008r2 To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Message-ID: a7e25fadf831e94dbbd5904d7e5848652b0...@gl-exc-01.iesve.com Content-Type: text/plain; charset=us-ascii You're missing the .NET Framework. You need to install it from the Features add-in in the Management Console on Server 2008. It's not enabled by default. Palbinder Sandher Software Platform Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Michael Jeppesen [mailto:m...@force.dk] Sent: 21 March 2013 16:09 To: wix-users@lists.sourceforge.net Subject: [WiX-users] wix v3.7 on win2008r2 I have just installed wix on a win 2008R2 server in the default location When I try to run heat.exe (or any of the other tools) I get the following error: Unhandled Exception: System.TypeLoadException: Could not load type 'Microsoft.Tools.WindowsInstallerXml.ConsoleMessageHandler' from assembly 'wix, Ver sion=3.0.0.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad'. at Microsoft.Tools.WindowsInstallerXml.Tools.Heat..ctor() at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Main(String[] args) Anybody who knows what's is wrong ? Regards Michael -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to pass some arguments during major upgrade to obsoleted msi to prevent removing RegistryKey
Hi! I try to implement major upgrade and find some issue: Msi code has some action, wich write Property value to the registry: RegistryKey Root=HKLM Key=[UninstallKey][BUNDLEGUID] ForceCreateOnInstall=yes ForceDeleteOnUninstall=yes RegistryValue Id=WriteSomeValue Name=ValueName Value=[Value] Type=string / /RegistryKey I konw, that`s a wrong way, but it was already used. If I run my MBA to install or uninstall product, everything is ok, but when new version of the my msi start RemoveExistingProducts action, obsoleted msi is starting with no custom arguments(BundleVariables), it will cause removing the registry key [UninstallKey] wholly, because BUNDLEGUID property will be empty. Is some way available to pass some custom arguments to obsoleted msi? Alexey. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-pass-some-arguments-during-major-upgrade-to-obsoleted-msi-to-prevent-removing-RegistryKey-tp7584535.html Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM+ registration help
My COM+ experience is 10 years old but here's something I'm wondering: I wonder if what ever classes that are in System.Enterprise.Services ( or whatever that namespace is that was thrown around ) are really needed? Maybe those are just wrappers in .NET for the COMAdmin objects just like they created (unneeded) classes in .NET for installing Windows NT services. I'm wondering if like .NET Windows Services that perhaps there are useful classes for creating and hosting a COM+ application but that perhaps there are other classes that are less then truly needed. I don't care enough about COM+ to find out so just take that public thought as-is. From: Neil Sleightholm n...@x2systems.com Sent: Friday, March 22, 2013 2:46 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] COM+ registration help I'll see if I can make a simple repro first and try and come up with some ideas. dmm - can you raise a defect so this is not lost? Any thoughts how to fix it? I hope we don't have to do the whole marshalling to a separate process that DTF does just to handle COM+ registration. That will be expensive. On Wed, Mar 20, 2013 at 2:44 PM, Neil Sleightholm n...@x2systems.comwrote: I have had a look at the WiX code and my suspicion is that it loads which ever version of the .NET framework is in the msiexec process space, so if .NET 2.0 (or 3.5) was first then that is how it loads the COM+ assembly therefore if yours if .NET 4.0 is won't work. I am not sure how that could be fixed. Could you try starting your msi and then using something like process explorer to see what version of .NET is loaded in the same process space as you msi? -Original Message- From: DexterSinister [mailto:dma...@nt4hire.com] Sent: 20 March 2013 21:23 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] COM+ registration help Yes, Neil ... RegSvcs works fine for either version of the DLL, installs fine ... uninstalls fine ... Weird, eh? I'm going to take a look at the ComPlus extension code to see if I can find any obvious reason why it's not working ... not familiar territory, but I may as well give it a shot ... Thanks, -dmm -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/COM-registr ation-help-tp7584402p7584501.html Sent from the wix-users mailing list archive at Nabble.com. - - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to pass some arguments during major upgrade to obsoleted msi to prevent removing RegistryKey
You'll need this: http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern That is a really dangerous design, by the way. On Fri, Mar 22, 2013 at 4:26 AM, AK kisslo...@gmail.com wrote: Hi! I try to implement major upgrade and find some issue: Msi code has some action, wich write Property value to the registry: RegistryKey Root=HKLM Key=[UninstallKey][BUNDLEGUID] ForceCreateOnInstall=yes ForceDeleteOnUninstall=yes RegistryValue Id=WriteSomeValue Name=ValueName Value=[Value] Type=string / /RegistryKey I konw, that`s a wrong way, but it was already used. If I run my MBA to install or uninstall product, everything is ok, but when new version of the my msi start RemoveExistingProducts action, obsoleted msi is starting with no custom arguments(BundleVariables), it will cause removing the registry key [UninstallKey] wholly, because BUNDLEGUID property will be empty. Is some way available to pass some custom arguments to obsoleted msi? Alexey. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-pass-some-arguments-during-major-upgrade-to-obsoleted-msi-to-prevent-removing-RegistryKey-tp7584535.html Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM+ registration help
What do you mean, unneeded code for installing Windows services? What if the service is written in .net? Then the code is needed. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, March 22, 2013 9:24 AM To: General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM+ registration help My COM+ experience is 10 years old but here's something I'm wondering: I wonder if what ever classes that are in System.Enterprise.Services ( or whatever that namespace is that was thrown around ) are really needed? Maybe those are just wrappers in .NET for the COMAdmin objects just like they created (unneeded) classes in .NET for installing Windows NT services. I'm wondering if like .NET Windows Services that perhaps there are useful classes for creating and hosting a COM+ application but that perhaps there are other classes that are less then truly needed. I don't care enough about COM+ to find out so just take that public thought as-is. From: Neil Sleightholm n...@x2systems.com Sent: Friday, March 22, 2013 2:46 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] COM+ registration help I'll see if I can make a simple repro first and try and come up with some ideas. dmm - can you raise a defect so this is not lost? Any thoughts how to fix it? I hope we don't have to do the whole marshalling to a separate process that DTF does just to handle COM+ registration. That will be expensive. On Wed, Mar 20, 2013 at 2:44 PM, Neil Sleightholm n...@x2systems.comwrote: I have had a look at the WiX code and my suspicion is that it loads which ever version of the .NET framework is in the msiexec process space, so if .NET 2.0 (or 3.5) was first then that is how it loads the COM+ assembly therefore if yours if .NET 4.0 is won't work. I am not sure how that could be fixed. Could you try starting your msi and then using something like process explorer to see what version of .NET is loaded in the same process space as you msi? -Original Message- From: DexterSinister [mailto:dma...@nt4hire.com] Sent: 20 March 2013 21:23 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] COM+ registration help Yes, Neil ... RegSvcs works fine for either version of the DLL, installs fine ... uninstalls fine ... Weird, eh? I'm going to take a look at the ComPlus extension code to see if I can find any obvious reason why it's not working ... not familiar territory, but I may as well give it a shot ... Thanks, -dmm -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/COM-regi str ation-help-tp7584402p7584501.html Sent from the wix-users mailing list archive at Nabble.com. -- --- - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --- - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] FirewallException and WCF
I am building an installer for a product that uses WCF and needs an exception added to the Windows firewall. Unfortunately, I have been unable to get a FirewallException element to work for me. I found this solution at http://geoffwebbercross.blogspot.mx/2011/08/wix-3-netsh-customaction.html and this does work, but I would rather use the WIX FirewallException since calling commands via a CA gives me the willies. Does anyone know how I can accomplish this? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Event source sharing
Hi everyone, I'm getting the hang of Util:EventSource, and I realized our original plan was to have several of our applications (which are all of a kind - they are a bunch of collection instruments which are from the perspective of installation more or less identical) share a source. If one MSI installs the EventSource originally, and another application attempts to install it ... (a) What happens on install? I seem to see that this collision is harmless. (b) What happens on uninstall of *one* of the applications? Is there reference counting so that this does nothing to the source until the last application is removed? Do they have to share components or anything like that for this to work, or is the naming sufficient? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to pass some arguments during major upgrade to obsoleted msi to prevent removing RegistryKey
On 22/03/2013 11:26, AK wrote: Is some way available to pass some custom arguments to obsoleted msi? One possible hack is to schedule RemoveExistingProducts after InstallExecute and to add an empty component with the same Guid as the existing one. That way, Windows Installer won't remove the key. -- Bruce Cran -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM+ registration help
I'm referring to the ServiceInstaller class (http://msdn.microsoft.com/en-us/library/system.serviceprocess.serviceinstal ler.aspx) and I assure you it is not needed. The only class needed (unless you want to rewrite all this yourself) for a service that is written in .NET is ServiceBase (http://msdn.microsoft.com/en-us/library/system.serviceprocess.servicebase.a spx) Windows Installer has built in support for installing Windows Service ( ServiceInstall, ServiceControl table ) that makes ServiceInstaller unneeded. Don't believe me? I'm not offended. I wrote nearly 7 years ago a blog entry called MSI vs .NET where I wrote: http://blog.iswix.com/2006/07/msi-vs-net.html And of course just TRY telling .Net developers that there is a better way to do it. You'll quickly find out how much respect they have for the guy that does installations. After all, Setup is just XCOPY, right?? :-) Regards, Chris From: Katherine Moss katherine.m...@gordon.edu Sent: Friday, March 22, 2013 9:53 AM To: chr...@iswix.com chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: RE: [WiX-users] COM+ registration help What do you mean, unneeded code for installing Windows services? What if the service is written in .net? Then the code is needed. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, March 22, 2013 9:24 AM To: General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] COM+ registration help My COM+ experience is 10 years old but here's something I'm wondering: I wonder if what ever classes that are in System.Enterprise.Services ( or whatever that namespace is that was thrown around ) are really needed? Maybe those are just wrappers in .NET for the COMAdmin objects just like they created (unneeded) classes in .NET for installing Windows NT services. I'm wondering if like .NET Windows Services that perhaps there are useful classes for creating and hosting a COM+ application but that perhaps there are other classes that are less then truly needed. I don't care enough about COM+ to find out so just take that public thought as-is. From: Neil Sleightholm n...@x2systems.com Sent: Friday, March 22, 2013 2:46 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] COM+ registration help I'll see if I can make a simple repro first and try and come up with some ideas. dmm - can you raise a defect so this is not lost? Any thoughts how to fix it? I hope we don't have to do the whole marshalling to a separate process that DTF does just to handle COM+ registration. That will be expensive. On Wed, Mar 20, 2013 at 2:44 PM, Neil Sleightholm n...@x2systems.comwrote: I have had a look at the WiX code and my suspicion is that it loads which ever version of the .NET framework is in the msiexec process space, so if .NET 2.0 (or 3.5) was first then that is how it loads the COM+ assembly therefore if yours if .NET 4.0 is won't work. I am not sure how that could be fixed. Could you try starting your msi and then using something like process explorer to see what version of .NET is loaded in the same process space as you msi? -Original Message- From: DexterSinister [mailto:dma...@nt4hire.com] Sent: 20 March 2013 21:23 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] COM+ registration help Yes, Neil ... RegSvcs works fine for either version of the DLL, installs fine ... uninstalls fine ... Weird, eh? I'm going to take a look at the ComPlus extension code to see if I can find any obvious reason why it's not working ... not familiar territory, but I may as well give it a shot ... Thanks, -dmm -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/COM-regi str ation-help-tp7584402p7584501.html Sent from the wix-users mailing list archive at Nabble.com. -- --- - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --- - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Event source sharing
If you look at the built MSI, you'll see EventSource is just some syntactic sugar to express simple registry keys/values.Create a component in a fragment / wix library and mark it as shared. Then do a ComponentRef in your various installers and they will all share that component. Last one off will remove it. Or you could just mark it as permanent and not worry about it so much. I probably would because any event log entries are likely to stick around long after your applications have been uninstalled. From: keith.doug...@statcan.gc.ca Sent: Friday, March 22, 2013 10:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Event source sharing Hi everyone, I'm getting the hang of Util:EventSource, and I realized our original plan was to have several of our applications (which are all of a kind - they are a bunch of collection instruments which are from the perspective of installation more or less identical) share a source. If one MSI installs the EventSource originally, and another application attempts to install it ... (a) What happens on install? I seem to see that this collision is harmless. (b) What happens on uninstall of *one* of the applications? Is there reference counting so that this does nothing to the source until the last application is removed? Do they have to share components or anything like that for this to work, or is the naming sufficient? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FirewallException and WCF
This isn't much to go on. Can you show us the FirewallException and related tags you're using, so we might see what could be wrong? Alain -Original Message- From: John Lalande [mailto:j...@psrm.ca] Sent: March 22, 2013 11:05 To: wix-users@lists.sourceforge.net Subject: [WiX-users] FirewallException and WCF I am building an installer for a product that uses WCF and needs an exception added to the Windows firewall. Unfortunately, I have been unable to get a FirewallException element to work for me. I found this solution at http://geoffwebbercross.blogspot.mx/2011/08/wix-3-netsh-customaction.html and this does work, but I would rather use the WIX FirewallException since calling commands via a CA gives me the willies. Does anyone know how I can accomplish this? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FirewallException and WCF
Classification: Public
Hey John,
This works for me:
Component Id=cmpCreateFireWall Guid={some GUID} KeyPath=yes
!-- Add port to firewall --
firewall:FirewallException Id=ManagementFirewallPort
Port=[MANAGEMENTSERVICEPORTNUM] IgnoreFailure=yes Name=MYCORP Service
Port Profile=domain Protocol=tcp Scope=any/
Condition![CDATA[NOT Installed AND
SERVER_INSTALL=1]]/Condition
/Component
Steve
-Original Message-
From: John Lalande [mailto:j...@psrm.ca]
Sent: March-22-13 11:05 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FirewallException and WCF
I am building an installer for a product that uses WCF and needs an exception
added to the Windows firewall.
Unfortunately, I have been unable to get a FirewallException element to work
for me. I found this solution at
http://geoffwebbercross.blogspot.mx/2011/08/wix-3-netsh-customaction.html
and this does work, but I would rather use the WIX FirewallException since
calling commands via a CA gives me the willies.
Does anyone know how I can accomplish this?
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for free
today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
This message has been marked as Public by Steven Ogilvie on March-22-13
11:19:31 AM.
The above classification labels were added to the message by TITUS Message
Classification.
Visit www.titus.com for more information.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] FORCEABSENT and ABSENT
Hello, I'm pretty new to WiX. I've looked all over for some definitive answer but have not found resolution to my issue, so I'm bringing it to this list. I have a Bundle and a MBA written in WPF. The bundle contains two packages, both packages are MSI compiled from other WiX Product packages. Example: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id= REDACTED Name=REDACTED Language=1033 Version=13.0.1.11 Manufacturer= REDACTED UpgradeCode= REDACTED Package InstallerVersion=200 Compressed=yes InstallScope=perMachine / MajorUpgrade AllowSameVersionUpgrades=no DowngradeErrorMessage=A newer version of [ProductName] is already installed. / MediaTemplate EmbedCab=yes / Feature Id=ProductFeature ConfigurableDirectory=INSTALLFOLDER Display=expand Title= REDACTED Level=1 ComponentGroupRef Id=ProductComponents / /Feature /Product Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLFOLDER Name= REDACTED / Directory Id=ProgramMenuFolder Directory Id=ApplicationProgramsFolder Name= REDACTED / /Directory /Directory /Directory DirectoryRef Id=ApplicationProgramsFolder Component Id=ApplicationShortcut Guid= REDACTED Shortcut Id=UninstallProduct Name= REDACTED Description= REDACTED Target=[SystemFolder]msiexec.exe Arguments=/x [ProductCode]/ RemoveFolder Id=ApplicationProgramsFolder On=uninstall/ RegistryValue Root=HKCU Key=Software\Microsoft\ REDACTED Name=installed Type=integer Value=1 KeyPath=yes/ /Component /DirectoryRef /Fragment Fragment ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER ComponentGroupRef Id=HeatGenerated/ ComponentRef Id=ApplicationShortcut/
[WiX-users] Question about conditional statements in elements
I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level value or install type value? Thanks for some newbie help. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about conditional statements in elements
As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level value or install type value? Thanks for some newbie help. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about conditional statements in elements
Huh, I just noticed that my explanation directly contradicts the behaviour you're seeing, so...either I'm wrong, or there might be something flaky going on in your installer. Alain -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: March 22, 2013 11:43 To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level value or install type value? Thanks for some newbie help. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FORCEABSENT and ABSENT
ForceAbsent allows you to remove permanent packages. However, Burn will ignore your Bundle's request to remove a package if another Bundle has a reference count on the package. You'll see a statement in the bundle log file to that effect. On Fri, Mar 22, 2013 at 8:26 AM, Doug Beard dbe...@jackhenry.com wrote: Hello, I'm pretty new to WiX. I've looked all over for some definitive answer but have not found resolution to my issue, so I'm bringing it to this list. I have a Bundle and a MBA written in WPF. The bundle contains two packages, both packages are MSI compiled from other WiX Product packages. Example: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id= REDACTED Name=REDACTED Language=1033 Version=13.0.1.11 Manufacturer= REDACTED UpgradeCode= REDACTED Package InstallerVersion=200 Compressed=yes InstallScope=perMachine / MajorUpgrade AllowSameVersionUpgrades=no DowngradeErrorMessage=A newer version of [ProductName] is already installed. / MediaTemplate EmbedCab=yes / Feature Id=ProductFeature ConfigurableDirectory=INSTALLFOLDER Display=expand Title= REDACTED Level=1 ComponentGroupRef Id=ProductComponents / /Feature /Product Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLFOLDER Name= REDACTED / Directory Id=ProgramMenuFolder Directory Id=ApplicationProgramsFolder Name= REDACTED / /Directory /Directory /Directory DirectoryRef Id=ApplicationProgramsFolder Component Id=ApplicationShortcut Guid= REDACTED Shortcut Id=UninstallProduct Name= REDACTED Description= REDACTED Target=[SystemFolder]msiexec.exe Arguments=/x [ProductCode]/ RemoveFolder Id=ApplicationProgramsFolder On=uninstall/ RegistryValue Root=HKCU Key=Software\Microsoft\ REDACTED Name=installed Type=integer Value=1 KeyPath=yes/ /Component /DirectoryRef /Fragment Fragment ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER ComponentGroupRef Id=HeatGenerated/ ComponentRef Id=ApplicationShortcut/ /ComponentGroup /Fragment /Wix ___ Bundle: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; xmlns:bal=http://schemas.microsoft.com/wix/BalExtension; Bundle Name=REDACTED Version=13.0.1.11 Manufacturer= REDACTED UpgradeCode= REDACTED IconSourceFile= REDACTED _AddRemove.ico Variable Name=InstallFolder Type=string Value=[ProgramFilesFolder] REDACTED / Variable Name= REDACTED Type=string Value=[ProgramFilesFolder] REDACTED / Variable Name=WCFUser bal:Overridable=yes Persisted=yes Type=string Value=.\LocalSystem/ Variable Name=WCFPassword bal:Overridable=yes Persisted=yes Type=string Value=/ RelatedBundle Id= REDACTED Action=Upgrade / BootstrapperApplicationRef Id=ManagedBootstrapperApplicationHost PayloadGroupRef Id=InstallerPayload/ /BootstrapperApplicationRef Chain PackageGroupRef Id='Netfx4Full' / MsiPackage SourceFile=$(var. REDACTED.TargetPath) Id= REDACTED ForcePerMachine=yes Compressed=yes Cache=no Visible=no Vital=no MsiProperty Name=INSTALLFOLDER Value=[InstallFolder] / MsiProperty Name=WCFUSER Value=[WCFUser] / MsiProperty Name=WCFPASSWORD Value=[WCFPassword] / /MsiPackage MsiPackage
Re: [WiX-users] Question about conditional statements in elements
Remember, WiX is just an authoring tool for Windows Installer databases. For the underlying knowledge, please see: Conditional Syntax Statement (Windows) http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012%28v=vs.85%2 9.aspx Installed property (Windows) http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297%28v=vs.85%2 9.aspx Properties http://msdn.microsoft.com/en-us/library/windows/desktop/aa370889%28v=vs.85%2 9.aspx Regards, Chris From: Ackerman, Buddy backer...@tnsi.com Sent: Friday, March 22, 2013 10:43 AM To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level value or install type value? Thanks for some newbie help. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about conditional statements in elements
Answers are in the following two links: http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa368012(v=vs.85).aspx On Fri, Mar 22, 2013 at 8:44 AM, Alain Forget afor...@cmu.edu wrote: Huh, I just noticed that my explanation directly contradicts the behaviour you're seeing, so...either I'm wrong, or there might be something flaky going on in your installer. Alain -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: March 22, 2013 11:43 To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level value or install type value? Thanks for some newbie help. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Event source sharing
Please don't mark things permanent that are part of your application. Have your application clean up correctly. The only time you should think about leaving stuff is for user generated data (including user settings). On Fri, Mar 22, 2013 at 8:14 AM, Christopher Painter chr...@iswix.comwrote: If you look at the built MSI, you'll see EventSource is just some syntactic sugar to express simple registry keys/values.Create a component in a fragment / wix library and mark it as shared. Then do a ComponentRef in your various installers and they will all share that component. Last one off will remove it. Or you could just mark it as permanent and not worry about it so much. I probably would because any event log entries are likely to stick around long after your applications have been uninstalled. From: keith.doug...@statcan.gc.ca Sent: Friday, March 22, 2013 10:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Event source sharing Hi everyone, I'm getting the hang of Util:EventSource, and I realized our original plan was to have several of our applications (which are all of a kind - they are a bunch of collection instruments which are from the perspective of installation more or less identical) share a source. If one MSI installs the EventSource originally, and another application attempts to install it ... (a) What happens on install? I seem to see that this collision is harmless. (b) What happens on uninstall of *one* of the applications? Is there reference counting so that this does nothing to the source until the last application is removed? Do they have to share components or anything like that for this to work, or is the naming sufficient? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about conditional statements in elements
Classification: Public NOT Installed means this product is not on the machine Installed means the product has been installed -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: March-22-13 11:44 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Question about conditional statements in elements Huh, I just noticed that my explanation directly contradicts the behaviour you're seeing, so...either I'm wrong, or there might be something flaky going on in your installer. Alain -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: March 22, 2013 11:43 To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level value or install type value? Thanks for some newbie help. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message has been marked as Public by Steven Ogilvie on March-22-13 11:49:31 AM. The above classification labels were added to the message by TITUS Message Classification. Visit www.titus.com for more information. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about conditional statements in elements
It means an MSI sharing this ProductCode ( either this PackageCode which would indicate a maintenance transaction or another PackageCode which would indicate a small or minor update ) is already installed. In the case of a Major Upgrade the ProductCode has been changed and therefore from this new MSI's perspective it is not yet installed. is a special operator regarding features. See the links I sent in my other email. Regards, Chris From: Alain Forget afor...@cmu.edu Sent: Friday, March 22, 2013 10:47 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level value or install type value? Thanks for some newbie help. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Event source sharing
Hi Rob, Do you have any advice on my question per se, then? Should the developers just use a separate source for each of these very similar applications? Troubleshooters will often want to see them all at once, and not have to go back and forth between different names and things. But I do see the point of having clean stuff and not use Permanent willy-nilly. On the other hand, our stuff is also for internal use only and the applications and environment targeted is very controlled and standardized with very technically unsophisticated users and plenty of space, etc. on their machines. In fact, I've never heard of an out-and-out uninstall in the environment we use now (which doesn't use Windows Installer at all for these applications). We do want to be able to do it, hence one of the reasons to use WiX to help us to do better - and it certainly has proved much more congenial than Setup projects. Since all the application packages of this type create the source anyway, I guess we'd only have a problem with a non-permanent if we somehow did not immediately replace it with something. Thanks for the thoughts, Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: March-22-13 11:49 AM To: Christopher Painter; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Event source sharing Please don't mark things permanent that are part of your application. Have your application clean up correctly. The only time you should think about leaving stuff is for user generated data (including user settings). On Fri, Mar 22, 2013 at 8:14 AM, Christopher Painter chr...@iswix.comwrote: If you look at the built MSI, you'll see EventSource is just some syntactic sugar to express simple registry keys/values.Create a component in a fragment / wix library and mark it as shared. Then do a ComponentRef in your various installers and they will all share that component. Last one off will remove it. Or you could just mark it as permanent and not worry about it so much. I probably would because any event log entries are likely to stick around long after your applications have been uninstalled. From: keith.doug...@statcan.gc.ca Sent: Friday, March 22, 2013 10:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Event source sharing Hi everyone, I'm getting the hang of Util:EventSource, and I realized our original plan was to have several of our applications (which are all of a kind - they are a bunch of collection instruments which are from the perspective of installation more or less identical) share a source. If one MSI installs the EventSource originally, and another application attempts to install it ... (a) What happens on install? I seem to see that this collision is harmless. (b) What happens on uninstall of *one* of the applications? Is there reference counting so that this does nothing to the source until the last application is removed? Do they have to share components or anything like that for this to work, or is the naming sufficient? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about conditional statements in elements
Dangit Chris, beat me to it :)
Switch on verbose logging (http://support.microsoft.com/kb/314852),
and look for something like this:
MSI (c) (14:28) [11:56:32:469]: Doing action: FindRelatedProducts
Action 11:56:32: FindRelatedProducts. Searching for related applications
Action start 11:56:32: FindRelatedProducts.
FindRelatedProducts: Found application: {XX----X}
Immediately following this you should get some PROPERTY CHANGE events,
which will be the property defined in the upgrade table as what should
be set when it finds an upgrade.
On 22 March 2013 15:49, Christopher Painter chr...@iswix.com wrote:
It means an MSI sharing this ProductCode ( either this PackageCode which
would indicate a maintenance transaction or another PackageCode which would
indicate a small or minor update ) is already installed. In the case of a
Major Upgrade the ProductCode has been changed and therefore from this new
MSI's perspective it is not yet installed.
is a special operator regarding features. See the links I sent in my
other email.
Regards,
Chris
From: Alain Forget afor...@cmu.edu
Sent: Friday, March 22, 2013 10:47 AM
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Question about conditional statements in elements
As far as I understand it, Installed means, Before this installer was
run, a version of this program was already installed on
this machine. Someone please correct me if that isn't quite true.
As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax
yet.
Alain
-Original Message-
From: Ackerman, Buddy [mailto:backer...@tnsi.com]
Sent: March 22, 2013 11:39
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Question about conditional statements in elements
I'm very new to WiX and have inherited an existing project. I've been
deciphering it fine except for a few things. In this project
I have the following element:
Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show
The question with this is the NOT Installed condition. What exactly does
Installed mean? When I run this to upgrade and
already installed application this dialog still shows up. SO, I'm not sure
what Installed really means (there is also an Upgrade
element in the project with a property assigned to it that is used in other
controls throughout the project).
Next is the following syntax that I have in several control conditional
statements:
ftDatabase=3
The ftDatabase is the ID of one of the Features. However, I don't know
what value it would have. Is this an install level value or
install type value?
Thanks for some newbie help.
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of
Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If
you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for
free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Event source sharing
If you want to share the event sources, put them in a single Component (probably with the resource .dll) and give the Component a Guid. Now the event sources and .dll will be correctly reference counted by the Windows Installer no matter how many MSIs share it. You could go as far as to put the Compnent into a .wixlib and make sharing across multiple .wixproj's as easy as a ComponentRef. This is what Christopher was referring to below. Permanent will be unnecessary when the code is written properly (which should also provide the minimal solution). smile/ On Fri, Mar 22, 2013 at 8:58 AM, keith.doug...@statcan.gc.ca wrote: Hi Rob, Do you have any advice on my question per se, then? Should the developers just use a separate source for each of these very similar applications? Troubleshooters will often want to see them all at once, and not have to go back and forth between different names and things. But I do see the point of having clean stuff and not use Permanent willy-nilly. On the other hand, our stuff is also for internal use only and the applications and environment targeted is very controlled and standardized with very technically unsophisticated users and plenty of space, etc. on their machines. In fact, I've never heard of an out-and-out uninstall in the environment we use now (which doesn't use Windows Installer at all for these applications). We do want to be able to do it, hence one of the reasons to use WiX to help us to do better - and it certainly has proved much more congenial than Setup projects. Since all the application packages of this type create the source anyway, I guess we'd only have a problem with a non-permanent if we somehow did not immediately replace it with something. Thanks for the thoughts, Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: March-22-13 11:49 AM To: Christopher Painter; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Event source sharing Please don't mark things permanent that are part of your application. Have your application clean up correctly. The only time you should think about leaving stuff is for user generated data (including user settings). On Fri, Mar 22, 2013 at 8:14 AM, Christopher Painter chr...@iswix.com wrote: If you look at the built MSI, you'll see EventSource is just some syntactic sugar to express simple registry keys/values.Create a component in a fragment / wix library and mark it as shared. Then do a ComponentRef in your various installers and they will all share that component. Last one off will remove it. Or you could just mark it as permanent and not worry about it so much. I probably would because any event log entries are likely to stick around long after your applications have been uninstalled. From: keith.doug...@statcan.gc.ca Sent: Friday, March 22, 2013 10:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Event source sharing Hi everyone, I'm getting the hang of Util:EventSource, and I realized our original plan was to have several of our applications (which are all of a kind - they are a bunch of collection instruments which are from the perspective of installation more or less identical) share a source. If one MSI installs the EventSource originally, and another application attempts to install it ... (a) What happens on install? I seem to see that this collision is harmless. (b) What happens on uninstall of *one* of the applications? Is there reference counting so that this does nothing to the source until the last application is removed? Do they have to share components or anything like that for this to work, or is the naming sufficient? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make
Re: [WiX-users] Burn Engine Operations (WAS: Using transforms (regular) to install multiple times per application)
PS: there was a discussion about this on wix-devs. To support instance
transforms in Burn, more code would need to be added to Burn. It just isn't
supported today. Someone else said, instance transforms are more trouble
than they are worth, and I tended to agree. smile/
On Thu, Mar 14, 2013 at 4:09 PM, Richard Norman
technologyexpe...@outlook.com wrote:
Ok so for an update. After digging through the Burn source I saw it was
reading an XML file from the package (and I assume that it includes the
GUID for the original MSI and not the transform). That is when I noticed
that there was nothing that actually wrote the XML. So I was wondering if
it was created on install or build.
So I took 7-Zip and was able to extract the files from my simple Burn
package and noticed a “0” file. This file seems to equate to the XML file
that is being read. That file seemed to have the GUID for the MSI package
embedded. So I THINK that answers that question.
So from my knowledge research, BURN pre-records the MSI GUID and the
transform effectively breaks the uninstall scenario without a custom action
of some sort.
So I recommended 2 options:
1: Use WiXLibs to package the install with the WiX project for the master
MSI instead of doing a transform. (depending on the environment this may
not be practical, but this gets rid of your need for a transform and
tracking the GUIDs)
2: package a MSIs for each main install you need. (more MSIs to build and
maintain, but no need to worry about transform)
A consideration was given to Merge Modules BUT they also seem to have a
GUID that would need to be transformed as well.
If there is a different scenario that I am missing or a way that I am not
initially seeing, let me know. But the engine doesn’t seem to handle the
transform of the ID GUID of the package well.
Richard Norman
TechX - Technology eXperts
Technical Support Consulting
Phone: 559.464.5042
Web: http://on.fb.me/Ztd9ns
Sent from Windows Mail
From: Richard Norman
Sent: March 14, 2013 10:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Using transforms (regular) to install mulitple
times per application
Ok, I am working with Jonathan today in my day job capacity and I have an
understanding of PROBABLY what is happening. If the WiX-devs list is better
for this, let me know...
Based on the install logs and the way BURN appears to work, transforms
seem a bit limited in how BURN handles them (and if someone knows the
section of code I would appreciate the pointer).
Background:
So the transform is working on install. The installation works as expected
and the appropriate transform is applied and installed. On uninstall they
are getting an error saying that the item is not installed (weird cause we
did install it). So looking at the log we see that the initial product GUID
is one value and the transform changes it to a different value. Also the
registry shows that the transform was applied as expected. So far so good.
When we go to uninstall we notice the GUID being used is the old GUID for
the application not the transformed one. This leads to the uninstall error.
What we believe is happening is that BURN is tracking the MSI GUIDs that
are being installed and when the transform is applied and changes that
GUID, BURN has no trace of it.
What we need:
So what we need to do is when a transform is applied, update the XML list
that BURN maintains with the new GUID so that the uninstall tracks it
appropriately. We just need to update this on install only. Once updated it
should be fine going forward. I can see in the BURN source where it reads
this XML information and operates based on that, but I am not 100% sure
where this information is generated. Is it on install or is this done at
build time? If at build time is there a way for us to tell BURN what the
GUID will change to? That will resolve their uninstall problem...
Below are some of the logs during install:
[09B4:06A0][2013-03-13T07:48:14]: Verified acquired payload:
cab07A065F47DD6E9FCDAE62ABCDDF335E7 at path: C:\Documents and Settings\All
Users\Application Data\Package
Cache\.unverified\cab07A065F47DD6E9FCDAE62ABCDDF335E7, moving to:
C:\Documents and Settings\All Users\Application Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\cab1.cab.
[09B4:0D50][2013-03-13T07:48:14]: Applying execute package: RADInstall30,
action: Install, path: C:\Documents and Settings\All Users\Application
Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\RADInstall30,
arguments: ' ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7 TRANSFORMS=:Jon2T
ARPSYSTEMCOMPONENT=1'
[09B4:0D50][2013-03-13T07:48:16]: Unable to register source directory:
C:\Documents and Settings\All Users\Application Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\, product:
Re: [WiX-users] Question about conditional statements in elements
So what property is it actually checking to see if it's installed? On my product element there is a Version attribute and there is an UpgradeCode attribute, are these what are being used? Again I have already installed the product and when I run the installer again (with the Version attribute change to a higher minor version) this dialog still shows. I actually want the dialog to show but I am just curious as to why it is still showing given this criteria. Thanks. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, March 22, 2013 11:50 AM To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements It means an MSI sharing this ProductCode ( either this PackageCode which would indicate a maintenance transaction or another PackageCode which would indicate a small or minor update ) is already installed. In the case of a Major Upgrade the ProductCode has been changed and therefore from this new MSI's perspective it is not yet installed. is a special operator regarding features. See the links I sent in my other email. Regards, Chris From: Alain Forget afor...@cmu.edu Sent: Friday, March 22, 2013 10:47 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level value or install type value? Thanks for some newbie help. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps
Re: [WiX-users] Question about conditional statements in elements
Yes, the Installed property means this ProductCode is installed. If you see that Welcome dialog again the most obvious thing to check is whether the ProductCode has changed. The idea is that you only see the Welcome dialog on fresh first time install. Later actions based on the same ProductCode are maintenance options, feature add/remove etc. It's got to be the ProductCode changing. This stuff works all the time and has done for years. This is a Windows Installer property used in every MSI-based install, whether WiX or not. It's not likely that such a basic thing doesn't work. http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297(v=vs.85).as px Phil -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: Friday, March 22, 2013 9:32 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements So what property is it actually checking to see if it's installed? On my product element there is a Version attribute and there is an UpgradeCode attribute, are these what are being used? Again I have already installed the product and when I run the installer again (with the Version attribute change to a higher minor version) this dialog still shows. I actually want the dialog to show but I am just curious as to why it is still showing given this criteria. Thanks. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, March 22, 2013 11:50 AM To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements It means an MSI sharing this ProductCode ( either this PackageCode which would indicate a maintenance transaction or another PackageCode which would indicate a small or minor update ) is already installed. In the case of a Major Upgrade the ProductCode has been changed and therefore from this new MSI's perspective it is not yet installed. is a special operator regarding features. See the links I sent in my other email. Regards, Chris From: Alain Forget afor...@cmu.edu Sent: Friday, March 22, 2013 10:47 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level value or install type value? Thanks for some newbie help. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] Question about conditional statements in elements
Ah, the other explanation is that you installed that MSI in a per User context, and now you're installing it a different user context (another user or per System). Phil -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, March 22, 2013 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Question about conditional statements in elements Yes, the Installed property means this ProductCode is installed. If you see that Welcome dialog again the most obvious thing to check is whether the ProductCode has changed. The idea is that you only see the Welcome dialog on fresh first time install. Later actions based on the same ProductCode are maintenance options, feature add/remove etc. It's got to be the ProductCode changing. This stuff works all the time and has done for years. This is a Windows Installer property used in every MSI-based install, whether WiX or not. It's not likely that such a basic thing doesn't work. http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297(v=vs.85).as px Phil -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: Friday, March 22, 2013 9:32 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements So what property is it actually checking to see if it's installed? On my product element there is a Version attribute and there is an UpgradeCode attribute, are these what are being used? Again I have already installed the product and when I run the installer again (with the Version attribute change to a higher minor version) this dialog still shows. I actually want the dialog to show but I am just curious as to why it is still showing given this criteria. Thanks. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, March 22, 2013 11:50 AM To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements It means an MSI sharing this ProductCode ( either this PackageCode which would indicate a maintenance transaction or another PackageCode which would indicate a small or minor update ) is already installed. In the case of a Major Upgrade the ProductCode has been changed and therefore from this new MSI's perspective it is not yet installed. is a special operator regarding features. See the links I sent in my other email. Regards, Chris From: Alain Forget afor...@cmu.edu Sent: Friday, March 22, 2013 10:47 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level value or install type value? Thanks for some newbie help. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction Network Services. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] Question about conditional statements in elements
That's not the case. I'm installing it on the same machine logged in as the same user. I guess my question is, what is the ProductCode, where is it set? Here's my Product element, what should be changed so that it knows that this an upgrade to a product that is already installed? Product Id=* Name=My App $(var.BuildVersion)$(var.BuildNameSuffix) Language=!(loc.Language) Version=$(var.BuildVersion) Manufacturer=Me UpgradeCode=75DD6EF7-EDDE-40D1-A997-170A8419A4E4 Codepage=1252 -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, March 22, 2013 12:53 PM To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Question about conditional statements in elements Ah, the other explanation is that you installed that MSI in a per User context, and now you're installing it a different user context (another user or per System). Phil -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, March 22, 2013 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Question about conditional statements in elements Yes, the Installed property means this ProductCode is installed. If you see that Welcome dialog again the most obvious thing to check is whether the ProductCode has changed. The idea is that you only see the Welcome dialog on fresh first time install. Later actions based on the same ProductCode are maintenance options, feature add/remove etc. It's got to be the ProductCode changing. This stuff works all the time and has done for years. This is a Windows Installer property used in every MSI-based install, whether WiX or not. It's not likely that such a basic thing doesn't work. http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297(v=vs.85).as px Phil -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: Friday, March 22, 2013 9:32 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements So what property is it actually checking to see if it's installed? On my product element there is a Version attribute and there is an UpgradeCode attribute, are these what are being used? Again I have already installed the product and when I run the installer again (with the Version attribute change to a higher minor version) this dialog still shows. I actually want the dialog to show but I am just curious as to why it is still showing given this criteria. Thanks. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, March 22, 2013 11:50 AM To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements It means an MSI sharing this ProductCode ( either this PackageCode which would indicate a maintenance transaction or another PackageCode which would indicate a small or minor update ) is already installed. In the case of a Major Upgrade the ProductCode has been changed and therefore from this new MSI's perspective it is not yet installed. is a special operator regarding features. See the links I sent in my other email. Regards, Chris From: Alain Forget afor...@cmu.edu Sent: Friday, March 22, 2013 10:47 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know
Re: [WiX-users] Event source sharing
My thought here is that there is user data. There are going to be a bunch of event log entries written to a log by an application and there's going to be an event source associated with them. No? In general I agree with you but what are your thoughts with this exact scenario? From: Rob Mensching r...@robmensching.com Sent: Friday, March 22, 2013 10:51 AM To: Christopher Painter chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Event source sharing Please don't mark things permanent that are part of your application. Have your application clean up correctly. The only time you should think about leaving stuff is for user generated data (including user settings). On Fri, Mar 22, 2013 at 8:14 AM, Christopher Painter chr...@iswix.com wrote: If you look at the built MSI, you'll see EventSource is just some syntactic sugar to express simple registry keys/values.Create a component in a fragment / wix library and mark it as shared. Then do a ComponentRef in your various installers and they will all share that component. Last one off will remove it. Or you could just mark it as permanent and not worry about it so much. I probably would because any event log entries are likely to stick around long after your applications have been uninstalled. From: keith.doug...@statcan.gc.ca Sent: Friday, March 22, 2013 10:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Event source sharing Hi everyone, I'm getting the hang of Util:EventSource, and I realized our original plan was to have several of our applications (which are all of a kind - they are a bunch of collection instruments which are from the perspective of installation more or less identical) share a source. If one MSI installs the EventSource originally, and another application attempts to install it ... (a) What happens on install? I seem to see that this collision is harmless. (b) What happens on uninstall of *one* of the applications? Is there reference counting so that this does nothing to the source until the last application is removed? Do they have to share components or anything like that for this to work, or is the naming sufficient? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about conditional statements in elements
That would probably explain it as well. By default, I believe WiX will use a property called WIX_UPGRADE_DETECTED. Again, remember that WiX is just a way of creating MSI files, so that MajorUpgrade element creates entries in the Upgrade table in the install. One of the columns in this table defines the property to set if a matching upgrade code is found. You can examine the contents of that table using a tool called Orca (http://msdn.microsoft.com/en-gb/library/windows/desktop/aa370557(v=vs.85).aspx) The other way to find out what property it's *actually* using is by examine the log for PROPERTY CHANGE events emitted by FindRelatedProducts. Hope that helps On 22 March 2013 16:52, Phil Wilson phil.wil...@mvps.org wrote: Ah, the other explanation is that you installed that MSI in a per User context, and now you're installing it a different user context (another user or per System). Phil -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, March 22, 2013 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Question about conditional statements in elements Yes, the Installed property means this ProductCode is installed. If you see that Welcome dialog again the most obvious thing to check is whether the ProductCode has changed. The idea is that you only see the Welcome dialog on fresh first time install. Later actions based on the same ProductCode are maintenance options, feature add/remove etc. It's got to be the ProductCode changing. This stuff works all the time and has done for years. This is a Windows Installer property used in every MSI-based install, whether WiX or not. It's not likely that such a basic thing doesn't work. http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297(v=vs.85).as px Phil -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: Friday, March 22, 2013 9:32 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements So what property is it actually checking to see if it's installed? On my product element there is a Version attribute and there is an UpgradeCode attribute, are these what are being used? Again I have already installed the product and when I run the installer again (with the Version attribute change to a higher minor version) this dialog still shows. I actually want the dialog to show but I am just curious as to why it is still showing given this criteria. Thanks. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, March 22, 2013 11:50 AM To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements It means an MSI sharing this ProductCode ( either this PackageCode which would indicate a maintenance transaction or another PackageCode which would indicate a small or minor update ) is already installed. In the case of a Major Upgrade the ProductCode has been changed and therefore from this new MSI's perspective it is not yet installed. is a special operator regarding features. See the links I sent in my other email. Regards, Chris From: Alain Forget afor...@cmu.edu Sent: Friday, March 22, 2013 10:47 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in the project with a property assigned to it that is used in other controls throughout the project). Next is the following syntax that I have in several control conditional statements: ftDatabase=3 The ftDatabase is the ID of one of the Features. However, I don't know what value it would have. Is this an install level
Re: [WiX-users] Question about conditional statements in elements
Product Id=* generates a new product code each time you build. -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: 22 March 2013 17:04 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements That's not the case. I'm installing it on the same machine logged in as the same user. I guess my question is, what is the ProductCode, where is it set? Here's my Product element, what should be changed so that it knows that this an upgrade to a product that is already installed? Product Id=* Name=My App $(var.BuildVersion)$(var.BuildNameSuffix) Language=!(loc.Language) Version=$(var.BuildVersion) Manufacturer=Me UpgradeCode=75DD6EF7-EDDE-40D1-A997-170A8419A4E4 Codepage=1252 -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, March 22, 2013 12:53 PM To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Question about conditional statements in elements Ah, the other explanation is that you installed that MSI in a per User context, and now you're installing it a different user context (another user or per System). Phil -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, March 22, 2013 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Question about conditional statements in elements Yes, the Installed property means this ProductCode is installed. If you see that Welcome dialog again the most obvious thing to check is whether the ProductCode has changed. The idea is that you only see the Welcome dialog on fresh first time install. Later actions based on the same ProductCode are maintenance options, feature add/remove etc. It's got to be the ProductCode changing. This stuff works all the time and has done for years. This is a Windows Installer property used in every MSI-based install, whether WiX or not. It's not likely that such a basic thing doesn't work. http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297(v=vs.85).as px Phil -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: Friday, March 22, 2013 9:32 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements So what property is it actually checking to see if it's installed? On my product element there is a Version attribute and there is an UpgradeCode attribute, are these what are being used? Again I have already installed the product and when I run the installer again (with the Version attribute change to a higher minor version) this dialog still shows. I actually want the dialog to show but I am just curious as to why it is still showing given this criteria. Thanks. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, March 22, 2013 11:50 AM To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements It means an MSI sharing this ProductCode ( either this PackageCode which would indicate a maintenance transaction or another PackageCode which would indicate a small or minor update ) is already installed. In the case of a Major Upgrade the ProductCode has been changed and therefore from this new MSI's perspective it is not yet installed. is a special operator regarding features. See the links I sent in my other email. Regards, Chris From: Alain Forget afor...@cmu.edu Sent: Friday, March 22, 2013 10:47 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it fine except for a few things. In this project I have the following element: Show Dialog=WelcomeDlg Before=ProgressDlgNOT Installed/Show The question with this is the NOT Installed condition. What exactly does Installed mean? When I run this to upgrade and already installed application this dialog still shows up. SO, I'm not sure what Installed really means (there is also an Upgrade element in
Re: [WiX-users] Event source sharing
My thinking: If the application is removed, the archived event log entries aren't interesting any longer. On Fri, Mar 22, 2013 at 10:02 AM, Christopher Painter chr...@iswix.comwrote: My thought here is that there is user data. There are going to be a bunch of event log entries written to a log by an application and there's going to be an event source associated with them. No? In general I agree with you but what are your thoughts with this exact scenario? From: Rob Mensching r...@robmensching.com Sent: Friday, March 22, 2013 10:51 AM To: Christopher Painter chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Event source sharing Please don't mark things permanent that are part of your application. Have your application clean up correctly. The only time you should think about leaving stuff is for user generated data (including user settings). On Fri, Mar 22, 2013 at 8:14 AM, Christopher Painter chr...@iswix.com wrote: If you look at the built MSI, you'll see EventSource is just some syntactic sugar to express simple registry keys/values.Create a component in a fragment / wix library and mark it as shared. Then do a ComponentRef in your various installers and they will all share that component. Last one off will remove it. Or you could just mark it as permanent and not worry about it so much. I probably would because any event log entries are likely to stick around long after your applications have been uninstalled. From: keith.doug...@statcan.gc.ca Sent: Friday, March 22, 2013 10:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Event source sharing Hi everyone, I'm getting the hang of Util:EventSource, and I realized our original plan was to have several of our applications (which are all of a kind - they are a bunch of collection instruments which are from the perspective of installation more or less identical) share a source. If one MSI installs the EventSource originally, and another application attempts to install it ... (a) What happens on install? I seem to see that this collision is harmless. (b) What happens on uninstall of *one* of the applications? Is there reference counting so that this does nothing to the source until the last application is removed? Do they have to share components or anything like that for this to work, or is the naming sufficient? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about conditional statements in elements
...And that's not necessarily a bad thing, since major upgrades work just fine for most scenarios. However, you probably need to include a check against your upgrade property (which, if you're just using MajorUpgrade, is probably WIX_UPGRADE_DETECTED). On 22 March 2013 17:12, David Watson dwat...@sdl.com wrote: Product Id=* generates a new product code each time you build. -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: 22 March 2013 17:04 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements That's not the case. I'm installing it on the same machine logged in as the same user. I guess my question is, what is the ProductCode, where is it set? Here's my Product element, what should be changed so that it knows that this an upgrade to a product that is already installed? Product Id=* Name=My App $(var.BuildVersion)$(var.BuildNameSuffix) Language=!(loc.Language) Version=$(var.BuildVersion) Manufacturer=Me UpgradeCode=75DD6EF7-EDDE-40D1-A997-170A8419A4E4 Codepage=1252 -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, March 22, 2013 12:53 PM To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Question about conditional statements in elements Ah, the other explanation is that you installed that MSI in a per User context, and now you're installing it a different user context (another user or per System). Phil -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, March 22, 2013 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Question about conditional statements in elements Yes, the Installed property means this ProductCode is installed. If you see that Welcome dialog again the most obvious thing to check is whether the ProductCode has changed. The idea is that you only see the Welcome dialog on fresh first time install. Later actions based on the same ProductCode are maintenance options, feature add/remove etc. It's got to be the ProductCode changing. This stuff works all the time and has done for years. This is a Windows Installer property used in every MSI-based install, whether WiX or not. It's not likely that such a basic thing doesn't work. http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297(v=vs.85).as px Phil -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: Friday, March 22, 2013 9:32 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements So what property is it actually checking to see if it's installed? On my product element there is a Version attribute and there is an UpgradeCode attribute, are these what are being used? Again I have already installed the product and when I run the installer again (with the Version attribute change to a higher minor version) this dialog still shows. I actually want the dialog to show but I am just curious as to why it is still showing given this criteria. Thanks. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, March 22, 2013 11:50 AM To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements It means an MSI sharing this ProductCode ( either this PackageCode which would indicate a maintenance transaction or another PackageCode which would indicate a small or minor update ) is already installed. In the case of a Major Upgrade the ProductCode has been changed and therefore from this new MSI's perspective it is not yet installed. is a special operator regarding features. See the links I sent in my other email. Regards, Chris From: Alain Forget afor...@cmu.edu Sent: Friday, March 22, 2013 10:47 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Question about conditional statements in elements As far as I understand it, Installed means, Before this installer was run, a version of this program was already installed on this machine. Someone please correct me if that isn't quite true. As far as ftDatabase=3, I have no idea, I haven't yet seen that syntax yet. Alain -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: March 22, 2013 11:39 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question about conditional statements in elements I'm very new to WiX and have inherited an existing project. I've been deciphering it
Re: [WiX-users] Event source sharing
The answer is, it depends. I worked on some very large products that had a lot of code reuse and sometimes the asset that had the logging dependency wanted the event source to be named a certain thing regardless of what product it shipped with and other assets wanted the event source to be rebranded based on the product that consumed it. Reusable, composable software designs are funny that way. Our job as installers was to support those stories while maintaining highest quality standards. From: keith.doug...@statcan.gc.ca Sent: Friday, March 22, 2013 11:23 AM To: wix-users@lists.sourceforge.net, chr...@iswix.com Subject: RE: [WiX-users] Event source sharing Hi Rob, Do you have any advice on my question per se, then? Should the developers just use a separate source for each of these very similar applications? Troubleshooters will often want to see them all at once, and not have to go back and forth between different names and things. But I do see the point of having clean stuff and not use Permanent willy-nilly. On the other hand, our stuff is also for internal use only and the applications and environment targeted is very controlled and standardized with very technically unsophisticated users and plenty of space, etc. on their machines. In fact, I've never heard of an out-and-out uninstall in the environment we use now (which doesn't use Windows Installer at all for these applications). We do want to be able to do it, hence one of the reasons to use WiX to help us to do better - and it certainly has proved much more congenial than Setup projects. Since all the application packages of this type create the source anyway, I guess we'd only have a problem with a non-permanent if we somehow did not immediately replace it with something. Thanks for the thoughts, Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: March-22-13 11:49 AM To: Christopher Painter; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Event source sharing Please don't mark things permanent that are part of your application. Have your application clean up correctly. The only time you should think about leaving stuff is for user generated data (including user settings). On Fri, Mar 22, 2013 at 8:14 AM, Christopher Painter chr...@iswix.comwrote: If you look at the built MSI, you'll see EventSource is just some syntactic sugar to express simple registry keys/values.Create a component in a fragment / wix library and mark it as shared. Then do a ComponentRef in your various installers and they will all share that component. Last one off will remove it. Or you could just mark it as permanent and not worry about it so much. I probably would because any event log entries are likely to stick around long after your applications have been uninstalled. From: keith.doug...@statcan.gc.ca Sent: Friday, March 22, 2013 10:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Event source sharing Hi everyone, I'm getting the hang of Util:EventSource, and I realized our original plan was to have several of our applications (which are all of a kind - they are a bunch of collection instruments which are from the perspective of installation more or less identical) share a source. If one MSI installs the EventSource originally, and another application attempts to install it ... (a) What happens on install? I seem to see that this collision is harmless. (b) What happens on uninstall of *one* of the applications? Is there reference counting so that this does nothing to the source until the last application is removed? Do they have to share components or anything like that for this to work, or is the naming sufficient? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow
Re: [WiX-users] Event source sharing
Possibly. I work in enterprise IT these days so I can imagine the operations guys might be interested in certain scenarios. From: Rob Mensching r...@robmensching.com Sent: Friday, March 22, 2013 12:22 PM To: Christopher Painter chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Event source sharing My thinking: If the application is removed, the archived event log entries aren't interesting any longer. On Fri, Mar 22, 2013 at 10:02 AM, Christopher Painter chr...@iswix.com wrote: My thought here is that there is user data. There are going to be a bunch of event log entries written to a log by an application and there's going to be an event source associated with them. No? In general I agree with you but what are your thoughts with this exact scenario? From: Rob Mensching r...@robmensching.com Sent: Friday, March 22, 2013 10:51 AM To: Christopher Painter chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Event source sharing Please don't mark things permanent that are part of your application. Have your application clean up correctly. The only time you should think about leaving stuff is for user generated data (including user settings). On Fri, Mar 22, 2013 at 8:14 AM, Christopher Painter chr...@iswix.com wrote: If you look at the built MSI, you'll see EventSource is just some syntactic sugar to express simple registry keys/values.Create a component in a fragment / wix library and mark it as shared. Then do a ComponentRef in your various installers and they will all share that component. Last one off will remove it. Or you could just mark it as permanent and not worry about it so much. I probably would because any event log entries are likely to stick around long after your applications have been uninstalled. From: keith.doug...@statcan.gc.ca Sent: Friday, March 22, 2013 10:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Event source sharing Hi everyone, I'm getting the hang of Util:EventSource, and I realized our original plan was to have several of our applications (which are all of a kind - they are a bunch of collection instruments which are from the perspective of installation more or less identical) share a source. If one MSI installs the EventSource originally, and another application attempts to install it ... (a) What happens on install? I seem to see that this collision is harmless. (b) What happens on uninstall of *one* of the applications? Is there reference counting so that this does nothing to the source until the last application is removed? Do they have to share components or anything like that for this to work, or is the naming sufficient? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about conditional statements in elements
Hi Alain, In general, Product ID=* is a good thing. Each new build should generate a new product code because it typically means you've made changes to the product (i.e. made a new version). If you want to test the Maintenance dialog then run the same MSI (without rebuilding it!) twice. When you use the MajorUpgrade element in WiX it handles removing the old version and installing the new version when you upgrade. Hence, in many cases the Welcome dialog is entirely appropriate because the user experience on upgrade or new installation from a UI perspective is similar. The MajorUpgrade element has options for displaying messages if the user tries to upgrade or downgrade and should not be allowed, etc. if that's what you need. If you want something more complicated on upgrade then you will have to do a little more work. Daniel Madill www.quanser.com -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: March-22-13 1:12 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements Product Id=* generates a new product code each time you build. -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: 22 March 2013 17:04 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements That's not the case. I'm installing it on the same machine logged in as the same user. I guess my question is, what is the ProductCode, where is it set? Here's my Product element, what should be changed so that it knows that this an upgrade to a product that is already installed? Product Id=* Name=My App $(var.BuildVersion)$(var.BuildNameSuffix) Language=!(loc.Language) Version=$(var.BuildVersion) Manufacturer=Me UpgradeCode=75DD6EF7-EDDE-40D1-A997-170A8419A4E4 Codepage=1252 -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, March 22, 2013 12:53 PM To: 'Phil Wilson'; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Question about conditional statements in elements Ah, the other explanation is that you installed that MSI in a per User context, and now you're installing it a different user context (another user or per System). Phil -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, March 22, 2013 9:51 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Question about conditional statements in elements Yes, the Installed property means this ProductCode is installed. If you see that Welcome dialog again the most obvious thing to check is whether the ProductCode has changed. The idea is that you only see the Welcome dialog on fresh first time install. Later actions based on the same ProductCode are maintenance options, feature add/remove etc. It's got to be the ProductCode changing. This stuff works all the time and has done for years. This is a Windows Installer property used in every MSI-based install, whether WiX or not. It's not likely that such a basic thing doesn't work. http://msdn.microsoft.com/en-us/library/windows/desktop/aa369297(v=vs.85).as px Phil -Original Message- From: Ackerman, Buddy [mailto:backer...@tnsi.com] Sent: Friday, March 22, 2013 9:32 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements So what property is it actually checking to see if it's installed? On my product element there is a Version attribute and there is an UpgradeCode attribute, are these what are being used? Again I have already installed the product and when I run the installer again (with the Version attribute change to a higher minor version) this dialog still shows. I actually want the dialog to show but I am just curious as to why it is still showing given this criteria. Thanks. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, March 22, 2013 11:50 AM To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about conditional statements in elements It means an MSI sharing this ProductCode ( either this PackageCode which would indicate a maintenance transaction or another PackageCode which would indicate a small or minor update ) is already installed. In the case of a Major Upgrade the ProductCode has been changed and therefore from this new MSI's perspective it is not yet installed. is a special operator regarding features. See the links I sent in my other email. Regards, Chris From: Alain Forget afor...@cmu.edu Sent: Friday, March 22, 2013 10:47 AM To: General discussion for Windows
[WiX-users] Order of Execution
Running Wix 3.7, I have a feature with several ComponentGroupRef's: Feature Id=, Title=, Level=1 ComponentGroupRef Id=one / ComponentGroupRef Id=two / ... ComponentGroupRef Id=xxx / ComponentGroupRef Id=yyy / /Feature I need to yyy to execute after xxx because of a dependency (it needs to wait for IIS to start). How do I do this? I know Wix order-of-execution is unpredictable. And I know if I were doing via Custom Actions, I could order them, but I would rather not do Custom Actions if I don't have to. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setup.exe won't exit gracefully
Running Wix 3.6.1922, I have a Setup.exe that's a custom managed boostrapper application. When I execute, I see two or three instances of Setup.exe in the Task Manager. Problem is, when the Setup.exe terminates (normally or abnormally), it almost always leaves an instance of Setup.exe still running. I have to manually use Task Manager to kill it. Any idea why this is, and how do I fix this problem? Thanks! -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WixTargetPath and relative paths
With Wix 3.6.1922, I manually add the WixToolPath, WixTargetsPath and WixTaskPath to my .wixproj file. If I use absolute paths, there's never any problem. However, due to build servers not having Wix installed, I must use relative paths, and that's where I run into all kinds of problems, especially with WixTargetPath. If I use a relative path that enables it to find WixTasks.dll, it then seems to screw up my WixExtension later in the file, causing my extension DLL's to not be found. I think WIx 3.7 works better, but due to some incompatibilities, I am stuck with 3.6.1922 for now. Is there a work-around? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixTargetPath and relative paths
I have a similar situation where I am building two different WIX burn chainers (long story, has to do with .Net versions). In any case I was running into similar issues with the paths. I ended up creating an environment variable for my Wix 3.6 binaries path and inserting that in my WIX files as necessary. I then just got the Wix 3.6 binaries and copied to a suitable directory. With Wix 3.7 I did a proper install so it set up its own environment variables. You could probably just do the Wix 3.7 binaries in the same fashion on your build machines if that was necessary (but I have to wonder why your build machines would not have it installed if it was a necessary part of the build). I then created my own version of the Wix 3.6 target paths and import that where I want to reference Wix 3.6 specifically. With this I am able to have one msbuild script that builds all targets, plus the installers targeting both Wix 3.6 and Wix 3.7 as necessary. Andreas A. Mertens Founder, Software Consultant and Developer NVision Ideas, Inc. cell: 604-354-9332 email: andre...@nvisionideas.com From: George Fleming [gef...@microsoft.com] Sent: March 22, 2013 11:42 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WixTargetPath and relative paths With Wix 3.6.1922, I manually add the WixToolPath, WixTargetsPath and WixTaskPath to my .wixproj file. If I use absolute paths, there's never any problem. However, due to build servers not having Wix installed, I must use relative paths, and that's where I run into all kinds of problems, especially with WixTargetPath. If I use a relative path that enables it to find WixTasks.dll, it then seems to screw up my WixExtension later in the file, causing my extension DLL's to not be found. I think WIx 3.7 works better, but due to some incompatibilities, I am stuck with 3.6.1922 for now. Is there a work-around? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] COM+ registration help
Neil Sleightholm wrote I'll see if I can make a simple repro first and try and come up with some ideas. dmm - can you raise a defect so this is not lost? Thanks Neil! I believe there are already a couple of bug reports / fix requests for this but I will double-check and enter one if my memory is failing ... Thanks again to you, Chris P. and RobMen for your time, attention and assistance on this. -dmm -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/COM-registration-help-tp7584402p7584577.html Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ProductFeature registry entry.
Thanks for the help, I ended up splitting them into different features and now I can install on older versions of XP. Sarvesh On 3/18/13 7:21 PM, Rob Mensching r...@robmensching.com wrote: VS2012 Ultimate shipped with 130 packages. smile/ On Mon, Mar 18, 2013 at 5:59 PM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: Depending on your upgrade plans, you can have multiple files per component. If you are always doing major upgrades, this isn't a huge ordeal (though if any non-key file gets damaged you have to send custom parameters to msiexec to force it to rewrite all the files). A second option would be to break apart the files into separate installers and bundle them together with burn. This would be a more typical approach and is a bit more complex to manage but is certainly more flexible. I believe the VS2012 beta had over 110 separate packages in it's bundle. -Original Message- From: Chinnappa, Sarvesh [Audatex - Americas] [mailto: sarvesh.chinna...@audatex.com] Sent: Monday, March 18, 2013 6:58 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ProductFeature registry entry. I was afraid you were going to say that, I am actually in the process of trying to distribute components across features since reducing them is not an option. What is the best practice in this scenario? The number of components is rather large and this would result in a lot of registry write operations during the install. Although the files need to be copied over they are not really part of the application itself and don't need to be tracked individually. Maybe a custom action that manually copies the files and deletes them during uninstall. I thought it was possible with MSIs to include a directory and everything in it as a component. I was wrong. Thanks, Sarvesh On 3/18/13 4:31 PM, Rob Mensching r...@robmensching.com wrote: Its the Feature Component mapping. Reduce the number of Components to succeed. You can also try to distrbute the Components across more Features but that only works to a certain degree. On Mon, Mar 18, 2013 at 3:42 PM, Chinnappa, Sarvesh [Audatex - Americas] sarvesh.chinna...@audatex.com wrote: Hi, I am facing an unusual problem with my installer. I will try explain in detail, may be there is a workaround for this issue. 1. The installer is rather large 5GB with a lot of files, mostly data files used by the application (a separate installer) 2. I am using heat to harvest the files with this command $(WIX)bin\heat.exe dir $(DataFiles) -cg DataFiles -gg -scom -sreg -sfrag -srd -dr INSTALLLOCATION -var env.DataFiles -out $(ProjectDir)Fragments\FilesFragment.wxs 3. When installing everything is copied and all files are in the right place. Issue: After copying the files when the MSI registers the product if fails on some XP machines. Specifically it fails to write this registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1- 5-1 8\Products\GUID\Features\ProductFeature because the data is greater than 1MB. The error reported during this is unfortunately wrong, registry is full. So the MSI tries to increase the registry size and tries to rewrite the value which fails and then it gives up. Researching on this I found that older registry formats didn't allow for values to be greater than 1MB. The questions are 1. I am guessing this is some sort of hash of the filenames. So how exactly is this generated? Anyway to control it? 2. Is there anyway to reduce the size of the entry so the install would pass? 3. Can I specify just the directory for the component and not include all the files? Would that reduce the size of the registry entry to less than 1MB. Thanks, Sarvesh Chinnappa -- --- --- PRIVILEGE AND CONFIDENTIALITY NOTICE The information in this electronic mail (and any associated attachments) is intended for the named recipient(s) only and may contain privileged and confidential information. If you have received this message in error, you are hereby notified that any use, disclosure, copying or alteration of this message is strictly prohibited. If you are not the intended recipient(s), please contact the sender by reply email and destroy all copies of the original message. Thank you. -- --- -- -- --- - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] .Net 3.5 Custom Managed Bootstrapper
Hi, I have a custom managed bootstrapped that works fine when .net 3.5 is installed. When testing the scenario where .net 3.5 is not installed burn fails to install the .net redistributable (local redistributable install). It is is the first item in the chain BootstrapperApplicationRef Id=ManagedBootstrapperApplicationHost Payload SourceFile=$(var.MyCustomInstallUI.TargetDir)MyCustomInstallUI.dll/ Payload SourceFile=$(var.MyCustomInstallUI.TargetDir)BootstrapperCore.config/ /BootstrapperApplicationRef Chain PackageGroupRef Id=Netfx35 / /Chain And defined as below. PackageGroup Id=Netfx35 ExePackage Id=Netfx35 Cache=no Compressed=yes PerMachine=yes Permanent=yes Vital=yes Name=Redist\dotnetfx35.exe SourceFile=..\Redist\dotnetfx35.exe InstallCommand=/q /norestart /lang:ENU RepairCommand=/q /norestart /lang:ENU UninstallCommand=/q /norestart /lang:ENU InstallCondition=NOT Netfx35Version OR (Netfx35Version lt; v3.5.30729.1) DetectCondition=Netfx35Version AND (Netfx35Version gt;= v3.5.30729.1) ExitCode Value =3010 Behavior=forceReboot / /ExePackage /PackageGroup The .net prerequisite installs fine if I use the standard managed bootstrapped but it doesn't when I include the custom UI. I get the standard screen where it says .net framework is required with Install option and when I click accept and install it the UI disappears, here is the log [00E0:0130][2013-03-22T13:32:09]i200: Plan begin, 2 packages, action: Install [00E0:0130][2013-03-22T13:32:09]i052: Condition 'NOT Netfx35Version OR (Netfx35Version v3.5.30729.1)' evaluates to true. [00E0:0130][2013-03-22T13:32:09]w321: Skipping dependency registration on package with no dependency providers: Netfx35 [00E0:0130][2013-03-22T13:32:09]i201: Planned package: Netfx35, state: Absent, default requested: Present, ba requested: None, execute: None, rollback: None, cache: No, uncache: No, dependency: None Not sure what I am missing. Unfortunately I can't use .Net 4.0 which I see is already defined in NetFxExtensions. Any pointers where I should I look for the problem? Thanks, Sarvesh PRIVILEGE AND CONFIDENTIALITY NOTICE The information in this electronic mail (and any associated attachments) is intended for the named recipient(s) only and may contain privileged and confidential information. If you have received this message in error, you are hereby notified that any use, disclosure, copying or alteration of this message is strictly prohibited. If you are not the intended recipient(s), please contact the sender by reply email and destroy all copies of the original message. Thank you. --- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] util:XmlConfig: can attributes be updated, or can they only be added or removed?
Hi all, Struggled with this one for the last few hours and finally found what I'd like to think is just a work-around. What I'm trying to do is add a node to an xml config during install using Node=document and then CDATA to add the whole xml element. One of the attributes is just set to a dummy value, so my next sequence step is to try to update the attribute's value with a property that holds the correct value. Along with wanting to know if there's a better way to do this, I also wanted to express that I could not find a correct set of args for XmlConfig that would allow me to update the value of the attribute. What I'm doing instead for now is to just leave the attribute out of the CDATA and then add it as my update to the element. That's working, but I can foresee a time when I'll need to update an attribute, and I'd really like to know how to do that : ) Thanks! -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to perform installation per-user or per-machine by detecting previous installation context?
Hello,
I have an installer version 1.0.0 released as per-user installation, and in
version 2.0.0(and after) I need to do per-machine installation.
When doing upgrade from 1.0.0 to 2.0.0 installation, it has problems that
the previous one cannot be uninstalled.
Finally I find msi cannot support upgrade cross install context.
So I change intsaller 2.0.0 as follows:
*case1*. New Install 2.0.0: Cannot detect per-machine flag in HKLM and find
2.0.0 is a new installtion, so cheng ALLUSERS to 1 and do pre-machine
install, and write pre-machine flag in HKLM.
*case2*. Upgrade from 1.0.0 to 2.0.0: If 1.0.0 is installed and user wants
to upgrade to 2.0.0, installers detect registry in HKLM and find no
per-machine falg(because after 2.0.0 this flag is written to HKLM), so
change ALLUSERS to and do per-user install.
*case3*. Upgrade from 2.0.0 to 3.0.0:If users installs newer version 3.0.0
in future, install detects per-machine flag in HKLM. If there is per-machine
flag, do per-machine install, and if there is no flag, do per-user install.
After these changes, I can handle the case1 and case2.
But I still get issue in case3 that 2.0.0 is not uninstalled.
I analyze the log and find 3.0.0 is per-user install and skip uninstall
2.0.0 in FindRelatedProducts.
The property ALLUSERS is changed after seraching the registry in
AppSearch. But FindRelatedProducts is before AppSearch, that means
before AppSearch 3.0.0 is per-user, so it skip 2.0.0 uninstall. After
AppSearch, 3.0.0 does per-machine installation.
log of upgrade from 2.0.0 to 3.0.0:
/ MSI (c) (4C:38) [09:58:38:093]: FindRelatedProducts: current install is
per-user. Related install for product '{OLD-PRODUCT-UID}' is per-machine.
Skipping... /
*So my question is how can perform installation per-user or per-machine by
detecting previous installation context?*
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-perform-installation-per-user-or-per-machine-by-detecting-previous-installation-context-tp7584581.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Order of Execution
Order of Components matters none. Order of actions is defined by the Sequences. On Fri, Mar 22, 2013 at 11:20 AM, George Fleming gef...@microsoft.comwrote: Running Wix 3.7, I have a feature with several ComponentGroupRef's: Feature Id=, Title=, Level=1 ComponentGroupRef Id=one / ComponentGroupRef Id=two / ... ComponentGroupRef Id=xxx / ComponentGroupRef Id=yyy / /Feature I need to yyy to execute after xxx because of a dependency (it needs to wait for IIS to start). How do I do this? I know Wix order-of-execution is unpredictable. And I know if I were doing via Custom Actions, I could order them, but I would rather not do Custom Actions if I don't have to. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setup.exe won't exit gracefully
Uhh, that is a very old build of WiX v3.6. You're probably hitting some ancient bug that we fixed in the year+ after that build was made available. smile/ On Fri, Mar 22, 2013 at 11:24 AM, George Fleming gef...@microsoft.comwrote: Running Wix 3.6.1922, I have a Setup.exe that's a custom managed boostrapper application. When I execute, I see two or three instances of Setup.exe in the Task Manager. Problem is, when the Setup.exe terminates (normally or abnormally), it almost always leaves an instance of Setup.exe still running. I have to manually use Task Manager to kill it. Any idea why this is, and how do I fix this problem? Thanks! -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] .Net 3.5 Custom Managed Bootstrapper
You probably need: WixVariable Id=WixMbaPrereqPackageId Value=Netfx35 / To tell the prereq BA to install that package when NETFX is missing. Also, you probabl want to remove your InstallCondition. On Fri, Mar 22, 2013 at 2:37 PM, Chinnappa, Sarvesh [Audatex - Americas] sarvesh.chinna...@audatex.com wrote: Hi, I have a custom managed bootstrapped that works fine when .net 3.5 is installed. When testing the scenario where .net 3.5 is not installed burn fails to install the .net redistributable (local redistributable install). It is is the first item in the chain BootstrapperApplicationRef Id=ManagedBootstrapperApplicationHost Payload SourceFile=$(var.MyCustomInstallUI.TargetDir)MyCustomInstallUI.dll/ Payload SourceFile=$(var.MyCustomInstallUI.TargetDir)BootstrapperCore.config/ /BootstrapperApplicationRef Chain PackageGroupRef Id=Netfx35 / /Chain And defined as below. PackageGroup Id=Netfx35 ExePackage Id=Netfx35 Cache=no Compressed=yes PerMachine=yes Permanent=yes Vital=yes Name=Redist\dotnetfx35.exe SourceFile=..\Redist\dotnetfx35.exe InstallCommand=/q /norestart /lang:ENU RepairCommand=/q /norestart /lang:ENU UninstallCommand=/q /norestart /lang:ENU InstallCondition=NOT Netfx35Version OR (Netfx35Version lt; v3.5.30729.1) DetectCondition=Netfx35Version AND (Netfx35Version gt;= v3.5.30729.1) ExitCode Value =3010 Behavior=forceReboot / /ExePackage /PackageGroup The .net prerequisite installs fine if I use the standard managed bootstrapped but it doesn't when I include the custom UI. I get the standard screen where it says .net framework is required with Install option and when I click accept and install it the UI disappears, here is the log [00E0:0130][2013-03-22T13:32:09]i200: Plan begin, 2 packages, action: Install [00E0:0130][2013-03-22T13:32:09]i052: Condition 'NOT Netfx35Version OR (Netfx35Version v3.5.30729.1)' evaluates to true. [00E0:0130][2013-03-22T13:32:09]w321: Skipping dependency registration on package with no dependency providers: Netfx35 [00E0:0130][2013-03-22T13:32:09]i201: Planned package: Netfx35, state: Absent, default requested: Present, ba requested: None, execute: None, rollback: None, cache: No, uncache: No, dependency: None Not sure what I am missing. Unfortunately I can't use .Net 4.0 which I see is already defined in NetFxExtensions. Any pointers where I should I look for the problem? Thanks, Sarvesh PRIVILEGE AND CONFIDENTIALITY NOTICE The information in this electronic mail (and any associated attachments) is intended for the named recipient(s) only and may contain privileged and confidential information. If you have received this message in error, you are hereby notified that any use, disclosure, copying or alteration of this message is strictly prohibited. If you are not the intended recipient(s), please contact the sender by reply email and destroy all copies of the original message. Thank you. --- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
