Re: [WiX-users] Referencing filenames (without full path) anddirectories in formatted strings
Given that you know the filename already when you create your wxs file, why not just replace [#fileABCClass] with ABC.class in your wxs file rather than trying to look it up later on? If you want to avoid typing the filename all over the place you could use the preprocessor to set it once. $define Filename=ABC.class ? and then use it later on as $(var.Filename). -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: Wednesday, April 10, 2013 4:08 PM To: 'Rob Mensching'; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Referencing filenames (without full path) anddirectories in formatted strings That's what I thought. It's too bad that we can't somehow parse out just the filename from the full path (maybe with some regex?), but I guess it's a pretty uncommon request that can be bypassed by just setting the file name to a Property, and referring to that. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: April 10, 2013 18:28 To: afor...@cmu.edu; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Referencing filenames (without full path) anddirectories in formatted strings Oh, sorry, misread question. The answer is there is no way to do that. You already know the file's name so there isn't a way to look it up at runtime. On Wed, Apr 10, 2013 at 2:51 PM, Alain Forget afor...@cmu.edu wrote: Yes, that I know, but I *don't* want the directory. I only want the file's name. For example, say some File element installs a file to C:/My/Path/To/File.exe, I'd like some formatted string type thing to return just File.exe. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: April 10, 2013 17:27 To: afor...@cmu.edu; General discussion for Windows Installer XML toolset. Cc: David Watson Subject: Re: [WiX-users] Referencing filenames (without full path) anddirectories in formatted strings You can use [#ComponentId] to get the directory of the Component containing the file. It's all laid out here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa368609(v=vs.85).aspx On Wed, Apr 10, 2013 at 11:19 AM, Alain Forget afor...@cmu.edu wrote: Yep, confirmed about directories being properties. Thanks...I should have noticed it in my installer logs as well. Duh. I no longer need to get just a filename without its full path, but in case I or someone else wants to do this in the future, how could it be done? -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: April 10, 2013 12:55 To: afor...@cmu.edu; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] Referencing filenames (without full path) anddirectories in formatted strings Indeed, directories are properties. http://blogs.msdn.com/b/robmen/archive/2006/10/17/deciphering-the-msi-directo ry-table-part-7-directories-are-properties.aspx http://blogs.msdn.com/b/robmen/archive/2006/10/17/deciphering-the-msi-directo ry-table-part-7-directories-are-properties.aspx -Original Message- From: Alain Forget [mailto:afor...@cmu.edu] Sent: 10 April 2013 16:02 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Referencing filenames (without full path) anddirectories in formatted strings Thanks for the reply. I thought the syntax [dirA] was only for properties. Does the Directory element also count as (or create) a property? -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: April 10, 2013 10:38 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Referencing filenames (without full path) and directories in formatted strings What about [dirA]. The [$dirA] would be trying to get the directory of a Component matching that Id, right? On Mon, Apr 8, 2013 at 4:00 PM, Alain Forget afor...@cmu.edu wrote: Hi all, Say we have the following structure: Directory Id=dirA Name=A Directory Id=dirB Name=B Directory Id=dirC Name=C Component Id='compABCClass' Guid='MyGuid' File Id=fileABCClass Name=ABC.class DiskId='1'
Re: [WiX-users] Assistance with creating a patch
It would be helpful to know the commands you are using to generate your initial packages as well as your patches. It sounds like you may be having a problem because the base path where its looking for the contents of your admin image doesn't exist. Does this location exist? 'C:\ADS_AutoUpdate\ADS_Install\bin\debug\ADSD\ADS.exe' -Original Message- From: Jeanne Dixon [mailto:jdi...@cots.com] Sent: Friday, July 13, 2012 10:08 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] FW: Assistance with creating a patch I added back into the patch the componentref for the changed file and that got rid of the funny file error. However, I still have the No valid transforms error. It also seems mu file attachments did not go through, so I will paste them here. Product.wxs: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=1F4BF3CB-0221-40A0-AB57-8989358F9C46 Name=ADS Language=1033 Version=1.0.0.0 Manufacturer=me UpgradeCode=2076411E-2B76-4A7A-9B07-930B2ABD16D1 !--Package InstallerVersion=200 Compressed=yes /-- Package InstallerVersion=200 Compressed=yes InstallScope=perMachine AdminImage=yes/ Media Id=1 Cabinet=ads7.cab EmbedCab=yes / Property Id=DBUpdate1/Property !--Property Id=ALLUSERS1/Property-- Property Id =WIXUI_INSTALLDIR Value=INSTALLLOCATION/Property WixVariable Id=WixUIBannerBmp Value=.\bitmap\banner.bmp/ WixVariable Id=WixUIDialogBmp Value=.\bitmap\background.bmp/ !-- this is for the shortcut -- Icon Id=globe.ico SourceFile=..\ADS7\image\globe.ico/ !-- make the path release once this is working -- Binary Id =SupportDLL SourceFile=..\ADS_Support\bin\Debug\ADS_Support.CA.dll / CustomAction Id=UpdateDB BinaryKey=SupportDLL DllEntry=DBUpdate Return=check/CustomAction UI ProgressText Action=UpdateDBVerifying Database Settings/ProgressText /UI UIRef Id =WixUI_InstallDir_NoLic/ InstallExecuteSequence !-- if the flag is set do the database update stuff -- !--Custom Action=UpdateDB After=InstallFinalize(DBUpdate=1) AND ((Installed) OR (Repaired)) AND NOT (REMOVE=ALL)/Custom-- Custom Action=UpdateDB After=InstallFinalize(DBUpdate=1) AND NOT (REMOVE=ALL) AND NOT (PATCH)/Custom /InstallExecuteSequence FeatureRef Id=ProductFeature/ /Product Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLLOCATION Name=ADSD Component Id=ADS7 Guid=8DF796C4-F3C3-4352-A796-5D3174FA0D7F File Id =ADS7.exe Source=..\ADS7\bin\$(var.ADS_Install.Configuration)\ADS7.exe/ Shortcut Id=ADSDesktopShortcut Directory=DesktopFolder Name=ADS Advertise=yes Icon=globe.ico/ Shortcut Id=ADSShortcut Directory=ShortcutsDir Name=ADS Advertise=yes Description=ADS Icon=globe.ico/ /Component !-- the following are the app subdirectories and files -- Directory Id =Reports Name=report/ Directory Id=DBData Name=data/ Directory Id=HelpDir Name=help/ /Directory !-- install -- /Directory !-- program files -- Directory Id=CommonAppDataFolder Directory Id=ADS7Data Name=ADSData Directory Id=AppCheck Name=check/ Directory Id=AppData Name=data Directory Id=AppDataStore Name=store/ Directory Id=AppDataArchive Name=archive/ /Directory !-- data dir -- Directory Id=AppErrorLog Name=errorlog/ Directory Id=AppPdf Name=pdf/ /Directory !-- ads7 -- /Directory !-- common data -- !-- this sets up the shortcuts -- Directory Id=ProgramMenuFolder Directory Id=ShortcutsDir Name=ADS/ Component Id=ShortcutsDir Guid=C2A4E076-5E4b-441C-9C8C-603BAFFF2301 RemoveFolder Id=RemoveShortcutsDir Directory=ShortcutsDir On=uninstall/ RegistryValue Root=HKMU Key=Software\me\ADS Type=integer Value=1 KeyPath=yes / /Component /Directory !-- program menu folder -- Directory Id=DesktopFolder Name=Desktop/ /Directory !-- targetdir -- /Fragment Fragment Feature Id=ProductFeature Title=ADS Level=1 ComponentRef Id=ADS / ComponentGroupRef Id=ReportsGroup/ ComponentGroupRef Id=DBData/ ComponentGroupRef Id=UserDirGroup/ ComponentGroupRef Id=DLLGroup/ ComponentRef Id=NoChart/ ComponentRef Id =HelpFile/
Re: [WiX-users] Patches on patches
Are you saying that you are changing the ComponentRef/@Id in the patch family and generating a bunch of different patches off of this template? Are you changing the name if the PatchFamily as well? If so, your patches are probably superseding eachother. Once you define the contents of a patch family, you can only add to it, and not remove anything from it until you reset your baseline. You need to have a patchfamily per component to get this to work and if you want to also control the order in which these transforms are applied, you will need a second patch family that is common to all your patches (with no content) where the version of the patch family dictates the order. This will force the updates to sequence properly and not supercede. I hope this helps and that I understood your question properly. -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: Monday, May 7, 2012 1:07 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patches on patches I'm trying to work out how to allow an initial MSI to be fixed by an arbitrary (fortunately linear) chain of MSPs. Following the documentation I can do the first link in the chain, but when I apply the same sort of MSP to the resulting bit, it fails to install with the make sure you have the product installed etc. message. Here's a WXS file used to generate my patch: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Patch AllowRemoval=yes Manufacturer=Statistics Canada MoreInfoURL=http://f7cmdev15/; DisplayName=Patch Description=Small update patch Classification=Update Media Id=5000 Cabinet=RTM.cab PatchBaseline Id=RTM / /Media PatchFamilyRef Id=SamplePatchFamily / /Patch Fragment PatchFamily Id=SamplePatchFamily Version=1.0.0.0 Supersede=yes ComponentRef Id=Fbfda1e7e1ccd4 / /PatchFamily /Fragment /Wix At each stage of the chain I've simply been changing the ComponentRefs appropriately in the PatchFamily. Those of you who remember my previous questions may recall that I intend this to be all hidden away in an automatic tool, so what I've done is compared new to old in the full WXS for the new MSI and put in all changed ComponentRefs, which as far as I can tell works at the first stage but fails once you have the first MSP installed. I figure it has something to do with the PatchBaseline being wrong, but don't know for sure, since the documentation is unclear to me here. Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] creating a WIX small or minor patch
The problem is a mismatch between the PatchBaseline you have in the patch wxs and the baseline you are specifying to pyro to attach the transform to. The first argument after the -t is the baseline. If your patch targets RTM (your patch will apply to an RTM install) then you should have Id=RTM for PatchBaseline\@Id. PatchBaseline Id=SP3 / -t RTM out\patch\diff.wixmst -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Wednesday, January 18, 2012 1:48 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] creating a WIX small or minor patch The pyro command looks OK. Could you post your torch, candle and light command lines and your patch wxs please ? -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: 18 January 2012 08:02 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] creating a WIX small or minor patch Hi, As far as I understand the pyro command takes the patch.wxs and the diff file generated with the torch command. The problem is that the diff file is generated from 2 wixpdb files and I don't know how to make my patch.wxs compatible... the right ID to pass has something to do with the diff file, the example works fine, but when I use the same technique on my wixpdb's I get the error mentioned below. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Wednesday, January 11, 2012 12:02 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] creating a WIX small or minor patch That is a example from one of our released products. The Id in the patchbaseline is something you invent and only appears otherwise on the pyro command line. Why do you say that your files are relevant ? -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: 10 January 2012 11:21 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] creating a WIX small or minor patch Yea, that I got from the sample, the problem is that our build.wxs files are a bit more complicated than the example ones... We are using HearDirectory to create our file list, and the file list generated doesn't have a nice ID that I can reference too... What I really need is a good example, an example that shows how to work with real life scenarios... Thanks. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Monday, January 09, 2012 6:02 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] creating a WIX small or minor patch This goes in the Patch element. !-- Id must be higher than any sequence number in the baseline msi's Media/File table. Cabinet must match the original cabinet file name. -- Media Id=5728 Cabinet=Product.cab !-- Id created for the patches' baseline. Referenced in the command line. -- PatchBaseline Id=SP3 / /Media -Original Message- From: tome...@qualisystems.com [mailto:tome...@qualisystems.com] Sent: 09 January 2012 15:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] creating a WIX small or minor patch HI all, I'm having problems creating a WIX small or minor patch... My wsx files that I use to create the installation use HeatDirectory to harvest the files I need to put in my MSI (I'm not using cab, it's in a folder besides the MSI), anyway, I have 2 versions of the installation MSI and the wixpdb files that go along with them, the problem I'm having is creating the right patch.wsx to work with the diff.wixmst I create with the torch... The call to this command: pyro.exe out\patch\patch.wixmsp -out out\patch\patch.msp -t RTM out\patch\diff.wixmst throws: pyro.exe : error PYRO0252 : No valid transforms were provided to attach to the patch. Check to make sure the transforms you passed on the command line have a matching baseline authored in the patch. Also, make sure there are differences between your target and upgrade. And it figures... I don't have an RTM id anywhere... please help... Any link to a patch.wsx sample with a bit MORE details will be MUCH appreciated. Tomer Cohen InSight Team Leader, RD QualiSystems 20 Hacarmel St. Ganey Tikva, Israel 55900 Fax: +972-77-9014099 phone: +972-77-9014094 Mobile: +972-52-3362846 Email: tome...@qualisystems.com Web: www.qualisystems.com QualiSystems | 20 Hacarmel St. Ganey Tikva, Israel 55900 Learn about our NEW Test Automation Solution - TestShell Studio Join our QA Test Automation Group on LinkedIn Standards of Excellence This email including any attachment may contain confidential and/or privileged information intended solely for the use of the specified addressee[s]. Its contents shall not be copied, reproduced, changed or communicated to another - either in whole or in part. If you have received this email or parts thereof in error we request that you immediately notify us and delete this email.
Re: [WiX-users] How to patch elements in InstallExecuteSequence table?
I can offer a workaround. Add a Property in the same fragment as the update you want to reference and then reference that property in your patch family. Alternatively, you can create a patch with no patch families if you are willing to include all the changes in the product. This is something that we need to figure out a way to improve where entire fragments exist with nothing referencable by a normal reference. If you'd like to file a sourceforge bug we can look at finding a better solution. -Peter My team is hiring. Ask me about the open positions. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, December 02, 2009 9:31 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to patch elements in InstallExecuteSequence table? Did this ever get resolved? On Fri, Nov 20, 2009 at 1:01 PM, Sharat Janapareddy sharat.janapare...@microsoft.com wrote: We made some changes to the MSI installer that was released this year and we are releasing the SP soon. One of those changes include adding support to uninstall the patches. For this, we modified some Custom elements in InstallExecuteSequence table of the MSI generating WXS file. (I am not sure if these are the same as CustomActions though!) Anyway, how do we specify in the Patch.wxs that these Custom elements need to be patched? For instance, here's the change which says that we should not run this action when uninstalling the patch - Custom Action='_GetServiceState' After='_SetADName'![CDATA[Installed And REMOVEALL And Not MSIPATCHREMOVE ]]/Custom And here's how I listed it in the Patch.wxs - PatchFamily Id=AgentPatchFamily Version=1.0.0.1 Supersede=yes !-- Nothing here as of now -- CustomActionRef Id=_GetServiceState / /PatchFamily I have also tried this way - Fragment InstallExecuteSequence Custom Action=_GetServiceState After=_SetADName / InstallServices Sequence=5800 / DeleteServices Sequence=2000 / /InstallExecuteSequence /Fragment However in both the cases, when I generated the patch and applied it to the release MSI through ORCA, I don't see this change at all! Another similar issue is with InstallServices and DeleteServices elements of the same InstallExecuteSequence table. Can someone tell me if this is the right way to do this? Thanks, Sharat Janapareddy ~ 40269 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch Creation Issues
Hi Aaron, I posted this blog a while back about patching using admin images. http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-you-didnt-build-with-wix-using-wix-.aspx . I titled it to appeal to people trying to patch things they didn't build with WiX but it is just as applicable to people who built their original product with all the components in one fragment. If you go through the admin image patching process, it will create fragments for each component for you and you will be able to filter the contents of your patch as you desire using patch families. You can also get PatchWiz equivalent behavior as far as filtering without using the legacy patchwiz process by simply not including any patch families in your patch. It will pick up all the differences. You can redefine the conditions of a customaction in a patch. All you have to do is reference something in the same fragment as where your condition is defined. Caveat here is that the condition change wont be applicable during the uninstall of this particular patch. -Peter My team is hiring. Ask me about the open positions. -Original Message- From: Aaron DeMarre [mailto:adema...@gmail.com] Sent: Tuesday, January 25, 2011 1:23 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch Creation Issues Blair, first off, thanks for your help! I really appreciate it. After more investigation (i.e. I rechecked the svn commit dates) my default config file was not changed between the original installer creation and the patch creation, which makes it even more perplexing to me. And to add to my confusion, it was not installing the default config file during patching, but rather restoring the default config file upon uninstallation of the patch. My understanding of what happens during the uninstallation of a patch is limited, but this file is marked permanent, so even if the product was fully reinstalled, I assumed it would fall under the Nonversioned Files are User Data rule of the file versioning. I have never had this issue in the past, so I cannot figure out why this is happening only when new files are added to the patch, and not happening when existing files are updated. This behavior, along with the big change in output from torch.exe when new files are added to the patch raises red flags in this process for me. I think you are right about patchwiz, I do not see a way to exclude files in this process. I could see this causing a lot of issues in the future if I want to release a new installer and a patch that can be applied to both. And finally, from my testing it seems ARPINSTALLLOCATION must be set every time a patch is applied, so the correct condition for the custom action that sets this is NOT REMOVE. Since there is no going back now, it looks like it is a bug in our installer that we are going to have to live with, unless there is a way to redefine the conditions of a custom action in a patch that I am not aware of. Thanks again, -Aaron On Thu, Jan 20, 2011 at 8:42 PM, Blair os...@live.com wrote: I'm not sure how you exclude your default config file changes with PatchWiz, but then again I gave up on PatchWiz after it hung my build system one too many times. -Blair -Original Message- From: Aaron DeMarre [mailto:adema...@gmail.com] Sent: Thursday, January 20, 2011 12:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch Creation Issues Thanks for the info. I played around with this a bit, but still could not get a patch I was happy with. I switched to the patchwiz.dll process and it is giving me the behavior I expect when adding new files to the patch. -Aaron On Tue, Jan 18, 2011 at 8:54 PM, Blair os...@live.com wrote: As I understand it, it uses the fragmentation of the updated installer (and ignores the fragmentation of the original), but Peter is a much better authority than I on that. -Blair -Original Message- From: Aaron DeMarre [mailto:adema...@gmail.com] Sent: Monday, January 17, 2011 10:12 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch Creation Issues Thank you that gives me something to go on. I have all my components in the same fragment, so now I understand what is going on with PatchFamily. If I were to move all changed components into a separate fragment in the updated installer, would this have any effect? Or does it use the fragments declared in the original installer? -Aaron On Sat, Jan 15, 2011 at 2:39 AM, Blair os...@live.com wrote: Some notes on how that patch creation process works: 1. Torch doesn't look at the files themselves, only at the metadata for them already captured in Windows Installer tables. In part because of this (but mostly because some other data that isn't likely to change is also needed when building
Re: [WiX-users] warning PYRO1079 and error PYRO0227 during patch creation
Can you share your patch authoring as well as the command line arguments you are using to build the patch. The usual cause for this is a mismatch between the first argument passed to pyro -t flag and Id in the PatchBasline element in the patch. -Peter My team is hiring. Ask me about the open positions. -Original Message- From: Liam Flanagan [mailto:l...@dyalog.com] Sent: Tuesday, December 07, 2010 4:25 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] warning PYRO1079 and error PYRO0227 during patch creation I'm having some trouble creating a patch for a real world sized application after having successfully followed the patching using purely wix guide within the wix 3.x manual for a small test program. The error is occurring at the final patch production phase (using Pyro) and I'm getting the following output: warning PYRO1079 : The cabinet 'RTM.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please add files to the cabinet or remove it. error PYRO0227 : The transform being built did not contain any differences so it could not be created. The patch.wxs xml definitely defines a feature ref that should have changed between the original and the new version of the program; therefore I imagine I am possibly getting the PYRO1079 warning because of the PYRO0227? The patch wxs is fairly similar to the one used for the small test program. Nevertheless here is some background on the environment: . Using Wix 3.0.5419.0 tools . There are no warnings or errors when creating the msi / wixpdb files for the original or updated application versions . http://blogs.technet.com/b/alexshev/archive/2008/03/08/from-msi-to-wix-part- 9-patching.aspx states that having a compression state of no in the package xml element within the wxs for the msi files is important for patching. I have tried both yes and no as I only discovered that article after I had the simple example working and it appears that I successfully patched my simple example with a setting of yes. I'm aware that this article is fairly dated; is compression still relevant to patching? . The changes between the original and the update version of the program can be seen within the msi files using Orca. Files that have changed in the new version have grown in size, have a higher version number and have all been created/modified after the original files. According to http://msdn.microsoft.com/en-us/library/aa368599%28v=VS.85%29.aspx that should be more than enough for the files to be considered as different. . Furthermore I have separately tested the two msi files by installing the applications on a VM and checking the files installed. The original msi has the original files and the update version msi contains the new files. . Both sets of compiled files (original and update) are available at all times including when using pyro. http://sourceforge.net/tracker/index.php?func=detail http://sourceforge.net/tracker/index.php?func=detailaid=2086871group_id=1 05970atid=642714 aid=2086871group_id=105970atid=642714 implies that not having all the files to hand might cause an issue when pyro is running. Furthermore I have checked the wixmst file output from torch and the relative paths seem correct. Can anyone shed any light on this / point me in the right direction? Thanks, Liam -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Advantage of using Patch Creation Properties over plain WiX?
I am curious to understand why you were getting unchanged files in your patches. Wix does a byte by byte comparison of all files before putting them in a patch. If they don't differ, it shouldn't add them. Perhaps there is a small bug that should be fixed. -Peter My team is hiring. Ask me about the open positions. -Original Message- From: Travis Gaff [mailto:tra...@pc-doctor.com] Sent: Thursday, September 30, 2010 8:30 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Advantage of using Patch Creation Properties over plain WiX? I recently worked with both and failed to get the Pyro method to work to my liking. WiX was excluding obviously changed files in some of my early builds and I couldn't find definitive information on how it determines which files to include in the patch cab. Later I also discovered that it was including a lot of files unnecessarily that were not changed (they were images). This doubled the size of my patches. I suspect that this may have occurred due to including the images in each images directory in one ComponentGroup (and one image changed, thereby dragging the rest in). The PatchWiz method just worked. So while I originally set-up our build system to use the Torch/Pyro method, right now I can't use it (at least until I can make a lot of other changes). I think that PatchWiz may be more common overall, but like the rest of WiX, Pyro/Torch will likely offer more customization in the long run. You might want to look through the past discussions and see what other problems people have had with either solution since WiX3. CONFIDENTIALITY The information contained in this message is confidential. It is intended to be read only by the individual or entity to whom it is addressed or by an authorized designee. If the reader of this message is not the intended recipient, be aware that distribution of this message in any form is strictly prohibited. If you have received this message in error, please immediately notify the sender and destroy any copy of this message. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Monday, September 27, 2010 8:18:50 PM Subject: Re: [WiX-users] Advantage of using Patch Creation Properties over plain WiX? If you do builds in a service account (such as a build lab), know that PatchWiz has been known to pop up a dialog box from time to time which hangs the build and requires someone to attach to the build's desktop (which, of course, no one generally can) to press the OK button. Torch and Pyro never produce dialog boxes during builds that I have ever seen. Yet another mark against PatchWiz. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, September 27, 2010 7:41 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Advantage of using Patch Creation Properties over plain WiX? The WiX tools (pyro.exe in particular) are much smarter. You can get PatchFamily filtering and better error messages. The latter is usually enough for me. smile/ On Tue, Sep 21, 2010 at 6:20 AM, Supermower jg0...@hotmail.com wrote: I am creating a patch, and I noticed that there are two methods recommended for doing so: 1) the use of a Patch Creation Properties file, as recommended http://wix.sourceforge.net/manual-wix3/patch_building.htm here , and 2) just using WiX, as recommended http://wix.sourceforge.net/manual-wix3/wix_patching.htm here and http://www.tramontana.co.hu/wix/lesson4.php here Is one of these ways better? Aside from requiring Windows Installer 3.1 to use the PCP file (which isn't a problem for me), I have not found any documentation on which is better, or why someone would choose one method over the other. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Advantage-of-u sing-Patch-Creation-Properties-over-plain-WiX-tp5554705p5554705.html Sent from the wix-users mailing list archive at Nabble.com. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
Re: [WiX-users] CustomAction in .msp MSI patch
You theoretically only need to add it in the upgrade but if you put it in both
that will work before you ship. If you already shipped your product, changing
the target isn't really an option...
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Valet
Sent: Saturday, November 17, 2007 2:10 AM
To: wix-users list
Subject: Re: [WiX-users] CustomAction in .msp MSI patch
I finally got it working.
My mistake was that I was trying to include the definition of the custom action
into the patch definition. One must in fact define his custom actions in the
base packages and then torch/pyro will detect the differences and include the
custom action into the patch if necessary.
Here is the code snipset that I am now using:
{{{
?xml version='1.0' encoding='UTF-8'?
Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'
PatchAllowRemoval='no'
Manufacturer='corp'
MoreInfoURL='http://www.dummy.com/'
DisplayName='prod'
Description='prod descr'
Classification='Update'
Media Id='5000' Cabinet='RTM.cab'
PatchBaseline Id='RTM'/
/Media
PatchFamilyRefId='UpdatePatchFamily' /
/Patch
Fragment
PatchFamily Id='UpdatePatchFamily' Version='2.0.0.35'
ComponentRef Id='SampleComponent'/
CustomActionRef Id='DoIt' /
PropertyRef Id='MyProp' /
/PatchFamily
/Fragment
/Wix
}}}
Best regards,
J.
Découvrez la nouvelle génération des servives de Windows Live Cliquez
ici!http://get.live.com
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in Wix preprocessor?
This should work. Can you file a bug on SourceForge for this? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hancock (HSG) Sent: Tuesday, November 13, 2007 7:08 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: [WiX-devs] Bug in Wix preprocessor? I'm getting a compile error in a Wix project in the following scenario where a .wxi include file included in another .wxi include file isn't read from a location relative to the outside include but instead relative to the file that included the outer include file. In other words, I've got files that look something like the following: A.wxs Outer.wxi Inner.wxi SubDirectory\B.wxs A.wxs includes Outer.wxi like: ?include Outer.wxi ? B.wxs includes Outer.wxi like: ?include ..\Outer.wxi ? Outer.wxi includes the line: ?include Inner.wxi ? I get a compile error something like the following: Error 1 The system cannot find the file 'Inner.wxi ' with type 'include'. D:\MyDirectory\Outer.wxi 111 MyProject When processing includes for A.wxs, the compiler is able to find Inner.wxi OK, but it cannot for B.wxs because it looks for Inner.wxi in its own folder rather than relative to the location where it included Outer.wxi. This ought to work, should it not? John - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wixpdb
It compares the files on disk and does a bitwise comparison of the files. If they are truly identical, it is smart enough to know. The CompareFiles method is also extensible if you implement a binder extension which would allow you to incorporate any additional smarts that you can infer based on your build environment or source structure. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Sent: Thursday, November 08, 2007 9:55 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] wixpdb When creating patches... Does the wixpdb method compare the binaries from the two .msi files? Or, does it compare the files as they are on the disk? (My preference is for using .msi files due to project archiving and other such things). If it compares the files as they are on the disk, is it wise enough to know when one .msi has a c:\1.0\whatever.exe, and another .msi has c:\1.1\whatever.exe, and the whatever.exe files are exactly identical? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New to WIX, trying to use VOTIVE 3.0 but can't get embedded CAB working properly
You don't need to create the cab yourself. WiX will do that for you. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lanteigne, Alan Sent: Thursday, November 08, 2007 9:56 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] New to WIX, trying to use VOTIVE 3.0 but can't get embedded CAB working properly I'm trying to package up a C# application I've made. The final installer will need to set some registry keys, but for now I'm trying to just get simple file copying to work. I've created a CAB file containing the EXE and a few supporting files by using cabarc.exe: cabarc N product.cab Release\*.* Release\images\*.* Release\icons\*.* This creates product.cab, which definitely contains the files. I then create a WIX project in VS2005 and modify the template Product.wxs to include this: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=43f2ead8-70d1-41b6-9db5-a5d4ad96be83 Name=ID14 Language=1033 Version=1.4.0.0 Manufacturer=AlanTest Package InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=product.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Name=ID14 Component Id=ID14exe Guid=43f2ead8-70d1-41b6-9db5-a5d4ad96be83 File Id= ID14file Name=id14.exe LongName=id14.exe Source= id14.exe Vital=yes KeyPath=yes DiskId=1/ /Component /Directory /Directory Feature Id=ProductFeature Title=PUT-FEATURE-TITLE-HERE Level=1 ComponentRef Id=ID14exe / /Feature /Product /Wix I copy my CAB file to the project folder (same folder as Product.wxs), compile, and get a The system cannot find the file 'id14.exe' error. Am I missing some simple step? I looked through the tutorial and docs but they mostly skipped over how to stage the CAB file properly. Thanks, Alan S. Lanteigne | Channel Ready Solutions phone fax +1.317.715.8293| [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Interactive Intelligence Inc. Deliberately Innovative www.inin.comhttp://www.inin.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Building a patch in Visual Studio
You are correct, the MsiFileHash table is not populated for Setup and Deployment project msi's. From looking in the Patching code in WiX, it appears it will add the MsiFileHash entry for unversioned files into the transform for files that have changed when binding the transform into the patch. Have you built a patch and observed the MsiFileHash entry being added to the msi? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Wednesday, November 07, 2007 9:40 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Building a patch in Visual Studio Visual Studio setups don't generate MsiFileHash entries for data files. Does WiX (well MsiFiler) populate these tables later? This is usually an issue when generating patches because the original install source is more likely to be required when the patch is applied. See MSDN topic Preventing a Patch from Requiring Access to the Original Installation Source. Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Marcu Sent: Tuesday, November 06, 2007 11:11 AM To: Schuett, Michael; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Building a patch in Visual Studio Not possible using the Setup Deployment project. You can however build patches out of the MSI's it produces using wix v3's admin image patching features. Generate an admin image of your baseline and upgrade msi's. Call torch with -ax and the msi's in the admin layouts. Then follow the wix patch building process from there. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schuett, Michael Sent: Tuesday, November 06, 2007 10:08 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Building a patch in Visual Studio Is it possible to build a patch inside VS2005? All I've been able to generate is a useless MSI. Thanks, Mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Building a patch in Visual Studio
Not possible using the Setup Deployment project. You can however build patches out of the MSI's it produces using wix v3's admin image patching features. Generate an admin image of your baseline and upgrade msi's. Call torch with -ax and the msi's in the admin layouts. Then follow the wix patch building process from there. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schuett, Michael Sent: Tuesday, November 06, 2007 10:08 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Building a patch in Visual Studio Is it possible to build a patch inside VS2005? All I've been able to generate is a useless MSI. Thanks, Mike - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Font definition and WXL
The issue is that those columns in the TextStyle table are not marked as localizable so the !(loc variable replacement never happens. Please file a sourceforge bug on this. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy Sent: Friday, November 02, 2007 8:51 AM To: Paul Houldridge Cc: [EMAIL PROTECTED]; Eric Baudouin; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Font definition and WXL Actually, paul, I suspect that Facename isn't working either, you just don't get an XSD validation error because there's no rules for the format of the face name. I bet if you hardcoded the size and bold attributes and compiled your MSI you'd have the !(...) stuff in your facename in the output MSI. You just wouldn't get a validation error, because there's no way for MSI to know that the facename you supplied isn't a valid font name -- after all, who wouldn't want to call their font !(loc.BannerTextStyle_Facename)? wink/ Paul Houldridge [EMAIL PROTECTED] 11/02/2007 08:17 AM To Eric Baudouin [EMAIL PROTECTED], Kelly Leahy [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net, [EMAIL PROTECTED] [EMAIL PROTECTED] Subject RE: [WiX-users] Font definition and WXL I actually rewrote the code for the last test. If you look at the original example the names match. However, after trying a few more things, it looks like the FaceName attribute takes the localized string just fine. It’s the Size and Bold attributes that are not preprocessing the localized string. Look at the original errors below. Paul From: Eric Baudouin Sent: Thursday, November 01, 2007 5:20 PM To: Kelly Leahy Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] Font definition and WXL Not a bad suggestion☺ Paul would you mind to have a look at this, in case the linker is case sensitive. Thank you. E. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 4:59 PM To: Eric Baudouin Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] Font definition and WXL Ok... It also appears that your error message says 'Facename' (lowercase 'N'), but your declaration shows an uppercase. Not sure if it matters, just thought I'd mention it since I noticed it. Kelly Eric Baudouin [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/01/2007 04:44 PM To Kelly Leahy [EMAIL PROTECTED] cc [EMAIL PROTECTED] [EMAIL PROTECTED], Paul Houldridge [EMAIL PROTECTED], wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject Re: [WiX-users] Font definition and WXL Here is the answer from Paul, so it look like syntaxically speaking we were doing the right thing. So I think we need to focus more on the methodology. Thank you anyway for your reply. No luck. Using the ! instead of the $ is right. $ is deprecated. .\SetupUI.wix(26) : warning LGHT1073 : The localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'. Please use the '!' prefix instead. Since the prefix '$' is also used by the preprocessor, it has been deprecated to avoid namespace collisions. warnings in directory c:\drs_sync_1\sql\sync\src\setup\core c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : warning LGHT1073 : The localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'. Please use the '!' prefix instead. Since the prefix '$' is also used by the preprocessor, it has been deprecated to avoid namespace collisions. .\SetupUI.wix(26) : error LGHT0102 : The localization variable !(loc.BannerTextStyle_Facename) is unknown. Please ensure the variable is defined. errors in directory c:\drs_sync_1\sql\sync\src\setup\core c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : error LGHT0102 : The localization variable !(loc.BannerTextStyle_Facename) is unknown. Please ensure the variable is defined. NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code '0x66' NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code '0x66' Stop. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 4:31 PM To: Eric Baudouin Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] Font definition and WXL Don't you want $(loc.BannerTextStyle_Size) not !(loc.BannerTextStyle_Size)? Kelly Eric Baudouin [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/01/2007 04:17 PM To wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net cc Paul Houldridge [EMAIL PROTECTED] Subject [WiX-users] Font definition and WXL Hello, We have moved our resource to a wxl file to facilitate the localization of our component. In the localization world it is a good practice to make sure that the font size and the font facename can be localized. I was hoping that I could move the font style attribute in the
Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)
Change the product code. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay Sent: Thursday, November 01, 2007 1:40 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv) Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)http://sourceforge.net/mailarchive/message.php?msg_name=E1Ing0k-0001xa-00%40xmission.xmission.com From: Richard [EMAIL PROTECTED] - 2007-11-01 19:47 In article [EMAIL PROTECTED], Davut Karabay [EMAIL PROTECTED] writes: When I run the new version of installer, it invokes the installed old versi= on. I don't want that happen. I want the new version installed anyway. Why? -- Because new version of the product is completely different from old one (apparently except the installer). Set of features, targeted platforms are different. So, it makes sense to me that new one does not invoke old cache. Specific scenario is this: --Old version is installed on XP --New version has launch conditions to install only on Vista --Try installing new version on XP (to test that it won't install) --New version invokes old cache. Launch conditions won't even run. Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try now!http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)
From the msi documentation: The ProductCode property is a unique identifier for the particular product release It sounded to me like you have a completely separate release so you should change the ProductCode property of the MSI. This is set by the Product/@Id attribute in WiX. From: Davut Karabay [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 2:31 PM To: Peter Marcu; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv) Hi Peter - What do you mean by changing the product code? From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Date: Thu, 1 Nov 2007 13:47:35 -0700 Subject: RE: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv) Change the product code. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay Sent: Thursday, November 01, 2007 1:40 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv) Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)http://sourceforge.net/mailarchive/[EMAIL PROTECTED] From: Richard [EMAIL PROTECTED] - 2007-11-01 19:47 In article [EMAIL PROTECTED], Davut Karabay [EMAIL PROTECTED] writes: When I run the new version of installer, it invokes the installed old versi= on. I don't want that happen. I want the new version installed anyway. Why? -- Because new version of the product is completely different from old one (apparently except the installer). Set of features, targeted platforms are different. So, it makes sense to me that new one does not invoke old cache. Specific scenario is this: --Old version is installed on XP --New version has launch conditions to install only on Vista --Try installing new version on XP (to test that it won't install) --New version invokes old cache. Launch conditions won't even run. Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try now!http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews Windows Live Hotmail and Microsoft Office Outlook - together at last. Get it now!http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)
Note that Package ID and ProductCode are different. One is on the Package element and should always change, one is on the Product element and should change with each release. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay Sent: Thursday, November 01, 2007 2:54 PM To: Chad Petersen; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv) That was the first thing I did, changing both product id and upgrade code. But still invokes the cached msi. I think I will give another try because everyone suggests it will work. By the way please bare with me on installers :). It is one of the things that I inherited recently. Subject: RE: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv) Date: Thu, 1 Nov 2007 14:38:33 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Peter is suggesting you change your Product Id=GUID. I think you might want to also consider changing the UpgradeCode=GUID also for future ease of upgrading one product versus the other, but it really depends on what your ultimate goal is. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay Sent: Thursday, November 01, 2007 2:31 PM To: Peter Marcu; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv) Hi Peter - What do you mean by changing the product code? From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Date: Thu, 1 Nov 2007 13:47:35 -0700 Subject: RE: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv) Change the product code. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay Sent: Thursday, November 01, 2007 1:40 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv) Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)http://sourceforge.net/mailarchive/[EMAIL PROTECTED] From: Richard [EMAIL PROTECTED] - 2007-11-01 19:47 In article [EMAIL PROTECTED], Davut Karabay [EMAIL PROTECTED] writes: When I run the new version of installer, it invokes the installed old versi= on. I don't want that happen. I want the new version installed anyway. Why? -- Because new version of the product is completely different from old one (apparently except the installer). Set of features, targeted platforms are different. So, it makes sense to me that new one does not invoke old cache. Specific scenario is this: --Old version is installed on XP --New version has launch conditions to install only on Vista --Try installing new version on XP (to test that it won't install) --New version invokes old cache. Launch conditions won't even run. Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try now!http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews Windows Live Hotmail and Microsoft Office Outlook - together at last. Get it now!http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033 Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. Play Now!http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Latest WiX build is good.
For the past few wix builds, we have been having some assembly loading problems due to mismatched strong names in the wix binaries. This has been resolved and the latest build should work. http://wix.sourceforge.net/releases/3.0.3429.0/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Torch error
Are there any differences in the table definition for WixFile between the two wixouts? Can you send just the tale definitions to me? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Goshi Sent: Wednesday, October 31, 2007 10:36 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Torch error I recently upgraded to using Wix build 3.0.3439.0 because I wanted to use the new transform validation flags support for patch building. When I switched to the new Wix build (was using 3110), I now get the following torch error: error TRCH0001 : Different numbers of columns for WixFile. What does this error mean? I went into my .wixout file and looked at the WixFile tables and they all look like they have 11 columns. Thank you, Justin [cid:image001.gif@01C81BAA.55A6E390]http://office/Teams/officelive/teamsites/olpwis hiring devhttp://career/search/results.aspx?FromCP=YJobCategoryCodeID=10056JobLocationCodeID=JobProductCodeID=11105JobTitleCodeID=Divisions=TargetLevels=Keywords=JobCode=ManagerAlias=Interval=50StartDate=EndDate=, testhttp://career/search/results.aspx?FromCP=YJobCategoryCodeID=10020JobLocationCodeID=JobProductCodeID=11105JobTitleCodeID=Divisions=TargetLevels=Keywords=JobCode=ManagerAlias=Interval=50StartDate=EndDate= and PMhttp://career/search/details.aspx?JobID=6517DB8E-AF18-4341-A40F-11B045B3164Fstart=1interval=10! inline: image001.gif- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Torch error
Yup, that will do it. From: Justin Goshi Sent: Wednesday, October 31, 2007 11:12 AM To: Peter Marcu; wix-users@lists.sourceforge.net Subject: RE: Torch error Yup, there are differences in the table definition for WixFile between the two wixouts. It's because my base image wixout was generated by the old Wix build, and the new wixout has an additional PatchAttributes column in the WixFile table. Thank you for your help! Justin From: Peter Marcu Sent: Wednesday, October 31, 2007 10:40 AM To: Justin Goshi; wix-users@lists.sourceforge.net Subject: RE: Torch error Are there any differences in the table definition for WixFile between the two wixouts? Can you send just the tale definitions to me? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Goshi Sent: Wednesday, October 31, 2007 10:36 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Torch error I recently upgraded to using Wix build 3.0.3439.0 because I wanted to use the new transform validation flags support for patch building. When I switched to the new Wix build (was using 3110), I now get the following torch error: error TRCH0001 : Different numbers of columns for WixFile. What does this error mean? I went into my .wixout file and looked at the WixFile tables and they all look like they have 11 columns. Thank you, Justin [cid:image001.gif@01C81BAF.00F91610]http://office/Teams/officelive/teamsites/olpwis hiring devhttp://career/search/results.aspx?FromCP=YJobCategoryCodeID=10056JobLocationCodeID=JobProductCodeID=11105JobTitleCodeID=Divisions=TargetLevels=Keywords=JobCode=ManagerAlias=Interval=50StartDate=EndDate=, testhttp://career/search/results.aspx?FromCP=YJobCategoryCodeID=10020JobLocationCodeID=JobProductCodeID=11105JobTitleCodeID=Divisions=TargetLevels=Keywords=JobCode=ManagerAlias=Interval=50StartDate=EndDate= and PMhttp://career/search/details.aspx?JobID=6517DB8E-AF18-4341-A40F-11B045B3164Fstart=1interval=10! inline: image001.gif- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Changing the location of the files to take...
Use a preprocessor variable. $(var.TakeFolder) and on the commandline to candle pass -dTakeFolder=1. Then change it to 2 when you need to change it to 2. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Rivers Sent: Monday, October 29, 2007 4:19 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Changing the location of the files to take... Hi all, I have a Take folder, which os for our developers to put the compiled files into for me to take to put into the installer but with version changes this directory could also change. for instance I currently have this: File Id=foo.bar Name=foo.bar DiskId=1 KeyPath=yes Source=u:\1\take\common\foo.bar / but when I build the installer for version 2 Have to go through all the files changing the 1 to a 2. sure, this doesn't take that long using a find and replace, but what would be nice is to have a variable of say TakeFolder and just change it in the 1 location, and have all my file codes looking like this: File Id=foo.bar Name=foo.bar DiskId=1 KeyPath=yes Source=[takefolder]\common\foo.bar / is there a way to do this? thanks in advanced. Jason - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Doing QFEs With WiX
In WiX v2, you should be able to create patches using the PatchCreation element. The process is documented in the chm. It will build you a PCP file which you then can to push through a set of Windows Installer tools. WiX v3 has made patch creation a more native part of the process and that process is documented in the latest chm file about the Patch element. From: Jim Williams [mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 11:22 AM To: Peter Marcu; WiX-users@lists.sourceforge.net Subject: RE: Doing QFEs With WiX I am a little behind on keeping up with the latest updates, but am currently using WiX 2.0.3719. Jim From: Peter Marcu [mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 11:14 AM To: Jim Williams; WiX-users@lists.sourceforge.net Subject: RE: Doing QFEs With WiX What version of WiX are you using? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Williams Sent: Monday, October 29, 2007 11:16 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Doing QFEs With WiX We currently have a product which installs, literally, thousands of files (source and binaries) that define applications for creating operating systems using Windows Embedded CE. The installer is defined in WiX. But we would like to release updates to the files on a regular basis, like what Microsoft does monthly using QFEs for Windows Embedded CE. Is there some way to define a QFE-like mechanism by using WiX? Even if there isn't, are there some guidelines online somewhere that define how ones goes about creating a QFE and how the original installer should be structured to allow for easy installation of QFEs? Thanks, Jim Williams Intrinsyc Software International, Inc. 11130 NE 33rd Place, Suite 200 Bellevue, WA 98004 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] 425.732.4904 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Doing QFEs With WiX
What version of WiX are you using? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Williams Sent: Monday, October 29, 2007 11:16 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Doing QFEs With WiX We currently have a product which installs, literally, thousands of files (source and binaries) that define applications for creating operating systems using Windows Embedded CE. The installer is defined in WiX. But we would like to release updates to the files on a regular basis, like what Microsoft does monthly using QFEs for Windows Embedded CE. Is there some way to define a QFE-like mechanism by using WiX? Even if there isn't, are there some guidelines online somewhere that define how ones goes about creating a QFE and how the original installer should be structured to allow for easy installation of QFEs? Thanks, Jim Williams Intrinsyc Software International, Inc. 11130 NE 33rd Place, Suite 200 Bellevue, WA 98004 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] 425.732.4904 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Target specific version with patch generated using pyro
In the last couple of months support was added to wix for specifying transform validation flags for your transforms either on the command line to torch, or through your patch authoring. These flags determine which products your patch transforms will apply to. Adding an upgrade table using a patch is possible and will enable the product to go through a major upgrade in the future. I didn't understand the last question. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Goshi Sent: Tuesday, October 23, 2007 11:37 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Target specific version with patch generated using pyro I'm generating patch files using the new WiX patch building system (followed the directions on Peter's blog). Is there any way to have the patch target specific versions, languages, etc? I tried adding an Upgrade element into the new msi (it was missing in the baseline msi). Would this work? Is there any built in Windows Installer support when the Upgrade table detects unsupported versions, languages, etc. or do I have to handle them using custom actions based on the results of FindRelatedProducts? Thank you for your time. Justin [cid:image001.gif@01C81569.F7149610]http://office/Teams/officelive/teamsites/olpwis hiring devhttp://career/search/results.aspx?FromCP=YJobCategoryCodeID=10056JobLocationCodeID=JobProductCodeID=11105JobTitleCodeID=Divisions=TargetLevels=Keywords=JobCode=ManagerAlias=Interval=50StartDate=EndDate=, testhttp://career/search/results.aspx?FromCP=YJobCategoryCodeID=10020JobLocationCodeID=JobProductCodeID=11105JobTitleCodeID=Divisions=TargetLevels=Keywords=JobCode=ManagerAlias=Interval=50StartDate=EndDate= and PMhttp://career/search/details.aspx?JobID=6517DB8E-AF18-4341-A40F-11B045B3164Fstart=1interval=10! inline: image001.gif- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wixout file format
The wixout is not a pure xml file in WiX 3.0. It has a cab at the beginning of it that contains embedded binary files. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Goshi Sent: Tuesday, October 23, 2007 12:26 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] wixout file format I have a question about the .wixout file format. I thought it was supposed to be just an xml file, but it looks like it has a bunch of binary data in front of the xml part. What is the binary data used for and is there a way to suppress it? The reason I'm asking is I want to parse the .wixout file so I can rewrite the path to a dll we are patching (useful for our automated build process), but cannot simply open as an xml file due to the binary data in front. Here is my command to generate the file: light.exe -nologo -xo -b path -ext WixUtilExtension -ext WixIISExtension -ext WixSqlExtension -ext WixNetFxExtension -cultures:en-US -sice:ICE30 -sice:ICE74 -sice:ICE32 -sice:ICE09 -sice:ICE54 -sice:ICE48 -sice:ICE40 -loc uistrings.xml -sice:ICE40 -sice:ICE87 -out file.wixout file.wixobj Thank you, Justin [cid:image001.gif@01C81576.EA68CC80]http://office/Teams/officelive/teamsites/olpwis hiring devhttp://career/search/results.aspx?FromCP=YJobCategoryCodeID=10056JobLocationCodeID=JobProductCodeID=11105JobTitleCodeID=Divisions=TargetLevels=Keywords=JobCode=ManagerAlias=Interval=50StartDate=EndDate=, testhttp://career/search/results.aspx?FromCP=YJobCategoryCodeID=10020JobLocationCodeID=JobProductCodeID=11105JobTitleCodeID=Divisions=TargetLevels=Keywords=JobCode=ManagerAlias=Interval=50StartDate=EndDate= and PMhttp://career/search/details.aspx?JobID=6517DB8E-AF18-4341-A40F-11B045B3164Fstart=1interval=10! inline: image001.gif- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Command line parameters
You could use 3 different properties. One for the command line, one for the registrysearch, and one for the default. Then have two set property custom actions conditioned on whether or not the command line property is set or if the registrysearch property is set. If they are, then you would set the default property to that value using the custom action. You can order them in the order you need to in order to get the precedence you want. Then just use the default property everywhere else. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RussGreen Sent: Sunday, October 21, 2007 8:56 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Command line parameters I have 2 public properties in my MSI file. Each property is set a default value as well has a registrysearch to find a value.. e.g. Property Id=MDBFULLPATH Value=C:\Program Files\eProject\database\eProject - empty.mdb RegistrySearch Id=MDBPathRegistry Type=raw Root=HKLM Key=Software\eProject Name=DataSource / /Property What I want to be able to do is pass in a value for this property from the command line but that only works when RegistrySearch is commented out. If the RegistrySeach returns a value then that should be used, else the command line value should be used, else the defautl Value should be used as a last resort. Is this possible? Russ -- View this message in context: http://www.nabble.com/Command-line-parameters-tf4666532.html#a13330344 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] For a commerical install - Wix 3.0 Vs Wix 2.0
WiX 3.0 is fairly stable at this point. Very few new features are being added and it is being used by some fairly large and complex installs already. It is also is more feature rich than 2.0, as well as having many bugs fixes that didn't make it into 2.0. As long as you are willing to update your wix binaries if something changes and update your sources to match the change (WixCop should help you with that), I would go with 3.0. To summarize: There are many commercial installs out there already on WiX 3.0 and it is fairly stable at this point. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, October 21, 2007 12:14 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] For a commerical install - Wix 3.0 Vs Wix 2.0 I am trying to figure out if Wix 2.0 is better then Wix 3.0 for a client's commerical product installation that I am trying to migrate out of InstallShield 9.0. Even though 2.0 is the stable version, I have had some problems with the latest downloads 2.0.5325.0, e.g. missing .wixobj files etc. I can't even build the source downloads. The make.bat calls NMAKE, not NANT. Rather than upgrading InstallShield from 9 to the latest, I have been experimenting with Wix, as I have not been to impressed with InstallShield. I current use the the basic install format, using C++ as opposed to InstallScript for CA's. Thank you: Aris Green - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch element and creation of patch in 3.0
Delta patching is not supported using the Patch element yet. Also, using the WiX 3.0 patch build system, you cannot patch things that come from MSM's. The suggested way to share setup logic is to use Wixlibs, if your msm's are built using wix, then you could consider that. Alternatively, you can create admin images of your target and upgrade layouts and run torch with the -ax switch. You can then pass those transforms as inputs into pyro along with Patch authoring. This is a way to get your msm logic into you patch. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Stindl Sent: Tuesday, October 16, 2007 5:38 AM To: WiX Users Subject: [WiX-users] Patch element and creation of patch in 3.0 Hallo all, could you anybody explain me, how to create patch in 3.0 WiX version? I've read any samples from Peter Marcu (e.g. http://blogs.msdn.com/pmarcu/archive/2007/06/28/sample-patch.aspx) but it is not enough for solution of my problem. I also can't find any documentation of Patch 3.0 WiX element. My problem is following: I have really big MSI installation, which is built on our build server every day and from time to time we need to apply delta patch on our production platform. Unfortunately with 2.0 WiX + PatchWiz we were not successful, because of crash of PatchWiz utility every time. The MSI packages are packages, where we have about 30 features (MSM modules), MSI are created by WiX version 2.0. Thanks a lot for help, otherwise I'm going to be crazy from that... :-/ David There is the main MSI source: -- Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; !-- Product definition -- Product Id=2EDDF5B5-FACA-437e-A5AF-E5EB84B47FB5 UpgradeCode='457F1CC2-0441-4114-A317-F640D32F8712' Language=1033 Codepage=1252 Version=4.2 Name=Product Manufacturer=Company.. !-- Package definition -- Package Id='----' InstallerVersion=200 Compressed=yes Manufacturer=Company Comments=a comment / !-- Media definitions -- Media Id='1' Cabinet='Foris.cab' EmbedCab='yes' DiskPrompt=CD-ROM #1 / Property Id='DiskPrompt' Value=Product Installation [1] / Property Id=ALLUSERS1/Property !-- Upgrade properties -- Upgrade Id='457F1CA2-0441-4114-A317-F640D32F8712' UpgradeVersion OnlyDetect='yes' Property='PATCHFOUND' Minimum='4.2.0' IncludeMinimum='yes' / UpgradeVersion OnlyDetect='yes' Property='NEWERFOUND' Minimum='4.2.0' IncludeMinimum='no' / /Upgrade CustomAction Id='AlreadyUpdated' Error='[ProductName] is already installed.' / CustomAction Id='NoDowngrade' Error='A later version of [ProductName] is already installed.' / !-- Installer Directories -- Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='INSTALLDIR' Name='4.2' Merge Id=FNGInstallLib.971AF99B-8195-4248-9C21-776B2B3FD6C5 Language=1033 SourceFile=FNGInstallLib.msm DiskId=1 / /Directory /Directory /Directory /Directory /Directory !-- Installer Features -- Feature Id='Complete' Title=Product 4.2 Installation' Description='The complete Product 4.2 package.' Display='expand' Level='300' ConfigurableDirectory='INSTALLDIR' /Feature !-- ### Component Instalation Fragments ### -- FragmentRef Id='BaseFragment_FF'/ FragmentRef Id='BaseFragment_PP'/ FragmentRef Id='BaseFragment_PCT'/ FragmentRef Id='BaseFragment_RE'/ FragmentRef Id='BaseFragment_BM'/ FragmentRef Id='BaseFragment_CM'/ FragmentRef Id='BaseFragment_CMO'/ FragmentRef Id='BaseFragment_BE'/ FragmentRef Id='BaseFragment_AR'/ FragmentRef Id='BaseFragment_C'/ FragmentRef Id='BaseFragment_DF'/ FragmentRef Id='BaseFragment_V'/ FragmentRef Id='BaseFragment_MG'/ FragmentRef Id='BaseFragment_RI'/ FragmentRef Id='BaseFragment_RT'/ FragmentRef Id='BaseFragment_NE'/ FragmentRef Id='BaseFragment_UM'/ FragmentRef Id='BaseFragment_TU'/ !-- Installer GUI -- UIRef Id=WixUI_Mondo / UIRef Id=WixUI_ErrorProgressText / !-- Installer Seguinces -- InstallExecuteSequence Custom Action='AlreadyUpdated' After='FindRelatedProducts'PATCHFOUND/Custom Custom Action='NoDowngrade' After='FindRelatedProducts'NEWERFOUND/Custom RemoveExistingProducts After='InstallFinalize' / StartServices Suppress='yes'/ /InstallExecuteSequence /Product /Wix -- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com
Re: [WiX-users] NGen and uninstalling
Hi Doug, Can you verify for me whether or not the images are removed after a reboot? My suspicion is that because the file is in use, the OS cant remove it and schedules a Pending File Rename Operation on the file which will be executed on a reboot. If they are not removed on reboot, let me know and I'll dig deeper. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Payne Sent: Tuesday, October 09, 2007 3:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] NGen and uninstalling Hello, I would like some help understanding how the native image element and related custom actions work in Wix 2.0. Specifically, I would like some advice on how to debug a problem I am seeing when uninstalling my product. I am using this element to add assemblies to the Native Image Cache during install, and remove them during uninstall. This works well unless one of the applications relying on these assemblies is running when the product is reinstalled or removed. In that case, even if Restart Manager is able to close the applications, the files sometimes remain in the Native Image folder after uninstall. From the verbose log, I see that the ExecNetFX CA fires, and ngen.exe is indeed called once for each assembly which is to be removed. (Unlike during the installation process, I do not see the actual command line being used for ngen.) I verified: * NetFxScheduleNativeImage is run after InstallValidate. Numerous 2715 errors are logged, indicating the specified file key could not be found in the file table. The second parameter for these messages, the file key itself is either blank or not logged. Regardless, the CA sets the NetFxExecuteNativeImageUninstal and NetFxExecuteNativeImageCommitUninstal propeties. It returns 1 * NetFxExecuteNativeImageCommitUninstall runs next, and returns 1. * NetFxExecuteNativeImageUninstall is skipped. * NetFxExecuteNativeImageCommitInstall runs next, and returns 1. * NetFxExecuteNativeImageInstall is skipped. * The NetFX custom action is then invoked, which appears to run NGen once for each assembly, presumably to uninstall the files from the cache. * The ExecNetFx CA then runs. I don't know what it does, but this is followed in the log by 40 lines of the form RollbackCleanup: File: C:\Config.Msi\4f516.rbf. I also tried using a custom actionw which shuts down the applications before Restart Manager sees them. This is to prevent the user from allowing the applications to run during uninstall. This did not help, as images remained in the cache after setup completed. Has anyone else seen this problem? If so, how did you handle it? Thanks for your time. --Doug - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] QFE authoring after service pack release
The transforms in patches usually only apply to a single baseline. In your case, you chose your RTM as your baseline. A patch can carry multiple transforms but you will need to include both in the patch if you want your patch to apply to both scenarios. The other option is to carry the single transform and set the transform validation bits to say that the transform applies to 1.0.2000 and earlier. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chad Petersen Sent: Wednesday, October 10, 2007 9:26 AM To: Ning Lin; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] QFE authoring after service pack release I believe the last digit of the version is ignored. You might have better luck using 1.0.2020 instead. Just a hunch. Might be worth a try. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ning Lin Sent: Wednesday, October 10, 2007 9:16 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] QFE authoring after service pack release Resend ... Appreciate any pointers! Thanks! Ning Hello, So our scenario is this 1) Product RTM'ed (say version 1.0.1000) 2) We created and shipped a service pack 1 (say version 1.0.2000) 3) Now we realize we need to ship a QFE (say version 1.0.2002) So we created a QFE patch that is basically a diff between versions 1.0.1000 and versions 1.0.2002 -- it tries to update 1 file to version 1.0.2002. Now this QFE patch works on a machine that only has the RTM version installed, that 1 binary is updated to version 2002 as expected. On a machine that has SP1 installed, it simply does nothing! On the verbose log, it shows that it's trying to update the file to version 2000, since version 2000 is already on the machine, it does nothing. So my question is, should we author the QFE by diff'ing it to the RTM CD, or diff'ing it to the SP1 CD? Thank you for any input! Ning - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] NGen and uninstalling
Ok, I followed up on this and having files left behind after uninstall when an managed app is using it is a known issue with ngen.exe itself. While the images still appear to be there, they will not be loaded so in effect they are deleted from the cache but the file still exists on disk. I know this isn't quite the answer you were hoping for but at least we know its not an installer/CA problem. Its in ngen itself and the way it manages its state. From: Doug Payne Sent: Wednesday, October 10, 2007 10:06 AM To: Peter Marcu; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Thanks for your response, Peter, The images are not removed after reboot. I did notice one odd thing, though, after initial install and reboot, THE IMAGES (*.NI.* FILES) WERE IN THE Native Image folder, but ngen reported their status as pending, even though I specified Priority=0 for all the assemblies in the .wxs file. I ran 'ngen update', which fixed this problem, but the images were still not removed from the cache during uninstall if the dependent applications were running. --Doug From: Peter Marcu Sent: Wednesday, October 10, 2007 9:37 AM To: Doug Payne; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Hi Doug, Can you verify for me whether or not the images are removed after a reboot? My suspicion is that because the file is in use, the OS cant remove it and schedules a Pending File Rename Operation on the file which will be executed on a reboot. If they are not removed on reboot, let me know and I'll dig deeper. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Payne Sent: Tuesday, October 09, 2007 3:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] NGen and uninstalling Hello, I would like some help understanding how the native image element and related custom actions work in Wix 2.0. Specifically, I would like some advice on how to debug a problem I am seeing when uninstalling my product. I am using this element to add assemblies to the Native Image Cache during install, and remove them during uninstall. This works well unless one of the applications relying on these assemblies is running when the product is reinstalled or removed. In that case, even if Restart Manager is able to close the applications, the files sometimes remain in the Native Image folder after uninstall. From the verbose log, I see that the ExecNetFX CA fires, and ngen.exe is indeed called once for each assembly which is to be removed. (Unlike during the installation process, I do not see the actual command line being used for ngen.) I verified: * NetFxScheduleNativeImage is run after InstallValidate. Numerous 2715 errors are logged, indicating the specified file key could not be found in the file table. The second parameter for these messages, the file key itself is either blank or not logged. Regardless, the CA sets the NetFxExecuteNativeImageUninstal and NetFxExecuteNativeImageCommitUninstal propeties. It returns 1 * NetFxExecuteNativeImageCommitUninstall runs next, and returns 1. * NetFxExecuteNativeImageUninstall is skipped. * NetFxExecuteNativeImageCommitInstall runs next, and returns 1. * NetFxExecuteNativeImageInstall is skipped. * The NetFX custom action is then invoked, which appears to run NGen once for each assembly, presumably to uninstall the files from the cache. * The ExecNetFx CA then runs. I don't know what it does, but this is followed in the log by 40 lines of the form RollbackCleanup: File: C:\Config.Msi\4f516.rbf. I also tried using a custom actionw which shuts down the applications before Restart Manager sees them. This is to prevent the user from allowing the applications to run during uninstall. This did not help, as images remained in the cache after setup completed. Has anyone else seen this problem? If so, how did you handle it? Thanks for your time. --Doug - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] NGen and uninstalling
Sorry, no workarounds that I could see. From: Doug Payne Sent: Wednesday, October 10, 2007 11:50 AM To: Peter Marcu; wix-users@lists.sourceforge.net; Sumit Mehrotra Subject: RE: NGen and uninstalling Thanks, Peter. This is consistent with what I just discovered. I paused setup just after my custom action closed down all the running applications, then ran ngen manually on each asembly, in the same order as setup. 'NGen display ...' reported each assembly had been removed, but with one exception, the *.ni.* files were left behind. Did you come across any workarounds during your research? Thanks very much for your assistance! --Doug From: Peter Marcu Sent: Wednesday, October 10, 2007 11:29 AM To: Doug Payne; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Ok, I followed up on this and having files left behind after uninstall when an managed app is using it is a known issue with ngen.exe itself. While the images still appear to be there, they will not be loaded so in effect they are deleted from the cache but the file still exists on disk. I know this isn't quite the answer you were hoping for but at least we know its not an installer/CA problem. Its in ngen itself and the way it manages its state. From: Doug Payne Sent: Wednesday, October 10, 2007 10:06 AM To: Peter Marcu; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Thanks for your response, Peter, The images are not removed after reboot. I did notice one odd thing, though, after initial install and reboot, THE IMAGES (*.NI.* FILES) WERE IN THE Native Image folder, but ngen reported their status as pending, even though I specified Priority=0 for all the assemblies in the .wxs file. I ran 'ngen update', which fixed this problem, but the images were still not removed from the cache during uninstall if the dependent applications were running. --Doug From: Peter Marcu Sent: Wednesday, October 10, 2007 9:37 AM To: Doug Payne; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Hi Doug, Can you verify for me whether or not the images are removed after a reboot? My suspicion is that because the file is in use, the OS cant remove it and schedules a Pending File Rename Operation on the file which will be executed on a reboot. If they are not removed on reboot, let me know and I'll dig deeper. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Payne Sent: Tuesday, October 09, 2007 3:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] NGen and uninstalling Hello, I would like some help understanding how the native image element and related custom actions work in Wix 2.0. Specifically, I would like some advice on how to debug a problem I am seeing when uninstalling my product. I am using this element to add assemblies to the Native Image Cache during install, and remove them during uninstall. This works well unless one of the applications relying on these assemblies is running when the product is reinstalled or removed. In that case, even if Restart Manager is able to close the applications, the files sometimes remain in the Native Image folder after uninstall. From the verbose log, I see that the ExecNetFX CA fires, and ngen.exe is indeed called once for each assembly which is to be removed. (Unlike during the installation process, I do not see the actual command line being used for ngen.) I verified: * NetFxScheduleNativeImage is run after InstallValidate. Numerous 2715 errors are logged, indicating the specified file key could not be found in the file table. The second parameter for these messages, the file key itself is either blank or not logged. Regardless, the CA sets the NetFxExecuteNativeImageUninstal and NetFxExecuteNativeImageCommitUninstal propeties. It returns 1 * NetFxExecuteNativeImageCommitUninstall runs next, and returns 1. * NetFxExecuteNativeImageUninstall is skipped. * NetFxExecuteNativeImageCommitInstall runs next, and returns 1. * NetFxExecuteNativeImageInstall is skipped. * The NetFX custom action is then invoked, which appears to run NGen once for each assembly, presumably to uninstall the files from the cache. * The ExecNetFx CA then runs. I don't know what it does, but this is followed in the log by 40 lines of the form RollbackCleanup: File: C:\Config.Msi\4f516.rbf. I also tried using a custom actionw which shuts down the applications before Restart Manager sees them. This is to prevent the user from allowing the applications to run during uninstall. This did not help, as images remained in the cache after setup completed. Has anyone else seen this problem? If so, how did you handle it? Thanks for your time. --Doug - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your
Re: [WiX-users] Fw: Some STUPID Limitations in WiX
I appreciate the feedback.
Can you log bugs on sourgeforge for both issues you mentioned. I'm looking at
putting some significant time into fixing bugs in WiX over the next few months
and its easiest for me to track all of them if they are all logged on
sourceforge.
With bugs, you will also be able to track when the bug gets fixed.
From: Cristian N. Baiu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 03, 2007 8:19 PM
To: Peter Marcu
Cc: wix-users@lists.sourceforge.net
Subject: Fw: [WiX-users] Fw: Some STUPID Limitations in WiX
Hello Peter,
Thanks again for your answers. Melt is great for me.
However, from what I have tested so far, I got stuck with it because of a bug
(I am using Wix 3.0.3307.0).
In the generated wxs, every Source attribute of the File element contents
the modularization guid in double -
like: SourceDir\File\MyFile.ext.MSM_GUID.MSM_GUID.
I have debuged my melt version (3.0.3307.0) and found the problem in
Decompiler::FinalizeFileTable.
When the the output type is Module I have
file.Source = String.Concat(SourceDir, Path.DirectorySeparatorChar, File,
Path.DirectorySeparatorChar, file.Id, '.', this.modularizationGuid.Substring(1,
36).Replace('-', '_'));
But the file.Id already contains the modularization GUID, so it would not be
necessary to append it again.
I will correct the problem and build my own melt, but I would also like to have
this problem corrected if possible in a future WIX release, so that I wouldn't
be forced to integrate and build it everytime I need to update my WIX version.
In addition, I must say I'm disappointed that melt hardcodes SourceDir in the
file source path instead of resolving it with the path provided through the -x
switch. Due to this, it cannot be used as it is in an automated build
process. I hope this would also be fixed someday.
Thanks a lot,
Cristian.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] no tallow in wix 3.0
Tallow doesn't exist in WiX 3.0. Take a look at Heat. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sergei Shelukhin Sent: Tuesday, October 02, 2007 8:36 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] no tallow in wix 3.0 Hi. How come there's no tallow utility in Wix 3.0 binaries? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fw: Some STUPID Limitations in WiX
You should be able to pass transforms generated from wixpdb's in combination with ones generated from admin images. You will need a transform passed to torch for each product you want to target because product code information is important and I assume each language you ship has a different product code. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Tuesday, October 02, 2007 9:07 AM To: Cristian Baiu Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX Cristian Baiu wrote: So far I don't know how to instruct pyro to address my patch to all MSIs unless I make differences for all of them and pass all these difference sets to pyro. Can you please advice me if it's possible to target multiple MSIs with only one set of differences and how ? You'll need to use Torch's -ax switch to use admin images. I'm not sure how well that works to create one patch that also targets products using .wixpdbs. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fw: Some STUPID Limitations in WiX
I meant pyro when I said torch below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Marcu Sent: Tuesday, October 02, 2007 10:15 AM To: Bob Arnson; Cristian Baiu Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX You should be able to pass transforms generated from wixpdb's in combination with ones generated from admin images. You will need a transform passed to torch for each product you want to target because product code information is important and I assume each language you ship has a different product code. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Tuesday, October 02, 2007 9:07 AM To: Cristian Baiu Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX Cristian Baiu wrote: So far I don't know how to instruct pyro to address my patch to all MSIs unless I make differences for all of them and pass all these difference sets to pyro. Can you please advice me if it's possible to target multiple MSIs with only one set of differences and how ? You'll need to use Torch's -ax switch to use admin images. I'm not sure how well that works to create one patch that also targets products using .wixpdbs. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fw: Some STUPID Limitations in WiX
The problem you are hitting is that the Wixpdb contains no information about msm's they are merged in after the fact. Three options: 1. Instead of using the wixpdb, just use the admin image functionality I added in order to create transforms for the products that contain msm's. 2. Use Melt.exe to convert your msm into a componentgroup, then remove the msm from your authoring and add in the componentgroup. 3. Don't use MSM's. :) To answer your repair question, it depends on the flags that are passed to msi during the repair, by default the newest version wins. One way to solve the long build time is to consider a langpack model. Where all the files that aren't per language live together in a single msi. This would mean that if you are patching a language neutral component you only have to patch the core msi and not the langpacks. -Original Message- From: Cristian N. Baiu [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 02, 2007 11:18 AM To: Peter Marcu; [EMAIL PROTECTED]; Cristian Baiu Cc: wix-users@lists.sourceforge.net Subject: Fw: [WiX-users] Fw: Some STUPID Limitations in WiX Thanks Bob, thanks Peter for your answers. I will not have problems with the localizations. The only problem will be the time to generate a patch, because my setup takes a very long time to build - about 30 mins for each MSI and I have over 20 MSI's (12 languages * 2 - due to x86 and x64). Knowing that my patches (hot-fixes most of them) will patch only non-localizable files (practically will update versioned DLL files), I was hoping I could optimize the patch build process by building only two upgrade MSIs (one for x86 and x64) and then pass by some other means only the product codes for the other MSI's to pyro. I don't know if it would be a best practice but it would sure suite me. Anyway, in lack of alternatives, I will do all the differences. Still, the biggest of my problems is the patching of the MSM which I was talking earlier. I have done some testing, trying to patch a (versioned) dll which is part of my MSM using pyro but had no success. The patch log wasn't saying anything about my file. Then I have tried to build the patch removing all the physical occurences of the file which I needed to patch (the MSM and MSI target and upgrade versions being build at the testing time). I have removed the DLL from my deployment folder - from where the MSM setup resolves it, I have removed the MSM from the folder used by the MSI which includes the MSM, I have removed the upgrade MSI's cabinet from the folder where torch is using it's upgrade wixpdb input file. Then I have build the patch and had no errors. This makes me think that neither torch, candle, light or pyro are even trying to do something with that file. (The reason for all of these was my hope to find out which of them needs to resolve the file and then try to debug it and understand what I've done wrong). Peter, you said in an earlier post that you could provide some workarounds for patching MSMs. It seems I have reached the moment when I need very bad to know them. Could you help me please ? Also Bob said earlier: It will update the shared component but it won't update the other product, so a repair operation can undo the patch. That's why merge modules are falling way out of favor... (refering to a patch for an MSM component which targets only one of more products containing the MSM). These are bad news. I do not know how installer performs the repair so my question is : does the repair replace a newer version of the shared file with an older one if the file is versioned correctly ? Thanks for your answers. I hope I was not too boring with my long story. Cristian. - Original Message - From: Peter Marcu [EMAIL PROTECTED] To: Peter Marcu [EMAIL PROTECTED]; Bob Arnson [EMAIL PROTECTED]; Cristian Baiu [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Tuesday, October 02, 2007 8:24 PM Subject: RE: [WiX-users] Fw: Some STUPID Limitations in WiX I meant pyro when I said torch below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Marcu Sent: Tuesday, October 02, 2007 10:15 AM To: Bob Arnson; Cristian Baiu Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX You should be able to pass transforms generated from wixpdb's in combination with ones generated from admin images. You will need a transform passed to torch for each product you want to target because product code information is important and I assume each language you ship has a different product code. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Tuesday, October 02, 2007 9:07 AM To: Cristian Baiu Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Fw: Some STUPID Limitations in WiX Cristian Baiu wrote: So far I don't know how to instruct pyro to address my patch to all MSIs unless I make differences for all
Re: [WiX-users] Release 3.0.3328.0 Assemblies won't bind
Apparently wix.dll was strong named with a different public key this time around while all the other tools are using the correct one. We are looking what caused the problem and will get a fix and release a new build once its fixed. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Lavelle Sent: Tuesday, October 02, 2007 7:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Release 3.0.3328.0 Assemblies won't bind Hi, I get the following error when running the Candle.exe in the WiX Release 3.0.3328.0 : Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'wix, Version=3.0.3328.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'wix, Version=3.0.3328.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad' I suspect it's caused by the recent Strong Name changes made by PMarcu, because Release 3.0.3307.0 doesn't give any such problems, and the candle.exe.config in that file has significantly less in it. Or I could be completely wrong... Please advise if you want a bug raised. Regards Martin. _ The information contained in this message, together with any attachments, may be legally privileged or confidential and is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify us immediately before deleting it. This message has been checked for all known viruses through MessageLabs Virus Control Centre, for and on behalf of the AVEVA Group. Although no viruses were found it is the recipient's responsibility to ensure that this message is safe for use on their system. AVEVA Group plc is a Public Limited Company registered in England with registered number 2937296. The registered office of AVEVA Group plc is High Cross, Madingley Road, Cambridge, England CB3 0HB - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ICE03 error from light
The error is saying that the DllPath column of the ComPlusAssembly table has a
value of LAPComPlusAssembly. This is a foreign key and therefore needs to be
present in the table has the corresponding primary key. Make sure that
LAPComPlusAssembly is defined as a Primary key somewhere else in your msi. I
cant see the code right now to tell you exactly which table needs to have that
Primary key defined.
Also, -sice:03 should suppress ice03 from being run. If it doesn’t, that’s a
bug that we should fix.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of daveog
Sent: Monday, October 01, 2007 8:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ICE03 error from light
Hi all,
I am seeing the following error from the linking phase:
error LGHT0204 : ICE03: Not a valid foreign key; Table: ComPlusAssembly,
Column: DllPath, Key(s): LAPComPlusAssembly
Binder temporary directory located at 'C:\Documents and
Settings\dogborne\Local Settings\Temp\1lro9s9v'.
Validator temporary directory located at 'C:\Documents and
Settings\dogborne\Local Settings\Temp\7zjin2ut'.
using the following link command:
light -ext wixcomplusextension -cultures:en-us
letterproductioninstall.wixobj keywordrestrict.wixobj -out
keywordrestrict.msi
Microsoft (R) Windows Installer Xml Linker version 3.0.3328.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.
I have tried using the -notidy and -sice switches but the error is still
produced!
A resulting msi is produced but when I run it I get the following msi
errors:
MSI (s) (78:20) [16:10:46:725]: The call to SRSetRestorePoint API failed.
Returned status: 0. GetLastError() returned: 127
and further down the log file ...
MSI (s) (78:20) [16:10:48:157]: Executing op:
CustomActionSchedule(Action=ComPlusRollbackInstallExecute,ActionType=3329,Source=BinaryData,Target=ComPlusRollbackInstallExecute,CustomActionData=C:\DOCUME~1\dogborne\LOCALS~1\Temp\CPI63E1E26B.tmpCreateSubscriptionsComPlusComponentsCreating
subscriptions for COM+ componentsSubscription:
[1]0AddComPlusRoleAssignmentsAssigning roles to COM+
componentsComponent: [1]0RegisterComPlusAssembliesRegistering COM+
componentsDLL:
[1]125LAPComPlusAssembly0{DA3AA263-8D65-4466-A610-2A6E45CC4B9F}5{D419CE6F-42D6-45D1-B451-6E66F40D2FD9}000{80E7D5F7-28E8-4180-8C65-5C90C606EB33}000{52DCCE25-40DF-4DEF-AF33-1279DC230C0E}000{24538838-CC96-4F50-89D8-DC5CE1E6FB52}000{0B737682-CC88-472F-AE9B-A39DE0B982AC}000AddUsersToComPlusApplicationRolesAdding
users to COM+ application rolesUser:
[1]0CreateComPlusApplicationRolesCreating COM+ application rolesRole:
[1]0CreateComPlusApplicationsCreating COM+ applicationsApplication:
[1]121CISSLAPDLLCOMPLUS{DA3AA263-8D65-4466-A610-2A6E45CC4B9F}Letter
And Phrase
MSI (s) (78:20) [16:10:48:157]: Executing op:
ActionStart(Name=ComPlusInstallExecute,Description=Registering COM+
components,)
MSI (s) (78:20) [16:10:48:157]: Executing op:
CustomActionSchedule(Action=ComPlusInstallExecute,ActionType=3073,Source=BinaryData,Target=ComPlusInstallExecute,CustomActionData=C:\DOCUME~1\dogborne\LOCALS~1\Temp\CPI63E1E26B.tmpCreateComPlusPartitionsCreating
COM+ partitionsPartition: [1]0AddUsersToComPlusPartitionRolesAdding
users to COM+ partition rolesRole: [1]0AddComPlusPartitionUsersSetting
default COM+ partitions for usersUser:
[1]0CreateComPlusApplicationsCreating COM+ applicationsApplication:
[1]111CISSLAPDLLCOMPLUS{DA3AA263-8D65-4466-A610-2A6E45CC4B9F}Letter
And Phrase0CreateComPlusApplicationRolesCreating COM+ application
rolesRole: [1]0AddUsersToComPlusApplicationRolesAdding users to COM+
application rolesUser: [1]0RegisterComPlusAssembliesRegistering COM+
componentsDLL:
[1]115LAPComPlusAssembly0{DA3AA263-8D65-4466-A610-2A6E45CC4B9F}5{D419CE6F-42D6-45D1-B451-6E66F40D2FD9}1Transaction100{80E7D5F7-28E8-4180-8C65-5C90C606EB33}1Transaction100{52DCCE25-40DF-4DEF-AF33-1279DC230C0E}1Transaction100{24538838-CC
MSI (s) (78:60) [16:10:48:167]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI18.tmp, Entrypoint: ComPlusInstallExecute
ComPlusInstallExecute: Error 0x80070057: Failed to install components
ComPlusInstallExecute: Error 0x80070057: Failed to register native assembly
ComPlusInstallExecute: Error 0x80070057: Failed to register assembly, key:
LAPComPlusAssembly
ComPlusInstallExecute: Error 0x80070057: Failed to register assemblies
Action ended 16:10:48: InstallFinalize. Return value 3.
MSI (s) (78:20) [16:10:48:728]: User policy value 'DisableRollback' is 0
MSI (s) (78:20) [16:10:48:728]: Machine policy value 'DisableRollback' is 0
Does anyone have any ideas as to the problem?
Any help would be appreciated .
Thanks,
Dave
--
View this message in context:
http://www.nabble.com/ICE03-error-from-light-tf4549092.html#a12981539
Sent from the wix-users mailing list archive at Nabble.com.
Re: [WiX-users] Some STUPID Limitations in WiX
If you need to get an msm from someone because they don't use WiX, that makes sense. If you're msi is the only one consuming those msm's you wont hit the major problem of servicing msm's which is, you don't know all of the various places it was consumed and therefore you don't know all the products to ship patches for. If you are using WiX v3 and want to take advantage of the Patch building system, changes to msm's wont show up in your patches. I can give workarounds for that scenario if you have it so let me know. If you use patchwiz to generate you patches everything should work. The major benefit of the Patch system in WiX is the ability to filter only the changes you want into a patch. PatchWiz doesn't allow you to do this. The only other major limitation is the one Dong pointed out which is that things in an MSM are not referencable from you WiX authoring. If you've broken things apart such that you don't need to reference stuff in the MSM then you should be ok here. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cristian Baiu Sent: Tuesday, September 25, 2007 11:20 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Some STUPID Limitations in WiX Hello Peter, Hello everybody, Peter, you said: For #2. Use libraries instead of modules. My advice is to produce modules only if you are shipping them for consumption in a setup you have no control over. They have additional limitations when you get into patching that make them hard to service. WiX supports msm's because Windows installer supports them but I would only recommend using them as a last resort :) Dont use them to share setup logic within your own system. Take advantage of the linker to separate things into smaller projects and pull it all together in the end. Can you explain a little more what are the problems involving patches and MSMs ? I am extremely worried because in our company we have more products which share a big module. We decided to implement the installation the shared part as an MSM created with WIX (which installs files, writes registries, registers COM and permorms some extremly necessary custom actions). These decision was made because the setups for our products are done by different teams (not all of these teams using WIX), so we didn't want to share this installation as library but rather MSM (we decided one team creates the MSM and maintains it and other teams just use it). As I am part of the team which handles the MSM, I'm very woried to hear that I will probably have problems to patch it, so I would like to know what my problems could be in order to know how to avoid these problems. Many thanks. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Some STUPID Limitations in WiX
For #1. FileSearch, RegistrySearch, and DirectorySearch search are part of core Windows Installer functionality. This is why WiX has those contructs in the language and not the others. For #2. Use libraries instead of modules. My advice is to produce modules only if you are shipping them for consumption in a setup you have no control over. They have additional limitations when you get into patching that make them hard to service. WiX supports msm's because Windows installer supports them but I would only recommend using them as a last resort :) Dont use them to share setup logic within your own system. Take advantage of the linker to separate things into smaller projects and pull it all together in the end. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dong Fang Xie (Excell Data Corporation) Sent: Tuesday, September 25, 2007 2:29 PM To: Justin Rockwood; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Some STUPID Limitations in WiX Justin, Thank you for your advice. I'll improve my attitude towards WiX and Windows Installer. BTW, you didn't answer my question. How to break those limitations ? Thanks, DongFang -Original Message- From: Justin Rockwood [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 25, 2007 2:22 PM To: Dong Fang Xie (Excell Data Corporation); wix-users@lists.sourceforge.net Subject: RE: Some STUPID Limitations in WiX Hey, Dong, thanks for the laugh! :) While we appreciate feedback on the WiX toolset, it's typically not a good idea to call it STUPID and then in the same sentence ask for help. You're biting the hand that feeds you. Plus if you think it's stupid then why would you trust the advice from the people that created it? At any rate, good luck with your powerful installer. Since we don't really know how to build those (smile), you may want to take any advice we give with a grain of salt. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dong Fang Xie (Excell Data Corporation) Sent: Tuesday, September 25, 2007 12:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Some STUPID Limitations in WiX I'm working on a small and simple installer using WiX toolset (the latest stable version 2.0.3719.0). To my surprise, it is really very very tough !! It almost drove me crazy. I really don't understand why there are so many stupid limitations: LIMIT 1: Since FileSearch, DirectorySearch, RegistrySearch are WiX elements, Why there is no ProcessSearch or TaskSearch ?!I need to know whether a specific process is running before installation/uninstallation. LIMIT 2: If all files in a msi package are from different small projects, I can build a module for each small project, and create a main wxs file to merge all modules. It should be a good idea, but how can I use the files from different modules ? There is no way for now. I must control all custom actions in the main wxs file, and some custom actions need a FileKey to a file in a module. I cannot distribute all cutom actions in different modules, if I do so, how can I control the InstallSequence ? Using stupid numbers? LIMIT 3: I defined a dialog which must be shown not only during installation but also during uninstallation. But how to make it shown during uninstallation ? the UILevel will be set to basic UI or no UI automatically by msiexec.exe. How can I beg Windows NOT do that for me? I can use command msiexec /qf /x msifile, but how can I know my customer can do that each time they want to uninstall the msi file ? Is there any way I can define UILevel of uninstallation inside msi file ? WiX is a very good toolset, but far from perfect ! I bet the developers of WiX toolset have never built a powerful installer for customers. I will never know the limit if I wasn't assigned the job to build a small and simple installer. I noticed that there are some extensions in WiX 3.0, but it is still far from enough. For LIMIT 1, I've built my own dll to detect running processes. But how to break LIMIT 2 and LIMIT 3 ? Can you guys give me some ideas ? Thanks in advance - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Deploying the MSI
On your Media element add a cabinet attribute and an EmbedCab='yes' attribute. That should do it. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jessi Darling Sent: Tuesday, September 25, 2007 2:08 PM To: wix-users Subject: [WiX-users] Deploying the MSI Is there a way that I can deploy the msi file only? When I try to copy and paste the msi file only, a window pops up that the files cannot be found. Is there a way around this, where the msi file creates the files that you need without them having to be present in the folder the msi is run from? -- Jessica Darling - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] can we merge an msi same as we merge msm to create new msi ? eom
No. If you want to install the contents of multiple msi's you will need a chainer/bootstrapper. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of shambhu kumar Sent: Sunday, September 16, 2007 8:58 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] can we merge an msi same as we merge msm to create new msi ? eom plz reply asap. -- View this message in context: http://www.nabble.com/can-we-merge-an-msi-same-as-we-merge-msm-to-create-new-msi---%3Ceom%3E-tf4464158.html#a12729012 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Executing embedded MSI's
It will fail with error code 1618 Another installation is already in progress. Complete that installation before proceeding with this install. Why do you need to run the msi nested? Could you run one msi and then the other? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dix, John Sent: Tuesday, August 21, 2007 10:42 PM To: Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Executing embedded MSI's So is there a way around this? Creating a CustomAction in a DLL I write that spawns the msiexec application against the MSI's maybe? From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Tue 8/21/2007 10:24 PM To: Dix, John Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Executing embedded MSI's Dix, John wrote: It copies the file but I am not sure how then to execute it. I would rather execute the file than copy it. My previous installer experience is with InstallShield 11.5 and event hen it wasn't a lot of customization. Would it help greatly to learn MSI parallel to WiX? Or is learning the WiX environment sufficient? You definitely need to know MSI -- WiX concepts are almost direct mappings to MSI functionality (except the custom actions, which are all WiX-specific). In this case, MSI no longer supports nested installations so there's nothing WiX can do. A bootstrapper is in development, to allow you to chain multiple MSIs together. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] KeyPath problem
When no keypath is specified, it uses the first resource in the component. In
your case it was the first file. In order to remove that file you need to
remove the entire component. Note, that if you remove a component, you have to
remove the entire feature. Removing a keypath file using a patch can be very
tricky...
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrice Lamarche
Sent: Wednesday, August 08, 2007 8:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] KeyPath problem
Hello,
I'm working with a patch. I receive this error
D:\Disk_X\Setup1.wxs(23) : error PYRO0243 : Component
'comment_protect_once.pl_1' has a changed keypath
. Patches cannot change the keypath of a component.
Here my wxs
Component Id=comment_protect_once.pl_1
Guid={C7F7628E-A9A8-4498-88A2-07183672E8EE}
File Id=comment_protect_once.pl_1 Name=comment-protect-once.pl
Source=x:\Versions\0.0.0\Tools\Scripts\Refactoring\comment-protect-once.pl /
File Id=remove_protect_once.pl_1 Name=remove-protect-once.pl Source=
x:\Versions\0.0.0\\Tools\Scripts\Refactoring\remove-protect-once.pl /
File Id=rewrite_protect_once.pl_1 Name=rewrite-protect-once.pl Source=
x:\Versions\0.0.0\\Tools\Scripts\Refactoring\rewrite-protect-once.pl /
File Id=set_namespace.pl_1 Name=set-namespace.pl Source=
x:\Versions\0.0.0\\Tools\Scripts\Refactoring\set-namespace.pl /
File Id=update_ubinew.pl_1 Name=update-ubinew.pl Source=
x:\Versions\0.0.0\\Tools\Scripts\Refactoring\update-ubinew.pl /
/Component
Component Id=comment_protect_once.pl_1
Guid={C7F7628E-A9A8-4498-88A2-07183672E8EE}
RemoveFile Id=comment_protect_once.pl_1 On=install
Name=comment-protect-once.pl /
File Id=remove_protect_once.pl_1 Name=remove-protect-once.pl Source
x:\Versions\0.0.1\Tools\Scripts\Refactoring\remove-protect-once.pl /
File Id=rewrite_protect_once.pl_1 Name=rewrite-protect-once.pl Source=
x:\Versions\0.0.1\Tools\Scripts\Refactoring\rewrite-protect-once.pl /
File Id=set_namespace.pl_1 Name=set-namespace.pl Source=
x:\Versions\0.0.1\Tools\Scripts\Refactoring\set-namespace.pl /
File Id=update_ubinew.pl_1 Name=update-ubinew.pl Source=
x:\Versions\0.0.1\Tools\Scripts\Refactoring\update-ubinew.pl /
/Component
I tried with keypath=false every where to and still have the problem. I thought
when no keypath where specified, it use the directory.
Thanks
Best Regards,
Patrice Lamarche
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Goodbye fragmentref - how to replace?
My recommendation would be to either put this authoring as a child of your Product element or use a wxi (wix include) to pull it in from an external file. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Tavares Sent: Tuesday, August 07, 2007 1:35 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Goodbye fragmentref - how to replace? I have the following fragment in my WiX 2 installer: ?xml version=1.0 encoding=utf-8? Wix xmlns='http://schemas.microsoft.com/wix/2003/01/wi' Fragment Id='NoRegisterSequenceFragment' InstallExecuteSequence RegisterProduct Suppress=yes / RegisterUser Suppress=yes / PublishProduct Suppress=yes / PublishFeatures Suppress=yes / /InstallExecuteSequence AdvertiseExecuteSequence PublishProduct Suppress=yes / PublishFeatures Suppress=yes / /AdvertiseExecuteSequence /Fragment /Wix In my main .wxs file, I used a FragmentRef to pull in these sequences. That won't work, of course, on WiX 3. So what do I do? There's no InstallExecuteSequenceRef that I can find. Thanks for any suggestions, -Chris - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Preprocessor Directives
I don't think the preprocessor supports dots in the name of the variable. Try replacing them with underscores or something and see how that goes. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hall Sent: Friday, July 27, 2007 12:58 AM To: Quattro IV Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Preprocessor Directives Where can I find the current list of preprocessor directives? I'm using the list from this article, http://msdn2.microsoft.com/en-us/library/aa302186.aspx#wixsetup_topic6 But I'm getting compilation errors in VS when using the ProjectAggregator2-3.0.2925.0.msi. Thanks Example error: Error 1 Undefined preprocessor variable '$(var.DNA.RadWorkflow.TabletWorklist.TargetPath)'. C:\RWFSystem\DNA.RadWorkflow\DNA.RadWorkflow.TabletWorklist\Application.TabletWorklist\Installer\TabletWorklist.wxs 19 1 TabletWorklist There is a wix.chm help file that gets installed in the doc directory. Under Tools in the contents is a section on the preprocessor. Is 'DNA.RadWorkflow.TabletWorklist.TargetPath' perhaps a WixVariable rather than a preprocessor variable? How is it defined? Regards, John - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
Unfortunately, removing a file via a patch is not as easy as that. Windows
Installer requires that if a component is removed, the feature containing it be
removed so you probably don't want to do that. You need to author a RemoveFile
element to remove the file in your component. This will remove the file for you
but you should leave the component.
As for your patch taking a long time. Try using PatchFamily elements to limit
the number of components you want to consider in your patch. Also, if you want
to get deeper into WiX, you can implement a Binder extension that will allow
you to dictate how files are compared when deciding what files to include in
your patch.
Another side note: Windows Installer has a limit of 1600 components tied to any
one feature. I don't know what the side effects are of this but if you have
16,000 files, each with their own component, and they are all tied to the same
feature, you may run into some problems...
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Collins, James
Sent: Thursday, July 19, 2007 11:03 AM
To: Patrice Lamarche; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
My understanding is that if your removing a file then just remove the whole
component all together and when you upgrade MSI will realize the component no
longer exists and remove the file for you.
So you would start with
Component Id=bla.build_1 Guid={6CB5A96B-2470-4F61-A237-8B8FC9853BCC}
File Id=bla.build_1 Name=bla.build KeyPath=yes
Source=x:\Data\bla.build DiskId=1 /
/Component
And change it to...
Empty string.
But as I said I'm no expert on the component rules. J
Jimbo
From: Patrice Lamarche [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 10:57 AM
To: Collins, James; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
Hello,
First, thanks for the reply. No I'm not using heat, I'll look. I'm
currently generating my GUIDS with a perl script for the 1st install and we
planned to create a program that will create the RemoveFile entry for deleted
files, add the new files. I downloaded a weekly build from the website and it
resolved my pyro problem. I can now generate patch with the files I manually
edited. I'll search for more info about a component catalog.
Just to be sure. If a file is deleted I need to change
Component Id=bla.build_1 Guid={6CB5A96B-2470-4F61-A237-8B8FC9853BCC}
File Id=bla.build_1 Name=bla.build KeyPath=yes
Source=x:\Data\bla.build DiskId=1 /
/Component
For
Component Id=bla.build_1 Guid={6CB5A96B-2470-4F61-A237-8B8FC9853BCC}
RemoveFile Id=bla.build_1 Name=bla.build KeyPath=yes
Source=x:\Data\bla.build DiskId=1 /
/Component
It's give me error about the keypath. I've read in the doc and I'm not sure
about what the keypath attribute does.
Thanks for your reactivity!
Best regards,
Patrice Lamarche
De : Collins, James [mailto:[EMAIL PROTECTED]
Envoyé : 19 juillet 2007 13:43
À : Patrice Lamarche; wix-users@lists.sourceforge.net
Objet : RE: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
Hey Patrice,
Have you tried using heat.exe ?? Since you have so many files you
might want to take a look at that. You point it to you folder and it writes out
the wxs file for you including all the reg keys for DLL's etc.
If order to build patch's and minor versions your going to need to
reconcile your GUIDS and ID. The tool you need I believe this community calls
it a component catalog, and as far as I'm aware it does not exist.
Unfortunately when you use heat it will not generate GUIDS and you
need to maintain them and the ID's yourself. Remember to not break any of the
component rules (whatever they are).
I have written what I think is a component catalog, however I don't
have enough knowledge to ensure all component rules are not broken so it's just
something I'm playing with at this point.
Jimbo
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrice Lamarche
Sent: Thursday, July 19, 2007 6:39 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] New to wix 3.0 ( 3.0.2925.0)
Hello everyone,
We are stating using WiX. I'm searching for some help about how to
structure our wxs file. We have a lot (more than 60K) files. The format we use
currently is one file per component and one feature containing all the
components. I have to build patch between minor version that remove, update and
add new files. Is there any best practices or suggestions?
I did some tests. I correctly generated a setup. I tried the patching system
with pyro. I based my Patch.wxs on the Peter Marcu's Blog sample. My sample did
work but it's took long time to generate the patch for only one file modified.
Pyro looks to do a binary compare on each file can we specify to check if the
file date
Re: [WiX-users] Patching Wix generated msis
You should also note that when doing patches, you need to add a removefile entry in order to remove files. For update/add you must update the keypath file of a component in order to see changes in the component during patching. Ideally, when adding new files, they are in their own component. Is this what you are currently doing? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Tuesday, June 05, 2007 8:27 AM To: Grant Wagner Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching Wix generated msis Grant Wagner wrote: Reciently, we have grown a need to starting patching our application in production. Using the technique at http://wix.sourceforge.net/manual-wix2/patch_building.htm seems to produce nice results until we starting adding or removing files. At which point it failes completely. New files are always added, removed files are never removed, and modified files are always left in their old revisions. It's important to note that we have a application which will scan our dynamic directories and add to the wix file all files and directories it finds, and I'm afraid that this is causing issues for us. If you're generating your IDs and GUIDs, then you won't realistically be able to create patches. See, for example, http://blogs.msdn.com/windows_installer_team/archive/2007/03/07/arbitrary-labels-used-as-primary-keys-must-not-be-changed-between-versions.aspx for why. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] problem with serviceconfig
The fix for this was submitted yesterday and should in the next published build. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Tuesday, June 05, 2007 1:06 PM To: 'koawmfot'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] problem with serviceconfig Oh, for reference: 0x8007065a is Win32 error (because 0x8007 represents FACILITY_WIN32 in an HRESULT) number 1626 (0x65a), which if you look in the Platform SDK header WinError.h is code ERROR_FUNCTION_NOT_CALLED. The documentation for MsiDoAction indicates that this means 'The action was not found.' From there I looked for the action in the .wxs file used to generate the .wixlib embedded in the WixUtilExtension extension DLL, and when I didn't find it, I went looking for the cause. -- Mike Dimmick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of koawmfot Sent: 05 June 2007 18:37 To: wix-users@lists.sourceforge.net Subject: [WiX-users] problem with serviceconfig using v3.0.2911.0 i had no problem with the WixUtilExtension and ServiceConfig element. I just installed v3.0.3001.0 and now my msi dies when it gets to SchedServiceConfig. below is the relevent MSI log file information: Action start 13:26:37: SchedServiceConfig. MSI (s) (10!38) [13:26:37:715]: Doing action: RollbackServiceConfig Action start 13:26:37: RollbackServiceConfig. Action ended 13:26:37: RollbackServiceConfig. Return value 0. SchedServiceConfig: Error 0x8007065a: Failed MsiDoAction on deferred action SchedServiceConfig: Error 0x8007065a: failed to schedule RollbackServiceConfig action MSI (s) (10:EC) [13:26:37:715]: Machine policy value 'DisableRollback' is 0 MSI (s) (10:EC) [13:26:37:715]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2 Action ended 13:26:37: SchedServiceConfig. Return value 3. I tried the different versions and recompiling the same code with any version from v3.0.2921 and higher does not work. Was something changed in the newer version of WixUtilExtension.dll that broke it? thanks doug - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Announcement: FragmentRefs are no longer supported in WiX 3.0
Hi All, I am send this email to let everyone using WiX 3.0 know that FragmentRef's will no longer be supported in WiX 3.0. After being deprecated for many months it is time to say goodbye. Every Fragment should have a child that is a referencable element using the supported Ref elements. Examples of these are ComponentRef, FeatureRef, PropertyRef, and CustomActionRef. If you are still using FragmentRef's in your authoring you can usually just replace the FragmentRef with the appropriate Ref element pertaining to the Fragment you are trying to reference. WixCop has been updated to error whenever it encounters a FragmentRef. Peter Marcu Software Development Engineer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
