[WiX-users] Accessing Regsitry Values from an Immediate Custom Action
Hello, I have a wix based installer that writes some registry values using the standard wix registry element a bit like: RegistryValue Action=write Type=string Root=HKMU Key=Software\Company\Key Name=KeyName Value=1/ Is it possible for me to be able to read these values from a *immediate* custom action? If so when do I need to schedule it? I've currently got an immediate custom action that is scheduled *after WriteRegistryValues* but it doesn't seem to be able to read the written entries: RegOpenKeyEx returns ERROR_FILE_NOT_FOUND when trying to open the relevant key with read access. Custom action xml is: CustomAction Id=MyCustomAction Impersonate=yes Return=ignore Execute=immediate BinaryKey=MyCustomActionDll DllEntry=MyCustomAction / and the sequencing is: InstallExecuteSequence Custom Action=MyCustomAction After=WriteRegistryValuesNOT Installed/Custom /InstallExecuteSequence *Other Notes* * In the example ALLUSERS is 1 so the registry values will end up in the HKEY_LOCAL_MACHINE key. * As a result of the above the installation is given elevated privileges. * I've got the custom action's impersonate value set to yes as there are various pieces of user information I want to access from the CA. AFAIK this shouldn't be an issue as long as I only want to *read* keys from HKEY_LOCAL_MACHINE, which is the case. Any modification happens in the HKEY_CURRENT_USER key. *Environment* * Compiled using Wix v3.5 * Installing on a Windows 7 Enterprise (SP1) machine -- Liam -- 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] Accessing Regsitry Values from an Immediate CustomAction
Peter, That worked perfectly =) I thought I'd tried this at some point whilst debugging but clearly I was mistaken... Thanks, Liam On 30/04/2012 11:53, Peter Shirtcliffe wrote: It can be immediate if you schedule it after InstallFinalize. -Original Message- From: Liam Flanagan [mailto:l...@dyalog.com] Sent: Monday, April 30, 2012 9:04 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Accessing Regsitry Values from an Immediate CustomAction Hello, I have a wix based installer that writes some registry values using the standard wix registry element a bit like: RegistryValue Action=write Type=string Root=HKMU Key=Software\Company\Key Name=KeyName Value=1/ Is it possible for me to be able to read these values from a *immediate* custom action? If so when do I need to schedule it? I've currently got an immediate custom action that is scheduled *after WriteRegistryValues* but it doesn't seem to be able to read the written entries: RegOpenKeyEx returns ERROR_FILE_NOT_FOUND when trying to open the relevant key with read access. Custom action xml is: CustomAction Id=MyCustomAction Impersonate=yes Return=ignore Execute=immediate BinaryKey=MyCustomActionDll DllEntry=MyCustomAction / and the sequencing is: InstallExecuteSequence Custom Action=MyCustomAction After=WriteRegistryValuesNOT Installed/Custom /InstallExecuteSequence *Other Notes* * In the example ALLUSERS is 1 so the registry values will end up in the HKEY_LOCAL_MACHINE key. * As a result of the above the installation is given elevated privileges. * I've got the custom action's impersonate value set to yes as there are various pieces of user information I want to access from the CA. AFAIK this shouldn't be an issue as long as I only want to *read* keys from HKEY_LOCAL_MACHINE, which is the case. Any modification happens in the HKEY_CURRENT_USER key. *Environment* * Compiled using Wix v3.5 * Installing on a Windows 7 Enterprise (SP1) machine -- Liam - - 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 SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- 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] How to manage the following build process?
Unless I'm mistaken you'd need to create a different MSI for each customer... You could automate the process of building the MSIs via command line scripts and use preprocessor / environment variables to have the build process determine which logos, licence agreement and help / config files to package into the MSI. Language support could be done via the standard Wix UI localisation support (there are plenty of tutorials) - example http://wix.tramontana.co.hu/tutorial/localization Hope that helps. Liam On 08/09/2011 11:57, Michael Tissington wrote: I'm needing help trying to build an automated process for the following. 1) Each customer has many clients 2) Same binaries 3) Support for multiple languages 4) msi needs to be branded with customers logos and license agreement 5) Some help files and configuration files are specific to each customer I need to be able to support major upgrades and patches. Do I need to create an msi for each customer or can I build a single generic msi and then maybe apply a transform for each customer? How would I manage the need for different languages? Any ideas how best to create a build process for this. -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom Action Not Running In XP 32-Bit
Hello, I have a custom action function written in C that is called from a Wix MSI. This custom action runs successfully on Windows 7 (32-bit 64-bit), Vista (32-bit 64-bit) and Windows XP 64-bit however appears to simply not run on Windows XP 32-bit. The underlying issue here was that code within the dll for this custom action (not specifically code called or accessed from the entry point into the dll within the wix) referenced a call to the WinAPI RegDeleteKeyEx function which is unsupported in XP 32-bit. Now my question here is simply is there some way I could have been informed about why this dll wasn't loading let alone running from the install? For your information: . As this was a custom action that failed to load the installer continued happily without kicking up any fuss to the user . I ran the msi with /l*vx and I couldn't find anything within the log file that suggested the dll hadn't even been loaded, in fact you even get a message in the log file stating that the InstallIME (the wix) action ending with a return value of 1. See below an extract from the log for a install where the custom action failed to load: MSI (s) (2C:2C) [15:25:11:617]: Doing action: InstallIME Action 15:25:11: InstallIME. Action start 15:25:11: InstallIME. InstallIME: Action ended 15:25:11: InstallIME. Return value 1. . Just to remind you the problematic code that used RegDeleteKeyEx wasn't even called / referenced by InstallIME32 therefore it clearly just didn't want to load the dll at all In the end I managed to solve the issue through trial and error but I'm convinced there must be a more pragmatic (and hopefully quicker) approach, even if it is simply getting a warning that the custom action dll has not loaded. Thanks, Liam -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching Using Purely Wix
Peter, Thanks you for your reply. This does seem very promising; I'll let you know how we get on with it. Cheers, Liam -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 17 February 2011 10:55 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching Using Purely Wix Would creating a pure Wix patch from administrative installations work for you ? It's what we do here. This gives you an idea of the process. http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-you-did n t-build-with-wix-using-wix-.aspx -Original Message- From: Liam Flanagan [mailto:l...@dyalog.com] Sent: 16 February 2011 12:46 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching Using Purely Wix Hello All, I've been wondering if it's possible to create minor patches using the purely wix method, however only using the baseline and QFE MSI packages instead of requiring the original source files and structure that the MSIs were built from. I want have the benefits of purely wix patching (i.e. referencing wix components etc) however not the complexity of having build output snapshots that have a large quantities of files and file structures, instead simply the released MSIs. The table in this msdn blog ( http://blogs.msdn.com/b/heaths/archive/2010/08/24/comparison-of-patchwiz-and -wix-v3-patch-build.aspx ) implies that these should be possible; although I guess not all at the same time. (CF: ticks in the Ignore certain other resource types to be upgraded by the patch (ex: registry values, components, etc.) and Can automatically extract compressed files when creating transforms. Boxes) A little background into what I've tried so far: . Using the wixpdb files with torch to create the transform between the two versions appears to require the original msi build structure when creating the patch . Using torch on the msi files as standard appears to create a binary mst file, I presume this is for use with PatchWiz as Wix tools don't seem to like this at all . If whilst using torch on the msi files you specify you want an xml output (wixout) you appear to get a file very similar to that of the output when using torch on the wixpdb files, however you appear to lose all information about wix structures (wix components/component groups etc). Therefore if I try to specify them in the patch.wxs, pyro doesn't understand what differences you're actually trying to bring through in the patch. Furthermore on this, this fairly dated blog post ( http://blogs.msdn.com/b/pmarcu/archive/2007/04/27/building-a-patch-using-wix -v3-0.aspx ) implies that when creating the original msi files creating an interim wixmsi and using light to convert that into an MSI rather than just lighting the wixobj may change the game a bit; however I couldn't get this to work. The produced MSI files whilst having different md5sums appeared identical in Orca and furthermore produced identical wixout files via torch. Is what I'm hoping for achievable? Thanks, Liam - - The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel
[WiX-users] Viewing a wixmst file
Hello All, Is there any way to view a wixmst file created via torch in the following manner: torch -xi -xo RTM.wixpdb QFE.wixpdb -out diff.wixmst I was under the impression that the output file should be a xml; however I appear to get a lot of excess at the top of the file which appears to be binary output. Is this normal? Thanks, Liam -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching Using Purely Wix
Hello All, I've been wondering if it's possible to create minor patches using the purely wix method, however only using the baseline and QFE MSI packages instead of requiring the original source files and structure that the MSIs were built from. I want have the benefits of purely wix patching (i.e. referencing wix components etc) however not the complexity of having build output snapshots that have a large quantities of files and file structures, instead simply the released MSIs. The table in this msdn blog ( http://blogs.msdn.com/b/heaths/archive/2010/08/24/comparison-of-patchwiz-and -wix-v3-patch-build.aspx ) implies that these should be possible; although I guess not all at the same time. (CF: ticks in the Ignore certain other resource types to be upgraded by the patch (ex: registry values, components, etc.) and Can automatically extract compressed files when creating transforms. Boxes) A little background into what I've tried so far: . Using the wixpdb files with torch to create the transform between the two versions appears to require the original msi build structure when creating the patch . Using torch on the msi files as standard appears to create a binary mst file, I presume this is for use with PatchWiz as Wix tools don't seem to like this at all . If whilst using torch on the msi files you specify you want an xml output (wixout) you appear to get a file very similar to that of the output when using torch on the wixpdb files, however you appear to lose all information about wix structures (wix components/component groups etc). Therefore if I try to specify them in the patch.wxs, pyro doesn't understand what differences you're actually trying to bring through in the patch. Furthermore on this, this fairly dated blog post ( http://blogs.msdn.com/b/pmarcu/archive/2007/04/27/building-a-patch-using-wix -v3-0.aspx ) implies that when creating the original msi files creating an interim wixmsi and using light to convert that into an MSI rather than just lighting the wixobj may change the game a bit; however I couldn't get this to work. The produced MSI files whilst having different md5sums appeared identical in Orca and furthermore produced identical wixout files via torch. Is what I'm hoping for achievable? Thanks, Liam -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] 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
