Re: [WiX-users] Component/@Guid error
Not sure what the problem actually was. I scrapped what I had, and started over. Everything working now as expected. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Component-Guid-error-tp7579390p7581179.html Sent from the wix-users mailing list archive at Nabble.com. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems executing two custom actions with same button click
Add a condition of '1' to each Publish directive, and see if that helps. The WiX help links to the MSDN pages for Windows Installer for a reason. From the ControlEvent Table you will find the following statement: Condition A conditional statement that determines whether the installer activates the event in the Event column. The installer triggers the event if the conditional statement in the Condition field evaluates to True. Therefore put a 1 in this column to ensure that the installer triggers the event. The installer does not trigger the event if the Condition field contains a statement that evaluates to False. The installer does not trigger an event with a blank in the Condition field unless no other events of the control evaluate to True. If none of the Condition fields for the control named in the Control_ field evaluate to True, the installer triggers the one event having a blank Condition field, and if more than one Condition field is blank it triggers the one event of these with the largest value in the Ordering field. See Conditional Statement Syntax. Which should explain the behavior and the solution. hope this helps, bill -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Problems-executing-two-custom-actions-with-same-button-click-tp7580803p7580857.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] define element for ProgramFilesFolder not working in include file :(
try Property ... SupressModularization=yes/ -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/define-element-for-ProgramFilesFolder-not-working-in-include-file-tp7580463p7580487.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Assistance with creating a patch
I cannot suggest a solution for the patch problem you currently have, but I might be able to suggest an alternative. I was unable to use the pure WiX patching technique, as I was attempting to patch a file in a merge module. The WiX help describes two methods of patch generation, the first WiX only (using pyro and torch), the second using patch creation properties. I was successfully able to generate a patch using this method. Using an administrative install from the original, and one from the patch, you can then generate a patch with the following commands: candle -o %PATCH%.wixobj PatchCreation.wxs light -o %PATCH%.pcp %PATCH%.wixobj msimsp -s %PATCH%.pcp -p patch/%PATCH%.msp -l %PATCH%.log I was able to build the sample patch as outlined in the help, then extend/modify the patch creation file to suit. good luck, bill -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Assistance-with-creating-a-patch-tp7579419p7579692.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Component/@Guid error
Rob, Unless I am mistaken, that criteria: [no] Property substitutions ... is only relevant if I am asking WiX to generate the Guid; which seems to be indicated in the initial message. The Component/@Guid attribute's value '*' is not valid for this component... What has me confused is that the Guid is explicitly specified, and is not generated. I don't understand why the error is posted. The component was acceptable within the mergemodule (WiX happily generated the merge module). But it is choking since I moved it into a lib. thanks, bill -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Component-Guid-error-tp7579390p7579405.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] AppId, Class and ProgId elements
I am attempting to create AppId, Class and ProgId entries instead of using
raw registry key/value elements, which generate warnings. In the
documentation for Class it has the following entry:
SafeForInitializing
In General
Value yes specified:
[HKCR\CLSID\{Id}\Implemented
Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
Specific Example
[HKCR\CLSID\{01234567-89AB-CDEF-0123-456789ABCDEF}\Implemented
Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
SafeForInitializing
In General
Value yes specified:
[HKCR\CLSID\{Id}\Implemented
Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
Specific Example
[HKCR\CLSID\{01234567-89AB-CDEF-0123-456789ABCDEF}\Implemented
Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
My question is, where do the Implemented Categories come from? Are these
supposed to be additional RegistryKey elements? Or is there some way to
specify this information within the Class element?
I need the following.
HKCR\CLSID\{GUID0}\Implemented Categories\{GUID1}
HKCR\CLSID\{GUID0}\Implemented Categories\{GUID2}
HKCR\CLSID\{GUID0}\Implemented Categories\{GUID3}
I also have entries under AppId that do not have a GUID, for example:
HKCR\AppId\exename.exe. However, the pattern constraint for the AppId Id
field requires a GUID. I guess I use RegistryValue for these.
thanks,
bill
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/AppId-Class-and-ProgId-elements-tp6916937p6916937.html
Sent from the wix-users mailing list archive at Nabble.com.
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Build speed, suggestions?
Chris, John, Thanks for the suggestions. I tried a vm with Server 2008 as a base OS (instead of 2003) and it seems to help considerably. I did a couple of trials and the set of merge modules took only 10+ minutes. The 2003 based vm takes ~ 90 minutes. The real hardware (with 2003) takes about 20-30 minutes. I haven't yet attempted to quantify what the bottleneck is/was, but moving to Server 2008 seems to be the simplest mechanism moving forward. thanks, bill -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Build-speed-suggestions-tp5616138p5627789.html Sent from the wix-users mailing list archive at Nabble.com. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Passing Values from the ProductModule to a MergeModule
I think you can simplify what you have: Property Id=SERVICEUSER SuppressModularization=yes/ Property Id=SERVICEPASSWORD SuppressModularization=yes/ Directory Id=TARGETDIR Name=SourceDir Directory Id=MergeRedirectFolder Component Id=ServiceInstaller Guid=* DiskId=1 ServiceInstall Id=ServiceInstaller Name=XPedientServiceHost Start=auto ErrorControl=normal Type=ownProcess Account=[SERVICEUSER] Password=[SERVICEPASSWORD] /ServiceInstall /Component /Directory /Directory Then simply pass in on the command line SERVICEUSER and SERVICEPASSWORD. You should not need the custom actions and multiple properties for the same elements. You may need to mark the properties as secure to get them to the execute sequence. As for using the module configuration, I didn't find it trivial. Here is an example that reparents an entry in the merge module's directory table with a property from the msi: in the merge module you would have: Configuration Name=SMPRODNAME Format=Key Type=Identifier DefaultValue=SMPRODNAME Description=Start Menu Path DisplayName=Start Menu Folder/ Substitution Table=Directory Column=Directory_Parent Row=SMHelp Value=[=SMPRODNAME]/ Directory Id=TARGETDIR Name=SourceDir Directory Id=SMHelp Name=Help Documentation ShortName=HELPDOC / ... /Directory The configuration updates the directory table changing the parent of the SMHelp to be the SMPRODNAME property. This happens when the merge module is imported by the msi. The SMPRODNAME property does not have to be defined anywhere in the merge module. hope this helps -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-Values-from-the-ProductModule-to-a-MergeModule-tp5318970p5321075.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Am I doing something wrong, or is this a bug?
I am attempting to build a project which contains a couple of rtf files outside the msi. I have built a small Project.wxs that displays the issue. In the project I have two components, each with a single file. One is embedded, the other may not be. When the Package is set to Compressed=yes the external file cannot be found - the msi expects it to be in the SourceRoot, even though it is supposed to be in a subordinate folder. If all files are compressed, or the Package default is Compressed=no, everything works correctly. If not compressed, the licenseagreement.rtf should be in SourceRoot/RTF. Adding a Layout directive to the uncompressed media has no effect (if the Package default is compressed). The Source directive is apparently only for patches, and is ignored. Wix version 3.0.5419 ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=* Name=KepTest Language=1033 Version=1.0.0.0 Manufacturer=Kepware UpgradeCode=* Package InstallerVersion=301 Compressed=yes / !-- Comment out the ExternalOEMFolder define if all files are to be compressed in the MSI -- ?define ExternalOEMFolder ? Media Id=1 Cabinet=media1.cab EmbedCab=yes / ?ifdef ExternalOEMFolder ? Media Id=2 EmbedCab=no/ ?define CompressExternal=no ? ?else? Media Id=2 EmbedCab=yes Cabinet=RTF.cab/ ?define CompressExternal=yes ? ?warning ExternalOEMFolder is not defined, all files will be compressed!? ?endif? Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=RTFSDIR Name=RTF/ Directory Id=INSTALLDIR Name=KepTest /Directory /Directory /Directory DirectoryRef Id=INSTALLDIR DiskId=1 FileSource=_buildout Component Id=Server.exe Feature=ProductFeature Guid=* CreateFolder Directory=INSTALLDIR/ File Id=Server.exe Name=server.exe KeyPath=yes Checksum=yes Compressed=yes/ /Component /DirectoryRef DirectoryRef Id=RTFSDIR DiskId=2 FileSource=External Component Id=licenseagreement.rtf Feature=ProductFeature Guid=* File Id=LicenseAgreement.rtf Name=licenseagreement.rtf KeyPath=yes Compressed=$(var.CompressExternal)/ /Component /DirectoryRef Feature Id=ProductFeature Title=KepTest Level=1 /Feature !-- This action resets the external directory to the INSTALLDIR so that rtf files are correctly placed -- CustomAction Id=Set_RTFSDIR Property=RTFSDIR Value=[INSTALLDIR] / InstallExecuteSequence Custom Action=Set_RTFSDIR After=ValidateProductID/ /InstallExecuteSequence /Product /Wix thanks, bill -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Am-I-doing-something-wrong-or-is-this-a-bug-tp5154423p5154423.html Sent from the wix-users mailing list archive at Nabble.com. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition Table generation
Mike, Basically I need to adjust the feature tree for each MSI. Each of the 10 MSIs is a distinct product package with a unique upgrade code. Payload is attached to features via mergemodules. If the feature tree contains features A and B, with sub-features A0 - An, B0 - Bn, the first MSI could contain all items in the tree. While subsequent MSIs would only contain a subset of all items, possibly only a single sub-feature. In the Wise implementation each MSI project contained its own copy of the condition table, but a consistent copy of the feature table (this allowed changes to the tree without requiring changes to each MSI project, only a synchronizing/replacement of the feature table). If a feature was not to be included for a specific MSI, that condition table would contain a row setting the feature level to zero (the merge module reference would also be stripped out in another step). Thus the resultant MSI would only display features that were relevant and had payload. It may be that FeatureGroups are what I need, although the condition table seems better encapsulated. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Condition-Table-generation-tp5085798p5093810.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Condition Table generation
Ultimately I am controlling what the user sees, the stripping out of the merge modules is simply reducing the size of the package. Using the condition table I have a consistent feature table for all packages, and encapsulate exclusions within each package. Probably FeatureGroups will work, but at the expense of decomposing the feature tree to isolate pieces that are now or may later be excluded. Instead of having a consistent feature table which I can make into a wixlib, I need to create a series of FeatureGroups and build the tree in each project. More work, less encapsulation, more duplication. Enhancing Wix with the ability to specify a Condition as a child of the FeatureRef would allow the feature tree to remain intact, with FeatureRef entries describing the condition table in each Product /. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Condition-Table-generation-tp5085798p5095129.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
