Thanks for your kind words, I'm feeling less stupid now ;-)
Given that restart manager can still be disabled, I think it would be more
complete to expose this information to BAs in v4.0, but for WixStdBa I
changed my mind.
Kind regards,
Georg
Von: Rob Mensching [mailto:r...@firegiant.com]
Gesendet: Mittwoch, 30. April 2014 18:20
An: WiX toolset developer mailing list
Betreff: Re: [WiX-devs] Feature #4382: Add support for "files in use" in
WixStdBA
Over time you learn to trust the MSI documentation only so far. I've been
burned many a time because the documentation wasn't clear. Writing a touch
of code is often the best way to verify the doc.
Question: Do you think it is still worth it to expose whether the callback
is for restart manager in WiX v4.0?
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
<http://www.firegiant.com/> http://www.firegiant.com/
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: Wednesday, April 30, 2014 2:47 AM
To: 'WiX toolset developer mailing list'
Subject: Re: [WiX-devs] Feature #4382: Add support for "files in use" in
WixStdBA
Thanks to throw light on this. I have interpreted the docs wrong.
Let's follow the simple path you pointed out.
Kind regards,
Georg
Von: Rob Mensching [mailto:r...@firegiant.com]
Gesendet: Dienstag, 29. April 2014 19:30
An: WiX toolset developer mailing list
Betreff: Re: [WiX-devs] Feature #4382: Add support for "files in use" in
WixStdBA
Two things:
#1
Too much conjecture here so I used the test bundle code and locked the file
it tried to uninstall. Then I wrote a dirty handler OnExecuteFilesInUse that
always returned IDRETRY. This test confirmed my memory:
Returning IDRETRY from INSTALLMESSAGE_RMFILESINUSE or
INSTALLMESSAGE_FILESINUSE will cause the Windows Installer to try again with
the other one (assuming RM is enabled).
My dirty example code caused an infinite loop of INSTALLMESSAGE_RMFILESINUSE
then INSTALLMESSAGE_FILESINUSE.
That leads me to two high level thoughts:
1. I don't think the wixstdba files in use dialog should look
different for RM vs. no-RM.
2. IDRETRY is pretty screwy and if we expose it, we need to think
through the switching behavior.
#2
In your bullet point 4 below you say, "RM fails, INSTALLMESSAGE_FILESINUSE
is send". I have never seen this behavior.
In my test, when I returned IDOK for RM to do it's thing then the RM showed
a small message box and said something to the affect, "This file
path\to\file is locked. Please close all other applications and retry.
[Retry] [Cancel]". Retry would keep showing the same little message box.
Click Cancel, caused INSTALLMESSAGE_RMFILESINUSE to be called again.
In other words, I never switched to INSTALLMESSAGE_FILESINUSE unless I
returned IDRETRY.
Based on the experiments I've done I don't see any need to cache any
results. Just respond to the OnExecuteFilesInUse callback assuming restart
manager is there and avoid IDRETRY.
Maybe I'm missing something but the simple path also very much seems the
correct path.
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
<http://www.firegiant.com/> http://www.firegiant.com/
From: Georg von Kries [mailto:g...@creativbox.net]
Sent: Tuesday, April 29, 2014 3:28 AM
To: 'WiX toolset developer mailing list'
Subject: Re: [WiX-devs] Feature #4382: Add support for "files in use" in
WixStdBA
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/
------------------------------------------------------------------------------
"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
