Hi all,

Until now I was having an InstallScript installer that was used only for
installing the product and uninstalling it. The update feature was
something we developed internaly and it was patching the installed
files. One of the installations file is an lsp.dll (layered service
provider) which is a dll loaded by any network application from the
machine.

VC++ gives you a different binary every time you build it because of
some timestamps. So, because of that, the lsp.dll file needed to be
patched every time even though there were no changes besides being
rebuilt. Being in use by different application at the time of patching,
it was a file in use so our updare feature was using a trick in order to
replace it and not asking for a reboot every time:
- renamed the old lsp.dll (renaming works for a file in use)
- patched a copy of this file
- put this new file as lsp.dll
The new opened application then were using teh new lsp.dll and the
application already started before the patch were using the old lsp.dll
as it was already loaded for them, but it was no problem as anyhow there
was no major change.

Now we have to switch our installer to MSI and because of the above
issues I have the following questions:
1) If I use the MSI patch, because a file is in use, it will request a
reboot correct? (I haven't tried this out but this is what I have read)
2) If yes, is there any way to delay/avoid the reboot (as I know that
the lsp.dll doesn't really need to be replaced right away as it's
changes are not major)?
3) If I can't avoid the reboot, is there any way to accomplish the same
behaviour like the one described above using MSI patches? (meaning
renaiming old lsp.dll and then copy the new one) This method should of
course not be broken if the user uninstalls the patch.
4) We could use our own update feature also if we change the installer
to an MSI, but if after an update done by us the user choses repair then
the user might end up with the previous version of the product, the one
used to install it. Is there a way to completely remove the repair
feature from a MSI? (meaning from advertising, add/remove programs,
right-click a MSI, command line, etc)

Sorry for the long post and thx in advance,
Viv

If the in-use Dll is being used by an app with a Window, MSI will prompt the
user to close the window to release the file. Also there's nothing to stop
you shutting down whatever is using the Dll. If it's a Service, MSI has
support for stopping them and restarting them, plus there's no reason you
couldn't perhaps have a custom action to close down the app using the Dll.
See this too:
http://msdn.microsoft.com/library/de...tup/reboot.asp
--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

"Viviana Vc" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi all,
>
> Until now I was having an InstallScript installer that was used only for
> installing the product and uninstalling it. The update feature was
> something we developed internaly and it was patching the installed
> files. One of the installations file is an lsp.dll (layered service
> provider) which is a dll loaded by any network application from the
> machine.
>
> VC++ gives you a different binary every time you build it because of
> some timestamps. So, because of that, the lsp.dll file needed to be
> patched every time even though there were no changes besides being
> rebuilt. Being in use by different application at the time of patching,
> it was a file in use so our updare feature was using a trick in order to
> replace it and not asking for a reboot every time:
> - renamed the old lsp.dll (renaming works for a file in use)
> - patched a copy of this file
> - put this new file as lsp.dll
> The new opened application then were using teh new lsp.dll and the
> application already started before the patch were using the old lsp.dll
> as it was already loaded for them, but it was no problem as anyhow there
> was no major change.
>
> Now we have to switch our installer to MSI and because of the above
> issues I have the following questions:
> 1) If I use the MSI patch, because a file is in use, it will request a
> reboot correct? (I haven't tried this out but this is what I have read)
> 2) If yes, is there any way to delay/avoid the reboot (as I know that
> the lsp.dll doesn't really need to be replaced right away as it's
> changes are not major)?
> 3) If I can't avoid the reboot, is there any way to accomplish the same
> behaviour like the one described above using MSI patches? (meaning
> renaiming old lsp.dll and then copy the new one) This method should of
> course not be broken if the user uninstalls the patch.
> 4) We could use our own update feature also if we change the installer
> to an MSI, but if after an update done by us the user choses repair then
> the user might end up with the previous version of the product, the one
> used to install it. Is there a way to completely remove the repair
> feature from a MSI? (meaning from advertising, add/remove programs,
> right-click a MSI, command line, etc)
>
> Sorry for the long post and thx in advance,
> Viv

Hi Phil,

Thanks for the answer. I will answer inline ...

>If the in-use Dll is being used by an app with a Window, MSI will prompt the
>user to close the window to release the file. Also there's nothing to stop
>you shutting down whatever is using the Dll. If it's a Service, MSI has
>support for stopping them and restarting them, plus there's no reason you
>couldn't perhaps have a custom action to close down the app using the Dll.

It's really not that easy. An LSP is loaded by a lot of system proceses
including for instance lsass.exe, so it's really not possible to stop
everything that helds this dll.

>See this too:
>http://msdn.microsoft.com/library/de...tup/reboot.asp

Thx! This seems to be what I need. The "Suppress" would solve my
problem. I assume it's possible to have different reboot behaviour in
the MSI full-package (here I want a reboot at the end of
(un)installation) and MSI patch (here I don't want any reboot)?

As far as I read from your book seems a lot of people are trying to find
out how repair can be disabled. Still there is no answer. I mean the one
with the empty guid for a component, it's something I wouldn't want to
do. Is there a way to disable repair per-whole-MSI-package without
having empty GUIDs?

Thank you,
Viv

There's the DISABLEADVTSHORTCUTS property. Setting that to 1 in the property
table turns off advertised shortcuts so that using a shortcut won't cause a
repair, however there are still other actions that can cause a repair.
--
Phil Wilson [MVP Windows Installer]
----
"Viviana Vc" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi Phil,
>
> Thanks for the answer. I will answer inline ...
>
>>If the in-use Dll is being used by an app with a Window, MSI will prompt
>>the
>>user to close the window to release the file. Also there's nothing to stop
>>you shutting down whatever is using the Dll. If it's a Service, MSI has
>>support for stopping them and restarting them, plus there's no reason you
>>couldn't perhaps have a custom action to close down the app using the Dll.
>
> It's really not that easy. An LSP is loaded by a lot of system proceses
> including for instance lsass.exe, so it's really not possible to stop
> everything that helds this dll.
>
>>See this too:
>>http://msdn.microsoft.com/library/de...tup/reboot.asp
>
> Thx! This seems to be what I need. The "Suppress" would solve my
> problem. I assume it's possible to have different reboot behaviour in
> the MSI full-package (here I want a reboot at the end of
> (un)installation) and MSI patch (here I don't want any reboot)?
>
> As far as I read from your book seems a lot of people are trying to find
> out how repair can be disabled. Still there is no answer. I mean the one
> with the empty guid for a component, it's something I wouldn't want to
> do. Is there a way to disable repair per-whole-MSI-package without
> having empty GUIDs?
>
> Thank you,
> Viv

Hi Phil,

Disable the adv shortcuts isn't such a good idea as this is one of the
methods that admins (as far as I read) are using for "blessing" the
package right?

Besides, as you said disabling the adv shortcuts and remove the repair
from the maintenance dialog doesn't really mean that it's completely
disabled and that the user won't be able to still repair, so basically
there is no way to disable the repair completely.

Thank you,
Viv

On Mon, 5 Dec 2005 09:50:50 -0800, "Phil Wilson"
<(E-Mail Removed)> wrote :

>There's the DISABLEADVTSHORTCUTS property. Setting that to 1 in the property
>table turns off advertised shortcuts so that using a shortcut won't cause a
>repair, however there are still other actions that can cause a repair.