microsoft / microsoft/WindowsAppSDK

App instance redirection needs to fully support command line arguments (including current working directory, ideally exit code and deferral also)

Open
#6,431 4 comments 0 reactions 0 assignees View on GitHub
area-Activation needs-triage
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.