Re: [WiX-users] problems browsing WiX.sourceforge.net
A report from our internal bug tracking system: When compiling, this error can appear: D:\temp\wixcandle.exe Unhandled Exception: Cannot print exception string because Exception.ToString() failed. This is most likely caused by .Net 2.0 or an update of its dependency. To prove it, I disabled the supportedRuntime version=v2.0.50727 / in the candle.exe.config file and restarted using supportedRuntime version=v1.1.4322 /. It works on Net 1.1. This happened a few weeks ago. Now I wanted to send you the memory file, but it works with Net 2.0. The only difference is that during this time I uninstalled the F-Secure antivirus. -- From: Rob Mensching [EMAIL PROTECTED] Sent: Friday, December 21, 2007 12:20 PM To: Calin Iaru [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] problems browsing WiX.sourceforge.net Can you provide more details about these crashes? There should be a stack dump with lots of information. Calin Iaru wrote: Some links are down like the download links. Sometimes the browser won't even open WiX.sourceforge.net. What is wrong? I could not download WiX 2 nor could I take any of the weekly releases. By the way, it appears that the Stable WiX2 crashes on my computer out of the blue. There are no updates to NetFX2 only to 1 and I also have installed NetFX3. So what gives? I will copy WiX2 to another machine and try again from there. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to use SHGetKnownFolderPath(Environment.SpecialFolder.CommonApplicationData) to get targetdir?
Thank you Gabor Kelly. Hina Kelly Leahy-2 wrote: As Gabor said, This reference is a reference to the way normal apps should retrieve the value of that folder name, not the way that installers should retrieve it - they should just use the MSI property. I'm not sure why that reference is even made in the MSI documentation - it's confusing at best, and I think it's a bit misleading. Kelly hina1703 [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 12/27/2007 06:43 PM To wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] How to use SHGetKnownFolderPath(Environment.SpecialFolder.CommonApplicationData) to get targetdir? Gabor, Thanks again. I saw Vista when I clicked on LocalAppDataFolder property on the page you mentioned. The resulting page is: http://msdn2.microsoft.com/en-us/library/aa369768(VS.85).aspx Hina DEÁK JAHN, Gábor-2 wrote: On Thu, 27 Dec 2007 14:41:03 -0800 (PST), hina1703 wrote: Hina, Thanks for the reply. But it says that for Vista, SHGetKnownFolderPath function should be used to get the path. So I wanted to know how can I use it? I can't see Vista mentioned on that page anywhere. Are you sure you visited the Windows Installer properties, not the Win32 API for applications? SHGetKnownFolderPath () is a shell function programs can call and it is indeed new to Vista, a new alias for the old SHGetFolderPath () function. All you have to do is to use the property name listed on that page as your target dir in your .wxs file. There is no need to call any Windows function at all. Bye, G?bor --- DE?K JAHN, G?bor -- Budapest, Hungary E-mail: [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/How-to-use-SHGetKnownFolderPath%28Environment.SpecialFolder.CommonApplicationData%29-to-get-targetdir--tp14518285p14521485.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ** This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Unless indicated to the contrary: it does not constitute professional advice or opinions upon which reliance may be made by the addressee or any other party, and it should be considered to be a work in progress. Unless stated otherwise, this communication does not form a prescribed statement of actuarial opinion under American Academy of Actuaries guidelines. ** - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/How-to-use-SHGetKnownFolderPath%28Environment.SpecialFolder.CommonApplicationData%29-to-get-targetdir--tp14518285p14526285.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix3: File/@Name as part of @Source
Last version wix-3.0.3621 add new feature - auto fill File/@Name field. But some difference confuse me. Changes from histoty.txt : BobArnso: - Default File/@Name and @Id to the file name portion of @Source. Changes from Wix chm documentation (about attribute File/@Name): ... if this attribute is omitted then it is defaulted to the value of the Id attribute. In real, Wix not working as described in history.txt, but working as described in documentation - if Name not specified then Name *taken from Id*. It is BAD. Files Id must be unique in msi package scope, but file names may be same. In real life at 99.999% cases File/@Name equal file name part of File/@Sorce. Why Wix take file name from [EMAIL PROTECTED], but not from [EMAIL PROTECTED] ??? -- View this message in context: http://www.nabble.com/Wix3%3A-File-%40Name-as-part-of-%40Source-tp14526294p14526294.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using XmlFile in a merge module
Merge modules are for providing to third parties, for them to integrate into their installers. If you're only using this common code in-house, in other WiX-based installers, I recommend building and sharing a .wixlib instead (or you can simply share the .wxs source code, the .wixlib simply saves some compilation time). Sharing components between product installers is being de-emphasised as it leads to trouble with servicing - you cannot target a component with a patch, only a product, so if a defect is discovered in a common component, all products which installed that component have to be patched, unless some other mechanism is available to redirect clients to the new version (e.g. publisher policy in .NET and Win32 assemblies). In answer to your question, the scheduling of custom actions contained in a merge module is controlled by the ModuleInstallExecuteSequence table. Unlike in the master InstallExecuteSequence table, the merge module can specify a sequence relative to a base action rather than a specific sequence. The absolute sequence number is resolved when the module is merged in. This requires that a merge tool is used which understands this - the standard mergemod.dll does. WiX interprets InstallExecuteSequence elements to generate rows in the InstallExecuteSequence for the main installer, if building an .msi (the Product element) or in the ModuleInstallExecuteSequence for a merge module. The standard scheduling of SchedXmlFile, as of at least 3.0.3502, is to come after InstallFiles, but this can be overridden in your own InstallExecuteSequence. To confirm the problem could you post: - The exact version of WiX you're using, including build number; - The name and version of the tool used to build the final .msi; - If you have access to Orca, or another tool for viewing .msm contents, the contents of the ModuleInstallExecuteSequence table from the .msm (specifically the SchedXmlFile row). -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of csellers Sent: 27 December 2007 23:00 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using XmlFile in a merge module I currently have an MSI Wix project that (among other things) copies an xml file and makes modifications to it using util:XmlFile. I am in the process of converting this project to a merge module (MSM), but when I include the merge module in another install, I get an error saying there was a failure while configuring XML files. I then noticed that I get this error before the xml file had been copied (which would explain the error). I did not have this problem when I was building an msi file. Looking at the log file, the failure is in SchedXmlFile, which is occurring before any files have been copied. If I remove the XmlFile commands, the install runs without any problems. Is there a reason why this is happening in the merge module when it didn't in the msi? Is there anyway to control when SchedXmlFile runs? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] error CNDL0014
The TypeLib/@HelpDirectory attribute's value is supposed to be the ID of the directory, not a Formatted type. Use INSTALLDIR, not [INSTALLDIR]. The documentation isn't very helpful as it's generated directly from the XML schema, which in the main doesn't differentiate between different logical types of string. This is partly due to the difficulty of defining regular expressions for the different types to limit the allowed characters, because WiX also supports using compile-time and localization-time variables in place of at least some identifiers (they must of course ultimately resolve to identifiers). I'm not sure if it's possible to define a new type based on String with no additional restrictions. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McCann, Jerome Sent: 27 December 2007 17:52 To: wix-users@lists.sourceforge.net Subject: [WiX-users] error CNDL0014 When I run the candle C:\Wix 3\UltraEdit32_FIles.wxs -out C:\Wix 3\UltraEdit32_FIles.wixobj, I am getting the following error: UltraEdit32_Files.wxs C:\Installs\UltraEdit32_Files.wxs(72) : error CNDL0014 : The TypeLib/@HelpDirect ory attribute's value, '[INSTALLDIR]', is not a legal identifier. Identifier's may contain ASCII characters A-Z, a-z, digits, underscores (_), or periods (.). Every identifier must begin with either a letter or an underscore. C:\Installs\UltraEdit32_Files.wxs(102) : error CNDL0014 : The TypeLib/@HelpDirec tory attribute's value, '[INSTALLDIR]', is not a legal identifier. Identifier's may contain ASCII characters A-Z, a-z, digits, underscores (_), or periods (.). Every identifier must begin with either a letter or an underscore. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ICE03: String overflow warning
Hi, When I compile my WIX project, I get the following warning: ICE03: String overflow (greater than length permitted in column); Table: CustomAction, Column: Target Is this something I should care about? After all, the column is limited (according to Orca) to 255 chars which is not enough given that I must put in all the data I want to access from a deferred custom action. Or is there another way to transfer data from the MSI database to a deferred custom action? Kind regards, Henning - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix3: File/@Name as part of @Source
alexbirk wrote: BobArnso: - Default File/@Name and @Id to the file name portion of @Source. I detailed what it does on my blog: http://www.joyofsetup.com/2007/12/07/simplifying-the-wix-v3-language/. In real, Wix not working as described in history.txt, but working as described in documentation - if Name not specified then Name *taken from Id*. It is BAD. Files Id must be unique in msi package scope, but file names may be same. It's a default: If you need files with the same name, then you cannot rely on the Name value defaulting from Id. In real life at 99.999% cases File/@Name equal file name part of File/@Sorce. Why Wix take file name from [EMAIL PROTECTED], but not from [EMAIL PROTECTED] ??? Because the compiler already had support for defaulting Name from Id. Defaulting Id from Source was a new feature that wasn't a breaking change. Going the other way would be a breaking change so I didn't pursue it. Feel free to file a feature request -- it's not a bad idea and I think we could check for the combination in WixCop. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallMode Conditions DON'T work!
carlldev wrote: It would have been better if I could tell what mode the installer is in whether it be install, uninstall or repair so that this code isn't tied to a specific feature or component. It's possible to mix and match actions at a feature and component level so there isn't a package-wide installation mode. the custom action I now check the install status of the component that each file belongs to to check whether it should import or remove. That way we can implement a change mode as well and each component will be handled individually And that's exactly how the WiX custom actions work: Everything's driven by the component action state. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] error CNDL0014
Mike Dimmick wrote: The TypeLib/@HelpDirectory attribute's value is supposed to be the ID of the directory, not a Formatted type. Use INSTALLDIR, not [INSTALLDIR]. The documentation isn't very helpful as it's generated directly from the XML schema, which in the main doesn't differentiate between different logical types of string. This is partly due to the difficulty of defining regular expressions for the different types to limit the allowed characters, because WiX also supports using compile-time and localization-time variables in place of at least some identifiers (they must of course ultimately resolve to identifiers). I'm not sure if it's possible to define a new type based on String with no additional restrictions. I just added a new error message for this case: Where an identifier is expected but the compiler gets a [BLAHBLAH] string instead, it throws a more specific error message. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using XmlFile in a merge module
Thank you very much for your reply. We are planning on providing this part of the install to third parties, so the merge module approach is desirable. My answers in bold. - The exact version of WiX you're using, including build number; We are using Wix build 3.0.2925.0 - The name and version of the tool used to build the final .msi; We are using Votive v3 - If you have access to Orca, or another tool for viewing .msm contents, the contents of the ModuleInstallExecuteSequence table from the .msm (specifically the SchedXmlFile row). This is the part that has me stumped. This is the contents of the SchedXmlFile row: Action: SchedXmlFile Sequence: [blank] BaseAction: InstallFiles After: 1 Condition: [blank] Looking at this, you would think SchedXmlFile would occur after InstallFiles, but it doesn't seem to work this way. Any thoughts? Mike Dimmick-2 wrote: Merge modules are for providing to third parties, for them to integrate into their installers. If you're only using this common code in-house, in other WiX-based installers, I recommend building and sharing a .wixlib instead (or you can simply share the .wxs source code, the .wixlib simply saves some compilation time). Sharing components between product installers is being de-emphasised as it leads to trouble with servicing - you cannot target a component with a patch, only a product, so if a defect is discovered in a common component, all products which installed that component have to be patched, unless some other mechanism is available to redirect clients to the new version (e.g. publisher policy in .NET and Win32 assemblies). In answer to your question, the scheduling of custom actions contained in a merge module is controlled by the ModuleInstallExecuteSequence table. Unlike in the master InstallExecuteSequence table, the merge module can specify a sequence relative to a base action rather than a specific sequence. The absolute sequence number is resolved when the module is merged in. This requires that a merge tool is used which understands this - the standard mergemod.dll does. WiX interprets InstallExecuteSequence elements to generate rows in the InstallExecuteSequence for the main installer, if building an .msi (the Product element) or in the ModuleInstallExecuteSequence for a merge module. The standard scheduling of SchedXmlFile, as of at least 3.0.3502, is to come after InstallFiles, but this can be overridden in your own InstallExecuteSequence. To confirm the problem could you post: - The exact version of WiX you're using, including build number; - The name and version of the tool used to build the final .msi; - If you have access to Orca, or another tool for viewing .msm contents, the contents of the ModuleInstallExecuteSequence table from the .msm (specifically the SchedXmlFile row). -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of csellers Sent: 27 December 2007 23:00 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using XmlFile in a merge module I currently have an MSI Wix project that (among other things) copies an xml file and makes modifications to it using util:XmlFile. I am in the process of converting this project to a merge module (MSM), but when I include the merge module in another install, I get an error saying there was a failure while configuring XML files. I then noticed that I get this error before the xml file had been copied (which would explain the error). I did not have this problem when I was building an msi file. Looking at the log file, the failure is in SchedXmlFile, which is occurring before any files have been copied. If I remove the XmlFile commands, the install runs without any problems. Is there a reason why this is happening in the merge module when it didn't in the msi? Is there anyway to control when SchedXmlFile runs? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/Using-XmlFile-in-a-merge-module-tp14519897p14532015.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix question
Hello: I had a Wix related question and thought someone on this alias could help me with this. For my application, I need to add a program files menu item that starts the visual studio command prompt in the directory of my choice (similar to All Programs - Microsoft .NET Framework SDK v2.0 - SDK Command Prompt). Any ideas on how this can be done? I was unable to find a related help topic in the wix documentation. Thanks Vijay _ Don't get caught with egg on your face. Play Chicktionary! http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ICE03: String overflow warning
Codes in deferred custom action cannot directly access MSI database. In the function, you can only read CustomActionData property, of which value is set as the name of the custom action. For example, to transfer the data to the deferred custom action named MyDeferredCustomAction, you have to set the property MyDeferredCustomAction by defining it in the MSI Property table or using immediate custom actions. And then in your deferred custom action code, you use MsiGetProperty(_T(CustomActionData), ...) to retrieve the value. See this: http://msdn2.microsoft.com/en-us/library/aa370543.aspx In well-coded custom actions where deferred custom actions are required, we only schedule the immediate custom actions in the InstallExecutionSequence table, and in an immediate custom action (MyImmediateCustomAction) , we access the MSI table and set MyDeferredCustomAction property appropriately and call DoMsiAction(MyDeferredCustomAction). As MSI properties only can be strings, you may have to use parsers or use binary-to-text encoder/decoder (e.g. binhex, base64 or ascii85). Hope this helps. On Dec 28, 2007 8:47 AM, Krause, Henning [EMAIL PROTECTED] wrote: Hi, When I compile my WIX project, I get the following warning: ICE03: String overflow (greater than length permitted in column); Table: CustomAction, Column: Target Is this something I should care about? After all, the column is limited (according to Orca) to 255 chars which is not enough given that I must put in all the data I want to access from a deferred custom action. Or is there another way to transfer data from the MSI database to a deferred custom action? Kind regards, Henning - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
