Here is the download link to the uninstall logs:
https://www.dropbox.com/s/5qivuotwbornc8t/UninstallLogs.zip?dl=0
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-running-very-Slow-tp7600812p7600828.html
Sent from the wix-users mailing li
Nope the VM's are strictly captured snapshots and therefore no accumulative
changes are applied to the images.
Another thing to note is that we have our own uninstaller application that
simply launch the uninstalls of our products that are selected by the user
and the tester noticed that the slow
It may help to post the logs somewhere anyway, just in case someone
here can see something unusual.
IIRC, the VM may be one of those that does accumulative changes but
keeps the original image intact, so each action requires checking the
original image and then searching the list of changes to get
OK,
problem solved,
I had one file that was locked, that failed the deletion operation,
Thanks for all your help!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600206.html
Sent from the
Sorry for that,
SHOULDDELETEINSTALLATIONFOLDER = "TRUE"
wrapped with CDATA..
where the property is set from burn
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600205.html
Sent from the w
The inner text is:
where
SHOULDDELETEINSTALLATIONFOLDER is a property set from the bundle..
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-worki
iginal Message-
From: ronif [mailto:ro...@microsoft.com]
Sent: Wednesday, May 6, 2015 10:50 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
The inner text is:
bject: Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
Hi again,
you were correct about the property but for some reason the folder is still not
being delete..
Here are the relevant lines from the log:
MSI (s) (A8:90) [07:55:51:893]: Doing action: SetInstallationPathProperty
Actio
Hi again,
you were correct about the property but for some reason the folder is still
not being delete..
Here are the relevant lines from the log:
MSI (s) (A8:90) [07:55:51:893]: Doing action: SetInstallationPathProperty
Action ended 7:55:51: ValidateProductID. Return value 1.
MSI (s) (A8:90) [07
Thanks for your help John!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-and-util-RemoveFolderEx-not-working-tp7600191p7600196.html
Sent from the wix-users mailing list archive at Nabble.com.
---
o:ro...@microsoft.com]
Sent: Wednesday, May 6, 2015 9:12 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Uninstall and util:RemoveFolderEx - not working
Hi,
thanks for your answer,
so what is the best way to be able to reference an msiproperty i get from
Hi,
thanks for your answer,
so what is the best way to be able to reference an msiproperty i get from
burn?
If I can't use ?
and how can I set it before CostInitialize?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabbl
>From the documentation:
The folder must be specified in the Property attribute as the name of a
property that will have a value that resolves to the full path of the folder
before the CostInitialize action. Note that Directory ids cannot be used. For
more details, see the Remarks.
Before Cost
Where to include REMOVE=ALL using WIXFAILWHENDEFERRED
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-Rollback-not-triggered-with-WIXFAILWHENDEFERRED-tp7598874p7599202.html
Sent from the wix-users mailing list archive at Nabble.com.
Ok I came across the method you prefer to chain several MSI packages. But,
what I have now is 2 bundles (let's say Light and Pro) with their own MSI
packages.
I want the Pro version to uninstall the Light, and vice versa.
With RelatedBundle you can detect if they are related but only the version
You can use Wix XML to author MSI package project(s) or a Bundle
(bootstrapper) project, but you do not have to author a bootstrapper.
http://wixtoolset.org/documentation/manual/v3/bundle/
A Bundle includes a "Bootstraper Application" (BA) which is processed by the
Wix Burn engine. The event hand
I don't have WixFailWhenDeferred custom action in InstallExecuteSequence.
Infact, when I opened the msi in ORCA, the CA was sequenced at 6599 (before
InstallFinalize) with condition "WIXFAILWHENDEFERRED=1 AND VersionNT > 400"
This I believe should trigger rollback for both Install and Uninstall.
A
Include the condition in your execute sequence to include REMOVE=ALL
On Fri, Jan 16, 2015 at 11:35 AM, wixtester wrote:
> Hi,
>
>I am using the WIXFAILWHENDEFFERED customaction reference to test the
> installer rollback sequence.
> The Install rollback works fine with this property but the u
By ProductCode, do you mean Product Id? I tried , but
it seems like the installer will just install/overwrite and not remove the
old application.
By PackageCode, do you mean http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-previous-version-tp7596982p7596999.html
Sent from t
Nobody can know if your upgrade will work because it depends on the
changes made to a set of properties between old and new MSI files. The
UpgradeCode must be the same, ProductCode must have changed,
PackageCode too (but WiX does that by default I think) and the
ProductVersion must be incremented
I have the following:
Is that enough and should that be modified?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-previous-version-tp7596982p7596985.html
Sent from the wix-users mailing lis
2014-09-25 11:49 GMT-03:00 newuser2014 :
> Hi,
> I have the Product id as follows:
>
> And I have added the following:
>
>
>
> This seems to just overwrite the previous version and not uninstall it.
> After installation of the newer version, I went into Add/Remove Programs
> and saw that
Original Message-
> From: Walter Dexter [mailto:wfdex...@gmail.com ]
> Sent: Friday, May 30, 2014 1:36 PM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Uninstall then Reinstall Same Package
>
> Why is doing this a bad idea? I know that's the
nry.com
-Original Message-
From: Walter Dexter [mailto:wfdex...@gmail.com]
Sent: Friday, May 30, 2014 1:36 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Uninstall then Reinstall Same Package
Why is doing this a bad idea? I know that's the common belief, b
Why is doing this a bad idea? I know that's the common belief, but I don't
know the reason.
On Fri, May 30, 2014 at 11:09 AM, John Cooper
wrote:
> Instead of using the old Upgrade authoring, use the MajorUpgrade authoring
> and take a look at the AllowSameVersionUpgrades attribute. Note that
Phil,
Thanks for the info, it clarified my assumptions...
Marc
-Original Message-
From: Phil Wilson [mailto:phildgwil...@gmail.com]
Sent: May-30-2014 12:37 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Uninstall Guidelines - What should be happening
My
My interpretation of using a file for user-specific data is that it's
being contrasted with using the registry. It is next to impossible to
remove HKCU-type registry data for a user that isn't currently logged
on. Removing a file in some other user's data folder is much easier.
We're talking about
Thanks, I'll take a look at that. I completely agree, this should not be
done but people more important than myself decide such things.
On Fri, May 30, 2014 at 12:09 PM, John Cooper
wrote:
> Instead of using the old Upgrade authoring, use the MajorUpgrade authoring
> and take a look at the Allo
I do this in some MSIs that we deploy strictly silently via Microsoft
system management stuff.
My upgrade block looks like this:
And also this, which I think matters:
Then I have a wxi file that I include that contains:
You don't really need the vars and the .wxi fi
Instead of using the old Upgrade authoring, use the MajorUpgrade authoring and
take a look at the AllowSameVersionUpgrades attribute. Note that this is a
really bad idea(tm) in the field.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry & Associates, Inc.®
Shawnee Mission,
I got the solution for my first problem (files not removed from installed
location). I forgot to set the MSI property value on uninstallation. So the
MSI feature is not get called and files not removed. Now the files are
removed correctly.
Could anyone please share example/way for removing selecte
Great, Thanks Rob.
In which event I need to handle this process? In DetectPackageComplete I can
able to get the state of the packages.
My bundle having "InstallCondition" in chain/MsiPackage element. Is this
condition enough for handle selected MSI on Uninstallation?
--
View this message in con
@lists.sourceforge.net
Subject: Re: [WiX-users] Uninstall MSI from ARP doesn't remove installed files
Thanks for your reply.
I need some clarifications in uninstalling MSI using burn.
Is it possible to remove only the selected MSI files while uninstallation?
Scenario :
If launch the bundle uninstall fro
Thanks for your reply.
I need some clarifications in uninstalling MSI using burn.
Is it possible to remove only the selected MSI files while uninstallation?
Scenario :
If launch the bundle uninstall from ARP, it shows the installed MSI packages
list. I will select any of one MSI from that list and
If you're saying that you uninstall one of the MSIs from ARP and some
files remain, but if you uninstall both MSIs via the bundle and no
files remain, one explanation is there are some shared files in both
MSIs and uninstalling one will leave them behind because they are used
by the other.
Sounds like something is awry with your MSI. I would expect that to work.
Verbose log file should show you what's going on.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message---
Thanks David, I will try this and let you know
On 21-03-2014 19:48, David Watson wrote:
> You need to persist the VIRTUAL_DIR_VAL (store it in the registry) so the
> uninstaller knows it has changed otherwise it will use the default values.
>
> http://robmensching.com/blog/posts/2010/5/2/the-wix
You need to persist the VIRTUAL_DIR_VAL (store it in the registry) so the
uninstaller knows it has changed otherwise it will use the default values.
http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern
-Original Message-
From: Suvrajyoti Panda [mailto:s
These might help. It's possible the patched file was never cached in
the baseline cache (or was removed) or it wasn't a >= MSI 3.0 patch:
http://blogs.msdn.com/b/heaths/archive/2007/01/17/the-patch-cache-and-freeing-space.aspx
and this may still be an issue:
http://blogs.msdn.com/b/heaths/archiv
>>
>> -Original Message-
>> From: David Connet [mailto:d...@agilityrecordbook.com]
>> Sent: Wednesday, December 18, 2013 8:25 AM
>> To: General discussion about the WiX toolset.
>> Subject: Re: [WiX-users] Uninstall by Installer not removing the path
ring uninstall).
>
> -Original Message-
> From: David Connet [mailto:d...@agilityrecordbook.com]
> Sent: Wednesday, December 18, 2013 8:25 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
>
Message-
> From: David Connet [mailto:d...@agilityrecordbook.com]
> Sent: Wednesday, December 18, 2013 8:25 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
> if that path is open on the system
>
val on uninstall even if that path is open, or this is a
>>>>> known issue?
>>>>>
>>>>> Regards,
>>>>> SuvraJyoti
>>>>> On 17-12-2013 14:14, Blair Murri wrote:
>>>>>> If a file being removed can’t be moved, then i
25 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
if that path is open on the system
There is no way (that I know of) to delete a directory where something has an
open handle on that. The only way is to make sur
ring reboot, and unfortunately the folder will then be left
>>> behind (because only file delete records are placed into the reboot
>>> sequence, not folders). After reboot there isn’t an installation left to
>>> run to cleanup any further.
>>>>>
&
me, files still in use can be moved (even if they are
>> still loaded in other processes) and the folder is thus removed during the
>> installation transaction (before the reboot) and the moved file is then
>> removed as part of the reboot sequence.
>>>>
>>>>
&g
;
> >> From: Suvrajyoti Panda
> >> Sent: Monday, December 16, 2013 8:57 PM
> >> To: General discussion for Windows Installer XML toolset.
> >>
> >>
> >>
> >>
> >>
> >> No Wesley, I have not used any create folder o
rote:
>>> Did you use CreateFolder to create this directory? If so I think you need
>>> to use RemoveFolder to remove the folder. Not sure about that though.
>>>
>>> -Original Message-
>>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.
--Original Message-
>> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
>> Sent: December-16-13 12:37 AM
>> To: General discussion about the WiX toolset.
>> Subject: Re: [WiX-users] Uninstall by Installer not removing the path
>> created if that path is o
ory? If so I think you need to
> use RemoveFolder to remove the folder. Not sure about that though.
>
> -Original Message-
> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
> Sent: December-16-13 12:37 AM
> To: General discussion about the WiX toolset.
>
inal Message-
> From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.in]
> Sent: December-16-13 12:37 AM
> To: General discussion about the WiX toolset.
> Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
> if that path is open on the system
>
>
WiX toolset.
Subject: Re: [WiX-users] Uninstall by Installer not removing the path created
if that path is open on the system
Hey Wesley,
checked it on a reboot, that does not work. The structure is still there. Any
others suggestions guys?
Regards,
SuvraJyoti
On 13-12-2013 20:13, Wesley Manning
Hey Wesley,
checked it on a reboot, that does not work. The structure is still
there. Any others suggestions guys?
Regards,
SuvraJyoti
On 13-12-2013 20:13, Wesley Manning wrote:
> It might be removed on a reboot. If you had folder open, then windows
> installer can't uninstall it. But I think
It might be removed on a reboot. If you had folder open, then windows
installer can't uninstall it. But I think it marks it for removal. I know for
sure files have this behaviour but I'm not sure about folders.
-Original Message-
From: Suvrajyoti Panda [mailto:suvrajyo...@contata.co.i
19, 2013 10:43 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Uninstall previous version with new version
>
> They have to be minor upgrades of each other (i.e. share the same
> ProductCode). The three downsides that immediately come to m
013 12:08 PM
To: chr...@iswix.com, "General discussion for Windows Installer XML
toolset."
Subject: Re: [WiX-users] Uninstall removing user data
The rule is that if MSI installs it, then an uninstall will uninstall it.
The modify/creation date difference is what determines whether to o
The rule is that if MSI installs it, then an uninstall will uninstall it.
The modify/creation date difference is what determines whether to overwrite
it, not uninstall it. User data is created by the app, not installed with
the app, in this context that's the way I look at it.
(Unless I'm having a
ll need to find out how to
update that within TFS.
Cheers!
.Mark
-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: Thursday, September 19, 2013 10:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Uninstall previous version with n
They have to be minor upgrades of each other (i.e. share the same ProductCode).
The three downsides that immediately come to mind are that you cannot
double-click version 2.msi and succeed at installing it (you have to supply a
special command-line), if the version 2.msi isn't identically named
This is just a wild idea, but could you create a bundle (with a product
search), which you use to stage your test project (uninstall the old and
install the new)?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Uninstall-bundle-by-name-tp7588776p7
Hi,
What we did is build a front end that builds an "uninstall message" when the
package is built (again by the front end, but you could use a build script or
something maybe) and uses our install-and-monitor software to parse it when it
arrives. You'd need SCCM or Afaria or other tools like th
Nothing that is documented today.
On Wed, Sep 4, 2013 at 3:57 PM, wrote:
> Hi all - I've managed to upgrade some of our installs to Wix 3.7 with the
> burn bootstrapper, hooray !
>
> One thing I haven't quite anticipated is this: after our automated build
> we need to push a newly-built install
The engine always returns an HRESULT in the ApplyComplete event. Converted to
hex, you're getting 0x8007015E. 0x015E, or 350, is ERROR_FAIL_NOACTION_REBOOT
(from WinError.h). I also see the engine raising the Error event in this case,
where it sends the error code 350.
I think the only thin
It's ARP being magical. Never quite tracked down how they did it.
Fortunately, Burn is smart enough to recognize that it is already elevated
and doesn't ask again.
On Thu, Jul 25, 2013 at 3:55 AM, Tobias S wrote:
> Any idea on that behavior? Feedback highly appreciated.
>
> Best regards,
> To
Any idea on that behavior? Feedback highly appreciated.
Best regards,
Tobias
2013/7/16 Tobias S
> Hi,
>
> Didn't find any answer related to this on the mailing list yet.
>
> Have following behavior on Win7 VMs with Custom BAL as well as when using
> BootstrapperApplicationRef Id="
> WixStandar
the meantime.
Alain
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: June 28, 2013 16:07
To: afor...@cmu.edu; General discussion for Windows Installer XML toolset.
Subject: RE: [WiX-users] Uninstall restart issue
Do you still have the computer management console
: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 2:38 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
I'll open by saying that I don't think this is why the services are being
disabled, because I&#
such a
nightmare, I might have pushed harder to redo everything in .NET.
Alain
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: June 28, 2013 14:55
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Any proc
it will be ok and the service will stop.
If your java runtime has an explicit way to stop a Windows service and wait
for it to actually finish, use that.
Phil
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 11:14 AM
To: 'General discuss
gestions.
Alain
-Original Message-
From: Phil Wilson [mailto:phil.wil...@mvps.org]
Sent: June 28, 2013 14:03
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
I've mentioned this before, but I don't recall if
is
not complicated and is much more manageable than a command shell.
Phil
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Friday, June 28, 2013 7:07 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restar
es aren't being completely removed immediately
at uninstall, even though I have specified that they should be removed at
uninstall in the ServiceControl tags?
Alain
-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: June 27, 2013 19:06
To: 'General discussion
wix-users@lists.sourceforge.net
> Date: Thu, 27 Jun 2013 16:12:04 -0400
> Subject: Re: [WiX-users] Uninstall restart issue
>
> I have just confirmed that, when my service is running the cmd.exe process,
> the RestartManager requests the restart, while otherwise, it does not.
>
>
0
9767
Application
aforget
http://schemas.microsoft.com/win/2004/08/events";
xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";>
0
2013-06-27T17:50:24.860219600Z
-Original M
aforget
http://schemas.microsoft.com/win/2004/08/events";
xmlns="http://www.microsoft.com/2005/08/Windows/Reliability/RestartManager/";>
0
2013-06-27T17:50:24.860219600Z
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: June 26, 2013
Installer XML toolset.
Subject: Re: [WiX-users] Uninstall restart issue
Hey Alain,
Take a look at my answer to this problem on stackoverflow -
http://stackoverflow.com/questions/6913332/wix-installer-problem-why-does-restartmanager-mark-service-as-rmcritical-and-no/8147540#8147540
Basically, you can
Hey Alain,
Take a look at my answer to this problem on stackoverflow -
http://stackoverflow.com/questions/6913332/wix-installer-problem-why-does-restartmanager-mark-service-as-rmcritical-and-no/8147540#8147540
Basically, you can 'lie' about the custom action and mark it as
immediate instead of de
r the problem (and hopefully
a solution)?
Alain
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: June 21, 2013 12:14
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Uninstall restart issue
I've found a number of
I've had to deal with this in the past. DIFX just unloads the driver from the
device. DIF_REMOVE is only called when removing the entire device as happens in
device manager when using the Remove option. I got around this with a CA that
sent the DIF_REMOVE directly to the device class using the
orget [mailto:afor...@cmu.edu]
Sent: June 21, 2013 11:42
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Uninstall restart issue
Blair (and anyone else interested),
You were bang on about both manually trying to launch the service to test it
and using
oing on?
Alain
-Original Message-
From: Blair Murri [mailto:os...@live.com]
Sent: June 21, 2013 04:31
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Alain,
Temporarily remove the ServiceControl\@Start and install. The
o be
Arguments="-ini "[#fileClientCommModuleJslConfig]""
Blair Murri
> From: afor...@cmu.edu
> To: jacob.hoo...@greenheck.com; wix-users@lists.sourceforge.net
> Date: Thu, 20 Jun 2013 17:09:30 -0400
> Subject: Re: [WiX-users] Uninstall restart issue
>
> Anyone out there have any id
Sent: June 19, 2013 19:12
To: 'Hoover, Jacob'; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Uninstall restart issue
I've implemented Blair's 2nd suggestion, and the services do seem to get
installed, but I don't think they&#
iles in use before
deciding that a restart is required?
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: June 19, 2013 14:10
To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Uninstall restart issue
No, a
) and their related
ServiceInstall/ServiceControl elements in a component.
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Wednesday, June 19, 2013 1:16 PM
To: Hoover, Jacob; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Un
ssage-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: June 19, 2013 14:10
To: afor...@cmu.edu; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Uninstall restart issue
No, a component can only have one key path, be it a file, directory, or
]
Sent: Wednesday, June 19, 2013 12:51 PM
To: Hoover, Jacob; 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Uninstall restart issue
Oh, I see, so if we make a Component contain multiple files, any time any one
of those files are changed, the inst
r XML toolset.
Subject: RE: [WiX-users] Uninstall restart issue
One file per component is the most flexible for maintenance, but depending on
your patching/upgrade plan it may not be needed. If the key file to the
component is a 3rd party exe (and all of your jars were within this component),
the
olset.'
Subject: Re: [WiX-users] Uninstall restart issue
You're quite right; after installing our software, there is a separate jsl.exe
process for each of our services. One disturbing thing I've noticed is that if
I then reboot the computer after installing our software, then op
08
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
I looked at the source code from the jsl website and what they are doing is
installing whichever jsl*.exe binary as the service executable (passing '-ini
' as the
jsl.exe binary into multiple target binary
files (one for each service).
Blair
> From: afor...@cmu.edu
> To: wix-users@lists.sourceforge.net
> Date: Tue, 18 Jun 2013 17:31:25 -0400
> Subject: Re: [WiX-users] Uninstall restart issue
>
> Hm, interesting. Assuming you are right and
: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Uninstall restart issue
Restart manager in your situation is probably working something like this:
Look at each component that is being removed
Look at each and every file in each of those components
Look at
Restart manager in your situation is probably working something like this:
Look at each component that is being removed
Look at each and every file in each of those components
Look at each and every process holding any of those files open?
Is that process's binary the keypath of any component tha
Can you post the entire verbose log somehere?
Phil
-Original Message-
From: Alain Forget [mailto:afor...@cmu.edu]
Sent: Saturday, June 15, 2013 11:11 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] Uninstall restart issue
I'm still wrestling with thi
That's more of a Windows Installer question. The File Versioning rules are
what's available:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa368599(v=vs.85).aspx
On Wed, Jun 5, 2013 at 12:47 AM, BGINFO4X wrote:
> Hello,
>
> Is there any way to tell WIX that when uninstalling the progr
+1 for uninstalling things in the reverse order they were in installed
-Original Message-
From: Daniel Madill [mailto:dan.mad...@quanser.com]
Sent: May 2, 2013 11:16
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Uninstall Order
Hello Nick,
In
udlow [mailto:john.ludlow...@gmail.com]
Sent: Thursday, May 02, 2013 11:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Uninstall Order [P]
It would be interesting, but I'm struggling to imagine out how the syntax would
work in your .wxs code if you were able t
Your right, and that is probably what I am going to do.
-Original Message-
From: Daniel Madill [mailto:dan.mad...@quanser.com]
Sent: Thursday, May 02, 2013 11:16 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Uninstall Order
Hello Nick,
In
Hello Nick,
In general, I find it makes sense to uninstall things in the reverse order to
which they were installed. Why not install your SQL data first? That would make
sense because then the data is present before the service runs (which I assume
is installed along with the application MSI),
>
> On Thu, May 2, 2013 at 8:25 AM, Nick Miller >wrote:
>
> > Seems to be, yes.
> >
> >
> > -Original Message-
> > From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> > Sent: Thursday, May 02, 2013 11:21 AM
> > To: General discussion for W
1 - 100 of 434 matches
Mail list logo
