[WiX-users] Question regarding Burn and prerequisites (WiX 3.8)
Hello, I have recently had an epiphany regarding Burn, and have been busy writing a bundle for our installer package. Now, we have several prerequisites that needs to be installed before our own installer is executed. The .NET Framework 4.5 is a no-brainer, as a ExePackage already exists in the NetFxExtension, but how about Windows Installer 4.5? SharedManagementObjects? Sql Server 2012 Express? I realize that I can download all these and add them compressed or uncompressed directly to my bundle, but what if I do not want to redistribute these myself, but rather just add a download link, just like the NetFx45Web package. Alternatively how can I define the redists in my bundle but not include them directly in the build? But rather package them when we deploy? This way I would be able to package two different deployment packages, one for 32-bit and one for 64-bit. I have found direct links for the Sql Server Express 2012, thanks to Scott Hanselman here: http://downloadsqlserverexpress.com/ But I cannot figure out how to include them in my bundle for downloading, but not having them physically present. I have this: ExePackage Id=SqlExpress86 PerMachine=yes Permanent=yes Name=SQLEXPRWT_x86_ENU.exe Compressed=no Cache=no DownloadUrl=http://download.microsoft.com/download/8/D/D/8DD7BDBA-CEF7-4D8E-8C16-D9F69527F909/ENU/x86/SQLEXPRWT_x86_ENU.exe; DetectCondition=InstallSQL AND (NOT VersionNT64)/ It seems I need to include a RemotePayload, which requires all sorts of information regarding public keys etc. that I don't have. Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: wix-users-requ...@lists.sourceforge.net [mailto:wix-users-requ...@lists.sourceforge.net] Sent: 27. august 2014 04:58 To: wix-users@lists.sourceforge.net Subject: WiX-users Digest, Vol 99, Issue 59 Send WiX-users mailing list submissions to wix-users@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/wix-users or, via email, send a message with subject or body 'help' to wix-users-requ...@lists.sourceforge.net You can reach the person managing the list at wix-users-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of WiX-users digest... -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8)
Oh, okay, so if I do not wish to use the RemotePayload (due to the Hash requirements) I just need the prereqs for building? Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: 27. august 2014 16:11 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8) The bundle build process requires them on disk or you can satisfy this with the RemotePayload. If you specify a DownloadURL, you don't need to distribute the payload with your bundle. It will download them if and only if the payload is needed. -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: Wednesday, August 27, 2014 7:23 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question regarding Burn and prerequisites (WiX 3.8) Hello, I have recently had an epiphany regarding Burn, and have been busy writing a bundle for our installer package. Now, we have several prerequisites that needs to be installed before our own installer is executed. The .NET Framework 4.5 is a no-brainer, as a ExePackage already exists in the NetFxExtension, but how about Windows Installer 4.5? SharedManagementObjects? Sql Server 2012 Express? I realize that I can download all these and add them compressed or uncompressed directly to my bundle, but what if I do not want to redistribute these myself, but rather just add a download link, just like the NetFx45Web package. Alternatively how can I define the redists in my bundle but not include them directly in the build? But rather package them when we deploy? This way I would be able to package two different deployment packages, one for 32-bit and one for 64-bit. I have found direct links for the Sql Server Express 2012, thanks to Scott Hanselman here: http://downloadsqlserverexpress.com/ But I cannot figure out how to include them in my bundle for downloading, but not having them physically present. I have this: ExePackage Id=SqlExpress86 PerMachine=yes Permanent=yes Name=SQLEXPRWT_x86_ENU.exe Compressed=no Cache=no DownloadUrl=http://download.microsoft.com/download/8/D/D/8DD7BDBA-CEF7-4D8E-8C16-D9F69527F909/ENU/x86/SQLEXPRWT_x86_ENU.exe; DetectCondition=InstallSQL AND (NOT VersionNT64)/ It seems I need to include a RemotePayload, which requires all sorts of information regarding public keys etc. that I don't have. Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: wix-users-requ...@lists.sourceforge.net [mailto:wix-users-requ...@lists.sourceforge.net] Sent: 27. august 2014 04:58 To: wix-users@lists.sourceforge.net Subject: WiX-users Digest, Vol 99, Issue 59 Send WiX-users mailing list submissions to wix-users@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/wix-users or, via email, send a message with subject or body 'help' to wix-users-requ...@lists.sourceforge.net You can reach the person managing the list at wix-users-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of WiX-users digest... -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Chaining .NET 3.5 in Burn
Thank you :) Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: 10. januar 2014 21:13 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Chaining .NET 3.5 in Burn Niel provides the infor in his blog. http://neilsleightholm.blogspot.com/2012/05/wix-burn-tipstricks.html -- View this message in context: http://windows-installer-xml-wix- toolset.687559.n2.nabble.com/Chaining-NET-3-5-in-Burn- tp7591622p7591696.html Sent from the wix-users mailing list archive at Nabble.com. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Chaining .NET 3.5 in Burn
Hi, I am currently looking into Burn, and have a question. Our application is still using .NET 3.5, and although we fully intend to update to .NET 4.5, we are not quite ready for that yet. It seems that Burn only supports Chaining .NET 4.0 or newer. Is that correct, or is there a way of chaining .NET 3.5? Best regards, Thomas Due - Software Developer -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Possible bug in 3.8
Hello, I have tried the entire morning to register for the issue tracker on wixtoolset.org/issues, but the activation email is so long arriving, that the link has expired, so now I post here instead. I have recently upgraded to 3.8 in order to get support for VS2013. Now I just attempted to recompile my installer and got this error: Failed to open the database. During validation, this most commonly happens when attempting to open a database using an unsupported code page or a file that is not a valid Windows Installer database. Please use a different code page in Module/@Codepage, Package/@SummaryCodepage, Product/@Codepage, or WixLocalization/@Codepage; or make sure you provide the path to a valid Windows Installer database. Nothing has changed in the project. The only difference is the WiX version. The project compiles fine on the build server (WiX 3.5), but now I have the exact same issue with 3.7. I uninstalled 3.8 and installed 3.7, without restarting or anything. Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: wix-users-requ...@lists.sourceforge.net [mailto:wix-users- requ...@lists.sourceforge.net] Sent: 29. oktober 2013 11:52 To: wix-users@lists.sourceforge.net Subject: WiX-users Digest, Vol 89, Issue 114 Send WiX-users mailing list submissions to wix-users@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/wix-users or, via email, send a message with subject or body 'help' to wix-users-requ...@lists.sourceforge.net You can reach the person managing the list at wix-users-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of WiX-users digest... -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating patches
Ah gotcha. Thanks :) /Thomas -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: 22. maj 2013 19:57 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Creating patches If you want to show a dialog that's specific to patching then use PATCH as the condition in the same general way that you used the Installed property. So NOT PATCH might be a better condition in that example. PATCH is a Windows Installer property just like Installed, ProductCode, MsiRunningElevated etc. Phil -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: Tuesday, May 21, 2013 11:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating patches Would you mind expanding on that? Because I don't know what you mean... /Thomas -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: 21. maj 2013 18:58 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Creating patches I think a check for the PATCH property is more typical. Phil -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: Tuesday, May 21, 2013 6:09 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating patches I was reviewing the code again, again, again. And suddenly it occurred to me, that I was missing the product code attribute in PatchFamily. I was certain I had it in there at some point, but in my desperate attempts to getting it to work, it must have been removed at some point. Anyway, now I got it to generate a patch file. This prompt led me to the next problem. The patch file cheerfully goes through the entire dialog from the original installer. This is not really interesting to me, so how do I go about jumping from the welcome dialog to the verify ready dialog? I assume it is because my dialog next actions are defined something like this: Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=InstallDirDlg1/Publish I would need a check for Installed, right? So something like this instead: Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=InstallDirDlgNOT Installed/Publish Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=VerifyReadyDlgInstalled/Publish But how would this perform when doing a major update? /Thomas -Original Message- From: MrWiX [mailto:philipp.ew...@asamnet.de] Sent: 21. maj 2013 10:32 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Creating patches Identical file versions are definitely not the problem. (I just ran a test with WiX 3.7 and it work just fine. Only got a warning that the patch contains to files.) It looks like your wixpdb files differ in more just the version number. Even the referenced files are the same, the internal structure/names doesn't/don't seem to fit. -- View this message in context: http://windows-installer-xml-wix- toolset.687559.n2.nabble.com/Creating-patches- tp7585541p7586023.html Sent from the wix-users mailing list archive at Nabble.com. -- -- -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS- based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS- based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ WiX
Re: [WiX-users] Creating patches
Would you mind expanding on that? Because I don't know what you mean... /Thomas -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: 21. maj 2013 18:58 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Creating patches I think a check for the PATCH property is more typical. Phil -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: Tuesday, May 21, 2013 6:09 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating patches I was reviewing the code again, again, again. And suddenly it occurred to me, that I was missing the product code attribute in PatchFamily. I was certain I had it in there at some point, but in my desperate attempts to getting it to work, it must have been removed at some point. Anyway, now I got it to generate a patch file. This prompt led me to the next problem. The patch file cheerfully goes through the entire dialog from the original installer. This is not really interesting to me, so how do I go about jumping from the welcome dialog to the verify ready dialog? I assume it is because my dialog next actions are defined something like this: Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=InstallDirDlg1/Publish I would need a check for Installed, right? So something like this instead: Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=InstallDirDlgNOT Installed/Publish Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=VerifyReadyDlgInstalled/Publish But how would this perform when doing a major update? /Thomas -Original Message- From: MrWiX [mailto:philipp.ew...@asamnet.de] Sent: 21. maj 2013 10:32 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Creating patches Identical file versions are definitely not the problem. (I just ran a test with WiX 3.7 and it work just fine. Only got a warning that the patch contains to files.) It looks like your wixpdb files differ in more just the version number. Even the referenced files are the same, the internal structure/names doesn't/don't seem to fit. -- View this message in context: http://windows-installer-xml-wix- toolset.687559.n2.nabble.com/Creating-patches-tp7585541p7586023.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS- based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating patches
No, I don't think so. Is that the cause? /Thomas -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 19. maj 2013 17:08 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Creating patches On 13-May-13 02:47, Thomas Due wrote: I have built two versions of the installer, with the only real difference being the version nummer (1.2.0 and 1.2.5). Did the versions of all the files change too? -- sig://boB http://joyofsetup.com/ -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating patches
I agree, I am quite certain there is something I am missing, like a name or ID that must be identical. However, if it is documented anyway, I have failed to find it. /Thomas -Original Message- From: MrWiX [mailto:philipp.ew...@asamnet.de] Sent: 21. maj 2013 10:32 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Creating patches Identical file versions are definitely not the problem. (I just ran a test with WiX 3.7 and it work just fine. Only got a warning that the patch contains to files.) It looks like your wixpdb files differ in more just the version number. Even the referenced files are the same, the internal structure/names doesn't/don't seem to fit. -- View this message in context: http://windows-installer-xml-wix- toolset.687559.n2.nabble.com/Creating-patches-tp7585541p7586023.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating patches
I was reviewing the code again, again, again. And suddenly it occurred to me, that I was missing the product code attribute in PatchFamily. I was certain I had it in there at some point, but in my desperate attempts to getting it to work, it must have been removed at some point. Anyway, now I got it to generate a patch file. This prompt led me to the next problem. The patch file cheerfully goes through the entire dialog from the original installer. This is not really interesting to me, so how do I go about jumping from the welcome dialog to the verify ready dialog? I assume it is because my dialog next actions are defined something like this: Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=InstallDirDlg1/Publish I would need a check for Installed, right? So something like this instead: Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=InstallDirDlgNOT Installed/Publish Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=VerifyReadyDlgInstalled/Publish But how would this perform when doing a major update? /Thomas -Original Message- From: MrWiX [mailto:philipp.ew...@asamnet.de] Sent: 21. maj 2013 10:32 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Creating patches Identical file versions are definitely not the problem. (I just ran a test with WiX 3.7 and it work just fine. Only got a warning that the patch contains to files.) It looks like your wixpdb files differ in more just the version number. Even the referenced files are the same, the internal structure/names doesn't/don't seem to fit. -- View this message in context: http://windows-installer-xml-wix- toolset.687559.n2.nabble.com/Creating-patches-tp7585541p7586023.html Sent from the wix-users mailing list archive at Nabble.com. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating patches
Hello, Yes I am using 3.7 for both installers, and the patch. There seems to be a bug in 3.7 versus 3.5, but it turned out that 3.5 simply ignored the fact that the transform was empty, so it generated an empty patch. This does not alter the fact though, that I am unable to make this patch mechanism work. I have a fairly complex installer, which hundreds of files, windows services, moving existing files and one or two custom actions. I have built two versions of the installer, with the only real difference being the version nummer (1.2.0 and 1.2.5). I have then created a patch.wxs: CODE START ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; ?include ..\ScanXNETSetup\BuildVariables.wxi ? Patch AllowRemoval=yes Classification=Update Manufacturer=$(var.Manufacturer) Description=$(var.Description) DisplayName=$(var.Description) ($(var.CurVersion)) Media Id=5000 Cabinet=Patch.cab PatchBaseline Id=Patch / /Media PatchFamily Id=ApplicationPatch Supersede=yes Version=$(var.CurVersion) ComponentRef Id=ComponentCommonExtensions / ComponentRef Id=ComponentMainClient / /PatchFamily /Patch /Wix CODE END and a batch script to run it CODE START @echo off set wixdir=c:\Program Files (x86)\WiX Toolset v3.7\ set oldmsi=..\..\..\..\..\Build\Debug\OldInstaller\x86\en-us\Application.wixpdb set newmsi=..\..\..\..\..\Build\Debug\Installer\x86\en-us\Application.wixpdb set output=..\..\..\..\..\Build\Debug\Patch\ del /f /q %output%*.* %wixdir%bin\torch.exe -p -xi %oldmsi% %newmsi% -v -out %output%diff.wixmst %wixdir%bin\candle.exe -v Patch.wxs %wixdir%bin\Light.exe -v Patch.wixobj -out %output%patch.wixmsp %wixdir%bin\pyro.exe -v %output%patch.wixmsp -out %output%patch.msp -t ApplicationPatch %output%diff.wixmst CODE END But I get errors every time, regardless of what I do. This generates the following output: pyro.exe : error PYRO0252 : No valid transforms were provided to attach to the patch. Check to make sure the transforms you passed on the command line have a matching baseline authored in the patch. Also, make sure there are differences between your target and upgrade. I have a feeling that I have an ID mismatch somewhere, but I cannot figure out where. /Thomas -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 9. maj 2013 16:54 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating patches Are you using a different version of the WiX toolset to patch than what was used to build the MSIs? That's not technically supported since there are a lot of fine details that can go awry. However, that error message is not terribly helpful and a bug certainly would in order for it. On Tue, May 7, 2013 at 2:29 AM, Thomas Due t...@scanvaegt.dk wrote: Hello, I am still looking for an answer to this problem. I have two versions of my MSI installer, the only true difference is the version number. I have a patch.wxs script which identitifies a couple of components which are supposedly changed. In reality no file have been changed, except for their version number. When I execute the tools sequence described in Nick Ramirez' book and the WiX manual, nothing constructive happens. Both Torch and Pyro gives me errors, shown below. I am pretty much clueless as to what I am doing wrong, mainly because neither the manual or the book properly explains WHAT I need to do, and WHY. Mainly they just show me HOW. Is any able to help get past this issue? /Thomas Due -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 3. maj 2013 09:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating patches I have now modified my build script to use a locally build msi installer and comparing it with a version build on my build server yesterday. There is no practical difference between the two msi files except the version numbers. Is that why I keep getting errors? I get the following error from Torch: error TRCH0279 : The table definition of 'WixVariable' in the target database does not match the table definition in the updated database. A transform requires that the target database schema match the updated database schema. And I get this from Pyro: Updating file information. Creating cabinet files. There will be '8' threads used to produce CAB files. MinorUpdate\Patch.wxs(13) : warning PYRO1079 : The cabinet Patch.cab' does not contain any files. If this patch contains
Re: [WiX-users] Creating patches
Hello, I am still looking for an answer to this problem. I have two versions of my MSI installer, the only true difference is the version number. I have a patch.wxs script which identitifies a couple of components which are supposedly changed. In reality no file have been changed, except for their version number. When I execute the tools sequence described in Nick Ramirez' book and the WiX manual, nothing constructive happens. Both Torch and Pyro gives me errors, shown below. I am pretty much clueless as to what I am doing wrong, mainly because neither the manual or the book properly explains WHAT I need to do, and WHY. Mainly they just show me HOW. Is any able to help get past this issue? /Thomas Due -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 3. maj 2013 09:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating patches I have now modified my build script to use a locally build msi installer and comparing it with a version build on my build server yesterday. There is no practical difference between the two msi files except the version numbers. Is that why I keep getting errors? I get the following error from Torch: error TRCH0279 : The table definition of 'WixVariable' in the target database does not match the table definition in the updated database. A transform requires that the target database schema match the updated database schema. And I get this from Pyro: Updating file information. Creating cabinet files. There will be '8' threads used to produce CAB files. MinorUpdate\Patch.wxs(13) : warning PYRO1079 : The cabinet Patch.cab' does not contain any files. If this patch contains no files, this warning can likely be safely ignored. Otherwise, try passing -p to torch.exe when first building the transforms, or add a ComponentRef to your PatchFamily authoring to pull changed files into the cabinet. Creating cabinet 'AppData\Local\Temp\q0qw3fj2\#Patch.cab'. Generating database. pyro.exe : error PYRO0001 : Cannot set column 'Protocol' with value 1 because it is less than the minimum allowed value for this column, 6. Exception Type: System.InvalidOperationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Objec t value) at Microsoft.Tools.WindowsInstallerXml.Row.set_Item(Int32 field, Object value) at Microsoft.Tools.WindowsInstallerXml.Binder.BindTransform(Output transform, String transformFile) at Microsoft.Tools.WindowsInstallerXml.Binder.GenerateDatabase(Output output, String databaseFile, Boolean keepAddedColumns, Boolean useSubdirectory) at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output output, String databaseFile) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file) at Microsoft.Tools.WindowsInstallerXml.Tools.Pyro.Run(String[] args) Any help will be appreciated. /Thomas Due -Original Message- From: uni [mailto:unigauld...@gmail.com] Sent: 2. maj 2013 12:07 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating patches 于02 May 2013 17:31:10,Thomas Due写到: Hello, I am trying to grasp the concept of minor and small upgrades, but I am having some trouble with getting it to work. First of all, it doesn't seem to work at all with 3.7. I have downgraded my WiX to 3.5, and there something happens at least, but my msp seems to be empty when I examine it with instead (http://www.instedit.com/). A bit about what I do: I have a fairly complex installer with a couple of hundred files total, divided among 4 features. I build this with TeamCity, and I have two separate installers (no real changes, except for the version nummer - 1.2.0.22679 and 1.2.5.22754). I imagine that this should be enough to generate something. I have a build script, a simple batch file, which executes the four steps described in both the WiX doc and Nick Ramirez' book. My patch.wxs then includes a couple of file components, as I want these replaces (mind you, I am still in the testing phase, trying to understand the concept). First my build script: === %wixdir%bin\torch.exe -p -xi %oldmsi% %newmsi% -v -out diff.wixmst %wixdir%bin\candle.exe -v Patch.wxs %wixdir%bin\Light.exe -v Patch.wixobj -out patch.wixmsp %wixdir%bin\pyro.exe -v patch.wixmsp -out patch.msp -t Patch diff.wixmst %oldmsi% and %newmsi are complete paths to the wixpdb files for respectively old and new installer. Then my Patch.wsx: === ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; ?include BuildVariables.wxi ? Patch AllowRemoval=yes Classification=Update Manufacturer=$(var.Manufacturer
Re: [WiX-users] Creating patches
I have now modified my build script to use a locally build msi installer and comparing it with a version build on my build server yesterday. There is no practical difference between the two msi files except the version numbers. Is that why I keep getting errors? I get the following error from Torch: error TRCH0279 : The table definition of 'WixVariable' in the target database does not match the table definition in the updated database. A transform requires that the target database schema match the updated database schema. And I get this from Pyro: Updating file information. Creating cabinet files. There will be '8' threads used to produce CAB files. MinorUpdate\Patch.wxs(13) : warning PYRO1079 : The cabinet Patch.cab' does not contain any files. If this patch contains no files, this warning can likely be safely ignored. Otherwise, try passing -p to torch.exe when first building the transforms, or add a ComponentRef to your PatchFamily authoring to pull changed files into the cabinet. Creating cabinet 'AppData\Local\Temp\q0qw3fj2\#Patch.cab'. Generating database. pyro.exe : error PYRO0001 : Cannot set column 'Protocol' with value 1 because it is less than the minimum allowed value for this column, 6. Exception Type: System.InvalidOperationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object value) at Microsoft.Tools.WindowsInstallerXml.Row.set_Item(Int32 field, Object value) at Microsoft.Tools.WindowsInstallerXml.Binder.BindTransform(Output transform, String transformFile) at Microsoft.Tools.WindowsInstallerXml.Binder.GenerateDatabase(Output output, String databaseFile, Boolean keepAddedColumns, Boolean useSubdirectory) at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output output, String databaseFile) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file) at Microsoft.Tools.WindowsInstallerXml.Tools.Pyro.Run(String[] args) Any help will be appreciated. /Thomas Due -Original Message- From: uni [mailto:unigauld...@gmail.com] Sent: 2. maj 2013 12:07 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating patches 于02 May 2013 17:31:10,Thomas Due写到: Hello, I am trying to grasp the concept of minor and small upgrades, but I am having some trouble with getting it to work. First of all, it doesn't seem to work at all with 3.7. I have downgraded my WiX to 3.5, and there something happens at least, but my msp seems to be empty when I examine it with instead (http://www.instedit.com/). A bit about what I do: I have a fairly complex installer with a couple of hundred files total, divided among 4 features. I build this with TeamCity, and I have two separate installers (no real changes, except for the version nummer - 1.2.0.22679 and 1.2.5.22754). I imagine that this should be enough to generate something. I have a build script, a simple batch file, which executes the four steps described in both the WiX doc and Nick Ramirez' book. My patch.wxs then includes a couple of file components, as I want these replaces (mind you, I am still in the testing phase, trying to understand the concept). First my build script: === %wixdir%bin\torch.exe -p -xi %oldmsi% %newmsi% -v -out diff.wixmst %wixdir%bin\candle.exe -v Patch.wxs %wixdir%bin\Light.exe -v Patch.wixobj -out patch.wixmsp %wixdir%bin\pyro.exe -v patch.wixmsp -out patch.msp -t Patch diff.wixmst %oldmsi% and %newmsi are complete paths to the wixpdb files for respectively old and new installer. Then my Patch.wsx: === ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; ?include BuildVariables.wxi ? Patch AllowRemoval=yes Classification=Update Manufacturer=$(var.Manufacturer) Description=Patch DisplayName=Patch $(var.CurVersion) Media Id=1000 Cabinet=´Patch.cab EmbedCab=yes PatchBaseline Id=Patch / /Media PatchFamily Id=ScanXNETPatchFamily Version=$(var.CurVersion) Supersede=yes ComponentRef Id=ComponentCommonExtensions / ComponentRef Id=ComponentMainClient/ /PatchFamily /Patch /Wix BuildVariables.wxi is simply a number of preprocessor variables, which is shared with the installer project. Now, as I said, with 3.7 I get this result: Updating file information. Creating cabinet files. There will be '8' threads used to produce CAB files. Patch.wxs(20) : warning PYRO1079 : The cabinet 'ïPatch.cab' does not contain any files. If this patch contains no files, this warning can likely be safely ignored. Otherwise, try passing -p to torch.exe when first building the transforms, or add a ComponentRef to your
[WiX-users] Creating patches
Hello, I am trying to grasp the concept of minor and small upgrades, but I am having some trouble with getting it to work. First of all, it doesn't seem to work at all with 3.7. I have downgraded my WiX to 3.5, and there something happens at least, but my msp seems to be empty when I examine it with instead (http://www.instedit.com/). A bit about what I do: I have a fairly complex installer with a couple of hundred files total, divided among 4 features. I build this with TeamCity, and I have two separate installers (no real changes, except for the version nummer - 1.2.0.22679 and 1.2.5.22754). I imagine that this should be enough to generate something. I have a build script, a simple batch file, which executes the four steps described in both the WiX doc and Nick Ramirez' book. My patch.wxs then includes a couple of file components, as I want these replaces (mind you, I am still in the testing phase, trying to understand the concept). First my build script: === %wixdir%bin\torch.exe -p -xi %oldmsi% %newmsi% -v -out diff.wixmst %wixdir%bin\candle.exe -v Patch.wxs %wixdir%bin\Light.exe -v Patch.wixobj -out patch.wixmsp %wixdir%bin\pyro.exe -v patch.wixmsp -out patch.msp -t Patch diff.wixmst %oldmsi% and %newmsi are complete paths to the wixpdb files for respectively old and new installer. Then my Patch.wsx: === ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi ?include BuildVariables.wxi ? Patch AllowRemoval=yes Classification=Update Manufacturer=$(var.Manufacturer) Description=Patch DisplayName=Patch $(var.CurVersion) Media Id=1000 Cabinet=´Patch.cab EmbedCab=yes PatchBaseline Id=Patch / /Media PatchFamily Id=ScanXNETPatchFamily Version=$(var.CurVersion) Supersede=yes ComponentRef Id=ComponentCommonExtensions / ComponentRef Id=ComponentMainClient/ /PatchFamily /Patch /Wix BuildVariables.wxi is simply a number of preprocessor variables, which is shared with the installer project. Now, as I said, with 3.7 I get this result: Updating file information. Creating cabinet files. There will be '8' threads used to produce CAB files. Patch.wxs(20) : warning PYRO1079 : The cabinet 'ïPatch.cab' does not contain any files. If this patch contains no files, this warning can likely be safely ignored. Otherwise, try passing -p to torch.exe when first building the transforms, or add a ComponentRef to your PatchFamily authoring to pull changed files into the cabinet. Creating cabinet '\Local\Temp\kvov1bbk\#ïPatch.cab'. Generating database. diff.wixmst : error PYRO0227 : The transform being built did not contain any differences so it could not be created. Which is probably an indication of what is actually wrong. With 3.5 I get an empty msp. What am I doing wrong? -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating patches
Update: I discovered that I had a wrong PatchBaseline Id, I fixed this so it is equal to the installer, and got this error instead: pyro.exe : error PYRO0252 : No valid transforms were provided to attach to the patch. Check to make sure the transforms you passed on the command line have a matching baseline authored in the patch. Also, make sure there are differences between your target and upgrade. /Thomas Due -Original Message- From: Thomas Due Sent: 2. maj 2013 11:31 To: 'wix-users@lists.sourceforge.net' Subject: Creating patches Hello, I am trying to grasp the concept of minor and small upgrades, but I am having some trouble with getting it to work. First of all, it doesn't seem to work at all with 3.7. I have downgraded my WiX to 3.5, and there something happens at least, but my msp seems to be empty when I examine it with instead (http://www.instedit.com/). A bit about what I do: I have a fairly complex installer with a couple of hundred files total, divided among 4 features. I build this with TeamCity, and I have two separate installers (no real changes, except for the version nummer - 1.2.0.22679 and 1.2.5.22754). I imagine that this should be enough to generate something. I have a build script, a simple batch file, which executes the four steps described in both the WiX doc and Nick Ramirez' book. My patch.wxs then includes a couple of file components, as I want these replaces (mind you, I am still in the testing phase, trying to understand the concept). First my build script: === %wixdir%bin\torch.exe -p -xi %oldmsi% %newmsi% -v -out diff.wixmst %wixdir%bin\candle.exe -v Patch.wxs %wixdir%bin\Light.exe -v Patch.wixobj -out patch.wixmsp %wixdir%bin\pyro.exe -v patch.wixmsp - out patch.msp -t Patch diff.wixmst %oldmsi% and %newmsi are complete paths to the wixpdb files for respectively old and new installer. Then my Patch.wsx: === ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi ?include BuildVariables.wxi ? Patch AllowRemoval=yes Classification=Update Manufacturer=$(var.Manufacturer) Description=Patch DisplayName=Patch $(var.CurVersion) Media Id=1000 Cabinet=´Patch.cab EmbedCab=yes PatchBaseline Id=Patch / /Media PatchFamily Id=ScanXNETPatchFamily Version=$(var.CurVersion) Supersede=yes ComponentRef Id=ComponentCommonExtensions / ComponentRef Id=ComponentMainClient/ /PatchFamily /Patch /Wix BuildVariables.wxi is simply a number of preprocessor variables, which is shared with the installer project. Now, as I said, with 3.7 I get this result: Updating file information. Creating cabinet files. There will be '8' threads used to produce CAB files. Patch.wxs(20) : warning PYRO1079 : The cabinet 'ïPatch.cab' does not contain any files. If this patch contains no files, this warning can likely be safely ignored. Otherwise, try passing -p to torch.exe when first building the transforms, or add a ComponentRef to your PatchFamily authoring to pull changed files into the cabinet. Creating cabinet '\Local\Temp\kvov1bbk\#ïPatch.cab'. Generating database. diff.wixmst : error PYRO0227 : The transform being built did not contain any differences so it could not be created. Which is probably an indication of what is actually wrong. With 3.5 I get an empty msp. What am I doing wrong? -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Executing an application after installation
Ok, I get that. As I wrote it is at worst a minor inconvenience. However, I still need to know how I pass a command-line argument to the application I run on ExitDialog exit. TIA Thomas -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: 18. oktober 2011 04:53 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Executing an application after installation On 13-Oct-11 04:55, Thomas Due wrote: However since my installer requires elevated priviliges I don't understand why it is not possible to run the application. MSI UI isn't elevated, even if the rest of the install is. -- sig://boB http://joyofsetup.com/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Executing an application after installation
Yeah, I found it here though: http://wix.sourceforge.net/manual-wix3/run_program_after_install.htm And I can see it does it in a different way, so I will test this and see if it solves my problem. A question though: I need to pass one or more parameters to the application as command-line parameters. How do I do that? I have this: Component Id=ComponentMainConfig Guid=* DiskId=1 File Id=MasterConfig Source=$(var.BuildPath)ScanXNET\MasterConfig.exe KeyPath=yes/ /Component ... Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchConfig Order=999NOT Installed/Publish ... Property Id=WixShellExecTarget Value=[#MasterConfig] / CustomAction Id=LaunchConfig BinaryKey=WixCA DllEntry=WixShellExec Impersonate=yes / Do I simply add the parameters to the property value, like this: Value=[#MasterConfig] -lan=[INSTALLLANGUAGE] Thanks, Thomas Due -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: 14. oktober 2011 15:06 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Executing an application after installation Interesting, the link How To: Run the Installed Application After Setup seems to be dead in the wix.chm. -- John M. Cooper -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: Friday, October 14, 2011 4:07 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Executing an application after installation Hello, I can't seem to find it in the docs? /Thomas Due -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 13. oktober 2011 15:55 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Executing an application after installation Did the WiX documentation not help you? This case is explicitly called out. On Thu, Oct 13, 2011 at 1:55 AM, Thomas Due t...@scanvaegt.dk wrote: Hello, I have a configuration application that I wish to run always after my installer have completed. I don't want to have the application start until I close the installer. The application is installed into the INSTALLDIR location. The custom action is defined like this: CustomAction Id=LaunchConfig FileKey=MasterConfig Return=asyncNoWait / And called when the ExitDialog exits: Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchConfig Order=999 NOT Installed/Publish This works like a charm in Windows XP, but in Windows 7 (with the UAC enabled) nothing happens. I assume that the UAC somehow blocks this action, which is what it is supposed to do normally, I guess. However since my installer requires elevated priviliges I don't understand why it is not possible to run the application. What can I do to ensure that the application will always execute, even on Windows 7 with the UAC enabled? Thank you, Thomas Due -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct
Re: [WiX-users] Executing an application after installation
Hello, It works, I had hoped that the shell execution had inherited the privileges from the installer, so I didn't have to accept that the application ran (it requires elevated privileges). That is not the problem, it is at worst a minor nuisance. However, I need to pass at least one command-line argument to the application, like I wrote below, but the way I illustrated it does not work. I just got a 2896 error. So using the method described, how do I pass one or more command-line arguments to the application from the installer? Thanks, Thomas Due -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 17. oktober 2011 08:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Executing an application after installation Yeah, I found it here though: http://wix.sourceforge.net/manual-wix3/run_program_after_install.htm And I can see it does it in a different way, so I will test this and see if it solves my problem. A question though: I need to pass one or more parameters to the application as command-line parameters. How do I do that? I have this: Component Id=ComponentMainConfig Guid=* DiskId=1 File Id=MasterConfig Source=$(var.BuildPath)ScanXNET\MasterConfig.exe KeyPath=yes/ /Component ... Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchConfig Order=999NOT Installed/Publish ... Property Id=WixShellExecTarget Value=[#MasterConfig] / CustomAction Id=LaunchConfig BinaryKey=WixCA DllEntry=WixShellExec Impersonate=yes / Do I simply add the parameters to the property value, like this: Value=[#MasterConfig] -lan=[INSTALLLANGUAGE] Thanks, Thomas Due -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: 14. oktober 2011 15:06 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Executing an application after installation Interesting, the link How To: Run the Installed Application After Setup seems to be dead in the wix.chm. -- John M. Cooper -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: Friday, October 14, 2011 4:07 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Executing an application after installation Hello, I can't seem to find it in the docs? /Thomas Due -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 13. oktober 2011 15:55 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Executing an application after installation Did the WiX documentation not help you? This case is explicitly called out. On Thu, Oct 13, 2011 at 1:55 AM, Thomas Due t...@scanvaegt.dk wrote: Hello, I have a configuration application that I wish to run always after my installer have completed. I don't want to have the application start until I close the installer. The application is installed into the INSTALLDIR location. The custom action is defined like this: CustomAction Id=LaunchConfig FileKey=MasterConfig Return=asyncNoWait / And called when the ExitDialog exits: Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchConfig Order=999 NOT Installed/Publish This works like a charm in Windows XP, but in Windows 7 (with the UAC enabled) nothing happens. I assume that the UAC somehow blocks this action, which is what it is supposed to do normally, I guess. However since my installer requires elevated priviliges I don't understand why it is not possible to run the application. What can I do to ensure that the application will always execute, even on Windows 7 with the UAC enabled? Thank you, Thomas Due -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted
Re: [WiX-users] Executing an application after installation
Hello, I can't seem to find it in the docs? /Thomas Due -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 13. oktober 2011 15:55 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Executing an application after installation Did the WiX documentation not help you? This case is explicitly called out. On Thu, Oct 13, 2011 at 1:55 AM, Thomas Due t...@scanvaegt.dk wrote: Hello, I have a configuration application that I wish to run always after my installer have completed. I don't want to have the application start until I close the installer. The application is installed into the INSTALLDIR location. The custom action is defined like this: CustomAction Id=LaunchConfig FileKey=MasterConfig Return=asyncNoWait / And called when the ExitDialog exits: Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchConfig Order=999 NOT Installed/Publish This works like a charm in Windows XP, but in Windows 7 (with the UAC enabled) nothing happens. I assume that the UAC somehow blocks this action, which is what it is supposed to do normally, I guess. However since my installer requires elevated priviliges I don't understand why it is not possible to run the application. What can I do to ensure that the application will always execute, even on Windows 7 with the UAC enabled? Thank you, Thomas Due -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Executing an application after installation
Hello, I have a configuration application that I wish to run always after my installer have completed. I don't want to have the application start until I close the installer. The application is installed into the INSTALLDIR location. The custom action is defined like this: CustomAction Id=LaunchConfig FileKey=MasterConfig Return=asyncNoWait / And called when the ExitDialog exits: Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchConfig Order=999 NOT Installed/Publish This works like a charm in Windows XP, but in Windows 7 (with the UAC enabled) nothing happens. I assume that the UAC somehow blocks this action, which is what it is supposed to do normally, I guess. However since my installer requires elevated priviliges I don't understand why it is not possible to run the application. What can I do to ensure that the application will always execute, even on Windows 7 with the UAC enabled? Thank you, Thomas Due -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Sharing file components between directories
Hello, I am wondering about file components and directories. As I understand it, I have to point any component containing a file towards a named directory. But what if I need a file in several directories? Currently I am thinking about making two separate installers with a common wix library containing the files each have in common. But I would rather have a single installer and then handle the separation through features. But how do I handle multiple installationpoints for some files? Thanks, Thomas Due -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] GUID vs. * for components (Was: RE: WiX-users Digest, Vol 64, Issue 49)
Rob, That was a most thorough answer, thank you very much. My questions (regarding THIS subject) has been fully answered. Med venlig hilsen / Best regards Thomas Due Software udvikler Scanvaegt Nordic A/S Fra: Rob Mensching [r...@robmensching.com] Sendt: 27. september 2011 14:50 Til: General discussion for Windows Installer XML toolset. Emne: Re: [WiX-users] GUID vs. * for components (Was: RE: WiX-users Digest, Vol 64, Issue 49) Well, my opinion is my opinion. People are welcome to disagree with my opinion smile/ For example, a few people around here (including some clients) disagree with me whether MajorUpgrade/@AllowSameVersionUpgrades is a good thing or not. It's only when something *really* doesn't work and people want to disagree that the world has issues. smile/ Anyway, to answer your question. The advantage of * GUID over explicit GUID is that you don't have to provide a GUID. IN WiX v3.6 we've gone as far as to make the Component/@Guidoptional so you can leave the attribute off completely and get the * GUID behavior. Previously (before WiX v3.5, I think) we did not provide the option of * GUID because we did not have a mechanism to maintain a stable GUID across builds. It was a really gnarly problem that took us a while to finally come up with a (IMHO) really nice solution. Basically, the GUID is generated from a hash of the *target path* of the KeyPath of the Component. If the target path changes, the GUID changes. This aligns perfectly with the Component Rules ( http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101) as long as you don't change the other resources in there. That's where most of the restrictions come from. To really understand I suggest reading that link above. If you have already shipped then you need to keep the same GUIDs unless you change the Component in such a way that a new GUID is required (see how * might be nicer, you don't have to think about that). If you do an early MajorUpgrade (afterInstallValidate or afterInstallInitialize) then you can change all your GUIDs as long as nothing is shared with other products (again, see how * is much nicer, you don't have to think about that either). The Component Rules are a pain. But they are the foundation of the Windows Installer so understanding them has a lot of value. smile/ -- virtually, Rob Mensching - http://RobMensching.com LLC On Mon, Sep 26, 2011 at 10:12 PM, Thomas Due t...@scanvaegt.dk wrote: And I would think your opinion carries at least SOME weight on the issue *grin* A follow up question though, I have a hard time understanding the difference of the two. All the documentation is a bit on thin side, or I do simply not understand the issue. So, to refrase, what are the advantages to using * opposed to GUIDS? And vice-versa. In my current situation I have two installers sharing a wixlib with several components in it. Now, one of the installers have been in production use for some time, but we are using a major upgrade model everytime. So, is there any danger in changing all the component GUIDs to *? Med venlig hilsen / Best regards Thomas Due Software udvikler Scanvaegt Nordic A/S -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 26. september 2011 15:44 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX-users Digest, Vol 64, Issue 49 Either is actually an option (because the file paths will be changing, presumably). I would use the * GUID, but I try to use * GUID for everything. On Mon, Sep 26, 2011 at 6:21 AM, Thomas Due t...@scanvaegt.dk wrote: Hello, I am currently struggling with two installer packages. One is done, and the other is coming along nicely. However, the applications they each install shares a set of assemblies which I am thinking of putting in a common wix library. Each installer will install the assemblies into separate folders, so each assembly has the potential to be installed once by each installer. It would be ideal to install these to a common location, but that would require som restructuring and redesign of our application, so that is not an option at the moment. Now my question is: If a set of assemblies is shared by two different installers, what would be the best way to set the GUID on the components containing these assemblies? Should I set a fixed GUID, or use an *? Med venlig hilsen / Best regards Thomas Due Software udvikler Scanvaegt Nordic A/S Fra: wix-users-requ...@lists.sourceforge.net [ wix-users-requ...@lists.sourceforge.net] Sendt: 26. september 2011 13:40 Til: wix-users@lists.sourceforge.net Emne: WiX-users Digest, Vol 64, Issue 49 Send WiX-users mailing list submissions to wix-users@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https
Re: [WiX-users] WiX-users Digest, Vol 64, Issue 49
Hello, I am currently struggling with two installer packages. One is done, and the other is coming along nicely. However, the applications they each install shares a set of assemblies which I am thinking of putting in a common wix library. Each installer will install the assemblies into separate folders, so each assembly has the potential to be installed once by each installer. It would be ideal to install these to a common location, but that would require som restructuring and redesign of our application, so that is not an option at the moment. Now my question is: If a set of assemblies is shared by two different installers, what would be the best way to set the GUID on the components containing these assemblies? Should I set a fixed GUID, or use an *? Med venlig hilsen / Best regards Thomas Due Software udvikler Scanvaegt Nordic A/S Fra: wix-users-requ...@lists.sourceforge.net [wix-users-requ...@lists.sourceforge.net] Sendt: 26. september 2011 13:40 Til: wix-users@lists.sourceforge.net Emne: WiX-users Digest, Vol 64, Issue 49 Send WiX-users mailing list submissions to wix-users@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/wix-users or, via email, send a message with subject or body 'help' to wix-users-requ...@lists.sourceforge.net You can reach the person managing the list at wix-users-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of WiX-users digest... -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] GUID vs. * for components (Was: RE: WiX-users Digest, Vol 64, Issue 49)
And I would think your opinion carries at least SOME weight on the issue *grin* A follow up question though, I have a hard time understanding the difference of the two. All the documentation is a bit on thin side, or I do simply not understand the issue. So, to refrase, what are the advantages to using * opposed to GUIDS? And vice-versa. In my current situation I have two installers sharing a wixlib with several components in it. Now, one of the installers have been in production use for some time, but we are using a major upgrade model everytime. So, is there any danger in changing all the component GUIDs to *? Med venlig hilsen / Best regards Thomas Due Software udvikler Scanvaegt Nordic A/S -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 26. september 2011 15:44 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX-users Digest, Vol 64, Issue 49 Either is actually an option (because the file paths will be changing, presumably). I would use the * GUID, but I try to use * GUID for everything. On Mon, Sep 26, 2011 at 6:21 AM, Thomas Due t...@scanvaegt.dk wrote: Hello, I am currently struggling with two installer packages. One is done, and the other is coming along nicely. However, the applications they each install shares a set of assemblies which I am thinking of putting in a common wix library. Each installer will install the assemblies into separate folders, so each assembly has the potential to be installed once by each installer. It would be ideal to install these to a common location, but that would require som restructuring and redesign of our application, so that is not an option at the moment. Now my question is: If a set of assemblies is shared by two different installers, what would be the best way to set the GUID on the components containing these assemblies? Should I set a fixed GUID, or use an *? Med venlig hilsen / Best regards Thomas Due Software udvikler Scanvaegt Nordic A/S Fra: wix-users-requ...@lists.sourceforge.net [ wix-users-requ...@lists.sourceforge.net] Sendt: 26. september 2011 13:40 Til: wix-users@lists.sourceforge.net Emne: WiX-users Digest, Vol 64, Issue 49 Send WiX-users mailing list submissions to wix-users@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/wix-users or, via email, send a message with subject or body 'help' to wix-users-requ...@lists.sourceforge.net You can reach the person managing the list at wix-users-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of WiX-users digest... -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Best practice for making dependent installers
No one? /Thomas Due -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 11. februar 2011 09:00 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Best practice for making dependent installers Hi, I am maintaining the installer for our main product. This product is extensible and I was wondering how I would go about making installers for our extensions? What I would like is for the extension installers to refuse being installed if the main application isn't installed. Furthermore I would like the extension installers to be removed if the main application is removed, but NOT if it is being upgraded. Currently I am not using patching or minor upgrades, only major upgrades for our main product. What we do today is essentially copying the extension assemblies into the folder of the main application, and then it automatically detects the new extensions and loads them (after a restart). Sometimes we need to tweak or change some settings which we then do either by hand, or by a small application designed to handle the specific settings. I would really like a general scheme for deployment extensions, but my knowledge and understanding of WiX and MSI is not so complete that I can think my way through the problem on my own. So I turn to you for some tips, guidelines and suggestions? I am happy to provide more information should it be needed. /Thomas Due -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Best practice for making dependent installers
Hi, I am maintaining the installer for our main product. This product is extensible and I was wondering how I would go about making installers for our extensions? What I would like is for the extension installers to refuse being installed if the main application isn't installed. Furthermore I would like the extension installers to be removed if the main application is removed, but NOT if it is being upgraded. Currently I am not using patching or minor upgrades, only major upgrades for our main product. What we do today is essentially copying the extension assemblies into the folder of the main application, and then it automatically detects the new extensions and loads them (after a restart). Sometimes we need to tweak or change some settings which we then do either by hand, or by a small application designed to handle the specific settings. I would really like a general scheme for deployment extensions, but my knowledge and understanding of WiX and MSI is not so complete that I can think my way through the problem on my own. So I turn to you for some tips, guidelines and suggestions? I am happy to provide more information should it be needed. /Thomas Due -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] A couple of questions regarding sql server and wix installer
Hmm, that looks promising. I will look into it, however assuming that I don't want to include any third-party components (not saying that I don't, just assuming), is what I want doable without a lot of work? Thanks, Thomas Due -Original Message- From: dB. [mailto:dbl...@dblock.org] Sent: 23. oktober 2010 16:22 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] A couple of questions regarding sql server and wix installer This might be helpful: http://code.dblock.org/ShowPost.aspx?id=100. We use another set of extensions, the one described in my post handles your scenario properly, and we keep our schema incremental, so it figures out which version of the database it's looking at and generates an upgrade script from there. -dB. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: Thursday, October 21, 2010 2:40 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] A couple of questions regarding sql server and wix installer I am maintaining the installer for our software, and so far I have a pretty simple installer which copies the files, registrers the windows services and creates a couple of shortcuts. No big deal. Now I am beginning to get to the more complex stuff though, like maintaining a database. I have experimented a bit with this, and found a way to create the database and run a script. However, the way I understand it, this script will actually create the database (through a sql user login with permissions to create a database): Component Id=CreateDB Guid=* DiskId=1 KeyPath=yes Condition![CDATA[(NOT Installed) AND (DATABASEAUTH=0)]]/Condition Util:User Id=DBUser Name=[DATABASEUSER] Password=[DATABASEPWD]/ !-- Create the database -- Sql:SqlDatabase Id=CreateDatabase Server=[DATABASESERVER] Database=[DATABASENAME] User=DBUser CreateOnInstall=yes ConfirmOverwrite=no !-- Run the script to create tables -- Sql:SqlScript Id=CreateDB ExecuteOnInstall=yes BinaryKey=CreateDBScript Sequence=3 ContinueOnError=no/ !-- Run any updates -- Sql:SqlScript Id=UpdateDB ExecuteOnInstall=yes BinaryKey=UpdateDBScript Sequence=4 ContinueOnError=no/ !-- Insert static data -- Sql:SqlScript Id=InsertData ExecuteOnInstall=yes BinaryKey=InsertDataScript Sequence=4 ContinueOnError=no/ /Sql:SqlDatabase /Component However, how would I formulate this if the database already exists? Can I only handle that sort of thing in the actual script, or does the SqlWixExtension give me any tools to work with? Thanks, Thomas Due -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] A couple of questions regarding sql server and wix installer
I am maintaining the installer for our software, and so far I have a pretty simple installer which copies the files, registrers the windows services and creates a couple of shortcuts. No big deal. Now I am beginning to get to the more complex stuff though, like maintaining a database. I have experimented a bit with this, and found a way to create the database and run a script. However, the way I understand it, this script will actually create the database (through a sql user login with permissions to create a database): Component Id=CreateDB Guid=* DiskId=1 KeyPath=yes Condition![CDATA[(NOT Installed) AND (DATABASEAUTH=0)]]/Condition Util:User Id=DBUser Name=[DATABASEUSER] Password=[DATABASEPWD]/ !-- Create the database -- Sql:SqlDatabase Id=CreateDatabase Server=[DATABASESERVER] Database=[DATABASENAME] User=DBUser CreateOnInstall=yes ConfirmOverwrite=no !-- Run the script to create tables -- Sql:SqlScript Id=CreateDB ExecuteOnInstall=yes BinaryKey=CreateDBScript Sequence=3 ContinueOnError=no/ !-- Run any updates -- Sql:SqlScript Id=UpdateDB ExecuteOnInstall=yes BinaryKey=UpdateDBScript Sequence=4 ContinueOnError=no/ !-- Insert static data -- Sql:SqlScript Id=InsertData ExecuteOnInstall=yes BinaryKey=InsertDataScript Sequence=4 ContinueOnError=no/ /Sql:SqlDatabase /Component However, how would I formulate this if the database already exists? Can I only handle that sort of thing in the actual script, or does the SqlWixExtension give me any tools to work with? Thanks, Thomas Due -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX book available
Got my copy yesterday, and have already devoured the first two chapters. So far I have learned at least one new thing I didn't know per chapter, and confirmed some of my practices. Definitely a great piece of work :) /Thomas -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Stopping services on uninstall
I currently work (as you all probably know by now) on an installer for our software. Now I have a new problem which I need a bit of input on. My installer installs five windows services. This is all good and the services are installed correctly. They are not started for various reasons, but this has been tested and that works as well, should it be necessary. Uninstallation, however, is giving me a bit of a problem. On Windows XP there is nothing wrong, and the services are stopped and uninstalled fine. On Windows 7, however I get a warning that the installer will have to reboot when done. If I stop the services manually, there is not problems, then it uninstalls beautifully. In other words, it seems that the installer cannot stop the services when uninstalling on Windows 7. This is true regardless of whether I uninstall from Programs and Features og directly through call to msiexec. The exact message I get is: The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup. As mentioned, this is not a problem on Windows XP. My code looks like this: Component Id=MessageListenerComponent Guid=44FCBFDC-7E2E-4EE6-9E17-30BB4C566421 DiskId=1 File Id=MsgListener Source=$(var.BuildPath)MessageListener.exe KeyPath=yes / File Source=$(var.BuildPath)MessageListener.pdb CompanionFile=MsgListener/ File Source=$(var.BuildPath)MessageListener.exe.config CompanionFile=MsgListener / ServiceInstall Id=MsgInstall DisplayName=!(loc.MessageListenerDisplayName) Name=MessageListener Description=!(loc.MessageListenerDescription) ErrorControl=normal Start=auto Type=ownProcess Account=NT AUTHORITY\NetworkService Vital=yes Interactive=no ServiceDependency Id=MSMQ/ ServiceDependency Id=NSEngine/ ServiceDependency Id=SMI/ /ServiceInstall ServiceControl Id=MsgLstnrControl Name=MessageListener Stop=uninstall Remove=uninstall Wait=yes/ fw:FirewallException Id=MsgLstnrException Name=!(loc.MessageListenerFirewallException) Program=[#MsgListener] IgnoreFailure=yes Protocol=tcp Scope=localSubnet/ /Component There are five services, of which this is the third. It requires NSEngine and SMI which is two others of our services. For some reason the installer fails to elevate for the stop on uninstall, but how do I get it to do that? Thank you, Thomas Due -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems launching an application on finish
So what is the conclusion? That what I am trying is basically impossible? MSI will not launch an elevated process except as a deferred custom action and you can't use those from the UI. I read that as a yes. So, what is my options then? I will of course attempt the solution that Palbinder Sandher suggested, but is that really the only solution? I have run out of time on the subject for the time being, so I have to resign to the fact that people have to run the application manually on Windows Vista and 7. But since I will be returning to the subject, I just want to know If the custom action described in the manual is the only (possibly) way? In any event, thank you for your time. Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems launching an application on finish
So what is the conclusion? That what I am trying is basically impossible? I tried setting the action to Impersonate=No and Execute=Commit. I got this for my trouble: --- Action start 13:54:36: LaunchConfig. MSI (c) (AC:A8) [13:54:36:027]: Note: 1: 2762 DEBUG: Error 2762: Unable to schedule operation. The action must be scheduled between InstallInitialize and InstallFinalize. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2762. The arguments are: , , MSI (c) (AC:A8) [13:54:42:205]: Product: ScanX.NET -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2762. The arguments are: , , Action ended 13:54:42: LaunchConfig. Return value 3. DEBUG: Error 2896: Executing action LaunchConfig failed. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2896. The arguments are: LaunchConfig, , --- Is there any way to solve this issue, without having to start the entire msi as administrator, or launching the application through obscure custom actions? In any event, thank you all so far for your help. /Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 5. juli 2010 17:26 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Problems launching an application on finish You can't run a deferred action from a Publish. If you use cmd.exe (or QAQuietExec) you may be able to launch the executable in such a way as to let UAC prompt you for elevation. The failure is because CustomAction FileKey/ launches in such a way as to not allow UAC to be invoked, and the application's elevation manifest prevents execution. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, July 05, 2010 4:01 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems launching an application on finish Try adding the Impersonate attribute with value no to your CustomAction element. You may also want to change the Execute attribute to commit or deferred. See - http://wix.sourceforge.net/manual-wix3/wix_xsd_customaction.htm Palbinder Sandher Software Deployment IT Administrator 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: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 05 July 2010 11:38 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problems launching an application on finish Hello, I have a rather simple installer which among other things registers and starts some windows services. As such, the installer requires admin privileges from the UAC on Vista and Win7. It runs beautifully on Windows XP, Windows Vista and Windows 7, so not problems with the installer. However, I need to launch an application when the user clicks the Finish button on the last dialog. Since the application needs to restart the services, it needs to run with administrative privileges. I have as a result included a manifest in the application requesting admin rights. This also works beautifully, when executed separately. On Windows XP the installer launches the application as it should, but on Windows 7 (I haven't tested on Vista yet) it doesn't start. I suspect it has to do with the installer running as normal user, while the application requires admin privileges, and I am missing something for making the installer able to launch the application. My launch code looks like this: Product .. Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchConfig Order=999NOT Installed/Publish CustomAction Id=LaunchConfig FileKey=MasterConfig Return=asyncNoWait / Where the MasterConfig points correctly to an application being installed. So, what am I missing? Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: wix-users-requ...@lists.sourceforge.net [mailto:wix-users-requ...@lists.sourceforge.net] Sent: 4. juli 2010 03:48 To: wix-users@lists.sourceforge.net Subject: WiX-users Digest, Vol 50, Issue 14 Send WiX-users mailing list
[WiX-users] Problems launching an application on finish
Hello, I have a rather simple installer which among other things registers and starts some windows services. As such, the installer requires admin privileges from the UAC on Vista and Win7. It runs beautifully on Windows XP, Windows Vista and Windows 7, so not problems with the installer. However, I need to launch an application when the user clicks the Finish button on the last dialog. Since the application needs to restart the services, it needs to run with administrative privileges. I have as a result included a manifest in the application requesting admin rights. This also works beautifully, when executed separately. On Windows XP the installer launches the application as it should, but on Windows 7 (I haven't tested on Vista yet) it doesn't start. I suspect it has to do with the installer running as normal user, while the application requires admin privileges, and I am missing something for making the installer able to launch the application. My launch code looks like this: Product .. Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchConfig Order=999NOT Installed/Publish CustomAction Id=LaunchConfig FileKey=MasterConfig Return=asyncNoWait / Where the MasterConfig points correctly to an application being installed. So, what am I missing? Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: wix-users-requ...@lists.sourceforge.net [mailto:wix-users-requ...@lists.sourceforge.net] Sent: 4. juli 2010 03:48 To: wix-users@lists.sourceforge.net Subject: WiX-users Digest, Vol 50, Issue 14 Send WiX-users mailing list submissions to wix-users@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/wix-users or, via email, send a message with subject or body 'help' to wix-users-requ...@lists.sourceforge.net You can reach the person managing the list at wix-users-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of WiX-users digest... -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX-users Digest, Vol 49, Issue 116
Hello, I have two quick questions: First, I need to run an application when the installer is closed. Currently it runs when the finished dialog is shown: InstallExecuteSequence Custom Action=LaunchConfig After=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence CustomAction Id=LaunchConfig FileKey=MasterConfig ExeCommand=-lan=[INSTALLLANGUAGE] -src=[SourceDir] Return=asyncNoWait / But how do I make it run when the finished dialog is CLOSED? Second, how do I escape a in the ExeCommand attribute? E.g. ExeCommand=-lan=\[INSTALLLANGUAGE]\ -src=[SourceDir]? Thanks, Thomas Due -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check?
My installer must be run on Windows7 and Windows 2008 (and r2). One of the prerequisite is service MSMQ, which must be installed on this computer. But how to check it? On windows XP and Windows 2003 I checked registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OC Manager\Subcomponents\msmq_core and if it exists - msmq is installed. Now this value doesn't correspond to the installed state of the MSMQ. So any ideas how to check MSMQ installed state? This approach seems to work for me. Product ... Property Id=HASMSMQ RegistrySearch Id=MSMQIsInstalled Root=HKLM Key=System\CurrentControlSet\Services\MSMQ Name=ImagePath Type=raw / /Property Condition Message=MSMQ must be installed ![CDATA[Installed or not HasMSMQ]] /Condition /Product /Thomas Due -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check?
Oh, I hadn't noticed the typo. Thanks. The casing should of course be identical. Also, I wasn't aware that the registry location differs from Windows version to Windows version. /Thomas Due -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 22. juni 2010 13:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check? HasMSMQ HASMSMQ are not interchangeable when talking about Windows Installer Properties. Also Launch Conditions fire the error when the inner text evaluates to false. Hence Condition Message=MSMQ must be installed ![CDATA[(HASMSMQ AND VersionNT=600) OR (HASMSMQ_CORE AND (VersionNT500 AND VersionNT600)) OR Installed]] /Condition would be a better choice for the inner text (assuming you set HASMSMQ_CORE in a RegistrySearch for the XP/2003 registry location described below, replace HASMSMQ_CORE with your own public Property name). However the question is ambiguous as Vista Server 2008 are v6.0, Windows 7 Server 2008 R2 are v6.1 (no mention of Vista in the original question). The above change to the Condition's inner text would check the HASMSMQ only on Vista/Server 2008 above while XP/2003 use the original property which I can only assume is the expected behaviour. Palbinder Sandher Software Deployment IT Administrator 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: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 22 June 2010 07:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check? My installer must be run on Windows7 and Windows 2008 (and r2). One of the prerequisite is service MSMQ, which must be installed on this computer. But how to check it? On windows XP and Windows 2003 I checked registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OC Manager\Subcomponents\msmq_core and if it exists - msmq is installed. Now this value doesn't correspond to the installed state of the MSMQ. So any ideas how to check MSMQ installed state? This approach seems to work for me. Product ... Property Id=HASMSMQ RegistrySearch Id=MSMQIsInstalled Root=HKLM Key=System\CurrentControlSet\Services\MSMQ Name=ImagePath Type=raw / /Property Condition Message=MSMQ must be installed ![CDATA[Installed or not HasMSMQ]] /Condition /Product /Thomas Due -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check?
Just to keep spamming on this subject ;) I found this: http://technet.microsoft.com/en-us/library/cc754407(WS.10).aspx Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 22. juni 2010 13:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check? HasMSMQ HASMSMQ are not interchangeable when talking about Windows Installer Properties. Also Launch Conditions fire the error when the inner text evaluates to false. Hence Condition Message=MSMQ must be installed ![CDATA[(HASMSMQ AND VersionNT=600) OR (HASMSMQ_CORE AND (VersionNT500 AND VersionNT600)) OR Installed]] /Condition would be a better choice for the inner text (assuming you set HASMSMQ_CORE in a RegistrySearch for the XP/2003 registry location described below, replace HASMSMQ_CORE with your own public Property name). However the question is ambiguous as Vista Server 2008 are v6.0, Windows 7 Server 2008 R2 are v6.1 (no mention of Vista in the original question). The above change to the Condition's inner text would check the HASMSMQ only on Vista/Server 2008 above while XP/2003 use the original property which I can only assume is the expected behaviour. Palbinder Sandher Software Deployment IT Administrator 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: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 22 June 2010 07:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check? My installer must be run on Windows7 and Windows 2008 (and r2). One of the prerequisite is service MSMQ, which must be installed on this computer. But how to check it? On windows XP and Windows 2003 I checked registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OC Manager\Subcomponents\msmq_core and if it exists - msmq is installed. Now this value doesn't correspond to the installed state of the MSMQ. So any ideas how to check MSMQ installed state? This approach seems to work for me. Product ... Property Id=HASMSMQ RegistrySearch Id=MSMQIsInstalled Root=HKLM Key=System\CurrentControlSet\Services\MSMQ Name=ImagePath Type=raw / /Property Condition Message=MSMQ must be installed ![CDATA[Installed or not HasMSMQ]] /Condition /Product /Thomas Due -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check?
I have been looking at this again. And it seems that the following registry path is only available if MSMQ is installed. This path exists on XP (SP3), Windows 2008 (R1) and Windows 7. I expect it will exist on other OS's as well: HKLM\Software\Microsoft\MSMQ If MSMQ is NOT installed, this path does not exist at all. Furthermore, there is a sub-path called Setup (HKLM\Software\Microsoft\MSMQ\Setup). This path contains several keys which seem to indicate what MSMQ components has been installed. E.g. MSMQ_Core. I have seen the path on an ancient Windows 2000 Server although MSMQ wasn't installed, there the Setup folder was empty however. So, unless someone have some hard fact about this, I think I will personally check for the existence of the path: HKLM\Software\Microsoft\MSMQ Since this seems to only exists if MSMQ has actually been installed, at least for those OS' we support. Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 22. juni 2010 13:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check? HasMSMQ HASMSMQ are not interchangeable when talking about Windows Installer Properties. Also Launch Conditions fire the error when the inner text evaluates to false. Hence Condition Message=MSMQ must be installed ![CDATA[(HASMSMQ AND VersionNT=600) OR (HASMSMQ_CORE AND (VersionNT500 AND VersionNT600)) OR Installed]] /Condition would be a better choice for the inner text (assuming you set HASMSMQ_CORE in a RegistrySearch for the XP/2003 registry location described below, replace HASMSMQ_CORE with your own public Property name). However the question is ambiguous as Vista Server 2008 are v6.0, Windows 7 Server 2008 R2 are v6.1 (no mention of Vista in the original question). The above change to the Condition's inner text would check the HASMSMQ only on Vista/Server 2008 above while XP/2003 use the original property which I can only assume is the expected behaviour. Palbinder Sandher Software Deployment IT Administrator 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: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 22 June 2010 07:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSMQ and Windows 2008 \ Windows 7, how to check? My installer must be run on Windows7 and Windows 2008 (and r2). One of the prerequisite is service MSMQ, which must be installed on this computer. But how to check it? On windows XP and Windows 2003 I checked registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\OC Manager\Subcomponents\msmq_core and if it exists - msmq is installed. Now this value doesn't correspond to the installed state of the MSMQ. So any ideas how to check MSMQ installed state? This approach seems to work for me. Product ... Property Id=HASMSMQ RegistrySearch Id=MSMQIsInstalled Root=HKLM Key=System\CurrentControlSet\Services\MSMQ Name=ImagePath Type=raw / /Property Condition Message=MSMQ must be installed ![CDATA[Installed or not HasMSMQ]] /Condition /Product /Thomas Due -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Architectural advice needed
Well... ok then. I will just ignore the warning although I dislike letting warnings go by me. Thank you for the input, all of you who participated. Med venlig hilsen / Best regards, Thomas Due - Software Developer Tel: +45 8678 5500 Fax: +45 8678 5210 Johann Gutenbergs vej 5-9, Aarhus N, Denmark t...@scanvaegt.dk | www.scanvaegt.dk This e-mail and its attachments are intended for the named addressee only and may contain information that is confidential and privileged. Unauthorized use can instigate a claim for damages and constitute a criminal offence. If you received this in error, please contact the sender and delete the material. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 28. maj 2010 10:24 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Architectural advice needed The problem is that the ICE isn't smart enough to tell that the conditions are mutually exclusive. It sounds like you have exactly what you want. You need to let the ICE warnings go. smile/ On Thu, May 27, 2010 at 12:10 AM, Thomas Due t...@scanvaegt.dk wrote: Hi, I think I need to supply a bit more information about our setup. Our application is not targeted towards multi-lingual users. The client runtime language is decided at installation time, and is very rarely changed afterwards. As a result we don't really have a need for separate language-specific subfolders. I realize that this is very often the way it is done, but this is not the way we are used to doing it. So, as a result our application expects report files in one location, ie. a subfolder named Reports. Regardless of language. At some point, we expect to move the report files away from the client installation, and place them in a centralized location maybe using sql server reporting services as a report server. But right now reports are placed in the same subfolder regardless of language. I have a working solution for the installer right now, but I dislike the multitude of ICE warnings for each duplicate file name. Sincerely, Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 27. maj 2010 00:47 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Architectural advice needed If your program's architecture will allow it, place each language-specific file into its own language-specific subfolder. -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Wednesday, May 26, 2010 2:02 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Architectural advice needed Hi, This is simply a warning to you to make sure that the conditions are bulletproof, if you are sure, you can ignore it. I would personally treat this as configuration, i.e. nothing to do with the the installer. You could install all the report files in specific folders and get the application to allow you to switch between them (this is what we do with localized files). Of course you may not have access to the application. You could also install all the languages to a template folder then copy the selected one with filecopy to the report location, this may add unneeded complexity to the install though. Dave -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 26 May 2010 08:50 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Architectural advice needed Hi, I need a bit of advice on my installer from you guys. I have an installer which is mostly done, several dozen files, some windows services which is registered and started, etc. However, during the interview I ask for a language which the installation should use. This choice results in a set of different report files being installed based on language. As it is right now, I have each language report set isolated in separate components, which is enabled/disabled based on the language choice made during the interview. However, since I cannot guarantee that the report files will have unique names, I get a lot of ICE (ICE30 to be specific) warnings because there are files with identical names and that these have the same destination. The exact warning is: ICE30: The target file 'Articles.rdl' might be installed in '[ProgramFilesFolder]\f252vad8\ScanX.NET\Reports\' by two different conditionalized components on an SFN system: 'DA_ReportsComponent' and 'NO_ReportsComponent'. If the conditions are not mutually exclusive, this will break the component reference counting system. Now, I am faced with an architectural challenge; how do I solve this best? 1. In reality I could just ignore these warnings, as the conditions I have set prevents more than one language-specific component from being installed. But I abhor warning in my code, even if they have no consequence. 2. Restructure the installer, so each language-specific component
Re: [WiX-users] Architectural advice needed
Hi, I think I need to supply a bit more information about our setup. Our application is not targeted towards multi-lingual users. The client runtime language is decided at installation time, and is very rarely changed afterwards. As a result we don't really have a need for separate language-specific subfolders. I realize that this is very often the way it is done, but this is not the way we are used to doing it. So, as a result our application expects report files in one location, ie. a subfolder named Reports. Regardless of language. At some point, we expect to move the report files away from the client installation, and place them in a centralized location maybe using sql server reporting services as a report server. But right now reports are placed in the same subfolder regardless of language. I have a working solution for the installer right now, but I dislike the multitude of ICE warnings for each duplicate file name. Sincerely, Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 27. maj 2010 00:47 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Architectural advice needed If your program's architecture will allow it, place each language-specific file into its own language-specific subfolder. -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Wednesday, May 26, 2010 2:02 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Architectural advice needed Hi, This is simply a warning to you to make sure that the conditions are bulletproof, if you are sure, you can ignore it. I would personally treat this as configuration, i.e. nothing to do with the the installer. You could install all the report files in specific folders and get the application to allow you to switch between them (this is what we do with localized files). Of course you may not have access to the application. You could also install all the languages to a template folder then copy the selected one with filecopy to the report location, this may add unneeded complexity to the install though. Dave -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 26 May 2010 08:50 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Architectural advice needed Hi, I need a bit of advice on my installer from you guys. I have an installer which is mostly done, several dozen files, some windows services which is registered and started, etc. However, during the interview I ask for a language which the installation should use. This choice results in a set of different report files being installed based on language. As it is right now, I have each language report set isolated in separate components, which is enabled/disabled based on the language choice made during the interview. However, since I cannot guarantee that the report files will have unique names, I get a lot of ICE (ICE30 to be specific) warnings because there are files with identical names and that these have the same destination. The exact warning is: ICE30: The target file 'Articles.rdl' might be installed in '[ProgramFilesFolder]\f252vad8\ScanX.NET\Reports\' by two different conditionalized components on an SFN system: 'DA_ReportsComponent' and 'NO_ReportsComponent'. If the conditions are not mutually exclusive, this will break the component reference counting system. Now, I am faced with an architectural challenge; how do I solve this best? 1. In reality I could just ignore these warnings, as the conditions I have set prevents more than one language-specific component from being installed. But I abhor warning in my code, even if they have no consequence. 2. Restructure the installer, so each language-specific component is contained in a transform package, this has the extra advantage of enabling me to localize the installation interview as well. It does, however, require a bootstrapper. 3. Ignore the issue complete and distribute the report files as a zip and letting the user / software technician install them manually after the installation is complete. 4. ? I would like some advice on how things like this is usually done. Thank you, Thomas Due Software Developer -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users /pre BR style=font-size:4px; a href = http://www.sdl.com;img src=http://www.sdl.com/images/email logo_150dpi-01.png alt=www.sdl.com border=0//a BR font face=arial size=2 a href = http://www.sdl.com; style=color:005740; font-weight: boldwww.sdl.com/a BR BR font face=arial size=1 color=#736F6E bSDL PLC confidential, all rights reserved./b If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its
[WiX-users] Architectural advice needed
Hi, I need a bit of advice on my installer from you guys. I have an installer which is mostly done, several dozen files, some windows services which is registered and started, etc. However, during the interview I ask for a language which the installation should use. This choice results in a set of different report files being installed based on language. As it is right now, I have each language report set isolated in separate components, which is enabled/disabled based on the language choice made during the interview. However, since I cannot guarantee that the report files will have unique names, I get a lot of ICE (ICE30 to be specific) warnings because there are files with identical names and that these have the same destination. The exact warning is: ICE30: The target file 'Articles.rdl' might be installed in '[ProgramFilesFolder]\f252vad8\ScanX.NET\Reports\' by two different conditionalized components on an SFN system: 'DA_ReportsComponent' and 'NO_ReportsComponent'. If the conditions are not mutually exclusive, this will break the component reference counting system. Now, I am faced with an architectural challenge; how do I solve this best? 1. In reality I could just ignore these warnings, as the conditions I have set prevents more than one language-specific component from being installed. But I abhor warning in my code, even if they have no consequence. 2. Restructure the installer, so each language-specific component is contained in a transform package, this has the extra advantage of enabling me to localize the installation interview as well. It does, however, require a bootstrapper. 3. Ignore the issue complete and distribute the report files as a zip and letting the user / software technician install them manually after the installation is complete. 4. ? I would like some advice on how things like this is usually done. Thank you, Thomas Due Software Developer -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Regarding best practices
I am wondering about how to best create my installer, and is looking for some advice on this from the experienced people on this list. A bit about the system I am shipping: Software Requirements === (These will be handled by either a bootstrapper or manually by the person performing the installation). 1. Microsoft .NET Framework 3.5 sp1 2. MSMQ 3. Sql Server 2005 Express (as minimum) 4. Microsoft Report Viewer 2008 redistributables Steps need to be taken before the system is installed and configured. = 1. Several windows services (server install only) - These should be installed and registered - Exceptions should set up in the firewall - Write permissions to the installation folder for the NETWORK SERVICES account 2. A bunch of dlls and exes in addition to the windows services. - Report files etc. 3. Creating/updating a database on a local database - Collecting logon information about database - Alternatively collecting information about where the database is placed 4. Collecting information about server location 5. Adding/changing/verifying several lines in a xml document. In addition I need to perform a lot of application configuration, but these steps is more or less necessary before I am able to begin configuring the application. I have created a simple installer that performs step 1 and 2, but now I am stuck as to the best approach to the rest of the items. I know I can create a database and run scripts from the installer, but how does MSI/WiX make sure that the database doesn't already exists? If it exists, can I prevent running of certain scripts? Or do I have to handle this in the scripts themselves? My system consists of several windows services which ideally exists only on a server. The installation of these services are done, but I need to point client installations to the server, so they can establish communication with the services. I know how to create a custom dialog for entering the name of the server, but how do I write this information into a xml file, and how do I make sure that the information isn't already there? I am considering writing a master configuration application which will collect all this information and create/update the xml document, but I realize that this will make silent installs much more difficult. I would very much like for the installer to perform initial configuration, like creating/updating/connecting the database and services. But I am uncertain as to how I do this best. Thank you in advance, Thomas Due Software Developer Scanvaegt Nordic A/S -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problems with major upgrade
I know this has been asked and answered about a zillion times and that I probably can find the information somewhere on the mailing list. The problem is I don't know how to limit my search, so I get roughly 1500 hits. It's like searching for the proverbial needle in a haystack. I try to do it exactly it says in the WiX help file, but it doesn't seem to work like I want. It is probably something simple, but I can't see it. What I want is an installer that automatically uninstalls a previous version of the same product and installs the new version. In addition it should detect whether a newer version already exists, and if so abort the installation. In other words, no downgrading. But for some reason, I just get two versions of the same product installed in the same folder. Mind you, this is the first version, so although there is nothing to upgrade yet, I would like the logic to be in place before shipping. My WiX is like this (the relevant bits): ?define MinVersion=1.0.0 ? ?define MaxVersion=1.0.1 ? ?define CurVersion=1.0.1 ? Product Id=* Name=!(loc.ApplicationName) Language=!(loc.ProductLanguage) Version=$(var.CurVersion) Manufacturer=!(loc.CompanyName) Codepage=1252 UpgradeCode=DC776FD7-DF88-4F7F-A241-6F9233C2A997 Package Platform=x86 Manufacturer=!(loc.CompanyName) InstallPrivileges=elevated Description=!(loc.PackageDescription) InstallScope=perMachine InstallerVersion=301 Compressed=yes / Upgrade Id=214E215F-7633-421E-A7D8-FD5DB5992709 UpgradeVersion Minimum=$(var.MinVersion) Maximum=$(var.MaxVersion) IncludeMinimum=yes Property=MYAPPVERSION / UpgradeVersion Minimum=$(var.MaxVersion) OnlyDetect=yes Property=NEWERVERSIONDETECTED / /Upgrade InstallUISequence LaunchConditions After=AppSearch/ /InstallUISequence InstallExecuteSequence RemoveExistingProducts After=InstallInitialize/ LaunchConditions After=AppSearch/ /InstallExecuteSequence !-- Irrelevant stuff here -- /Product I plan to simply change the CurVersion and MaxVersion variables between releases, so I don't have to change several entries and risk missing one. Best regards, Thomas Due -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems with major upgrade
Nevermind, it seems I got it to work. I hadn't caught that the upgra...@id code needed to be the same as produ...@upgradecode. Best regards, Thomas Due -Original Message- From: Thomas Due Sent: 10. november 2009 12:38 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Problems with major upgrade I know this has been asked and answered about a zillion times and that I probably can find the information somewhere on the mailing list. The problem is I don't know how to limit my search, so I get roughly 1500 hits. It's like searching for the proverbial needle in a haystack. I try to do it exactly it says in the WiX help file, but it doesn't seem to work like I want. It is probably something simple, but I can't see it. What I want is an installer that automatically uninstalls a previous version of the same product and installs the new version. In addition it should detect whether a newer version already exists, and if so abort the installation. In other words, no downgrading. But for some reason, I just get two versions of the same product installed in the same folder. Mind you, this is the first version, so although there is nothing to upgrade yet, I would like the logic to be in place before shipping. My WiX is like this (the relevant bits): ?define MinVersion=1.0.0 ? ?define MaxVersion=1.0.1 ? ?define CurVersion=1.0.1 ? Product Id=* Name=!(loc.ApplicationName) Language=!(loc.ProductLanguage) Version=$(var.CurVersion) Manufacturer=!(loc.CompanyName) Codepage=1252 UpgradeCode=DC776FD7-DF88-4F7F-A241-6F9233C2A997 Package Platform=x86 Manufacturer=!(loc.CompanyName) InstallPrivileges=elevated Description=!(loc.PackageDescription) InstallScope=perMachine InstallerVersion=301 Compressed=yes / Upgrade Id=214E215F-7633-421E-A7D8-FD5DB5992709 UpgradeVersion Minimum=$(var.MinVersion) Maximum=$(var.MaxVersion) IncludeMinimum=yes Property=MYAPPVERSION / UpgradeVersion Minimum=$(var.MaxVersion) OnlyDetect=yes Property=NEWERVERSIONDETECTED / /Upgrade InstallUISequence LaunchConditions After=AppSearch/ /InstallUISequence InstallExecuteSequence RemoveExistingProducts After=InstallInitialize/ LaunchConditions After=AppSearch/ /InstallExecuteSequence !-- Irrelevant stuff here -- /Product I plan to simply change the CurVersion and MaxVersion variables between releases, so I don't have to change several entries and risk missing one. Best regards, Thomas Due -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to know which InstallerVersion to use?
Oh right. Sorry, I missed that bit. I just stubbed my toes against: Vista/2008 only That'll teach me to read the entire thing.. (not bloody likely, but one can always hope ;) ) /Thomas -Original Message- From: Blair [mailto:os...@live.com] Sent: 3. november 2009 08:31 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to know which InstallerVersion to use? Quoting myself: MSI 4.5 - ..., and a redistributable ... for supported pre-Vista platforms. -Original Message- From: Thomas Due [mailto:thomas@scanvaegt.dk] Sent: Monday, November 02, 2009 11:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to know which InstallerVersion to use? Uh, according to this link: http://msdn.microsoft.com/da-dk/library/dd408041%28en-us,VS.85%29.aspx Is MSI 4.5 also available on Windows XP SP2 as a redistributable: Windows Installer 4.5 is available as a redistributable for Windows Server 2008, Windows Vista with Service Pack 1 (SP1), Windows XP with Service Pack 2 (SP2) and later, and Windows Server 2003 with Service Pack 1 (SP1) and later. For a complete list of all Windows Installer versions and redistributables, see Released Versions of Windows Installer. This link describes each version and version number in relation to operating system: http://msdn.microsoft.com/da-dk/library/aa371185%28en-us,VS.85%29.aspx Regards, Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 2. november 2009 22:46 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to know which InstallerVersion to use? If you don't specify, WiX currently defaults to 1.0 (100). Very brief matrix: MSI 1.x - basic MSI support, 32-bit only. MSI 2.x - added 64-bit support. MSI 3.0 - improved patching. MSI 3.1 - improved external ui. MSI 4.0 - Vista/2008 only. Incorporates UAC-integration/restart-manager-integration/transaction-integration as well as embedded-UI/msi-chaining and some improvements to patch support (superseded components/patch removal custom actions. MSI 4.5 - some bug fixes, and a redistributable containing the embedded ui, msi chaining, and improved patch support (superseded components and patch removal actions) for supported pre-Vista platforms. The restart manager, UAC, and transaction integrations require platform support so they are not in the downlevel redistributable (although they are retained in the vista/2008 redistributable), but all the other improvements in 4.0 are in 4.5. MSI 5.0 - Windows 7/2008 R2 only (AFAIK). Big things are SDDL for configuring permissions, more control over services, finally some improvement to the internal UI (a hyperlink control, a print and a launch-app control events), along with a way to finally author packages that can be switched between per-user and per-machine during the installation. See the links off this page for more details: http://msdn.microsoft.com/library/aa372796.aspx for details after 2.0. This page details each released build from 2.0 on: http://msdn.microsoft.com/library/aa371185.aspx. MSDN no longer documents the changes that 2.0 added from 1.x apart from the 64-bit support, but no version of 1.x is supported anymore either (that was much more than a decade ago). Most of the info on 1.x I found was on Wikipedia. If you look to see in the lists of what wasn't supported to determine which version started supporting the things you use, you will then be able to determine which is your minimum version. Or, if you have a minimum platform (XP SP2, Vista, whatever) you can look to see what shipped with that platform and avoid anything that isn't supported in that release of Windows Installer. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Monday, November 02, 2009 11:16 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] How to know which InstallerVersion to use? I am a beginner to MSI and WiX and have a question on the InstallerVersion attribute: How to know what version of WindowsInstaller my .msi will need to run correctly? Is there some kind of table that I did not discover so far, containing all WiX / MSI features plus the needed version number? And, if I do not use the attribute at all, what will happen then? Maybe this is a silly question, but I did not find any answer besides For 64-bit Windows Installer packages, this property must be set to 200 or greater.. Thanks! Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
Re: [WiX-users] How to know which InstallerVersion to use?
Jumping to conclusions certainly is grin/ /Thomas -Original Message- From: Blair [mailto:os...@live.com] Sent: 4. november 2009 06:49 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to know which InstallerVersion to use? It is human to not RTFM (along with all similar activities), isn't it smile/ -Original Message- From: Thomas Due [mailto:thomas@scanvaegt.dk] Sent: Tuesday, November 03, 2009 4:59 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to know which InstallerVersion to use? Oh right. Sorry, I missed that bit. I just stubbed my toes against: Vista/2008 only That'll teach me to read the entire thing.. (not bloody likely, but one can always hope ;) ) /Thomas -Original Message- From: Blair [mailto:os...@live.com] Sent: 3. november 2009 08:31 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to know which InstallerVersion to use? Quoting myself: MSI 4.5 - ..., and a redistributable ... for supported pre-Vista platforms. -Original Message- From: Thomas Due [mailto:thomas@scanvaegt.dk] Sent: Monday, November 02, 2009 11:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to know which InstallerVersion to use? Uh, according to this link: http://msdn.microsoft.com/da-dk/library/dd408041%28en-us,VS.85%29.aspx Is MSI 4.5 also available on Windows XP SP2 as a redistributable: Windows Installer 4.5 is available as a redistributable for Windows Server 2008, Windows Vista with Service Pack 1 (SP1), Windows XP with Service Pack 2 (SP2) and later, and Windows Server 2003 with Service Pack 1 (SP1) and later. For a complete list of all Windows Installer versions and redistributables, see Released Versions of Windows Installer. This link describes each version and version number in relation to operating system: http://msdn.microsoft.com/da-dk/library/aa371185%28en-us,VS.85%29.aspx Regards, Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 2. november 2009 22:46 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to know which InstallerVersion to use? If you don't specify, WiX currently defaults to 1.0 (100). Very brief matrix: MSI 1.x - basic MSI support, 32-bit only. MSI 2.x - added 64-bit support. MSI 3.0 - improved patching. MSI 3.1 - improved external ui. MSI 4.0 - Vista/2008 only. Incorporates UAC-integration/restart-manager-integration/transaction-integration as well as embedded-UI/msi-chaining and some improvements to patch support (superseded components/patch removal custom actions. MSI 4.5 - some bug fixes, and a redistributable containing the embedded ui, msi chaining, and improved patch support (superseded components and patch removal actions) for supported pre-Vista platforms. The restart manager, UAC, and transaction integrations require platform support so they are not in the downlevel redistributable (although they are retained in the vista/2008 redistributable), but all the other improvements in 4.0 are in 4.5. MSI 5.0 - Windows 7/2008 R2 only (AFAIK). Big things are SDDL for configuring permissions, more control over services, finally some improvement to the internal UI (a hyperlink control, a print and a launch-app control events), along with a way to finally author packages that can be switched between per-user and per-machine during the installation. See the links off this page for more details: http://msdn.microsoft.com/library/aa372796.aspx for details after 2.0. This page details each released build from 2.0 on: http://msdn.microsoft.com/library/aa371185.aspx. MSDN no longer documents the changes that 2.0 added from 1.x apart from the 64-bit support, but no version of 1.x is supported anymore either (that was much more than a decade ago). Most of the info on 1.x I found was on Wikipedia. If you look to see in the lists of what wasn't supported to determine which version started supporting the things you use, you will then be able to determine which is your minimum version. Or, if you have a minimum platform (XP SP2, Vista, whatever) you can look to see what shipped with that platform and avoid anything that isn't supported in that release of Windows Installer. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Monday, November 02, 2009 11:16 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] How to know which InstallerVersion to use? I am a beginner to MSI and WiX and have a question on the InstallerVersion attribute: How to know what version of WindowsInstaller my .msi will need to run correctly? Is there some kind of table that I did not discover so far, containing all WiX / MSI features plus the needed version number? And, if I do not use the attribute at all, what will happen then? Maybe this is a silly
Re: [WiX-users] How to know which InstallerVersion to use?
Uh, according to this link: http://msdn.microsoft.com/da-dk/library/dd408041%28en-us,VS.85%29.aspx Is MSI 4.5 also available on Windows XP SP2 as a redistributable: Windows Installer 4.5 is available as a redistributable for Windows Server 2008, Windows Vista with Service Pack 1 (SP1), Windows XP with Service Pack 2 (SP2) and later, and Windows Server 2003 with Service Pack 1 (SP1) and later. For a complete list of all Windows Installer versions and redistributables, see Released Versions of Windows Installer. This link describes each version and version number in relation to operating system: http://msdn.microsoft.com/da-dk/library/aa371185%28en-us,VS.85%29.aspx Regards, Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 2. november 2009 22:46 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to know which InstallerVersion to use? If you don't specify, WiX currently defaults to 1.0 (100). Very brief matrix: MSI 1.x - basic MSI support, 32-bit only. MSI 2.x - added 64-bit support. MSI 3.0 - improved patching. MSI 3.1 - improved external ui. MSI 4.0 - Vista/2008 only. Incorporates UAC-integration/restart-manager-integration/transaction-integration as well as embedded-UI/msi-chaining and some improvements to patch support (superseded components/patch removal custom actions. MSI 4.5 - some bug fixes, and a redistributable containing the embedded ui, msi chaining, and improved patch support (superseded components and patch removal actions) for supported pre-Vista platforms. The restart manager, UAC, and transaction integrations require platform support so they are not in the downlevel redistributable (although they are retained in the vista/2008 redistributable), but all the other improvements in 4.0 are in 4.5. MSI 5.0 - Windows 7/2008 R2 only (AFAIK). Big things are SDDL for configuring permissions, more control over services, finally some improvement to the internal UI (a hyperlink control, a print and a launch-app control events), along with a way to finally author packages that can be switched between per-user and per-machine during the installation. See the links off this page for more details: http://msdn.microsoft.com/library/aa372796.aspx for details after 2.0. This page details each released build from 2.0 on: http://msdn.microsoft.com/library/aa371185.aspx. MSDN no longer documents the changes that 2.0 added from 1.x apart from the 64-bit support, but no version of 1.x is supported anymore either (that was much more than a decade ago). Most of the info on 1.x I found was on Wikipedia. If you look to see in the lists of what wasn't supported to determine which version started supporting the things you use, you will then be able to determine which is your minimum version. Or, if you have a minimum platform (XP SP2, Vista, whatever) you can look to see what shipped with that platform and avoid anything that isn't supported in that release of Windows Installer. -Original Message- From: Markus Karg [mailto:markus.k...@gmx.net] Sent: Monday, November 02, 2009 11:16 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] How to know which InstallerVersion to use? I am a beginner to MSI and WiX and have a question on the InstallerVersion attribute: How to know what version of WindowsInstaller my .msi will need to run correctly? Is there some kind of table that I did not discover so far, containing all WiX / MSI features plus the needed version number? And, if I do not use the attribute at all, what will happen then? Maybe this is a silly question, but I did not find any answer besides For 64-bit Windows Installer packages, this property must be set to 200 or greater.. Thanks! Markus -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How do I check for existance of other installation
I know this has probably been asked about a zillion times before, but here goes: I have created an installer for a product I am developing. This project however depends on the existence of our primary product. So, basically I have to test for the existence of our primary product, and if it is not installed, abort the installation. How do I do that? Is there some kind of support built into MSI, or do I simply solve it by having the primary product create a key in a known location in the registry? If this key exists, then I can proceed with the installation, if not abort. Best regards, Thomas Due - Software Developer -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How do I check for existance of other installation
@Sandher: Yes, this is the approach I am testing right now, and it seems to work fine. @Blair: Interesting. Definitely somewhat easier than searching for a registry key. Thanks for both suggestions. Best regards, Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 28. oktober 2009 15:59 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How do I check for existance of other installation If you know the UpdateCode of the primary product, you can add an update\updatevers...@onlydetect='yes' that you can then use in a LaunchCondition, something like this: Update Id=PRIMARY_PRODUCT_UPGRADE_CODE UpgradeVersion OnlyDetect=yes Property=PRIMARY_PRODUCT/!--Add any other required constraints, such as min/max versions, language, etc.-- /Upgrade Condition Message=Primary Product must be installedInstalled OR PRIMARY_PRODUCT/Condition -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Wednesday, October 28, 2009 6:13 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How do I check for existance of other installation In most cases you would check for the existence of something the primary product installs such as a Registry Key or a File Version. This is how the .NET Framework checks in WixNetfxExtension work AFAIK. I use Properties with RegistrySearches in our plug-in installers to check for the existence of the app the plug-in is for and the existence of our software. You can then use those Properties in LaunchConditions or Feature Conditions to either disallow installation entirely in the first case or selectively disable/remove Features if you have Features which depend on the primary product existing in the second case. Works pretty well for us so far. Palbinder Sandher Software Deployment IT Administrator 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: Thomas Due [mailto:thomas@scanvaegt.dk] Sent: 28 October 2009 12:07 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How do I check for existance of other installation I know this has probably been asked about a zillion times before, but here goes: I have created an installer for a product I am developing. This project however depends on the existence of our primary product. So, basically I have to test for the existence of our primary product, and if it is not installed, abort the installation. How do I do that? Is there some kind of support built into MSI, or do I simply solve it by having the primary product create a key in a known location in the registry? If this key exists, then I can proceed with the installation, if not abort. Best regards, Thomas Due - Software Developer -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to best install generic system withcustomerspecific add-ins
Fair enough, I'll try to explain the situation a little better, but Sascha's suggestion about shared fragments files makes absolute sense now that I think about it. It hadn't even crossed my mind. I would to be careful about how I shared them, so I would only have one actual copy of the fragments files, otherwise I would face hell updating all copies when there were changes to the common files. Anyway: I have a service with a couple of common libraries, in itself this service does nothing. It merely forms an extensible framework for customer specific functions. Then I have the customer specific functions, these are just dll assemblies which are added to the service and supplies the actual functionality. So, instead of having to copy-and-paste a generic WiX project to each customer project, I thought I would make a generic module which contains the service and common assemblies, the necessary functionality for installing and starting the service etc. Additionally it would contain the UI sequence but allow for customer specific dialogs. This module would then be added to a customer specific installer which contained the remaining logic, like adding the customer extension to the framework and other various customer specific actions. This is what I want, how do I do that best? Merge Modules? WiX libraries? Shared WiX fragments? Best regards, Thomas Due -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 22. oktober 2009 17:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to best install generic system withcustomerspecific add-ins If Merge Modules look like they will work, I'd use .wixlibs instead ( http://www.robmensching.com/blog/posts/2008/10/10/What-are-.wixlibs-and-why-would-you-use-them). The WiX toolset's reusable functionality (from the Extensions and all the UI) use .wixlibs. The Wix.chm has a nice section on how to customize dialogs. I'd start there. Without more details about your exact project it's hard to provide more detailed advice. smile/ On Thu, Oct 22, 2009 at 1:27 AM, Thomas Due thomas@scanvaegt.dk wrote: I have been studying the documentation and the tutorial and come to the conclusion that patching is out, since that is essentially just the difference between two installers which is exactly what I want to avoid; Writing two installers... So, my next thought is: How about merge modules then? What I mean is, that I put all the common stuff into a merge module, it seems that it can contain all the logic regarding files and components and installing/starting services etc. Then I write the installer for each customer, which contains only the customer specific bits and adds the merge module containing all the common bit etc. So far so good. But how about the UI? Can I contain MOST of the gui in the merge module and only add a few customer specific dialogs (if necessary) in the customer installer, and if so, how do inject dialogs like that? Best regards, Thomas Due - Software Developer -Original Message- From: Thomas Due Sent: 22. oktober 2009 09:13 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to best install generic system with customerspecific add-ins I am currently finishing up on a generic system which we will sell to many different customer with different needs. So, as a result this generic system is based on extensions, or add-ins. Now I am thinking how to best write an installer for this. Although I could copy-n-paste the entire WiX project every time I make a new customer-specific extension, I think that is quite the wrong way to go about writing the installer for this system. So, I am thinking patches, or maybe transformations? An installer for the system itself, and then a patch with the customer specific bits. This way, I get to maintain a single installer with upgrade codes etc. and a simple patch installer for each customer project. On paper that should be simple enough, but how do I do that? I am currently still learning WiX, so my knowledge is, at best, shaky. So I need a bit of help. How do I create patches for a specific installer, and is the plan actually sound? Best regards, Thomas Due - Software Developer -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC
Re: [WiX-users] How to best install genericsystem withcustomerspecific add-ins
Cool, that actually sounds like a clever plan. Thanks for the input. Best regards, Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 23. oktober 2009 10:29 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to best install genericsystem withcustomerspecific add-ins The difference between wixlibs and shared wix fragments is that the wixlibs are simply several shared compiled wix fragments joined into a single library file. That would ensure you don't have multiple copies of the sources, but would require that you compile them, either from their own projects in your solution(s) or into some super-library repository you simply grab at either buildtime or version control sync time. Either one is usually vastly superior to merge modules. Merge modules have several limitations that makes them more difficult to service, including issues related to patching. Their content lives in a strange world where they are live in your MSI but stand apart from all other content in that MSI. They bulk up the size and slow down the performance of your MSI due to the way they integrate in (created system folder custom actions, difficulties in being referenced from your MSI-specific authoring, etc.). The closest build-style to merge modules on your list would be wixlibs (you can build and managed them the exact same way, without the merge module-specific pain). Or, you simply link in your projects to the source files wherever you place them for the shared fragment solution. One other thing superior with the wixlib/shared fragments approach over the MSM one is that any fragments you don't access in some way aren't included in the final link, meaning they don't take up any room in your MSI. That means you can always include all of them in all your projects, and just reference what you need. Merge modules, once built, are an all-or-nothing where simply including them includes everything in the MSM in your MSI, whether you really needed it or not. -Original Message- From: Thomas Due [mailto:thomas@scanvaegt.dk] Sent: Thursday, October 22, 2009 11:45 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to best install generic system withcustomerspecific add-ins Fair enough, I'll try to explain the situation a little better, but Sascha's suggestion about shared fragments files makes absolute sense now that I think about it. It hadn't even crossed my mind. I would to be careful about how I shared them, so I would only have one actual copy of the fragments files, otherwise I would face hell updating all copies when there were changes to the common files. Anyway: I have a service with a couple of common libraries, in itself this service does nothing. It merely forms an extensible framework for customer specific functions. Then I have the customer specific functions, these are just dll assemblies which are added to the service and supplies the actual functionality. So, instead of having to copy-and-paste a generic WiX project to each customer project, I thought I would make a generic module which contains the service and common assemblies, the necessary functionality for installing and starting the service etc. Additionally it would contain the UI sequence but allow for customer specific dialogs. This module would then be added to a customer specific installer which contained the remaining logic, like adding the customer extension to the framework and other various customer specific actions. This is what I want, how do I do that best? Merge Modules? WiX libraries? Shared WiX fragments? Best regards, Thomas Due -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 22. oktober 2009 17:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to best install generic system withcustomerspecific add-ins If Merge Modules look like they will work, I'd use .wixlibs instead ( http://www.robmensching.com/blog/posts/2008/10/10/What-are-.wixlibs-and- why- would-you-use-them). The WiX toolset's reusable functionality (from the Extensions and all the UI) use .wixlibs. The Wix.chm has a nice section on how to customize dialogs. I'd start there. Without more details about your exact project it's hard to provide more detailed advice. smile/ On Thu, Oct 22, 2009 at 1:27 AM, Thomas Due thomas@scanvaegt.dk wrote: I have been studying the documentation and the tutorial and come to the conclusion that patching is out, since that is essentially just the difference between two installers which is exactly what I want to avoid; Writing two installers... So, my next thought is: How about merge modules then? What I mean is, that I put all the common stuff into a merge module, it seems that it can contain all the logic regarding files and components and installing/starting services etc. Then I write the installer for each customer, which
[WiX-users] How to best install generic system with customer specific add-ins
I am currently finishing up on a generic system which we will sell to many different customer with different needs. So, as a result this generic system is based on extensions, or add-ins. Now I am thinking how to best write an installer for this. Although I could copy-n-paste the entire WiX project every time I make a new customer-specific extension, I think that is quite the wrong way to go about writing the installer for this system. So, I am thinking patches, or maybe transformations? An installer for the system itself, and then a patch with the customer specific bits. This way, I get to maintain a single installer with upgrade codes etc. and a simple patch installer for each customer project. On paper that should be simple enough, but how do I do that? I am currently still learning WiX, so my knowledge is, at best, shaky. So I need a bit of help. How do I create patches for a specific installer, and is the plan actually sound? Best regards, Thomas Due - Software Developer -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to best install generic system with customerspecific add-ins
I have been studying the documentation and the tutorial and come to the conclusion that patching is out, since that is essentially just the difference between two installers which is exactly what I want to avoid; Writing two installers... So, my next thought is: How about merge modules then? What I mean is, that I put all the common stuff into a merge module, it seems that it can contain all the logic regarding files and components and installing/starting services etc. Then I write the installer for each customer, which contains only the customer specific bits and adds the merge module containing all the common bit etc. So far so good. But how about the UI? Can I contain MOST of the gui in the merge module and only add a few customer specific dialogs (if necessary) in the customer installer, and if so, how do inject dialogs like that? Best regards, Thomas Due - Software Developer -Original Message- From: Thomas Due Sent: 22. oktober 2009 09:13 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to best install generic system with customerspecific add-ins I am currently finishing up on a generic system which we will sell to many different customer with different needs. So, as a result this generic system is based on extensions, or add-ins. Now I am thinking how to best write an installer for this. Although I could copy-n-paste the entire WiX project every time I make a new customer-specific extension, I think that is quite the wrong way to go about writing the installer for this system. So, I am thinking patches, or maybe transformations? An installer for the system itself, and then a patch with the customer specific bits. This way, I get to maintain a single installer with upgrade codes etc. and a simple patch installer for each customer project. On paper that should be simple enough, but how do I do that? I am currently still learning WiX, so my knowledge is, at best, shaky. So I need a bit of help. How do I create patches for a specific installer, and is the plan actually sound? Best regards, Thomas Due - Software Developer -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Is there an easier way of adding nodes and attributes to an xml file?
During my install I need to add some nodes to an xml file. These nodes will in addition have up to two attributes. The xml file itself is fairly simple with no really structure, just a single root and a bunch of children. Basically the xml file is structured like this: ?xml version=1.0 encoding=utf-8? Storage StorageItem name=.. / StorageItem name=.. value=.../ StorageItem name=.. value=.../ ... /Storage As far as I can tell, the way I add nodes and attributes to this, is like this: util:XmlConfig Id=NodeId Name=StorageItem File=[INSTALLDIR]configuration.xml ElementPath=/Storage Node=element On=install Action=create util:XmlConfig Id=FirstAttributeId Name=Name Value=Checked File=[INSTALLDIR]configuration.xml ElementId=NodeId / util:XmlConfig Id=SecondAttributeId Name=Value Value=True File=[INSTALLDIR]configuration.xml ElementId=NodeId / /util:XmlConfig Of course, I can probably write an xml code snippet to help in this, but still... This seems rather cumbersome, is that really the best way to add nodes and attributes to an xml file? It seems kinda excessive that I have to have 3(!!) XmlConfig elements in order to add a single node with two attributes. Is there any way I can make this more streamlined? /Thomas -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there an easier way of adding nodes andattributes to an xml file?
Thank you for the answer, but I was thinking of how to do it through WiX. There are quite a few variables I need to write to the xml file, so it would even more cumbersome to send them to a CA and writing the nodes and attributes through this. /Thomas -Original Message- From: Adnan Mian [mailto:miand...@gmail.com] Sent: 14. oktober 2009 09:22 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Is there an easier way of adding nodes andattributes to an xml file? Hi Thomas, for adding some nodes and attributes in already existing xml file you can write a custom action using XmlDoucument,XmlElement, XmlAttribute. If xml file not exist then it can be created using XmlWriter, for this purpose you can use FileStream. Best Regards Adnan 2009/10/14 Thomas Due thomas@scanvaegt.dk During my install I need to add some nodes to an xml file. These nodes will in addition have up to two attributes. The xml file itself is fairly simple with no really structure, just a single root and a bunch of children. Basically the xml file is structured like this: ?xml version=1.0 encoding=utf-8? Storage StorageItem name=.. / StorageItem name=.. value=.../ StorageItem name=.. value=.../ ... /Storage As far as I can tell, the way I add nodes and attributes to this, is like this: util:XmlConfig Id=NodeId Name=StorageItem File=[INSTALLDIR]configuration.xml ElementPath=/Storage Node=element On=install Action=create util:XmlConfig Id=FirstAttributeId Name=Name Value=Checked File=[INSTALLDIR]configuration.xml ElementId=NodeId / util:XmlConfig Id=SecondAttributeId Name=Value Value=True File=[INSTALLDIR]configuration.xml ElementId=NodeId / /util:XmlConfig Of course, I can probably write an xml code snippet to help in this, but still... This seems rather cumbersome, is that really the best way to add nodes and attributes to an xml file? It seems kinda excessive that I have to have 3(!!) XmlConfig elements in order to add a single node with two attributes. Is there any way I can make this more streamlined? /Thomas -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there an easier way of adding nodes andattributes to an xml file?
*Sigh* I was afraid you'd say something like that. Ok, I'll just have to figure it out then, and find a way to test for the existence of the node. My XPath level of expertise is a step shy of beginner ;) Thanks the input. /Thomas -Original Message- From: Blair [mailto:os...@live.com] Sent: 14. oktober 2009 17:24 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Is there an easier way of adding nodes andattributes to an xml file? The actions supplied with the toolset are of a necessity made as generic as possible to be applicable to as many users as possible. Each action needs to be testable to ensure that future code modifications won't break existing uses, and testing resources are not unlimited. Those things constrain the provided actions to do one thing at a time. The source code is available to allow you to modify the actions to accomplish whatever your needs are (or to hire that task out). -Original Message- From: Thomas Due [mailto:thomas@scanvaegt.dk] Sent: Tuesday, October 13, 2009 11:00 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is there an easier way of adding nodes and attributes to an xml file? During my install I need to add some nodes to an xml file. These nodes will in addition have up to two attributes. The xml file itself is fairly simple with no really structure, just a single root and a bunch of children. Basically the xml file is structured like this: ?xml version=1.0 encoding=utf-8? Storage StorageItem name=.. / StorageItem name=.. value=.../ StorageItem name=.. value=.../ ... /Storage As far as I can tell, the way I add nodes and attributes to this, is like this: util:XmlConfig Id=NodeId Name=StorageItem File=[INSTALLDIR]configuration.xml ElementPath=/Storage Node=element On=install Action=create util:XmlConfig Id=FirstAttributeId Name=Name Value=Checked File=[INSTALLDIR]configuration.xml ElementId=NodeId / util:XmlConfig Id=SecondAttributeId Name=Value Value=True File=[INSTALLDIR]configuration.xml ElementId=NodeId / /util:XmlConfig Of course, I can probably write an xml code snippet to help in this, but still... This seems rather cumbersome, is that really the best way to add nodes and attributes to an xml file? It seems kinda excessive that I have to have 3(!!) XmlConfig elements in order to add a single node with two attributes. Is there any way I can make this more streamlined? /Thomas -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using resource strings but not localizing the MSI
Ok, thanks. As I wrote it wasn't as much a problem as an annoyance :)
/Thomas
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: 12. oktober 2009 09:37
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Using resource strings but not localizing the MSI
The one day that you do decide to localize it, you won't suddenly find your
second language overwriting your MSI from the first.
How all this works can be found in the wix.targets file (AssignCultures
target):
Determines the final list of culture groups to build based on either the
Cultures property or
those specified in .wxl files.
Culture groups specified in the Cultures property must be specified as
a semi-colon
delimited list of groups, with comma-delimited cultures within a
group.
For example:
Culturesen-US,en;en-GB,en/Cultures
This will build 2 targets, outputing to en-US and en-GB sub-folders.
Light will first look
for strings in the first culture (en-US or en-GB) then the second
(en).
Cultures of .wxl files will be used when the Culture property is not
set. The culture of a
.wxl file is determined by the Culture attribute in the
WixLocalization element in the file
Sets the OutputFolder metadata on each culture group. In most cases
this is the same as the
first culture in the culture group. When the Culture's property is
unspecified and no .wxl
files are provided this is the same as the output directory. When the
Culture's property
specifies a single culture group and no .wxl files are provided this is
the same as the output
directory.
Updates the TargetPath and TargetPdbPath properties to be used in
subsequent targets.
-Original Message-
From: Thomas Due [mailto:thomas@scanvaegt.dk]
Sent: Sunday, October 11, 2009 10:31 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Using resource strings but not localizing the MSI
I have another problem with my installer, or rather, not so much a problem
as an annoyance.
I have collected all string in my WiX project in a .wxl file, like this:
WixLocalization Culture=en-us
xmlns=http://schemas.microsoft.com/wix/2006/localization;
String Id=SelectLanguageDlgSelect Nationality/String
String Id=SelectLanguageTitle{\WixUI_Font_Title}Select
Language/String
String Id=SelectLanguageDescriptionSelect the language of the
installation./String
...
/WixLocalization
My intention is to collect all strings in one place, so that when we one
day decide to localize the installer, it is fairly easy to do. In any event
I think it is kinda a best practice, instead of having hardcoded text
scattered all over the place.
However, this results in my MSI being placed in a en-us subfolder. It is not
critical, but it IS a bit annoying. I don't really wish to localize my
installer, I just want to collect my strings in a resource file for the
eventuality that I one day wants to localize it.
I am a bit stumped by this, because the UI strings, and others strings seems
to be localized (I looked in the source code) in the same way, and unless
I include a .wxl file myself, I don't have to bother with the Culture thing
when these are included.
I checked my project settings, and the culture field is empty, and yet,
light.exe still insists on adding a -cultures:en-us to the parameters.
How do I prevent WiX from assuming I want to localize and still be able to
collect all my string in a resource file?
If this is the way it has to be, then so be it, I'll live with it, but it is
annoying that Light does this.
/Thomas
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Cumbersome method of adding nodes and attributes to an xml file
During my install I need to add some nodes to an xml file. These nodes will in addition have up to two attributes. The xml file itself is fairly simple with no really structure, just a single root and a bunch of children. Basically the xml file is structured like this: ?xml version=1.0 encoding=utf-8? Storage StorageItem name=.. value=.../ StorageItem name=.. value=.../ StorageItem name=.. value=.../ ... /Storage As far as I can tell, the way I add nodes and attributes to this, is like this: util:XmlConfig Id=NodeId Name=StorageItem File=[INSTALLDIR]configuration.xml ElementPath=/Storage Node=element On=install Action=create util:XmlConfig Id=FirstAttributeId Name=Name Value=Checked File=[INSTALLDIR]configuration.xml ElementId=NodeId / util:XmlConfig Id=SecondAttributeId Name=Value Value=True File=[INSTALLDIR]configuration.xml ElementId=NodeId / /util:XmlConfig Of course, I can probably write an xml code snippet to help in this, but still... This seems rather cumbersome, is that really the best way to add nodes and attributes to an xml file? /Thomas -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to modify a file during install using a CA
Yes, that is the approach I went with to get it to work, and it worked
beautifully, so as it turns out, I was basically just wondering why I couldn't
access the installer properties in a deferred action.
Thanks for the answer, it helped a bit with my understanding of the beast
called Windows Installer... 5% understanding down, 95% to go, or so it feels at
times.
/Thomas
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: 10. oktober 2009 23:30
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] How to modify a file during install using a CA
All in-script actions (deferred, rollback, and commit) do not have access
to session properties or the database. You have to pass them information
using properties (named after the in-script action's name) that the action
can retrieve using the special CustomActionData property.
In your case I would recommend you instead create an immediate custom action
that takes the properties you need to encrypt and generate properties that
contain those encrypted values, and then you can use XmlConfig and/or
XmlFile to place the values of the properties you generate with the
encrypted values.
-Original Message-
From: Thomas Due [mailto:thomas@scanvaegt.dk]
Sent: Saturday, October 10, 2009 4:45 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to modify a file during install using a CA
During the install interview I collect information about the database
connection and this information has to be added to an xml file which is
added during install. I could do this using the XmlConfig or XmlFile
elements, but unfortunately some of the information have to be encrypted
before added to the file. This is, of course, not possible using the MSI or
WiX elements, so I have to use a CA which then handles the encryption.
The Xml is used by a windows service installed and started during the
install, so I have to modify the file AFTER the files have been installed,
but before the service is started.
I struggled with this for a while, it was easy enough to find the exact spot
to call the CA, however it seems (according to the log file) that the MSI
makes two passes, so to speak.
And the CA fired during the first pass where the installer is simply
figuring out what to do, as far as I can figure.
So, I figured out that I need to delay the execution of the CA to the second
pass, but how to do that? I have tried with Execute=commit and
Execute=Deferred like this:
CustomAction Id=AddXmlConfig BinaryKey=XmlConfig DllEntry=AddXml
Execute=commit/
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize/
LaunchConditions After=AppSearch/
Custom Action=AddXmlConfig After=InstallServices
SERVERINSTALL/Custom
/InstallExecuteSequence
But this results in this exception thrown:
System.Reflection.TargetInvocationException: Exception has been thrown by
the target of an invocation. ---
Microsoft.Deployment.WindowsInstaller.InstallerException: Cannot access
session details from a non-immediate custom action
What does this mean? Why can I not access session details during commit or
deferred, and how do I access the properties then?
My CA looks like this, somewhat shortened though:
[CustomAction]
public static ActionResult AddXml(Session session)
{
string xmlDoc = Path.Combine(session[INSTALLDIR], configuration.xml);
// Exact data from Session properties and encrypt where necessary
XmlDocument doc = new XmlDocument();
if (File.Exists(xmlDoc))
{
doc.Load(xmlDoc);
// Add nodes and attributes to the xml document
doc.Save(xmlDoc);
return ActionResult.Success;
}
else
return ActionResult.NotExecuted;
}
So assuming that I am not completely off track, how do I accomplish this
task?
To sum it up:
I need to modify a xml file using a CA during installation, but before
starting services. I have a work-around that actually works, where I simply
perform the encryption in the CA and lets my installer handle the xml file
modifications. I would like to know why this is not working though, and how
I MAKE it work. Next time, it may not be possible to modify the file using
only msi and wix.
Any ideas?
/Thomas
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend
[WiX-users] Using resource strings but not localizing the MSI
I have another problem with my installer, or rather, not so much a problem as
an annoyance.
I have collected all string in my WiX project in a .wxl file, like this:
WixLocalization Culture=en-us
xmlns=http://schemas.microsoft.com/wix/2006/localization;
String Id=SelectLanguageDlgSelect Nationality/String
String Id=SelectLanguageTitle{\WixUI_Font_Title}Select Language/String
String Id=SelectLanguageDescriptionSelect the language of the
installation./String
...
/WixLocalization
My intention is to collect all strings in one place, so that when we one day
decide to localize the installer, it is fairly easy to do. In any event I think
it is kinda a best practice, instead of having hardcoded text scattered all
over the place.
However, this results in my MSI being placed in a en-us subfolder. It is not
critical, but it IS a bit annoying. I don't really wish to localize my
installer, I just want to collect my strings in a resource file for the
eventuality that I one day wants to localize it.
I am a bit stumped by this, because the UI strings, and others strings seems to
be localized (I looked in the source code) in the same way, and unless I
include a .wxl file myself, I don't have to bother with the Culture thing when
these are included.
I checked my project settings, and the culture field is empty, and yet,
light.exe still insists on adding a -cultures:en-us to the parameters.
How do I prevent WiX from assuming I want to localize and still be able to
collect all my string in a resource file?
If this is the way it has to be, then so be it, I'll live with it, but it is
annoying that Light does this.
/Thomas
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to modify a file during install using a CA
During the install interview I collect information about the database
connection and this information has to be added to an xml file which is added
during install. I could do this using the XmlConfig or XmlFile elements, but
unfortunately some of the information have to be encrypted before added to the
file. This is, of course, not possible using the MSI or WiX elements, so I have
to use a CA which then handles the encryption.
The Xml is used by a windows service installed and started during the install,
so I have to modify the file AFTER the files have been installed, but before
the service is started.
I struggled with this for a while, it was easy enough to find the exact spot to
call the CA, however it seems (according to the log file) that the MSI makes
two passes, so to speak.
And the CA fired during the first pass where the installer is simply figuring
out what to do, as far as I can figure.
So, I figured out that I need to delay the execution of the CA to the second
pass, but how to do that? I have tried with Execute=commit and
Execute=Deferred like this:
CustomAction Id=AddXmlConfig BinaryKey=XmlConfig DllEntry=AddXml
Execute=commit/
InstallExecuteSequence
RemoveExistingProducts After=InstallInitialize/
LaunchConditions After=AppSearch/
Custom Action=AddXmlConfig After=InstallServices
SERVERINSTALL/Custom
/InstallExecuteSequence
But this results in this exception thrown:
System.Reflection.TargetInvocationException: Exception has been thrown by the
target of an invocation. ---
Microsoft.Deployment.WindowsInstaller.InstallerException: Cannot access session
details from a non-immediate custom action
What does this mean? Why can I not access session details during commit or
deferred, and how do I access the properties then?
My CA looks like this, somewhat shortened though:
[CustomAction]
public static ActionResult AddXml(Session session)
{
string xmlDoc = Path.Combine(session[INSTALLDIR], configuration.xml);
// Exact data from Session properties and encrypt where necessary
XmlDocument doc = new XmlDocument();
if (File.Exists(xmlDoc))
{
doc.Load(xmlDoc);
// Add nodes and attributes to the xml document
doc.Save(xmlDoc);
return ActionResult.Success;
}
else
return ActionResult.NotExecuted;
}
So assuming that I am not completely off track, how do I accomplish this task?
To sum it up:
I need to modify a xml file using a CA during installation, but before starting
services. I have a work-around that actually works, where I simply perform the
encryption in the CA and lets my installer handle the xml file modifications. I
would like to know why this is not working though, and how I MAKE it work. Next
time, it may not be possible to modify the file using only msi and wix.
Any ideas?
/Thomas
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating SQLServer Users/Logins....
This one triggered me: This way I can pass username information into the SQL script as an MSI property. How do you do that? That is something I find could be very very useful to me, not only username information, but all sorts of information that could be useful during database creation, or update. TYI /Thomas -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: 6. oktober 2009 23:32 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQLServer Users/Logins Louis You need to look at SqlDatabase, SqlScript and SqlString. I use SqlString to create users (with TSQL) and then assign them a role in the target database, as SqlString expands formatted strings. This way I can pass username information into the SQL script as an MSI property. You could also use this to do the attach process, passing the file The alternate method to attaching databases is to script out you database creation into SLQ Scripts and use the WIX SqlScript custom actions to create the database. Michael -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: Wednesday, 7 October 2009 1:42 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Creating SQLServer Users/Logins Hi all, I'm working on a script that attaches our database to an instance of SQLServer. It then creates a virtual directory ( not under c:\Inetpub ) in IIS ( 6 or 7 ) and correctly sets the appropriate folder permissions so that the ASP.NET v2.x, can be viewed across the network. This all seems to work and I'll post some code snippets in the next week. My issue is that if these .aspx page make a DB call, it doesn't get through. On XP I can manually create a [ComputerName]\ASPNET Login and that seems to allow the pages to correctly connect to the SQLServer DB. On Vista, and I assume Window Server 2008, the ASPNET user does not exist :(. So my questions are, using Wix... 1. How can I automate the creation of a User/Login on SQLServer. 2. Is there a way to work out ( maybe via a custom action ) what the correct ASPNET/IIS user that is required for SQLServer to accepts connections from ASP.NET pages. 3. One of the developers here suggested that what might be better or more flexible would be to create a DB specific user and use that DB User to connect from the .aspx page to the DB. a. How can I automate the creation of the DB User? b. Can Wix automate the attachment of aforementioned user to the DB? 4. Are there better/easier ways of doing what I'm trying to do? I hope that all makes sense. DOMINIQUE LOUIS | IS DEVELOPER, AMX DIGITAL MEDIA GROUP AMX UK| 6TH FLOOR SALISBURY HOUSE,| LONDON WALL | LONDON | EC2M 5QQ www.amx.com AMX AMX UK Auster Road Clifton Moor York, North Yorkshire United Kingdom YO30 4GD +44 (0) 1904 343100 office +44 (0) 1904 343101 fax AMX South 6th Floor Salisbury House London Wall London United Kingdom EC2M 5QQ +44 (0) 2076 529450 office +44 (0) 8701 991661 fax AMX Belgium Boerenkrijglaan, 96a B-2260 Westerlo Belgium + 32 (0) 1454 2763 office + 32 (0) 1454 2766 fax ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. This email was scanned and cleared by NetIQ MailMarshal. ## -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating SQLServer Users/Logins....
Cool, thanks.
/Thomas
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: 7. oktober 2009 08:11
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creating SQLServer Users/Logins
Here's an example of how I create the user login for a database
depending if the database is on the same server as the web application
or a different server
Some of the security stored procs I am using are obsolete in SQL2008
though (this was built for SQL2000)
SqlDatabase Id=DBSQL1 CreateOnInstall=yes
ConfirmOverwrite=yes DropOnInstall=no ContinueOnError=no
Database=[BAYAPPDB] DropOnUninstall=no Server=[BAYDBSERVER]
SQL Scripts go here ---
SqlString Id=CreateUsers ContinueOnError=yes
ExecuteOnInstall=yes ExecuteOnReInstall=no Sequence=11000
SQL=
-- Add user to the database, if it is local then this is just
a Rpt User
-- Else add the System User
if ('[BAYSECURITYMODEL]'='local')
BEGIN
-- Create User in SQL
if ((select count(name) from master.dbo.syslogins where
name = '[BAYSYSUSERNAME]') lt; 1)
exec sp_addlogin '[BAYSYSUSERNAME]',
'[BAYSYSPASSWORD]'
if ((select count(name) from sysusers where sid=(select
sid from master.dbo.syslogins where name = '[BAYSYSUSERNAME]')) lt; 1)
BEGIN
exec sp_grantdbaccess '[BAYSYSUSERNAME]',
'RptUser'
exec sp_addrolemember @rolename = 'db_datareader',
@membername = 'RptUser'
END
END
else
BEGIN
-- Add the windows user to the system
if ( (select count(name) from master.dbo.syslogins where
name = '[BAYSYSUSERNAME]') lt; 1)
exec sp_grantlogin '[BAYSYSUSERNAME]'
-- Create User in this database
if ((select count(name) from sysusers where sid=(select
sid from master.dbo.syslogins where name = '[BAYSYSUSERNAME]')) lt; 1)
BEGIN
exec sp_grantdbaccess '[BAYSYSUSERNAME]',
'AppUser'
exec sp_addrolemember @rolename = 'db_datareader',
@membername = 'AppUser'
exec sp_addrolemember @rolename = 'db_datawriter',
@membername = 'AppUser'
END
END
-- If we are all installing together
if (('[BAYSECURITYMODEL]'='local') AND ('[ComputerName]' like
'[BAYDBSERVER]') AND ( NOT '[SKIPCONFIGUREIIS]' = '1' ))
BEGIN
if ( SUSER_ID('[ComputerName]\iis_wpg') is null)
exec sp_grantlogin '[ComputerName]\iis_wpg'
if ((select count(name) from sysusers where
sid=SUSER_SID('[ComputerName]\iis_wpg')) lt; 1)
BEGIN
exec sp_grantdbaccess '[ComputerName]\iis_wpg',
'iis_wpg'
exec sp_addrolemember @rolename = 'db_datareader',
@membername = 'iis_wpg'
exec sp_addrolemember @rolename = 'db_datawriter',
@membername = 'iis_wpg'
END
END
/
-Original Message-
From: Thomas Due [mailto:thomas@scanvaegt.dk]
Sent: Wednesday, 7 October 2009 4:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creating SQLServer Users/Logins
This one triggered me:
This way I can pass username information into the SQL script as an
MSI property.
How do you do that? That is something I find could be very very useful
to me, not only username information, but all sorts of information that
could be useful during database creation, or update.
TYI
/Thomas
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: 6. oktober 2009 23:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Creating SQLServer Users/Logins
Louis
You need to look at SqlDatabase, SqlScript and SqlString.
I use SqlString to create users (with TSQL) and then assign them a role
in the target database, as SqlString expands formatted strings. This
way I can pass username information into the SQL script as an MSI
property.
You could also use this to do the attach process, passing the file
The alternate method to attaching databases is to script out you
database creation into SLQ Scripts and use the WIX SqlScript custom
actions to create the database.
Michael
-Original Message-
From: Dominique Louis [mailto:dominique.lo...@amxeurope.com]
Sent: Wednesday, 7 October 2009 1:42 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Creating SQLServer Users/Logins
Hi all,
I'm working on a script that attaches our database to an instance of
SQLServer. It then creates a virtual directory ( not under c:\Inetpub )
in IIS ( 6 or 7 ) and correctly sets the appropriate folder permissions
so that the ASP.NET v2.x, can
Re: [WiX-users] CustomAction : Enumerating SQLServer Instances acrossthe network using SQLDMO
This would be perfect for http://wixrepo.codeplex.com/ Also: Looks good, looking forward to playing around with it, although the company I work for, will have to support 2008 as well in the near future. /Thomas -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 1. oktober 2009 18:16 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] CustomAction : Enumerating SQLServer Instances acrossthe network using SQLDMO Hi all, I couldn't find all this code in one place so I thought this list might be a good place to archive it. Set sqlApp = CreateObject(SQLDMO.Application) If ( Err.Number 0 ) Then wscript.echo SQLDMO.Application Not found. Error : Err.Number wscript.Quit -1 End If Set sqlServer2 = CreateObject(SQLDMO.SQLServer2) If ( Err.Number 0 ) Then wscript.echo SQLDMO.SQLServer2 Not found. Error : Err.Number wscript.Quit -1 End If Set serverList = sqlApp.ListAvailableSQLServers numServers = serverList.Count Dim x, y For x = 1 To numServers Set instanceList = sqlServer2.ListInstalledInstances( serverList(x) ) if Not ( instanceList is Nothing ) Then numInstances = instanceList.Count wscript.echo serverList(x) For y = 1 To numInstances wscript.echo instanceList(y) Next End IF Next Set sqlServer2 = Nothing Set sqlApp = Nothing Note SQLDMO only works with SQLServer 2005 and below and is not installed by default on SQLServer 2008 onwards Hope this helps someone. DOMINIQUE LOUIS | IS DEVELOPER, AMX DIGITAL MEDIA GROUP AMX UK| 6TH FLOOR SALISBURY HOUSE,| LONDON WALL | LONDON | EC2M 5QQ www.amx.com AMX AMX UK Auster Road Clifton Moor York, North Yorkshire United Kingdom YO30 4GD +44 (0) 1904 343100 office +44 (0) 1904 343101 fax AMX South 6th Floor Salisbury House London Wall London United Kingdom EC2M 5QQ +44 (0) 2076 529450 office +44 (0) 8701 991661 fax AMX Belgium Boerenkrijglaan, 96a B-2260 Westerlo Belgium + 32 (0) 1454 2763 office + 32 (0) 1454 2766 fax ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. This email was scanned and cleared by NetIQ MailMarshal. ## -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom UI Repository
I think such a repository would be great. Maybe using Codeplex? I think everybody (if logged in) can upload patches on the source code tab, without having to be a member of the project. Codeplex would also supply a nice forum for discussion of these packages. This would still leave the mailing list for technical questions and such as it is now. I have no admin experience on Codeplex though, so I am not sure if any of what I said is true. What IS true though, is that I know of several teams that use Codeplex for something exactly like this, although I am not familiar with the administrative work necessary. Thomas Due -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 18. september 2009 10:21 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom UI Repository I think this would be a great idea, and would certainly save everyone time in the long run, if it was done well. A repository for CustomActions with full source would also be useful, maybe broken up into language categories ( VbScript, Jscript, C/C++, .NET, Delphi etc ) Dominique. -Original Message- From: Slide [mailto:slide.o@gmail.com] Sent: 18 September 2009 05:01 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Custom UI Repository Are there any sites that repositories of custom UI markup? I would think that there would be scenarios that people would use quite frequently which would come in handy (SQL Server login info, username/password for stuff, key file selection) and I was wondering if there was a place to share stuff I may have, and pick up stuff that other people may have created. Thanks, slide -- slide-o-blog http://slide-o-blog.blogspot.com/ -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users AMX AMX UK Auster Road Clifton Moor York, North Yorkshire United Kingdom YO30 4GD +44 (0) 1904 343100 office +44 (0) 1904 343101 fax AMX South 6th Floor Salisbury House London Wall London United Kingdom EC2M 5QQ +44 (0) 2076 529450 office +44 (0) 8701 991661 fax AMX Belgium Boerenkrijglaan, 96a B-2260 Westerlo Belgium + 32 (0) 1454 2763 office + 32 (0) 1454 2766 fax ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. This email was scanned and cleared by NetIQ MailMarshal. ## -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Questions regarding the SqlExtension
Aha! That is what I was looking for. I'll play with that, and see if I can make it work. Thanks, Thomas DUe -Original Message- From: André Werlang [mailto:and...@gvdasa.com.br] Sent: 28. august 2009 15:17 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RES: Questions regarding the SqlExtension Hi buddy! I'm sorry for I somewhat misguided you, I was in a hurry and didn't recalled correctly the steps for SqlExtension. We have a general element called User in the SqlUtil package. It can be referenced in the User attribute of SqlDatabase, like this: util:User Id='SQLUser' Name='[SQLUSER]' Password='[SQLPASSWORD]' / sql:SqlDatabase Id='SQLDatabase' User='SQLUser' ... / Define properties for SQLUSER and SQLPASSWORD. Regards, André Felipe Werlang Antes de imprimir pense em seu compromisso com o Meio Ambiente e o comprometimento com os Custos -Mensagem original- De: Thomas Due [mailto:tho@gmail.com] Enviada em: 28 de agosto de 2009 03:57 Para: WiX-users Assunto: Re: [WiX-users] Questions regarding the SqlExtension Hmm, well you're probably right about the binary elements, I'll play a bit with that. Regarding the Password property suggested by Andre, there is no such property on the SqlDatabase element. So, if I don't have the option of creating a database using integrated security, what do I do then? -- Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 27. august 2009 19:52 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] RES: Questions regarding the SqlExtension I'm assuming that the @BinaryKey attributes are pulling the scripts from the Binary table (populated with the Binary elements). Thus, you probably don't need the File elements with those same files for the Sql:SqlScript elements at all. That should get rid of the need to delete them towards the end of install. -Original Message- From: André Werlang [mailto:and...@gvdasa.com.br] Sent: Thursday, August 27, 2009 7:27 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RES: Questions regarding the SqlExtension Hi. 1) Check out the User and Password attributes of SqlDatabase. Need to ask the user for user/password? Create controls in a dialog and associate with properties. Remember to hid the password, i.e. Property Id='SQLPASSWORD' Hidden='yes'/Property 2) Hmm...I'm not sure, but I think that this binaries are deleted. 3) Could you write a single SQL script that checks on the existence of the database and perform the apropriate actions? Otherwise you would have to go for a custom action, I think. Regards, André Felipe Werlang PAntes de imprimir pense em seu compromisso com o Meio Ambiente e o comprometimento com os Custos -Mensagem original- De: Thomas Due [mailto:tho@gmail.com] Enviada em: 27 de agosto de 2009 09:46 Para: WiX-users Assunto: [WiX-users] Questions regarding the SqlExtension I am currently creating an installer which have to create a database. This works fine as goes, however I have a question: Right now my code looks like this: Binary Id=DB SourceFile=.\Database\DB.SQL / Binary Id=Data SourceFile=.\Database\Data.SQL / DirectoryRef Id=INSTALLDIR Component Id=DatabaseInstall Guid= 1D1A4965-D440-47C0-BA3E-29E43EBF1D03 DiskId=1 KeyPath=yes File Id=CreateDB Name=DB.SQL Source=.\Database\DB.SQL / File Id=CreateData Name=Data.SQL Source= .\Database\Data.SQL/ Sql:SqlDatabase Id=ScanXNETDatabase Server= [DATABASESERVER] Database=[DATABASENAME] CreateOnInstall=yes ConfirmOverwrite=no Sql:SqlScript Id=CreateDB ExecuteOnInstall=yes BinaryKey=DB Sequence=1/ Sql:SqlScript Id=Data ExecuteOnInstall=yes BinaryKey=Data Sequence=1/ /Sql:SqlDatabase /Component /DirectoryRef I have a few problems with this: First, this requires integrated security, if that is not possible, how do I supply a user id and password for the creation of my database? Second, how do I ensure that the script files are deleted from INSTALLDIR after the database has been created? Third, if the database already exists on the server I do NOT want to delete it, but rather run an update script, how do I do that? Please help. The help file is rather vague on the use of the Sql Extension, and my google-fu seems to be lacking. -- Thomas Due -- Mvh Thomas Due
Re: [WiX-users] Questions regarding the SqlExtension
Hmm, well you're probably right about the binary elements, I'll play a bit with that. Regarding the Password property suggested by Andre, there is no such property on the SqlDatabase element. So, if I don't have the option of creating a database using integrated security, what do I do then? -- Thomas Due -Original Message- From: Blair [mailto:os...@live.com] Sent: 27. august 2009 19:52 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] RES: Questions regarding the SqlExtension I'm assuming that the @BinaryKey attributes are pulling the scripts from the Binary table (populated with the Binary elements). Thus, you probably don't need the File elements with those same files for the Sql:SqlScript elements at all. That should get rid of the need to delete them towards the end of install. -Original Message- From: André Werlang [mailto:and...@gvdasa.com.br] Sent: Thursday, August 27, 2009 7:27 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RES: Questions regarding the SqlExtension Hi. 1) Check out the User and Password attributes of SqlDatabase. Need to ask the user for user/password? Create controls in a dialog and associate with properties. Remember to hid the password, i.e. Property Id='SQLPASSWORD' Hidden='yes'/Property 2) Hmm...I'm not sure, but I think that this binaries are deleted. 3) Could you write a single SQL script that checks on the existence of the database and perform the apropriate actions? Otherwise you would have to go for a custom action, I think. Regards, André Felipe Werlang PAntes de imprimir pense em seu compromisso com o Meio Ambiente e o comprometimento com os Custos -Mensagem original- De: Thomas Due [mailto:tho@gmail.com] Enviada em: 27 de agosto de 2009 09:46 Para: WiX-users Assunto: [WiX-users] Questions regarding the SqlExtension I am currently creating an installer which have to create a database. This works fine as goes, however I have a question: Right now my code looks like this: Binary Id=DB SourceFile=.\Database\DB.SQL / Binary Id=Data SourceFile=.\Database\Data.SQL / DirectoryRef Id=INSTALLDIR Component Id=DatabaseInstall Guid= 1D1A4965-D440-47C0-BA3E-29E43EBF1D03 DiskId=1 KeyPath=yes File Id=CreateDB Name=DB.SQL Source=.\Database\DB.SQL / File Id=CreateData Name=Data.SQL Source= .\Database\Data.SQL/ Sql:SqlDatabase Id=ScanXNETDatabase Server= [DATABASESERVER] Database=[DATABASENAME] CreateOnInstall=yes ConfirmOverwrite=no Sql:SqlScript Id=CreateDB ExecuteOnInstall=yes BinaryKey=DB Sequence=1/ Sql:SqlScript Id=Data ExecuteOnInstall=yes BinaryKey=Data Sequence=1/ /Sql:SqlDatabase /Component /DirectoryRef I have a few problems with this: First, this requires integrated security, if that is not possible, how do I supply a user id and password for the creation of my database? Second, how do I ensure that the script files are deleted from INSTALLDIR after the database has been created? Third, if the database already exists on the server I do NOT want to delete it, but rather run an update script, how do I do that? Please help. The help file is rather vague on the use of the Sql Extension, and my google-fu seems to be lacking. -- Thomas Due -- Mvh Thomas Due -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Questions regarding the SqlExtension
I am currently creating an installer which have to create a database. This works fine as goes, however I have a question: Right now my code looks like this: Binary Id=DB SourceFile=.\Database\DB.SQL / Binary Id=Data SourceFile=.\Database\Data.SQL / DirectoryRef Id=INSTALLDIR Component Id=DatabaseInstall Guid= 1D1A4965-D440-47C0-BA3E-29E43EBF1D03 DiskId=1 KeyPath=yes File Id=CreateDB Name=DB.SQL Source=.\Database\DB.SQL / File Id=CreateData Name=Data.SQL Source= .\Database\Data.SQL/ Sql:SqlDatabase Id=ScanXNETDatabase Server= [DATABASESERVER] Database=[DATABASENAME] CreateOnInstall=yes ConfirmOverwrite=no Sql:SqlScript Id=CreateDB ExecuteOnInstall=yes BinaryKey=DB Sequence=1/ Sql:SqlScript Id=Data ExecuteOnInstall=yes BinaryKey=Data Sequence=1/ /Sql:SqlDatabase /Component /DirectoryRef I have a few problems with this: First, this requires integrated security, if that is not possible, how do I supply a user id and password for the creation of my database? Second, how do I ensure that the script files are deleted from INSTALLDIR after the database has been created? Third, if the database already exists on the server I do NOT want to delete it, but rather run an update script, how do I do that? Please help. The help file is rather vague on the use of the Sql Extension, and my google-fu seems to be lacking. -- Thomas Due -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Option checkbox in ExitDialog isn't transparent
Is it possible to catch click events on labels on a custom dialog? If so, would it be possible to bind a click event on the label that puts focus on the checkbox and checks/unchecks it? Or is that too advanced for MSI? Thomas -Original Message- From: Rob Mensching [mailto:r...@wixtoolset.org] Sent: 3. juli 2009 10:01 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Option checkbox in ExitDialog isn't transparent and accessibility is hosed. Neil Sleightholm wrote: There is a workaround for this. Create a custom exit dialog and make the checkbox only the size of the tick, then put a label next to it. It works but means that the user needs to click the check area only, the label part doesn't work. Neil -Original Message- From: Quinton Tormanen [mailto:quint...@deltacompsys.com] Sent: 02 July 2009 19:10 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Option checkbox in ExitDialog isn't transparent Sorry, I had searched for WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT in the bug database, but after posting I searched for transparent and found the issue right away (1669640). It's noted that there is no fix, which I understand. I promise that I tried to check that it wasn't already posted, but just not well enough! --Quinton -Original Message- From: Quinton Tormanen Sent: Thursday, July 02, 2009 11:06 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Option checkbox in ExitDialog isn't transparent I have a white background for my dlgbmp.bmp resource, like the one that WiX provides by default. I tried using WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT to allow the user to control whether our application is run at the end of the install. However, the entire checkbox control has a gray background. I see that there isn't a @Transparent=yes for this control like the others, but then I'm also aware that checkboxes are notorious for not being very easily made transparent in Win32. So, is this a known issue with no good workaround? Or is there a fix that can be made to ExitDialog so that it is transparent? I'm using WiX 3.0.5217.0 on x64 Vista. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Execute an MSI within an MSI
Or you could check with your provider to see if he can deliver a merge module instead? Thomas -Original Message- From: Dirk Räder [mailto:d...@raeder.cc] Sent: 3. juli 2009 12:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Execute an MSI within an MSI Hi, it is definitely not possible to call another MSI when an installation process is already running. Windows Installer takes care of that. You can either reverse engineer the MSI as already suggested, which I would not do - you have to do so every time you get a new MSI from your provider. I would write a simple bootstrapper application that calls the MSIs in sequence. If the second installer fails, uninstallation of the first installation should be proposed to the user. Hope that helps, Dirk 2009/7/3 Sunkesula, Srivardhan srivardhan.sunkes...@netapp.com: As far as I know, we cannot call an MSI inside an other MSI. Anyone Correct me if I'm wrong. What we can do is generate wxs from the msi(reverse engineering), which we need inside our msi. Then generate an MSI including those wxs. Thanks Regards, Srivardhan. -Original Message- From: David Hernández Díez [mailto:dhd...@hotmail.com] Sent: Friday, July 03, 2009 2:13 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Execute an MSI within an MSI Hello, I am wondering if it is possible to execute an MSI within the MSI that I create using Wix. I need to do it because a provider delivers me an MSI to install part of a solution and I need to bundle everything within an MSI. Thanks, David _ Windows Live(tm): Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bootstrapper of .NET Framework 3.5 SP1
And the next obvious question would then be: When is WiX v3.5 coming out? ;) /Thomas -Original Message- From: Rob Mensching [mailto:r...@wixtoolset.org] Sent: 28. maj 2009 17:56 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bootstrapper of .NET Framework 3.5 SP1 There are many. Unfortunately, nothing that great in the WiX toolset yet... ours is coming in WiX v3.5. rahul.ekb...@sungard.com wrote: Hi, Is there bootstrapper available for .net 3.5 SP1 Thanks, Rahul Ekbote Senior Software Engineer * SunGard * ALM * Bacware * SunGard Technology Services (India), Meridian Plaza, S B Road, Shivajinagar, Pune 411016. Direct Tel +91-20-25606237 * Main Tel +91-20-30238000 * Fax +91-20-25606222 * rahul.ekb...@sungard.com mailto:rahul.ekb...@sos.sungard.com * www.sungard.com http://www.sungard.com/bancware /bancware P Think before you print CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, please notify the sender and delete this e-mail from your system. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] This installation package could not be opened.
I usually experience this error when I forget where I am and try to execute an MSI package from a subst'ed drive. I get the same when executing from a network drive. I have not looked deeply into the cause, but it seems that the msi needs to be on at least a primary partition for msiexec to run it. /Thomas Due -Original Message- From: Michael.A.Kelley [mailto:michael.a.kel...@gmail.com] Sent: 1. april 2009 02:36 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] This installation package could not be opened. It's hard to say the exact circumstances. The .msi is downloaded from our website, and I don't have access to the client's computer. The client that last reported this problem has his AV scanner disabled. I'll ask him if he's running it from a network share. What are the circumstances when it fails? Perhaps there is another process locking the file open? I have seen this error occasionally when I try to open a package that is on a network share with orca. I presume that there is an AV scanner running on the server locking the file open. I have a .msi I've created using Wix that seems to work on a lot of computers. However, I occasionally have reports of of clients running the .msi on their computer and getting this error message: This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package. Does anyone know how I can recreate this image, and what I could possibly be doing wrong in my .wxs file? This error happens with both 2.0 and 3.0 versions of Wix. Product.wxs -- View this message in context: http://n2.nabble.com/%22This-installation-package-could-not-be-opened.%2 2-tp2566106p2566361.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Transparent launch application checkbox on exit dialog.
I have a nice little launch application check box on my exit dialog, but the background is not transparent. I suppose this is an issue of the MSI but is there a way around it, so I can make the background transparent? Sincerely, Thomas Due -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] auto delete on reinstall
Right. The reason I am asking is because in the past we have used InstallShield for our installations. With InstallShield it is possible to make an installation on top of an older installation, without changing the entry in the Add/Remove programs. It is a feature (one of the few) of InstallShield that I really like. However, I am aware that MSI usually uninstalls first, before installing a new version. I am not adverse to the concept, on the contrary, however I am wondering why it HAS to be this way. I know I can use patches and minor upgrades etc. to side-step the issue of uninstallation. However I don't want to start packaging patches to one version while Having an complete installer for another version. I can accept patches For critical bug fixes, but the next version is rolled out as a complete Installation. The way we are distributing our software does not warrant anything but a single installation script, I do not wish begin juggling major versions, minor versions etc. So, bottom line: Mainly I am asking from a philosophical viewpoint, but also from a practical viewpoint. /Thomas Due -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: 4. februar 2009 17:29 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] auto delete on reinstall Another thing to consider if you don't remove the old version is what does Control Panel Add/Remove Programs look like. If you have multiple entries then I've had customers remove the older ones, sometimes leading to problems in the newer ones. At a minimum it can cause some confusion. Chad -Original Message- From: Thomas Due [mailto:thomas@scanvaegt.dk] Sent: Tuesday, February 03, 2009 10:57 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] auto delete on reinstall Related question: Why should the old version even have to be uninstalled first? Shouldn't it be enough to just install on top of the old version? If so, how would one do that? /Thomas Due -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: 3. februar 2009 17:49 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] auto delete on reinstall I believe you need to change your Product Id= to use a different GUID than your previous package and also change the version. You might also need to add a Package Id=----, but not sure it is required to remove the previous package. HTH -Original Message- From: Thomas Guettler [mailto:h...@tbz-pariv.de] Sent: Friday, January 30, 2009 6:23 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] auto delete on reinstall Hi, thank you for this hint. I found more information now after searching for Major Upgrade. But somehow I couldn't find a working example. Here is my xml file: ?xml version='1.0'? !-- $Id: tbzmodwincontrol.wxs 9 2009-01-30 11:29:29Z tguettler $ $HeadURL: svn+ssh://svnserver/svn/modwincontrol/trunk/ms-windows/tbzmodwincontrol.wxs $ -- ?define Version = 1.0.78 ? !-- Variable muss immer erhöht werden. -- ?define UpgradeCode = 5B3289E7-EEFC-42BF-BC67-6B355C416290 ? !-- Variable bleibt konstant -- Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' Product Id='94132004-8EB3-4606-AA2E-9D58D2A5BE4A' Name='TBZ-PARIV ModWinControl $(var.Version)' Version='$(var.Version)' Manufacturer='TBZ-PARIV' Language='1033' UpgradeCode='$(var.UpgradeCode)' Package Description='TBZ-PARIV ModwinControl for Windows' Compressed='yes'/ Property Id='ALLUSERS' Value='1' / !-- http://neilsleightholm.blogspot.com/2009/01/wix-script-for-major-upgrades.html -- Property Id=UPGRADEFOUND Secure=yes / Property Id=NEWPRODUCTFOUND Secure=yes / Upgrade Id=$(var.UpgradeCode) UpgradeVersion Minimum=$(var.Version) IncludeMinimum=no OnlyDetect=yes Property=NEWPRODUCTFOUND / UpgradeVersion Minimum=0.0.0 Maximum=$(var.Version) IncludeMinimum=yes IncludeMaximum=no Property=UPGRADEFOUND / /Upgrade CustomAction Id=PreventDowngrading Error=Newer version already installed. / InstallExecuteSequence FindRelatedProducts Before=LaunchConditions / RemoveExistingProducts After=InstallValidate / Custom Action=PreventDowngrading After=FindRelatedProductsNEWPRODUCTFOUND/Custom /InstallExecuteSequence InstallUISequence Custom Action=PreventDowngrading After=FindRelatedProductsNEWPRODUCTFOUND/Custom /InstallUISequence Media Id='1' EmbedCab='yes' Cabinet='tbzmwc.cab'/ !-- Die cab-Datei wird in die msi-Datei eingebunden, so dass nur eine Datei benötigt wird. -- Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder
Re: [WiX-users] auto delete on reinstall
Related question: Why should the old version even have to be uninstalled first? Shouldn't it be enough to just install on top of the old version? If so, how would one do that? /Thomas Due -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: 3. februar 2009 17:49 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] auto delete on reinstall I believe you need to change your Product Id= to use a different GUID than your previous package and also change the version. You might also need to add a Package Id=----, but not sure it is required to remove the previous package. HTH -Original Message- From: Thomas Guettler [mailto:h...@tbz-pariv.de] Sent: Friday, January 30, 2009 6:23 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] auto delete on reinstall Hi, thank you for this hint. I found more information now after searching for Major Upgrade. But somehow I couldn't find a working example. Here is my xml file: ?xml version='1.0'? !-- $Id: tbzmodwincontrol.wxs 9 2009-01-30 11:29:29Z tguettler $ $HeadURL: svn+ssh://svnserver/svn/modwincontrol/trunk/ms-windows/tbzmodwincontrol.wxs $ -- ?define Version = 1.0.78 ? !-- Variable muss immer erhöht werden. -- ?define UpgradeCode = 5B3289E7-EEFC-42BF-BC67-6B355C416290 ? !-- Variable bleibt konstant -- Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' Product Id='94132004-8EB3-4606-AA2E-9D58D2A5BE4A' Name='TBZ-PARIV ModWinControl $(var.Version)' Version='$(var.Version)' Manufacturer='TBZ-PARIV' Language='1033' UpgradeCode='$(var.UpgradeCode)' Package Description='TBZ-PARIV ModwinControl for Windows' Compressed='yes'/ Property Id='ALLUSERS' Value='1' / !-- http://neilsleightholm.blogspot.com/2009/01/wix-script-for-major-upgrades.html -- Property Id=UPGRADEFOUND Secure=yes / Property Id=NEWPRODUCTFOUND Secure=yes / Upgrade Id=$(var.UpgradeCode) UpgradeVersion Minimum=$(var.Version) IncludeMinimum=no OnlyDetect=yes Property=NEWPRODUCTFOUND / UpgradeVersion Minimum=0.0.0 Maximum=$(var.Version) IncludeMinimum=yes IncludeMaximum=no Property=UPGRADEFOUND / /Upgrade CustomAction Id=PreventDowngrading Error=Newer version already installed. / InstallExecuteSequence FindRelatedProducts Before=LaunchConditions / RemoveExistingProducts After=InstallValidate / Custom Action=PreventDowngrading After=FindRelatedProductsNEWPRODUCTFOUND/Custom /InstallExecuteSequence InstallUISequence Custom Action=PreventDowngrading After=FindRelatedProductsNEWPRODUCTFOUND/Custom /InstallUISequence Media Id='1' EmbedCab='yes' Cabinet='tbzmwc.cab'/ !-- Die cab-Datei wird in die msi-Datei eingebunden, so dass nur eine Datei benötigt wird. -- Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=APPLICATIONROOTDIRECTORY Name=TBZ-PARIV ModWinControl Component Id=tbzmodwincontrol Guid=* File Id=tbzmodwincontrol.exe Source=dist\tbzmodwincontrol.exe KeyPath=yes/ /Component /Directory /Directory /Directory Feature Id=MainApplication Title=TBZPARIV MODWINCONTROL Level=1 ComponentRef Id=tbzmodwincontrol / /Feature /Product /Wix Rob Mensching schrieb: Yeah sure. Check out Major Upgrade. Hi, if I try to install a new version of my msi file, I get the error message, that I need to uninstall it first. Is there a way to automatically uninstall it? Is possible to enable a switch in the wix file that says delete old version on install? The next best solution would be an option if you start the installation from the shell. Thomas istinfo/wix-users -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users
Re: [WiX-users] Specify source of exe in ServiceInstall
I actually struggled a bit with this as well, I discovered that the easiest way to do that is: Component Id=NameServiceComponent Guid=* DiskId=1 File Id=ServiceId Name=FileName Source=FilePath / ServiceInstall Id=ServiceInstallId DisplayName=ServiceDisplayName Name=ServiceName Description= ErrorControl=normal Start=auto Type=ownProcess Vital=yes Account=NT AUTHORITY\NetworkService Interactive=no/ /Component Apparently the ServiceInstall node references the file node directly above it. Thomas Due -Original Message- From: Anupama A [mailto:anupama...@gmail.com] Sent: 26. januar 2009 08:24 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Specify source of exe in ServiceInstall I am trying to write an installer for a Windows Service. Depending on the deploy environment, I set a property called [ApplicationDirectory]. I have a separate component which copies all files from [ProgramFilesFolder] to [ApplicationDirectory] depending on what is dynamically set. And then the service install from the new location [ApplicationDirectory] should happen. In the below statement how do I specify the Service1.exe is in the [AppDirectory] path: ServiceInstall Id=Service1Installer Name=Service1.exe Type=ownProcess Start=auto Vital=yes ErrorControl=normal/ServiceInstall Wrapping this within a File element with the source pointing to the exe from the new location will fail at compile time as [AppDirectory] will not be set then. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setting folder permissions (was: Problems installing a windows service)
Yes, I have been messing around with Permission, and so far I have this: DirectoryId Id=INSTALLDIR Component Id=FolderPermissions Guid=174E96BB-87D6-40B0-84A4-8FF6C58BA702 CreateFolder Directory=INSTALLDIR Permission User=NT AUTHORITY\NetworkService GenericRead=yes GenericWrite=yes / /CreateFolder /Component /DirectoryId My problem is, that I seem to REPLACE the existing permissions, where I need to ADD to them. When I do this, I complete remove all other permissions on the folder (Except for System). Shouldn't it be possible to append a new permission set, instead of replacing the existing? It doesn't seem right that I have to add ALL permissions to a folder, when it can just as well Inherit those from its parent. Thomas Due -Original Message- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: 23. januar 2009 19:56 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems installing a windows service I think there are some WiX built-in custom actions that set permissions - I forget if it's Permissions or something else. Phil Wilson -Original Message- From: Thomas Due [mailto:thomas@scanvaegt.dk] Sent: Friday, January 23, 2009 1:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems installing a windows service It was the account name. I changed it to NT AUTHORITY\NetworkService and presto: It installed without a hitch. Now I only have a single question (at the moment): How do I set specific permissions to a specific account on the installdir? I need to set write permissions for NT AUTHORITY\NetworkService on the installation directory. Thanks, Thomas Due -Original Message- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: 23. januar 2009 01:54 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems installing a windows service To add to this: 1) A dependent assembly that you're installing in the GAC will be an issue because they're not available until the end of the install after StartServices. 2) What would you do in other circumstances if your service crashed or would not start? This is no different really. If it doesn't start at all it's usually a dependency issue, an account issue, or a catastrophic crash as soon as it starts. Trace or debug entries are something I can't live without these days. It's not that I'm a poor developer, honest, but with TraceListeners it's so easy to put trace information that it's bad practice NOT to add Trace.WriteLine that goes to a text file somewhere. 3) Regardless of what tool you use, the underlying engine is still Windows Installer and an MSI file. Getting to know something about that is always useful. In this case, the content of the ServiceInstall table and allowed values for StartName are relevant. Anyway, I don't believe that Network Service is the correct name for that account. Those actual account names (as opposed to the friendly names) need to be something like NT AUTHORITY\LocalService. Perhaps NT AUTHORITY\NetworkService is the actual name. Phil Wilson -Original Message- From: Chad Miles [mailto:chad.mi...@gmail.com] Sent: Thursday, January 22, 2009 7:51 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems installing a windows service Have you run depends/reflector on your file to see if your missing any dependencies by chance? On Thu, Jan 22, 2009 at 9:48 AM, Thomas Due thomas@scanvaegt.dk wrote: I am currently experimenting with WiX to see if it is something we can use for our next generation software. My immediate thought was to simply build the complete installation from ground-up in small steps. This have worked fine so far, now I have run into a problem though, when I try to install a Windows Service I get this error: Service My Name Server (NSEngine) could not be installed. Verify that you have sufficient privileges to install system services. The problem is, I DO have sufficient privileges to install services, at least I haven't had any problems using the InstallUtil. The services have been created with VS2008 and .NET 3.5 (C#). If I use InstallUtil, they install fine, but I thought I would try doing it the right way. Here is the code I am currently using: DirectoryRef Id=INSTALLDIR Component Id=NameServiceComponent Guid=53398A87-395B-4DA8-A475-04684FE5DE20 File Id=NSEngine Name=$(var.NSEngine.TargetFileName) Source=$(var.NSEngine.TargetPath) DiskId=1 KeyPath=yes / ServiceInstall Id=NSEngineInstall DisplayName=My Name Server Name=NSEngine ErrorControl=normal Start=auto
Re: [WiX-users] Problems installing a windows service
It was the account name. I changed it to NT AUTHORITY\NetworkService and presto: It installed without a hitch. Now I only have a single question (at the moment): How do I set specific permissions to a specific account on the installdir? I need to set write permissions for NT AUTHORITY\NetworkService on the installation directory. Thanks, Thomas Due -Original Message- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: 23. januar 2009 01:54 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems installing a windows service To add to this: 1) A dependent assembly that you're installing in the GAC will be an issue because they're not available until the end of the install after StartServices. 2) What would you do in other circumstances if your service crashed or would not start? This is no different really. If it doesn't start at all it's usually a dependency issue, an account issue, or a catastrophic crash as soon as it starts. Trace or debug entries are something I can't live without these days. It's not that I'm a poor developer, honest, but with TraceListeners it's so easy to put trace information that it's bad practice NOT to add Trace.WriteLine that goes to a text file somewhere. 3) Regardless of what tool you use, the underlying engine is still Windows Installer and an MSI file. Getting to know something about that is always useful. In this case, the content of the ServiceInstall table and allowed values for StartName are relevant. Anyway, I don't believe that Network Service is the correct name for that account. Those actual account names (as opposed to the friendly names) need to be something like NT AUTHORITY\LocalService. Perhaps NT AUTHORITY\NetworkService is the actual name. Phil Wilson -Original Message- From: Chad Miles [mailto:chad.mi...@gmail.com] Sent: Thursday, January 22, 2009 7:51 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems installing a windows service Have you run depends/reflector on your file to see if your missing any dependencies by chance? On Thu, Jan 22, 2009 at 9:48 AM, Thomas Due thomas@scanvaegt.dk wrote: I am currently experimenting with WiX to see if it is something we can use for our next generation software. My immediate thought was to simply build the complete installation from ground-up in small steps. This have worked fine so far, now I have run into a problem though, when I try to install a Windows Service I get this error: Service My Name Server (NSEngine) could not be installed. Verify that you have sufficient privileges to install system services. The problem is, I DO have sufficient privileges to install services, at least I haven't had any problems using the InstallUtil. The services have been created with VS2008 and .NET 3.5 (C#). If I use InstallUtil, they install fine, but I thought I would try doing it the right way. Here is the code I am currently using: DirectoryRef Id=INSTALLDIR Component Id=NameServiceComponent Guid=53398A87-395B-4DA8-A475-04684FE5DE20 File Id=NSEngine Name=$(var.NSEngine.TargetFileName) Source=$(var.NSEngine.TargetPath) DiskId=1 KeyPath=yes / ServiceInstall Id=NSEngineInstall DisplayName=My Name Server Name=NSEngine ErrorControl=normal Start=auto Type=ownProcess Account=Network Service Vital=yes Interactive=no/ ServiceControl Id=NSEngineControl Name=NSEngine Start=install Stop=both Remove=uninstall / /Component /DirectoryRef Feature Id=MainFeature Title=Main Feature Level=1 ComponentRef Id=NameServiceComponent/ /Feature What I am doing wrong? TYI Thomas Due -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Chad E. Miles Software Engineer, Development Interactive Intelligence, Inc. chad.mi...@inin.com 317.715.8280 Office/Fax -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list
[WiX-users] Problems installing a windows service
I am currently experimenting with WiX to see if it is something we can use for our next generation software. My immediate thought was to simply build the complete installation from ground-up in small steps. This have worked fine so far, now I have run into a problem though, when I try to install a Windows Service I get this error: Service My Name Server (NSEngine) could not be installed. Verify that you have sufficient privileges to install system services. The problem is, I DO have sufficient privileges to install services, at least I haven't had any problems using the InstallUtil. The services have been created with VS2008 and .NET 3.5 (C#). If I use InstallUtil, they install fine, but I thought I would try doing it the right way. Here is the code I am currently using: DirectoryRef Id=INSTALLDIR Component Id=NameServiceComponent Guid=53398A87-395B-4DA8-A475-04684FE5DE20 File Id=NSEngine Name=$(var.NSEngine.TargetFileName) Source=$(var.NSEngine.TargetPath) DiskId=1 KeyPath=yes / ServiceInstall Id=NSEngineInstall DisplayName=My Name Server Name=NSEngine ErrorControl=normal Start=auto Type=ownProcess Account=Network Service Vital=yes Interactive=no/ ServiceControl Id=NSEngineControl Name=NSEngine Start=install Stop=both Remove=uninstall / /Component /DirectoryRef Feature Id=MainFeature Title=Main Feature Level=1 ComponentRef Id=NameServiceComponent/ /Feature What I am doing wrong? TYI Thomas Due -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
