-
Notifications
You must be signed in to change notification settings - Fork 673
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Installer: Improve minor-upgrade experience #321
Comments
See answer to #322 - this should be handled in a custom bootstrapper. For my own application's bundle I have created a IsDokanInstalled method to show a warning in case an older Dokan version than the one in the bundle is detected. |
Ooooh 😢 I guess I was too naïve 😄 Maybe we can leave those issues open nonetheless? I mean, maybe some of the downstream users are willing to contribute a solution Dokan can use for its bootstrapper as well? Downstream projects can then decide whether to use the Dokan bootstrapper or to incorporate a similar mechanism into their bootstrapper. Here is what my googling found: |
They Keybase stuff searches for a fixed product code which means it finds only a very specific Dokan setup version.
|
I am sorry that I do not have any concrete suggestions here. I think this is a good issue for a downstream user of Dokan without any kernel skills to contribute to the project ;-).
Updating from one version, e.g. 1.x.x to another minor (1.y.z) or minor-minor (1.x.y) version is currently not very smooth.
Current behaviour is:
We cannot reliably replace the running Dokan driver, even if the driver supported unloading/PnP, because there might still be volumes mounted.
I am not familiar with MSI, but maybe it possible to automate this. Contributions welcome ;-)
Back from my dusty memory I remember a mechanism to exchange files during boot to avoid the Windows-problem of not being able to replace files that are in use. At least that is how it worked in Windows 9x/ME using
WININIT.EXE/INI
(there you see how outdated my knowledge is....).I think that 20 years later maybe MSI provides a transaction-safe way of accomplishing a clean upgrade i.e. automating the upgrade/reinstall making sure that everything is consistent i.e. in case of failure either the old or new version are installed and not a mish-mash of both.
The text was updated successfully, but these errors were encountered: