KozaniHostRuntime implementation and FTA and protocol launch support #3714
Conversation
1. Enabled RDC launch to the foreground. 2. Hook up wil logging to trace providers 3. Added KozaniHostRuntime to KozaniManager MSIX package.
|
/azp run |
|
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
There was a problem hiding this comment.
However, if it is activated by file type association (FTA) or protocol, the command line will not contain the parameter. That's why we need additional logics to parse the manifest xml to get that info for FTA and protocol activation
Can't you query the ActivatedEventArgs to determine why KozaniHostRuntime is being activated (e.g. ActivationKind.FileTypeAssociation)?
(Any games involving "Find, Load and Parse appxmanifest.xml" is strongly discouraged for the yuuuge perf implications)
|
@DrusTheAxe , the problem is not because I can't get why KozaniHostRuntime is being activated. Of course we can get that info easily from ActivatedEventArgs. The problem is what the AUMID is for the remote app, associated with the LVP app being activated. It is encoded in the manifest of the LVP, like this: The uap10:Parameters will be passed to the KozaniHostRuntime.exe as command line parameter IF the LVP app is activated by launch contract (i.e., clicking the tile to launch it). However, if it is activated by FTA or Protocol, then the command line parameter will NOT contain the info. Instead, it will be the file path for FTA, or uri for protocol launch. That's why we need to load up the manifest to get the remote app AUMID. LVP's manifest is very small and perf hit is minimal. |
That's only true in the trivial case. The LVP isn't necessarily trivial or even generated from the remote package's manifest. There are those larger scenarios we've discussed where it gets more interesting (and complex).
Ahhh. So when the LVP app runs you need to know the associated app on the server to run? RECOMMENDATION: Use appextension. Add to the LVP's manifest where PRAID=the parent The manifest is parsed when the app's installed and AppExtension is the generic metadata mechanism with APIs working off that already parsed and optimized data. Leverage that. There are things we can do in the longer term to further optimize this in both code (Kozani, Activation and other Windows components) and data (e.g. appxmanifest.xml). Short-term this is more in line with other like efforts and while still a data contract it's slightly less of one, and more so an unambiguous one we can more readily migrate in the future. "Find, Load and Parse appxmanifest.xml" is strongly discouraged. |
|
@DrusTheAxe , I have updated the PR with the use of app extension. Please review. Thx. |
|
@howard ***@***.***>, can you take a look at my updated PR? Used app extension for remote app AUMID.
Thanks
Ruke
From: Howard Kapustein ***@***.***>
Sent: Monday, July 10, 2023 6:44 PM
To: microsoft/WindowsAppSDK ***@***.***>
Cc: Ruke Huang ***@***.***>; Author ***@***.***>
Subject: Re: [microsoft/WindowsAppSDK] KozaniHostRuntime implementation and FTA and protocol launch support (PR #3714)
The problem is what the AUMID is for the remote app, associated with the LVP app being activated. It is encoded in the manifest of the LVP, like this:
Ahhh. So when the LVP app runs you need to know the associated app on the server to run?
RECOMMENDATION: Use appextension.
Add to the LVP's manifest
<uap3:Extension Category="windows.appExtension">
<uap3:AppExtension Name="com.microsoft.kozani.localvariant.remoteapp.AUMID" Id="kozani.remoteapp.PRAID" DisplayName="Kozani RemoteApp REMOTEAUMID">
<uap3:Properties>
<RemoteApp AppUserModelId="REMOTEAUMID"/>
</>
</>
</>
where PRAID=the parent <Application>'s PRAID, AUMID=the parent <Application>'s AUMID and REMOTEAUMID=the remoteapp's AUMID. Then KozaniHostRuntime.exe can use the AppExtension API to retrieve this e.g.
aumid = GetCurrentApplicationUserModelId()
pkgfamilyname,praid = ParseApplicationUserModelId(aumid)
catalog = AppExtensionCatalog.Open("com.microsoft.kozani.localvariant.remoteapp." + aumid)
list<AppExtension> aes = co_await catalog.FindAllAsync()
IPropertySet properties = co_await aes[0].GetExtensionPropertiesAsync()
remoteaumid = ***@***.***")
The manifest is parsed when the app's installed and AppExtension is the generic metadata mechanism with APIs working off that already parsed and optimized data. Leverage that.
"Find, Load and Parse appxmanifest.xml" is strongly discouraged.
-
Reply to this email directly, view it on GitHub<#3714 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AS5OW5JRXN3PSGZ7OSNBK3DXPSVXRANCNFSM6AAAAAA2DEKOVI>.
You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>
|
There was a problem hiding this comment.
Nicely done. Only 2 Qs come to mind:
#1 Manifest extension XML
Is that doc'd? I see the comment in dev/Kozani/KozaniHostRuntime/main.cpp line 118+ which looks close (see comments there). Is that meant to doc the expected info in the manifest?
#2 E2E testing
Is there an automated E2E test for this here? Or in the Aggregator as an Integration test? Is that not possible without a remote environment?
The doc is not created yet. Right now the comments in line 118 serves the documentation.
|
|
/azp run |
|
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
…com/microsoft/WindowsAppSDK into user/rhuang-msft/KozaniHostRuntime1
|
/azp run |
|
Azure Pipelines could not run because the pipeline triggers exclude this branch/path. |
KozaniHostRuntime
**Added logics to get remote app AUMID from app extension of the Local Variant Package (LVP).
Added logics to get the configuration file paths (connection.rdp file and AdditionalSettings.txt) from LVP's app data folder.
Implemented IKozaniStatusCallback interface to handle remote app status changes. It will exit the KozaniHostRuntime process if the remote app is terminated, or the remote app activation fails, or the activation does not start a new instance (like UWPs that do not start a new app process for multiple activations).
KozaniManager
Fixed various bugs in process lifetime tracking, race condition, etc.
Moved Remote Desktop Client (RDC) launcher code to KozaniManagerRuntime.dll, which is loaded in-proc by the KozaniHostRuntime.exe to ensure RDC is launched in foreground. KozaniManager.exe is a background process with no UIs. Launching RDC by it will not guarantee the RDC login window to show up in foreground. Instead, it will be launched minimized with flashing icon at the taskbar, unless RDC itself pops up a warning dialog in the first connection to the new host. KozaniHostRuntime.exe on the other hand, has foreground privileges as it is launched by the user by activating the LVP app. Launching RDC from KozaniHostRuntime.exe will guarantee the RDC login dialog shows up in foreground.
KozaniRemoteManager
Added support for FTA and protocol launch in remote desktop server side.
Moved activation code to KozaniRemoteManagerLauncher.exe to ensure the activated apps show up in foreground. KozaniRemoteManager.exe is a background process with no UIs. Launching apps from it will not guarantee the app will have foreground. If the app activation causes a new process to be created, then the windows from the new process will show up in foreground. However, if the activation does not create a new process, then the app window will not show up in foreground. UWP apps are single instancing and once launched, subsequent activation will not create a new process. It will be problematic if the activation is done from KozaniRemoteManager.exe as if the UWP app is already running and not in foreground (e.g., minimized), the activation will not bring the app to foreground, like nothing has happened. Win32 apps have the same problem if they implement single instancing. KozaniRemoteManagerLauncher.exe on the other hand, has foreground privileges as it is launched by remote desktop shell by RAIL. It is also a new process each time it is launched by the client. Activating apps from it will guarantee the apps will show up in foreground, whether a new process is created or not.
Used IApplicationActivationManager::ActivateForFile for UWP FTA activation, IApplicationActivationManager::ActivateForProtocol for UWP protocol activation because these 2 APIs only works for UWPs. Used ShellExecuteEx for Packaged desktop apps FTA and protocol activation. Implemented registry lookup logics to find the ProgId of the FTA and protocol association for the app to be used in ShellExecuteEx.