Re: [WiX-users] How to prevent upgrade and downgrade if system depends from particular installed product version
On 12/05/2014 04:51 AM, Nicolás Alvarez wrote: 2014-12-04 4:26 GMT-03:00 Valery Portnyagin valery.portnya...@oracle.com: On 12/02/2014 10:15 PM, Phil Wilson wrote: If you're saying that two MSI products are incompatible and you want to make sure that a product cannot be installed if another one is already installed then some choices are: You use Upgrade and UpgradeVersion elements with OnlyDetect=yes that target the specific incompatible installed product. The upgrade logic will look for that product and set the property associated with the upgrade. This subject to the rule that both products are per machine (or both per user). If that property is set you could trigger a dialog box. If there is a file with a specific version associated with the incompatible product you could do a File Search for that specific version. Again, a property will be set if the file is found. These, and your request, have the problem that in a silent install there is no UI so do you want to go ahead with the install or not? If you choose not to do the install at all if invoked silently then it's better to do that with a launch condition, and WiX generates MSI files with FindRelatedProducts before launch condition checks, so you could use the upgrade property in a launch condition. --- Phil Wilson Hello Phil, Thank for the answer. but I say about other case. there is one package A (msi package) and there is package B (also msi package). they are combined inside one exe bundle C. User install product C. Next step, user gets a new version of package B (just download from vendor site, for example). And try to install it. But for some reasons package A depends from particular version of package B. So, it is pleased if user will see some message with warning like other products are installed which depend on that product. and he may decide to do or not to do this upgrade. And how i think, such logic can be realized via Requires/Provides Elements from Dependency Extension. But there is lack of information about this option/feature. Anyway, if there is another approach to achieve this i will appreciate for any clues or explanations. I'm quite sure the logic to display such a message would have to be in the new version of package B. So if B is coming from an external vendor, I don't think you can do what you want... From Requires Element (Dependency Extension) description: This element declares a dependency on any product that uses the Provides element. If that product is uninstalled before a product that requires it, the uninstall will err or warn the user that other products are installed which depend on that product. Upgrade logic consists two steps - uninstall old, then install a new package. So when i install a new version of package B i can expect the uninstall will err or warn the user that other products are installed which depend on that product. This is what i want to see. What else, I have made different experiments with Requires/Provides elements, but i didn't find the right way to get a working WiX script. I am experimenting with 3 simple projects: 1. MSI A 2. MSI B 3. Exe bundle C (MSI A + MSI B) It doesn't matter where i put these elements, every time i see the same results. I see that in the registry under HKCR\Installer\Dependencies are created the same structure from key/records - Both MSI A and MSI B depends from bundle C only. How can i achieve the result when under HKCR\Installer\Dependencies i will see dependency of package A from particular version of package B? regards, Valery. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cant get util:RemoveFolderEx to work on network drive
Hi Jeremiahf, Thanks for your reply =). Im saving the path in the registy (RegistryValue Root=HKLM Key=SOFTWARE\[ManufacturerName]\Me Name=Path Type=string Value=h:\topfolder\middlefolder KeyPath=yes /) insted of creating it as a directory (Fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLFOLDER Name=Wix example application / /Directory /Directory /Fragment) since I understood that the directory would not be saved to the wix database. I'm using RegistryValue insted of Registry Element since the wix documentation says that Registry Element is depricated. I know that the driver letter always will be H: since it is a requirement from the customer. I still don't understand why it works on C but not on H. And it is interesing that it almost work on H(anly one directory is left undeleted). I'm thankful for your help, but unfortunatelly I have still not managed to solve the problem. Regards Samir -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Cant-get-util-RemoveFolderEx-to-work-on-network-drive-tp7598399p7598419.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cant get util:RemoveFolderEx to work on network drive
You cannot delete files on a network system where you lack the appropriate rights and also cannot delete read-only, hidden, or system files. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Cant-get-util-RemoveFolderEx-to-work-on-network-drive-tp7598399p7598420.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to find out the installlocation from WiX Bootstrapper after installation?
Thanks a lot for Your explanations! I have defined now a property in my GUI, which contains the complete installfolder-path. That's a little bit tricky but what shall You do? Goodbye and have a nice day! Patrick -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-find-out-the-installlocation-from-WiX-Bootstrapper-after-installation-tp7598318p7598421.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cant get util:RemoveFolderEx to work on network drive
Thanks for the reply Namrata Kumari. What I'm guessing that you are saying, is that removing files on the network is not supported by WIX. Since I'm able to delete one of the two folders on the network drive. Regards Samir -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Cant-get-util-RemoveFolderEx-to-work-on-network-drive-tp7598399p7598422.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to prevent upgrade and downgrade if system depends from particular installed product version
According to the documentation for the Requires elements (http://wixtoolset.org/documentation/manual/v3/xsd/dependency/requires.html), it can be put inside of a Product element. I am wondering if that's a feature that hasn't been implemented yet. What I'm saying is, it sounds like the WiX team would like to have MSI packages themselves register as providers and requires packages. But currently, perhaps it's only something that works with Burn bootstrappers. Also, the MSI in question would have to be authored with WiX and use the DependencyExtension. Feature not implemented? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-prevent-upgrade-and-downgrade-if-system-depends-from-particular-installed-product-version-tp7598305p7598423.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to prevent upgrade and downgrade if system depends from particular installed product version
A while back I was also struggling with understanding the DependencyExtension. (My razor is often dull. smile/) I was trying to assure that a particular version of one dependency was not removed after my bundle/packages were installed. I came across Rob's advice in the following link. Since my scenario also included a third-party dependency (vcruntime) I concluded that the DependencyExtenstion would not be useful and abandoned those efforts. I have not had a chance to try a scenario where I have multiple co-existent bundles with common packages (all of which I author). But reading the code for DependencyExtension it is intended to be a feature where Burn reference counts a package across multiple bundles, as I understand it. http://stackoverflow.com/questions/18603313/how-to-avoid-uninstalling-previously-installed-exepackage-redistributables-whi -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-prevent-upgrade-and-downgrade-if-system-depends-from-particular-installed-product-version-tp7598305p7598425.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition problem
That makes a little more sense now. Try placing a condition in your feature that includes a condition message. The condition message should reference the condition using similar to what Pavan gave an example of. example for .net 4 detection just to give you an idea of what I am talking about: !--.NET 4.0 Installation detection-- Property Id=NETFRAMEWORK40CLIENT RegistrySearch Id=NetFramework40Client Root=HKLM Key=SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client Name=Install Type=raw / /Property !--.NET 4.0 Condition message-- Condition Message=This application requires .NET Framework 4.0. Please install the .NET Framework then run this installer again ![CDATA[Installed OR NETFRAMEWORK40CLIENT]] /Condition Does it make sense how the message is related to the condition? This will pop up a message and stop the installation. This installer will never complete until the condition is met. On Thu, Dec 4, 2014 at 8:56 PM, Marek Mielcarek mmielca...@actuate.com wrote: I appreciate your help. The problem is that the installer is mainly used as command-line without any GUI. The package gets pushed to several machines and executed with several options (features) enabled or disabled, depending on deployment automation schema. There might be 100+ servers involved. My installer might be directed to deploy a feature that requires IIS but server might not have it. In reality, the situation is even more complex as there are other features that need to check for other prerequisites (i.e. MSMQ, specific OLDB drivers etc). I started leaning toward custom actions that can break installation process if they cannot detect something they should. I wanted to avoid that hoping there is something cleaner. Thanks a lot. Original Message From: Pavan Konduru Sent: Thursday, December 4, 2014 21:46 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem You should set up the next button in the feature selection screen to display a dialog that IIS is required for that feature(if selected). MyCustomizeDLg is the dialog that has the list of the your features user can select. IISFOUND is a property you set to search for IIS present or not(I think WIX has an in-built property to do this IISMAJORVERSION). FeatureneedsIIS is the feature that requires IIS. Something like this: Publish Dialog=MyCustomizeDlg Control=Next Event=NewDialog Value=IISNotFoundDlg![CDATA[NOT IISFOUND AND (FeatureneedsIIS = 3 AND ! FeatureneedsIIS 3)]]/Publish In the dialog that shows the message to the user redirect the OK button to exit dialog. Control Id=OK Type=PushButton X=102 Y=90 Width=56 Height=17 Default=yes Cancel=yes Text=OK Publish Event=EndDialog Value=Return1/Publish /Control -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Thursday, December 04, 2014 3:06 PM To: wix-users@lists.sourceforge.net; General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem Example: one of the features requires IIS. Check for IIS should occur only if the feature is selected. If te check succeeds, the feature shall be installed. If it fails, the installation shall fail. If feature is not selected the IIS does not matter. Original Message From: Pavan Konduru Sent: Thursday, December 4, 2014 18:00 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem Can give an example so it will be easier to understand? What are the conditions and what do the features depend on? -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Thursday, December 04, 2014 2:28 PM To: wix-users@lists.sourceforge.net; General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem User can select any feature. Each feature has a different condition. Installer verifies the condition for feature if it was selected for installation. If the condition is not met, installer breaks and informs what was the reason. Original Message From: Pavan Konduru Sent: Thursday, December 4, 2014 17:24 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem This Condition makes sense only if a particular Feature is being installed. So, how do you plan to achieve this even before a feature is selected for install? -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Thursday, December 04, 2014 12:13 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Condition problem I need to define a Condition which generates message and stops installation (if condition fails). This Condition makes sense only if a particular Feature is being installed. It looks
Re: [WiX-users] Condition problem
Thank you for your help Jeremiah. I actually tried that before I sent the message to this group. Apparently, it is not allowed to place Condition with a message inside a Feature. WiX compiler generates this: The Condition element contains an unexpected attribute 'Message' :( -Original Message- From: Jeremiahf [mailto:jeremi...@gmail.com] Sent: Friday, December 05, 2014 10:16 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem That makes a little more sense now. Try placing a condition in your feature that includes a condition message. The condition message should reference the condition using similar to what Pavan gave an example of. example for .net 4 detection just to give you an idea of what I am talking about: !--.NET 4.0 Installation detection-- Property Id=NETFRAMEWORK40CLIENT RegistrySearch Id=NetFramework40Client Root=HKLM Key=SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client Name=Install Type=raw / /Property !--.NET 4.0 Condition message-- Condition Message=This application requires .NET Framework 4.0. Please install the .NET Framework then run this installer again ![CDATA[Installed OR NETFRAMEWORK40CLIENT]] /Condition Does it make sense how the message is related to the condition? This will pop up a message and stop the installation. This installer will never complete until the condition is met. On Thu, Dec 4, 2014 at 8:56 PM, Marek Mielcarek mmielca...@actuate.com wrote: I appreciate your help. The problem is that the installer is mainly used as command-line without any GUI. The package gets pushed to several machines and executed with several options (features) enabled or disabled, depending on deployment automation schema. There might be 100+ servers involved. My installer might be directed to deploy a feature that requires IIS but server might not have it. In reality, the situation is even more complex as there are other features that need to check for other prerequisites (i.e. MSMQ, specific OLDB drivers etc). I started leaning toward custom actions that can break installation process if they cannot detect something they should. I wanted to avoid that hoping there is something cleaner. Thanks a lot. Original Message From: Pavan Konduru Sent: Thursday, December 4, 2014 21:46 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem You should set up the next button in the feature selection screen to display a dialog that IIS is required for that feature(if selected). MyCustomizeDLg is the dialog that has the list of the your features user can select. IISFOUND is a property you set to search for IIS present or not(I think WIX has an in-built property to do this IISMAJORVERSION). FeatureneedsIIS is the feature that requires IIS. Something like this: Publish Dialog=MyCustomizeDlg Control=Next Event=NewDialog Value=IISNotFoundDlg![CDATA[NOT IISFOUND AND (FeatureneedsIIS = 3 AND ! FeatureneedsIIS 3)]]/Publish In the dialog that shows the message to the user redirect the OK button to exit dialog. Control Id=OK Type=PushButton X=102 Y=90 Width=56 Height=17 Default=yes Cancel=yes Text=OK Publish Event=EndDialog Value=Return1/Publish /Control -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Thursday, December 04, 2014 3:06 PM To: wix-users@lists.sourceforge.net; General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem Example: one of the features requires IIS. Check for IIS should occur only if the feature is selected. If te check succeeds, the feature shall be installed. If it fails, the installation shall fail. If feature is not selected the IIS does not matter. Original Message From: Pavan Konduru Sent: Thursday, December 4, 2014 18:00 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem Can give an example so it will be easier to understand? What are the conditions and what do the features depend on? -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Thursday, December 04, 2014 2:28 PM To: wix-users@lists.sourceforge.net; General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem User can select any feature. Each feature has a different condition. Installer verifies the condition for feature if it was selected for installation. If the condition is not met, installer breaks and informs what was the reason. Original Message From: Pavan Konduru Sent: Thursday, December 4, 2014 17:24 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem This Condition makes sense only if a particular
Re: [WiX-users] Condition problem
Use a feature condition. A feature condition is where a Condition element is placed inside a Feature element. There, it can change whether or not that feature gets installed depending on if the statements evaluates to true. It does this by changing the Level of the Feature: Feature Id=FeatureThatNeedsSQL Title=My SQL Feature Level=1 ComponentGroupRef Id=SQLComponents / Condition Level=0 /Condition /Feature If SQL_INSTALLED is false, the feature's Level will be changed to 0, which means it will be disabled and removed from the feature tree. This works for the UI, because it removes the feature from the feature tree. It also works for the command-line because it disables the feature. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Condition-problem-tp7598403p7598429.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] multiple product codes returned from Upgrade code
It looks like what you have is correct. You have a SAME_VERSION property. Although you might want to set OnlyDetect to yes if you want to keep the existing product there and not overwrite it. Then, use a launch condition to stop the new installation from going through if SAME_VERSION is found. The new element, MajorUpgrade, does all of this for us, but that's how it's done by hand. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/multiple-product-codes-returned-from-Upgrade-code-tp7598400p7598433.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] harvesting x64 com dll with heat
Hi I am harvesting a x64 C# COM exposed dll using heat.exe. Though it creates a component with the file element only. I throws following warning: heat.exe : warning HEAT5150 : Could not harvest data from a file that was expect ed to be a SelfReg DLL: D:\testcom\testCOMdll.dll. If this file does not support SelfReg you can ignore this warning. Otherwise, this error detail may be helpfu l to diagnose the failure: Unable to load file: D:\testcom\testCOMdll.dll, error : 193 I have read some forum that heat will not harvest x64 COM dll. Could anyone share if there is an alternate way to do the same. We are using all x64 .net dlls. Regards, Sampat -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/harvesting-x64-com-dll-with-heat-tp7598434.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Deploying multiple cultures using Burn/MSI(s). Wix 3.9 issue??
Hi, Have you found a solution for this? Are there any pointers for this ? I have exactly same issue. -James -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deploying-multiple-cultures-using-Burn-MSI-s-Wix-3-9-issue-tp7596896p7598436.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Deploying multiple cultures using Burn/MSI(s). Wix 3.9 issue??
On Fri, 5/12/14, James [via Windows Installer XML (WiX) toolset] ml-node+s687559n7598436...@n2.nabble.com wrote: Subject: Re: Deploying multiple cultures using Burn/MSI(s). Wix 3.9 issue?? To: James unk...@yahoo.com Date: Friday, 5 December, 2014, 9:10 AM Hi, Have you found a solution for this? Are there any pointers for this ? I have exactly same issue. -James If you reply to this email, your message will be added to the discussion below: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deploying-multiple-cultures-using-Burn-MSI-s-Wix-3-9-issue-tp7596896p7598436.html To unsubscribe from Deploying multiple cultures using Burn/MSI(s). Wix 3.9 issue??, click here. NAML -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deploying-multiple-cultures-using-Burn-MSI-s-Wix-3-9-issue-tp7596896p7598437.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cant get util:RemoveFolderEx to work on network drive
It's about Windows Installer functionality not WiX functionality. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Samir [mailto:samir.elyahia...@hiq.se] Sent: Friday, December 5, 2014 3:15 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Cant get util:RemoveFolderEx to work on network drive Thanks for the reply Namrata Kumari. What I'm guessing that you are saying, is that removing files on the network is not supported by WIX. Since I'm able to delete one of the two folders on the network drive. Regards Samir -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition problem
This is a good solution from Nick! -Original Message- From: Nick Ramirez [mailto:nickra...@hotmail.com] Sent: Friday, December 05, 2014 7:36 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Condition problem Use a feature condition. A feature condition is where a Condition element is placed inside a Feature element. There, it can change whether or not that feature gets installed depending on if the statements evaluates to true. It does this by changing the Level of the Feature: Feature Id=FeatureThatNeedsSQL Title=My SQL Feature Level=1 ComponentGroupRef Id=SQLComponents / Condition Level=0 /Condition /Feature If SQL_INSTALLED is false, the feature's Level will be changed to 0, which means it will be disabled and removed from the feature tree. This works for the UI, because it removes the feature from the feature tree. It also works for the command-line because it disables the feature. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Condition-problem-tp7598403p7598429.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition problem
Yes, except that Condition cannot use Message when placed inside Feature. I already said that I tried it before even sending question to the group. Original Message From: Pavan Konduru Sent: Friday, December 5, 2014 12:18 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem This is a good solution from Nick! -Original Message- From: Nick Ramirez [mailto:nickra...@hotmail.com] Sent: Friday, December 05, 2014 7:36 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Condition problem Use a feature condition. A feature condition is where a Condition element is placed inside a Feature element. There, it can change whether or not that feature gets installed depending on if the statements evaluates to true. It does this by changing the Level of the Feature: Feature Id=FeatureThatNeedsSQL Title=My SQL Feature Level=1 ComponentGroupRef Id=SQLComponents / Condition Level=0 /Condition /Feature If SQL_INSTALLED is false, the feature's Level will be changed to 0, which means it will be disabled and removed from the feature tree. This works for the UI, because it removes the feature from the feature tree. It also works for the command-line because it disables the feature. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Condition-problem-tp7598403p7598429.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition problem
If you need to block an installation post-CostFinalize use a conditioned error custom action. LaunchConditions is not scheduled late enough. Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Friday, December 5, 2014 9:22 AM To: wix-users@lists.sourceforge.net; General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem Yes, except that Condition cannot use Message when placed inside Feature. I already said that I tried it before even sending question to the group. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition problem
Thank you Rob. That's exactly the way I've taken. And yes, you are correct, the problem is that although LaunchConditions would have been perfect place, there is no knowledge of Features because it is too early... I think we can close this case with CustomActiion being really the best way to go. Thanks a lot everybody for pitching in. Original Message From: Rob Mensching Sent: Friday, December 5, 2014 12:35 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem If you need to block an installation post-CostFinalize use a conditioned error custom action. LaunchConditions is not scheduled late enough. Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Friday, December 5, 2014 9:22 AM To: wix-users@lists.sourceforge.net; General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem Yes, except that Condition cannot use Message when placed inside Feature. I already said that I tried it before even sending question to the group. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] multiple product codes returned from Upgrade code
There's nothing to prevent multiple products being returned - it just means there are several installed products on the system that share the same UpgradeCode. In your case, I guess Nick is saying that one of the multiples returned might be your own. It looks like the different languages all share an UpgradeCode, so there may also be two language products installed. The list is returned by Windows Installer so there's nothing you can do about the format. In these situations it's my experience that each language will have a unique UpgradeCode because most people don't want (say) an English version to upgrade a French version. Using OnlyDetect for the other UpgradeCodes can be used to prevent side by side installs of different languages. --- Phil Wilson On Fri, Dec 5, 2014 at 8:04 AM, Nick Ramirez nickra...@hotmail.com wrote: It looks like what you have is correct. You have a SAME_VERSION property. Although you might want to set OnlyDetect to yes if you want to keep the existing product there and not overwrite it. Then, use a launch condition to stop the new installation from going through if SAME_VERSION is found. The new element, MajorUpgrade, does all of this for us, but that's how it's done by hand. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/multiple-product-codes-returned-from-Upgrade-code-tp7598400p7598433.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cant get util:RemoveFolderEx to work on network drive
I don't know how much this is related to your problem, but mapped drive letters are difficult for a number of reasons. They are not system wide because they belong to the user profile. There's also the issue that the system account usually has limited access (or none) to the network. To make it even worse, impersonation does not load the user's profile, the stuff that includes the mapped drives. So if the code runs without impersonation the system account can't get to the network. If you run impersonated you may not see the H: drive and by default won't be elevated. The general advice in these cases is to use the actual share name to avoid the mapped drive letter issues, but access is going to be an issue, that's probably where you need to look. --- Phil Wilson On Fri, Dec 5, 2014 at 9:16 AM, Rob Mensching r...@firegiant.com wrote: It's about Windows Installer functionality not WiX functionality. _ Short replies here. Complete answers over there: http://www.firegiant.com/ -Original Message- From: Samir [mailto:samir.elyahia...@hiq.se] Sent: Friday, December 5, 2014 3:15 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Cant get util:RemoveFolderEx to work on network drive Thanks for the reply Namrata Kumari. What I'm guessing that you are saying, is that removing files on the network is not supported by WIX. Since I'm able to delete one of the two folders on the network drive. Regards Samir -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] harvesting x64 com dll with heat
That error message and error 193 seem to indicate that Heat is expecting a Win32 Self Registering COM Dll, not a .NET Dll. What are you expecting to harvest? --- Phil Wilson On Fri, Dec 5, 2014 at 8:24 AM, ssmsam ssmcs...@gmail.com wrote: Hi I am harvesting a x64 C# COM exposed dll using heat.exe. Though it creates a component with the file element only. I throws following warning: heat.exe : warning HEAT5150 : Could not harvest data from a file that was expect ed to be a SelfReg DLL: D:\testcom\testCOMdll.dll. If this file does not support SelfReg you can ignore this warning. Otherwise, this error detail may be helpfu l to diagnose the failure: Unable to load file: D:\testcom\testCOMdll.dll, error : 193 I have read some forum that heat will not harvest x64 COM dll. Could anyone share if there is an alternate way to do the same. We are using all x64 .net dlls. Regards, Sampat -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/harvesting-x64-com-dll-with-heat-tp7598434.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] harvesting x64 com dll with heat
I built C# dll with x86 release mode and i Ran heat over it
the heat cmd:
D:\heat file testcom\testCOMdll32.tlb -srd -sfrag -suid -svb6 -gg -g1 -out
D:\testcom\testcomtlb.wxs
Windows Installer XML Toolset Toolset Harvester version 3.9.1006.0
Copyright (c) Outercurve Foundation. All rights reserved.
Heat gives the following fragment:
Fragment
DirectoryRef Id=TARGETDIR
Component Id=testCOMdll32.dll
Guid=84624085-DD3F-4336-BA27-8942799DE951
Class Id={36E6BC94-308C-4952-84E6-109041990EF7}
Context=InprocServer32 Description=testCOMDLL.CSCOMClass01
ThreadingModel=both ForeignServer=mscoree.dll
ProgId Id=CSCOMServer.CSCOMClass01
Description=testCOMDLL.CSCOMClass01 /
/Class
File Id=testCOMdll32.dll KeyPath=yes
Source=SourceDir\testCOMdll32.dll /
RegistryValue Root=HKCR
Key=CLSID\{36E6BC94-308C-4952-84E6-109041990EF7}\Implemented
Categories\{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29} Value= Type=string
Action=write /
RegistryValue Root=HKCR
Key=CLSID\{36E6BC94-308C-4952-84E6-109041990EF7}\InprocServer32\1.0.0.0
Name=Class Value=testCOMDLL.CSCOMClass01 Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{36E6BC94-308C-4952-84E6-109041990EF7}\InprocServer32\1.0.0.0
Name=Assembly Value=testCOMdll, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=46bb154641f15448 Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{36E6BC94-308C-4952-84E6-109041990EF7}\InprocServer32\1.0.0.0
Name=RuntimeVersion Value=v4.0.30319 Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{36E6BC94-308C-4952-84E6-109041990EF7}\InprocServer32\1.0.0.0
Name=CodeBase Value=file:///[#testCOMdll32.dll] Type=string
Action=write /
RegistryValue Root=HKCR
Key=CLSID\{36E6BC94-308C-4952-84E6-109041990EF7}\InprocServer32
Name=Class Value=testCOMDLL.CSCOMClass01 Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{36E6BC94-308C-4952-84E6-109041990EF7}\InprocServer32
Name=Assembly Value=testCOMdll, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=46bb154641f15448 Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{36E6BC94-308C-4952-84E6-109041990EF7}\InprocServer32
Name=RuntimeVersion Value=v4.0.30319 Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{36E6BC94-308C-4952-84E6-109041990EF7}\InprocServer32
Name=CodeBase Value=file:///[#testCOMdll32.dll] Type=string
Action=write /
/Component
/DirectoryRef
/Fragment
It didnt create any of the registry entries for the x64 release build of C#
dll. I need to create a COM+ entry in component services(dcomcnfg) with the
help of wiX ComPlusExtension. It was failing so i thought of doing this
through heat. No luck.
I followed the following link:
http://wix.tramontana.co.hu/tutorial/com-expression-syntax-miscellanea/com-applications
and got the same error mentioned in this link
http://stackoverflow.com/questions/13944373/registering-a-net-assembly-in-a-com-application-outside-of-the-gac
Regards ,
Sampat
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/heat-gives-warning-when-harvesting-net-com-dll-tp7598434p7598450.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition problem
I agree - all you said is very true. However, as I am sure you know, there is always more to the music than eye can see... there was an old contract between previous guy and information systems that installer failure should demonstrate as full-stop of the process. They can detect that through WMI and take the screenshot through some other management framework. They claim analyzing logs is tricky and unreliable. I know that this alone can be a subject to big discussion. And as to allowing users/process to choose possibly invalid options the issue is a bit more different. They choose the Feature that is correct and they want it to be installed. The problem is, that the system they try to get the feature installed on is not ready. This boils down to somebody not updating the image or physical system with right prerequisites. I certainly realized that the whole thing is not designed correctly. We really need a separate prerequisite checker that is a different entity than installer. This however does not come overnight. The legacy code is relatively complex and intricate (120 custom actions). So, yes it is not structured well and big overhaul is needed but nobody wants to approve the change knowing it is costly and risky. This has obviously very little do with WiX per se. Thanks a lot Original Message From: Nick Ramirez Sent: Friday, December 5, 2014 12:54 To: wix-users@lists.sourceforge.net Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem You said that you wanted this to work through automation when deployed to various machines. Having a message might not be necessary, if, using a feature condition, you never allow the installer to get into a bad state in the first place. Allowing a user (or automated process) to choose a possibly invalid feature and then later on, tell them they chose something that's not allowed...forcing them to deal with that...is going to be a tougher MSI to install than if you'd used feature conditions. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Condition-problem-tp7598403p7598447.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Deploying multiple cultures using Burn/MSI(s). Wix 3.9 issue??
Based on input in this thread I concluded that using embedded transforms would not work in a Burn driven scenario reliably. At the time I had difficulty understanding how to allow the packages to be created with multiple cultures in separate output folders and then pull those back into the bundle. I posted this question and got good advice. http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-external-cab-for-multiple-language-msi-packages-td7596991.html When a package builds, it uses an external cab file, and builds the output of that package project to separate culture named output folders (default behavior of wix). Then in the bundle's I rename the package like this Fragment PackageGroup Id='App' PackageGroupRef Id='App_de_DE'/ PackageGroupRef Id='App_en_US'/ /PackageGroup /Fragment Fragment PackageGroup Id='App_de_DE' MsiPackage Id='App_de_DE' ...stuff... SourceFile='de-DE\App.msi' Name='App\App_de-DE.msi' /MsiPackage /PackageGroup /Fragment Fragment PackageGroup Id='App_en_US' MsiPackage Id='App_en_US' ...stuff... SourceFile='_en_US\App.msi' Name='App\App_en_US.msi' /MsiPackage /PackageGroup /Fragment The packages are not compressed so the renamed msi and related external cab file end up in a sub folder relative to the bundle named App. The tree is much larger than when transforms are used, but since we stage to a server and the customer only gets the small bootstrapper exe (and the packages that their configuration needs), this seems to work for use. Others in this list mentioned using the transforms external to the msi, but I can't speak to that process. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Deploying-multiple-cultures-using-Burn-MSI-s-Wix-3-9-issue-tp7596896p7598452.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition problem
Did you set a condition level under the feature Id?? Condition Level=1![CDATA[Your condition]]/Condition On Fri, Dec 5, 2014 at 9:27 AM, Marek Mielcarek mmielca...@actuate.com wrote: Thank you for your help Jeremiah. I actually tried that before I sent the message to this group. Apparently, it is not allowed to place Condition with a message inside a Feature. WiX compiler generates this: The Condition element contains an unexpected attribute 'Message' :( -Original Message- From: Jeremiahf [mailto:jeremi...@gmail.com] Sent: Friday, December 05, 2014 10:16 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem That makes a little more sense now. Try placing a condition in your feature that includes a condition message. The condition message should reference the condition using similar to what Pavan gave an example of. example for .net 4 detection just to give you an idea of what I am talking about: !--.NET 4.0 Installation detection-- Property Id=NETFRAMEWORK40CLIENT RegistrySearch Id=NetFramework40Client Root=HKLM Key=SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client Name=Install Type=raw / /Property !--.NET 4.0 Condition message-- Condition Message=This application requires .NET Framework 4.0. Please install the .NET Framework then run this installer again ![CDATA[Installed OR NETFRAMEWORK40CLIENT]] /Condition Does it make sense how the message is related to the condition? This will pop up a message and stop the installation. This installer will never complete until the condition is met. On Thu, Dec 4, 2014 at 8:56 PM, Marek Mielcarek mmielca...@actuate.com wrote: I appreciate your help. The problem is that the installer is mainly used as command-line without any GUI. The package gets pushed to several machines and executed with several options (features) enabled or disabled, depending on deployment automation schema. There might be 100+ servers involved. My installer might be directed to deploy a feature that requires IIS but server might not have it. In reality, the situation is even more complex as there are other features that need to check for other prerequisites (i.e. MSMQ, specific OLDB drivers etc). I started leaning toward custom actions that can break installation process if they cannot detect something they should. I wanted to avoid that hoping there is something cleaner. Thanks a lot. Original Message From: Pavan Konduru Sent: Thursday, December 4, 2014 21:46 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem You should set up the next button in the feature selection screen to display a dialog that IIS is required for that feature(if selected). MyCustomizeDLg is the dialog that has the list of the your features user can select. IISFOUND is a property you set to search for IIS present or not(I think WIX has an in-built property to do this IISMAJORVERSION). FeatureneedsIIS is the feature that requires IIS. Something like this: Publish Dialog=MyCustomizeDlg Control=Next Event=NewDialog Value=IISNotFoundDlg![CDATA[NOT IISFOUND AND (FeatureneedsIIS = 3 AND ! FeatureneedsIIS 3)]]/Publish In the dialog that shows the message to the user redirect the OK button to exit dialog. Control Id=OK Type=PushButton X=102 Y=90 Width=56 Height=17 Default=yes Cancel=yes Text=OK Publish Event=EndDialog Value=Return1/Publish /Control -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Thursday, December 04, 2014 3:06 PM To: wix-users@lists.sourceforge.net; General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem Example: one of the features requires IIS. Check for IIS should occur only if the feature is selected. If te check succeeds, the feature shall be installed. If it fails, the installation shall fail. If feature is not selected the IIS does not matter. Original Message From: Pavan Konduru Sent: Thursday, December 4, 2014 18:00 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem Can give an example so it will be easier to understand? What are the conditions and what do the features depend on? -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Thursday, December 04, 2014 2:28 PM To: wix-users@lists.sourceforge.net; General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem User can select any feature. Each feature has a different condition. Installer verifies the condition for feature if it was selected for installation. If the condition is not met, installer breaks and informs what was the reason.
Re: [WiX-users] Condition problem
Now I see the rest of the threads. :/ On Fri, Dec 5, 2014 at 2:13 PM, Jeremiahf jeremi...@gmail.com wrote: Did you set a condition level under the feature Id?? Condition Level=1![CDATA[Your condition]]/Condition On Fri, Dec 5, 2014 at 9:27 AM, Marek Mielcarek mmielca...@actuate.com wrote: Thank you for your help Jeremiah. I actually tried that before I sent the message to this group. Apparently, it is not allowed to place Condition with a message inside a Feature. WiX compiler generates this: The Condition element contains an unexpected attribute 'Message' :( -Original Message- From: Jeremiahf [mailto:jeremi...@gmail.com] Sent: Friday, December 05, 2014 10:16 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem That makes a little more sense now. Try placing a condition in your feature that includes a condition message. The condition message should reference the condition using similar to what Pavan gave an example of. example for .net 4 detection just to give you an idea of what I am talking about: !--.NET 4.0 Installation detection-- Property Id=NETFRAMEWORK40CLIENT RegistrySearch Id=NetFramework40Client Root=HKLM Key=SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client Name=Install Type=raw / /Property !--.NET 4.0 Condition message-- Condition Message=This application requires .NET Framework 4.0. Please install the .NET Framework then run this installer again ![CDATA[Installed OR NETFRAMEWORK40CLIENT]] /Condition Does it make sense how the message is related to the condition? This will pop up a message and stop the installation. This installer will never complete until the condition is met. On Thu, Dec 4, 2014 at 8:56 PM, Marek Mielcarek mmielca...@actuate.com wrote: I appreciate your help. The problem is that the installer is mainly used as command-line without any GUI. The package gets pushed to several machines and executed with several options (features) enabled or disabled, depending on deployment automation schema. There might be 100+ servers involved. My installer might be directed to deploy a feature that requires IIS but server might not have it. In reality, the situation is even more complex as there are other features that need to check for other prerequisites (i.e. MSMQ, specific OLDB drivers etc). I started leaning toward custom actions that can break installation process if they cannot detect something they should. I wanted to avoid that hoping there is something cleaner. Thanks a lot. Original Message From: Pavan Konduru Sent: Thursday, December 4, 2014 21:46 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem You should set up the next button in the feature selection screen to display a dialog that IIS is required for that feature(if selected). MyCustomizeDLg is the dialog that has the list of the your features user can select. IISFOUND is a property you set to search for IIS present or not(I think WIX has an in-built property to do this IISMAJORVERSION). FeatureneedsIIS is the feature that requires IIS. Something like this: Publish Dialog=MyCustomizeDlg Control=Next Event=NewDialog Value=IISNotFoundDlg![CDATA[NOT IISFOUND AND (FeatureneedsIIS = 3 AND ! FeatureneedsIIS 3)]]/Publish In the dialog that shows the message to the user redirect the OK button to exit dialog. Control Id=OK Type=PushButton X=102 Y=90 Width=56 Height=17 Default=yes Cancel=yes Text=OK Publish Event=EndDialog Value=Return1/Publish /Control -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Thursday, December 04, 2014 3:06 PM To: wix-users@lists.sourceforge.net; General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem Example: one of the features requires IIS. Check for IIS should occur only if the feature is selected. If te check succeeds, the feature shall be installed. If it fails, the installation shall fail. If feature is not selected the IIS does not matter. Original Message From: Pavan Konduru Sent: Thursday, December 4, 2014 18:00 To: General discussion about the WiX toolset. Reply To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem Can give an example so it will be easier to understand? What are the conditions and what do the features depend on? -Original Message- From: Marek Mielcarek [mailto:mmielca...@actuate.com] Sent: Thursday, December 04, 2014 2:28 PM To: wix-users@lists.sourceforge.net; General discussion about the WiX toolset. Subject: Re: [WiX-users] Condition problem User can select any feature. Each feature has a different condition. Installer verifies the condition for feature if it was selected
Re: [WiX-users] multiple product codes returned from Upgrade code
Thanks for the help Nick and Phil! You guys have helped me a lot here. I am beginning to see the light. I've got SAME_VERSION set to NOT only-detect because we use the 4th part of the version number for upgrades. I've got to allow version 1.0.0x150 to upgrade 1.0.0x149, for example. I have a custom action that runs after FindRelatedProducts which manipulates the SAME_VERSION, NEWERPRODUCTFOUND and UPGRADEFOUND properties based on the 4th part of the version number. We've basically implemented 4th part-of-the-version-number support for development builds. I'm hoping that the Language= element of the UpgradeVersion element will help here because I read somewhere that MSI will return only the product number that has this specified language ID. Then I should get just one product code in UPGRADEFOUND. I have not tested this yet though - tomorrow's task. I really don't want to (can't?) change upgrade codes for each language version now, or at least I have not thought this all the way through yet. This product got released already, so I have to deal with existing installs. And Phil! Separate upgrade codes for different languages? Great Idea! This sounds like the right way to do it. I will do that next time. ;-) (Boo hoo - I wish I would have thought of that sooner!) Any insight you guys might have into this aspect of it would be greatly appreciated. Thanks again, GAP -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/multiple-product-codes-returned-from-Upgrade-code-tp7598400p7598456.html Sent from the wix-users mailing list archive at Nabble.com. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
