[WiX-devs] 您好,好久没有联系了还记得我吗?
您好,好久没有联系了还记得我吗? 福建我要性福一生两性乐园 http://www.51xf13.cn/ 福建最大的平价成人用品商城，打造良好的网上购物环境，真正实现货到付款，让你放心消费！http://www.51xf13.cn/ 亦可低价批发,代发货等业务. 本店出售: 情趣内衣 男用健慰器 美国伟哥 成人用品 女用健慰器 男用健慰器 丰胸 性保健品 性用品 SM用品 充气娃娃 maxman二代 情趣内衣 品牌产品!值得信赖!本商城货种齐全,最新引进美国壮阳产品,缩紧阴 道的产品 绝对无副作用!绿色安全,价格优惠!欢迎惠顾! 本商城的宗旨:拒绝款到发货,坚持货到付款(也支持财付通交易).打击网上骗子! 本商城为打击网上骗子,特与(宅急送,全一)快递公司签定了货到付款业务.全国2000多个城市提供货到付款交易让广大网友可放心消费! 为广大网友提供一个良好的网上购物环境,同时提供成人用品批发、代发货，实力强大。诚信第一,欢迎惠顾！更多精品尽在http://www.51xf13.cn/ (福建我要性福一生两性乐园)福建最大 的平价商城诚信第一,欢迎惠顾! 本邮件为群发邮件以上信息如有打扰,请谅解!欢迎光临本商城! 福建我要性福一生两性乐园 http://www.51xf13.cn/ 祝您身体健康,合家欢乐! - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1744399 ] NetFx extension uses duplicate RegSearch IDs
Bugs item #1744399, was opened at 2007-06-27 11:45 Message generated for change (Comment added) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1744399group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: extensions Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonatin (jonatin) Assigned to: pmarcu (pmarcu) Summary: NetFx extension uses duplicate RegSearch IDs Initial Comment: The .NET detection properties in the NetFx extension use duplicate RegSearch IDs when searching for the installation key and the service pack keys. Example: RegistrySearch Id=NetFramework11 ... Name=Install ... RegistrySearch Id=NetFramework11 ... Name=SP ... This causes the following light.exe error when both the installation and SP properties are referenced in a .wxs: C:\delivery\Dev\wix_public\src\ext\NetFxExtension\wixlib\NetFxExtension.wxs(33): error LGHT0130: The primary key 'NetFramework11' is duplicated in table 'RegLocator'. Please remove one of the entries or rename a part of the primary key to avoid the collision. I would suggest changing the duplicate 'NetFramework11' and 'NetFramework20' IDs to 'NetFramework11SP' and 'NetFramework20SP' or the like. Many Thanks! -- Comment By: pmarcu (pmarcu) Date: 2007-10-01 10:41 Message: Logged In: YES user_id=1612676 Originator: NO Already fixed? I seem to recall this being fixed about 3 months ago. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1744399group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1744025 ] invalid image on tlb with heat
Bugs item #1744025, was opened at 2007-06-27 00:52 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1744025group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: heat Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: RvdEls (rvdels) Assigned to: pmarcu (pmarcu) Summary: invalid image on tlb with heat Initial Comment: When I try to harvest a tlb file with heat I get the following erro: The application DLL full-path-to-my-tlb-file is not a valid Windows image. Please check this against your installation diskette. The strange thing is that I get this error on one machine but not on another machine. Both machine run Windows XP SP2 and heat version 3.0.3015.0 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1744025group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1745315 ] ICE54 - Bug in Wix2 (2.0.5325.0)
Bugs item #1745315, was opened at 2007-06-29 06:20 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1745315group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: v2.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Pavlik (vydra) Assigned to: pmarcu (pmarcu) Summary: ICE54 - Bug in Wix2 (2.0.5325.0) Initial Comment: WiX2 2.0.5325.0 Consider following code: Component Id=C_Core_dll Guid=... File Id=Core_dll Name=Core.DLL Vital=yes KeyPath=yes DiskId=1 Checksum=yes / /Component Component Id=C_SQLite_dll Guid=... File Id=Sqlite_dll Name=Sqlite.DLL Vital=yes DiskId=1 Checksum=yes CompanionFile=Core_dll KeyPath=no / /Component Validation of resultin package ends with warning from ICE54: Component 'C_SQLite_dll' uses file 'SQLite_dll' as its KeyPath, but the file's version is provided by the file 'Core_dll'. After clearing the KeyPath value (in MSI Component Table) manualy the ICE54 runs OK. It seems that specifying KeyPath='no' is ignored by WiX. -- Comment By: Stefan Pavlik (vydra) Date: 2007-06-29 06:22 Message: Logged In: YES user_id=1249288 Originator: YES Rob Mensching wrote: The work around is quite simple. Specify the Component/@KeyPath=yes and that will correctly set the KeyPath. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1745315group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1740296 ] Missing localization strings in 3.0.3015.0
Bugs item #1740296, was opened at 2007-06-20 05:13 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1740296group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: wixui Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Minor (drseltsam) Assigned to: Bob Arnson (barnson) Summary: Missing localization strings in 3.0.3015.0 Initial Comment: There are some german translations missing in the file WixUI_de-de.wxl. Since the use of this UI isn't possible out of the box, I translated the missing Strings. I hope you can put them in for the next build. String Id=MaintenanceTypeDlgRemoveDisabledText Overridable=yes[ProductName] kann nicht entfernt werden./String String Id=MaintenanceTypeDlgRepairDisabledText Overridable=yes[ProductName] kann nicht repariert werden./String String Id=UITextNewFolder Overridable=yesOrdner|Neuer Ordner/String -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1740296group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1805836 ] Shortcut documentation not in HTML
Bugs item #1805836, was opened at 2007-10-01 18:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1805836group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Ridd (chrisridd) Assigned to: Nobody/Anonymous (nobody) Summary: Shortcut documentation not in HTML Initial Comment: The web page describing the Shortcut schema element is almost completely blank. http://wix.sourceforge.net/manual-wix2/wix_xsd_shortcut.htm -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1805836group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1730786 ] ICE45 wanrings with ElevationShield=yes
Bugs item #1730786, was opened at 2007-06-04 08:43 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1730786group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wieser Software Ltd (wiesersoftware) Assigned to: pmarcu (pmarcu) Summary: ICE45 wanrings with ElevationShield=yes Initial Comment: As described on the users list, various problems occur with different versions of darice.cub when the Elevation shield is requested. I've entered this as a bug at Bob Arnson's request along with a sample MSI. The MSI file installs my minimal wxs and wixproj files to PROGRAMFILESDIR\Shield Bug -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1730786group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1724550 ] Patch build process should insert the PatchFiles action
Bugs item #1724550, was opened at 2007-05-23 17:37 Message generated for change (Comment added) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1724550group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pyro Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aaron Stebner (aaronste) Assigned to: pmarcu (pmarcu) Summary: Patch build process should insert the PatchFiles action Initial Comment: All patches should contain a PatchFiles action that is scheduled between InstallFiles and DuplicateFiles. The PatchWiz tool in the Windows Installer SDK always inserts a PatchFiles action into the InstallExecuteSequence with every patch it builds. The WiX patch build process should also do this. Also, we need to make sure that we schedule PatchFiles between InstallFiles and DuplicateFiles in patches created by WiX. The information in the PatchFiles MSDN documentation (http://msdn2.microsoft.com/en-us/library/aa370577.aspx) provides more detail about these scenarios: The PatchFiles action queries the Patch table to determine which patches are to be applied. The PatchFiles action also performs the byte-wise patching of the files. If the file that is to be patched is not installed, the PatchFiles action must come after the InstallFiles action that installs the file. Previously installed files may be patched at any point in the action sequence. The DuplicateFiles Action must come after the PatchFiles action to prevent duplicating the unpatched version of the file. Doing this work provides parity with the existing PatchWiz tool and allows support for delta patching scenarios. -- Comment By: pmarcu (pmarcu) Date: 2007-10-01 11:04 Message: Logged In: YES user_id=1612676 Originator: NO Need to make sure this is done when delta patching gets implemented. -- Comment By: Blair (bmurri) Date: 2007-09-07 13:51 Message: Logged In: YES user_id=1765232 Originator: NO I will do this. -- Comment By: Blair (bmurri) Date: 2007-07-06 13:50 Message: Logged In: YES user_id=1765232 Originator: NO Since whole files in a patch do not have entries in the Patch table, should this action still be added if the Patch table is empty/missing? The PatchFiles action is driven by that table. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1724550group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1722921 ] dir argument cannot have a trailing /
Bugs item #1722921, was opened at 2007-05-21 11:45 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1722921group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: heat Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: rowland (rowlandsdms) Assigned to: pmarcu (pmarcu) Summary: dir argument cannot have a trailing / Initial Comment: Version 3.0.2420.0 When the value of the dir argument has a trailing / The root directory fragment is created with a blank Name attribute, and what appears to be a default Id. ex. Directory Id=Directory Name= / -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1722921group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1722516 ] Same name, wrong file
Bugs item #1722516, was opened at 2007-05-21 02:39
Message generated for change (Comment added) made by pmarcu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=642714aid=1722516group_id=105970
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: light
Group: v3.0
Status: Open
Resolution: None
Priority: 1
Private: No
Submitted By: Jonas Eriksson (jayee)
Assigned to: pmarcu (pmarcu)
Summary: Same name, wrong file
Initial Comment:
I'm creating an installation which holds several files with filenames that are
identical but they reside in different directories. I have used heat to build
the file list as shown below. What happens is that I have 2 files with the same
name (resource.h) in different directories and during installation the same
file is copied to both directories. There seems to be a problem with spaces in
the Source tag as the file content is the same in all directories which starts
the same (before the space). The name of the file is copied correctly,
resource.h vs Resource.h like in the sample below, but the content and
timestamp comes from the second file.
I think this is a bug in the light command, but maybe it can be in the candle
instead.
I've used the build from 2007-05-11 (3.0.2911.0) but older builds (from feb)
give the same result.
?define Src=..\release\ ?
Fragment
DirectoryRef Id=ex_1
Component Id=resource.h_1
Guid={6E1DBB54-C726-48C2-BE9C-5831999A42AC}
File Id=resource.h_1 Name=resource.h KeyPath=yes
Source=$(var.Src)Samples\ex 1\resource.h /
/Component
/DirectoryRef
/Fragment
Fragment
DirectoryRef Id=ex_2
Component Id=Resource.h_1
Guid={463578C2-66F5-487F-9D7D-1AA7A509E4F5}
File Id=Resource.h_1 Name=Resource.h KeyPath=yes
Source=$(var.Src)Samples\ex 2\Resource.h /
/Component
/DirectoryRef
/Fragment
--
Comment By: pmarcu (pmarcu)
Date: 2007-10-01 11:09
Message:
Logged In: YES
user_id=1612676
Originator: NO
I think light and heat should both catch this.
--
Comment By: Bob Arnson (barnson)
Date: 2007-05-21 17:27
Message:
Logged In: YES
user_id=26581
Originator: NO
The CAB format doesn't support two file IDs that differ only by case. It's
undefined which file will be produced when the different IDs are supplied.
The bug here is that WiX should be noting that the IDs aren't distinct.
Unfortunately, neither light nor heat detects/warns about it. If you change
the File/@Id attribute, you'll be fine.
--
Comment By: Jonas Eriksson (jayee)
Date: 2007-05-21 04:26
Message:
Logged In: YES
user_id=799656
Originator: YES
Further investigation shows that the space in the Source tag does not
matter.
What matters is the File Id string... it is not case sensitive, and I
don't know if it should/must be.
Either heat.exe should not just make a case difference between the files,
or (better) the candle/light should be able to differ between the casing.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=642714aid=1722516group_id=105970
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1719357 ] CoreClean blindly deletes all previously built files
Bugs item #1719357, was opened at 2007-05-15 08:01 Message generated for change (Comment added) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1719357group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: msbuild Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Doug S (tpaxatb) Assigned to: pmarcu (pmarcu) Summary: CoreClean blindly deletes all previously built files Initial Comment: The target CoreClean in wix.targets will blindly delete ALL files that had been previously built, even if that file is outside of the current build directory structure (i.e. is in a different project configuration). This means that if I do a REBUILD of a Debug configuration and then a Release configuration, the Release configuration will delete all of the DEBUG configuration's files (because the DEBUG configuration wrote those filenames to the BaseIntermediateOutputPath\CleanFile, which is shared amongst all configurations. 3.0.2911.0 -- Comment By: pmarcu (pmarcu) Date: 2007-10-01 11:12 Message: Logged In: YES user_id=1612676 Originator: NO ccampbell, do you still have fixes you would like to contribute? If so, let me know. -- Comment By: Craig Campbell (ccampbell) Date: 2007-05-21 17:06 Message: Logged In: YES user_id=188467 Originator: NO I have been working on integrating wix 3.0 with our current build process. I have also found several problems with the way the wix.targets file builds the wix project. I've made a few changes that I would like to submit back to the project if there is some interest. The changes consist of aligning the current wix.targets file more closely to the other language specific targets files (i.e. Microsoft.CSharp.targets) in that we leverage the Microsoft.Commons.targets file and reuse several of their utility targets such as ResolveProjectReferences, CopyFilesToOuputDirectory, Pre/Post build events. This has allowed a more consistent integration point for custom build steps to happen before and after the core build steps. Oh, and it also fixes the deleting of other configuration builds problem as well. --Craig -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1719357group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1717558 ] Native assembly manifest reference fails
Bugs item #1717558, was opened at 2007-05-11 20:30 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1717558group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Doug S (tpaxatb) Assigned to: pmarcu (pmarcu) Summary: Native assembly manifest reference fails Initial Comment: When building a native assembly, in order to properly generate all the MsiAssembly tables, the files in the assembly's component must be listed in the order: Component Id=x86Assembly Guid=19715da1-4604-4d14-a60a-4e5b1b6e71b7 File Id=Dllx86 Assembly=win32 Name=ImageProcessing.Quality.dll KeyPath=yes AssemblyManifest=Manifestx86 / File Id=Catalogx86 Name=ImageProcessing.Quality.dll.cat / File Id=Manifestx86 Name=ImageProcessing.Quality.dll.manifest / /Component Otherwise, a LGHT0104 error occurs because the manifest parser reads the incorrect file. It took a lot of trial and error to figure this out. Note that suppressing the MsiAssembly or MsiAssemblyName table generation causes a succeed. In addition, when the AssemblyManifest attribute is removed from the key file's element, the MsiAssemblyName table is still generated correctly, seemingly reading the manifest file even though I didn't tell WiX which file to use. -- Comment By: Doug S (tpaxatb) Date: 2007-05-12 06:54 Message: Logged In: YES user_id=1342505 Originator: YES Quick update, it seems that light is ignoring the AssemblyManifest attribute and only finding the last filerow speficied in the table. I have 3 native assemblies in the project and they all use the last manifest in the table. In Binder.cs, there seems to be a comment to reveiew the logic. The only workaround I have found is to suppress the generation of the MsiAssemblyName table and manually create assembly references (ummm, the project has 43 assemblies, not very feasible!) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1717558group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1716583 ] website command throws COMException
Bugs item #1716583, was opened at 2007-05-10 08:22 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1716583group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: heat Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: suedeuno (suedeuno) Assigned to: pmarcu (pmarcu) Summary: website command throws COMException Initial Comment: heat.exe : error HEAT0001 : Unknown error (0x80005000) Exception Type: System.Runtime.InteropServices.COMException Stack Trace: at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_Name() at Microsoft.Tools.WindowsInstallerXml.Extensions.IIsWebSiteHarvester.Harvest WebFilter(DirectoryEntry webFilterEntry) at Microsoft.Tools.WindowsInstallerXml.Extensions.IIsWebSiteHarvester.Harvest WebSite(DirectoryEntry webSiteEntry) at Microsoft.Tools.WindowsInstallerXml.Extensions.IIsWebSiteHarvester.Harvest WebSite(String name) at Microsoft.Tools.WindowsInstallerXml.Extensions.IIsWebSiteHarvester.Harvest (String argument) at Microsoft.Tools.WindowsInstallerXml.Harvester.Harvest(String argument) at Microsoft.Tools.WindowsInstallerXml.Tools.Heat.Run(String[] args) -- Comment By: Bob Arnson (barnson) Date: 2007-05-12 10:30 Message: Logged In: YES user_id=26581 Originator: NO 0x80005000 means: E_ADS_BAD_PATHNAME An invalid directory pathname was passed -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1716583group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1714496 ] Light fails when authoring MSI file limit
Bugs item #1714496, was opened at 2007-05-07 11:39 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1714496group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: tammyngu (tammyngu) Assigned to: pmarcu (pmarcu) Summary: Light fails when authoring MSI file limit Initial Comment: The MSI schema was modified to allow 2^32-1 files. When authoring 2^18 files, the setup build fails with an IOException where light fails with the following error: Error: light.exe : error LGHT0001 : The process cannot access the file 'c:\dd\Decatur1_1\src\ddsuites\src\vs\setup\decatur\StressSetup\wix\outs\x86ret\enu\cooked\stress_test01.wixout' because it is being used by another process. When the number of files authored is less than 2^18, the setup build passes. -- Comment By: Tammy Nguyen (babyana) Date: 2007-05-11 13:27 Message: Logged In: YES user_id=510185 Originator: NO To clarify this bug, the build is failing to create the MSI when authoring the maximum number of files allowed. This is specified in the WiX default schema. The denied access to the wixout seems to occur somewhere between the i2 max and i4 max. -- Comment By: Heath Stewart (heaths) Date: 2007-05-10 20:29 Message: Logged In: YES user_id=1335104 Originator: NO Is this during patch build? What is the repro steps? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1714496group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1713977 ] ConfigurePerfmonUninstall Action sequence incorrect
Bugs item #1713977, was opened at 2007-05-06 17:52 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1713977group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: extensions Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Doug S (tpaxatb) Assigned to: pmarcu (pmarcu) Summary: ConfigurePerfmonUninstall Action sequence incorrect Initial Comment: When using the extension PerfCounter to install a performance counter, and the associated HKLM\SYSTEM\CurrentControlSet\Services\Counter\Performance registry key is set to createAndRemoveOnUninstall, the performance counter language texts are not removed from the registry during an uninstall. This is due to the scheduling of the ConfigurePerfmonUninstall action being sequenced after the RemoveRegistryValues action in the InstallExecuteSequence table. (2600 for RemoveRegistryValues and 2601 for ConfigurePerfmonUninstall). Creating the associated key with a create action will remove the performance counter text, however it will leave the associated key in the registry. In either situation, the installer does not completely clean up itself. By manually scheduling the ConfigurePerfmonUninstall custom action BEFORE the RemoveRegistryValues, the uninstall works as expected. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1713977group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1711440 ] localization variables cannot have . (dot) in the name
Bugs item #1711440, was opened at 2007-05-02 12:01 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1711440group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: rowland (rowlandsdms) Assigned to: pmarcu (pmarcu) Summary: localization variables cannot have . (dot) in the name Initial Comment: Having a localization variable with a dot(.) in the name like so: String Id=FUI_LicenseFileFinder.InfoIcon.ToolTipInformation/String yields a compile error of the form error LGHT0204 : ICE17: Icon: '!(loc.FUI_LicenseFileFinder.InfoIcon)' for Control: 'Icon' of Dialog: 'FUI_LicenseFilesNotFoundDialog' not found in Binary table Removing the dots from the name (and references) gets rid of the compile error. String Id=FUI_LicenseFileFinderInfoIconToolTipInformation/String It would be nice to either support names with dots, or give a better error message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1711440group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1708072 ] Access Violation with Large Cabinets
Bugs item #1708072, was opened at 2007-04-26 07:01 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1708072group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: None Status: Open Resolution: None Priority: 9 Private: No Submitted By: Martin Lavelle (hypercaust) Assigned to: pmarcu (pmarcu) Summary: Access Violation with Large Cabinets Initial Comment: Using WiX V3.0.2806.0 or V3.0.2716.0 I get the following error: Creating cabinet 'C:\WiX\SchemaV\CabCache\Marine1.cab'. light.exe : error LGHT0001 : Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Exception Type: System.AccessViolationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.CabInterop.CreateCabFinish(IntPtr contextHandle) at Microsoft.Tools.WindowsInstallerXml.Cab.WixCreateCab.Dispose() at Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.CreateCabinet(CabinetWorkItem cabinetWorkItem) at Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.ProcessWorkItems() Generating database. It succeeds if I reduce the number of files in the particular cabinet which is failing. All the files will cab, but not all at once. Substituting several small files, with one or two larger (overall) files, does not solve the problem. The problem is repeatable: 1) On different OS's and Hardware. 2) With 1 or 2 threads, or without specifying threads (e.g. -ct 2). 3) With Cabinet Cache (-cc) specified or not. 4) With a different [EMAIL PROTECTED] Number (Not tried Media=1). 5) With different versions of the .Net framework runtime. I've ran the whole build from my C:\ drive to eliminate Network and Source repository possibilities. I can't get the Cabinet larger than 577,667,792 Bytes. As requested, A directory listing in included (I'm not trying to build the 0kb files)... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1708072group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1706949 ] unresolved loc variables when linking patch with .wxl file.
Bugs item #1706949, was opened at 2007-04-24 14:24 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1706949group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: v3.0 Status: Open Resolution: None Priority: 1 Private: No Submitted By: Leo (dangleo) Assigned to: pmarcu (pmarcu) Summary: unresolved loc variables when linking patch with .wxl file. Initial Comment: Attached are the patch wix files. Run the following command line to reproduce: candle.exe -out patch.wixobj patch.wxs light.exe -nologo -out patch.pcp patch.wixobj -loc patch.wxl Wix toolset build version is 2.0.4820.0 From: Bob Arnson [EMAIL PROTECTED] To: Leo ... [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [WiX-users] building pacthes with .wxl files Date: Mon, 23 Apr 2007 20:54:15 -0700 MIME-Version: 1.0 Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by bay0-mc5-f13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 23 Apr 2007 20:56:50 -0700 Received: from sc8-sf-list1-new.sourceforge.net (sc8-sf-list1-new-b.sourceforge.net [10.3.1.93])by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTPid B27A8130DC; Mon, 23 Apr 2007 20:56:48 -0700 (PDT) Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92]helo=mail.sourceforge.net)by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43)id 1HgC8z-00011m-MLfor [EMAIL PROTECTED]; Mon, 23 Apr 2007 20:56:45 -0700 Received: from alnrmhc14.comcast.net ([204.127.225.94])by mail.sourceforge.net with esmtp (Exim 4.44) id 1HgC8z-0002Dq-G1for [EMAIL PROTECTED]; Mon, 23 Apr 2007 20:56:45 -0700 Received: from [192.168.0.103](c-71-231-176-73.hsd1.wa.comcast.net[71.231.176.73])by comcast.net (alnrmhc14) with ESMTPid 20070424035641b14009mueqe; Tue, 24 Apr 2007 03:56:42 + Leo ... wrote: light.exe -nologo -out patch.pcp patch.wixobj -loc patch.wxl the patch.pcp file got build successfully but the $(loc.text) variables didn't expanded/resolved to the actual text defined in the patch.wxl file. Can someone point out my problem. I'd expect it to work. Can you open a bug and attach a minimal repro case? WiX v2 is in lockdown right now, so if it's going to be considered for fixing in v2, we need as much detail as possible. -- sig://boB http://bobs.org - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/wix-users -- Comment By: Bob Arnson (barnson) Date: 2007-04-26 22:05 Message: Logged In: YES user_id=26581 Originator: NO It turns out that none of the PatchCreation elements and family are localizable. It's too big a change to take at this point in the v2 cycle. I'm moving this bug to v3 to finish the loc work (some of it already works). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1706949group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1699453 ] Merge Module Windows Installer Version isn't checked
Bugs item #1699453, was opened at 2007-04-12 11:25 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1699453group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike (mholcomb) Assigned to: pmarcu (pmarcu) Summary: Merge Module Windows Installer Version isn't checked Initial Comment: Expected: When linking a merge module to an MSI, the module's installer version is validated against the product's installer version that it is equal or great. Example that should break/warn: Foo.MSM: InstallerVersion=300 Foo.MSI: InstallerVersion=200 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1699453group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1695663 ] cannot decompile progid tables
Bugs item #1695663, was opened at 2007-04-06 07:35 Message generated for change (Comment added) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1695663group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: dark Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: doug (koawmfot) Assigned to: pmarcu (pmarcu) Summary: cannot decompile progid tables Initial Comment: while trying to fiure out how to match the class/progid tables in the msrdo20.msm, i tried to decompile to see what code i would be given. this is my dark error: C:\test\wix3dark c:\test\msrdo20.msm -out c:\test\msrdo20.wxs Microsoft (R) Windows Installer Xml Decompiler Version 3.0.2730.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. msrdo20.msm dark.exe : error DARK0001 : Item has already been added. Key in dictionary: 'Mic rosoft.Tools.WindowsInstallerXml.Serialize.ProgId' Key being added: 'Microsoft. Tools.WindowsInstallerXml.Serialize.ProgId' Exception Type: System.ArgumentException Stack Trace: at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add ) at System.Collections.Hashtable.Add(Object key, Object value) at Microsoft.Tools.WindowsInstallerXml.Decompiler.FinalizeProgIdTable(TableCo llection tables) at Microsoft.Tools.WindowsInstallerXml.Decompiler.FinalizeDecompile(TableColl ection tables) at Microsoft.Tools.WindowsInstallerXml.Decompiler.Decompile(Output output) at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[] args) C:\test\wix3 -- Comment By: pmarcu (pmarcu) Date: 2007-10-01 11:32 Message: Logged In: YES user_id=1612676 Originator: NO Can you please attach a repro case including the msm that is not decompilable. Thanks! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1695663group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1802341 ] candle -out cannot take a path as argument
Bugs item #1802341, was opened at 2007-09-25 16:15 Message generated for change (Comment added) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1802341group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: v3.0 Status: Open Resolution: None Priority: 9 Private: No Submitted By: Bruno Sabin (bsabin) Assigned to: pmarcu (pmarcu) Summary: candle -out cannot take a path as argument Initial Comment: Using WiX 3.0.3307.0 the command: candle.exe -out localization\xx_french.wixobj xx_french.wxs will output a file called: localizationxx_french.wixobj instead of the expected xx_french.wixobj in a subdirectory called localization (which already exists on the filessytem) -- Comment By: pmarcu (pmarcu) Date: 2007-10-01 09:37 Message: Logged In: YES user_id=1612676 Originator: NO I am not able to reproduce this. I used this commandline: candle -out localization\xx_french.wixobj xx_french.wxs and the xx_french.wixobj file was being properly produced in the localization folder. Bruno, can you try to reproduce this with the latest bits? -- Comment By: sameer garde (sameer_garde) Date: 2007-09-28 15:28 Message: Logged In: YES user_id=1864340 Originator: NO Pri: 1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1802341group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1802341 ] candle -out cannot take a path as argument
Bugs item #1802341, was opened at 2007-09-25 16:15 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1802341group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: v3.0 Status: Open Resolution: Works For Me Priority: 9 Private: No Submitted By: Bruno Sabin (bsabin) Assigned to: pmarcu (pmarcu) Summary: candle -out cannot take a path as argument Initial Comment: Using WiX 3.0.3307.0 the command: candle.exe -out localization\xx_french.wixobj xx_french.wxs will output a file called: localizationxx_french.wixobj instead of the expected xx_french.wixobj in a subdirectory called localization (which already exists on the filessytem) -- Comment By: pmarcu (pmarcu) Date: 2007-10-01 10:35 Message: Logged In: YES user_id=1612676 Originator: NO I am not able to reproduce this. I used this commandline: candle -out localization\xx_french.wixobj xx_french.wxs and the xx_french.wixobj file was being properly produced in the localization folder. Bruno, can you try to reproduce this with the latest bits? -- Comment By: pmarcu (pmarcu) Date: 2007-10-01 09:37 Message: Logged In: YES user_id=1612676 Originator: NO I am not able to reproduce this. I used this commandline: candle -out localization\xx_french.wixobj xx_french.wxs and the xx_french.wixobj file was being properly produced in the localization folder. Bruno, can you try to reproduce this with the latest bits? -- Comment By: sameer garde (sameer_garde) Date: 2007-09-28 15:28 Message: Logged In: YES user_id=1864340 Originator: NO Pri: 1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1802341group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1766355 ] WiX should not allow keypath to be renamed
Bugs item #1766355, was opened at 2007-08-02 10:32 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1766355group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pyro Group: v3.0 Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Jungwook Bae (jbae) Assigned to: pmarcu (pmarcu) Summary: WiX should not allow keypath to be renamed Initial Comment: WiX should not allow the keypath to be renamed. Repro step: Change a filename (File.LongName) of a keypath file in upgrade. Build a patch Renaming a keypath filename probably should not be allowed -- patch building should report error. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1766355group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1790319 ] Pyro uses English text for suminfo comments
Bugs item #1790319, was opened at 2007-09-07 09:57 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1790319group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pyro Group: v3.0 Status: Open Resolution: None Priority: 1 Private: No Submitted By: Heath Stewart (heaths) Assigned to: pmarcu (pmarcu) Summary: Pyro uses English text for suminfo comments Initial Comment: Pyro takes the declared Patch/@DisplayName and prepends This patch contains the logic and data required to install . This is not localizable. We should either take DisplayName as-is (which doesn't uphold the recommended value for Comments), add a Comments attribute to Patch, or consider this as part of a larger effort to automatically localize some values based on the codepage or some other value. -- Comment By: Heath Stewart (heaths) Date: 2007-09-07 11:16 Message: Logged In: YES user_id=1335104 Originator: YES Another idea is to add Patch/@SummaryComments - the naming of which is consistent with PatchInformation/@SummaryCodepage. This would create a row in _SummaryInformation in Compiler.cs. Patch.cs could then either *not* use the DisplayName at all (Patch/@SummaryComments or nothing at all), or to support existing authoring we could fallback to DisplayName and the hard-coded English text if Patch/@SummaryComments is missing. To note, the Comments summary property is not a required property so, other than for consistency, it really doesn't matter much what we do here so long as it isn't always in English. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1790319group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1740296 ] Missing localization strings in 3.0.3015.0
Bugs item #1740296, was opened at 2007-06-20 12:13 Message generated for change (Settings changed) made by barnson You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1740296group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: wixui Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Minor (drseltsam) Assigned to: Rob Mensching (robmen) Summary: Missing localization strings in 3.0.3015.0 Initial Comment: There are some german translations missing in the file WixUI_de-de.wxl. Since the use of this UI isn't possible out of the box, I translated the missing Strings. I hope you can put them in for the next build. String Id=MaintenanceTypeDlgRemoveDisabledText Overridable=yes[ProductName] kann nicht entfernt werden./String String Id=MaintenanceTypeDlgRepairDisabledText Overridable=yes[ProductName] kann nicht repariert werden./String String Id=UITextNewFolder Overridable=yesOrdner|Neuer Ordner/String -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1740296group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1806326 ] Merge COM Plus WiX 3.0.3328.0
Bugs item #1806326, was opened at 2007-10-02 09:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1806326group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Livermore (roblivermore) Assigned to: Nobody/Anonymous (nobody) Summary: Merge COM Plus WiX 3.0.3328.0 Initial Comment: msiexec throws a exception: The COM+ application was not found.( -2147023728 MYCOMAPP.GuidHere ) To Reproduce: Create a merge module with 1 Merge an msm Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:pca=http://schemas.microsoft.com/wix/ComPlusExtension; Module Id=SIMCOMMON . Package Id= pca:ComPlusApplication Id=MYCOMAPP Name=SIMComponents / Directory Id=TARGETDIR Name=SourceDir Directory Id=MergeRedirectFolder Component Id=PPJobScheduler.dll Guid=f8c430f6-8cb2-49b7-9526-41435652916c File Id=PPJobScheduler.dll Name=PPJobScheduler.dll Source=$(var.SimBin)PPJobScheduler.dll SelfRegCost=1 Vital =yes / pca:ComPlusAssembly Id=PPJobScheduler_COM Type=native Application=FASIMCOMPLUS DllPath =[#PPJobScheduler.dll] pca:ComPlusComponent Id =PPJobScheduler.PPJobSchedulerObj.1 CLSID =0CAE44CD-1AB2-11D4-A863-00C04F8F220E/ /pca:ComPlusAssembly /Component In the Package create the COM+ Application and Reference the merge module. Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=SIMFRAMEWORKDIR Name=SIMFramework !-- Custom Directory for SIMs Legacy SIMs are typically installed C:\Program files\SIMFramework\Bin -- Directory Id =SIMFRAMEWORKBINDIR Name=Bin Component Id =FASIMCOMCOMP Guid =4E9DFDB2-2B9C-4b3c-BFF3-3722392717D6 CreateFolder / pca:ComPlusApplication Id=MYCOMAPP Name=Fleet Assistant SIM Components ApplicationId=A2DF4104-7F9A-44FF-BE50-41C5EE376201 Authentication=none Activation=inproc /pca:ComPlusApplication /Component Merge Id =SIMCommon.msm Language=1033 DiskId=1 SourceFile =$(var.MergeModuleBin)\SimCommon\bin\$(var.Config)\SimCommon.msm / The problem is the MSI COMPlusApplication table after the merge contains an entry which is orphaned to any components. I can work around this by putting all components beneath the Product. However this is not desirable because the file become very large. The speed to merge into multipule MSI is faster then compiling the components multipult times. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1806326group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1690710 ] null exn - compressed media without cabinet attribute?
Bugs item #1690710, was opened at 2007-03-29 08:06 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1690710group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: James (jamarg) Assigned to: pmarcu (pmarcu) Summary: null exn - compressed media without cabinet attribute? Initial Comment: Rob said: 2. It looks like you’ve found a bug in the WiX toolset with “outputB.txt”. My first guess is that we’ve never tested having a Media that is compressed without a Cabinet attribute. Would you mind opening a bug on that? Thanks, James. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1690710group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1686827 ] The target _TimeStampAfterCompile ~exist after failed bld
Bugs item #1686827, was opened at 2007-03-23 07:07 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1686827group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: votive Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wieser Software Ltd (wiesersoftware) Assigned to: Justin Rockwood (justinrockwood) Summary: The target _TimeStampAfterCompile ~exist after failed bld Initial Comment: Using Votive in build 3.0.2716, adding a post build event gives the following error message if the build fails for some other reason: 1C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(360,7): Error MSB4057: The target _TimeStampAfterCompile does not exist in the project. If there are no errors in the project, the post build step executes successfully. -- Comment By: Wieser Software Ltd (wiesersoftware) Date: 2007-03-23 07:49 Message: Logged In: YES user_id=1748122 Originator: YES I should add, the dependency is set to run OnOutputUpdated -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1686827group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1681505 ] REG_MULTI_SZ RegistrySearch causes errors during MSI install
Bugs item #1681505, was opened at 2007-03-15 07:21 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1681505group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kelly Hollis (kellyhpdx) Assigned to: Bob Arnson (barnson) Summary: REG_MULTI_SZ RegistrySearch causes errors during MSI install Initial Comment: When a RegistrySearch element is reading a REG_MULTI_SZ, the resulting MSI fails to install to the location specified during feature customization, and will not uninstall via the Remove button. For instance, if the registry contains the key: HKLM\Software\TestWix\MyMultiString with values Test1 and Test2, the search RegistrySearch Id=mymulti Root=HKLM Key=SOFTWARE\TestWix Name=MyMultiString Type=raw / will cause the installer to exhibit the problems mentioned above. Attached is a zip file with a sample project that demonstrates these problems. Changing the registry search to look at a REG_SZ key instead causes the problems to disappear. This was tested using version 3.0.2712.0. -- Comment By: Bob Arnson (barnson) Date: 2007-03-20 23:46 Message: Logged In: YES user_id=26581 Originator: NO There is definitely a weirdness going on. The good news is that it affects only the UI; using 'msiexec /x' still removes the product. The neutral news is that a RegistrySearch for a REG_MULTI_SZ isn't very useful; see the RegLocator table doc: REG_MULTI_SZ Null. The installer sets the property to a value beginning with a null and ending with a null. I'll keep the bug open to keep thinking about it but at first glance, I can't think of a way the UI can change what MSI does. -- Comment By: Kelly Hollis (kellyhpdx) Date: 2007-03-16 05:23 Message: Logged In: YES user_id=229733 Originator: YES I'm attaching a verbose log during an attempted uninstall via the remove button. File Added: uninstall.log -- Comment By: Bob Arnson (barnson) Date: 2007-03-15 19:46 Message: Logged In: YES user_id=26581 Originator: NO Can you attach a verbose log? Much easier to diagnose problems that way. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1681505group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1680503 ] Invalid codepage generates invalid MSI
Bugs item #1680503, was opened at 2007-03-14 03:48 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1680503group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: The Mad Butcher (mad_burcher) Assigned to: pmarcu (pmarcu) Summary: Invalid codepage generates invalid MSI Initial Comment: If you provide a invalid SummeryCodepage attribute on the Package element candle and light run flawless but an invalid MSI is generated (Orca is the only tool i've found able to open the MSI file). Maybe it is possible to add some sanity check in light since even smoke is not able to open the generated MSI file! -- Comment By: Rob Mensching (robmen) Date: 2007-04-02 14:14 Message: Logged In: YES user_id=991639 Originator: NO Moving to v3. This is a good bug to fix but not for v2, not now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1680503group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1675329 ] Dark is not decompiling File Types (Exensions / Verbs)
Bugs item #1675329, was opened at 2007-03-06 14:51 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1675329group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: dark Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Muhammad Asim Ghaznawi (mghaznavi) Assigned to: pmarcu (pmarcu) Summary: Dark is not decompiling File Types (Exensions / Verbs) Initial Comment: Here are Repro steps: 1) Create an MSI package (e.g. using Visual Studio 2005) having some File Types (extensions / verbs) defined. 2) Decompile the MSI using dark. Actual Behavior: The File Types are not decompiled to Extensions / Verbs. Expected Behavior: Dark should decompile the File Types to Extensions / Verbs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1675329group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1672584 ] Exception during EnumerateCab
Bugs item #1672584, was opened at 2007-03-02 09:45 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1672584group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jacob Huck (jthuck) Assigned to: pmarcu (pmarcu) Summary: Exception during EnumerateCab Initial Comment: After upgrading to WiX 3.0.2420, we're now expereiencing random exceptions in light. They tend to happen to the same installs, but the exception changes, and at times is successful. Here are two of the stacks (and the only warning... suspicious, eh?): D:\builds\systest\EIC\rum\products\eic\install\msi\IceLib\WiX_IceLib.wxs(15) : warning LGHT1079 : The cabinet 'Product4. cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Ot herwise, please add files to the cabinet or remove it. light.exe : error LGHT0001 : The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE)) Exception Type: System.Runtime.InteropServices.COMException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.CabInterop.EnumerateCab(String cabinet, PFNNOTIFY notify) at Microsoft.Tools.WindowsInstallerXml.BinderExtension.ResolveCabinet(FileRowCollection fileRows, String cabinetPath ) at Microsoft.Tools.WindowsInstallerXml.Binder.CreateCabinetWorkItem(Output output, String cabinetDir, MediaRow mediaR ow, FileRowCollection fileRows, ArrayList fileTransfers) at Microsoft.Tools.WindowsInstallerXml.Binder.CreateCabinetFiles(Output output, FileRowCollection fileRows, ArrayList fileTransfers, MediaRowCollection mediaRows, String layoutDirectory, Boolean compressed) at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output output, String databaseFile) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) Binder temporary directory located at 'c:\temp\nm2ktxjl'. Validator temporary directory located at 'c:\temp\hntgyo3e'. D:\builds\systest\EIC\rum\products\eic\install\msi\IceLib\WiX_IceLib.wxs(15) : warning LGHT1079 : The cabinet 'Product4. cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Ot herwise, please add files to the cabinet or remove it. light.exe : error LGHT0001 : Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Exception Type: System.AccessViolationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.CabInterop.EnumerateCab(String cabinet, PFNNOTIFY notify) at Microsoft.Tools.WindowsInstallerXml.BinderExtension.ResolveCabinet(FileRowCollection fileRows, String cabinetPath ) at Microsoft.Tools.WindowsInstallerXml.Binder.CreateCabinetWorkItem(Output output, String cabinetDir, MediaRow mediaR ow, FileRowCollection fileRows, ArrayList fileTransfers) at Microsoft.Tools.WindowsInstallerXml.Binder.CreateCabinetFiles(Output output, FileRowCollection fileRows, ArrayList fileTransfers, MediaRowCollection mediaRows, String layoutDirectory, Boolean compressed) at Microsoft.Tools.WindowsInstallerXml.Binder.BindDatabase(Output output, String databaseFile) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) Binder temporary directory located at 'c:\temp\yigyysa2'. -- Comment By: Jacob Huck (jthuck) Date: 2007-03-02 11:55 Message: Logged In: YES user_id=1447432 Originator: YES It correctly states that this cab contains no files. -- Comment By: Bob Arnson (barnson) Date: 2007-03-02 11:11 Message: Logged In: YES user_id=26581 Originator: NO Obvious first question: Are you building products/modules with no files or is the first message bogus too? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1672584group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1660163 ] Non-advertised Classes Add Extra Quotes in Registry
Bugs item #1660163, was opened at 2007-02-14 15:52 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1660163group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike O'Laughlen (molaughlen1) Assigned to: pmarcu (pmarcu) Summary: Non-advertised Classes Add Extra Quotes in Registry Initial Comment: I'm new to the Windows Installer API, but I think I'm correct in reporting this bug (at least it wouldn't work until I used Orca to fix it). When the Compiler generates the wixobj file, the class' row in the Registry table has a Value column encapsulated in quotation marks: [#FileServer] it should be: [#FileServer] The following wxs snippet produces this issue: File Id=Component.dll Name=Component.dll KeyPath=yes Source=Component.dll DiskId=1 Class Id=GUID-HERE Context=InprocServer32 Description=Component Description ThreadingModel=apartment Programmable=yes ProgId Id=Component.ProgID Description=ProgID Description / /Class /File This results in a registry row: Registry: reg123456789 Root: 0 Key: CLSID\GUID-HERE\InprocServer32 Name: Value: [#Component.dll] Component_: Component.dll again Value should be: [#Component.dll] -- Comment By: Mike O'Laughlen (molaughlen1) Date: 2007-02-15 06:29 Message: Logged In: YES user_id=1719677 Originator: YES This is similar to bug 1370181 http://sourceforge.net/tracker/index.php?func=detailaid=1370181group_id=105970atid=642714 -- Comment By: Mike O'Laughlen (molaughlen1) Date: 2007-02-14 16:10 Message: Logged In: YES user_id=1719677 Originator: YES I've done some digging around in the previous versions of Compiler.cs and found that these quotes have been around for ahwile. I assume the quotes are necessary if arguments are supplied to the server, however when Excel attempts to load my automation add-in it balks because it can't find the component due to the quotes. I suppose I'll need to use RegistryValue/ elements. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1660163group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1657160 ] MsiHiddenProperties from merge module is ignored
Bugs item #1657160, was opened at 2007-02-10 23:12 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1657160group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Markus Wagner (ritzlgrmft) Assigned to: pmarcu (pmarcu) Summary: MsiHiddenProperties from merge module is ignored Initial Comment: I have a merge module with a hidden property. In Orca all looks fine, MsiHiddenProperties is filled correctly. But if I embed the merge module in a msi, the property is no longer hidden. MsiHiddenProperties now contains only the hidden properties from the msi package, the hidden property from the merge module is now visible. By the moment I use the following workaround: I define the property from the merge module additional in the containing msi, decorated with the merge module GUID. This works but it is not nice. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1657160group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1648088 ] FileSearch element - MinSize/MaxSize cause error
Bugs item #1648088, was opened at 2007-01-30 09:39 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1648088group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: v3.0 Status: Open Resolution: None Priority: 9 Private: No Submitted By: Lorne Laliberte (lornelaliberte) Assigned to: pmarcu (pmarcu) Summary: FileSearch element - MinSize/MaxSize cause error Initial Comment: While testing the FileSearch element, I tried using this XML code: Property Id=MYFILE RegistrySearch Id=reg_search_3 Root=HKLM Key=Software\!Test Name=MyDirBasePath Type=directory DirectorySearch Depth='4' Id=dir_search_1 Path=this folder FileSearch Id=file_search_1 Name=myfile.txt MinSize=50/ /DirectorySearch /RegistrySearch /Property Compiling that generates the following candle error: candle.exe : error CNDL0001 : Cannot set number column 'MinSize' with a value of type 'System.String'. Exception Type: System.InvalidOperationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object value) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseFileSearchElement(XmlNod e node, String parentSignature) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseDirectorySearchElement(X mlNode node, String parentSignature) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseRegistrySearchElement(Xm lNode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseSearchSignatures(XmlNode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParsePropertyElement(XmlNode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseProductElement(XmlNode n ode) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseWixElement(XmlNode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.Compile(XmlDocument source) at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args) ...looks like a bug in candle? Note: The same thing happens if I specify the MaxSize attribute alone, or use both the MinSize and MaxSize together. -- Comment By: Lorne Laliberte (lornelaliberte) Date: 2007-01-30 09:41 Message: Logged In: YES user_id=1705700 Originator: YES Oh - this is using version 3.0.2211.0 of candle. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1648088group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1656236 ] FileSearch requires a parent folder found at depth 0
Bugs item #1656236, was opened at 2007-02-09 08:42 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1656236group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lorne Laliberte (lornelaliberte) Assigned to: pmarcu (pmarcu) Summary: FileSearch requires a parent folder found at depth 0 Initial Comment: While testing the FileSearch and DirectorySearch elements, I've discovered what is either a bug, or a limitation, in WiX or MSI. (Based on Rob's quote about the difficulty of working with AppSearch I think it's most likely a bug in WiX. :) It's a bit tricky to describe, but basically it has to do with the FileSearch element needing two things: - it must be in a DirectorySearch element that describes its parent folder with an effective depth of 0; although the attribute can be higher it must be found at level 0 - if that DirectorySearch has a parent DirectorySearch element, it must have been found at an effective depth of 0 as well For example: Let's assume we have the following folder structure: C:\Temp\a\b\c\d\e\f\ And inside that folder structure we have a file: C:\Temp\a\b\c\d\e\f\foo.txt This search will NOT work: Property Id=FOO_DOT_TEXT_0 DirectorySearch Depth='0' Id=dir_search_0 Path=C:\Temp\a FileSearch Id=file_search_0 Name=foo.txt / /DirectorySearch /Property This search will NOT work either: Property Id=FOO_DOT_TEXT_1 DirectorySearch Depth='0' Id=dir_search_1 Path=C:\Temp DirectorySearch Depth='8' Id=dir_search_2 Path=f FileSearch Id=file_search_1 Name=foo.txt / /DirectorySearch /DirectorySearch /Property This search will NOT work either: Property Id=FOO_DOT_TEXT_2 DirectorySearch Depth='0' Id=dir_search_5 Path=C:\Temp DirectorySearch Depth='5' Id=dir_search_6 Path=d DirectorySearch Depth='2' Id=dir_search_7 Path=f FileSearch Id=file_search_2 Name=foo.txt / /DirectorySearch /DirectorySearch /DirectorySearch /Property However, this search WILL work: Property Id=FOO_DOT_TEXT_3 DirectorySearch Depth='0' Id=dir_search_8 Path=C:\Temp DirectorySearch Depth='6' Id=dir_search_9 Path=e DirectorySearch Depth='0' Id=dir_search_10 Path=f FileSearch Id=file_search_3 Name=foo.txt / /DirectorySearch /DirectorySearch /DirectorySearch /Property One workaround I've found is to use two searches, like this: Property Id=FOLDER_F DirectorySearch Depth='0' Id=dir_search_11 Path=C:\Temp DirectorySearch Depth='8' Id=dir_search_12 Path=f / /DirectorySearch /Property Property Id=FOO_DOT_TEXT_4 DirectorySearch Depth='0' Id=dir_search_13 Path=[FOLDER_F] FileSearch Id=file_search_4 Name=foo.txt / /DirectorySearch /Property ...which seems to work just fine so long as the properties are defined in the correct order. Is this a bug in WiX, or a limitation in MSI? So to summarize, there are two possible bugs: 1. you can't recursively search for a file without specifying its parent folder (the file must be found at an effective depth of 0) 2. you can't recursively search for the parent folder either (the file's parent folder must also be found at an effective depth of 0) -- Comment By: Lorne Laliberte (lornelaliberte) Date: 2007-04-18 13:04 Message: Logged In: YES user_id=1705700 Originator: YES (Uh - I meant DirectorySearch where I used Directory above.) -- Comment By: Lorne Laliberte (lornelaliberte) Date: 2007-04-18 13:01 Message: Logged In: YES user_id=1705700 Originator: YES Ah, I think I just realized something. The Depth attribute means something different when there is a child FileSearch element. If there is no child FileSearch element, the Directory's @Depth means the number of levels down from the parent Directory to look for @Path. If there is a child FileSearch element, the Directory's @Depth means the number of levels down from @Path to look for the file. In the latter case, the Directory element itself is assumed to be have a depth of 0, which is why something like this doesn't work: !-- DOES NOT WORK: -- Property Id=FOO_DOT_TEXT_1 DirectorySearch Depth='0' Id=dir_search_1 Path=C:\Temp DirectorySearch Depth='8' Id=dir_search_2 Path=f FileSearch Id=file_search_1 Name=foo.txt /
[WiX-devs] [ wix-Bugs-1637237 ] Formatted text in Upgrade:Language doesn't error out
Bugs item #1637237, was opened at 2007-01-16 15:23 Message generated for change (Comment added) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1637237group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Jeremy Kuhne (jkuhne) Assigned to: Nobody/Anonymous (nobody) Summary: Formatted text in Upgrade:Language doesn't error out Initial Comment: This should fail as it's an ICE03 error. Repro is to put [ProductLanguage] in the field. -- Comment By: pmarcu (pmarcu) Date: 2007-10-02 14:46 Message: Logged In: YES user_id=1612676 Originator: NO This is a problem with the Windows installer darice.cub that they distribute, not a WiX problem. Closing as I dont think there is much Wix can do here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1637237group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1633301 ] AllowAdvertise attribute somtimes missing
Bugs item #1633301, was opened at 2007-01-11 07:38 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1633301group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: dark Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: appel (appel__) Assigned to: pmarcu (pmarcu) Summary: AllowAdvertise attribute somtimes missing Initial Comment: If msidbFeatureAttributesNoUnsupportedAdvertise and msidbFeatureAttributesDisallowAdvertise is set in the source msi the Feature element does not get the AllowAdvertise attribute set to no, it is missing. If msidbFeatureAttributesDisallowAdvertise is set the msidbFeatureAttributesNoUnsupportedAdvertise is ignored by Windows installer, so the created Feature element should have AllowAdvertise=no. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1633301group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1632127 ] Detection of closing paren of a preprocessor function
Bugs item #1632127, was opened at 2007-01-10 01:32 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1632127group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: v3.0 Status: Open Resolution: Invalid Priority: 5 Private: No Submitted By: Dzenan (dzenand) Assigned to: pmarcu (pmarcu) Summary: Detection of closing paren of a preprocessor function Initial Comment: It seems that issue is inside PreprocessString methon in PreprocessorCore class. I have created custom preprocessor extension By typing ?if $(util.TestFunc())? Causes following exception Ill-formed preprocessor function '$(util.TestFunc()'. Functions must have a prefix (like 'fun.'), a name at least 1 character long, and matching opening and closing parentheses. As you can see it can not detect last character. Maybe theres a looping bug on line #112 inside PreprocessorCore class. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1632127group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1631288 ] Heat skips empty keys
Bugs item #1631288, was opened at 2007-01-09 01:17
Message generated for change (Settings changed) made by pmarcu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=642714aid=1631288group_id=105970
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: heat
Group: v3.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: appel (appel__)
Assigned to: pmarcu (pmarcu)
Summary: Heat skips empty keys
Initial Comment:
In RegistryHarvester.cs line 203 the value names of a key is enumerated. But if
the key is empty nothing is done.
This means that keys like HKCR\CLSID\{GUID}\Implemented Categories\{GUID} are
skipped.
--
Comment By: appel (appel__)
Date: 2007-01-09 03:06
Message:
Logged In: YES
user_id=893425
Originator: YES
To get around this I changed the return type of
RegistryHarvester.HarvestRegistry and all methods that depend on it to
ISchemaElement and added the following before the enumeration on line 203:
if (1 parts.Length registryKey.SubKeyCount == 0
registryKey.ValueCount == 0)
{
Wix.RegistryKey emptyKey = new Wix.RegistryKey();
emptyKey.Action = Wix.RegistryKey.ActionType.create;
emptyKey.Root = root;
emptyKey.Key = parts[1];
registryValues.Add(emptyKey);
}
Maybe not the cleanest solution and I don't have a CVS client installed
here so I can't create a patch. I did a local build of Wix and it looks
like this solved my issue at least.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=642714aid=1631288group_id=105970
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1629314 ] Improve handling of invalid Merge Language
Bugs item #1629314, was opened at 2007-01-06 02:03 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1629314group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: appel (appel__) Assigned to: pmarcu (pmarcu) Summary: Improve handling of invalid Merge Language Initial Comment: In src\wix\Binder.cs ProcessMergeModules exceptions are handled for when the merge module file does not exist and some other cases and you get great error messages. But if you've specified an invalid language for the merge all you get is a COMException: light.exe : error LGHT0001 : The language of this installation package is not supported by your system. (Exception from HRESULT: 0x80070657) The COMException should be caught and a WixException thrown with source line number and file instead to make it easier to figure out where the error is. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1629314group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1620683 ] heat.exe does not extract TypeLib/@Description
Bugs item #1620683, was opened at 2006-12-22 00:56 Message generated for change (Settings changed) made by pmarcu You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1620683group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: heat Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: BoresExpress (boresexpress) Assigned to: pmarcu (pmarcu) Summary: heat.exe does not extract TypeLib/@Description Initial Comment: heat.exe does not extract TypeLib/@Description -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1620683group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1615167 ] Registry rows generated by Class element are not unique
Bugs item #1615167, was opened at 2006-12-13 10:21
Message generated for change (Settings changed) made by pmarcu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=642714aid=1615167group_id=105970
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: heat
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: e__ (e__)
Assigned to: pmarcu (pmarcu)
Summary: Registry rows generated by Class element are not unique
Initial Comment:
Some of the Registry rows generated by the Class element may collide with the
RegistryValue elements, resulting in an error similar to the following:
C:\projects\sandbox\COMTest.wxs(19) : error LGHT0130 : The primary key
'reg9D78D592D2980BC3F33101F91D853AE6' is duplicated in table 'Registry'.
Please remove one of the entries or rename a part of the primary key to avoid
the collision.
Steps:
I heat’ed some files, and got something like this:
Component Id=ComTest.TestThing.dll
Guid={099EEAAA-852D-44AE-94A4-12F4AD41F39B}
Class Id={01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}
Context=InprocServer32 Description=ComTest.TestThing.JobCollection
ThreadingModel=both
ProgId Id=ComTest.TestThing.JobCollection
Description=ComTest.TestThing.JobCollection /
/Class
File Id=ComTest.TestThing.dll Name=ComTest.TestThing.dll
KeyPath=yes Source=C:\Files\ComTest.TestThing.dll /
ProgId Id=Record /
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32\1.2.0.0
Name=Class Value=ComTest.TestThing.JobCollection Type=string
Action=write /
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32\1.2.0.0
Name=Assembly Value=ComTest.TestThing, Version=1.2.0.0, Culture=neutral,
PublicKeyToken=f89fe288ec1a1c9a Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32\1.2.0.0
Name=RuntimeVersion Value=v1.1.4322 Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32\1.2.0.0
Name=CodeBase Value=[#ComTest.TestThing.dll] Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32
Value=mscoree.dll Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32 Name=Class
Value=ComTest.TestThing.JobCollection Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32
Name=Assembly Value=ComTest.TestThing, Version=1.2.0.0, Culture=neutral,
PublicKeyToken=f89fe288ec1a1c9a Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32
Name=RuntimeVersion Value=v1.1.4322 Type=string Action=write /
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32
Name=CodeBase Value=[#ComTest.TestThing.dll] Type=string Action=write /
/Component
Candle, then attempt to Light gives:
Microsoft (R) Windows Installer Xml Linker version 3.0.2315.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.
C:\projects\sandbox\COMTest.wxs(19) : error LGHT0130 : The primary key
'reg9D78D592D2980BC3F33101F91D853AE6' is duplicated in table 'Registry'.
Please remove one of the entries or rename a part of the primary key to avoid
the collision.
Workaround:
The collision appears to occur when there is a default value for the key.
Removing the following from the above snippit resolves the error.
RegistryValue Root=HKCR
Key=CLSID\{01D6FA3C-BCF4-35AB-820A-49ACAF99F5F8}\InprocServer32
Value=mscoree.dll Type=string Action=write /
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=642714aid=1615167group_id=105970
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1806655 ] WixCop 3 help text is misleading for indent
Bugs item #1806655, was opened at 2007-10-02 23:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1806655group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Green (ferrysoft) Assigned to: Nobody/Anonymous (nobody) Summary: WixCop 3 help text is misleading for indent Initial Comment: The command level help text (wixcop -?) for WixCop 3 indent is misleading. It says that the default value for the indentation multiple is 2. The default value is actually 4. The help text should be corrected accordingly for WixCop 3. WixCop 2 is correct in this respect as the default value is still 2 in that version. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1806655group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1577345 ] The WebAddress/@IP attribute description is confusing
Bugs item #1577345, was opened at 2006-10-14 19:58 Message generated for change (Comment added) made by ferrysoft You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1577345group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v2.0 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Mike Green (ferrysoft) Assigned to: Rob Mensching (robmen) Summary: The WebAddress/@IP attribute description is confusing Initial Comment: The WebAddress/@IP attribute description is confusing. As it stands, the wording is ambiguous. The wording also leads you to believe that there is no difference between specifying IP=* and omitting the IP attribute. This may be the case if the IP Address of the target web site is All Unassigned but it is not the case if an explicit IP Address is assigned. The WiX schema element description could be improved by including a remarks section that specifies how WiX behaves in the following circumstances: 1) IP is set to an IP Address. 2) IP is set to *. 3) IP attribute is not specified. It would also be worth reviewing whether WiX should behave differently for circumstances 2 and 3. Today, WiX does behave differently if the IP Address of the target web site is assigned. In circumstance 2, WiX finds the target web site. In circumstance 3, WiX does not find the target web site and generates the error Failed to read IIsWebs table (-2147023728). Is this intentional? -- Comment By: Mike Green (ferrysoft) Date: 2007-10-03 12:08 Message: Logged In: YES user_id=1108842 Originator: YES Rob, the new V2 content is a big improvement but I still found it a bit difficult to assimilate. I’ve provided an alternative below for your consideration. I also notice that the V3 help file needs updating with whatever is the final content for this attribute. Proposed content: The IP address to locate an existing WebSite or create a new WebSite. IP attribute not specified - Locates only the “All Unassigned” IP address or creates the “All Unassigned” IP address. IP explicitly specified - Locates only the specified IP address or creates the specified IP address. IP specified as “*” - Locates any IP address including the “All Unassigned” IP address or creates the “All Unassigned” IP address. Existing V2 content: The IP address for the web address. To specify the All Unassigned IP address, do not specify this attribute or specify its value as *. The IP address is also used to determine if the WebSite is already installed. The IP address must match exactly (empty value matches All Unassigned) unless * is used which will match any existing IP (including All Unassigned). Existing V3 content: For IP address All Unassigned, do not specify this attribute or specify its value as *. -- Comment By: Rob Mensching (robmen) Date: 2007-04-06 06:35 Message: Logged In: YES user_id=991639 Originator: NO Added more content to hopefully clear up the purpose. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1577345group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1687424 ] wixcop doesn't like utf-8 declaration
Bugs item #1687424, was opened at 2007-03-24 15:05 Message generated for change (Comment added) made by ferrysoft You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1687424group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: tallow Group: v2.0 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Elizabeth Smith (auroraeosrose) Assigned to: Rob Mensching (robmen) Summary: wixcop doesn't like utf-8 declaration Initial Comment: Wixcop in the last stable wix2 release throws an error when the encoding is declared as utf-8 instead of UTF-8 -- Comment By: Mike Green (ferrysoft) Date: 2007-10-02 23:11 Message: Logged In: YES user_id=1108842 Originator: NO This might be worth re-opening because there is an inconsistency between WixCop 2 and WixCop 3. WixCop 2 allows only encoding=UTF-8 and inserts it in uppercase if not found. WixCop 3 allows both encoding=UTF-8 and encoding=utf-8 and inserts it in lowercase if not found. Surely both versions of WixCop should be consistent and WixCop 2 should be changed to behave like WixCop 3 shouldn’t it? -- Comment By: Rob Mensching (robmen) Date: 2007-04-03 00:15 Message: Logged In: YES user_id=991639 Originator: NO WixCop has always had that check. It is extremely particular about data because one of it's goals is to make it possible to diff to .wxs files that have both been formatted with WixCop and verify. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1687424group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
[WiX-devs] [ wix-Bugs-1660163 ] Non-advertised Classes Add Extra Quotes in Registry
Bugs item #1660163, was opened at 2007-02-15 00:52 Message generated for change (Comment added) made by maliger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1660163group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike O'Laughlen (molaughlen1) Assigned to: pmarcu (pmarcu) Summary: Non-advertised Classes Add Extra Quotes in Registry Initial Comment: I'm new to the Windows Installer API, but I think I'm correct in reporting this bug (at least it wouldn't work until I used Orca to fix it). When the Compiler generates the wixobj file, the class' row in the Registry table has a Value column encapsulated in quotation marks: [#FileServer] it should be: [#FileServer] The following wxs snippet produces this issue: File Id=Component.dll Name=Component.dll KeyPath=yes Source=Component.dll DiskId=1 Class Id=GUID-HERE Context=InprocServer32 Description=Component Description ThreadingModel=apartment Programmable=yes ProgId Id=Component.ProgID Description=ProgID Description / /Class /File This results in a registry row: Registry: reg123456789 Root: 0 Key: CLSID\GUID-HERE\InprocServer32 Name: Value: [#Component.dll] Component_: Component.dll again Value should be: [#Component.dll] -- Comment By: Martin Aliger (maliger) Date: 2007-10-03 18:16 Message: Logged In: YES user_id=655297 Originator: NO see also issue 1784476. -- Comment By: Mike O'Laughlen (molaughlen1) Date: 2007-02-15 15:29 Message: Logged In: YES user_id=1719677 Originator: YES This is similar to bug 1370181 http://sourceforge.net/tracker/index.php?func=detailaid=1370181group_id=105970atid=642714 -- Comment By: Mike O'Laughlen (molaughlen1) Date: 2007-02-15 01:10 Message: Logged In: YES user_id=1719677 Originator: YES I've done some digging around in the previous versions of Compiler.cs and found that these quotes have been around for ahwile. I assume the quotes are necessary if arguments are supplied to the server, however when Excel attempts to load my automation add-in it balks because it can't find the component due to the quotes. I suppose I'll need to use RegistryValue/ elements. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=642714aid=1660163group_id=105970 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-devs mailing list WiX-devs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-devs
