> Use orca and have a look at your Upgrade table.
Looks fine to me. Here's the one for version 1.0.2, but the other versions
MSI's look the same (with the appriopriate version 1.0.x):
UpgradeCode VersionMin VersionMax Attributes
ActionProperty
{UPGRADE-GUID} 1.0.2 1
WIX_UPGRADE_DETECTED
{UPGRADE-GUID} 1.0.2 2
WIX_DOWNGRADE_DETECTED
{UPGRADE-GUID} 1.0.2 1.0.2 770 SELFFOUND
Does this tell you anything in particular?
> Do you have OLDERVERSION_BEINGUPGRADED / NEWERVERSION_INSTALLED defined
> there?
Actually no; that's disturbing. I thought they were Windows Installer
Properties, but looking at the reference, they're not:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370905%28v=vs.85%29.aspx
Ugh, what a mess. I'll try to hunt down where those Properties come from,
although I'm not starting to wonder how useful this Runtime.wxi is at all. :-(
Alain
-----Original Message-----
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: June 4, 2013 18:16
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] Upgrade uninstall restart issue
Use orca and have a look at your Upgrade table.
Do you have OLDERVERSION_BEINGUPGRADED / NEWERVERSION_INSTALLED defined there?
Are the other field values right? (Version Min/Max, Upgrade Code, Attributes)
-----Original Message-----
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Tuesday, June 04, 2013 4:53 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrade uninstall restart issue
>> But (apparently) just running the installer still works the same, whether
>> it's an MSI or EXE.
> Not sure what you mean by this?
So it's possible for me to install my software using just the unbundled MSI, as
well as part of a bundle (EXE), which is just the same MSI, and a packaged Java
Runtime Environment. So I meant that, regardless of whether the
installs/upgrades are being done with the bundled EXE or only our software's
MSI, the logs show the same result.
I thought I was generating /l*v logging, but anyway, looking at one generated
the way you suggested, I think I'm narrowing down on the problem. I'm using a
Runtime.wxi (attached) to determine what kind of install is being done; first
time, upgrade, maintenance, uninstall, etc. It seemed reasonable and reliable
enough, but I'm starting to think that's not the case, because although I am
definitely doing an upgrade, the properties set by the Runtime.wxi incorrectly
flag it as a FirstInstall, and not an Upgrading.
Here's a snippet of Runtime.wxi's property settings:
<InstallExecuteSequence>
<Custom Action="SetFirstInstall" After="FindRelatedProducts">
NOT Installed AND NOT OLDERVERSION_BEINGUPGRADED AND NOT
NEWERVERSION_INSTALLED
</Custom>
<Custom Action="SetUpgrading" After="SetFirstInstall">
OLDERVERSION_BEINGUPGRADED AND NOT (REMOVE="ALL")
</Custom>
<Custom Action="SetUninstalling" After="SetUpgrading">
Installed AND (REMOVE="ALL") AND NOT
(OLDERVERSION_BEINGUPGRADED OR UPGRADINGPRODUCTCODE)
</Custom>
<Custom Action="SetMaintenance" After="SetUninstalling">
Installed AND NOT Upgrading AND NOT Uninstalling AND NOT
UPGRADINGPRODUCTCODE
</Custom>
<Custom Action="SetRemovingForUpgrade" After="RemoveExistingProducts">
(REMOVE="ALL") AND UPGRADINGPRODUCTCODE
</Custom>
</InstallExecuteSequence>
The problem we're having seems to be that SetFirstInstall is somehow evaluating
to true. When I first looked though these, the way it set the conditions seemed
reasonable, but I'm guessing I don't understand them as well as I thought.
But basically, I think the way we're determining whether or not this is a first
install or an upgrade is flawed. Are there any suggestions on how to
improve/fix these? How do you other WiXers determine what kind of installation
is happening?
Alain
-----Original Message-----
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: June 4, 2013 17:19
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrade uninstall restart issue
ARPSYSTEMCOMPONENT just makes the install not appear in ARP so shouldn't make
any difference.
>> But (apparently) just running the installer still works the same, whether
>> it's an MSI or EXE.
Not sure what you mean by this?
I would suggest running the msiexec command from a batch file with the "/L*v"
logging option to ensure you get all the logging and see what that shows (it
shouldn’t be any different from the burn logs).
Neil
-----Original Message-----
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: 04 June 2013 22:09
To: Neil Sleightholm; 'General discussion for Windows Installer XML toolset.';
'Hoover, Jacob'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
Yes, I was using msiexec /I originally, before I moved from MSIs to the bundled
EXE. But (apparently) just running the installer still works the same, whether
it's an MSI or EXE.
I found the entry you're referencing:
[15CC:0FF8][2013-06-04T14:35:19]i301: Applying execute package: pkgMyProduct,
action: Install, path: C:\ProgramData\Package
Cache\{E6ABAC56-E437-4343-B888-58BA55037E0B}v1.0.1\MyProduct_v1.0.1.msi,
arguments: ' ARPSYSTEMCOMPONENT="1"'
[12C4:165C][2013-06-04T14:35:38]i319: Applied execute package: pkgMyProduct,
result: 0x0, restart: Required
So this looks like the only argument is "ARPSYSTEMCOMPONENT"="1", which...I
don't know if it's good or bad. But I do think the MSI is doing the same thing,
whether or not I run it by itself or from the bundle.
Unfortunately, I'm not sure how this gets us any further. Does this suggest any
possible solutions or at least a better understanding of the problem?
Alain
-----Original Message-----
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: June 4, 2013 13:33
To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.';
'Hoover, Jacob'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
I don't think that is the normal command for a silent install of an MSI, I
would expect something like "msiexec /i file.msi /passive"
If you are using the MsiPackage element in the log you will see an entry
containing "Applying execute package:" and after that the msiexec command line.
Neil
-----Original Message-----
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: 04 June 2013 17:32
To: Neil Sleightholm; 'General discussion for Windows Installer XML toolset.';
'Hoover, Jacob'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
Yeah, when running the MSIs, they run with the exact same command as the burn
EXEs:
cmd /c start MyInstaller.[exe or msi] -quiet -norestart -log MyInstaller.log
The only burn log lines I've found that seem to have command-line-like
parameters associated with the MSI are these:
When upgrading 1.0.1 over 1.0.0:
MSI (s) (B8:4C) [12:04:20:806]: Executing op:
Header(Signature=1397708873,Version=500,Timestamp=1120100491,LangId=1033,Platform=0,ScriptType=1,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
Action start 12:04:20: InstallFinalize.
MSI (s) (B8:4C) [12:04:20:806]: Executing op:
ProductInfo(ProductKey={GUID1},ProductName=MyProduct,PackageName=MyProduct_v1.0.1.msi,Language=1033,Version=16777217,Assignment=1,ObsoleteArg=0,ProductIcon=icoLogo,,PackageCode={GUID2},,,InstanceType=0,LUASetting=0,RemoteURTInstalls=0,ProductDeploymentFlags=3)
When upgrading 1.0.2 over 1.0.1:
MSI (s) (B8:80) [12:08:24:951]: Executing op:
Header(Signature=1397708873,Version=500,Timestamp=1120100621,LangId=1033,Platform=0,ScriptType=1,ScriptMajorVersion=21,ScriptMinorVersion=4,ScriptAttributes=1)
Action start 12:08:24: InstallFinalize.
MSI (s) (B8:80) [12:08:24:951]: Executing op: ProductInfo(ProductKey={GUID
3},ProductName=MyProduct,PackageName=MyProduct_v1.0.2.msi,Language=1033,Version=16777218,Assignment=1,ObsoleteArg=0,ProductIcon=icoLogo,,PackageCode={GUID
4},,,InstanceType=0,LUASetting=0,RemoteURTInstalls=0,ProductDeploymentFlags=3)
These don't really tell me much. Do they tell you anything, or maybe these
aren't the right lines?
One way or another, the bundle must be doing (or not doing) something
differently (and wrong) than when the MSI does its own thing correctly.
Alain
-----Original Message-----
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: June 4, 2013 11:45
To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.';
'Hoover, Jacob'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
One difference is that burn will only run the execute install sequence as it is
running the MSI silently, when you run just the MSIs have you tried running
them silently to see if you get the same issue - you can see the command line
that burn is using in the log files.
I had the service issue before burn and IIRC it was related to running the MSI
silent (I was using another bootstrapper at the time).
Neil
-----Original Message-----
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: 04 June 2013 16:36
To: Neil Sleightholm; 'General discussion for Windows Installer XML toolset.';
'Hoover, Jacob'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
Yes, I have 4 ServiceControl elements in the MSI, but up until this issue came
up, the MSI had absolutely no problems stopping all the services, removing
them, and then installing the new versions, and starting them. But that was
before I was using burn...so I just tried the same process (install 1.0.0,
upgrade to 1.0.1, then upgrade to 1.0.2, all w/o restarts) with only the MSI of
our software (unbundled), and the problem does NOT seem to happen. In the ARP,
there is only the 1.0.2, and no leftover 1.0.1. Furthermore, if I try to
uninstall 1.0.2, it does so without complaint.
So this suggests there's something with the bundling/burn process that's
messing things up, so let's take a look:
<?xml version='1.0' encoding='windows-1252'?> <Wix
xmlns='http://schemas.microsoft.com/wix/2006/wi'
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension";
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension";
>
<?ifndef PRODUCTVERSION?>
<?error PRODUCTVERSION must be defined ?> <?endif ?>
<Bundle
Name="MyBundle"
UpgradeCode="MYGUID"
Version="$(var.PRODUCTVERSION)"
Copyright="Copyright © Us"
IconSourceFile="lib/Logo.ico"
Manufacturer="Us"
DisableModify="yes"
>
<BootstrapperApplicationRef
Id="WixStandardBootstrapperApplication.RtfLicense" >
<bal:WixStandardBootstrapperApplication
LicenseFile="License.rtf"
LogoFile="lib\Logo.png"
SuppressOptionsUI="yes"
ThemeFile="MyRtfTheme.xml"
/>
</BootstrapperApplicationRef>
<!-- Abort installation if not running with administrator privileges -->
<bal:Condition Message="This installer requires administrator
privileges to run.">
Privileged <!--OR AdminUser-->
</bal:Condition>
<!-- Abort installation if not running on Windows 7 or 8 -->
<bal:Condition Message='Sorry, but this software only supports Windows
7 or Windows 8.'>
VersionNT >= v6.1 AND v7.0 > VersionNT
</bal:Condition>
<Chain DisableSystemRestore="yes">
<PackageGroupRef Id="pkgJRE7" />
<MsiPackage
Id="pkgMySoftware"
DisplayName="MySoftware"
Cache="no"
Compressed="yes"
Permanent="no"
SourceFile="MySoftware.msi"
Visible="no"
Vital="yes"
></MsiPackage>
</Chain>
</Bundle>
</Wix>
So as can be seen by Visible="no" in the MsiPackage, I don't want to show both
the MSI and the bundle's entries in the ARP. Is this a mistake?
Nothing else strikes me as odd or wrong, but I'm pretty new to burn.
Neil, did you notice the service-related problems when you transitioned from a
single MSI to a burn bundle, like I am here?
Alain
-----Original Message-----
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: June 4, 2013 02:09
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.;
'Hoover, Jacob'
Subject: RE: [WiX-users] Upgrade uninstall restart issue
Do you have more than one ServiceContol elements in your MSI? I found in the
past that Windows Installer (not WiX) only supports one (or it might have been
one per service id), this may have been fixed but is worth checking (try
writing a simple MSI that just stops services and check they are stopped).
What I have resorted to is using a custom action to run "net stop" to stop
services. The other thing you see is that the service gets marked as disabled
and then the install cannot install a new copy (I see this every time I upgrade
iTunes).
Since using burn I am using a support MSI that just stops all the services
before the main MSI runs, this seems to work much more reliably.
Neil
-----Original Message-----
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: 04 June 2013 00:40
To: 'Hoover, Jacob'; 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Upgrade uninstall restart issue
None of the services are inter-dependent (one of the features of our system),
and here's what the ServiceElements look like:
<ServiceControl
Id="ServiceId"
Name="ServiceName"
Remove="uninstall"
Start="install"
Stop="both"
Wait="yes"
/>
So wait was set to yes for all of them. And looking in the logs that each of
the services generate, they do all shut down in a timely fashion.
Any other thoughts?
Alain
-----Original Message-----
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: June 3, 2013 14:27
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] Upgrade uninstall restart issue
>From
>http://msdn.microsoft.com/en-us/library/windows/desktop/aa373667(v=vs.8
>5).aspx
351 = ERROR_FAIL_SHUTDOWN
Some applications could not be shut down. The AppStatus of the RM_PROCESS_INFO
structures returned by the RmGetList function contain updated status
information.
I'd suggest looking at your ServiceControl elements. Are the services
interdependent (IE does stopping one stop another)? Do you have Wait=no on any
of them?
-----Original Message-----
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Monday, June 03, 2013 12:52 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrade uninstall restart issue
We've encountered a curious problem when our bundle auto upgrades. When our
client software dials home and detects that it is outdated, it downloads the
newest version (1.0.1), and runs it with the following command:
cmd /c start MyUpToDateBundle.exe -quiet -norestart -log MyUpToDateBundle.log
This works fine and upgrades the software. However, if I then immediately try
to uninstall the (upgraded, 1.0.1) software, it fails with a message saying
that a restart is needed. Furthermore, if a second upgrade (1.0.2) occurs
before a restart, the software is successfully upgraded, but there are two
entries in the Programs and Features or Add/Remove Programs (ARP), the previous
version (1.0.1), and the current version (1.0.2).
This shouldn't happen. There should be only the most recent/currently installed
version (1.0.2) in the ARP. Furthermore, we don't know what part of our
software would request a restart, because it clearly updates and runs just fine
immediately without a restart. We also do not recall having this problem when
we were using an MSI, but curiously, the logs suggest that it's the packaged
MSI that's requesting the restart:
...
MSI (s) (B8:B0) [12:04:15:942]: RESTART MANAGER: Will attempt to shut down and
restart applications in no UI modes.
MSI (s) (B8:B0) [12:04:15:942]: RESTART MANAGER: Detected that the service
MyService1 will be stopped due to a service control action authored in the
package before the files are updated. So, we will not attempt to stop this
service using Restart Manager MSI (s) (B8:B0) [12:04:15:942]: RESTART MANAGER:
Detected that the service MyService2 will be stopped due to a service control
action authored in the package before the files are updated. So, we will not
attempt to stop this service using Restart Manager MSI (s) (B8:B0)
[12:04:15:942]: RESTART MANAGER: Detected that the service MyService3 will be
stopped due to a service control action authored in the package before the
files are updated. So, we will not attempt to stop this service using Restart
Manager MSI (s) (B8:B0) [12:04:15:942]: RESTART MANAGER: Detected that the
service MyService4 will be stopped due to a service control action authored in
the package before the files are updated. So, we will not attempt to stop this
service using Restart Manager MSI (c) (60:48) [12:04:15:980]: RESTART MANAGER:
Session opened.
MSI (s) (B8:B0) [12:04:16:041]: RESTART MANAGER: Failed to shut down all
applications in the service's session. Error: 351 MSI (c) (60:48)
[12:04:16:041]: Disallowing shutdown. Shutdown counter: 0 MSI (c) (60:48)
[12:04:16:041]: RESTART MANAGER: Successfully shut down all applications that
held files in use.
...
MSI (s) (B8:B0) [12:04:20:760]: Propagated Reboot to the client/parent install.
MSI (s) (B8:B0) [12:04:20:760]: Value of RebootAction property is MSI (s)
(B8:B0) [12:04:20:760]: Windows Installer requires a system restart. Product
Name: MyProduct. Product Version: 1.0.0. Product Language: 1033. Manufacturer:
Us. Type of System Restart: 1. Reason for Restart: 1.
Property(N): ReplacedInUseFiles = 1
CustomAction returned actual error code -1 (note this may not be 100% accurate
if translation happened inside sandbox) MSI (s) (B8:4C) [12:04:20:762]:
Skipping action: SetRemovingForUpgrade (condition is false) ...
MSI (s) (B8:4C) [12:04:28:584]: Product: MyProduct -- Installation completed
successfully.
MSI (s) (B8:4C) [12:04:28:585]: Windows Installer installed the product.
Product Name: MyProduct. Product Version: 1.0.1. Product Language: 1033.
Manufacturer: Us. Installation success or error status: 0.
MSI (s) (B8:4C) [12:04:28:585]: Value of RebootAction property is MSI (s)
(B8:4C) [12:04:28:585]: Windows Installer requires a system restart. Product
Name: MyProduct. Product Version: 1.0.1. Product Language: 1033. Manufacturer:
Us. Type of System Restart: 2. Reason for Restart: 0.
MSI (s) (B8:4C) [12:04:28:585]: Product: MyProduct. Restart required. The
installation or update for the product required a restart for all changes to
take effect. The restart was deferred to a later time.
MSI (s) (B8:4C) [12:04:28:586]: Deferring clean up of packages/files, if any
exist MSI (s) (B8:4C) [12:04:28:586]: MainEngineThread is returning 3010 MSI
(s) (B8:B4) [12:04:28:588]: RESTART MANAGER: Session closed.
MSI (s) (B8:B4) [12:04:28:591]: RESTART MANAGER: Previously shut down
applications have been restarted.
MSI (s) (B8:B4) [12:04:28:592]: RESTART MANAGER: Session closed.
I found two things curious about these logs. First, it claims that it failed to
shut down all applications, but also thinks they all shut down (which I'm
pretty certain they did):
MSI (s) (B8:B0) [12:04:16:041]: RESTART MANAGER: Failed to shut down all
applications in the service's session. Error: 351 MSI (c) (60:48)
[12:04:16:041]: Disallowing shutdown. Shutdown counter: 0 MSI (c) (60:48)
[12:04:16:041]: RESTART MANAGER: Successfully shut down all applications that
held files in use.
Second, the Type of System Restart and Reason for Restart seems to change:
MSI (s) (B8:B0) [12:04:20:760]: Windows Installer requires a system restart.
Product Name: MyProduct. Product Version: 1.0.0. Product Language: 1033.
Manufacturer: Us. Type of System Restart: 1. Reason for Restart: 1.
...
MSI (s) (B8:4C) [12:04:28:585]: Windows Installer requires a system restart.
Product Name: MyProduct. Product Version: 1.0.1. Product Language: 1033.
Manufacturer: Us. Type of System Restart: 2. Reason for Restart: 0.
Unfortunately, I haven't been able to figure out what those type and reason
codes represent. In any case, it seems to think that the restart is needed
because some files in use were replaced:
Property(N): ReplacedInUseFiles = 1
But I don't see how that can be, because our services do get shutdown
correctly. Maybe it's not waiting long enough (even though it really doesn't
take long at all)?
Any ideas why this might be happening and how we could prevent recently
upgraded versions of our software from being restart-locked in this way?
Alain
***************************************
Alain Forget, Ph.D.
Postdoctoral Researcher
CyLab, Carnegie Mellon University
afor...@cmu.edu
http://cups.cs.cmu.edu/~aforget/
***************************************
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free
troubleshooting tool designed for production Get down to code-level detail for
bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations 2.
Dashboards that offer high-level views of enterprise services 3. A single
system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations 2.
Dashboards that offer high-level views of enterprise services 3. A single
system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
