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/
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/
------------------------------------------------------------------------------
"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
