[WiX-users] Terminal Services support in MSI Installer
I developed a MSI Installer using WixV3 and MS2005. It is working fine for me. Now I have to provide Terminal Services support in my installer. When I tried to install on Win2003. I am getting error that Terminal Services version of driver is required. How I can make my installer to terminal services compatible. Regards, Veerendra -- View this message in context: http://www.nabble.com/Terminal-Services-support-in-MSI-Installer-tf4624850.html#a13207746 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] How do you trace a release version content
Hello, I was looking at the weekly build available for download an I noticed the change log file. How do you proceed it ? List of the Comments of each checkIn ordered by User ? something else ? regards, - 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] Unsigned Drivers not being installed correctly
As part of my install I have an unsigned NDIS IM Network driver component: I am using the following format, with DriverLegacy set to 'yes' because the driver is unsigned, DriverForceInstall set to 'yes' because I want to ensure any file left behind after a previous uninstall gets overwritten and the KeyPath set to the driver's .sys file, to ensure that a successsful install means that the driver is definitely in place. Directory Id='DriverFolder' Name='TSDriver' Component Id='TcpseqDriver' Guid='MyGUID' DriverDeleteFiles='no' DriverForceInstall='yes' DriverLegacy='yes' DriverPlugAndPlayPrompt='no' DriverAddRemovePrograms='no' File Id='Driver' Name='tcpseq.sys' DiskId='1' src='windows\tcpseq\objfre_w2k_x86\i386\tcpseq.sys' Vital='yes' KeyPath='yes' / File Id='TcpseqInf' Name=''tcpseq.inf' DiskId='1' src='windows\tcpseq\tcpseq.inf' Vital='yes' / /Component /Directory Note: I have to use 2 inf files to install this NDIS IM driver, one for the miniport stuff, and one for the network service stuff, and DIFX doesn't support this, I believe, so I just copy the miniport inf to the Windows/inf folder earlier in the install sequence than when MsiInstallDrivers needs it there. However! I get a number of strange scenarios when installing, and I would really appreciate any help that anyone can give me to avoid these scenarios : 1) During the driver install part I usually get prompted by XP oe Vista as to whether or not I want to install the 'unsafe' drvier. However, sometimes I do not get prompted, but the driver is installed anyway. 2) During the 'unsafe' driver install part, if I choose NOT to install the driver, Vista cancels the whole install process and my sytem is left as if I had never run the install. However XP goes ahead and completes the install as if I had chosen to accept the driver. 3) Sometimes after a successful installation, the driver files acts as if it's corrupted, so that the related service is not started properly, and worse, an uninstall (Remove) fails, and any subsequent install does not try to install that particular component. Help, please! Niall -- View this message in context: http://www.nabble.com/Unsigned-Drivers-not-being-installed-correctly-tf4626182.html#a13210196 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] Migrating merge modules to Wix
Hi Bob - thanks for that help. I reverted back to using the same Visual Studio MSM for the WiX installers for this shared COM component (hoping that it would help). Unfortunately it seems that this behaviour (un-installing the VS MSI breaking the COM registration of the shared COM component used by a WiX MSI) is still there! DETAILS I have a shared MSM that installs a shared COM component to ...\Common Files\... (built in VS2005) i) If I build two VS2005 MSIs, that include this merge modules, they coexist well and un-installing one doesn't break the other. ii) If I build two WiX MSIs, that include this merge modules, again they coexist well and un-installing one doesn't break the other. iii) If I build a WiX MSI and a VS MSI, that both include this merge module, when I un-install the Visual Studio one it breaks the WiX installation (though conversely the WiX one doesn't break the VS2005 one). QUESTIONS 1) I wonder if anyone can shed any light on the above issue (is it simply an issue with VS2005 - for which there is no WiX workaround) 2) Secondly, given what Bob has already said: *Is* there a way of migrating shared MSMs from VS2005 to WiX without breaking the component rules. My guess is that the answer is No, and that I have 2 options: either 2.1) add a new duplicate COM class/typelib and have a new WiX MSM that uses different file names and registry settings, or 2.2) upgrade all our installers together to WiX and live with the fact that the new set of installers cannot coexist (fully) with the VS2005 ones. Many thanks in advance, David - 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] Custom action to call a method in DLL
You're right.drvutil.dll is from APC SDK.Could you give me any sample or a link which demonstrate the implementation method you are talking about? Christopher Painter wrote: Is drvutil.dll your own DLL or are you using a third party dll? Googling the name seems to imply that it might be from an APC SDK and in that case it's very unlikely to follow Type 1 standard call declaration.You would have to create a wrapper CA that invoke the APC DLL and pass the result back to an MSI property. InstallShield has this built in as a generic `standard dll` story but WiX does not. If it is your CA then I assume you are already exporting your DLLfx per Type 1 specs. Brian Simoneau [EMAIL PROTECTED] wrote: The installer extracts the dll to the temporary location in order to call the custom action and then deletes the temp file. The actual error is in calling the custom action or in the custom action itself. -Brian Simoneau -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anidil Sent: Thursday, October 11, 2007 8:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Custom action to call a method in DLL I have a customaction as follows which invokes the IsUPSPresent function inside drvutil.dll. Id=caIsUPSPresent DllEntry=IsUPSPresent Return=check / As i see in the verbose MSI logs, installer seems to have accessed DLL: C:\Windows\Installer\MSI8342.tmp instead of the actual dll specified, and the MSI end up in install failure. Am i missing somethig here? I have searched for the file C:\Windows\Installer\MSI8342.tmp but could find anything as such. Here are the log snippet: MSI (s) (B4:84) [17:39:25:363]: Doing action: caIsUPSPresent Action start 17:39:25: caIsUPSPresent. MSI (s) (B4:60) [17:39:25:379]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI8342.tmp, Entrypoint: IsUPSPresent MSI (s) (B4:1C) [17:39:25:379]: Generating random cookie. MSI (s) (B4:1C) [17:39:25:394]: Created Custom Action Server with PID 2212 (0x8A4). MSI (s) (B4:48) [17:39:25:488]: Running as a service. MSI (s) (B4:EC) [17:39:25:737]: Hello, I'm your 32bit Impersonated custom action server. Action ended 17:39:25: caIsUPSPresent. Return value 3. Action ended 17:39:25: INSTALL. Return value 3. -- View this message in context: http://www.nabble.com/Custom-action-to-call-a-method-in-DLL-tf4606851.ht ml#a13154574 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 - Pinpoint customers who are looking for what you sell. - 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/Custom-action-to-call-a-method-in-DLL-tf4606851.html#a13212615 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] Files in xml not being installed
Anytime I have anything odd going on I always look to a verbose log file first. MSIEXEC /L*v name of log file /I name of msi file -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Blankley Sent: Monday, October 15, 2007 7:04 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Files in xml not being installed I have an existing msi and am building an updated msi and msp files. Sometimes, files that are new get found and correctly added to the xml, but don't seem to get installed when I run the resultant msi or msp files. Any clues as to where to look to troubleshoot? Thanks, Dave - 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] Handling Feature Dependencies
Hello, Let's say I have three features - fA, fB, fC. All of these features are at the same level - Level 1. But only fA and fB are shown to the user. fB is hidden from the user and should be installed if fA or fB is installed. If neither of those gets installed, fC should not be installed. Now what the seemingly obvious answer is, is to add a condition to fC on the order of: Feature Id=fA Level=1 /Feature Feature Id=fB Level=1 /Feature Feature Id=fC Level=0 Display=hidden Condition Level=1![CDATA[ (fA = 3) OR (fB = 3)]]/Condition /Feature But that does not seem to work. What am I missing? Is this not the proper way to evaluate a Feature condition that is based on the selection of other features. Can I not do the evaluation of the condition in fC in the FileCost action since the feature selection is there? Can I make fC a sub-feature of both fA and fB (That doesn't sound right.)? Do I have the condition statement correct? - 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, Nant and XMLPoke.
I had to use XMLPoke to inject a version number into a .wxs file. The following link helped in getting XMLPoke to work with .wxs files... http://solepano.blogspot.com/2006/11/problem-with-nants-xmlpoke-task.html However it seems that NANT also injects the byteorder marks into the file at the beginning when saving it, and visual studio commandline tool then errors out when building the wix project with the following errors... Error1Invalid token 'Text' at root level of document. C:\autobuild\pn\3.2\sourcecode\Source\NetKPI\NetKPI_Install\NetKPI_Install.wxs 11NetKPI_Install Error2Unexpected XML declaration. The XML declaration must be the first node in the document and no white space characters are allowed to appear before it. C:\autobuild\pn\3.2\sourcecode\Source\NetKPI\NetKPI_Install\NetKPI_Install.wxs 14NetKPI_Install The errors go away if I press backspace a few times in Visual studio at the root of the document... Any idea how to get either Nant to not input the byte order marks or Wix to ignore them? -- . Abdullah Ahmed . [EMAIL PROTECTED] - 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] Question regarding bootstrap installer
What is a bootstrap installer how can it be used to install Adobe Reader other softwares such as .NET 2.0 or .NET 3.0? Is there any example available where it shows how to add bootstrap installer to your installer install dependency softwares during your software install? Please help. Hina -- View this message in context: http://www.nabble.com/Question-regarding-bootstrap-installer-tf4628838.html#a13217007 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] Terminal Services support in MSI Installer
Surely that message is coming from the driver? Your setup is probably fine for a TS install, but that message seems to be saying that there is a completely different version of the driver required for TS. Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Veerendra Sent: Monday, October 15, 2007 12:08 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Terminal Services support in MSI Installer I developed a MSI Installer using WixV3 and MS2005. It is working fine for me. Now I have to provide Terminal Services support in my installer. When I tried to install on Win2003. I am getting error that Terminal Services version of driver is required. How I can make my installer to terminal services compatible. Regards, Veerendra -- View this message in context: http://www.nabble.com/Terminal-Services-support-in-MSI-Installer-tf46248 50.html#a13207746 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
Re: [WiX-users] Files in xml not being installed
Chad: Thanks for the suggestion. Unfortunately, the files that fail to be newly incorporated spit out the exact same info as files that were part of the original msi. What's also weird is that there seems to be no consistency to this. Other files are added fine (but not in that directory). dir names are unique. Other ideas? Thanks, Dave On Mon, 15 Oct 2007, Chad Petersen wrote: Anytime I have anything odd going on I always look to a verbose log file first. MSIEXEC /L*v name of log file /I name of msi file -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Blankley Sent: Monday, October 15, 2007 7:04 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Files in xml not being installed I have an existing msi and am building an updated msi and msp files. Sometimes, files that are new get found and correctly added to the xml, but don't seem to get installed when I run the resultant msi or msp files. Any clues as to where to look to troubleshoot? Thanks, Dave - 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] Files in xml not being installed
I've never seen a log file be inaccurate as to what happened. And I've never seen a log file give the same info for files that are installed versus not installed. Look for the logging of the Component. For the Components that do not get installed does it say Action: Null? See the example below of two identical files that are installed (Action: Local) or not installed (Action: Null) depending on a condition I have set. MSI (s) (88:EC) [09:04:46:359]: Component: ExceptionReport1099rox; Installed: Absent; Request: Local; Action: Null MSI (s) (88:EC) [09:04:46:359]: Component: ExceptionReport1098rox_26; Installed: Absent; Request: Local; Action: Local -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Blankley Sent: Monday, October 15, 2007 10:58 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Files in xml not being installed Chad: Thanks for the suggestion. Unfortunately, the files that fail to be newly incorporated spit out the exact same info as files that were part of the original msi. What's also weird is that there seems to be no consistency to this. Other files are added fine (but not in that directory). dir names are unique. Other ideas? Thanks, Dave On Mon, 15 Oct 2007, Chad Petersen wrote: Anytime I have anything odd going on I always look to a verbose log file first. MSIEXEC /L*v name of log file /I name of msi file -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Blankley Sent: Monday, October 15, 2007 7:04 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Files in xml not being installed I have an existing msi and am building an updated msi and msp files. Sometimes, files that are new get found and correctly added to the xml, but don't seem to get installed when I run the resultant msi or msp files. Any clues as to where to look to troubleshoot? Thanks, Dave - 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 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] Handling Feature Dependencies
Robert, I encountered this same issue when porting our installer from InstallShield to WiX. InstallShield has the ability to make dependencies between features - I decompiled the MSI and discovered that it does it with a custom action and a custom table of dependencies called ISRequiredFeature. It is not too hard to write a similar custom action that reads records from a custom table and enables the subordinate features as required. I run my custom action just before InstallValidate. However, in hindsight, I think just using a ComponentGroupRef instead of feature fC and including it in both fA and fB might be simpler and more robust. Not sure what the relative downsides are. Regards, John _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 15 October 2007 17:06 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Handling Feature Dependencies Hello, Let's say I have three features - fA, fB, fC. All of these features are at the same level - Level 1. But only fA and fB are shown to the user. fB is hidden from the user and should be installed if fA or fB is installed. If neither of those gets installed, fC should not be installed. Now what the seemingly obvious answer is, is to add a condition to fC on the order of: Feature Id=fA Level=1 /Feature Feature Id=fB Level=1 /Feature Feature Id=fC Level=0 Display=hidden Condition Level=1![CDATA[ (fA = 3) OR (fB = 3)]]/Condition /Feature But that does not seem to work. What am I missing? Is this not the proper way to evaluate a Feature condition that is based on the selection of other features. Can I not do the evaluation of the condition in fC in the FileCost action since the feature selection is there? Can I make fC a sub-feature of both fA and fB (That doesn't sound right.)? Do I have the condition statement correct? - 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] Files in xml not being installed
Below is the output from 2 files. It looks a little different than yours. The first is successfully installed when I run the msi/msp. The 2nd is not found on the installed media. Is there a way I can look inside the cab inside the msi to confirm that the missing file is indeed in the msi? Thanks. Dave MSI (s) (80:CC) [11:50:11:031]: Executing op: FileCopy(SourceName=MARKET_4.WMI|MarketDepthBkgrd.wmif,SourceCabKey=file2279,DestName=MarketDepthBkgrd.wmif,Attributes=0,FileSize=800039,PerTick=32768,,VerifyMedia=1,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=-89917452,HashPart2=1694465066,HashPart3=1569586833,HashPart4=299802530,,) MSI (s) (80:CC) [11:50:11:031]: File: I:\builder\WarlordOld\Warlord0.66\Pfiles\Warlord\Trade Images\MarketDepthBkgrd.wmif; Won't Overwrite;Won't patch; Existing file is unversioned and unmodified - hash matches source file MSI (s) (80:CC) [11:50:11:046]: Executing op: FileCopy(SourceName=CONFIR_1.WMI|confirm_input.wmif,SourceCabKey=file2683,DestName=confirm_input.wmif,Attributes=0,FileSize=14079,PerTick=32768,,VerifyMedia=1,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=1644515610,HashPart2=1582559771,HashPart3=-1450576442,HashPart4=2032300175,,) MSI (s) (80:CC) [11:50:11:046]: File: I:\builder\WarlordOld\Warlord0.66\Pfiles\Warlord\Trade Images\confirm_input.wmif; Won't Overwrite;Won't patch; Existing file is unversioned and unmodified - hash matches source file On Mon, 15 Oct 2007, Chad Petersen wrote: I've never seen a log file be inaccurate as to what happened. And I've never seen a log file give the same info for files that are installed versus not installed. Look for the logging of the Component. For the Components that do not get installed does it say Action: Null? See the example below of two identical files that are installed (Action: Local) or not installed (Action: Null) depending on a condition I have set. MSI (s) (88:EC) [09:04:46:359]: Component: ExceptionReport1099rox; Installed: Absent; Request: Local; Action: Null MSI (s) (88:EC) [09:04:46:359]: Component: ExceptionReport1098rox_26; Installed: Absent; Request: Local; Action: Local -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Blankley Sent: Monday, October 15, 2007 10:58 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Files in xml not being installed Chad: Thanks for the suggestion. Unfortunately, the files that fail to be newly incorporated spit out the exact same info as files that were part of the original msi. What's also weird is that there seems to be no consistency to this. Other files are added fine (but not in that directory). dir names are unique. Other ideas? Thanks, Dave On Mon, 15 Oct 2007, Chad Petersen wrote: Anytime I have anything odd going on I always look to a verbose log file first. MSIEXEC /L*v name of log file /I name of msi file -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Blankley Sent: Monday, October 15, 2007 7:04 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Files in xml not being installed I have an existing msi and am building an updated msi and msp files. Sometimes, files that are new get found and correctly added to the xml, but don't seem to get installed when I run the resultant msi or msp files. Any clues as to where to look to troubleshoot? Thanks, Dave - 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 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] Files in xml not being installed
The Windows SDK has a utility called 'Orca' that can show you the raw tables in an MSI. I use it constantly to check Files tables when our developers claim something is missing from my installers. You can probably find Orca in other places, but that's one place I know it resides. It might already be on your system. -Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Blankley Sent: Monday, October 15, 2007 11:25 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Files in xml not being installed Below is the output from 2 files. It looks a little different than yours. The first is successfully installed when I run the msi/msp. The 2nd is not found on the installed media. Is there a way I can look inside the cab inside the msi to confirm that the missing file is indeed in the msi? Thanks. Dave MSI (s) (80:CC) [11:50:11:031]: Executing op: FileCopy(SourceName=MARKET_4.WMI|MarketDepthBkgrd.wmif,SourceCabKey=file 2279,DestName=MarketDepthBkgrd.wmif,Attributes=0,FileSize=800039,PerTick =32768,,VerifyMedia=1,CheckCRC=0,,,InstallMode=58982400,HashOptions= 0,HashPart1=-89917452,HashPart2=1694465066,HashPart3=1569586833,HashPart 4=299802530,,) MSI (s) (80:CC) [11:50:11:031]: File: I:\builder\WarlordOld\Warlord0.66\Pfiles\Warlord\Trade Images\MarketDepthBkgrd.wmif; Won't Overwrite;Won't patch; Existing file is unversioned and unmodified - hash matches source file MSI (s) (80:CC) [11:50:11:046]: Executing op: FileCopy(SourceName=CONFIR_1.WMI|confirm_input.wmif,SourceCabKey=file268 3,DestName=confirm_input.wmif,Attributes=0,FileSize=14079,PerTick=32768, ,VerifyMedia=1,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashP art1=1644515610,HashPart2=1582559771,HashPart3=-1450576442,HashPart4=203 2300175,,) MSI (s) (80:CC) [11:50:11:046]: File: I:\builder\WarlordOld\Warlord0.66\Pfiles\Warlord\Trade Images\confirm_input.wmif; Won't Overwrite;Won't patch; Existing file is unversioned and unmodified - hash matches source file On Mon, 15 Oct 2007, Chad Petersen wrote: I've never seen a log file be inaccurate as to what happened. And I've never seen a log file give the same info for files that are installed versus not installed. Look for the logging of the Component. For the Components that do not get installed does it say Action: Null? See the example below of two identical files that are installed (Action: Local) or not installed (Action: Null) depending on a condition I have set. MSI (s) (88:EC) [09:04:46:359]: Component: ExceptionReport1099rox; Installed: Absent; Request: Local; Action: Null MSI (s) (88:EC) [09:04:46:359]: Component: ExceptionReport1098rox_26; Installed: Absent; Request: Local; Action: Local -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Blankley Sent: Monday, October 15, 2007 10:58 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Files in xml not being installed Chad: Thanks for the suggestion. Unfortunately, the files that fail to be newly incorporated spit out the exact same info as files that were part of the original msi. What's also weird is that there seems to be no consistency to this. Other files are added fine (but not in that directory). dir names are unique. Other ideas? Thanks, Dave On Mon, 15 Oct 2007, Chad Petersen wrote: Anytime I have anything odd going on I always look to a verbose log file first. MSIEXEC /L*v name of log file /I name of msi file -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Blankley Sent: Monday, October 15, 2007 7:04 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Files in xml not being installed I have an existing msi and am building an updated msi and msp files. Sometimes, files that are new get found and correctly added to the xml, but don't seem to get installed when I run the resultant msi or msp files. Any clues as to where to look to troubleshoot? Thanks, Dave - 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
[WiX-users] How to keep guids in similar setups
Hello List, I'm trying to build multiple similar setups (Pro, Standard, Base) of our product from a single WiX sources. And I'm trying to keep guids whenever possible. Bob Arnson wrote earlier in this list that guids are product-global and it's ok to keep the same guids, but when products are installed into different directories. Currently my investigations show most components are really product-global while some component types do not. Non-advertised shortcuts and CU registry keys are not uninstalled when another product that has the same components with the same guids is installed in different directory. E.g. we have two products, Pro and Base, both have My.exe with non-advertised shortcut pointing on it. Both exe files have the same guid and both shortcuts have the same (but different) guid. Program Files\My Product Pro\My.exe StartMenu\Programs\My Product Pro\My Product Shortcut.lnk HKCU\My Product Pro\ShortcutKeyPath Program Files\My Product Base\My.exe StartMenu\Programs\My Product Base\My Product Shortcut.lnk HKCU\My Product Base\ShortcutKeyPath 1. Install Pro into Program Files\My Product Pro 2. Install Base into Program Files\My Product Base 3. Uninstall Base (StartMenu\Programs\My Product Base\My Product Shortcut.lnk remains and it has Action: Null in the log) 4. Uninstall Pro (Pro\Shortcut to My.exe uninstalled) I use MSI 3.01 Could someone comment on this? Best regards, Ilya Slobodin - 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] How to keep guids in similar setups
If two components have the same GUID, they must be the same including the directory. -Original Message- From: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] On Behalf Of Ilya Slobodin Sent: Monday, October 15, 2007 2:29 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to keep guids in similar setups Hello List, I'm trying to build multiple similar setups (Pro, Standard, Base) of our product from a single WiX sources. And I'm trying to keep guids whenever possible. Bob Arnson wrote earlier in this list that guids are product-global and it's ok to keep the same guids, but when products are installed into different directories. Currently my investigations show most components are really product-global while some component types do not. Non-advertised shortcuts and CU registry keys are not uninstalled when another product that has the same components with the same guids is installed in different directory. E.g. we have two products, Pro and Base, both have My.exe with non-advertised shortcut pointing on it. Both exe files have the same guid and both shortcuts have the same (but different) guid. Program Files\My Product Pro\My.exe StartMenu\Programs\My Product Pro\My Product Shortcut.lnk HKCU\My Product Pro\ShortcutKeyPath Program Files\My Product Base\My.exe StartMenu\Programs\My Product Base\My Product Shortcut.lnk HKCU\My Product Base\ShortcutKeyPath 1. Install Pro into Program Files\My Product Pro 2. Install Base into Program Files\My Product Base 3. Uninstall Base (StartMenu\Programs\My Product Base\My Product Shortcut.lnk remains and it has Action: Null in the log) 4. Uninstall Pro (Pro\Shortcut to My.exe uninstalled) I use MSI 3.01 Could someone comment on this? Best regards, Ilya Slobodin --- -- 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] Nigel Rochford is out of the office.
I will be out of the office starting 15/10/2007 and will not return until 17/10/2007. I will respond to your message when I return - 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] Files in xml not being installed
WiX deliberately does not have any mechanism for automatically collecting files because it's way too easy to break component rules. My initial guess would be that you've added them to an existing component (which it is strongly recommend you avoid) but the key file of that component isn't changed, so Windows Installer thinks the component is already installed and skips it. The log you posted in another answer appears to indicate that Windows Installer thinks that the key file does not have a version number and that the file is unchanged since installation, since created and modified timestamps are the same, and it's not a new version of the file because the file data hashes to the same value as is declared in the MSI file. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Blankley Sent: 15 October 2007 15:04 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Files in xml not being installed I have an existing msi and am building an updated msi and msp files. Sometimes, files that are new get found and correctly added to the xml, but don't seem to get installed when I run the resultant msi or msp files. Any clues as to where to look to troubleshoot? Thanks, Dave - 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] How to keep guids in similar setups
Not necessarily true. It is OK to install the same component to different paths; it is definitely wrong to install two different components to the same path as then the references get cross-linked. Windows Installer tracks where every installed product installed every component that it installed. When removing a component, it checks to see whether any other product is still referencing that component at the same install path - if not, it removes it. If there is another component not installed by that product which installed the same file, the other product will then be broken. When installing and removing components, the definition from the package you are installing or maintaining is used. That's why you have to be very careful with adding and removing files in components. If you produce a (shared) component with files A, B, C and D and ship product P1, then add a new file E and ship product P2, if the user installs P1 then P2 and removes P2 then P1, file E will be left behind because it wasn't in P1's definition of the component. If you change the component GUID you _must_ move the resources. This no doubt includes ensuring that a user doesn't install a later version to the same folder as an old one. Astute readers will realise that if you're performing only major upgrades and you remove the old product before installing the new (i.e. schedule RemoveExistingProducts between InstallValidate and InstallInitialize), you can break a lot of component rules for private components that aren't shared with any other products, because the old components are wiped out before the new ones are installed. I'm not saying you should, I'm saying you're unlikely to suffer the consequences. Do anything more complicated, with shared components, minor upgrades, patches, or scheduling RemoveExistingProducts anywhere else, and you quickly run into difficulty. It's best to do it right to begin with so it doesn't affect -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Vottero Sent: 15 October 2007 19:41 To: Ilya Slobodin; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to keep guids in similar setups If two components have the same GUID, they must be the same including the directory. -Original Message- From: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] On Behalf Of Ilya Slobodin Sent: Monday, October 15, 2007 2:29 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to keep guids in similar setups Hello List, I'm trying to build multiple similar setups (Pro, Standard, Base) of our product from a single WiX sources. And I'm trying to keep guids whenever possible. Bob Arnson wrote earlier in this list that guids are product-global and it's ok to keep the same guids, but when products are installed into different directories. Currently my investigations show most components are really product-global while some component types do not. Non-advertised shortcuts and CU registry keys are not uninstalled when another product that has the same components with the same guids is installed in different directory. E.g. we have two products, Pro and Base, both have My.exe with non-advertised shortcut pointing on it. Both exe files have the same guid and both shortcuts have the same (but different) guid. Program Files\My Product Pro\My.exe StartMenu\Programs\My Product Pro\My Product Shortcut.lnk HKCU\My Product Pro\ShortcutKeyPath Program Files\My Product Base\My.exe StartMenu\Programs\My Product Base\My Product Shortcut.lnk HKCU\My Product Base\ShortcutKeyPath 1. Install Pro into Program Files\My Product Pro 2. Install Base into Program Files\My Product Base 3. Uninstall Base (StartMenu\Programs\My Product Base\My Product Shortcut.lnk remains and it has Action: Null in the log) 4. Uninstall Pro (Pro\Shortcut to My.exe uninstalled) I use MSI 3.01 Could someone comment on this? Best regards, Ilya Slobodin --- -- 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] Type libraries and component rules
Installing the same component to two different folders does not break component rules - this is allowed. Indeed, if installed to the same location, the behaviour may be surprising - installing product A with component version 1 then product B with component version 2, then uninstalling B will leave component version 2 installed. However, if you do install to different locations, I don't think Windows Installer can fixup the COM registration when uninstalling the newer version, even if you use the Class, TypeLib etc tables rather than raw registry entries (or @Advertise='no'). If you had versions 1 2 and 3 installed in different locations, then uninstalled 3, Windows Installer would see that this component was no longer referenced at this location and remove the component, therefore removing the registration. If you don't make the registration part of the component containing the file, instead making it a different component, it doesn't help because the registration information points to the wrong place (the file that's just been removed). Hypothetically I suppose Windows Installer could compare the version numbers of the key files of the other components (if the Class table were used) and re-register the most recent one. But I don't know if it does, and advertising classes (using the Class table) gives other surprising problems (e.g. asking for B's installer when you launch product A). I think my prescriptive guidance for COM objects would have to be: use registration-free COM whenever possible; when not possible, pick a shared location (e.g. a company folder under Program Files\Common Files) and always install the component there. Or do a private build (different GUIDs, ProgId, etc) for each product that uses it. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vilhelm Sjoberg Sent: 09 October 2007 11:59 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Type libraries and component rules Hello wix-users, this is a follow up to my emails from a few days ago about problems with COM registration. I think the problem is that I am violating component rules, but I'm not sure how to avoid it. My program ships with a com server dll file which will need to be upgraded from time to time. The plan was to keep the different version of the file as completely seperate components, installed into different directories. However, since the typelibrary GUID of the different versions is the same, when they are registered some of the registry keys written will be the same. So now I have different components writing the same key, and this seems to break reference counting (so when upgrading the keys get clobbered during the uninstall phase). On the other hand, I don't think I can put the different versions of the dll in the same component, since it will be installed to a different directory, again breaking component rules. Does anyone have any idea what to do here? Thanks in advance, Vilhelm -- View this message in context: http://www.nabble.com/Type-libraries-and-component-rules-tf4593489.html#a131 13374 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
Re: [WiX-users] Handling Feature Dependencies
John Hall wrote: However, in hindsight, I think just using a ComponentGroupRef instead of feature fC and including it in both fA and fB might be simpler and more robust. Not sure what the relative downsides are. If the feature was used just for grouping (i.e., it's never visible or user installable) then a component group is the best approach. Components can belong to multiple features just fine -- that's an MSI thing. -- 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] Registry and Permission
To whom should the bug be assigned to ? From: Bob Arnson [EMAIL PROTECTED] Sent: Monday, October 15, 2007 10:15 PM To: Harini Gurusamy Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Registry and Permission Harini Gurusamy wrote: Registry Id=”Reg” Root=”HKLM” Key=”Foo” Action=”write” Permission Extended =”yes” Read=”yes” User=”Everyone” / /Registry This works on 32 bit . But when Installing the msi on 64 bit , it throws an error ExecSecureObjects: Error 0x80070002: failed to get security info for object: When you use Permission/@Extended=yes, WiX runs a custom action; it's a 32-bit CA that doesn't know anything about the 64-bit portion of the registry so it can't write the ACLs. Please open a bug -- the CA should disable redirection for 64-bit components. -- 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
