Overall I'm okay with just supporting restart manager. But just because I
really don't like to be forced to restart my computer, let me argue once
more for a full support of both messages. I apologize if this is annoying to
you.
I haven't tried it, but if I understand the behavior right, it's the other
way around: If restart manager is available, only
INSTALLMESSAGE_RMFILESINUSE is send and a fallback to
INSTALLMESSAGE_FILESINUSE is done e.g. if IDRETRY is returned by the former
message. This is what MSDN states:
http://msdn.microsoft.com/en-us/library/aa372466(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa816478(v=vs.85).as
px
Therefore IDRETRY for INSTALLMESSAGE_FILESINUSE would not cause a switch
between different dialogs (at least for a single MSI package). Only an
application failing to respond to a shutdown by restart manager will cause a
second files in use dialog being shown, if we support both install messages.
"Returning IDOK at this point will be the same as IDIGNORE but UI would
still indicate that it's normally closing applications automatically."
I was trying to say, that suppose we act on each call to
OnExecuteFilesInUse() and don't cache the first response of the user, the
sequence would be roughly the following:
1. INSTALLMESSAGE_RMFILESINUSE is send
2. Dialog is shown
3. Return IDOK to use restart manager
4. RM fails, INSTALLMESSAGE_FILESINUSE is send
5. The same dialog is shown again
This is of cause avoided if the return value is cached which I would suggest
anyway. I think we don't want to show files in use more than once if
possible.
I also agree that sending the messages through OnExecuteMsiMessage() again
is not a very clean solution. But the longer I think about the problem, it
might be the easiest solution without changing the IBootstrapperApplication
interface. My last thoughts about adding an additional return value to
OnExecuteFilesInUse() gets complicated with more than one MSI package.
As said, I would like to support both cases, but I think you're right and we
should support files in use with restart manager only. :-)
Kind regards
Georg
Von: Rob Mensching [mailto:r...@firegiant.com]
Gesendet: Montag, 28. April 2014 19:12
An: WiX toolset developer mailing list
Betreff: Re: [WiX-devs] Feature #4382: Add support for "files in use" in
WixStdBA
Okay, cool, we're on the same page now. A couple thoughts on what you said:
"Returning IDOK at this point will be the same as IDIGNORE but UI would
still indicate that it's normally closing applications automatically."
At best, the UI can only indicate that it will *try* to close applications.
Restart Manager isn't necessarily successful if applications don't play well
with it. IMHO, this makes it not terribly interesting to be concerned about
the UI messaging when we know we fell back to FilesInUse and won't actually
close applications. I'd go back to my suggestion of not showing IDRETRY at
all.
I also agree that FilesInUse appearances should be fading. Again, if we
don't return IDRETRY in WiX v3.x then *typically* RM will be used.
All of the above suggests to me that in WiX v3.x we shouldn't do a lot of
work to try to handle this case. Basically your Option #1. I'd show a
dialog that assumes we're using RM that doesn't not show IDRETRY that has a
UI message that correctly notes we'll *try* to close applications and
restart them (even if we don't know if that's exactly true if for some
reason RM has been disabled).
In WiX v4.0 it'd be good to expose the information simply because it might
matter to someone. However, given all of the above, I'm not sure I'd change
wixstdba in WiX v4.0.
Also, I'm not really excited about sending the files in use messages back
through OnExecuteMsiMessage(). If that's really the best option then we
should get rid of OnExecuteFilesInUse(). I'm definitely not sold on that.
Finally, it's been a while since I played with it but IIRC returning IDRETRY
from INSTALLMESSAGE_FILESINUSE will actually get you back to
INSTALLMESSAGE_RMFILESINUSE. If my memory is correct, that makes it very
interesting if you show different dialogs based on whether RM is involved.
Each time the user hits retry the dialog will change. If we want to do more
than Option #1, we'd want to verify my memory because I think it would not
be an ideal user experience to have the dialog to change on IDRETRY.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
<http://www.firegiant.com/> http://www.firegiant.com/
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: Saturday, April 26, 2014 5:00 AM
To: 'WiX toolset developer mailing list'
Subject: Re: [WiX-devs] Feature #4382: Add support for "files in use" in
WixStdBA
That's exactly what I was trying to say ;-)
With restart manager, IDRETRY is not required and is actually making things
unpredictable for the user. But without restart manager, IDRETRY is required
to make sure the user has actually closed all applications. And if I
understand the behavior correct, INSTALLMESSAGE_FILESINUSE is only send if
restart manager fails, is not available or if IDRETRY is returned by the UI.
Returning IDOK at this point will be the same as IDIGNORE but UI would still
indicate that it's normally closing applications automatically.
I think the old FilesInUse behavior without restart manager is getting more
and more deprecated, at least now after Windows XP support is dropped. But
IIRC restart manager can still be disabled e.g. by a group policy.
I have three suggestions to solve this. Tell me what you think.
1. Live without a retry button until v4.0 and try to phrase the dialog
to cover both cases
2. Let the engine also call OnExecuteMsiMessage() for
INSTALLMESSAGE_FILESINUSE and INSTALLMESSAGE_RMFILESINUSE. This way it's up
to the bootstrapper application to decide whether to use
OnExecuteFilesInUse() or OnExecuteMsiMessage(). This should also not
interfere with existing bootstrapper applications
3. Introduce another return value for OnExecuteFilesInUse() which is
interpreted as either IDOK for restart manager or IDRETRY without it. This
should not affect existing bootstrapper applications, but allows newer ones
to tell whether restart manager has failed or not (by simply determining
whether OnExecuteFilesInUse() is called more than once)
Number 3 is maybe straight forward, because return values are already
interpreted differently there (WIU_MB_OKIGNORECANCELRETRY).
Kind regards,
Georg
Von: Rob Mensching [mailto:r...@firegiant.com]
Gesendet: Freitag, 25. April 2014 17:12
An: WiX toolset developer mailing list
Betreff: Re: [WiX-devs] Feature #4382: Add support for "files in use" in
WixStdBA
First of all, thanks for looking into this feature. It'll be a great
addition.
However, maybe I'm missing something but I think you can get the behavior
you want by simply returning IDOK (to use restart manager if possible),
IDCANCEL (to abort the install) or IDIGNORE (to not bother and just take the
restart). In that scenario, no IDRETRY is required.
However, I think I understand the issue you are pointing out. The BA can't
tell when sending IDOK will be interpreted as a restart manager request and
when IDOK will be interpreted as IDIGNORE (because that's what FilesInUse
does). That's too bad because much of the code is already in place to have
passed it along. It just wasn't done. Probably my mistake a long time ago
thinking it wasn't going to be necessary.
I expect it's true but have you actually verified that returning IDOK from
FilesInUse callback does not use Restart Manager if restart manager is
supported by the MsiPackage? If that is true, then we can pretty easily fix
this in WiX v4.0 by exposing whether the OnExecuteFilesInUse BA callback was
initiated with Restart Manager support. It'll make the comments about the
different return values a bit more complex but it's really just Windows
Installer complexity that we're not hiding here. right?
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
<http://www.firegiant.com/> http://www.firegiant.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-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
