Projectreunion: Proposal: Support for portable installation of applications

[soumyamahunt]

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??

[77376]

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.

[soumyamahunt]

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.

[stevewri]

@jvintzel: could MSIX support app install from a VHD on a USB stick?

[jvintzel]

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.

[stevewri]

Thanks! Moving it to the project board backlog.

[jonwis]

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. :)

[wjk]

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.