[WiX-users] Installation order for Service Installs
Hi all, I want to install a service, but the service needs a runtime installed first to be able to run. More importantly, the C runtime. My current setup is, Feature Id=ServiceToInstall Level=1 InstallDefault=local TypicalDefault=Install MergeRef Id=msvc80 / ComponentRef Id=service_component / /Feature This results in the component installed prior to the runtime or at least the runtime being unavailable before the component is installed and an attempt to start the service is executed. How can I structure this such that the merge module is installed completely prior to installing the component? Thanks, - Adam - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using .NET 2.0 Managed Custom Actions
Really, I did not try out, starting a managed custom action deferred. It needs the installercontext, of the current install to work, is the context still active at that time? Sorry, I don't know. Any hints welcome. Oliver From: Hao Liu [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 24. Oktober 2007 04:48 To: Mailinglist; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Using .NET 2.0 Managed Custom Actions I read and tested the Hosting the CLR with a custom action. It is great to bridge between the unmanaged CA and managed CA. However, it cannot work with a deferred CA. Right? Any input will be appreciated. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mailinglist Sent: Friday, April 20, 2007 4:52 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using .NET 2.0 Managed Custom Actions Hello WiX-users, because we needed to use managed custom actions in our setup, I searched around the net for a real solution to this. I found two projects ([1],[2]), that followed quite good ideas, but both did not work out of the box or only under special circumstances. So I combined them both to something working. Simply, we now use a custom action to start a C++ library, that hosts the CLR, loads a specified assembly and calls a class that needs to implement a small interface. From inside that class the installer context can be used to fill properties, etc. Since the demo code package is 3 MB, I uploaded it to Rapidshare [3] as well as to my blog [4]. Greetings, Oliver Friedrich Consultant - Software Solutions [1] Hosting the CLR within a custom action - Pablo M. Cibaro - http://weblogs.asp.net/cibrax/archive/2005/04/11/399839.aspx [2] Wrapping the Windows Installer 2.0 API - http://www.codeproject.com/csharp/msiinterop.asp [3] Rapidshare Download Link: http://rapidshare.com/files/26953203/ManagedCustomActions.zip.html [4] Blogentry: http://www.forestwalk.de/?p=31 - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX-users Digest, Vol 17, Issue 119
Hi Richard, I assume this isn't done in the Media element as I can only see that you can specify that the cab is embedded and it's name.. Simon -- Message: 8 Date: Tue, 23 Oct 2007 09:24:31 -0600 From: Richard [EMAIL PROTECTED] Subject: Re: [WiX-users] Digital Signatures.. 300 mb limit To: WiX Users wix-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] In article [EMAIL PROTECTED] .co.uk, Simon Topley [EMAIL PROTECTED] writes: Is there a way to split the cab file up so it can be more easily signed? Yes, you can have multiple CABs in your Media table. The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software is strictly prohibited. Wallingford Software is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them. Registered in the UK, company no: 02288719 Wallingford Software Limited, Howbery Park, Wallingford, Oxfordshire, OX10 8BA - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix 2.0 to 3.0 - COM registration
Not a direct answer, but if you run WiX 3.0's heat.exe against your 32-bit COM DLLs then it'll generate the right Class, AppID, Interface etc. output. -- View this message in context: http://www.nabble.com/wix-2.0-to-3.0---COM-registration-tf4682182.html#a13382551 Sent from the wix-users mailing list archive at Nabble.com. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Easy WiX way for a custom action to call multiple utility DLLs?
If my CA in MyCA.dll needs to call a fn in MyUtils.dll then I'm currently expecting to have to write a separate pair of CAs that pull MyUtils.dll out of the Binary table and then delete it at end-of-setup. InstallShield provides just such a handy pair of Custom Actions (ISSETUPFILESEXTRACT co.), and I was wondering if there's any WiX equivalent? tia, Karim -- View this message in context: http://www.nabble.com/Easy-WiX-way-for-a-custom-action-to-call-multiple-utility-DLLs--tf4683485.html#a13382997 Sent from the wix-users mailing list archive at Nabble.com. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] x64 and ProgramFilesFolder vs. ProgramFiles64Folder
Geoff Finger-2 wrote: The specific problem in this case is the x64 installer was working just fine but someone pointed out that one of the files was 32 bit and thus should be installed to Program Files (x86) instead of the normal Program Files folder. On 64-bit Windows, ProgramFiles64Folder will evaluate to Program Files ProgramFilesFolder to Program Files (x86). AFAIK you need to duplicate your directory hierarchies: it won't happen automatically: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=MyApp64Folder Name=MyApp ... /Directory /Directory Directory Id=ProgramFiles64Folder Directory Id=MyAppFolder Name=MyApp ... /Directory /Directory /Directory Geoff Finger-2 wrote: I have InstallerVersion=200 Compressed=yes Platforms=x64 in the Package element, and Win64=yes for all the components (except the one that's _supposed_ to end up in the x86 folder of course.) This sounds right. -Karim -- View this message in context: http://www.nabble.com/x64-and-ProgramFilesFolder-vs.-ProgramFiles64Folder-tf4680463.html#a13383179 Sent from the wix-users mailing list archive at Nabble.com. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix 2.0 to 3.0 - COM registration
All my DLL's are .net assembly but they can be registered as COM. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karim MacDonald Sent: Wednesday, October 24, 2007 3:21 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] wix 2.0 to 3.0 - COM registration Not a direct answer, but if you run WiX 3.0's heat.exe against your 32-bit COM DLLs then it'll generate the right Class, AppID, Interface etc. output. -- View this message in context: http://www.nabble.com/wix-2.0-to-3.0---COM-registration-tf4682182.html#a1338 2551 Sent from the wix-users mailing list archive at Nabble.com. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] AlwaysInstallElevated
On one of my Virtual PC's Custom Actions fails to execute. Log: MSI (c) (E0:F0) [14:10:03:142]: Machine policy value 'AlwaysInstallElevated' is 0 MSI (c) (E0:F0) [14:10:03:142]: User policy value 'AlwaysInstallElevated' is 0 ... MSI (s) (70:B8) [14:10:37:218]: Executing op: CustomActionSchedule(Action=SettingUpConfigFile,ActionType=3073,Source=BinaryData,Target=SetUpConfig,) MSI (s) (70:F0) [14:10:37:298]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI4B.tmp, Entrypoint: SetUpConfig MSI (s) (70:D0) [14:10:37:298]: Generating random cookie. MSI (s) (70:D0) [14:10:37:308]: Created Custom Action Server with PID 900 (0x384). MSI (s) (70:7C) [14:10:37:338]: Running as a service. MSI (s) (70:7C) [14:10:37:338]: Hello, I'm your 32bit Impersonated custom action server. Action ended 14:10:37: InstallFinalize. Return value 3. In WIX source file: CustomAction Id=SettingUpConfigFile BinaryKey=InstallHelper DllEntry=SetUpConfig Execute=deferred Impersonate=no/ InstallExecuteSequence Custom Action=SettingUpConfigFile After=PublishProductNOT Installed/Custom /InstallExecuteSequence This happens only if AlwaysInstallElevated is 0. Can any one explain what does it means and how to solve this problem? Thank you very much, Benas - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Feature selection conditions don't work on reinstall
I was under the impression that while it is only permitted to *trigger* one NewDialog operation, it is permitted to include definitions for several trigger operations as long as the conditions under which the separate dialogs are shown are mutually exclusive. I agree however that is not what the documentation (currently at http://msdn2.microsoft.com/en-us/library/aa368037.aspx) appears to suggest. One thing I would make sure of... presumably the default state for MyFeature will be set during CostFinalize (which I believe should have occurred before the UI is shown). I have a horrible sneaking suspicion that any modifications the user makes to the feature installation state will not be stored until the next dialog is triggered... which means that at the time you are performing the test (still inside the CustomizeDlg) the value for MyFeature will not yet have been modified. (A look at the verbose log may confirm this). In the sample from the tutorial, the property being tested was already set before entering the CustomizeDlg, and is not modified by the CustomizeDlg. As a result, it operates correctly. Of course, this is just a hypothesis. Hopefully someone with more Microsoft Installer knowledge will be able to confirm if I am barking up the wrong tree! Regards, Richard (there are too many of us around here! :-) ) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sent: Tuesday, October 23, 2007 8:44 PM To: WiX Users Subject: Re: [WiX-users] Feature selection conditions don't work on reinstall In article [EMAIL PROTECTED], OneReallyCoolApplication [EMAIL PROTECTED] writes: But how come the sample WiX code from Tramontana has multiple NewDialog events? Because its buggy? I didn't write that sample code, so I can't tell you why it is the way it is. However, if you look at the Windows Installer documentation, you will the restriction of a single NewDialog control event on any given control. If you don't observe the restriction, sometimes it works. But its only working by accident, not by design. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Checkbox does not recognize when it is checked
I am trying to give the option to delete some extra files if the user checks
a checkbox on uninstall. I can bypass the checkbox and make it delete the
files but when the checkbox is present, it deletes the files whether it is
checked or not. Any ideas what I am doing wrong?
Code segments below.
Thanks,
Mark
--
Control Id='All_Files' Type='CheckBox' X='10' Y='30' Width='400'
Height='18' Property='DELALL' CheckBoxValue=1
TextCheck the box to Delete extensibility.dll/Text
/Control
Control Id='RemoveNow' Type='PushButton' X='276' Y='210' Width='90'
Height='18' Default='yes'
Text![CDATA[{\Tahoma10}Remove Now]]/Text
/Control
---
Component Id='MyComponent' Guid='BLah BLah BLah-123456789012'
Condition
DELALL = 1
/Condition
RemoveFile Id='LogFile' On='uninstall' Name='*.*' /
RemoveFolder Id='TheDir' On='uninstall'/
/Component
-
--
View this message in context:
http://www.nabble.com/Checkbox-does-not-recognize-when-it-is-checked-tf4683976.html#a13384533
Sent from the wix-users mailing list archive at Nabble.com.
-
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-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wixout file format
Is anything in Wix 3.0 documented? Sorry. I just couldn't resist. Rob Mensching [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/23/2007 03:11 PM To 'Rob Mensching' [EMAIL PROTECTED], 'Adam Majer' [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net Subject Re: [WiX-users] wixout file format Also, the .wixout format is not documented. We don't expect people to really care about it or expect it to be one thing or another over time. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 15:05 To: 'Adam Majer' Cc: 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] wixout file format And it would be much bigger and slower to load, neither of which are desirable (especially if your project is as large as Office). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Majer Sent: Tuesday, October 23, 2007 13:46 Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] wixout file format Peter Marcu wrote: The wixout is not a pure xml file in WiX 3.0. It has a cab at the beginning of it that contains embedded binary files. Wouldn't it be possible to fix this such that it is a proper XML file? The cab could be embedded in the XML (eg. base64) and the entire thing would be much better, though not exactly perfect. At least it would work with XML parsers. - Adam - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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-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: 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix 2.0 to 3.0 - COM registration
Nitin Chaudhari wrote: All my DLL's are .net assembly but they can be registered as COM. Sorry, I should've looked more closely at your registry entries. FWIW, here's my take on the problem: http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on-generated-registry-data-tf2815472.html#a13239912 http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on-generated-registry-data-tf2815472.html#a13239912 I think that the problem is shared between heat.exe and candle.exe, and came to the conclusion that unless WiX is tweaked to specifically consider COM-registerable .NET assemblies then large numbers of registry keys end up being the cleanest solution. -- View this message in context: http://www.nabble.com/wix-2.0-to-3.0---COM-registration-tf4682182.html#a13384750 Sent from the wix-users mailing list archive at Nabble.com. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix 2.0 to 3.0 - COM registration
Using registry keys is the recommended way of registering .NET Assemblies for COM Interop. http://msdn2.microsoft.com/en-us/library/aa367520.aspx Use the Registry table instead of the Class table when you register COM Interop for an assembly. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] Im Auftrag von Karim MacDonald Gesendet: Mittwoch, 24. Oktober 2007 16:26 An: wix-users@lists.sourceforge.net Betreff: Re: [WiX-users] wix 2.0 to 3.0 - COM registration Nitin Chaudhari wrote: All my DLL's are .net assembly but they can be registered as COM. Sorry, I should've looked more closely at your registry entries. FWIW, here's my take on the problem: http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on- generated-registry-data-tf2815472.html#a13239912 http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130-on- generated-registry-data-tf2815472.html#a13239912 I think that the problem is shared between heat.exe and candle.exe, and came to the conclusion that unless WiX is tweaked to specifically consider COM-registerable .NET assemblies then large numbers of registry keys end up being the cleanest solution. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix 2.0 to 3.0 - COM registration
You can use the 'undocumented' -scom switch with heat.exe to generate only RegistryKey/RegistryValue-entries (instead of Class/ProgId/...). -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] Im Auftrag von Strele Franz Gesendet: Mittwoch, 24. Oktober 2007 16:48 An: wix-users@lists.sourceforge.net Betreff: Re: [WiX-users] wix 2.0 to 3.0 - COM registration Using registry keys is the recommended way of registering .NET Assemblies for COM Interop. http://msdn2.microsoft.com/en-us/library/aa367520.aspx Use the Registry table instead of the Class table when you register COM Interop for an assembly. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] Im Auftrag von Karim MacDonald Gesendet: Mittwoch, 24. Oktober 2007 16:26 An: wix-users@lists.sourceforge.net Betreff: Re: [WiX-users] wix 2.0 to 3.0 - COM registration Nitin Chaudhari wrote: All my DLL's are .net assembly but they can be registered as COM. Sorry, I should've looked more closely at your registry entries. FWIW, here's my take on the problem: http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130- on- generated-registry-data-tf2815472.html#a13239912 http://www.nabble.com/heating-COM-componnents-and-getting-LGHT0130- on- generated-registry-data-tf2815472.html#a13239912 I think that the problem is shared between heat.exe and candle.exe, and came to the conclusion that unless WiX is tweaked to specifically consider COM-registerable .NET assemblies then large numbers of registry keys end up being the cleanest solution. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] error in selection tree(urgent plz help)
shambhu kumar wrote: UIText Id=SelAbsent![CDATA[This feature will not be available.]]/UIText UIText Id=Seldvertise![CDATA[This feature will be installed when required.]]/UIText UIText Id=SelAllLocal![CDATA[This feature, and all subfeatures, will be installed on local hard drive.]]/UIText UIText Id=SelAbsentLocal![CDATA[This feature will be installed on the local hard drive.]]/UIText There are many more UIText strings required for the selection tree control with different IDs. See http://msdn2.microsoft.com/en-us/library/aa371604.aspx for a list. -- sig://boB http://joyofsetup.com/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] x64 and ProgramFilesFolder vs. ProgramFiles64Folder
Geoff Finger wrote: Instead what I found was a post claiming I don't think you want to reference ProgramFiles64Folder either. Use ProgramFilesFolder and Windows Installer will put things in the correct directory based upon the Component's Win64 setting. That's not how it works. A 64-bit package can write to both folders (as appropriate given the bitness of its components) but it's not automatic so you need both directory hierarchies. -- sig://boB http://joyofsetup.com/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installation order for Service Installs
Adam Majer wrote: How can I structure this such that the merge module is installed completely prior to installing the component? That's not how Windows Installer works: Merge modules lose their identity when merged, so they're just a bunch of components in the .msi. Then, each resource of each component is installed, via standard actions. (InstallFiles, for example, installs all the files in all components before WriteRegistryValues writes all the registry values for all components.) If you need tighter control than that, you need to use separate packages and a chainer. -- sig://boB http://joyofsetup.com/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX-users Digest, Vol 17, Issue 119
Simon Topley wrote: I assume this isn't done in the Media element as I can only see that you can specify that the cab is embedded and it's name.. Yes, you have multiple Media elements and use the DiskId attribute to control which components go into which .cab. -- sig://boB http://joyofsetup.com/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] wix.dll different?
for wix v3, build 3419, why is there a difference in the wix.dll that is installed with the msi and the version found in the zip file? if i install the msi to get the votive stuff and the xml references and stuff installed for VS, but then use binaries extracted into a temp directory to compile my wxs files, candle gives me an exception error, complaining about the public key token for wix.dll. if i copy the wix.dllinstalled with the MSI into my temp binary directory, it works fine. beyond compare shows the two files have the same version, but are not the same file with different file sizes and checksums. is there a reason behind this. Log file: Z:\test\wix3candle z:\test\padds\pdb.wxs -out z:\test\padds\pdb.wxs Unhandled Exception: System.IO.FileLoadException: Could not load file or assembl y 'wix, Version=3.0.3419.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad' or one of its dependencies. The located assembly's manifest definition does not ma tch the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'wix, Version=3.0.3419.0, Culture=neutral, PublicKeyToken=ce35f76fcda 82bad' === Pre-bind state information === LOG: User = NYCD-7SQC691-D\dgotthar LOG: DisplayName = wix, Version=3.0.3419.0, Culture=neutral, PublicKeyToken=ce35 f76fcda82bad (Fully-specified) LOG: Appbase = file:///Z:/test/wix3/ LOG: Initial PrivatePath = NULL Calling assembly : candle, Version=3.0.3419.0, Culture=neutral, PublicKeyToken=c e35f76fcda82bad. === LOG: This bind starts in default load context. LOG: Using application configuration file: Z:\test\wix3\candle.exe.Config LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2 .0.50727\config\machine.config. LOG: Post-policy reference: wix, Version=3.0.3419.0, Culture=neutral, PublicKeyT oken=ce35f76fcda82bad LOG: Attempting download of new URL file:///Z:/test/wix3/wix.DLL. WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Minimal UI doesn't paint license agreement
On 1/22/07, Goetz, Russ [EMAIL PROTECTED] wrote: Thanks to help from this group I am now able to specify which UI I wish to use by passing the following to light.exe: -ext WixUIExtension.dll-cultures:en-us and specifying say UIRef Id=WixUI_Minimal / In my .wxs file. The minimal UI shows a license agreement screen first then installs the product. Is there any way to change this so that it shows only a welcome screen then installs the product? I have a follow-up question to this... Is there a way to actually get the license agreement to show on the license agreement screen without having to highlight the text or adjust the scrollbar? I find that my license agreement is there - but is not drawn until I try to manipulate the text control that it is shown in. Is there a workaround? Scott - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix.dll different?
koawmfot wrote: for wix v3, build 3419, why is there a difference in the wix.dll that is installed with the msi and the version found in the zip file? It's a bug in the build process. For now, stick with the .msi copy. -- sig://boB http://joyofsetup.com/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Minimal UI doesn't paint license agreement
Scott Palmer wrote: Is there a way to actually get the license agreement to show on the license agreement screen without having to highlight the text or adjust the scrollbar? I find that my license agreement is there - but is not drawn until I try to manipulate the text control that it is shown in. Is there a workaround? Re-save the .rtf file in WordPad. RTF produced by Word is too complex for the rich-edit control. -- sig://boB http://joyofsetup.com/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wixout file format
I know you're being slightly flippant but truly the answer is, Yes, the schema is all documented. The command-lines and the tools to use are documented. I'm happy for people to say, Hey, such-and-such isn't documented. can I expect it to remain constant supported and all that good stuff? I'll then go into the tools and see if it is a purposeful feature or a side-effect that might change in the future. The former is something I should document. The latter is something you should not use. In this case, the fact that .wixout files were once XML files was a side-effect of some decisions made at the beginning of time (for WiX v2). Later (in WiX v3), having binary wixouts (and .wixlibs but nobody has been complaining about them grin/) provided us with some really nice features. So, we changed it. Thus far I have only had two organizations get huffy about that change, Microsoft Office and Microsoft Visual Studio. Why? Because they wrote tools that went in and dorked with the .wixout files as XML directly instead of using other supported mechanisms in the WiX toolset for doing what they wanted to do. Apparently, no one in Office told Justin (who, based on the gigantic signature on the end of his email, appears to work in Microsoft Office) that the .wixout files haven't been XML files for about a year now. smile/ From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 06:48 To: Rob Mensching Cc: 'Adam Majer'; Rob Mensching; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] wixout file format Is anything in Wix 3.0 documented? Sorry. I just couldn't resist. Rob Mensching [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/23/2007 03:11 PM To 'Rob Mensching' [EMAIL PROTECTED], 'Adam Majer' [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net Subject Re: [WiX-users] wixout file format Also, the .wixout format is not documented. We don't expect people to really care about it or expect it to be one thing or another over time. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 15:05 To: 'Adam Majer' Cc: 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] wixout file format And it would be much bigger and slower to load, neither of which are desirable (especially if your project is as large as Office). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Majer Sent: Tuesday, October 23, 2007 13:46 Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] wixout file format Peter Marcu wrote: The wixout is not a pure xml file in WiX 3.0. It has a cab at the beginning of it that contains embedded binary files. Wouldn't it be possible to fix this such that it is a proper XML file? The cab could be embedded in the XML (eg. base64) and the entire thing would be much better, though not exactly perfect. At least it would work with XML parsers. - Adam - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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-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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and
Re: [WiX-users] Checkbox does not recognize when it is checked
In article [EMAIL PROTECTED], xyavier [EMAIL PROTECTED] writes: I am trying to give the option to delete some extra files if the user checks a checkbox on uninstall. I can bypass the checkbox and make it delete the files but when the checkbox is present, it deletes the files whether it is checked or not. Any ideas what I am doing wrong? Code segments below. Thanks, Mark -- Control Id='All_Files' Type='CheckBox' X='10' Y='30' Width='400' Height='18' Property='DELALL' CheckBoxValue=1 TextCheck the box to Delete extensibility.dll/Text /Control This looks OK, did you double check the Control row for this control and the CheckBox table row in the MSI with Orca? In your verbose log, does the DELALL property have a value of '1' when the checkbox is checked? What does your verbose log say about your component 'MyComponent'? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Feature selection conditions don't work on reinstall
In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes: I was under the impression that while it is only permitted to *trigger* one NewDialog operation, it is permitted to include definitions for several trigger operations as long as the conditions under which the separate dialogs are shown are mutually exclusive. That's what I thought too, but I've had it fail even when the conditiosn were all mutually exclusive. Fortunately its not that hard to change the way you're managing the dialog transitions by using a property to hold the name of the target dialog for NewDialog. Why continue using something that works by accident when the change to make it work by design is easy? Isn't there an ICE that checks for multiple NewDialog control events on a single control? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installation order for Service Installs
In article [EMAIL PROTECTED], Adam Majer [EMAIL PROTECTED] writes: How can I structure this such that the merge module is installed completely prior to installing the component? In addition to what Bob Arnson said, check your install execute sequence and look at the relative ordering of the standard actions that manipulate services and those that install the files. The canonical sequence has the sequence of: stop services, install files, start services, so you should be OK. How did you determine that your service didn't start because of missing runtime files? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Invokoing DLL at the time of installation ...
In article [EMAIL PROTECTED], V K Gangwar [EMAIL PROTECTED] writes: I need to invoke a function (method) in a DLL and want to use return va= lue of that function. How this can be done. The best practice is to minimize the amount of custom code that's running at install time. What is this function doing and why do you need to call it at install time? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix 2.0 to 3.0 - COM registration
In article [EMAIL PROTECTED], Nitin [EMAIL PROTECTED] writes: All my DLL's are .net assembly but they can be registered as COM. Regasm /File will dump out a registry file of all the registry values/keys that are needed to register your assembly. Is there some tool in WiX that will eat a .reg file and turn it into the necessary markup? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix.dll different?
It is a mistake in the build process. I've been screwing around with the public key and the way that we store it on the build machine and the way we reference it in the build system and I apparently got things crossed somewhere. I'll get into it before the next build. Thanks for pointing this out. I probably never would have noticed and we'd forever have mismatched public key tokens between the MSI and the .zip file. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of koawmfot Sent: Wednesday, October 24, 2007 08:10 To: wix-users@lists.sourceforge.net Subject: [WiX-users] wix.dll different? for wix v3, build 3419, why is there a difference in the wix.dll that is installed with the msi and the version found in the zip file? if i install the msi to get the votive stuff and the xml references and stuff installed for VS, but then use binaries extracted into a temp directory to compile my wxs files, candle gives me an exception error, complaining about the public key token for wix.dll. if i copy the wix.dll installed with the MSI into my temp binary directory, it works fine. beyond compare shows the two files have the same version, but are not the same file with different file sizes and checksums. is there a reason behind this. Log file: Z:\test\wix3candle z:\test\padds\pdb.wxs -out z:\test\padds\pdb.wxs Unhandled Exception: System.IO.FileLoadException: Could not load file or assembl y 'wix, Version=3.0.3419.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad' or one of its dependencies. The located assembly's manifest definition does not ma tch the assembly reference. (Exception from HRESULT: 0x80131040) File name: 'wix, Version=3.0.3419.0, Culture=neutral, PublicKeyToken=ce35f76fcda 82bad' === Pre-bind state information === LOG: User = NYCD-7SQC691-D\dgotthar LOG: DisplayName = wix, Version=3.0.3419.0, Culture=neutral, PublicKeyToken=ce35 f76fcda82bad (Fully-specified) LOG: Appbase = file:///Z:/test/wix3/ file:///Z:\test\wix3\ LOG: Initial PrivatePath = NULL Calling assembly : candle, Version=3.0.3419.0, Culture=neutral, PublicKeyToken=c e35f76fcda82bad. === LOG: This bind starts in default load context. LOG: Using application configuration file: Z:\test\wix3\candle.exe.Config LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2 .0.50727\config\machine.config. LOG: Post-policy reference: wix, Version= 3.0.3419.0, Culture=neutral, PublicKeyT oken=ce35f76fcda82bad LOG: Attempting download of new URL file:///Z:/test/wix3/wix.DLL file:///Z:\test\wix3\wix.DLL . WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installation order for Service Installs
Bob Arnson wrote: Adam Majer wrote: How can I structure this such that the merge module is installed completely prior to installing the component? That's not how Windows Installer works: Merge modules lose their identity when merged, so they're just a bunch of components in the .msi. Then, each resource of each component is installed, via standard actions. (InstallFiles, for example, installs all the files in all components before WriteRegistryValues writes all the registry values for all components.) If you need tighter control than that, you need to use separate packages and a chainer. Are you saying that it is impossible to install a service that depends on a MSVC runtime and start it in the same installer? Surely, that can't be true. The installation keeps bombing that SxS install is not correct. Now, if I do not attempt to start the service, installation completes and I can start the service manually, through reboot or use a program that uses the same runtime SxS. It is as though SxS is not installed until after the installer is done making it unavailable to anything (including custom actions) called by the installer. The structure of the installer is very simple. directory... directory ... component id=service File id=service. ServiceInstall ServiceControl start=install ... /component /directory merge id=vcrt80 .../ /directory feature id=service level=1 .. componentref id=service mergeref id=vcrt80 /feature Therefore, to start services that need the SxS module installed by the same MSI, * reboot like in old days to start, * start manually, or * ??? - Adam - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wixout file format
Yep... I kinda forgot the smiley in my email :) So where is the 'command lines and the tools to use' documentation located, precisely? Kelly Rob Mensching [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/24/2007 09:05 AM To 'Kelly Leahy' [EMAIL PROTECTED] cc [EMAIL PROTECTED], wix-users@lists.sourceforge.net Subject Re: [WiX-users] wixout file format I know you’re being slightly flippant but truly the answer is, “Yes, the schema is all documented. The command-lines and the tools to use are documented.” I’m happy for people to say, “Hey, such-and-such isn’t documented… can I expect it to remain constant supported and all that good stuff?” I’ll then go into the tools and see if it is a purposeful feature or a side-effect that might change in the future. The former is something I should document. The latter is something you should not use. In this case, the fact that .wixout files were once XML files was a “side-effect” of some decisions made “at the beginning of time” (for WiX v2). Later (in WiX v3), having “binary wixouts” (and .wixlibs but nobody has been complaining about them grin/) provided us with some really nice features. So, we changed it. Thus far I have only had two organizations get huffy about that change, Microsoft Office and Microsoft Visual Studio. Why? Because they wrote tools that went in and dorked with the .wixout files as XML directly instead of using other supported mechanisms in the WiX toolset for doing what they wanted to do. Apparently, no one in Office told Justin (who, based on the gigantic signature on the end of his email, appears to work in Microsoft Office) that the .wixout files haven’t been XML files for about a year now. smile/ From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 06:48 To: Rob Mensching Cc: 'Adam Majer'; Rob Mensching; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] wixout file format Is anything in Wix 3.0 documented? Sorry. I just couldn't resist. Rob Mensching [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/23/2007 03:11 PM To 'Rob Mensching' [EMAIL PROTECTED], 'Adam Majer' [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net Subject Re: [WiX-users] wixout file format Also, the .wixout format is not documented. We don't expect people to really care about it or expect it to be one thing or another over time. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 15:05 To: 'Adam Majer' Cc: 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] wixout file format And it would be much bigger and slower to load, neither of which are desirable (especially if your project is as large as Office). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Majer Sent: Tuesday, October 23, 2007 13:46 Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] wixout file format Peter Marcu wrote: The wixout is not a pure xml file in WiX 3.0. It has a cab at the beginning of it that contains embedded binary files. Wouldn't it be possible to fix this such that it is a proper XML file? The cab could be embedded in the XML (eg. base64) and the entire thing would be much better, though not exactly perfect. At least it would work with XML parsers. - Adam - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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-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
Re: [WiX-users] Installation order for Service Installs
Richard wrote: In article [EMAIL PROTECTED], Adam Majer [EMAIL PROTECTED] writes: How can I structure this such that the merge module is installed completely prior to installing the component? In addition to what Bob Arnson said, check your install execute sequence and look at the relative ordering of the standard actions that manipulate services and those that install the files. The canonical sequence has the sequence of: stop services, install files, start services, so you should be OK. How did you determine that your service didn't start because of missing runtime files? Vista says that SxS (Visual C runtime 8.0 from VS 2005 SP1) is not available. Starting a configuration utility that depends on the same SxS indicated that there is a SxS installation error. If I do not attempt to start the service in the installer, I can run the configuration utility or the service after installation is complete. While searching the archives, I came across a response by Rob Mensching that appears to address the same problem. Usually, this means your service has some dependency that hasn’t been completely installed by the time StartServices is called. A favorite way to hit this is to have a managed code service that depends on an assembly that is being installed to the GAC. Because assemblies aren’t committed to the GAC until InstallFinalize, the assembly won’t be found in the GAC until the install is complete. Moving the StartService after InstallFinalize didn't work - got an error that didn't even rollback :) Kind of expected. I'll try to install as a local assembly in addition to the merge module and see what happens. - Adam - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installation order for Service Installs
We have one service in the installer that replies on a file being installed to the GAC, so the service can't be started until after InstallFinalize. I use a deferred Custom Action to NET START servicename and it seems to be working fine for our customers. Just thought I'd mention that option. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Majer Sent: Wednesday, October 24, 2007 9:48 AM To: WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] Installation order for Service Installs Bob Arnson wrote: Adam Majer wrote: How can I structure this such that the merge module is installed completely prior to installing the component? That's not how Windows Installer works: Merge modules lose their identity when merged, so they're just a bunch of components in the .msi. Then, each resource of each component is installed, via standard actions. (InstallFiles, for example, installs all the files in all components before WriteRegistryValues writes all the registry values for all components.) If you need tighter control than that, you need to use separate packages and a chainer. Are you saying that it is impossible to install a service that depends on a MSVC runtime and start it in the same installer? Surely, that can't be true. The installation keeps bombing that SxS install is not correct. Now, if I do not attempt to start the service, installation completes and I can start the service manually, through reboot or use a program that uses the same runtime SxS. It is as though SxS is not installed until after the installer is done making it unavailable to anything (including custom actions) called by the installer. The structure of the installer is very simple. directory... directory ... component id=service File id=service. ServiceInstall ServiceControl start=install ... /component /directory merge id=vcrt80 .../ /directory feature id=service level=1 .. componentref id=service mergeref id=vcrt80 /feature Therefore, to start services that need the SxS module installed by the same MSI, * reboot like in old days to start, * start manually, or * ??? - Adam - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installation order for Service Installs
That's correct, Vista uses the same SxS model with Fusion to install the C++ runtimes as GAC installation, so the runtimes aren't available until after InstallFinalize. Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Majer Sent: Wednesday, October 24, 2007 9:55 AM Cc: WiX Users Subject: Re: [WiX-users] Installation order for Service Installs Richard wrote: In article [EMAIL PROTECTED], Adam Majer [EMAIL PROTECTED] writes: How can I structure this such that the merge module is installed completely prior to installing the component? In addition to what Bob Arnson said, check your install execute sequence and look at the relative ordering of the standard actions that manipulate services and those that install the files. The canonical sequence has the sequence of: stop services, install files, start services, so you should be OK. How did you determine that your service didn't start because of missing runtime files? Vista says that SxS (Visual C runtime 8.0 from VS 2005 SP1) is not available. Starting a configuration utility that depends on the same SxS indicated that there is a SxS installation error. If I do not attempt to start the service in the installer, I can run the configuration utility or the service after installation is complete. While searching the archives, I came across a response by Rob Mensching that appears to address the same problem. Usually, this means your service has some dependency that hasn't been completely installed by the time StartServices is called. A favorite way to hit this is to have a managed code service that depends on an assembly that is being installed to the GAC. Because assemblies aren't committed to the GAC until InstallFinalize, the assembly won't be found in the GAC until the install is complete. Moving the StartService after InstallFinalize didn't work - got an error that didn't even rollback :) Kind of expected. I'll try to install as a local assembly in addition to the merge module and see what happens. - Adam - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wixout file format
Well, “-?” is documentation. smile/ The tools are supposed to be documented in WiX.chm… although, I expect we’re behind on that and I’d happily take bugs assigned to me to address. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 09:50 To: Rob Mensching Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] wixout file format Yep... I kinda forgot the smiley in my email :) So where is the 'command lines and the tools to use' documentation located, precisely? Kelly Rob Mensching [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/24/2007 09:05 AM To 'Kelly Leahy' [EMAIL PROTECTED] cc [EMAIL PROTECTED], wix-users@lists.sourceforge.net Subject Re: [WiX-users] wixout file format I know you’re being slightly flippant but truly the answer is, “Yes, the schema is all documented. The command-lines and the tools to use are documented.” I’m happy for people to say, “Hey, such-and-such isn’t documented… can I expect it to remain constant supported and all that good stuff?” I’ll then go into the tools and see if it is a purposeful feature or a side-effect that might change in the future. The former is something I should document. The latter is something you should not use. In this case, the fact that .wixout files were once XML files was a “side-effect” of some decisions made “at the beginning of time” (for WiX v2). Later (in WiX v3), having “binary wixouts” (and .wixlibs but nobody has been complaining about them grin/) provided us with some really nice features. So, we changed it. Thus far I have only had two organizations get huffy about that change, Microsoft Office and Microsoft Visual Studio. Why? Because they wrote tools that went in and dorked with the .wixout files as XML directly instead of using other supported mechanisms in the WiX toolset for doing what they wanted to do. Apparently, no one in Office told Justin (who, based on the gigantic signature on the end of his email, appears to work in Microsoft Office) that the .wixout files haven’t been XML files for about a year now. smile/ From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 24, 2007 06:48 To: Rob Mensching Cc: 'Adam Majer'; Rob Mensching; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] wixout file format Is anything in Wix 3.0 documented? Sorry. I just couldn't resist. Rob Mensching [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/23/2007 03:11 PM To 'Rob Mensching' [EMAIL PROTECTED], 'Adam Majer' [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net Subject Re: [WiX-users] wixout file format Also, the .wixout format is not documented. We don't expect people to really care about it or expect it to be one thing or another over time. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 15:05 To: 'Adam Majer' Cc: 'wix-users@lists.sourceforge.net' Subject: RE: [WiX-users] wixout file format And it would be much bigger and slower to load, neither of which are desirable (especially if your project is as large as Office). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Majer Sent: Tuesday, October 23, 2007 13:46 Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] wixout file format Peter Marcu wrote: The wixout is not a pure xml file in WiX 3.0. It has a cab at the beginning of it that contains embedded binary files. Wouldn't it be possible to fix this such that it is a proper XML file? The cab could be embedded in the XML (eg. base64) and the entire thing would be much better, though not exactly perfect. At least it would work with XML parsers. - Adam - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - 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-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
Re: [WiX-users] AlwaysInstallElevated
Most likely your custom action is crashing. If it works when you run it elevated then it's probably a security issue. Are you checking the results of API calls? Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benas Sent: Wednesday, October 24, 2007 4:30 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] AlwaysInstallElevated On one of my Virtual PC's Custom Actions fails to execute. Log: MSI (c) (E0:F0) [14:10:03:142]: Machine policy value 'AlwaysInstallElevated' is 0 MSI (c) (E0:F0) [14:10:03:142]: User policy value 'AlwaysInstallElevated' is 0 ... MSI (s) (70:B8) [14:10:37:218]: Executing op: CustomActionSchedule(Action=SettingUpConfigFile,ActionType=3073,Source=BinaryData,Target=SetUpConfig,) MSI (s) (70:F0) [14:10:37:298]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI4B.tmp, Entrypoint: SetUpConfig MSI (s) (70:D0) [14:10:37:298]: Generating random cookie. MSI (s) (70:D0) [14:10:37:308]: Created Custom Action Server with PID 900 (0x384). MSI (s) (70:7C) [14:10:37:338]: Running as a service. MSI (s) (70:7C) [14:10:37:338]: Hello, I'm your 32bit Impersonated custom action server. Action ended 14:10:37: InstallFinalize. Return value 3. In WIX source file: CustomAction Id=SettingUpConfigFile BinaryKey=InstallHelper DllEntry=SetUpConfig Execute=deferred Impersonate=no/ InstallExecuteSequence Custom Action=SettingUpConfigFile After=PublishProductNOT Installed/Custom /InstallExecuteSequence This happens only if AlwaysInstallElevated is 0. Can any one explain what does it means and how to solve this problem? Thank you very much, Benas - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wixout file format
Rob Mensching wrote: schema is all documented. The command-lines and the tools to use are documented.” I’m happy for people to say, “Hey, such-and-such isn’t documented… can I expect it to remain constant supported and all that good stuff?” I’ll then go into the tools and see if it is a purposeful feature or a side-effect that might change in the future. The former is something I should document. The latter is something you should not use. I'll bite on that and point you to light.exe command line options. light.exe 3.0.2925.0 [snip] -xo output xml instead of MSI format [snip] So either xml is not xml or -xo file format changed but documentation has not. Maybe it should say output internal WiX format instead of MSI format. Plain XML is still nicer regardless if it will result in something 1.35 times bigger (if binary part is base64 encoded). But then I don't really have anything invested in -xo output format so it doesn't really matter to me. - Adam PS. Another way would be to have a -xo for plain XML and -xb for the new binary format. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Sql extension problem
Trying to add a reference to the WixSqlExtension.dll on my project, and adding xmlns:Sql=http://schemas.microsoft.com/wix/SqlExtension; I always get this error: The extension 'Microsoft.Tools.WindowsInstallerXml.Extensions.SqlCompiler' uses the same xml schema namespace, 'http://schemas.microsoft.com/wix/SqlExtension', as previously loaded extension 'Microsoft.Tools.WindowsInstallerXml.Extensions.SqlCompiler'. Please either remove one of the extensions or rename the xml schema namespace to avoid the collision. how can i fix it? thanks -- View this message in context: http://www.nabble.com/Sql-extension-problem-tf4685658.html#a13390434 Sent from the wix-users mailing list archive at Nabble.com. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Minimal UI doesn't paint license agreement
On 10/24/07, Bob Arnson [EMAIL PROTECTED] wrote: Scott Palmer wrote: Is there a way to actually get the license agreement to show on the license agreement screen without having to highlight the text or adjust the scrollbar? I find that my license agreement is there - but is not drawn until I try to manipulate the text control that it is shown in. Is there a workaround? Re-save the .rtf file in WordPad. RTF produced by Word is too complex for the rich-edit control. Ok, thanks. It's funny that the Mondo UI doesn't show the same problem with the same RTF file. Must be related to the dimensions of the control or something. Scott - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Minimum Requirements for msi on client machine.
Hi, There was a strange issue which occured. I created a msi which was running perfectly on mine as well as another developer's machine, but it just ended prematurely when we copied this msi to another colleague (non-developer)'s machine. Of special notice is that it ended when the pressing on a next button which had a custom action linked to a c++ dll. (which worked perfectly fine on mine machine). On doing logging it was pointing to this line: Action ended 10:54:53: VerifyLicenseKey. Return value 3.DEBUG: Error 2896: Executing action VerifyLicenseKey failed. (VerifyLicenseKey is a c++ method signature) I would like to ask, what is the minimum requirements for a msi installation on a client machine , which has a c++ custom action in it ? Thanks for any suggestions! _ Express yourself with the latest Windows Live Messenger! Get it free today! http://www.get.live.com/wl/all- 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Minimum Requirements for msi on client machine.
Hi, do you compile your custom action in Debug or in Release? Whic version of C++ are you using? Be sure to deploy the VC runtime too. Run depends.exe tool on your friend´s machine and validate each dependence of your custom action dll. Regards Silvio. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jaguar 36 Sent: Wednesday, October 24, 2007 4:14 PM To: wix Subject: [WiX-users] Minimum Requirements for msi on client machine. Hi, ? There was a strange issue which occured. I created a msi which was running perfectly on mine as well as another developer's machine, but it just ended prematurely when we copied this msi to another colleague (non-developer)'s machine. Of special notice is that it ended when the pressing on a next button which had a custom action linked to a c++ dll. (which worked perfectly fine on mine machine). On doing logging it was pointing to this line: Action ended 10:54:53: VerifyLicenseKey. Return value 3. DEBUG: Error 2896:?Executing action VerifyLicenseKey failed. (VerifyLicenseKey is a c++ method signature) I would like to ask, what is the minimum requirements for a msi installation on a client machine , which has a c++ custom action in it ? ? Thanks for any suggestions! _ Express yourself with the latest Windows Live Messenger! Get it free today! HYPERLINK http://www.get.live.com/wl/allWindows Live Messenger No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.9/1090 - Release Date: 10/24/2007 8:48 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.9/1090 - Release Date: 10/24/2007 8:48 AM - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Checkbox does not recognize when it is checked
I did look at them in Orca, it looks OK to me. My verbose log is as follows when it is not checked: MSI (s) (AC:D0) [14:19:52:507]: Component: MyComponent; Installed: Local; Request: Absent; Action: Absent PROPERTY CHANGE: Deleting DELALL property. Its current value is '1'. The log is the same when it is checked. One other note just for clarification. When I make CheckBoxValue='1' and Condition DELALL = '1' /Condition it will delete the files with or without a check in the box. However, When I make it CheckBoxValue=1 and Condition DELALL = 1 /Condition It will never delete the files checked or not. Should it be single or double quotes? Thanks again, Mark Richard-45 wrote: In article [EMAIL PROTECTED], xyavier [EMAIL PROTECTED] writes: I am trying to give the option to delete some extra files if the user checks a checkbox on uninstall. I can bypass the checkbox and make it delete the files but when the checkbox is present, it deletes the files whether it is checked or not. Any ideas what I am doing wrong? Code segments below. Thanks, Mark -- Control Id='All_Files' Type='CheckBox' X='10' Y='30' Width='400' Height='18' Property='DELALL' CheckBoxValue=1 TextCheck the box to Delete extensibility.dll/Text /Control This looks OK, did you double check the Control row for this control and the CheckBox table row in the MSI with Orca? In your verbose log, does the DELALL property have a value of '1' when the checkbox is checked? What does your verbose log say about your component 'MyComponent'? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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-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/Checkbox-does-not-recognize-when-it-is-checked-tf4683976.html#a13392533 Sent from the wix-users mailing list archive at Nabble.com. - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Feature selection conditions don't work on reinstall
In article [EMAIL PROTECTED], [EMAIL PROTECTED] writes: Having said that, the scenario which prompted the question may still not work exactly as desired - specifically that the dialog which *immediately* follows the one showing the feature tree varies based on the presence (or otherwise) of a specific feature. Correct operation requires that the feature installation state has been updated before the user clicks next, and I am still not convinced this will be the case. Would any MSI guru care to comment? When I've done this, I wasn't using the feature tree control, but check boxes or radio buttons to select features. I had AddLocal/Remove control events on the control to adjust the feature selection, but since I was using a checkbox or radio button I also had properties of my own that reflected the feature choice. If you are requiring MSI 3.0 or later, then the selection tree control publishes events that can notify you when the feature selection states change. You should be able to use the ControlEvent table for the selection tree to set your own property indicating that a particular feature has been selected for installation and then use that property in a condition on your Next button to manage the dialog transition. I haven't experimented with this, so I don't have specifics on how this works with a SelectionTree control, but the docs indicate that the control communicates by setting properties that indicate what the user did with the control before it processes the ControlEvent table for that control. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Checkbox does not recognize when it is checked
In article [EMAIL PROTECTED], xyavier [EMAIL PROTECTED] writes: MSI (s) (AC:D0) [14:19:52:507]: Component: MyComponent; Installed: Local; Request: Absent; Action: Absent OK, this says your component is installed and will be removed. Isn't there anything later in the log about files being removed for this component and so-on? PROPERTY CHANGE: Deleting DELALL property. Its current value is '1'. This says your property is being nuked. What action is being processed where this occurs in your log? One other note just for clarification. When I make CheckBoxValue='1' and Condition DELALL = '1' /Condition Conditional statement syntax: http://msdn2.microsoft.com/en-us/library/aa368012.aspx Use to surround string literals. Numeric literals don't need them. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Minimum Requirements for msi on client machine.
Hi Thanks Silvio!! The c++ was done in debug mode and we shifted to release mode and it works perfectly! Thanks! Date: Wed, 24 Oct 2007 16:39:31 -0300 From: [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Minimum Requirements for msi on client machine. Hi, do you compile your custom action in Debug or in Release? Whic version of C++ are you using? Be sure to deploy the VC runtime too. Run depends.exe tool on your friend´s machine and validate each dependence of your custom action dll. Regards Silvio. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jaguar 36 Sent: Wednesday, October 24, 2007 4:14 PM To: wix Subject: [WiX-users] Minimum Requirements for msi on client machine. Hi, ? There was a strange issue which occured. I created a msi which was running perfectly on mine as well as another developer's machine, but it just ended prematurely when we copied this msi to another colleague (non-developer)'s machine. Of special notice is that it ended when the pressing on a next button which had a custom action linked to a c++ dll. (which worked perfectly fine on mine machine). On doing logging it was pointing to this line: Action ended 10:54:53: VerifyLicenseKey. Return value 3. DEBUG: Error 2896:?Executing action VerifyLicenseKey failed. (VerifyLicenseKey is a c++ method signature) I would like to ask, what is the minimum requirements for a msi installation on a client machine , which has a c++ custom action in it ? ? Thanks for any suggestions! _ Express yourself with the latest Windows Live Messenger! Get it free today! HYPERLINK http://www.get.live.com/wl/allWindows Live Messenger No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.9/1090 - Release Date: 10/24/2007 8:48 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.9/1090 - Release Date: 10/24/2007 8:48 AM - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users _ Get your free suite of Windows Live services! http://www.get.live.com/wl/all- 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installation order for Service Installs
Wilson, Phil wrote: That's correct, Vista uses the same SxS model with Fusion to install the C++ runtimes as GAC installation, so the runtimes aren't available until after InstallFinalize. Solution: * Install merge module if (VersionNT 600) OR Version9X . In other words, install the merge module on pre-Vista systems and the service will use the merge module files. * On Vista and newer machines (VersionNT = 600), install the runtime as a local assembly in the destination folder of your service. This makes the MSI file larger, but at least it works the Right Way. - Adam - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Minimal UI doesn't paint license agreement
Scott Palmer wrote: Ok, thanks. It's funny that the Mondo UI doesn't show the same problem with the same RTF file. Must be related to the dimensions of the control or something. That's because the EULA isn't shown in the first dialog in that set. That's the trigger. -- sig://boB http://joyofsetup.com/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Sql extension problem
jrcolons wrote: The extension 'Microsoft.Tools.WindowsInstallerXml.Extensions.SqlCompiler' uses the same xml schema namespace, 'http://schemas.microsoft.com/wix/SqlExtension', as previously loaded extension 'Microsoft.Tools.WindowsInstallerXml.Extensions.SqlCompiler'. Please either remove one of the extensions or rename the xml schema namespace to avoid the collision. A common cause of that is loading the same extension twice. -- sig://boB http://joyofsetup.com/ - 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-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
