microsoft
Proposal: Support for portable installation of applications
Proposal: Support for portable installation of applications
Summary
Having portable apps is a huge request from users who hop on different machines regularly. This enables them to install the apps once on an external drive and use it across machines and user accounts and all the app data will be available in the installed location.
VS Code offers a portable version in which you can choose to keep the extension data in the installed location and you can take those data to anywhere you want. Similarly, you can install a browser as portable and take your extensions, bookmarks and history everywhere.
Rationale
This enables:
- Install once and use everywhere.
- Take your work anywhere you go.
- Better back up of apps and their data.
- Other advantages of portable apps: https://portableapps.com/about/what_is_a_portable_app
Scope
| Capability | Priority |
|---|---|
| Sideload apps as portable apps | Must |
| Convert installed apps into portable apps | Should |
| Create portable copies of installed apps | Should |
| Convert portable apps into installed apps | Could |
| Restore portable apps into installed apps | Could |
| Auto-update portable apps | Could |
Important Notes
There already is an open standard for portable apps by portableapps.com. They have a great list of available apps and a huge user base. May be similar standard can be implemented natively in MSIX.
Open Questions
With the focus of backwards compatibility in Reunion, will there be any issues running the same app in multiple versions of windows??
Proposal: Support for portable installation of applications
Summary
Having portable apps is a huge request from users who hop on different machines regularly. This enables them to install the apps once on an external drive and use it across machines and user accounts and all the app data will be available in the installed location.
VS Code offers a portable version in which you can choose to keep the extension data in the installed location and you can take those data to anywhere you want. Similarly, you can install a browser as portable and take your extensions, bookmarks and history everywhere.
Rationale
This enables:
- Install once and use everywhere.
- Take your work anywhere you go.
- Better back up of apps and their data.
- Other advantages of portable apps: https://portableapps.com/about/what_is_a_portable_app
Scope
Capability Priority Sideload apps as portable apps Must Convert installed apps into portable apps Should Create portable copies of installed apps Should Convert portable apps into installed apps Could Restore portable apps into installed apps Could Auto-update portable apps Could
Important Notes
There already is an open standard for portable apps by portableapps.com. They have a great list of available apps and a huge user base. May be similar standard can be implemented natively in MSIX.
Open Questions
With the focus of backwards compatibility in Reunion, will there be any issues running the same app in multiple versions of windows??
you could specifically mention it for UWP apps, win32 can already do it.
you could specifically mention it for UWP apps, win32 can already do it.
Although win32 apps can do it, they have to rely on other mode of packaging, their should be unified way of installing apps as portable apps for both uwp and win32 apps and it should be implemented in MSIX.
We have the ability to install apps on other media today, but it is still related to the device it was installed on. This is something we can add to the backlog and look at in the future.
I think we could get there with app-attach work, or a similar "there's an app in this directory" model (similar to dev register, but "register this directory, validate signatures, etc."). We'd need a model where app state is also stored "next to" the package directory. Maybe apps deployed in this way don't get deep shell integration other than launch, so there's less to register/unregister. Or maybe the only thing you can do is "m:\myapps\myapp.exe" which brings up the app. Seems like there's some good stuff to explore here. :)
My 2¢: I am a user of PortableApps.com. PortableApps.com already has a detailed specification for how portable apps are to be integrated with the Windows platform. Every MSIX shell integration feature currently available is either implemented in some other way in that spec, or is simply impossible to implement correctly in a Windows app while staying fully portable. However, I don’t want to tie this issue to that specific platform, as others do exist.
With PortableApps, the app is to be installed into a different directory tree than its private data folder, which itself is in a different directory tree from the user-visible Documents directory. (Defaulting open/save dialogs to this directory is a best practice.) Failing to follow this convention puts app data at risk of being unintentionally deleted during an upgrade. There is a program called the PortableApps.com Launcher that already has ways to automatically set environment variables, including those that contain directory paths, to appropriate values before launching an app’s executable. I would always use the Launcher when I write a portable app (assuming the license is compatible; the Launcher cannot be used with commercial applications), independently of any MSIX setup. Of course, other platforms would do everything completely differently.
I would recommend simply adding some Detours code to this repo that detects when an MSIX-based program is in portable mode, and if so redirects the filesystem to (a subfolder of) the directory specified by %APPDATA% or %LOCALAPPDATA%. This would include shimming SHGetFolderPath() and the like, so the Documents folder can also be redirected. The onus is then on the app developer to use the appropriate Shell APIs to locate directories (or, in some cases, via the system-defined environment variables), and on the packager to ensure they are set to correct values. PortableApps.com already requires apps to follow conventions such as these.
When launching the app package for installation in App Installer, there could be a run once option if it detects that there's an activatable app inside the package. Maybe app packages intended to be portable can have the package writable and all the data (Local, roaming settings/files) can be written within the package so you can just take the package and all the data will be there.
