[WiX-users] Removing myself from this list
I've tried to unsubscribe but it is not getting processed. Can someone help? Thanks, Jon -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setting ARPNOMODIFY fails on Change install
Greetings. I have run into a scenario where I want to disable the ability to run a Change install from Add/Remove Programs and the MaintenanceTypeDlg after all available Features have been installed. This works fine if all Features are selected during the initial install but if a single feature is selected and then the last feature installed with a Change install it fails. I have tried setting the ARPNOMODIFY property via Custom Actions set throughout the InstallExecuteSequence and InstallUISequence on its own, through a Publish event within the Dialog* in which the Features are selected, as well as even a custom action that uses C++ to add the NoModify DWORD value to the products UNINSTALL/Product GUID registry key. I have tried these methods along with having UAC enabled and disabled. *The Dialog I am using is a custom Feature selection dialog. The install sets up 1 to 2 web applications/sites along with allowing Application Name and Application Pool custom names to be specified. By using a custom dialog I reduced the need to have multiple dialogs to handle the above configuration. Another item I noted was that UAC prompts do not appear when I run a Change install from the MaintenanceTypeDlg. Can anyone offer some guidance here as I'm at my wits end on this one? Thanks so much. Regards, Jon -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Controls of Type RadioButtonGroup - Condition element must be last?
Greetings, I just wanted to share something interesting that I recently found. If one wishes to add a Condition element to a Control that is of a type RadioButtonGroup that Condition Element needs to be at the bottom or the last child element of the Control. If it is placed before the RadioButtonGroup element candle throws the following error, error CNDL0107 : Schema validation failed with the following error at line 1, column 1158: The element 'Control' in namespace 'http://schemas.microsoft.com/wix/2006/wi' has invalid child element 'RadioButtonGroup' in namespace 'http://schemas.microsoft.com/wix/2006/wi'. List of possible elements expected: 'Condition Publish Subscribe'. Is there a specific reason that the placement is crucial? Shouldn't the condition just be evaluated regardless of the child element? Thanks, Jon -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Does anyone have any experience with the Binder File Manager Extension?
I'll take a look at that. Thanks. I just need to shift when that is called from Candle time to Light time. I'm hoping that is an easy change. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, April 19, 2012 10:13 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Does anyone have any experience with the Binder File Manager Extension? Not a lot of documentation on extensions in general. There is the default Binder File Manager in light that might provide some guidance. On Wed, Apr 18, 2012 at 10:14 AM, McCain, Jon jon.mcc...@inin.com wrote: I need to move the functionality of one of our extensions from candle time to light time. Rob mentioned using the Binder File Manager extension but I can't seem to find any documentation on it. Any help is appreciated. Thanks, Jon W. McCain | Software Engineer - Install -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Does anyone have any experience with the Binder File Manager Extension?
I need to move the functionality of one of our extensions from candle time to light time. Rob mentioned using the Binder File Manager extension but I can't seem to find any documentation on it. Any help is appreciated. Thanks, Jon W. McCain | Software Engineer - Install -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Are compiler extensions available for Light as they are for candle?
Rob I am finally working on this and I am ready to move our candle based preprocessor extension into the Binder File Manager you spoke of but I can't seem to find any documentation outside of Binder Extensions referenced within wix.chm in Extension Types. I read up on these and I don't believe they match what I need but if you could point me to where the documentation exists for Binder File Manager I can check there before asking further questions. Thanks, Jon W. McCain | Software Engineer - Install -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, March 01, 2012 11:47 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Are compiler extensions available for Light as they are for candle? I'm still a little fuzzy on the requirement but based on my interpretation of your text, that sounds exactly like problem a BinderFileManager would solve. On Wed, Feb 29, 2012 at 5:46 AM, McCain, Jon jon.mcc...@inin.com wrote: Rob, Are build architecture provides the ability to have multiple paths defined at build time which normally only occur when a team branch is used off of a product line. Those paths are set within an Environment Variable where the team branch path is first and then a Systest / Parent build path is next. Because of that a compiler extension was created to handle multiple paths so when a wxs file is processed via Candle the path to the file is set to the correct absolute path. This currently requires that whatever files use this extension be rebuilt whenever a developer wishes to build installs locally. The reason for the question is our build architecture is about to greatly change where all the wxs files will need to use this method compared to just one right now. We are looking to modify 10's of thousands of files and are trying to deduce a method where all the wxs files do not need to be rebuilt EVERY time on a local machine but rather have the paths set during light since that is truly the only point in which the specific paths matter. Does it sound like the BinderFileManager could take over what our Compiler Extension is currently doing? Thanks, Jon W. McCain | Software Engineer - Install -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 29, 2012 12:39 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Are compiler extensions available for Light as they are for candle? What exactly are you doing? This sounds a lot like you want a BinderFileManager (which is an extension point provided in Light). On Tue, Feb 28, 2012 at 8:39 AM, McCain, Jon jon.mcc...@inin.com wrote: We currently have an extension in place to handle relative path conversion to absolute paths for Source File Paths in a candle compiler extension. From a cursory look over the Googles... and other sites I don't see that as an option for light but I did notice that an -ext flag is available for light. Has anyone done this with success and could they comment on a pattern to follow or specification to use? Thanks, Jon W. McCain | Software Engineer - Install -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC
Re: [WiX-users] [WiX-devs] Bind .msi file in .msi file
This should be sent to the users list not the dev list. Bccin'g devs and adding users. To answer your question with the best of my knowledge on the subject it sounds like you are wanting to create a bootstrapper for multiple MSIs that can be deployed as a single install package. Is that correct? If so, that is available in the 3.6 version which is still in beta. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Vivek SOni [mailto:vivek.s...@brisetech.com] Sent: Tuesday, April 03, 2012 5:33 AM To: wix-d...@lists.sourceforge.net Subject: [WiX-devs] Bind .msi file in .msi file Hello Everybody, Actually I want to know that can I bind a .msi file in another .msi file? If yes then please help me to do this as I am new on WIX, I don't have much idea about this. Thanks in advance. -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ WiX-devs mailing list wix-d...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Are compiler extensions available for Light as they are for candle?
Rob, Are build architecture provides the ability to have multiple paths defined at build time which normally only occur when a team branch is used off of a product line. Those paths are set within an Environment Variable where the team branch path is first and then a Systest / Parent build path is next. Because of that a compiler extension was created to handle multiple paths so when a wxs file is processed via Candle the path to the file is set to the correct absolute path. This currently requires that whatever files use this extension be rebuilt whenever a developer wishes to build installs locally. The reason for the question is our build architecture is about to greatly change where all the wxs files will need to use this method compared to just one right now. We are looking to modify 10's of thousands of files and are trying to deduce a method where all the wxs files do not need to be rebuilt EVERY time on a local machine but rather have the paths set during light since that is truly the only point in which the specific paths matter. Does it sound like the BinderFileManager could take over what our Compiler Extension is currently doing? Thanks, Jon W. McCain | Software Engineer - Install -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 29, 2012 12:39 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Are compiler extensions available for Light as they are for candle? What exactly are you doing? This sounds a lot like you want a BinderFileManager (which is an extension point provided in Light). On Tue, Feb 28, 2012 at 8:39 AM, McCain, Jon jon.mcc...@inin.com wrote: We currently have an extension in place to handle relative path conversion to absolute paths for Source File Paths in a candle compiler extension. From a cursory look over the Googles... and other sites I don't see that as an option for light but I did notice that an -ext flag is available for light. Has anyone done this with success and could they comment on a pattern to follow or specification to use? Thanks, Jon W. McCain | Software Engineer - Install -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Are compiler extensions available for Light as they are for candle?
We currently have an extension in place to handle relative path conversion to absolute paths for Source File Paths in a candle compiler extension. From a cursory look over the Googles... and other sites I don't see that as an option for light but I did notice that an -ext flag is available for light. Has anyone done this with success and could they comment on a pattern to follow or specification to use? Thanks, Jon W. McCain | Software Engineer - Install -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Run App After Setup
Have you tried using the built in WIX action of WixCA? You can set a property with the command you wish to run and then schedule it later. From the WIX Help. Quiet Execution Custom Action The QtExec custom action allows you to run an arbitrary command line in an MSI-based setup in silent mode. QtExec is commonly used to suppress console windows that would otherwise appear appear when invoking the executable directly. The custom action is located in the WixCA library, which is a part of the WixUtilExtension. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Parkes, Kevin [mailto:kevin.par...@wacom.eu] Sent: Tuesday, January 24, 2012 9:45 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Run App After Setup I want to run an installed app after setup completes. I've seen the How to... on the subject, but that doesn't seem to allow for passing command line arguments to the app, which I need to do. How can I run the app with command line arguments? (My installer creates a shortcut, with the required arguments, if that would be easier to run.) Thanks -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
For reasons that boggle my mind I changed my RegistryValue Elements to include the Name attribute where before they only had the path and a key value, where the value included the new key to be created. I also removed the initial item that added a Default value of the Product Name which was outlined in the original help / example for using Active Setup. So for those playing along at home all you need are: 3 values to get this to work for a per machine install: Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Name=StubPath Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Name=Version Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Name=Version The latter is so that the installing user doesn't have the repair install done on their machine the next time they logoff and logon. One thing to note that I was unsure of was will the user see the repair install. There was discussion on the forums that /qn should be used instead of /qb. I can tell you that for a brand new user logging in /qb doesn't result in the user seeing anything. I rebuilt the install with /qn and ran the test again to see what would happen. Jon From: McCain, Jon Sent: Tuesday, January 17, 2012 4:37 PM To: chr...@iswix.com; General discussion for Windows Installer XML toolset.; Wilson, Phil; Dan Gough Cc: McCain, Jon Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Thanks for the quick response Chris. My issue is that the keys are NEVER copied into HKCU on XP or Win 7 64bit. I would love to see a working example though if you don't mind. Thanks again. Jon From: Christopher Painter [mailto:chr...@iswix.com]mailto:[mailto:chr...@iswix.com] Sent: Tuesday, January 17, 2012 4:16 PM To: McCain, Jon; General discussion for Windows Installer XML toolset.; Wilson, Phil; Dan Gough Cc: McCain, Jon Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install ActiveSetup predates MSI and doens't really know anything about MSI. The only thing that ActiveSetup copies is the version registry value so that it knows it doesn't need to run again. What active setup really does is run a program. This program could be Notepad but in our case it's msiexec to get MSI to repair itself and install the HKCU registry components. Make sense? I can send you some sample WXS tonight if you still need it. From: McCain, Jon jon.mcc...@inin.commailto:jon.mcc...@inin.com Sent: Tuesday, January 17, 2012 3:08 PM To: chr...@iswix.commailto:chr...@iswix.com chr...@iswix.commailto:chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net, Wilson, Phil phil.wil...@invensys.commailto:phil.wil...@invensys.com, Dan Gough goug...@gmail.commailto:goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Okay last question here... Does Active Setup require that some component be set as ADVERTISED? I have not been able to see Active Setup copy ANYTHING from HKLM to HKCU for the non-installing user. There has got to be a way to get this to work that I am just blindly not seeing. Jon -Original Message- From: McCain, Jon Sent: Sunday, January 15, 2012 10:44 AM To: chr...@iswix.commailto:chr...@iswix.com; General discussion for Windows Installer XML toolset.; Wilson, Phil; Dan Gough Cc: McCain, Jon Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I'll try it again with a fresh image but my understanding based on the links is that the replication should occur if the key is not there or if the version is higher in the HKLM Active Setup key. When each user logs in that replication should occur and then launch that repair. From what I have seen so far the replication is not occurring at all therefore not getting to the repair portion. As I said though I'll try it again on a clean machine just to be %100 sure. Although Phil stated that it had to be with an advertised shortcut which in my case I am NOT doing... Chris are you saying that is necessary as well? Thanks, Jon -Original Message- From: Christopher Painter [mailto:chr...@iswix.com]mailto:[mailto:chr...@iswix.com] Sent: Friday, January 13, 2012 3:40 PM To: Wilson, Phil; General discussion for Windows Installer XML toolset.; Dan Gough Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Actually I just realized I've been saying it all. I've been implying that the repair approach and the active setup approach are mutually exclusive. In fact the active setup is just a way to trigger the repair through a command line when an advertised shortcut is unavailable. I'm sorry
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
Okay last question here... Does Active Setup require that some component be set as ADVERTISED? I have not been able to see Active Setup copy ANYTHING from HKLM to HKCU for the non-installing user. There has got to be a way to get this to work that I am just blindly not seeing. Jon -Original Message- From: McCain, Jon Sent: Sunday, January 15, 2012 10:44 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset.; Wilson, Phil; Dan Gough Cc: McCain, Jon Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I'll try it again with a fresh image but my understanding based on the links is that the replication should occur if the key is not there or if the version is higher in the HKLM Active Setup key. When each user logs in that replication should occur and then launch that repair. From what I have seen so far the replication is not occurring at all therefore not getting to the repair portion. As I said though I'll try it again on a clean machine just to be %100 sure. Although Phil stated that it had to be with an advertised shortcut which in my case I am NOT doing... Chris are you saying that is necessary as well? Thanks, Jon -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, January 13, 2012 3:40 PM To: Wilson, Phil; General discussion for Windows Installer XML toolset.; Dan Gough Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Actually I just realized I've been saying it all. I've been implying that the repair approach and the active setup approach are mutually exclusive. In fact the active setup is just a way to trigger the repair through a command line when an advertised shortcut is unavailable. I'm sorry if I was unclear or if I was clear and now I'm just confusing myself. :-) From: Christopher Painter chr...@iswix.com Sent: Friday, January 13, 2012 2:33 PM To: Wilson, Phil phil.wil...@invensys.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net, Dan Gough goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install l've used the Active Setup technique and replication occurred right away when the user logged on. Make sure you are using a clean machine such as a snapshotted VM to ensure a good testing environment. It could be that replication already occurred and isn't occuring again because the Version value isn't changing/increasing. From: Wilson, Phil phil.wil...@invensys.com Sent: Friday, January 13, 2012 2:30 PM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net, chr...@iswix.com chr...@iswix.com, Dan Gough goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Log in won't cause replication of the keys. An earlier post mentioned that you need an advertised shortcut. Phil W -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Friday, January 13, 2012 8:06 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset.; Dan Gough Cc: McCain, Jon Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have tried using the Active Setup keys but when the other user logs in the replication isn't occurring nor is the repair type install. Here is what my setup looks like: !--Installed at HKLM so that Active Setup keys can be imployed-- RegistryValue Id=ctd_classinfo_185 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ RegistryValue Id=ctd_classinfo_186 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ RegistryValue Id=ctd_activesetup_regfix_1 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_regfix_2 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\StubPath Value=msiexec /fou [ProductCode] /qb/ RegistryValue Id=ctd_activesetup_regfix_3 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ HKCU items are in separate components so that they can have the KeyPath attribute set. !--Must be installed in HKCU for installing user to immediately use. All other users will have the plugin silently repaired using Active Setup-- Component Id=ctd_ieplugin_hkcu_menuext Guid=DB65E89E-C207-43BC-B4E9-E75D20A870AF SharedDllRefCount=yes RegistryValue Id
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
Thanks for the quick response Chris. My issue is that the keys are NEVER copied into HKCU on XP or Win 7 64bit. I would love to see a working example though if you don't mind. Thanks again. Jon From: Christopher Painter [mailto:chr...@iswix.com] Sent: Tuesday, January 17, 2012 4:16 PM To: McCain, Jon; General discussion for Windows Installer XML toolset.; Wilson, Phil; Dan Gough Cc: McCain, Jon Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install ActiveSetup predates MSI and doens't really know anything about MSI. The only thing that ActiveSetup copies is the version registry value so that it knows it doesn't need to run again. What active setup really does is run a program. This program could be Notepad but in our case it's msiexec to get MSI to repair itself and install the HKCU registry components. Make sense? I can send you some sample WXS tonight if you still need it. From: McCain, Jon jon.mcc...@inin.commailto:jon.mcc...@inin.com Sent: Tuesday, January 17, 2012 3:08 PM To: chr...@iswix.commailto:chr...@iswix.com chr...@iswix.commailto:chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net, Wilson, Phil phil.wil...@invensys.commailto:phil.wil...@invensys.com, Dan Gough goug...@gmail.commailto:goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Okay last question here... Does Active Setup require that some component be set as ADVERTISED? I have not been able to see Active Setup copy ANYTHING from HKLM to HKCU for the non-installing user. There has got to be a way to get this to work that I am just blindly not seeing. Jon -Original Message- From: McCain, Jon Sent: Sunday, January 15, 2012 10:44 AM To: chr...@iswix.commailto:chr...@iswix.com; General discussion for Windows Installer XML toolset.; Wilson, Phil; Dan Gough Cc: McCain, Jon Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I'll try it again with a fresh image but my understanding based on the links is that the replication should occur if the key is not there or if the version is higher in the HKLM Active Setup key. When each user logs in that replication should occur and then launch that repair. From what I have seen so far the replication is not occurring at all therefore not getting to the repair portion. As I said though I'll try it again on a clean machine just to be %100 sure. Although Phil stated that it had to be with an advertised shortcut which in my case I am NOT doing... Chris are you saying that is necessary as well? Thanks, Jon -Original Message- From: Christopher Painter [mailto:chr...@iswix.com]mailto:[mailto:chr...@iswix.com] Sent: Friday, January 13, 2012 3:40 PM To: Wilson, Phil; General discussion for Windows Installer XML toolset.; Dan Gough Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Actually I just realized I've been saying it all. I've been implying that the repair approach and the active setup approach are mutually exclusive. In fact the active setup is just a way to trigger the repair through a command line when an advertised shortcut is unavailable. I'm sorry if I was unclear or if I was clear and now I'm just confusing myself. :-) From: Christopher Painter chr...@iswix.commailto:chr...@iswix.com Sent: Friday, January 13, 2012 2:33 PM To: Wilson, Phil phil.wil...@invensys.commailto:phil.wil...@invensys.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net, Dan Gough goug...@gmail.commailto:goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install l've used the Active Setup technique and replication occurred right away when the user logged on. Make sure you are using a clean machine such as a snapshotted VM to ensure a good testing environment. It could be that replication already occurred and isn't occuring again because the Version value isn't changing/increasing. From: Wilson, Phil phil.wil...@invensys.commailto:phil.wil...@invensys.com Sent: Friday, January 13, 2012 2:30 PM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net, chr...@iswix.commailto:chr...@iswix.com chr...@iswix.commailto:chr...@iswix.com, Dan Gough goug...@gmail.commailto:goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Log in won't cause replication of the keys. An earlier post mentioned that you need an advertised shortcut
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
Those were my thoughts initially as well but for this particular setting that doesn't work. :( Jon -Original Message- From: Dan Gough [mailto:goug...@gmail.com] Sent: Thursday, January 12, 2012 6:21 PM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Or try applying the key to HKLM rather than HKCU in the first place. Many Windows settings can apply to either key to give you the flexibility of having each setting system-wide or per-user. On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.comwrote: The Registry element has a Root attribute that you can set to HKCU. If your program has an advertised shortcut you can use this to trigger resilency to complete the installation for each user who uses your app. It's an ugly story though like the old Office install that popped up every time you went to a new conference room and logged in. http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm Here's an alternative approach that avoids all that: http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setu p-to-r epair-user-settings.html From: McCain, Jon jon.mcc...@inin.com Sent: Thursday, January 12, 2012 3:28 PM To: General discussion for Windows Installer XML toolset. (wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net Subject: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have been working on a new install where a context menu is added to the Right-Click Menu within Internet Explorer. Everything I have read regarding this requires the key be added to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but the issue I have is that our installs are run as per-machine installs and this causes other users that login to not have this menu. Links to MSDN articles explaining context menu additions for Internet Explorer: http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx The wxs code is quite simple for this addition: RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName Value=[#FileID]/ RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName \Contexts Value=1/ Has anyone run into this or another issue where a per-machine install is performed but features or other items need to exist for all users in the above fashion? Thanks, Jon -- -- -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
I have tried using the Active Setup keys but when the other user logs in the replication isn't occurring nor is the repair type install. Here is what my setup looks like: !--Installed at HKLM so that Active Setup keys can be imployed-- RegistryValue Id=ctd_classinfo_185 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ RegistryValue Id=ctd_classinfo_186 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ RegistryValue Id=ctd_activesetup_regfix_1 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_regfix_2 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\StubPath Value=msiexec /fou [ProductCode] /qb/ RegistryValue Id=ctd_activesetup_regfix_3 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ HKCU items are in separate components so that they can have the KeyPath attribute set. !--Must be installed in HKCU for installing user to immediately use. All other users will have the plugin silently repaired using Active Setup-- Component Id=ctd_ieplugin_hkcu_menuext Guid=DB65E89E-C207-43BC-B4E9-E75D20A870AF SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ !--These two entries keep the install from re-running or repairing itself when the installing user logs back in.-- RegistryValue Id=ctd_activesetup_HKCU_COPY_1 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_HKCU_COPY_2 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ /Component Component Id=ctd_ieplugin_hkcu_menuext_context Guid=327241A1-ECFF-454D-A8EC-34E0BF616904 SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ /Component The OS I am running this on is Windows 7 64 Bit. The installing user is also in the local admin group but the others users are not. Jon -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, January 12, 2012 7:12 PM To: Dan Gough; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Then there's the case of Office AddIns that allowed either HKCU or HKLM in 2003, took away in 2007 ( and put it back with a hotfix and enabling registry value ) and really put it back in 2010 leaving one hell of a mess for us installer guys to deal with. So, yes, YMMV... in the event it really needs to be HKCU like the poster asserted then my response below will help. From: Dan Gough goug...@gmail.com Sent: Thursday, January 12, 2012 5:21 PM To: chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Or try applying the key to HKLM rather than HKCU in the first place. Many Windows settings can apply to either key to give you the flexibility of having each setting system-wide or per-user. On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.com wrote: The Registry element has a Root attribute that you can set to HKCU. If your program has an advertised shortcut you can use this to trigger resilency to complete the installation for each user who uses your app. It's an ugly story though like the old Office install that popped up every time you went to a new conference room and logged in. http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm Here's an alternative approach that avoids all that: http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-r epair-user-settings.html From: McCain, Jon jon.mcc...@inin.com Sent: Thursday, January 12, 2012 3:28 PM To: General discussion for Windows Installer XML toolset. (wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net Subject: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have been working on a new install where a context menu is added to the Right
[WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
I have been working on a new install where a context menu is added to the Right-Click Menu within Internet Explorer. Everything I have read regarding this requires the key be added to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but the issue I have is that our installs are run as per-machine installs and this causes other users that login to not have this menu. Links to MSDN articles explaining context menu additions for Internet Explorer: http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx The wxs code is quite simple for this addition: RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName Value=[#FileID]/ RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName \Contexts Value=1/ Has anyone run into this or another issue where a per-machine install is performed but features or other items need to exist for all users in the above fashion? Thanks, Jon -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Querying the package and installed product architecture
1. Open the install in Orca 2. Click View - Summary Information 3. The architecture type is listed under Platform. Jon -Original Message- From: Alex Ivanoff [mailto:aivan...@vmware.com] Sent: Thursday, December 29, 2011 6:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Querying the package and installed product architecture Is there a way to query the MSI package and/or installed product architecture (x86 vs. x64)? -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Querying the package and installed product architecture
I see. The only thing I can think of is to write a test app using the msi.dll and debug it upon opening a handle to the install. Then traversing through the object it shares with you. Jon -Original Message- From: Alex Ivanoff [mailto:aivan...@vmware.com] Sent: Friday, December 30, 2011 11:19 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Querying the package and installed product architecture I need to be able to do it programmatically. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Friday, December 30, 2011 07:31 To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Querying the package and installed product architecture 1. Open the install in Orca 2. Click View - Summary Information 3. The architecture type is listed under Platform. Jon -Original Message- From: Alex Ivanoff [mailto:aivan...@vmware.com] Sent: Thursday, December 29, 2011 6:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] Querying the package and installed product architecture Is there a way to query the MSI package and/or installed product architecture (x86 vs. x64)? -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates.
Thanks Peter. I am working on the suggestion of building a small install. But I will try that as well. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Wednesday, December 14, 2011 5:04 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates. You can view the result of a patched MSI in Orca by first opening the MSI then using one of the menu items called View Patch, if I remember rightly. You could also extract the embedded transforms from the msp and look at those but that's a little more work. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: 13 December 2011 13:58 To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates. I missed your response Chad... But opening an MSP in orca only shows the MSIPatchMetaData and MSIPatchSequence tables... Are you referring to opening up the new MSI that is ultimately used to create the patch? Thanks for the suggestion Dave. I'll put something together to test that out. Jon W. McCain -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Tuesday, December 13, 2011 8:27 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissionsisremoving additional users on minor/small updates. If you can replicate this behaviour in a minimal installer, I suspect this may be a bug in the util:FileSharePermission code. I would advise grabbing the wix source and checking out what the extension does. It may well trash the acl and rebuild it on a repair (or even the whole share) which would describe the behaviour you are seeing. But that's my speculation. Dave -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: 12 December 2011 16:33 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissionsisremoving additional users on minor/small updates. If you open up your MSP in Orca does it have a FileShare and/or FileSharePermissions tables? It sounds like it does based off of the behavior you describe, but I'd hope it doesn't because I'd think (ideally) your minor update should leave the shares and permissions alone that were created by the major installer as well as added since the install. If those tables were there I think I'd try making a copy of the MSP, then use Orca to drop those two tables and save and test it to see if the same thing happened. Using the modified MSP, of course. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Monday, December 12, 2011 5:32 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Util:FileShare or FileSharePermissions isremoving additional users on minor/small updates. Anyone have any other thoughts on this? Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: McCain, Jon Sent: Friday, December 09, 2011 8:31 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: RE: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. I am referring to a minor upgrade not a major in this instance. The product code remains the same and an MSP is used for the install. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Friday, December 09, 2011 4:47 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. If by the update you're meaning a major update then you can avoid the component being reinstalled by scheduling RemoveExistingProducts late - one of the latter 2 options here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs. 85%29 .aspx Components that exist in both the old and new installers are not reinstalled. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: 08 December 2011 18:18 To: wix-users@lists.sourceforge.net Cc: McCain, Jon Subject: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. I am experiencing an issue where a network share created
Re: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates.
I just completed my test and verified in a basic install that just creates a share using the util:FileSharePermission extension does indeed wipe out existing permissions and resets with the combined permissions outlined in the install. I say combined permissions as I added a new user to the component in the patch and that user was added but the user added outside the install was removed. This means that there is a bug of some sort in that extension that causes the share permissions to be destroyed and recreated as was suggested earlier. Jon W. McCain | Software Engineer - Install -Original Message- From: McCain, Jon Sent: Wednesday, December 14, 2011 8:06 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: RE: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates. Thanks Peter. I am working on the suggestion of building a small install. But I will try that as well. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Wednesday, December 14, 2011 5:04 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates. You can view the result of a patched MSI in Orca by first opening the MSI then using one of the menu items called View Patch, if I remember rightly. You could also extract the embedded transforms from the msp and look at those but that's a little more work. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: 13 December 2011 13:58 To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates. I missed your response Chad... But opening an MSP in orca only shows the MSIPatchMetaData and MSIPatchSequence tables... Are you referring to opening up the new MSI that is ultimately used to create the patch? Thanks for the suggestion Dave. I'll put something together to test that out. Jon W. McCain -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Tuesday, December 13, 2011 8:27 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissionsisremoving additional users on minor/small updates. If you can replicate this behaviour in a minimal installer, I suspect this may be a bug in the util:FileSharePermission code. I would advise grabbing the wix source and checking out what the extension does. It may well trash the acl and rebuild it on a repair (or even the whole share) which would describe the behaviour you are seeing. But that's my speculation. Dave -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: 12 December 2011 16:33 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissionsisremoving additional users on minor/small updates. If you open up your MSP in Orca does it have a FileShare and/or FileSharePermissions tables? It sounds like it does based off of the behavior you describe, but I'd hope it doesn't because I'd think (ideally) your minor update should leave the shares and permissions alone that were created by the major installer as well as added since the install. If those tables were there I think I'd try making a copy of the MSP, then use Orca to drop those two tables and save and test it to see if the same thing happened. Using the modified MSP, of course. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Monday, December 12, 2011 5:32 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Util:FileShare or FileSharePermissions isremoving additional users on minor/small updates. Anyone have any other thoughts on this? Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: McCain, Jon Sent: Friday, December 09, 2011 8:31 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: RE: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. I am referring to a minor upgrade not a major in this instance. The product code remains the same and an MSP is used for the install. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Friday
Re: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates.
As soon as my sourceforge account is verified, thought I already had one, I'll enter a bug. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: McCain, Jon Sent: Wednesday, December 14, 2011 9:32 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: RE: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates. I just completed my test and verified in a basic install that just creates a share using the util:FileSharePermission extension does indeed wipe out existing permissions and resets with the combined permissions outlined in the install. I say combined permissions as I added a new user to the component in the patch and that user was added but the user added outside the install was removed. This means that there is a bug of some sort in that extension that causes the share permissions to be destroyed and recreated as was suggested earlier. Jon W. McCain | Software Engineer - Install -Original Message- From: McCain, Jon Sent: Wednesday, December 14, 2011 8:06 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: RE: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates. Thanks Peter. I am working on the suggestion of building a small install. But I will try that as well. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Wednesday, December 14, 2011 5:04 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates. You can view the result of a patched MSI in Orca by first opening the MSI then using one of the menu items called View Patch, if I remember rightly. You could also extract the embedded transforms from the msp and look at those but that's a little more work. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: 13 December 2011 13:58 To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Util:FileShareor FileSharePermissionsisremoving additional userson minor/small updates. I missed your response Chad... But opening an MSP in orca only shows the MSIPatchMetaData and MSIPatchSequence tables... Are you referring to opening up the new MSI that is ultimately used to create the patch? Thanks for the suggestion Dave. I'll put something together to test that out. Jon W. McCain -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Tuesday, December 13, 2011 8:27 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissionsisremoving additional users on minor/small updates. If you can replicate this behaviour in a minimal installer, I suspect this may be a bug in the util:FileSharePermission code. I would advise grabbing the wix source and checking out what the extension does. It may well trash the acl and rebuild it on a repair (or even the whole share) which would describe the behaviour you are seeing. But that's my speculation. Dave -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: 12 December 2011 16:33 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissionsisremoving additional users on minor/small updates. If you open up your MSP in Orca does it have a FileShare and/or FileSharePermissions tables? It sounds like it does based off of the behavior you describe, but I'd hope it doesn't because I'd think (ideally) your minor update should leave the shares and permissions alone that were created by the major installer as well as added since the install. If those tables were there I think I'd try making a copy of the MSP, then use Orca to drop those two tables and save and test it to see if the same thing happened. Using the modified MSP, of course. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Monday, December 12, 2011 5:32 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Util:FileShare or FileSharePermissions isremoving additional users on minor/small updates. Anyone have any other thoughts on this? Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: McCain, Jon Sent: Friday, December 09, 2011 8:31 AM To: General discussion for Windows Installer XML toolset
Re: [WiX-users] Util:FileShare or FileSharePermissionsisremoving additional users on minor/small updates.
I missed your response Chad... But opening an MSP in orca only shows the MSIPatchMetaData and MSIPatchSequence tables... Are you referring to opening up the new MSI that is ultimately used to create the patch? Thanks for the suggestion Dave. I'll put something together to test that out. Jon W. McCain -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Tuesday, December 13, 2011 8:27 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissionsisremoving additional users on minor/small updates. If you can replicate this behaviour in a minimal installer, I suspect this may be a bug in the util:FileSharePermission code. I would advise grabbing the wix source and checking out what the extension does. It may well trash the acl and rebuild it on a repair (or even the whole share) which would describe the behaviour you are seeing. But that's my speculation. Dave -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: 12 December 2011 16:33 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissionsisremoving additional users on minor/small updates. If you open up your MSP in Orca does it have a FileShare and/or FileSharePermissions tables? It sounds like it does based off of the behavior you describe, but I'd hope it doesn't because I'd think (ideally) your minor update should leave the shares and permissions alone that were created by the major installer as well as added since the install. If those tables were there I think I'd try making a copy of the MSP, then use Orca to drop those two tables and save and test it to see if the same thing happened. Using the modified MSP, of course. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Monday, December 12, 2011 5:32 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Util:FileShare or FileSharePermissions isremoving additional users on minor/small updates. Anyone have any other thoughts on this? Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: McCain, Jon Sent: Friday, December 09, 2011 8:31 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: RE: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. I am referring to a minor upgrade not a major in this instance. The product code remains the same and an MSP is used for the install. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Friday, December 09, 2011 4:47 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. If by the update you're meaning a major update then you can avoid the component being reinstalled by scheduling RemoveExistingProducts late - one of the latter 2 options here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs. 85%29 .aspx Components that exist in both the old and new installers are not reinstalled. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: 08 December 2011 18:18 To: wix-users@lists.sourceforge.net Cc: McCain, Jon Subject: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. I am experiencing an issue where a network share created with util:FileShare is overwriting post install added members to the Share Permissions DACL. The components look like this for the GA install: Fragment DirectoryRef Id=CLIENT_RESOURCES Component Id=resourcedir_fileshare Guid=D2DAED14-E4E3-4405-8C0A-D26E9144793B SharedDllRefCount=yes CreateFolder / util:FileShare Name=Resources Id=ResourceDirectoryShare Description=IC Resources Folder util:FileSharePermission GenericAll=yes User=Administrators CreateChild=yes CreateFile=yes DeleteChild=yes / util:FileSharePermission GenericRead=yes User=Everyone GenericExecute=yes ReadPermission=yes ReadExtendedAttributes=yes / /util:FileShare /Component /DirectoryRef /Fragment These do not change during minor updates but when the update is applied any additional permissions that have been added are lost. I attempted to add Conditions to the components but to only run when Not Installed is true but that didn't resolve the issue. The only solution I can think of is a custom action that creates a cache of the share information and later restores it. I
Re: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates.
Anyone have any other thoughts on this? Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: McCain, Jon Sent: Friday, December 09, 2011 8:31 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: RE: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. I am referring to a minor upgrade not a major in this instance. The product code remains the same and an MSP is used for the install. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Friday, December 09, 2011 4:47 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. If by the update you're meaning a major update then you can avoid the component being reinstalled by scheduling RemoveExistingProducts late - one of the latter 2 options here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs.85%29 .aspx Components that exist in both the old and new installers are not reinstalled. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: 08 December 2011 18:18 To: wix-users@lists.sourceforge.net Cc: McCain, Jon Subject: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. I am experiencing an issue where a network share created with util:FileShare is overwriting post install added members to the Share Permissions DACL. The components look like this for the GA install: Fragment DirectoryRef Id=CLIENT_RESOURCES Component Id=resourcedir_fileshare Guid=D2DAED14-E4E3-4405-8C0A-D26E9144793B SharedDllRefCount=yes CreateFolder / util:FileShare Name=Resources Id=ResourceDirectoryShare Description=IC Resources Folder util:FileSharePermission GenericAll=yes User=Administrators CreateChild=yes CreateFile=yes DeleteChild=yes / util:FileSharePermission GenericRead=yes User=Everyone GenericExecute=yes ReadPermission=yes ReadExtendedAttributes=yes / /util:FileShare /Component /DirectoryRef /Fragment These do not change during minor updates but when the update is applied any additional permissions that have been added are lost. I attempted to add Conditions to the components but to only run when Not Installed is true but that didn't resolve the issue. The only solution I can think of is a custom action that creates a cache of the share information and later restores it. I searched the bugs on sourceforge and do not see a specific one for this issue. Any and all help is appreciated. Regards, Jon W. McCain | Software Engineer - Install - - Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ 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. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure
Re: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates.
I am referring to a minor upgrade not a major in this instance. The product code remains the same and an MSP is used for the install. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Friday, December 09, 2011 4:47 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. If by the update you're meaning a major update then you can avoid the component being reinstalled by scheduling RemoveExistingProducts late - one of the latter 2 options here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa371197%28v=vs.85%29 .aspx Components that exist in both the old and new installers are not reinstalled. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: 08 December 2011 18:18 To: wix-users@lists.sourceforge.net Cc: McCain, Jon Subject: [WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates. I am experiencing an issue where a network share created with util:FileShare is overwriting post install added members to the Share Permissions DACL. The components look like this for the GA install: Fragment DirectoryRef Id=CLIENT_RESOURCES Component Id=resourcedir_fileshare Guid=D2DAED14-E4E3-4405-8C0A-D26E9144793B SharedDllRefCount=yes CreateFolder / util:FileShare Name=Resources Id=ResourceDirectoryShare Description=IC Resources Folder util:FileSharePermission GenericAll=yes User=Administrators CreateChild=yes CreateFile=yes DeleteChild=yes / util:FileSharePermission GenericRead=yes User=Everyone GenericExecute=yes ReadPermission=yes ReadExtendedAttributes=yes / /util:FileShare /Component /DirectoryRef /Fragment These do not change during minor updates but when the update is applied any additional permissions that have been added are lost. I attempted to add Conditions to the components but to only run when Not Installed is true but that didn't resolve the issue. The only solution I can think of is a custom action that creates a cache of the share information and later restores it. I searched the bugs on sourceforge and do not see a specific one for this issue. Any and all help is appreciated. Regards, Jon W. McCain | Software Engineer - Install - - Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ 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. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Util:FileShare or FileSharePermissions is removing additional users on minor/small updates.
I am experiencing an issue where a network share created with util:FileShare is overwriting post install added members to the Share Permissions DACL. The components look like this for the GA install: Fragment DirectoryRef Id=CLIENT_RESOURCES Component Id=resourcedir_fileshare Guid=D2DAED14-E4E3-4405-8C0A-D26E9144793B SharedDllRefCount=yes CreateFolder / util:FileShare Name=Resources Id=ResourceDirectoryShare Description=IC Resources Folder util:FileSharePermission GenericAll=yes User=Administrators CreateChild=yes CreateFile=yes DeleteChild=yes / util:FileSharePermission GenericRead=yes User=Everyone GenericExecute=yes ReadPermission=yes ReadExtendedAttributes=yes / /util:FileShare /Component /DirectoryRef /Fragment These do not change during minor updates but when the update is applied any additional permissions that have been added are lost. I attempted to add Conditions to the components but to only run when Not Installed is true but that didn't resolve the issue. The only solution I can think of is a custom action that creates a cache of the share information and later restores it. I searched the bugs on sourceforge and do not see a specific one for this issue. Any and all help is appreciated. Regards, Jon W. McCain | Software Engineer - Install -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using wix how to always overwrite a file?
You could write a CA to put the file in a temp location each time, check the creation date on both (or some other unique variable), and then move it into the proper directory. You would have to write additional code to handle backup of the pre-existing file in the instance of an update removal or an total uninstall. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Pandurangan, Vasanthakumar [mailto:vasanthakumar.panduran...@hp.com] Sent: Tuesday, October 18, 2011 6:50 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using wix how to always overwrite a file? Hi, There are 2 msi installer files, both of them write the same file in the same location. Objective is to overwrite the file by the latest installer. As of now, the file is not versioned. So Installer re-writes the file only when the modified date is older than created date of the existing file. How to change it so that this file is always over written by the latest installer? What should be the value of DefaultVersion attribute in File tag? I'm unable to find any example of Wix code which uses DefaultVersion attribute in File element. Thanks in Advance, Vasanth -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LIT Error - Cannot find file
It could be that you have an old wixobj out there for that component. You could try removing that and rebuilding. Jon -Original Message- From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] Sent: Tuesday, October 18, 2011 10:21 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] LIT Error - Cannot find file I have started receiving this error lit.exe : error LIT0103: The system cannot find the file '..\Content.Client\dir1\Content\Integration\common\niem\ut_offender-tracking-misc\2.0\ut_offender-tracking-misc.xsd' with type ''. [D:\Builds\1\Product\version\Source\client \Fragment.TX.TarrantCounty.Content.LegacySonicService\Fragment.client.Content.contentlib.wixproj] What I don't understand is that this is only happening for two files out of about 100; I verified the paths and they are valid. In fact the relative pathing is doing using a defined value, and it is used for every file within this wix project, as well as others. Anyone have any idea as to how I should go about troubleshooting this? This builds correctly 100% of the time on the desktop builds. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using wix how to always overwrite a file?
Interesting solution. Very nice. Jon -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Tuesday, October 18, 2011 10:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Using wix how to always overwrite a file? Another option is to use the RemoveFile/ element tied to the same Component as your File/ element. This will always clear out the existing file prior to the current install writing the new one. Works for rollback and uninstall. Component Id=Filetxt DiskId=1 Guid=someguid RemoveFile Id=Remove_Filetxt Name=File.txt On=install / File Id=Filetxt Name=File.txt Source=.\data\File.txt / /Component The RemoveFiles action is always scheduled before the InstallFiles action by default, so as long as you don't change that sequence in InstallExecuteSequence then it should work fine. I consider this the functional equivalent of the InstallShield Always Overwrite setting. -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Tuesday, October 18, 2011 5:33 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Using wix how to always overwrite a file? You could write a CA to put the file in a temp location each time, check the creation date on both (or some other unique variable), and then move it into the proper directory. You would have to write additional code to handle backup of the pre-existing file in the instance of an update removal or an total uninstall. Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 | jon.mcc...@inin.com Interactive Intelligence Inc. Deliberately Innovative www.inin.com -Original Message- From: Pandurangan, Vasanthakumar [mailto:vasanthakumar.panduran...@hp.com] Sent: Tuesday, October 18, 2011 6:50 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using wix how to always overwrite a file? Hi, There are 2 msi installer files, both of them write the same file in the same location. Objective is to overwrite the file by the latest installer. As of now, the file is not versioned. So Installer re-writes the file only when the modified date is older than created date of the existing file. How to change it so that this file is always over written by the latest installer? What should be the value of DefaultVersion attribute in File tag? I'm unable to find any example of Wix code which uses DefaultVersion attribute in File element. Thanks in Advance, Vasanth -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
I understand maintaining the customers data but isn't the goal here to remove it? Which I agree is against the rules normally but it would appear that is what is wanted... Did I miss something? Jon -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Tuesday, October 04, 2011 10:23 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows. On 04-Oct-11 15:29, McCain, Jon wrote: If that is the case then you shouldn't need to worry about being a good install writer and just whack the folder or its subfolders that you don't control with your install. Of course you should. If there's a failure or other rollback, the user's data is gone. -- sig://boB http://joyofsetup.com/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files.
When calling another process from within a batch file that you want to waiting merely add 'call' in front of it. I do this to utilize multiple batch files with one call. Jon -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: Monday, October 03, 2011 6:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files. John Have a look at the Start command (help start) which can be used to start and wait in batch files. Michael -Original Message- From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] Sent: Tuesday, 4 October 2011 8:47 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files. I am working through deploying our software for automated testing and appear to have encountered an issue that I am not quite sure what the best way is to solve. I need to deploy multiple MSI files, my initial thought was that I could do this with a batch file, but apparently, the process of running the MSI starts a new process and the batch file continues, so all of the installers after the first one fails. The order of install doesn't matter in my case. I was using PSExec to start the MSIs remotely (both directly and via a batch file). Anyone have any ideas as far as what the best way to do this would be? -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Just curious here but why not use the RemoveFile element within the component
that initially installed the file or do you not own this file?
Also, AFAIK If you remove all files in the fashion above that directory will be
removed as well.
Jon W. McCain | Software Engineer - Install
phone fax +1.317.715.8462 | jon.mcc...@inin.com
Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October 04, 2011 2:45 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
I'm hoping that someone can help me out. I cannot seem to figure out why my
custom action is constantly failing me. The action executes on uninstall and
is to browse the install folder and add files to the RemoveFile table (with a
few additional properties too) in the MSI so that the file is removed during
uninstall. The action is defined as
InstallExecuteSequence
Custom
Action=PurgeFolder
After=InstallInitialize
![CDATA[REMOVE~=ALL AND NOT UPGRADINGPRODUCTCODE]]
/Custom
/InstallExecuteSequence
The action runs as expected as I can get log messages to show up in the log
file. However whenever the action attempts to insert a temporary row (Either
in the Property Table or the RemoveFile table) I get the exception:
Microsoft.Deployment.WindowsInstaller.InstallerException: Function failed
during execution. Database: Table(s) Update failed.
at Microsoft.Deployment.WindowsInstaller.View.Modify(ViewModifyMode mode,
Record record)
The method for updating the view looks like
Record newRecord = session.Database.CreateRecord(2);
newRecord.SetString(1, directoryProperty);
newRecord.SetString(2, directory.FullName);
session.Log(String.Format(Adding Property {0}, newRecord.ToString()));
propertyView.Modify(ViewModifyMode.InsertTemporary, newRecord);
I have even tried executing a straight insert statement like INSERT INTO
Property ('Property', 'Value') Values (Value1, Value2) TEMPORARY to no avail.
And there is no way the directory property name could be conflicting as it is
part static with a GUID (stripped of the hyphens) appended to the end of it.
I am almost at my wits end here. I am half a step away from the CA just
blowing away the whole directory but I am trying to be a good Windows Installer
citizen here and use the tools as they are.
--Brian
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity and more. Splunk takes this data and makes sense of it.
Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Okay so the folders/files are then classified as customer data which is why
RemoveFile wouldn't work since you don't actually lay those files down. At
least that is how I am reading your response.
If that is the case then you shouldn't need to worry about being a good install
writer and just whack the folder or its subfolders that you don't control with
your install.
Jon W. McCain | Software Engineer - Install
phone fax +1.317.715.8462 | jon.mcc...@inin.com
Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October 04, 2011 3:06 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Because most of these are nested in folders created by the application. I
would really like to use the RemoveFolderEX element found in Wix 3.6 but I am
not allowed to use that version yet. I am forced to stay on 3.5
-Original Message-
From: McCain, Jon [mailto:jon.mcc...@inin.com]
Sent: Tuesday, October 04, 2011 2:03 PM
To: General discussion for Windows Installer XML toolset.
Cc: McCain, Jon
Subject: Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Just curious here but why not use the RemoveFile element within the component
that initially installed the file or do you not own this file?
Also, AFAIK If you remove all files in the fashion above that directory will be
removed as well.
Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 |
jon.mcc...@inin.com
Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October 04, 2011 2:45 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
I'm hoping that someone can help me out. I cannot seem to figure out why my
custom action is constantly failing me. The action executes on uninstall and
is to browse the install folder and add files to the RemoveFile table (with a
few additional properties too) in the MSI so that the file is removed during
uninstall. The action is defined as
InstallExecuteSequence
Custom
Action=PurgeFolder
After=InstallInitialize
![CDATA[REMOVE~=ALL AND NOT UPGRADINGPRODUCTCODE]]
/Custom
/InstallExecuteSequence
The action runs as expected as I can get log messages to show up in the log
file. However whenever the action attempts to insert a temporary row (Either
in the Property Table or the RemoveFile table) I get the exception:
Microsoft.Deployment.WindowsInstaller.InstallerException: Function failed
during execution. Database: Table(s) Update failed.
at Microsoft.Deployment.WindowsInstaller.View.Modify(ViewModifyMode mode,
Record record)
The method for updating the view looks like
Record newRecord = session.Database.CreateRecord(2);
newRecord.SetString(1, directoryProperty);
newRecord.SetString(2, directory.FullName);
session.Log(String.Format(Adding Property {0}, newRecord.ToString()));
propertyView.Modify(ViewModifyMode.InsertTemporary, newRecord);
I have even tried executing a straight insert statement like INSERT INTO
Property ('Property', 'Value') Values (Value1, Value2) TEMPORARY to no avail.
And there is no way the directory property name could be conflicting as it is
part static with a GUID (stripped of the hyphens) appended to the end of it.
I am almost at my wits end here. I am half a step away from the CA just
blowing away the whole directory but I am trying to be a good Windows Installer
citizen here and use the tools as they are.
--Brian
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity and more. Splunk takes this data and makes sense of it.
Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity and more. Splunk takes this data and makes sense of it.
Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data
