Re: [WiX-users] Uninstall previous version with new version
Product\@Id = ProductCode property Product\@Version = ProductVersion property Correct. I believe both of these are documented in the CHM file. If not, please raise a bug. From: mri...@realtyim.com To: wix-users@lists.sourceforge.net Date: Fri, 20 Sep 2013 17:12:09 + Subject: Re: [WiX-users] Uninstall previous version with new version Thank you Blair. In my wxs file I see a Product element with an Id attribute - I found a webpage that says that this is the ProductCode. Can you confirm? That appears to be static in my case so I suspect the problem is with the version number which is also static at 1.0.0.0 - I will need to find out how to update that within TFS. Cheers! .Mark -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: Thursday, September 19, 2013 10:43 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Uninstall previous version with new version They have to be minor upgrades of each other (i.e. share the same ProductCode). The three downsides that immediately come to mind are that you cannot double-click version 2.msi and succeed at installing it (you have to supply a special command-line), if the version 2.msi isn't identically named the same as version 1 was then you can't ever even install it, and if you (re)move any components or otherwise break any component rules you orphan all of your resources and leave the entire product advertised and not installed without any of the resources actually removed (which can be fixed by immediately repairing, but that is very counter-intuitive). Also the upgrades do not use the Upgrade table (which is ignored during minor upgrades). From: mri...@realtyim.com To: wix-users@lists.sourceforge.net Date: Fri, 20 Sep 2013 01:03:36 + Subject: [WiX-users] Uninstall previous version with new version I remember using this feature from the past. I would have an .msi that is version 1 and another being version 2. I install version 1 on my machine and then I am able to right click the version 2 .msi and select uninstall and have it succeed. Does anyone know how to do this? It's quite convenient. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.c lktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Execution order issue
If I were your custom action I would log everything I could to figure it out. From: kpet...@otaksoft.com To: wix-users@lists.sourceforge.net Date: Fri, 20 Sep 2013 19:47:45 -0700 Subject: Re: [WiX-users] Execution order issue Thanks for asking the question again (why not after InstallFiles) - in my mind I had tried that and it failed. So I tried it again and got: Action ended 14:36:14: InstallFiles. Return value 1. MSI (s) (E8:74) [14:36:14:935]: Doing action: CA_CopyMasterIni MSI (s) (E8:74) [14:36:14:935]: Note: 1: 2205 2: 3: ActionText Action 14:36:14: CA_CopyMasterIni. Action start 14:36:14: CA_CopyMasterIni. MSI (s) (E8:80) [14:36:14:995]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI6D25.tmp, Entrypoint: CopyMasterInifile Action ended 14:36:15: CA_CopyMasterIni. Return value 1. All seems to look well - but CA_CopyMasterIni did not succeed as the file that ended up in the destination directory was the one installed by the MSI and not the external one copied by the CA. After I saw the log, I decided to rename the file installed by the MSI in my WIX code to see if overwriting was the failure point. It does appear so, for now I had both files in the dest. dir: the external one copied there by the CA and the installed one by a different name. So my question becomes: Is there something I need to be aware of here? I am using CopyFile from the Win API with FailIfExists set to False, so it should overwrite an existing file. Does MSIExec keep installed files locked while it's running? Thanks again, Kai On Fri, 20 Sep 2013 07:52:26 -0700, Phil Wilson wrote: Indeed, the original post seems to say that the issue is that InstallFiles is after the copy CA. It's not clear why the CA cannot be just moved to after InstallFiles. Phil Wilson On Thu, Sep 19, 2013 at 1:35 PM, Blair Murri os...@live.com wrote: Now that your CA is deferred, what happens if you schedule it right after InstallFiles? Remember, verbose logs tell a lot about what is and/or isn't happening. From: kpet...@otaksoft.com To: wix-users@lists.sourceforge.net Date: Thu, 19 Sep 2013 13:15:38 -0700 Subject: Re: [WiX-users] Execution order issue Phil, modified it accordingly (I think..) and this places CA_CopyMasterIni immediately BEFORE InstallFiles in the InstallExecute Sequence table !-- this CA copies a template provided by customer's IT from COMMON_APPDATA to final dest. -- CustomAction Id=CA_CopyMasterIni BinaryKey=BIN_InstallHelperDLL DllEntry=CopyMasterInifile Execute=deferred Return=check HideTarget=no Impersonate=yes / !-- schedule custom actions -- InstallExecuteSequence Custom Action=CA_BackupGlobalIni After=InstallInitialize / Custom Action=CA_RestoreGlobalIni After=RemoveExistingProducts / Custom Action=CA_CopyMasterIniBefore=InstallFiles / /InstallExecuteSequence How can I push it AFTER InstallFiles AND have it work? Surely there must be a way..? PS: Thanks for the warning re. repair/uninstall - had not thought abut that! Thanks for your help so far, Kai On Thu, 19 Sep 2013 07:20:46 -0700, Phil Wilson wrote: Well that means that you put it between InstallInitialize and InstallFinalize but before InstallFiles, if that's where it's supposed to be. Did you try that? It's not a safe design without some extra details. When InstallFiles copies your file, you need to be sure it won't replace the one you already copied - what do have to prevent that from happening? You may also need a condition on your copy to prevent it from happening during a repair or uninstall Phil Wilson On Wed, Sep 18, 2013 at 5:48 PM, Kai Peters kpet...@otaksoft.com wrote: My mistake for not specifying what else I had tried: When i switched to 'deferred' LIGHT complained: error LGHT0204 : ICE77: CA_CopyMasterIni is a in-script custom action. It must be sequenced in between the InstallInitialize action and the InstallFinalize action in the InstallExecuteSequence table I also found a piece of advice stating that in this case one should schedule in InstallUISequence - but that just gave errors during MSI execution On Wed, 18 Sep 2013 11:07:05 -0700, Phil Wilson wrote: Your copy custom action is immediate - that means it will always happen before any files are actually copied. If you need it to run after InstallFiles has physically copied files it should be marked deferred. Phil Wilson On Tue, Sep 17, 2013 at 10:45 PM, Kai Peters kpet...@otaksoft.com wrote: Hi all, hopefully my last newbie issue for some time (all previous issues have been resolved thanks to the great help from this list - thanks again!): I deploy a CA CA_CopyMasterIni to copy a configuration file template from location A to
[WiX-users] [SPAM] Re: Bootstrapper errors
@Rob, Why can't a new bundle handle this? Is there a GUID clash or? (We're seeing this on a dirty Win 8 VM) Thanks, -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-errors-tp7582859p7589364.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] One-Time Reboot in Burn Executable
All, I have a number of .msi's that are built using the WiX toolset, and they are also made available as a single .exe package using WiX Burn. A number of those individual installations check for the presence of the Window File Based Write Filter, and if found will prompt for a reboot and then continue installing after the reboot. However for the Burn package this is not working as I'd hoped - which is of course that I wouldn't have to do anything and a combination of luck and magic would make it all go away. What I therefore want is for a check to be performed at the beginning of the Burn .exe for the presence of the FBWF and perform a reboot, and following the reboot the .exe continues to install, but I'm not sure if this is even possible because it's an .exe rather than an .msi. Any clues? If so then perhaps you also know how to make the thing reboot once all of the MSIs have installed so that I can bring the system back up with the FBWF re-enabled. Thanks Adam -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [SPAM] Re: Execution order issue
You might find catest.dll a helpful tool in this situation. http://blogs.msdn.com/b/astebner/archive/2005/03/07/388739.aspx?Redirected=true -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Execution-order-issue-tp7588998p7589366.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [SPAM] Re: [SPAM] Re: Bootstrapper errors
Handle what? On Wed, Oct 2, 2013 at 2:41 AM, rowbot james.row...@microfocus.com wrote: @Rob, Why can't a new bundle handle this? Is there a GUID clash or? (We're seeing this on a dirty Win 8 VM) Thanks, -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-errors-tp7582859p7589364.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [SPAM] Re: Burn MBA - how to debug strutil.cpp line 277 Assert
This is a question better asked on wix-devs (to cover the debugging aspects). The assert is telling you that something is incorrectly passing NULL to a dutil string function. It *may* be okay but it could also indicate a huge problem. Try attaching your debugger with both native and managed code debuggers checked and then clicking Debug should cause the debugger to drop into Burn code to look at the issue. Can follow up more on wix-devs. On Fri, Sep 27, 2013 at 7:41 AM, Phill Hogland phogl...@rimage.com wrote: Originally I created a bundle (with Wix 3.7 and the WixExtendedBA) which I later converted to use Wix 3.8 and the BAFunctions. I also compiled a debug version of Wix 3.8 which my project links too. By setting a break point in the BAFunction.DLL I can step into the Wix 3.8 burn engine code and see what is going on. Now I have decided to replace the BA/BAFunction.dll with a MBA. Using the Wix 3.7 installer MBA as an example I created my MBA application. Now that I have hooked it into the bundle I am getting an Assert in strutil.cpp StrAllocString() on line 277 Assert(ppwz wzSource); While I can launch a debug build and step through my MBA, I did not find anyway to step from there into the Wix code so that I can determine why this assert is happening. If I click on Ignore in the Assert message, the bundle runs to completion and there are no entries in the verbose log that would indicate any problem with any string. If I click on Debug in the Assert message the application terminates. When stepping through the MBA the Assert pops up in MyClass::Run() when the code to 'create the UI' is executed. Specifically at MyMBA.View = new RootView(viewModel); I am still trying to learn the basics of MVVM so any pointers on how to debug this situation would be appreciated. Thanks! (I am using VS2010 on both Win7_x64 and Win8_x64). -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-MBA-how-to-debug-strutil-cpp-line-277-Assert-tp7589279.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] File Associations with external programs
Ideally a DLL custom action would be added. It would be great if that were contributed back so that everyone could benefit. One other concern: the blank guid on your Plugin component means that this file association, including the Open verb registration, would not be removed when the product/plugin was uninstalled. You should create and preserve a GUID for that component. From: penn...@gmail.com Date: Sat, 21 Sep 2013 11:15:11 +0800 To: wix-users@lists.sourceforge.net Subject: [WiX-users] File Associations with external programs Hi, I'm developing a plugin for XMetaL(an document editor), and set XMetaL the default program for a new file type, let's say, myxml. I think Wix Progid element can help dealing with all of this. My code is as below: Component Id=Plugin Guid= ProgId Id='Authoring.myxml' Description='my File Type' Extension Id='myxml' ContentType='text/xml' Verb Id='open' Command='Open' TargetProperty='XMETALAUTHOREXE' Argument='%1' / /Extension /ProgId CreateFolder / /Component Here is my scenario: First I create a file called abc.myxml, the current icon of this file is blank page. Then I install my plugin, it sets XMetaL as the deafult program of myxml files. After the full installation, the icon of myxml files should change to XMetaL's icon. When I double click abc.myxml, it will be opened by XMetaL. What troubles me is that after installing the plugin, the icon of myxml files won't change. When I try to open abc.myxml, it raises XMetaL, which means, file associations take effect. I found this on MSDN: Note Any time a file association is created or changed, notify the system that a change has been made by calling SHChangeNotify, specifying the SHCNE_ASSOCCHANGED event. If this is not done, the Shell might not recognize any changes made until the system restarts. I write a tiny c++ program to send SHChangeNotify and it works. But does anyone know how to generate this in Wix natively? This is my first time asking questions in mail threads. Correct me if I made something wrong, thanks in advance. -- Best Regards, Peng Lv Nanjing University, Computer Science Technology Mobile:86-186-2643-8113 Email: penn...@gmail.com Website: http://www.rebornix.com -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cannot patch correctly in 3.6
This has been discussed in this mail list and in several bugs before. The issue is that the documented Purely Wix method requires that the builds be done from different paths because the files to be compared have to have been linked into their respective MSIs from different locations. Builds that reuse the same output directories do not conform to that documentation (the example in the documentation builds each version in its own set of directories). The current best idea for your situation is to use Melt as described by Bob here: http://www.joyofsetup.com/2013/07/16/easy-pure-wix-patching-with-melt/. I haven't verified which versions of the toolset work this way yet, so please let us know if it works with your build. The garbage at the front of your WIXMST files is a cabinet containing the binaries coming from bound WIXLIBS (such as the custom actions obtained from WixExtensions) and is expected to be in that WIXMST (they come from the associated WIXPDBs). In fact, if that was larger (contained all of the files in your MSI) you wouldn't have the issue (since the files would be compared from that cabinet instead of from your build output directories). From: steven.par...@nikon.com To: wix-users@lists.sourceforge.net Date: Mon, 23 Sep 2013 10:32:52 + Subject: [WiX-users] Cannot patch correctly in 3.6 Hi all, We’ve had a “Purely Wix” patch build running daily for the last year or so with 3.5, it is setup exactly as stated in the documentation (http://wixtoolset.org/documentation/manual/v3/patching/wix_patching.html). However since upgrading to 3.6, the exact same method now just supplies us with an empty patch and the empty cab files message (much like http://sourceforge.net/p/wix/bugs/3244/?page=1 and http://wixtoolset.org/issues/3946/). The build process shown below has the released product wixpdb in PatchSourse and although they are in a different location to the new wixpdb files, in the file they reference to the same location (X:\output\install….) because this is where the install gets built to every time. If this is the cause of the issue, is there no easy way around this because otherwise this is going to require a major change to our entire build process. I have noted that at the top of the wixmst file from 3.6 there are lines and lines of garbage up to …..§Ê©sÜM€.\¸páÂ…‹ÿ ?xml version=1.0 encoding=utf-8?wixOutput type=Transform codepage=1252 which are not there in 3.5 but not sure if this is part of the problem, we’ve tried cleaning up the file and removing those lines but doesn’t make any difference. Current build process: Set PatchSourse=X:\Install\PRODUCTNAME\Patch\ Set OutputFolder=X:\Output\install\PRODUCTNAMEPatch\ Set NewInstall=X:\Output\install\PRODUCTNAME\ Set WIXDIR=c:\Program Files (x86)\WiX Toolset v3.6\bin %WIXDIR%\torch.exe -p -xi %PatchSourse%PRODUCTNAMEx32.wixpdb %NewInstall%x86\PRODUCTNAMEx32.wixpdb -out %OutputFolder%\PRODUCTNAMEpatch32.wixmst %WIXDIR%\candle.exe %PatchSourse%Patch32.wxs %WIXDIR%\light.exe %PatchSourse%Patch32.wixobj %WIXDIR%\pyro.exe %PatchSourse%Patch32.wixmsp -out %OutputFolder%PRODUCTNAMEPatch32.msp -t PATCH %OutputFolder%\PRODUCTNAMEpatch32.wixmst %WIXDIR%\torch.exe -p -xi %PatchSourse%PRODUCTNAMEx64.wixpdb %NewInstall%x64\PRODUCTNAMEx64.wixpdb -out %OutputFolder%\PRODUCTNAMEpatch64.wixmst %WIXDIR%\candle.exe %PatchSourse%Patch64.wxs %WIXDIR%\light.exe %PatchSourse%Patch64.wixobj %WIXDIR%\pyro.exe %PatchSourse%Patch64.wixmsp -out %OutputFolder%PRODUCTNAMEPatch64.msp -t PATCH %OutputFolder%\PRODUCTNAMEpatch64.wixmst We temporarily gave up with that method and instead thought we would try the method described here (http://bryanpjohnston.com/2013/03/06/automated-patch-building-with-wix-and-visual-studio/) msiexec.exe /a C:\TempInstall\Release\x64\PRODUCTNAMEx64.msi /qb TARGETDIR=C:\TempInstall\Release\x64\Install msiexec.exe /a C:\TempInstall\Patch\x64\PRODUCTNAMEx64.msi /qb TARGETDIR=C:\TempInstall\Patch\x64\Install %WIXDIR%\torch.exe -v -p -xo -ax C:\TempInstall\Release\x64\Install\\ C:\TempInstall\Release\x64\Install\PRODUCTNAMEx64.msi -ax C:\TempInstall\Patch\x64\Install\\ C:\TempInstall\Patch\x64\Install\PRODUCTNAMEx64.msi -out %OutputFolder%\PRODUCTNAMEpatch64.wixmst This successfully built a patch file which could be applied to the original install. However the patch appeared to patch our x64 binaries to x86 binaries and the application was then unable to start. We are assuming that this is because the msi file also contains x86 dlls and an exe even in the x64 install. We tried removing the ComponentRefs from the PatchFamily in our Patch64.wxs file. However this seemed to be ignored and all the files were still being patched anyway. Any help at all on any of this would be gratefully received. Steve Sam -- LIMITED TIME SALE -
Re: [WiX-users] Need some help with upgrade support in first version of MSI
For the file that should never be upgraded, check out the NeverOverwrite attribute of the Component element. From: afor...@cmu.edu To: wix-users@lists.sourceforge.net Date: Tue, 24 Sep 2013 09:37:50 -0400 Subject: Re: [WiX-users] Need some help with upgrade support in first version of MSI 1) http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html My MajorUpgrade element looks like this: MajorUpgrade DowngradeErrorMessage=A more recent version of [ProductName] is already installed. Schedule=afterInstallInitialize / So presumably your Product element has a Version attribute that would be something like 1.0.0. Say this is installed on client machines, and you need to upgrade them. You would then increment the Version to something like 1.0.1 (or whatever it appropriate), then when clients try to install the new msi package, it will detect that there is 1.0.0 installed already, remove it, and install 1.0.1. 2) Maybe this? http://stackoverflow.com/questions/488620/wix-major-upgrade If you've built your own WiX installer, you're not much more of a newbie than I am. :-) -Original Message- From: nkshirsagar [mailto:nkshirsa...@gmail.com] Sent: Tuesday, September 24, 2013 09:25 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Need some help with upgrade support in first version of MSI can you provide any details? I'm a wix newbie. I'm using wix 3.7. What do I need to 1) Make sure my msi can support future upgrades 2) When the next msi installs, one of the files must not be changed (its a data file, I need to keep it as it is.. ) please help ! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Re-Need-some-help-with-upgrade-support-in-first-version-of-MSI-tp7589171p7589172.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [SPAM] Re: Burn installer upgrade does not work
A couple other approaches to build versions (that can also set build versions into the binaries you build) are included in products like these: MSBuild Extension Pack http://www.msbuildextensionpack.com/ MSBuild Community Tasks https://github.com/loresoft/msbuildtasks From: r...@robmensching.com Date: Wed, 25 Sep 2013 08:04:06 -0700 To: wix-users@lists.sourceforge.net Subject: [WiX-users] [SPAM] Re: Burn installer upgrade does not work WiX toolset's versioning is controlled by this: tools\WixBuild.Version.targets On Wed, Sep 25, 2013 at 7:14 AM, Phill Hogland phogl...@rimage.com wrote: I'm sure there are many different ways to go at this. I was originally using Wix 3.7 when I was using the WixExtededBA and the bal:autoversion. If I had stayed with Wix 3.7 I would have used the source code at http://wixextba.codeplex.com/ to create a wix extension and modify the auto version algorytum as I needed. I had started down that path an extension dll working for Wix 3.7. However for other reasons I switched my project to use Wix 3.8, at which point for some reason I could not get the wix extension dll to compile. I never figured out what I was doing wrong, but I still think that creating a wix extension DLL is the better approach. I needed to figure out how to do MSBUILD tasks for another reason and as I was doing that I also used that approach to tackle the auto version issue. It is too involved to present a lot of details, and my legal department is still debating whether they approve of my participation in posting code. In VS2010 (for me) select the project and then select 'Unload Project' in the context menu. Then select edit the project file. Then the easiest way to create a MSBUILD task is to create an in-line task. http://msdn.microsoft.com/en-us/library/dd723643.aspx The drawback to creating an in-line task is that you do not get feedback on compile errors until run time. Since I am also learning C# (from a C++ background) I switched to creating an in-process Task (dll). http://msdn.microsoft.com/en-us/library/t9883dzc.aspx When running an in-line task if there is an error, a verbose msbuild log provides the path to the C# file which MSBuild generated. So I used this detail going back and forth between in-line and DLL as needed to figure out how to prototype different variables. Regarding the version algorythm that I implemented: 1) I created a master text file which originally had only the version in it x.x.x.x. Eventually I decided to add several control flags to the data. (i.e. major.minor.build(x).revision.f1.f2... ). Major, minor, and revision are static values which I set manually, so the MSBuild tasks only increment the build value and set the flags. 2) In the C# library project (for the Task DLL) I created a class derived from ITask which: a) reads in the master text file b) Splits (or tokenized) the string to a string array. c) read the two flags were f1 is my Bundle flag and f2 (etc) is a flag for each primary MSI package. d) If each flag is zero then increment the build value, and set all flags to 1. e) Save the values and flags back to the master text file. f) Format a string with the XML contents of a wxi file and insert the version. Write this wxi file out to the project folder. So the above Task is called in Target BeforeBuild in each project (MSI or Bundle). Then in Target AfterBuild I call another class derived from ITask in the MSBuild DLL which resets the specific flag. If there is an error in the build of the MSI that project will never call Target AfterBuild so if I get to AfterBuild I assume that the build succeeded. If this is the MSI project I clear the MSI flag. If the Bundle project I clear the Bundle flag in the master text file. I'm sure there are other ways to do this and I still think that the wix extension might be a better choice. But this is what I implemented for now. Some folks have mentioned that they increment revision to track changes in the Bundle. We use the Revision value for tracking changes to the deployment media, separate from the setup package, so I could not take that approach. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-installer-upgrade-does-not-work-tp7589150p7589200.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___
Re: [WiX-users] added performance counters are not registered in patch
Do you have any PatchFamily declared? What resources/components are included? From: hinrich@kofax.com To: wix-users@lists.sourceforge.net Date: Fri, 27 Sep 2013 08:37:30 + Subject: [WiX-users] added performance counters are not registered in patch we are using: util:PerformanceCounter Name=theName Help=HELP! Type=numberOfItems32/ to add new performance counters in an existing category. we have a patch that has been created for an older version using WiX 3.5. The performance counters are being added - no problem. In another version we have WiX 3.7 - performance counters are not added. So I've created some log output from both version and saw the following: in the WiX 3.5 installer I see the following: MSI (s) (24:04) [09:52:44:750]: Executing op: RegAddValue(Name=Counter Names,Value=[~]blabla [~]new performance counter[~],) WriteRegistryValues: Key: \SYSTEM\CurrentControlSet\Services\Server Scheduler\Performance, Name: Counter Names, Value: [~]blabla [~]new performance counters[~] in the 3.7 wix installer I only see the first line: MSI (s) (94:D0) [11:26:20:632]: Executing op: RegAddValue(Name=Counter Names,Value=[~]blabla[~]new performance counter [~],) but not the second log entry. It looks like the registry key is not written - makes sense since performance counters are mostly registry entries. Is it possible that this is a difference between WiX 3.5 and WiX 3.7 - or is it a problem in the WiX util:PerformanceCounter? Thanks, Hinrich Hinrich Aue Sr. SW Engineer Kofax Development GmbH Wentzinger Strasse 19 79106 Freiburg Germany Tel: +49 761 452 69 57234 Fax: +49 761 452 69 58734 hinrich@kofax.com NEWS FLASH: Kofax Acquires Kapow Software http://www.kofax.com/news/press-releases/press-release.php?pr=kofax-acquires-kapow-technologies-a-leading-data-integration-software-provider This communication is only for the use of the intended recipient. It may contain confidential or proprietary information. If you are not the intended recipient or have received this communication in error, please notify the sender via phone and destroy this communication immediately. Kofax Development GmbH Sitz der Gesellschaft: Freiburg i. Brg. Registergericht: Amtsgericht Freiburg i.Br. Registernummer: HRB 7007 Gesch?ftsf?hrer: Bradford Weller, Christian Hefner, Daniel Geiger -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [SPAM] Re: Bootstrapper errors
2013/10/2 rowbot james.row...@microfocus.com: @Rob, Why can't a new bundle handle this? Is there a GUID clash or? (We're seeing this on a dirty Win 8 VM) Thanks, You are replying to a message from January and posting no context at all. I hadn't joined the mailing list yet, so I don't even have that message. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] changes to support upgrades ? help !
Why can't you use the current CopyFile element in Wix instead of creating your own custom action? Use a ComponentSearch to find the old file's location for upgrade purposes. Date: Fri, 27 Sep 2013 03:15:27 -0700 From: nkshirsa...@gmail.com To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] changes to support upgrades ? help ! thanks for the affirmation. I will try this out.. but where should I schedule the custom action to copy? (I'm assuming it will be a copyfile custom action.. am i right? Here's my wxs file in case you want to see where I'm scheduling the upgrade in majorupgrade, and where my custom actions are being scheduled.. please let me know where i should schedule this copyfile.. ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=* Name=SolidFire Hardware Provider Language=1033 Version=1.0.0.0 Manufacturer=SolidFire UpgradeCode=0c60967f-f184-4b8b-a96a-b1caa4a8879e Package Id=* InstallerVersion=405 Compressed=yes InstallScope=perMachine / Condition Message= You need to be an administrator to install this product. Privileged /Condition MajorUpgrade DowngradeErrorMessage=A newer version of [ProductName] is already installed. Schedule=afterInstallInitialize/ MediaTemplate EmbedCab='yes'/ PropertyRef Id=NETFRAMEWORK35/ Condition Message =This application installs only on Windows Server 2012 and Windows Server 2008 R2 /Condition Condition Message=This application requires .NET Framework 3.5. Please install the .NET Framework then run this installer again. /Condition Feature Id=ProductFeature Title=InstallProvider Level=1 ComponentGroupRef Id=ProductComponents / /Feature Feature Id=VCRedistcrt Title=Visual C++ Runtime AllowAdvertise=no Display=hidden Level=1 MergeRef Id=VCRedistcrt/ /Feature Feature Id=VCRedist Title=Visual C++ Runtime AllowAdvertise=no Display=hidden Level=1 MergeRef Id=VCRedistatl/ /Feature UI Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchApplicationWIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and NOT Installed/Publish /UI Property Id=WIXUI_INSTALLDIR Value=INSTALLFOLDER /Property Property Id=WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT Value=Launch Config Utility / Property Id=WixShellExecTarget Value=[#configutility] / CustomAction Id=LaunchApplication BinaryKey=WixCA DllEntry=WixShellExec Impersonate=yes / UIRef Id=WixUI_InstallDir/ InstallExecuteSequence Custom Action=RunInstallScript After=InstallFiles NOT Installed/Custom /InstallExecuteSequence InstallExecuteSequence Custom Action='BeforeUninstall' Before='RemoveFiles'Installed AND (NOT REINSTALL)/Custom /InstallExecuteSequence CustomAction Id=RunInstallScript ExeCommand=cmd /c install-solidfireprovider.cmd install.log Directory=INSTALLFOLDER Execute=deferred Return=ignore/ CustomAction Id=BeforeUninstall ExeCommand=cmd /c uninstall-solidfireprovider.cmd install.log Directory=INSTALLFOLDER Execute=deferred Return=ignore/ /Product Fragment DirectoryRef Id=TARGETDIR Merge Id=VCRedistatl SourceFile=$(env.CommonProgramFiles)\Merge Modules\Microsoft_VC90_ATL_x86_x64.msm DiskId=1 Language=0/ /DirectoryRef /Fragment Fragment DirectoryRef Id=TARGETDIR Merge Id=VCRedistcrt SourceFile=$(env.CommonProgramFiles)\Merge Modules\Microsoft_VC90_CRT_x86_x64.msm DiskId=1 Language=0/ /DirectoryRef /Fragment Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFiles64Folder Directory Id=INSTALLFOLDER Name=SolidFireVSS / /Directory /Directory /Fragment Fragment ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER Component Id=ProductComponent File Id=restinterfacedll.dll Source=..\x64\$(var.build)\RESTInterfacelib.dll/File /Component Component Id=vssdll File Id=vsssolidfireprovider.dll Source=..\x64\$(var.build)\vsssolidfireprovider.dll /File /Component Component Id=installscript File Id=installscript Source=install-solidfireprovider.cmd/File /Component Component Id=uninstallscript File Id=uninstallscript Source=uninstall-solidfireprovider.cmd/File /Component Component Id=registerprovider File Id=registerprovider Source=register_app.vbs/File /Component Component Id=vshadow File Id=vshadow Source=vshadow.exe/File /Component Component Id=clusterinfo File Id=clusterinfo Source=clusterinfo.bin/File /Component Component
Re: [WiX-users] System.OutOfMemoryException
The .pdbs for Wix 3.6 RTM are in the wix36-pdbs.zip file on this page: http://wix.codeplex.com/releases/view/93929 Date: Mon, 30 Sep 2013 10:34:24 +0530 From: ravishankar.krishnasw...@idsnext.com To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] System.OutOfMemoryException Hi Rob, Am compiling using VS 2008 and its not creating any *.pdb file either in debug or Release folder. Please let me know if you need any specific information. Thanks and Regards Ravi Shankar On 9/28/2013 1:12 AM, Rob Mensching wrote: Try grabbing the .pdbs for that build, put them next to the executable and see if you get line numbers for the exception. Then provide the full callstack of the error to help diagnose the issue. On Fri, Sep 27, 2013 at 5:38 AM, Ravishankar ravishankar.krishnasw...@idsnext.com wrote: Hi, Am trying to build a msi and getting the error . candle.exe(0,0): error CNDL0001: Exception of type 'System.OutOfMemoryException' was thrown. Please find below my system configurations.. a. XP sp3 b. 4 gb RAM c. 21 GB space in C: drive d. 88 GB space in D: drive e. VS 2008 with .Net Framework 3.5 + sp1 f. WiX 3.6 g. Installation files are around 600 mb and 6100 files(3500 dll's) h. Virtual Memory is 6100 mb I had earlier built a instaler with 167 mb(800 files) and the msi is working perfectly Kindly let me know if any other environment details are required. Thanks and Regards Ravi Shankar -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to replace action on next button
This is described in the CHM, in the online documentation, and in the tutorial. From: dusan.pla...@avitech-ag.com To: wix-users@lists.sourceforge.net Date: Mon, 30 Sep 2013 16:08:30 +0200 Subject: [WiX-users] How to replace action on next button Hi there, I am using mondoUI, and I customized CustomizeDlg. Now I want my customized dialog to show right after Welcome Dialog. So I did it like in tutorial: Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=CustomCustomizeDlg1/Publish Publish Dialog=CustomCustomizeDlg Control=Back Event=NewDialog Value=WelcomeDlg 1/Publish Publish Dialog=CustomCustomizeDlg Control=Next Event=NewDialog Value=VerifyReadyDlg 1/Publish Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog Value=CustomCustomizeDlg 1/Publish Problem is that it is not working. When I click on next button at WelcomeDlg, the window with License Agreement shows up. I looked at msi DB with orca and I found that there are actually tree rows for welcome dialog with next control and NewDialog event: CustomCustomizeDlg 1 1 LicenseAgreementDlg NOT Installed1 VerifyReadyDlg Installed AND PATCH 1 And all of them have order = 1 But I want my CustomCustomizeDlg to show up and not LicenseAgreement. is there any way to accomplish this? Ok I am aware that I can copy the WelcomeDialog code and change it there. but do I need to do it? Thanks -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Quick question about WiXCA - CAQuietExec
Thanks, at first it did not seem to work as the calling app did have failures and they did not cause the install to fail, but then we had another error that did fail the install. So we figured that some returns were not a complete failure and therefore the return did not cause an install failure and some are. So it seems to work as expected. From: Blair Murri-3 [via Windows Installer XML (WiX) toolset] [mailto:ml-node+s687559n7589379...@n2.nabble.com] Sent: Wednesday, October 02, 2013 10:49 AM To: Tim Mayert Subject: Re: Quick question about WiXCA - CAQuietExec Any text written by the app (both stdout and stderr) is written to the log, and any non-zero exit code is interpreted as a failure causing CAQuietExec to also return a failure. Date: Tue, 24 Sep 2013 10:45:53 -0700 From: [hidden email]/user/SendEmail.jtp?type=nodenode=7589379i=0 To: [hidden email]/user/SendEmail.jtp?type=nodenode=7589379i=1 Subject: [WiX-users] Quick question about WiXCA - CAQuietExec We have an app that when runs produces a quick Dos Window and then goes away. So we are using the WiXCA - CAQuietExec custom action to call the app in quite mode. This work great, but my question is if the App fails and I have the WiXCA custom action set to Return the error code will it return the failure of the app that CAQuietExec triggered or will it only return an error return code if the WiXCA returned a failure and ignore what comes from the triggered app? I just have to confirm that if the app fails that the failure is returned to the CA instead of just returning to no where and as long as the quiet app triggered the app successfully then no failure is returned to the install. Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Quick-question-about-WiXCA-CAQuietExec-tp7589181.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7589379i=2 https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7589379i=3 https://lists.sourceforge.net/lists/listinfo/wix-users If you reply to this email, your message will be added to the discussion below: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Quick-question-about-WiXCA-CAQuietExec-tp7589181p7589379.html To unsubscribe from Quick question about WiXCA - CAQuietExec, click herehttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7589181code=VGltTWF5ZXJ0QHNtYXJ0dGVjaC5jb218NzU4OTE4MXwtMTcxMzc3MTUwNA==. NAMLhttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Quick-question-about-WiXCA-CAQuietExec-tp7589181p7589383.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to handle a context menu component on install/upgrade?
It is possible to use Restart Manager to avoid the reboot (it will stop explorer.exe and restart it during the upgrade) if no other users are logged in. From: nicolas.alva...@gmail.com Date: Mon, 30 Sep 2013 17:57:04 -0300 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to handle a context menu component on install/upgrade? 2013/9/30 victorwhiskey victorhwhis...@yahoo.com: Hi, I'm trying to install/upgrade a component that is a context menu handler. I'm trying to see how others do this, especially on upgrade. When upgrading the component is installed and explorer is using it. Is it possible to do a upgrade without restarting explorer and without rebooting the machine? It's impossible to avoid restarting explorer. If explorer has the DLL loaded, the file is locked and you can't replace it. But I'm curious if it's possible to use Restart Manager to restart explorer alone instead of rebooting the whole machine... -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Practical use of wixlibs
See http://blogs.msdn.com/b/heaths/archive/2009/12/21/about-shared-components.aspx From: nicolas.alva...@gmail.com Date: Tue, 1 Oct 2013 00:51:36 -0300 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Practical use of wixlibs I can't find any documentation on best-practices when creating either merge modules or wixlibs, only procedure documentation on how to create them. Let's say I create a wixlib (or msm) with multiple components that make up a large C++ library. Someone making an application with that library can then use the wixlib and only write installation code for his own app files, instead of having to also define the installation of the library. But where would the library be installed? Would the wixlib need to have a Directory under (say) Common Files where the library would go? Or can the wixlib provide a way for the application wxs to decide where the library would be installed? But then there's a problem: two applications importing the same wixlib could install the same components (with same GUID) in different directories. As far as I know that means only the first one would get installed, the second would see the component is already installed (identified by GUID) and do nothing. Does anyone have experiences to share? -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Authoring a Major Minor upgrade in same package
Is it possible to make a single MSI/Bundle to handle both Major upgrades and Minor upgrade/updates? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Authoring-a-Major-Minor-upgrade-in-same-package-tp7589392.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Authoring a Major Minor upgrade in same package
2013/10/2 victorwhiskey victorhwhis...@yahoo.com: Is it possible to make a single MSI/Bundle to handle both Major upgrades and Minor upgrade/updates? A major upgrade changes the ProductCode, and works by uninstalling the existing version and installing the new msi. A minor upgrade doesn't change the ProductCode, and is installed on top of the existing version. It's obviously impossible for a .msi to both change and not change the ProductCode :) What *might* be possible is creating a bundle that contains both MSIs and somehow chooses which one to install. You can even save space by having both MSIs share an external cabinet file instead of embedding the cabinet in the MSI. But as usual, the big question is: why do you want to do that, or think you need to do that? It sounds really strange, and would cause problems if you manage to do it... -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Authoring a Major Minor upgrade in same package
I've never tried but in thinking it over, it's not possible. I have done MSI's that might install side by side or in place upgrade at runtime. This was done through manipulating the upgrade process at runtime. However an MSI that might be major or might be minor would either have to have the old ProductCode or a new ProductCode and that would have to be manipulated prior to invoking the MSI. Possibly via applying a transform. So maybe you could create a bundle experience that prompts the user and applies the MSI with or without a transform but it would be way beyond my current capabilities with Burn. From: victorwhiskey victorhwhis...@yahoo.com Sent: Wednesday, October 02, 2013 1:21 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Authoring a Major Minor upgrade in same package Is it possible to make a single MSI/Bundle to handle both Major upgrades and Minor upgrade/updates? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Authoring-a-Ma jor-Minor-upgrade-in-same-package-tp7589392.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Id / Guid - updated documentation, etc.
Components have two identities, a local one (used within the MSI, including in conditions and properties) and a global one (used when identifying a component from a different MSI or even from outside all MSIs). The local one is an identifier (alphanumeric string) and the global one is a GUID. Product and Package identities are always the ProductCode and PackageCode values, so those make sense being named @Id. If you are not tying to support Patching it is generally recommended to first try using a * for all guids (except UpgradeCode) required by WiX/Windows Installer itself, which will cause the WiX toolset to generate stable guids. The toolset will tell you (with a build time error message) when it can't generate that guid. If you don't supply the Component\@Guid value, it will default to * for you, so that is the usual recommendation. Fragment allows you to group resources that need to either be included in the MSI all together or not at all. A reference to any resource within a fragment causes the entire fragment to be linked into the final file by the Light tool. In general going through the CHM (or the online documentation of the same material, but I find the CHM more convenient to access) will give you most of the above information as well as answers to the rest of your raised questions. From: cker...@claremontcompanies.com To: wix-users@lists.sourceforge.net Date: Tue, 1 Oct 2013 18:50:15 + Subject: [WiX-users] Id / Guid - updated documentation, etc. Greetings, I am just now diving into Wix - watched a few videos and went through the tutorial. In the online tutorial, found here (http://wix.tramontana.co.hu/tutorial/getting-started/the-software-package) I realized I was getting mixed up with a few ambiguities (at least I my mind!) I'm hoping you can resolve for me - also, want to make quick recommendation, though I'm sure doing so would wreck previous development if it was implemented ... :) First off - recommendation? I'm using VS 2012. In the tutorial linked above, I see that all products and packages require a Guid. The Product and package uses the id attribute for this Guid. However, the component, uses a Guid attribute. This just threw me off a little. I'm sure adding a Guid attribute to the Product and Package for constancy would probably be an epic change, but I'm a glutton for consistency :) Take it for what it is. Second - I used VS2012 to create a new Wix project (see attached screenshot) which introduces two new elements that were not addressed in the tutorial. The fragment and componentGroup Would be nice to get an idea of the relationship which may be apparent to those already familiar with wix, but again, makes a beginner like myself a little confused. Lastly - what would be really cool would be to update the tutorial with the entire listing in a block, with hi-lites that identify the primary keys that tie sections together. In the online example, (for example), there is a package-directory reference with an Id of programfilesfolder, but everywhere else there is a reference to programmenudirectory - and it was difficult to ascertain whether that was a typo, a reserved name, or simply an id that Wix uses in the MSI and it doesn't need to be referenced anywhere else in the file. If the section names / ids are supposed to reference prior sections of the XML, hi-lites would really make that stand out and help the reader ascertain what are supposed to be FK references as opposed to predefined / reserved identifiers (so to speak). I'm really thankful to the team for creating Wix and want to learn it! So, thanks for making this available and I hope to be an active member of this discussion group. When I learn the ropes well enough, I plan on making a tutorial of my own to help me understand it better, and to benefit others who are, like me, noobs! Thanks! Chris ?xml version='1.0' encoding='windows-1252'? Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' Product Name='Foobar 1.0' Id='YOURGUID-86C7-4D14-AEC0-86416A69ABDE' UpgradeCode='YOURGUID-7349-453F-94F6-BCB5110BA4FD' Language='1033' Codepage='1252' Version='1.0.0' Manufacturer='Acme Ltd.' Package Id='*' Keywords='Installer' Description=Acme's Foobar 1.0 Installer Comments='Foobar is a registered trademark of Acme Ltd.' Manufacturer='Acme Ltd.' InstallerVersion='100' Languages='1033' Compressed='yes' SummaryCodepage='1252' / Media Id='1' Cabinet='Sample.cab' EmbedCab='yes' DiskPrompt='CD-ROM #1' / Property Id='DiskPrompt' Value=Acme's Foobar 1.0 Installation [1] / Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='Acme' Name='Acme' Directory Id='INSTALLDIR' Name='Foobar 1.0' Component Id='MainExecutable' Guid='YOURGUID-83F1-4F22-985B-FDB3C8ABD471' File Id='FoobarEXE' Name='FoobarAppl10.exe' DiskId='1' Source='FoobarAppl10.exe'
Re: [WiX-users] Authoring a Major Minor upgrade in same package
Thanks guys. I've only done installers with major upgrades, so I'm not too sure it that was possible. So what I'm doing now is keeping the ProductCode as * for each build I can install upgrade on top of the previous one. Is this a bad practice then? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Authoring-a-Major-Minor-upgrade-in-same-package-tp7589392p7589398.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Practical use of wixlibs
That's extremely enlightening. I thought having two components in different products with the same GUID but different installation directories would be a blatant break of component rules and would just not work. Allowing uninstallation of shared component. Other clients exist, but installed to a different location. was totally unexpected to me :) Is this documented anywhere other than blogs? I think I read *all* of Rob's blog. It looks like Heath Stewart's blog will be my next time sink. -- Nicolás 2013/10/2 Blair Murri os...@live.com: See http://blogs.msdn.com/b/heaths/archive/2009/12/21/about-shared-components.aspx From: nicolas.alva...@gmail.com Date: Tue, 1 Oct 2013 00:51:36 -0300 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Practical use of wixlibs I can't find any documentation on best-practices when creating either merge modules or wixlibs, only procedure documentation on how to create them. Let's say I create a wixlib (or msm) with multiple components that make up a large C++ library. Someone making an application with that library can then use the wixlib and only write installation code for his own app files, instead of having to also define the installation of the library. But where would the library be installed? Would the wixlib need to have a Directory under (say) Common Files where the library would go? Or can the wixlib provide a way for the application wxs to decide where the library would be installed? But then there's a problem: two applications importing the same wixlib could install the same components (with same GUID) in different directories. As far as I know that means only the first one would get installed, the second would see the component is already installed (identified by GUID) and do nothing. Does anyone have experiences to share? -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to pass an enumeration as a variable? Allowing Service Start Type to be passed in as an MSI PROPERY
A standard custom action should be able to deal with that scenario as well. From: chr...@iswix.com To: wix-users@lists.sourceforge.net; wix-users@lists.sourceforge.net Date: Tue, 1 Oct 2013 17:58:42 -0700 Subject: Re: [WiX-users] How to pass an enumeration as a variable? Allowing Service Start Type to be passed in as an MSI PROPERY The other scenario to cover is when an EXE sometimes is and sometimes isn't a service. I usually try to get my developers to factor their classes out into a DLL and create two different EXE facades for it. This plays nicer with MSI. But sometimes they resist and I'm forced to do mutually exclusive components. From: Rob Reynolds ferventco...@gmail.com Sent: Tuesday, October 01, 2013 6:58 PM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to pass an enumeration as a variable? Allowing Service Start Type to be passed in as an MSI PROPERY I think that's likely the path I will take. I'll send a link when done for review. On Tuesday, October 1, 2013, Rob Mensching wrote: Yeah, this sort of thing reminds me why we need to create a standard custom action to replace the built-in ServiceInstall support of the Windows Installer. They just didn't get the core functionality right. sigh/ On Tue, Oct 1, 2013 at 11:02 AM, Hoover, Jacob jacob.hoo...@greenheck.com javascript:;wrote: As Chris outlined in in his answer, If you want an Install time variation point you'll have to go the mutually exclusive component route or the harder dynamically emmited ServiceInstall table route using custom actions that leverage SQL Temporary Tables. ( Much harder... ) The first involves defining a component for each startup option you want to support, condition the components, and utilize the remember me pattern to persist the users choice across upgrades and repairs. The second is much harder to get right, and would take an advanced understanding of Windows Installer. -Original Message- From: Rob Reynolds [mailto:ferventco...@gmail.com] Sent: Tuesday, October 01, 2013 12:48 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to pass an enumeration as a variable? Allowing Service Start Type to be passed in as an MSI PROPERY I am trying to pass a variable to the service start enumeration. This is what I have found http://stackoverflow.com/questions/9419411/wix-setting-service-startup-type- using-a-property-property-not-recognized What is the recommended way to do that? Rob Be passionate in all you do http://devlicio.us/blogs/rob_reynolds http://ferventcoder.com http://twitter.com/ferventcoder -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Rob Be passionate in all you do http://devlicio.us/blogs/rob_reynolds http://ferventcoder.com http://twitter.com/ferventcoder -- October Webinars: Code for Performance
Re: [WiX-users] Authoring a Major Minor upgrade in same package
2013/10/2 victorwhiskey victorhwhis...@yahoo.com: Thanks guys. I've only done installers with major upgrades, so I'm not too sure it that was possible. So what I'm doing now is keeping the ProductCode as * for each build I can install upgrade on top of the previous one. Is this a bad practice then? That means you're changing the ProductCode on every build, which means you're creating major upgrades every time. Nothing wrong with that if it's what you want. -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Authoring a Major Minor upgrade in same package
A single bundle can correctly install one MSI as a major upgrade and another MSI as a minor upgrade in the same chain, if that is what you are asking. Generally minor upgrades are not what most people think that they are (unless you are talking about patching). Major Upgrade is what will work correctly for most people most of the time and is much simpler in both practice and in support. Date: Wed, 2 Oct 2013 11:45:55 -0700 From: victorhwhis...@yahoo.com To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Authoring a Major Minor upgrade in same package Thanks guys. I've only done installers with major upgrades, so I'm not too sure it that was possible. So what I'm doing now is keeping the ProductCode as * for each build I can install upgrade on top of the previous one. Is this a bad practice then? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Authoring-a-Major-Minor-upgrade-in-same-package-tp7589392p7589398.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Practical use of wixlibs
Sort of obscure not-detailed-enough half-mentions on MSDN? For deep technical dives into Windows Installer Heath is my go-to resource. From: nicolas.alva...@gmail.com Date: Wed, 2 Oct 2013 15:45:52 -0300 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Practical use of wixlibs That's extremely enlightening. I thought having two components in different products with the same GUID but different installation directories would be a blatant break of component rules and would just not work. Allowing uninstallation of shared component. Other clients exist, but installed to a different location. was totally unexpected to me :) Is this documented anywhere other than blogs? I think I read *all* of Rob's blog. It looks like Heath Stewart's blog will be my next time sink. -- Nicolás 2013/10/2 Blair Murri os...@live.com: See http://blogs.msdn.com/b/heaths/archive/2009/12/21/about-shared-components.aspx From: nicolas.alva...@gmail.com Date: Tue, 1 Oct 2013 00:51:36 -0300 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Practical use of wixlibs I can't find any documentation on best-practices when creating either merge modules or wixlibs, only procedure documentation on how to create them. Let's say I create a wixlib (or msm) with multiple components that make up a large C++ library. Someone making an application with that library can then use the wixlib and only write installation code for his own app files, instead of having to also define the installation of the library. But where would the library be installed? Would the wixlib need to have a Directory under (say) Common Files where the library would go? Or can the wixlib provide a way for the application wxs to decide where the library would be installed? But then there's a problem: two applications importing the same wixlib could install the same components (with same GUID) in different directories. As far as I know that means only the first one would get installed, the second would see the component is already installed (identified by GUID) and do nothing. Does anyone have experiences to share? -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Practical use of wixlibs
One more point I should make: Windows Installer differentiates between File resources and other resources (like Registry, etc.). Thus, if the shared component has registry and file both (such as COM registrations) the uninstall will remove the files but not touch the registry entries, so COM will remain pointing to the last installed/updated location (which may be the one you just removed, thus breaking COM). If you are installing files that are registered (their locations are written somewhere, like the registry) you probably want to place those components into a common location (unless you need SxS, in which case you need to look at fusion). Otherwise it is safe to place them in the parent product's installation dir. That doesn't change whether you are building MSMs or WixLibs. From: os...@live.com To: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Practical use of wixlibs Date: Wed, 2 Oct 2013 12:01:14 -0700 Sort of obscure not-detailed-enough half-mentions on MSDN? For deep technical dives into Windows Installer Heath is my go-to resource. From: nicolas.alva...@gmail.com Date: Wed, 2 Oct 2013 15:45:52 -0300 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Practical use of wixlibs That's extremely enlightening. I thought having two components in different products with the same GUID but different installation directories would be a blatant break of component rules and would just not work. Allowing uninstallation of shared component. Other clients exist, but installed to a different location. was totally unexpected to me :) Is this documented anywhere other than blogs? I think I read *all* of Rob's blog. It looks like Heath Stewart's blog will be my next time sink. -- Nicolás 2013/10/2 Blair Murri os...@live.com: See http://blogs.msdn.com/b/heaths/archive/2009/12/21/about-shared-components.aspx From: nicolas.alva...@gmail.com Date: Tue, 1 Oct 2013 00:51:36 -0300 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Practical use of wixlibs I can't find any documentation on best-practices when creating either merge modules or wixlibs, only procedure documentation on how to create them. Let's say I create a wixlib (or msm) with multiple components that make up a large C++ library. Someone making an application with that library can then use the wixlib and only write installation code for his own app files, instead of having to also define the installation of the library. But where would the library be installed? Would the wixlib need to have a Directory under (say) Common Files where the library would go? Or can the wixlib provide a way for the application wxs to decide where the library would be installed? But then there's a problem: two applications importing the same wixlib could install the same components (with same GUID) in different directories. As far as I know that means only the first one would get installed, the second would see the component is already installed (identified by GUID) and do nothing. Does anyone have experiences to share? -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Download of shared components
Windows Installer was created in the days of physical software distribution and small hard disks. Physical software distribution means you can and should put all prerequisites in the disc. It doesn't matter if you ship a dozen different products and all of them waste 100MB with the exact same shared DLLs. Small hard disks means that if you install those dozen applications, you wouldn't want all of them installing their own 100MB copy of the DLLs, you would want them installed once and shared across the products. The way shared components work in Windows Installer fits this perfectly. Each MSI carries its own copy of the shared components, but that doesn't matter because they are on different discs. When you install the products, the shared components are only installed once on the user's hard disk. We're now in the age of digital distribution, where requirements change. I think trying to avoid duplicated hard disk usage is still important, but it's even more important to reduce bandwidth use. If I have a dozen applications which share components, and the user wants to install even two of the apps, ideally he should only download the shared components *once*. The only way I know to do this in Windows Installer is not to use multiple products sharing components, but instead to put the shared stuff in its own MSI. Then each application installer will have a bootstrapper that checks if the shared-stuff product is already installed, and if it's not, it downloads the shared msi and installs it. Yhen the next application won't need to. Is there a different way to do this? For example, is it possible to have one msi per application with shared components, but put the shared files in a different non-embedded cabinet, and have the bootstrapper only download this cabinet if needed? -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Id / Guid - updated documentation, etc.
Thanks. I bought a book and am reading through it. It just struck me as odd that the online example placed a GUID in an id, instead of defining an attribute named Guid. For example Product Name='Foobar 1.0' Id='YOURGUID-86C7-4D14-AEC0-86416A69ABDE'why not Guid? ... This (from the install doc) makes more sense - placing he Guid in an identifier name GUID DirectoryRef Id=APPLICATIONROOTDIRECTORY Component Id=myapplication.exe Guid=PUT-GUID-HERE ... Anyways, thanks. I'm 1/4 way through the book and am trying to get my first installer working. Chris -Original Message- From: Blair Murri [mailto:os...@live.com] Sent: Wednesday, October 02, 2013 11:38 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Id / Guid - updated documentation, etc. Components have two identities, a local one (used within the MSI, including in conditions and properties) and a global one (used when identifying a component from a different MSI or even from outside all MSIs). The local one is an identifier (alphanumeric string) and the global one is a GUID. Product and Package identities are always the ProductCode and PackageCode values, so those make sense being named @Id. If you are not tying to support Patching it is generally recommended to first try using a * for all guids (except UpgradeCode) required by WiX/Windows Installer itself, which will cause the WiX toolset to generate stable guids. The toolset will tell you (with a build time error message) when it can't generate that guid. If you don't supply the Component\@Guid value, it will default to * for you, so that is the usual recommendation. Fragment allows you to group resources that need to either be included in the MSI all together or not at all. A reference to any resource within a fragment causes the entire fragment to be linked into the final file by the Light tool. In general going through the CHM (or the online documentation of the same material, but I find the CHM more convenient to access) will give you most of the above information as well as answers to the rest of your raised questions. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Sequencing Patches with MBA
Hi, I have a MBA and I need to support 2 types of release 1. Which warn the user if a previous version exists and ask him to remove it from ARP first 2. Removable patch I have couple questions 1. I am not sure where and if I need to use RelatedBundle…. Action=quot;Patchquot;/ in MBA 2. How can I ensure correct sequencing of patches, is this done with the DetectTargetMsiPackage event? 3. Assuming I install Patch 1, 2, 3 – I would like to prevent the user from uninstalling patch 2 befire uninstalling patch 3 ...how can I detect user remove a middle patch? Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Sequencing-Patches-with-MBA-tp7589408.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Download of shared components
After trying several variations I ended where you have. With common components in a single MSI that goes with several bundles. -Original Message- From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] Sent: Wednesday, October 02, 2013 12:29 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Download of shared components Windows Installer was created in the days of physical software distribution and small hard disks. Physical software distribution means you can and should put all prerequisites in the disc. It doesn't matter if you ship a dozen different products and all of them waste 100MB with the exact same shared DLLs. Small hard disks means that if you install those dozen applications, you wouldn't want all of them installing their own 100MB copy of the DLLs, you would want them installed once and shared across the products. The way shared components work in Windows Installer fits this perfectly. Each MSI carries its own copy of the shared components, but that doesn't matter because they are on different discs. When you install the products, the shared components are only installed once on the user's hard disk. We're now in the age of digital distribution, where requirements change. I think trying to avoid duplicated hard disk usage is still important, but it's even more important to reduce bandwidth use. If I have a dozen applications which share components, and the user wants to install even two of the apps, ideally he should only download the shared components *once*. The only way I know to do this in Windows Installer is not to use multiple products sharing components, but instead to put the shared stuff in its own MSI. Then each application installer will have a bootstrapper that checks if the shared-stuff product is already installed, and if it's not, it downloads the shared msi and installs it. Yhen the next application won't need to. Is there a different way to do this? For example, is it possible to have one msi per application with shared components, but put the shared files in a different non-embedded cabinet, and have the bootstrapper only download this cabinet if needed? -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Authoring a Major Minor upgrade in same package
Thanks for the info and tips. This brings me to another post of mine here http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-handle-a-context-menu-component-on-install-upgrade-td7589322.html . I asked if it was possible to update a context menu handler component without rebooting or restarting explorer. Which would be the better experience? Tell the user a reboot is necessary, or restart explorer and have the screen go blank and all icons and taskbar disappear? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Authoring-a-Major-Minor-upgrade-in-same-package-tp7589392p7589411.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Authoring a Major Minor upgrade in same package
Reboot, since it's 100% effective. In a multi-user environment, you wouldn't want to be killing everyone's shell off (if it were even possible). If it were me, I wouldn't force the reboot either. (Similar to how TortoiseGit upgrades happen; I can ignore the reboot till it suits me.) -Original Message- From: victorwhiskey [mailto:victorhwhis...@yahoo.com] Sent: Wednesday, October 02, 2013 4:38 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Authoring a Major Minor upgrade in same package Thanks for the info and tips. This brings me to another post of mine here http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-handle-a-context-menu-component-on-install-upgrade-td7589322.html . I asked if it was possible to update a context menu handler component without rebooting or restarting explorer. Which would be the better experience? Tell the user a reboot is necessary, or restart explorer and have the screen go blank and all icons and taskbar disappear? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Authoring-a-Major-Minor-upgrade-in-same-package-tp7589392p7589411.html Sent from the wix-users mailing list archive at Nabble.com. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ★ Прочитайте ваше сообщение до того, как оно будет удалено!
Кирилл отправил вам сообщение. Прочитайте его до того, как оно будет удалено! Чтобы прочитать сообщение, перейдите по этой ссылке: http://eu1.badoo.com/0340187522/in/Qt0-7fKkri4/?lang_id=2g=57m=65mid=524ce46a0002025d516a00ec4054016c Если ссылка не работает, скопируйте и вставьте её в адресную строку браузера. Это письмо является частью процедуры доставки сообщения от Кирилл. Если вы получили это письмо по ошибке, просто проигнорируйте его. Через некоторое время сообщение будет удалено. Удачи! Команда Badoo Вы получили это письмо от Badoo Trading Limited (почтовый адрес ниже). Если вы не хотите получать уведомления от Badoo, нажмите здесь: https://eu1.badoo.com/impersonation.phtml?lang_id=2email=wix-users%40lists.sourceforge.netblock_code=b234f1.m=65mid=524ce46a0002025d516a00ec4054016c Badoo Trading Limited зарегистрирована в Англии и Уэльсе под номером CRN 7540255 по юридическому адресу: Media Village, 131 - 151 Great Titchfield Street, London, W1W 5BB. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Download of shared components
Yeah, IMHO, bundles are the future of MSI packages, somewhat captured here: http://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me On Wed, Oct 2, 2013 at 2:03 PM, Wheeler, Blaine (DSHS/DCS) bwhee...@dshs.wa.gov wrote: After trying several variations I ended where you have. With common components in a single MSI that goes with several bundles. -Original Message- From: Nicolás Alvarez [mailto:nicolas.alva...@gmail.com] Sent: Wednesday, October 02, 2013 12:29 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Download of shared components Windows Installer was created in the days of physical software distribution and small hard disks. Physical software distribution means you can and should put all prerequisites in the disc. It doesn't matter if you ship a dozen different products and all of them waste 100MB with the exact same shared DLLs. Small hard disks means that if you install those dozen applications, you wouldn't want all of them installing their own 100MB copy of the DLLs, you would want them installed once and shared across the products. The way shared components work in Windows Installer fits this perfectly. Each MSI carries its own copy of the shared components, but that doesn't matter because they are on different discs. When you install the products, the shared components are only installed once on the user's hard disk. We're now in the age of digital distribution, where requirements change. I think trying to avoid duplicated hard disk usage is still important, but it's even more important to reduce bandwidth use. If I have a dozen applications which share components, and the user wants to install even two of the apps, ideally he should only download the shared components *once*. The only way I know to do this in Windows Installer is not to use multiple products sharing components, but instead to put the shared stuff in its own MSI. Then each application installer will have a bootstrapper that checks if the shared-stuff product is already installed, and if it's not, it downloads the shared msi and installs it. Yhen the next application won't need to. Is there a different way to do this? For example, is it possible to have one msi per application with shared components, but put the shared files in a different non-embedded cabinet, and have the bootstrapper only download this cabinet if needed? -- Nicolás -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
