So after further investigation (i.e. running the debug build and adding some
trace statements), there are 2 separate issues here:
a) Watson doesn't re-install cleanly in 100% of cases
b) The setup bootstrapper is working like it probably should, i.e. in the
DetectMsi() function, the action is being determined to be NONE, since each
.msi inside the package is already installed, same major version, same minor
version. So it's probably fine, except that it would be good if there was
feedback to say none of the msi's contained within it needed to be executed.
Recommended action: we modify the standard bootstrapper in setupexe.cpp to pop
up a message box to say that no work needs to be done as everything is already
installed, rather than exiting silently.
Alec
Ps something I noticed, our internal Microsoft share of the source code for
wix3 seems to be missing the code for dutil which is present in the publicly
available version. Was wondering why it wouldn't build initially J.
From: Rob Mensching
Sent: Thursday, May 17, 2007 6:32 PM
To: Alec Siu; wix-users@lists.sourceforge.net
Cc: Jon LeCroy; Margaret Rottsolk
Subject: RE: WiX v3 setupbld.exe question
1. You can run a debug build (have to build it yourself) and see some things
dumped to the debug console.
2. Also, it was pointed out to me that the name in the cached scenario is
actually the "ProductCodevVersion.msi" not the name of the MSI you originally
built. That might be causing you problems.
3. New chainer probably won't be realistically interesting for 4 - 6 months
for shipping code. There is a lot of new stuff in there and I hope to have
drops in the next month (but I thought I'd have enough code working by now and
that hasn't work out.. real life... blah, blah, blah).
From: Alec Siu
Sent: Thursday, May 17, 2007 2:31 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Cc: Jon LeCroy; Margaret Rottsolk
Subject: RE: WiX v3 setupbld.exe question
Thanks Rob for the info; I tried using -mc in the parameters to setupbld.exe to
enable caching but to no avail. Actually I enabled global MSI logging with the
regkey HKLM\Software\Policies\Microsoft\Windows\Installer\Logging, and it
doesn't seem as though the first MSI is being invoked at all (if the absence of
a log file is a reliable indication).
Is there a way to enable debugging spew to see what the chainer/setup stub is
doing? And do you have an estimate of when a future chainer might be released?
Thanks much,
Alec
From: Rob Mensching
Sent: Thursday, May 17, 2007 11:34 AM
To: Alec Siu; wix-users@lists.sourceforge.net
Cc: Jon LeCroy; Margaret Rottsolk
Subject: RE: WiX v3 setupbld.exe question
Yeah, in the current setup.exe in the WiX toolset, if you don't specify to
cache the MSI then the original path is going to be random. The future chainer
will have better behavior.
From: Alec Siu
Sent: Wednesday, May 16, 2007 4:26 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Cc: Jon LeCroy; Margaret Rottsolk
Subject: RE: WiX v3 setupbld.exe question
Hi Rob,
Copying and pasting from an e-mail from Carolyn Napier who had a look at our
logs relating to this issue:
----8< ----
Error 1316. A network error occurred while attempting to read from the file:
C:\EHS\alec\dev\CTEB.tmp
MSI (s) (F0:14) [14:19:26:471]: Note: 1: 2205 2: 3: Error
MSI (s) (F0:14) [14:19:26:471]: Note: 1: 2228 2: 3: Error 4: SELECT `Message`
FROM `Error` WHERE `Error` = 1709
MSI (s) (F0:14) [14:19:26:471]: Product: Microsoft Application Error Reporting
-- Error 1316. A network error occurred while attempting to read from the file:
C:\EHS\alec\dev\CTEB.tmp
Action ended 14:19:26: PublishProduct. Return value 3.
Per MSDN documentation, you cannot change the filename of the MSI package file
in small/minor updates. This product is already installed. Does your chainer
extract to a temporary file name and install in that manner? My guess as to
the common cause of this error in this situation is that the prior install was
done using the MSI file called CTEB.tmp and now you're trying to do the install
from a new location but with a different filename.
MSI (c) (08:80) [14:19:23:440]: ******* RunEngine:
******* Product: dw20sharedamd64.msi
******* Action:
******* CommandLine: **********
And this is further evidenced in the log file:
MSI (c) (08:80) [14:19:23:487]: Product registered: entering maintenance mode
MSI (c) (08:80) [14:19:23:487]: PROPERTY CHANGE: Adding ProductState property.
Its value is '5'.
MSI (c) (08:80) [14:19:23:487]: PROPERTY CHANGE: Adding ProductToBeRegistered
property. Its value is '1'.
MSI (c) (08:80) [14:19:23:487]: Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (c) (08:80) [14:19:23:487]: Specifed source is not already in a list.
MSI (c) (08:80) [14:19:23:487]: User policy value 'SearchOrder' is 'nmu'
MSI (c) (08:80) [14:19:23:487]: Machine policy value 'DisableBrowse' is 0
MSI (c) (08:80) [14:19:23:487]: Machine policy value 'AllowLockdownBrowse' is 0
MSI (c) (08:80) [14:19:23:487]: Adding new sources is allowed.
MSI (c) (08:80) [14:19:23:487]: Package name retrieved from configuration data:
'CTEB.tmp'
You need to ensure that the filenames stay the same. Yes, it's a known
limitation given that sources are validated using the filename and the package
code. The filename is considered an integral part.
---- >8----
So this is starting to make sense, the chainer is extracting to some randomized
filename and calling msiexec on the temp file, so that the next time we run our
setup.exe, it fails because Windows Installer recognizes the already-installed
product and tries to re-read the original extracted (temporary) MSI, which has
been of course by now deleted.
Does this explanation sound feasible to you? Would there be ways to get around
this and/or confirm this theory?
Alec
From: Rob Mensching
Sent: Friday, May 04, 2007 11:03 AM
To: Jon LeCroy; Alec Siu; wix-users@lists.sourceforge.net
Subject: RE: WiX v3 setupbld.exe question
Ahh, dude, your MSI (it does look like it is running the already installed
version) is accessing that file for some reason and can't find it. Can't
decipher much more than that from the log file.
From: Jon LeCroy
Sent: Friday, May 04, 2007 10:33 AM
To: Rob Mensching; Alec Siu; wix-users@lists.sourceforge.net
Subject: RE: WiX v3 setupbld.exe question
It doesn't crash, but it does present this error: Error 1316. A network error
occurred while attempting to read from the file: C:\EHS\alec\dev\CTEB.tmp
Note - this is running locally. Log attached.
From: Rob Mensching
Sent: Friday, May 04, 2007 10:19 AM
To: Alec Siu; wix-users@lists.sourceforge.net
Cc: Jon LeCroy
Subject: RE: WiX v3 setupbld.exe question
What do you mean by the install "crashes with an error message"? Installations
shouldn't crash. They may error out but crashing is a really scary thing.
The best thing is to get the logging registry key set to get a log file for the
A.msi.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alec Siu
Sent: Thursday, May 03, 2007 1:57 PM
To: wix-users@lists.sourceforge.net
Cc: Jon LeCroy
Subject: [WiX-users] WiX v3 setupbld.exe question
Hi All,
We're using setupbld.exe to chain two MSIs together (the first one say A.msi
spec'ed with -mu, the second B.msi with -mus). This works fine, except we're
testing the scenario where the user might try and run the setup.exe more than
once.
B.msi has some code to detect and prevent re-installations, but A.msi (which is
3rd party) does not. When I run A.msi by itself, it crashes with an error
message, so it seems that the combined .exe version is suppressing this. I
tried re-specing with -mus for A.msi as well in order to show any embedded UI
it might have, but again it fails silently. I tried turning on global MSI
logging via the registry
(HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\Installer\Logging =
voicewarmupx!) but it doesn't show up there either...
Is there a way to debug this combined setup.exe (to confirm that this is in
fact what's causing the problem) or is this a known limitation?
Thanks,
Alec
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
