Re: [WiX-users] Installer runs OK via msiexec but fails when double-clicked
Hello, I know you said the installer prompts for elevated but do you have this? InstallPrivileges="elevated" InstallScope="perMachine"/> In the package ID section in your product.wxs file. On Mon, Apr 28, 2014 at 5:46 PM, wrote: > Dit mailadres is niet meer in gebruik. Mail kan je voortaan sturen naar > basti...@careercontrol.nl. > > > > > -- > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- "They may forget what you said but they will never forget how you made them feel." -- Anonymous -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installer runs OK via msiexec but fails when double-clicked
Dit mailadres is niet meer in gebruik. Mail kan je voortaan sturen naar basti...@careercontrol.nl. -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installer runs OK via msiexec but fails when double-clicked
Phil, Many thanks for the comments. To answer your questions ... So far as I recall, there were no other errors recorded in the log file - I'll check again in the morning. So far as I know, the error dialog is standard WiX 3.8. I haven't consciously imported anything from Visual Studio. I created the WiX project within Visual Studio 2010 using the WiX-supplied template and essentially wrote the was from scratch. I hear what you're saying regarding InstalUtilLib.dll! I have got the "InstallUtil is evil and harmful" message loud and clear. However, I'm trying to install a (.NET) WMI provider and, for that, InstallUtil (in the form of InstallUtilLib.dll) appears to be the only game in town. If anyone can point me to a working example of a viable alternative I'll be only too happy to use it. I've done a reasonable amount of searching and I've tried things like invoking the .NET installer class with no success. (Interestingly, that also "appeared" to work (ie the installer completed without error - it just didn't install the WMI class properly) when run via msi exec from an elevated shell but threw an exception (from the deferred CA) when run by double-clicking the msi - more or less similar symptoms!) InstallUtilLib.dll currently feels like the "Last Chance Saloon". As regards VS MSIs - there haven't been any involved. The install DOES explicitly ask for elevation after the UI sequence. Having said all the above, one thing does occur to me. I have a VC++ project (complete with VS-supplied merge module for the VC++ redistributable) in the same installer. Could that be supplying the error dialog? I'll try removing that and see what happens. Thanks again for the response. I'm very new to WiX (and MSIs) so still trying to get this clear in my head. Regards David On 28 Apr 2014, at 18:34, "Phil Wilson" wrote: > I'd back up from the error 2869 and see what's before that. That > error is when it's decides to show you an error but doesn't like the > error dialog, and the actual error is prior to that. Where did you get > that error dialog from? That's a common error in Visual Studio setup > projects, so did you import their dialogs into a WiX setup? > > InstallUtilLib.dll is also a Visual Studio setup project thing. I'd > avoid it because it's unsupported since VS dropped setup projects, may > have the wrong bitness depending on your install, and I don't know if > you're even supposed to redistribute it like that. There's got to be a > way to accomplish the task without it. > > If you just ported the setup from a Visual Studio MSI then I don't > know if you'll get proper UAC handling, depending on the version of > VS. If the install is set up right the install should explicitly ask > for elevation after the UI sequence, because the install needs it. > That might be the issue, but look for the error just before the 2869. > --- > Phil Wilson > > > On Mon, Apr 28, 2014 at 9:58 AM, David Allen wrote: >> I have an installer that invokes InstallUtilLib.dll via a set of CAs as >> documented in >> http://blogs.msdn.com/b/josealmeida/archive/2004/11/08/253831.aspx & >> http://avinashkt.blogspot.co.uk/2007/05/how-to-create-installer-using-wix-which.html >> If I simply double-click on the MSI or run it using msiexec (NOT as an >> administrator) then it fails with Error 2869! >> The relevant files from the logfile (msiexec /Log ...) are >> Action 17:17:50: Install. >> DEBUG: Error 2869: The dialog ErrorDlg has the error style bit set, but is >> not an error dialog >> The installer has encountered an unexpected error installing this package. >> This may indicate a problem with this package. The error code is 2869. The >> arguments are: ErrorDlg, , >> MSI (c) (44:C0) [17:17:52:800]: Product: OpenPKI Tools -- The installer has >> encountered an unexpected error installing this package. This may indicate a >> problem with this package. The error code is 2869. The arguments are: >> ErrorDlg, , >> >> Error 1001. >> MSI (s) (04!EC) [17:17:52:800]: >> DEBUG: Error 2769: Custom Action Install did not close 1 MSIHANDLEs. >> The installer has encountered an unexpected error installing this package. >> This may indicate a problem with this package. The error code is 2769. The >> arguments are: Install, 1, >> CustomAction Install returned actual error code 1603 (note this may not be >> 100% accurate if translation happened inside sandbox) >> Action ended 17:17:52: InstallFinalize. Return value 3. >> Action 17:17:52: Rollback. Rolling back action: >> >> If I run the installer via msiexec AS AN ADMINISTRATOR it works fine! >> >> For reference - the set of CAs, including the custom action "Install" to >> which the Error 2769 refers is as follows: - >> >> > After="StartServices">$WmiProvider>2 >> > After="InstallSetProp">$WmiProvider>2 >> >> > After="MsiUnpublishAssemblies">$WmiProvider=2 >> > After="UninstallSetProp">$WmiProvider=2 >> >> > After="
Re: [WiX-users] [SPAM] Re: How implement installer to update single file ? Upgrade? Patch?
Are there others experienced in patching/updating that can share an example or offer advice? I followed the " Using Patch Creation Properties" tutorial which installs an updated sample.txt file. This worked well. http://wixtoolset.org/documentation/manual/v3/patching/patch_building.html Next I copied the working tutorial and started to modify it to do same for updating a DLL instead of the sample.txt file. I have the original 3.8.1 version of the MSI which installs an executable and a DLL. It is only the DLL that I need to replace and not the executable. I suspect my problem may not be setting up matches of the original ids, guids, or references that Orca displays in the original 3.8.1 MSI. 1 - I created a new /3.8.1/product.msi containing the original DLL extracted from the original 3.8.1 version on the MSI. In the product.wxs file I set ProductId and UpgradeCode to match original MSI. 2 - I created a second /3.8.2/product.msi containing the updated DLL. The executable (*.exe) was not changed, only the DLL, so exe was not included. 3 - The patch.msp was created from the patch.wxs from the /3.8.1/product.msi and /3.8.2/product.msi files. My patch has no GUI. When I set my product.wxs ProductId and UpgradeCode to match the original 3.8.1 MSI it launching the patch results in launching of the original installer GUI in repair/remove mode. I tried to do a repair. I confirmed this did *not* update the DLL. I think this is expected when launching original installer. If the patch install would have worked, I expected to see UAC request elevation as it does with the tutorial that installs the pdated sample.txt file. msiexec.exe /p patch\patch.msp /l*vx patch.log Phil it sounds like you are picking this up pretty quickly - I am impressed. I have always struggled with MSI and find it complex. I usually use deployment tools included with Visual Studio, crippled InstallShield versions, Wise Installer, etc. I am trying to take better notes this time as I always have to relearn what I figured out years past. It would like to figure out WiX and start using it with all new projects I have coming up. It sounds like WiX has been around since 2007 and is not likely to disappear. I know I am missing something. Probably multiple things. Any suggestions or patch examples are welcome. -Ed -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: Monday, April 28, 2014 1:45 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] [SPAM] Re: How implement installer to update single file ? Upgrade? Patch? While I have not used that process, my understanding is that you are creating a 'small update' patch for the original version of the two MSI files (used in that process). (The updated version of the two MSI files is not distributed. Only the original MSI and the patch which targets only that original MSI.) So in the case where the original MSI is installed and you apply the patch it sounds like it worked. In the case were you tried to apply the patch using a different ProductCode it makes sense that the error message indicated that it could not find the ProductCode indicated on the installed system, as the original MSI did not use that code. I do not have much experience in this area as I am just working through some of these issues myself. So there may be others who can provide better guidance. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-implement-installer-to-update-single-file-Upgrade-Patch-tp7594344p7594388.html Sent from the wix-users mailing list archive at Nabble.com. -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any
[WiX-users] [SPAM] Re: How implement installer to update single file ? Upgrade? Patch?
While I have not used that process, my understanding is that you are creating a 'small update' patch for the original version of the two MSI files (used in that process). (The updated version of the two MSI files is not distributed. Only the original MSI and the patch which targets only that original MSI.) So in the case where the original MSI is installed and you apply the patch it sounds like it worked. In the case were you tried to apply the patch using a different ProductCode it makes sense that the error message indicated that it could not find the ProductCode indicated on the installed system, as the original MSI did not use that code. I do not have much experience in this area as I am just working through some of these issues myself. So there may be others who can provide better guidance. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-implement-installer-to-update-single-file-Upgrade-Patch-tp7594344p7594388.html Sent from the wix-users mailing list archive at Nabble.com. -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How implement installer to update single file ? Upgrade? Patch?
Thank you Phil.
I am trying the "Using Patch Creation Properties" approach. I made two
subfolders, 3.8.1 contained only the original DLL I wished to replace, and
3.8.2 the updated DLL.
http://wixtoolset.org/documentation/manual/v3/patching/patch_building.html
Should both UpgradeCode and Product ID match the original 3.81 version seen in
Orca?
When both match the original 3.8.1 MSI the patch launches the 3.8.1
repair/remove installer.
msiexec.exe /p patch\patch.msp /l*vx patch.log
When only UpgradeCode matches the Windows Installer displays a dialog with
message:
"The upgrade patch cannot be installed" because "program to be upgraded may be
missing".
===Orca Properties Displayed With Original 3.8.1 MSI===
Table: Property
Manufacturer The Charles Machine Works, Inc.
ProductCode{C80FB86A-42A1-4FB8-B9B2-30DCFF138E3D}
ProductNameTMS Plus
ProductVersion 3.8.1
UpgradeCode{59BF7F9E-FF46-45D5-8050-F1477466A661}
Table: File
_ACE1F72023AD44F5829BCA1329E212FD C__ACE1F72023AD44F5829BCA1329E212FD
REGTMS.DLL|Regtms.dll 40960 1.0.0.2 1033514 80
Table: Component
C__ACE1F72023AD44F5829BCA1329E212FD{CFB9D5A8-65CC-E091-DC21-4F4653B149D6}
TARGETDIR 0 _ACE1F72023AD44F5829BCA1329E212FD
Table: FeatureComponents
DefaultFeature C__ACE1F72023AD44F5829BCA1329E212FD
Table: Feature
DefaultFeature 2 1 TARGETDIR 0
Table: Directory
TARGETDIR SourceDir
Table: CreateFolder
TARGETDIR C__A0F5E19C01BE425EB5FD3CE9A5BBB86D
Table: CustomAction
DIRCA_TARGETDIR307 TARGETDIR [ProgramFilesFolder]TMSPlus
*
* File: product.wxs
*
http://schemas.microsoft.com/wix/2006/wi";>
*
* File: Patch.wxs
*
http://schemas.microsoft.com/wix/2006/wi";>
http://www.ditchwitch.com/";
Classification="Update"
DisplayName="TMS Plus Patch Sample"/>
Any direction is much appreciated,
-Ed
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday, April 25, 2014 11:30 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How implement installer to update single file ?
Upgrade? Patch?
If you have the old MSI, there are a couple of options (but I am no expert).
If the old mis supports doing a /a layout then you can extract the files of the
old msi to two folder tress, original and changed, change the files in the
'changed' folder tree, and use torch to create a transform.
Or you can use orca in the old msi to find out which component the files is
associated. Then create a new msi with only all of the files (resources) of
that component, using the same component GUID, and run that msi to update the
file. But the component must be identical to the component in the original
package with regard to the guid, target path, and all resources included in
that component.
I am just learning and experimenting with a similar situation, so others can
provide more expert advice.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-implement-installer-to-update-single-file-Upgrade-Patch-tp7594344p7594346.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Start Your Social Network Today - Download eXo Platform Build your Enterprise
Intranet with eXo Platform Software Java Based Open Source Intranet - Social,
Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A
Collaboration Platform http://p.sf.net/sfu/ExoPlatform
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
This email and any files transmitted with it from The Charles Machine Works,
Inc. are confidential and intended solely for the use of the individual or
entity to which they are addressed. If you have received this email in error
please notify the sender. Our company accepts no liability for the contents of
this email, or for the consequences of any actions taken on the basis of the
information provided, unless that information is subsequently confirmed in
writing. Please note that any views or opinions presented in this email are
solely those of the author and do not necessarily represent those of the
company. Finally, the recipient should check this email and any attachments
for the presence of viruses. The company accepts no liability for any damage
caused by any virus transmitted by this email.
---
Re: [WiX-users] Installer runs OK via msiexec but fails when double-clicked
I'd back up from the error 2869 and see what's before that. That error is when it's decides to show you an error but doesn't like the error dialog, and the actual error is prior to that. Where did you get that error dialog from? That's a common error in Visual Studio setup projects, so did you import their dialogs into a WiX setup? InstallUtilLib.dll is also a Visual Studio setup project thing. I'd avoid it because it's unsupported since VS dropped setup projects, may have the wrong bitness depending on your install, and I don't know if you're even supposed to redistribute it like that. There's got to be a way to accomplish the task without it. If you just ported the setup from a Visual Studio MSI then I don't know if you'll get proper UAC handling, depending on the version of VS. If the install is set up right the install should explicitly ask for elevation after the UI sequence, because the install needs it. That might be the issue, but look for the error just before the 2869. --- Phil Wilson On Mon, Apr 28, 2014 at 9:58 AM, David Allen wrote: > I have an installer that invokes InstallUtilLib.dll via a set of CAs as > documented in > http://blogs.msdn.com/b/josealmeida/archive/2004/11/08/253831.aspx & > http://avinashkt.blogspot.co.uk/2007/05/how-to-create-installer-using-wix-which.html > If I simply double-click on the MSI or run it using msiexec (NOT as an > administrator) then it fails with Error 2869! > The relevant files from the logfile (msiexec /Log ...) are > Action 17:17:50: Install. > DEBUG: Error 2869: The dialog ErrorDlg has the error style bit set, but is > not an error dialog > The installer has encountered an unexpected error installing this package. > This may indicate a problem with this package. The error code is 2869. The > arguments are: ErrorDlg, , > MSI (c) (44:C0) [17:17:52:800]: Product: OpenPKI Tools -- The installer has > encountered an unexpected error installing this package. This may indicate a > problem with this package. The error code is 2869. The arguments are: > ErrorDlg, , > > Error 1001. > MSI (s) (04!EC) [17:17:52:800]: > DEBUG: Error 2769: Custom Action Install did not close 1 MSIHANDLEs. > The installer has encountered an unexpected error installing this package. > This may indicate a problem with this package. The error code is 2769. The > arguments are: Install, 1, > CustomAction Install returned actual error code 1603 (note this may not be > 100% accurate if translation happened inside sandbox) > Action ended 17:17:52: InstallFinalize. Return value 3. > Action 17:17:52: Rollback. Rolling back action: > > If I run the installer via msiexec AS AN ADMINISTRATOR it works fine! > > For reference - the set of CAs, including the custom action "Install" to > which the Error 2769 refers is as follows: - > >After="StartServices">$WmiProvider>2 >After="InstallSetProp">$WmiProvider>2 > >After="MsiUnpublishAssemblies">$WmiProvider=2 >After="UninstallSetProp">$WmiProvider=2 > >After="Rollback">$WmiProvider>2 > $WmiProvider>2 > >After="Install">$WmiProvider>2 >After="RollbackSetProp">$WmiProvider>2 > > > DllEntry="ManagedInstall" Execute="deferred" /> > > > DllEntry="ManagedInstall" Execute="deferred" /> > > > DllEntry="ManagedInstall" Execute="rollback" /> > > > DllEntry="ManagedInstall" Execute="commit" /> > > > > Am I missing something that should be obvious? It feels as if the CAs are not > being run with admin rights (even though I am prompted). > > All suggestions gratefully received. Apologies in advance if this is a FAQ > with a well known answer that I've missed! > > Regards > David > > > > -- > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Immediate Custom Action could not be run in some computers.
By default immediate custom actions run with limited user rights (even if the user is admin) because the UI sequence isn't elevated by default. So it might be a security issue on UAC systems. --- Phil Wilson On Mon, Apr 28, 2014 at 1:50 AM, Uni Gauldoth wrote: > Thanks for replying. > > I'm sure that there is no dependency problems. > If I run the msi installer with elevated privilege on that user's computer, > the install will finish successfully. > It turns out Windows Installer failed to extract the custom action dll to > temp directory during the InstallUISequence. > When the error message box is shown, there is no MSI209E.tmp under the temp > directory. > But I tried using GetTempFileName on that user's computer, it succeeded and > a temp file is created. > > > > On Tue, Apr 22, 2014 at 12:50 AM, Phil Wilson wrote: > >> This is useful for showing C++ dependencies: >> >> http://www.dependencywalker.com/ >> --- >> Phil Wilson >> >> >> On Mon, Apr 21, 2014 at 9:07 AM, Carter Young >> wrote: >> > Following Phil's Hunch, see here: >> > >> > >> http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html >> > >> > Carter >> > >> > Quoting Phil Wilson : >> > >> >> 1157 is a missing dependency, so I'd assume that there's a dependency >> >> not installed on all computers. If it's a C++ Dll it'll most likely be >> >> a missing C run time. >> >> --- >> >> Phil Wilson >> >> >> >> >> >> On Sun, Apr 20, 2014 at 5:55 AM, uni wrote: >> >>> Hi all, >> >>> >> >>> I have sequenced a custom action in my msi after CostFinalize. >> >>> On most user's computers, it works well. >> >>> >> >>> But on some user's computers, when the msi is double clicked directly >> >>> for installing, it will prompt "A DLL required for this install to >> >>> complete could not be run." >> >>> I've changed CheckIfAnotherProductExists function to only call >> >>> MessageBox(0,0,0,0), and it still prompted the error and the message >> box >> >>> is not showed. >> >>> If I remove the CheckIfAnotherProductExists entry in the >> >>> InstallExecuteSequence table, all goes well. >> >>> If I run the msi in cmd(run as administrator), it works fine, there >> >>> should be not dependency problem with my custom action dll. >> >>> >> >>> It acts as if it has something to do with the privilege. >> >>> May be it failed when the custom action's dll is being copied into the >> >>> temp directory, or maybe LoadLibrary failed under non elevated >> privilege? >> >>> >> >>> Does any one has experienced something like this? >> >>> >> >>> The WiX code is as below, >> >>> >> === >> >>> > >>> BinaryKey="MyDll" DllEntry="CheckIfAnotherProductExists" /> >> >>> > > >> >>> >> === >> >>> >> >>> The log is as below, >> >>> >> === >> >>> Action 14:20:31: CheckIfAnotherProductExists. >> >>> Action start 14:20:31: CheckIfAnotherProductExists. >> >>> MSI (c) (C4:B4) [14:20:31:680]: Invoking remote custom action. DLL: >> >>> C:\Users\administrator\AppData\Local\Temp\MSI209E.tmp, Entrypoint: >> >>> CheckIfAnotherProductExists >> >>> MSI (c) (C4:88) [14:20:31:680]: Cloaking enabled. >> >>> MSI (c) (C4:88) [14:20:31:680]: Attempting to enable all disabled >> >>> privileges before calling Install on Server >> >>> MSI (c) (C4:88) [14:20:31:680]: Connected to service for CA interface. >> >>> CustomAction CheckIfAnotherProductExists returned actual error code >> 1157 >> >>> (note this may not be 100% accurate if translation happened inside >> sandbox) >> >>> MSI (c) (C4:D8) [14:20:31:740]: Note: 1: 1723 2: >> >>> CheckIfAnotherProductExists 3: CheckIfAnotherProductExists 4: >> >>> C:\Users\foxit\AppData\Local\Temp\MSI209E.tmp >> >>> Error 1723. There is a problem with this Windows Installer package. A >> >>> DLL required for this install to complete could not be run. Contact >> your >> >>> support personnel or package vendor. Action >> CheckIfAnotherProductExists, >> >>> entry: CheckIfAnotherProductExists, library: >> >>> C:\Users\administrator\AppData\Local\Temp\MSI209E.tmp >> >>> MSI (c) (C4:D8) [14:20:42:153]: Product: MyProduct -- Error 1723. There >> >>> is a problem with this Windows Installer package. A DLL required for >> >>> this install to complete could not be run. Contact your support >> >>> personnel or package vendor. Action CheckIfAgentVersion, entry: >> >>> CheckIfAgentVersion, library: >> C:\Users\foxit\AppData\Local\Temp\MSI209E.tmp >> >>> >> === >> >>> >> >>> Any suggestion will be helpful. >> >>> Gauldoth >> >>> >> >>> >> >>> >> -- >> >>> Learn Graph Databases - Download FR
Re: [WiX-users] WiX missing 'Start In' property in desktop shortcut
The shortcut should be under the Component tag, not the file tag, as described in the Stack Overflow answer to your question there. If that's not working then you could supply a bit more info about what you've tried. --- Phil Wilson On Sun, Apr 27, 2014 at 11:18 PM, Satbir Singh wrote: > I am working with WiX from last 5 month with no issues. Recently, i am in > need to have "StartIn" property in App Desktop shortcut. By default, its > empty. > > I am working with below code: > > > > > > > > * Guid="D42BBB80-579B-42B3-A65D-130829F2982D">Name="My Application.exe" Source="D:\My Application\My Application.exe"> > IconIndex="0" Description="My Application Description" /> > > * > But didn't worked. > > > I have also tried adding "Target" property: > > > * Directory="DesktopFolder" Name="Virtual Sim Center Beta" > WorkingDirectory="INSTALLDIR" Icon="DesktopIcon.exe" IconIndex="0" > Description="My Application Description" />* > but getting error message: > The Shortcut/@Target attribute cannot be specified when the Shortcut > element is nested underneath a File element. > > Please Help. > -- > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installer runs OK via msiexec but fails when double-clicked
I have an installer that invokes InstallUtilLib.dll via a set of CAs as documented in http://blogs.msdn.com/b/josealmeida/archive/2004/11/08/253831.aspx & http://avinashkt.blogspot.co.uk/2007/05/how-to-create-installer-using-wix-which.html If I simply double-click on the MSI or run it using msiexec (NOT as an administrator) then it fails with Error 2869! The relevant files from the logfile (msiexec /Log ...) are Action 17:17:50: Install. DEBUG: Error 2869: The dialog ErrorDlg has the error style bit set, but is not an error dialog The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDlg, , MSI (c) (44:C0) [17:17:52:800]: Product: OpenPKI Tools -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2869. The arguments are: ErrorDlg, , Error 1001. MSI (s) (04!EC) [17:17:52:800]: DEBUG: Error 2769: Custom Action Install did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: Install, 1, CustomAction Install returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 17:17:52: InstallFinalize. Return value 3. Action 17:17:52: Rollback. Rolling back action: If I run the installer via msiexec AS AN ADMINISTRATOR it works fine! For reference - the set of CAs, including the custom action "Install" to which the Error 2769 refers is as follows: - $WmiProvider>2 $WmiProvider>2 $WmiProvider=2 $WmiProvider=2 $WmiProvider>2 $WmiProvider>2 $WmiProvider>2 $WmiProvider>2 Am I missing something that should be obvious? It feels as if the CAs are not being run with admin rights (even though I am prompted). All suggestions gratefully received. Apologies in advance if this is a FAQ with a well known answer that I've missed! Regards David -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Application pool creation
All the assemblies and config files are present after upgrade Le Vendredi 25 avril 2014 17h57, John Cooper a écrit : Something is definitely wrong with the code. Are all the assemblies and config files present after upgrade? I never see this unless something is missing. -- John Merryweather Cooper Build & Install Engineer - ESA Jack Henry & Associates, Inc.® Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: eric foka [mailto:nanafo...@yahoo.fr] Sent: Friday, April 25, 2014 3:27 PM To: 'General discussion about the WiX toolset.' Subject: [WiX-users] Application pool creation Hi I am using Wix to create an application pool with an identity of a custom account. When I do a major upgrade the application pool is stopped. and I get a service unavailable message when I try to access the website that uses this application pool. the application pool is stopped and I get Service Unavailable message. Can somebody help me for this problem. Thx -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Restart manager, services, unattended installs
Ok, I have discovered something else. For other reasons I've started developing a little notification application for our users. This is to run at login and stay running while they go about their use. It will from time to time remind them of things they should be doing and that sort of thing. Long story short, it stays running, so when it is updated (as I am now testing) it is running. This provokes the RestartManager dialogue when installed interactively and works if OK is selected. It also installs well with /quiet /norestart. What is different between this and the service? Is it because msiexec was called *from* the service in question in the sitation below? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: Douglas, Keith - CoSD/DSCo Sent: April-25-14 1:22 PM To: General discussion about the WiX toolset. Subject: RE: [WiX-users] Restart manager, services, unattended installs Do I have to have created a proper ServiceControl *before* I do the upgrade, or can my new package do everything? In any case, I do have ServiceControl Stop="both" and Wait="yes" in the *existing* packages (including the one which was causing some people trouble), so something is funny. Is there a problem with the name: some services use an 8 character name, but I've never had any other trouble with "EscalationService" as a name, so ... As for the restart, there's a situation's explanation missing: how do the command line arguments to msiexec work? (/quiet and /norestart.) Does that work to simply *stop* the restart you mentioned? Or does it fail the install because it can't tell you it is about to do so because of /quiet? Or does it just do it? Do those interact with RestartManager in any way? Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: April-25-14 1:05 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Restart manager, services, unattended installs You haven't said (or I missed it) if you're using ServiceControl - you can use that to shut down the service and restart it after the upgrade. In most cases that will mitigate any files-in-use situations because Windows looks at the ServiceControl table to see if the service will be shut down. That may make a difference in your case. If it's a completely silent install, it'll stay silent. There'll be no dialogs, and if a reboot is needed it will just do it - it can't prompt in a silent install, and a reboot is needed to complete the install so it does it. --- Phil Wilson On Fri, Apr 25, 2014 at 8:28 AM, Marc Beaudry wrote: > Hi Keith, > > Not sure that the Util:RestartResource does but have you tried > something simple like: > > > > I am using this: > > > > And all my reboots seem suppressed. > > Hope this helps, > Marc > > -Original Message- > From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] > Sent: April-25-2014 9:50 AM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Restart manager, services, unattended > installs > > Hi Marc, I think I'm finally piecing this together: the only very > missing part is the interaction with /quiet - if I am not mistaken. > But I have one question for everyone: > > Util:RestartResource - does one use that to register that one wants to > restart an *existing* application / service, or does it flag part of > one's installation as sensitive for the changes to *it*? If it is the > latter, I will be no further ahead until I install an update which > includes that, presumably. (Once I also set MSIRMSHUTDOWN=2 and > MSIDISABLERMRESTART=0) > > My question is the dual to the one on stackoverflow: 8354767. The > person there wants to prevent auto-kill; I want to do the opposite (to > ensure that the installation succeeds). > > > Keith Douglas > Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 > Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A > 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-854-5589 > Facsimile | Télécopieur 613-951-4674 Government of Canada | > Gouvernement du Canada > > -Original Message- > From: Marc Beaudry [mailto:mbeau...@matrox.com] > Sent: April-24-14 5:31 PM > To: 'General discussion about the WiX toolset.' > Subject: Re: [WiX-users] Restart manager, services, unattended > installs > > Hi Keith, > >
Re: [WiX-users] within MSI capture user cancelled... [P]
Classification: Public I tried rollback but it isn't between installinitialize and installfinalize so it errors when you start the MSI :( -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: April-27-14 1:13 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] within MSI capture user cancelled... I am probably misunderstanding the UI flow here, but why is anything happening before the user has made an upgrade choices? Typically this would all be in the UI sequence where the system isn't supposed to be affected. In the actual execute sequence this type of recovery is handled with rollback CAs. --- Phil Wilson On Sat, Apr 26, 2014 at 11:19 AM, Steve-Ogilvie wrote: > Hi > > On an upgrade (after the user selected yes to upgrade on a messagebox) > I stop our Web App Pool, and our Web Site. However if the user Cancels > the install BEFORE choosing to install the upgrade (verify ready > screen install > button) our application is in limbo because the web app pool and web > site are stopped... > > I want to capture if the user hits Cancel so I can run a custom action > to start the web app pool first then the web site using appcmd.exe > (not a deferred custom action) > > I tried using > After="CA_DISPLAY_UPGRADE_DETECTED">WIX_UPGRADE_DETECTED > >WIX_UPGRADE_DETECTED > > but when I try to compile I get a error that ExitUser is already using > that OnExit="cancel" > > Error 14 ICE82: This action UserExit has duplicate sequence number -2 > in the > table InstallUISequence > C:\Dev\SetupCommon\Main\WIX_ToolSet_v3.8\src\ext\UIExtension\wixlib\UserExit.wxs > 26 1 Admin_Console_Setup > > InstallUISequence table: > Action Condition > Sequence > CA_UPGRADE_START_APPPOOLWIX_UPGRADE_DETECTED-2 > > UserExit > -2 > > > not sure on how to handle this, any help would be appreciated! > > thanks, > > Steve > > > > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/within-M > SI-capture-user-cancelled-tp7594359.html > Sent from the wix-users mailing list archive at Nabble.com. > > -- > Start Your Social Network Today - Download eXo Platform Build > your Enterprise Intranet with eXo Platform Software Java Based Open > Source Intranet - Social, Extensible, Cloud Ready Get Started Now And > Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message has been marked as Public by Steven Ogilvie on April-28-14 9:48:38 AM. The above classification labels were added to the message by TITUS Message Classification. For more information visit www.titus.com. -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix Visual Studio Unused components does not create an error
Hello, I'm using wix 3.8 in Visual Studio 2010. If I have 2 components in a fragment in a wxs file and I only reference one of them in a feature I get an ICE21 error. If I have a wxs file with components where none of the components are part of a feature I get no error, the components are just silently skipped. Is this the desired behaviour? Is there a way to force an error message in this case? Jan Obrestad -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How implement installer to update single file ? Upgrade? Patch?
-Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: Friday, April 25, 2014 11:30 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How implement installer to update single file ? Upgrade? Patch? If you have the old MSI, there are a couple of options (but I am no expert). If the old mis supports doing a /a layout then you can extract the files of the old msi to two folder tress, original and changed, change the files in the 'changed' folder tree, and use torch to create a transform. Or you can use orca in the old msi to find out which component the files is associated. Then create a new msi with only all of the files (resources) of that component, using the same component GUID, and run that msi to update the file. But the component must be identical to the component in the original package with regard to the guid, target path, and all resources included in that component. I am just learning and experimenting with a similar situation, so others can provide more expert advice. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-implement-installer-to-update-single-file-Upgrade-Patch-tp7594344p7594346.html Sent from the wix-users mailing list archive at Nabble.com. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting property at a sequence
Thanks Bryan and Phil, Using only 'UPGRADINGPRODUCTCODE' worked to differentiate between Uninstall and Install cycle of an Upgrade. However this condition is false if Uninstalled from Add Remove Programs. I want the custom action to run in below two scenarios: 1. During Uninstall cycle of an Upgrade (only 'UPGRADINGPRODUCTCODE' works) 2. Uninstall from Add Remove Programs (only 'UPGRADINGPRODUCTCODE' does not work) Hence I modified the condition to be as: (Installed) OR (UPGRADINGPRODUCTCODE) It appears to be working fine now in all conditions. Thanks a lot for the help. Aparna Karkare L&T Infotech OAI-sys, Enterprise Components and Frameworks Office: 020-6641-6142 Email: akark...@travelers.com -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: Friday, April 25, 2014 12:07 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Setting property at a sequence Bryan has it right. In the older install that is being uninstalled, REMOVE="ALL" means it's being uninstalled, and UPGRADINGPRODUCTCODE is also set if it's being uninstalled by an upgrade. If you are in the new product being installed and you used the majorupgrade element, the WIX_UPGRADE_DETECTED property is set as the documentation says. Forget sequence numbers - they irrelevant. What matters is where actions are sequenced relative to other actions, not what the number is. Also, don't make the mistake of assuming that properties like UPGRADINGPRODUCTCODE are set to "true" or "false", or 0 or 1. They are not, so don't use them like that in any conditions. --- Phil Wilson On Fri, Apr 25, 2014 at 7:08 AM, Bryan Wolf wrote: > Try the UPGRADINGPRODUCTCODE property[1] as well as the property associated > with your Major Upgrade[2]. There's no need for all the custom actions. The > Major Upgrade property is set for the version to be installed and the > UPGRADINGPRODUCTCODE property is set for the version that is being > upgraded/removed. So, in other words, if your sequence is being run with > UPGRADINGPRODUCTCODE set then you are in a major upgrade removal. If the > Major Upgrade property is set then you're performing a major upgrade of > another version. > > [1] http://msdn.microsoft.com/en-us/library/aa372380(v=vs.85).aspx > [2] > http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.htm > l > > -Original Message- > From: Karkare,Aparna [mailto:akark...@travelers.com] > Sent: Friday, April 25, 2014 6:25 AM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Setting property at a sequence > > Hi, > > I have a custom action which is sequenced to run at number 1554. When an > Upgrade is happening, this custom action runs twice; 1st for Uninstall and > then for Install. I want that this custom action should run only for > Uninstall iteration and should skip at Install iteration internally when an > Upgrade is happening (i.e. when Uninstall and Install both cycles run one > after other). > > I couldn't find any condition which will separate these two scenarios > (Uninstall and Install phase of an upgrade). There is no property which > changes after the Uninstall cycle is over. > REMOVE="ALL" is true from the beginning till end of whole upgrade cycle. > > Hence I wrote another custom action which will set value of a property > (UNINSTALLMARKED) at sequence number around 1555 so that when Install starts > after Uninstall, I can use this property to differentiate between two > scenarios. So My condition looks like below: > > Sequence="1554">(REMOVE="ALL") AND (EXISTINGVERSION) AND (NOT > UNINSTALLMARKED) > > EXISTINGVERSION property also is always set right from the beginning as it > detects an Upgrade. > > I assumed when Uninstall cycle starts above condition will be true as > 'UNINSTALLMARKED' will not be set at sequence number 1554. But it will be set > at 1555. Hence this custom action will get executed for the Uninstall cycle > and will be skipped for Install cycle as by then the 'UNINSTALLMARKED'' > property will be set. > > However when I ran an Upgrade (run msi), below are the logs: > > MSI (s) (14:F4) [06:22:19:824]: Skipping action: > QtExecHKCRHTTPImportProperty_Cmd (condition is false) MSI (s) (14:F4) > [06:22:19:864]: PROPERTY CHANGE: Adding UNINSTALLMARKED property. Its value > is 'UNINSTALLED'. > > I don't understand if the property is getting set after the custom action > then why the condition is false? I believe out of three properties in the > condition the culprit is 'UNINSTALLMARKED' as according to logs both other > properties are getting set very early in the logs. > > Is it like even if I see property getting set later in the logs, it actually > is set before itself? Below is how I am setting property. > > Value="UNINSTALLED" Execute="immediate" /> Action="CA_MarkUninstall" Sequence="1555"> > > I basically need a condition which will differentiate between UNINSTALL and > INSTALL phase of an
Re: [WiX-users] Immediate Custom Action could not be run in some computers.
Thanks for replying. I'm sure that there is no dependency problems. If I run the msi installer with elevated privilege on that user's computer, the install will finish successfully. It turns out Windows Installer failed to extract the custom action dll to temp directory during the InstallUISequence. When the error message box is shown, there is no MSI209E.tmp under the temp directory. But I tried using GetTempFileName on that user's computer, it succeeded and a temp file is created. On Tue, Apr 22, 2014 at 12:50 AM, Phil Wilson wrote: > This is useful for showing C++ dependencies: > > http://www.dependencywalker.com/ > --- > Phil Wilson > > > On Mon, Apr 21, 2014 at 9:07 AM, Carter Young > wrote: > > Following Phil's Hunch, see here: > > > > > http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html > > > > Carter > > > > Quoting Phil Wilson : > > > >> 1157 is a missing dependency, so I'd assume that there's a dependency > >> not installed on all computers. If it's a C++ Dll it'll most likely be > >> a missing C run time. > >> --- > >> Phil Wilson > >> > >> > >> On Sun, Apr 20, 2014 at 5:55 AM, uni wrote: > >>> Hi all, > >>> > >>> I have sequenced a custom action in my msi after CostFinalize. > >>> On most user's computers, it works well. > >>> > >>> But on some user's computers, when the msi is double clicked directly > >>> for installing, it will prompt "A DLL required for this install to > >>> complete could not be run." > >>> I've changed CheckIfAnotherProductExists function to only call > >>> MessageBox(0,0,0,0), and it still prompted the error and the message > box > >>> is not showed. > >>> If I remove the CheckIfAnotherProductExists entry in the > >>> InstallExecuteSequence table, all goes well. > >>> If I run the msi in cmd(run as administrator), it works fine, there > >>> should be not dependency problem with my custom action dll. > >>> > >>> It acts as if it has something to do with the privilege. > >>> May be it failed when the custom action's dll is being copied into the > >>> temp directory, or maybe LoadLibrary failed under non elevated > privilege? > >>> > >>> Does any one has experienced something like this? > >>> > >>> The WiX code is as below, > >>> > === > >>> >>> BinaryKey="MyDll" DllEntry="CheckIfAnotherProductExists" /> > >>> > > >>> > === > >>> > >>> The log is as below, > >>> > === > >>> Action 14:20:31: CheckIfAnotherProductExists. > >>> Action start 14:20:31: CheckIfAnotherProductExists. > >>> MSI (c) (C4:B4) [14:20:31:680]: Invoking remote custom action. DLL: > >>> C:\Users\administrator\AppData\Local\Temp\MSI209E.tmp, Entrypoint: > >>> CheckIfAnotherProductExists > >>> MSI (c) (C4:88) [14:20:31:680]: Cloaking enabled. > >>> MSI (c) (C4:88) [14:20:31:680]: Attempting to enable all disabled > >>> privileges before calling Install on Server > >>> MSI (c) (C4:88) [14:20:31:680]: Connected to service for CA interface. > >>> CustomAction CheckIfAnotherProductExists returned actual error code > 1157 > >>> (note this may not be 100% accurate if translation happened inside > sandbox) > >>> MSI (c) (C4:D8) [14:20:31:740]: Note: 1: 1723 2: > >>> CheckIfAnotherProductExists 3: CheckIfAnotherProductExists 4: > >>> C:\Users\foxit\AppData\Local\Temp\MSI209E.tmp > >>> Error 1723. There is a problem with this Windows Installer package. A > >>> DLL required for this install to complete could not be run. Contact > your > >>> support personnel or package vendor. Action > CheckIfAnotherProductExists, > >>> entry: CheckIfAnotherProductExists, library: > >>> C:\Users\administrator\AppData\Local\Temp\MSI209E.tmp > >>> MSI (c) (C4:D8) [14:20:42:153]: Product: MyProduct -- Error 1723. There > >>> is a problem with this Windows Installer package. A DLL required for > >>> this install to complete could not be run. Contact your support > >>> personnel or package vendor. Action CheckIfAgentVersion, entry: > >>> CheckIfAgentVersion, library: > C:\Users\foxit\AppData\Local\Temp\MSI209E.tmp > >>> > === > >>> > >>> Any suggestion will be helpful. > >>> Gauldoth > >>> > >>> > >>> > -- > >>> Learn Graph Databases - Download FREE O'Reilly Book > >>> "Graph Databases" is the definitive new guide to graph databases and > their > >>> applications. Written by three acclaimed leaders in the field, > >>> this first edition is now available. Download your free book today! > >>> http://p.sf.net/sfu/NeoTech > >>> ___ > >>> WiX-users mailing list > >>> WiX-users@lists.sourceforge.net > >>> h
