microsoft / microsoft/WindowsAppSDK
App instance redirection needs to fully support command line arguments (including current working directory, ideally exit code and deferral also)
- Dominant language
- C++
- Stars
- 4.7k
- Forks
- 471
- Avg merge
- 3d 13h
- Merged PRs (30d)
- 28
Description
I'm trying to port a single-instance UWP app to WindowsAppSDK. The app allows launching via the command line. Since command line launch is not explicitly supported with its own activated args in WindowsAppSDK, we have to use `Environment.GetCommandLineArgs()` or `ILaunchActivatedEventArgs.Arguments` get the command line arguments and `Environment.CurrentDirectory` to get the current working directory. `ILaunchActivatedEventArgs.Arguments` does work in a single app instance redirection scenario, but `Environment.CurrentDirectory` does not since it needs to be called in the original process where the command line was invoked. Also, it would be good to support deferring the exit of the command line launch and setting the exit code. Here are some possible solutions.
### Idea 1
Add a string property `CurrentDirectory` to `AppActivationArguments` which can be easily marshalled during the app instance redirection.
### Idea 2
Like idea 1 but instead allow an arbitrary data string to be set on AppActivationArguments like `UserDataString` allowing us to manually transfer the data. Could make this an object of some sort but then marshalling would be an issue presumably. Maybe a property `UserData` of type `IBuffer` would be the most general, since it needs to be serialized to bytes anyway.
### Idea 3
Properly support CommandLineActivatedEventArgs (including GetDeferral and ExitCode).
### Idea 4
In fact maybe GetDeferral and ExitCode are useful more generally in a redirection scenario, so you could go even more general and add a property like `RedirectionEventArgs` to `AppActivationArguments`. with perhaps the IBuffer from Idea 2 and maybe an ExitCode property or even a return buffer as well, and also with a `GetDeferral` method that would prevent RedirectActivationToAsync returning until completed.
--------------
Without this, I guess I am going to have to create my own memory mapped file or something to transfer some info.
PS my app is packaged so I mainly care about that scenario, but I guess unpackaged should be supported as well.
-------------
Note issue was updated to reflect below comment that command line args are actually available (but not current working directory).
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the AppActivationArguments and RedirectActivationToAsync APIs involved in app instance redirection, then trace how command-line activation data crosses from the original process. Done should include a supported way to transfer the current working directory and, if in scope, deferral and exit-code behavior for packaged and unpackaged apps.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- cli, desktop
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100