Immediate crash when trying to run as a different user

Describe the bug
App crashes during load when run as a different user than the one to whom the Terminal Services session belongs.
Steps to reproduce the bug

Install Visual Studio 2022 version 17.2.3.
Restart the computer.
On the Windows sign-in screen sign-in to User A.
Install Windows App SDK C++ VS2022 Templates extension version <IP_ADDRESS>285337.
Install the Windows App SDK Runtime version 1.1.0 x64 (WindowsAppRuntimeInstall-1.1.0-x64.exe).
Start Visual Studio.
Create a new project using the instructions at the following page: https://docs.microsoft.com/en-us/windows/apps/winui/winui3/create-your-first-winui3-app#non-msix-packaged-create-a-new-project-for-a-non-msix-packaged-c-or-c-winui-3-desktop-app

Use the Blank App, Packaged (WinUI 3 in Desktop) template.
Add <WindowsPackageType>None</WindowsPackageType> to the .vcxproj.
Modify  <AppxPackage>true</AppxPackage> to <AppxPackage>false</AppxPackage>
Run using the Unpackaged launch profile and make sure everything works.

Locate the EXE and launch it in a variety of other ways - double click in Windows Explorer, launch using full path in PowerShell, execute (F6) in WinDbg, etc. - and see that they all work.
Sign out of the TS session or lock it (🪟+L).
Back in the Windows sign-in screen sign-in to User B.
Install the same WindowsAppRuntimeInstall-1.1.0-x64.exe from above.
Launch the EXE in all the ways mentioned in section 8 and verify that they all work.
Sign out of the TS session or lock it.
Back again in the Windows sign-in screen sign-in to User A again.
From the TS session of User A run the EXE as User B in any of the following ways and note that it crashes in them all:

From Windows Explorer, hold shift and right click on the EXE, select Run as a different user,
If User A is not an administrator and User B is, right click and select Run as administrator.
Launch PowerShell/cmd as a User B and launch the EXE from there.
Run WinDbg as User B, and launch the EXE from there.

Microsoft (R) Windows Debugger Version 10.0.22621.1 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: D:\repos\App5\App5\x64\Debug\App5\App5.exe

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       SRV*D:\Symbols\Microsoft*http://msdl.microsoft.com/download/symbols
REDACTED

************* Path validation summary **************
Response                         Time (ms)     Location
REDACTED
Symbol search path is: REDACTED
Executable search path is:
ModLoad: 00007ff7`87b50000 00007ff7`87cce000   App5.exe
ModLoad: 00007ffa`e0300000 00007ffa`e0509000   ntdll.dll
ModLoad: 00007ffa`dfd20000 00007ffa`dfddd000   C:\WINDOWS\System32\KERNEL32.DLL
ModLoad: 00007ffa`dd7f0000 00007ffa`ddb69000   C:\WINDOWS\System32\KERNELBASE.dll
ModLoad: 00007ffa`dfe20000 00007ffa`e0198000   C:\WINDOWS\System32\combase.dll
ModLoad: 00007ffa`ddec0000 00007ffa`ddfd1000   C:\WINDOWS\System32\ucrtbase.dll
ModLoad: 00007ffa`9cc90000 00007ffa`9ccbb000   C:\WINDOWS\SYSTEM32\VCRUNTIME140D.dll
ModLoad: 00007ffa`df590000 00007ffa`df6b0000   C:\WINDOWS\System32\RPCRT4.dll
ModLoad: 00007ffa`6daa0000 00007ffa`6db83000   C:\WINDOWS\SYSTEM32\MSVCP140D.dll
ModLoad: 00007ffa`ded20000 00007ffa`dedf6000   C:\WINDOWS\System32\OLEAUT32.dll
ModLoad: 00007ffa`c0f30000 00007ffa`c0f3f000   C:\WINDOWS\SYSTEM32\VCRUNTIME140_1D.dll
ModLoad: 00007ffa`ddfe0000 00007ffa`de07d000   C:\WINDOWS\System32\msvcp_win.dll
ModLoad: 00007ffa`6d050000 00007ffa`6d271000   C:\WINDOWS\SYSTEM32\ucrtbased.dll
ModLoad: 00007ffa`9cb10000 00007ffa`9cb44000   D:\repos\App5\App5\x64\Debug\App5\Microsoft.WindowsAppRuntime.Bootstrap.dll
ModLoad: 00007ffa`dfb80000 00007ffa`dfd1a000   C:\WINDOWS\System32\ole32.dll
ModLoad: 00007ffa`dea80000 00007ffa`deaa9000   C:\WINDOWS\System32\GDI32.dll
ModLoad: 00007ffa`ddc30000 00007ffa`ddc56000   C:\WINDOWS\System32\win32u.dll
ModLoad: 00007ffa`de080000 00007ffa`de192000   C:\WINDOWS\System32\gdi32full.dll
ModLoad: 00007ffa`def70000 00007ffa`df11c000   C:\WINDOWS\System32\USER32.dll
ModLoad: 00007ffa`de950000 00007ffa`de9fe000   C:\WINDOWS\System32\ADVAPI32.dll
ModLoad: 00007ffa`deec0000 00007ffa`def63000   C:\WINDOWS\System32\msvcrt.dll
ModLoad: 00007ffa`e0200000 00007ffa`e029e000   C:\WINDOWS\System32\sechost.dll
ModLoad: 00007ffa`de1a0000 00007ffa`de94f000   C:\WINDOWS\System32\SHELL32.dll
(8cb0.740c): Break instruction exception - code 80000003 (first chance)
ntdll!LdrpDoDebuggerBreak+0x30:
00007ffa`e03dd114 cc              int     3
0:000> g
ModLoad: 00007ffa`dfde0000 00007ffa`dfe11000   C:\WINDOWS\System32\IMM32.DLL
ModLoad: 00007ffa`dde40000 00007ffa`ddebf000   C:\WINDOWS\System32\bcryptPrimitives.dll
D:\a\_work\1\s\BuildOutput\Release\x64\WindowsAppRuntime_DLL\WindowsAppRuntimeInsights.h(53)\Microsoft.WindowsAppRuntime.Bootstrap.dll!00007FFA9CB224DB: (caller: 00007FFA9CB1E1C6) LogHr(1) tid(740c) 8007007E The specified module could not be found.
    Msg:[Unable to load resource dll. Microsoft.WindowsAppRuntime.Insights.Resource.dll]
ModLoad: 00007ffa`dc9a0000 00007ffa`dc9b8000   C:\WINDOWS\SYSTEM32\kernel.appcore.dll
ModLoad: 00007ffa`dee00000 00007ffa`deeaf000   C:\WINDOWS\System32\clbcatq.dll
ModLoad: 00007ffa`d3250000 00007ffa`d3384000   C:\Windows\System32\AppXDeploymentClient.dll
ModLoad: 00007ffa`d3d60000 00007ffa`d3f4f000   C:\WINDOWS\SYSTEM32\urlmon.dll
ModLoad: 00007ffa`d3d30000 00007ffa`d3d58000   C:\Windows\System32\srvcli.dll
ModLoad: 00007ffa`dc440000 00007ffa`dc44c000   C:\Windows\System32\netutils.dll
ModLoad: 00007ffa`d3a70000 00007ffa`d3d23000   C:\Windows\System32\iertutil.dll
ModLoad: 00007ffa`be890000 00007ffa`be980000   C:\Windows\System32\Windows.ApplicationModel.dll
ModLoad: 00007ffa`db7b0000 00007ffa`db916000   C:\WINDOWS\SYSTEM32\wintypes.dll
D:\a\_work\1\s\dev\WindowsAppRuntime_BootstrapDLL\MddBootstrap.cpp(776)\Microsoft.WindowsAppRuntime.Bootstrap.dll!00007FFA9CB1B0D9: (caller: 00007FFA9CB19C2F) LogHr(2) tid(740c) 80040010 Object is not in any of the inplace active states
    Msg:[Bootstrap.Intitialize: Scanning packages for Major.Minor=1.1, Tag=, MinVersion=1000.516.2156.0] CallContext:[\Initialize]
ModLoad: 00007ffa`d3420000 00007ffa`d343b000   C:\WINDOWS\SYSTEM32\windows.staterepositorycore.dll
D:\a\_work\1\s\dev\WindowsAppRuntime_BootstrapDLL\MddBootstrap.cpp(865)\Microsoft.WindowsAppRuntime.Bootstrap.dll!00007FFA9CB1B85C: (caller: 00007FFA9CB19C2F) LogHr(3) tid(740c) 80040011 Not able to convert object
    Msg:[Bootstrap.Intitialize: Microsoft.WinAppRuntime.DDLM.1000.485.2229.0-x6-p3_1000.485.2229.0_x64__8wekyb3d8bbwe not applicable. Version doesn't match MinVersion criteria (Major.Minor=1.1, Tag=, MinVersion=1000.516.2156.0)] CallContext:[\Initialize]
D:\a\_work\1\s\dev\WindowsAppRuntime_BootstrapDLL\MddBootstrap.cpp(865)\Microsoft.WindowsAppRuntime.Bootstrap.dll!00007FFA9CB1B85C: (caller: 00007FFA9CB19C2F) LogHr(4) tid(740c) 80040011 Not able to convert object
    Msg:[Bootstrap.Intitialize: Microsoft.WinAppRuntime.DDLM.1000.485.2229.0-x8-p3_1000.485.2229.0_x86__8wekyb3d8bbwe not applicable.  Architecture doesn't match current architecture x64 (Major.Minor=1.1, Tag=, MinVersion=1000.516.2156.0)] CallContext:[\Initialize]
D:\a\_work\1\s\dev\WindowsAppRuntime_BootstrapDLL\MddBootstrap.cpp(908)\Microsoft.WindowsAppRuntime.Bootstrap.dll!00007FFA9CB1C486: (caller: 00007FFA9CB19C2F) LogHr(7) tid(740c) 80040013     Msg:[Bootstrap.Intitialize: Microsoft.WinAppRuntime.DDLM.1000.516.2156.0-x6_1000.516.2156.0_x64__8wekyb3d8bbwe best matches the criteria (Major.Minor=1.1, Tag=, MinVersion=1000.516.2156.0) of 118 packages scanned] CallContext:[\Initialize]
ModLoad: 00007ffa`ac030000 00007ffa`ac0fa000   C:\WINDOWS\System32\twinui.appcore.dll
ModLoad: 00007ffa`db920000 00007ffa`dc188000   C:\WINDOWS\System32\Windows.Storage.dll
ModLoad: 00007ffa`cceb0000 00007ffa`cd6c6000   C:\Windows\System32\OneCoreUAPCommonProxyStub.dll
ModLoad: 00007ffa`dec30000 00007ffa`ded1a000   C:\WINDOWS\System32\shcore.dll
ModLoad: 00007ffa`acca0000 00007ffa`acda4000   C:\WINDOWS\SYSTEM32\daxexec.dll
ModLoad: 00007ffa`dce60000 00007ffa`dce89000   C:\WINDOWS\System32\USERENV.dll
ModLoad: 00007ffa`c1ff0000 00007ffa`c2033000   C:\WINDOWS\System32\container.dll
ModLoad: 00007ffa`d84a0000 00007ffa`d84b7000   C:\WINDOWS\SYSTEM32\usermgrcli.dll
onecore\base\appmodel\execmodel\desktopappx\lib\aamextensions.cpp(332)\daxexec.dll!00007FFAACD41F38: (caller: 00007FFAACD4154D) Exception(1) tid(740c) 80070520 A specified logon session does not exist. It may already have been terminated.
    CallContext:[\TryActivateDesktopAppXApplication]
(8cb0.740c): C++ EH exception - code e06d7363 (first chance)
(8cb0.740c): C++ EH exception - code e06d7363 (first chance)
onecore\base\appmodel\execmodel\desktopappx\lib\aamextensions.cpp(113)\daxexec.dll!00007FFAACD570E1: (caller: 00007FFAACD1D3FF) ReturnHr(1) tid(740c) 80070520 A specified logon session does not exist. It may already have been terminated.
    Msg:[onecore\base\appmodel\execmodel\desktopappx\lib\aamextensions.cpp(332)\daxexec.dll!00007FFAACD41F38: (caller: 00007FFAACD4154D) Exception(1) tid(740c) 80070520 A specified logon session does not exist. It may already have been terminated.
    CallContext:[\TryActivateDesktopAppXApplication]
] CallContext:[\TryActivateDesktopAppXApplication]
onecore\base\appmodel\execmodel\desktopappx\desktoplib\desktopaamextensions.cpp(170)\daxexec.dll!00007FFAACD1D428: (caller: 00007FFAAC05C412) LogHr(1) tid(740c) 80070520 A specified logon session does not exist. It may already have been terminated.
    CallContext:[\TryActivateDesktopAppXApplication]
onecore\base\appmodel\execmodel\desktopappx\desktoplib\desktopaamextensions.cpp(203)\daxexec.dll!00007FFAACD1D5CD: (caller: 00007FFAAC05C412) ReturnHr(2) tid(740c) 80070520 A specified logon session does not exist. It may already have been terminated.
    CallContext:[\TryActivateDesktopAppXApplication]
onecoreuap\shell\twinui\activation\lib\applicationactivationmanagerproxy.cpp(90)\twinui.appcore.dll!00007FFAAC05C435: (caller: 00007FFA9CB19E34) ReturnHr(1) tid(740c) 80070520 A specified logon session does not exist. It may already have been terminated.
(8cb0.740c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.

Screenshots

NuGet package version
1.1.0
Packaging type
Unpackaged
Windows version
Windows 11 version 21H2 (22000)
IDE
Visual Studio 2022

@DrusTheAxe Are runas scenarios supported? I can repro this and a similar issue (inability to find machine-wide runtime).

@DrusTheAxe Are runas scenarios supported? I can repro this and a similar issue (inability to find machine-wide runtime).

Note that I have installed the runtime for the other user too.

Hmmm. I haven't seen the Run as another user feature before. Let me do some investigation to determine what it's actually doing.
As a general rule, you can run an app using WinAppSDK as long as the runtime is installed for that user e.g. the Microsoft.WindowsAppRuntime.1.1 MSIX package is registered for that user.
Alternatively, if the package is provisioned then it's made available to all users. At login a list of packages you should have but don't (and have but shouldn't) is built and processed, before you get to the desktop.
I doubt Run as another user is performing a full login. If it's just CreateProcessAsUser then results would depend on state of the machine and that user's profile. Will do some digging.

Hmmm. I haven't seen the Run as another user feature before. Let me do some investigation to determine what it's actually doing.

That's odd. It's been there at least since Windows XP, where it was called Run as..., and probably even before that, but my memory doesn't go that far.

As a general rule, you can run an app using WinAppSDK as long as the runtime is installed for that user e.g. the Microsoft.WindowsAppRuntime.1.1 MSIX package is registered for that user.

Right. Except it doesn't. Hence this issue.

Alternatively, if the package is provisioned then it's made available to all users. At login a list of packages you should have but don't (and have but shouldn't) is built and processed, before you get to the desktop.

That's interesting but not the situation here, since I've run the runtime installer from the second user, and when the TS session belongs to the second user the test program runs.

I doubt Run as another user is performing a full login. If it's just CreateProcessAsUser then results would depend on state of the machine and that user's profile. Will do some digging.

I don't know what that means. A call to CreateProcessAsUser requires a previous call to LogonUser or equivalent, and the flags passed to it are certainly not LOGON32_LOGON_BATCH or LOGON32_LOGON_SERVICE so that pretty much leaves only LOGON32_LOGON_INTERACTIVE.  What's a "full login"?
Anyway, again, this doesn't really matter here since, again, I have installed the runtime for the second user, being logged on to the console as the second user, so there's was no dependency on the provisioned package being auto-installed for the user.

I have updated the steps to reproduce above in hopes of making the situation more clear.

Is it relevant that this happens on a terminal session? I can see it crash when trying to run an unpackaged app from a normal desktop session as different user. It also crashes when trying to run as admin which is supposed to work with 1.1 onwards. So what is going on here?

That's just the term. I never said it was a remote session.
In the context of users and programs run by those users there are two things called "a session".
One of them is logon sessions, which represent a login for the purposes of permissions (including by a service account, or a login for SMB), are the basis for tokens, are represented by the SEP_LOGON_SESSION_REFERENCES struct and can be enumerated with LsaEnumerateLogonSessions.
The other one is Terminal Services sessions which represent a physical connection a console†, local or remote, used by Remote Desktop Services and Fast User Switching. They can be enumerated by the WTSEnumerateSessions function, where WTS stands for Windows Terminal Services. Certain information about them is published via the WM_WTSSESSION_CHANGE windows message, where again WTS stands for the same thing.
Each token is linked to a specific Terminal Services session, and while the member of the TOKEN struct that identifies the session is called simply SessionId rather than the lengthy MicrosoftWindowsTerminalServicesSessionId (as is the member of the MM_SESSION_SPACE struct etc.), WinDbg's !token command does use the term "TS session".

This term is used throughout Windows.
Here, since the processes run under different users, using different logon sessions, but in the same TS session, it was appropriate to qualify the term so as to reduce confusion. "Two processes in different logon session running in the same session" is undoubtedly worse than "two processes in different logon sessions running in the same Terminal Services session."
"Normal desktop session" isn't a thing. It's unclear and suggests the question are there abnormal desktop sessions. There's an existing term and I simply used it.

It also crashes when trying to run as admin which is supposed to work with 1.1 onwards. So what is going on here?

Programming is hard and not everyone is equally qualified or able to do it adequately.
† Except in the special case of session 0 since Windows Vista. Vista leverages the security boundary formed by TS session (in the Object Manager etc.) to separate certain system processes from user processes and protect them. That Windows XP gave the first user that logs on to the machine access to the "global namespace" it just odd and that was fixed in Vista.

In my case on a normal dekstop session, with no terminal services involved, event viewer logs the following error:
<EventData>
  <Data>Windows App Runtime</Data>
  <Data>ERROR 0x80070520: Bootstrapper initialization failed while looking for version 1.1 (MSIX package version >= 1002.543.1943.0)</Data>
</EventData>

Further investigation shows that adding <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> to the project or publishing file lets the application run successfully with a different than the logged on user.

Install the Windows App SDK Runtime version 1.1.0 x64

Does this repro with a recent servicing update (1.1.2+)? There were some fixes in 1.1.2 that may be significant here.
Is 1.1.2+ registered for the other user? Easiest way to tell is via an admin cmd prompt
powershell -c get-appxpackage -AllUsers micro*win*apprun*

and the PackageUserInformation property shows which users have the package registered e.g.
...
PackageUserInformation : {S-1-5-21-4071067175-473297690-1648030122-1003 [bob]: Installed}
...

Does this repro with a recent servicing update (1.1.2+)? There were some fixes in 1.1.2 that may be significant here.

As expected, the same crash still happens with:

Windows 11 22000.795
Visual Studio 2022 17.2.6
Windows SDK 22621
Windows App SDK C++ Templates extension <IP_ADDRESS>612342
Project NuGet packages (default):<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Microsoft.Windows.CppWinRT" version="2.0.210806.1" targetFramework="native" />
  <package id="Microsoft.Windows.ImplementationLibrary" version="1.0.211019.2" targetFramework="native" />
  <package id="Microsoft.Windows.SDK.BuildTools" version="10.0.22000.194" targetFramework="native" />
  <package id="Microsoft.WindowsAppSDK" version="1.1.2" targetFramework="native" />
</packages>

or (updated):<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Microsoft.Windows.CppWinRT" version="2.0.220608.4" targetFramework="native" />
  <package id="Microsoft.Windows.ImplementationLibrary" version="1.0.220201.1" targetFramework="native" />
  <package id="Microsoft.Windows.SDK.BuildTools" version="10.0.22621.1" targetFramework="native" />
  <package id="Microsoft.WindowsAppSDK" version="1.1.3" targetFramework="native" />
</packages>

Runtime packages:PS C:\> Get-AppxPackage -AllUsers Micro*Win*AppRun* | Select-Object PackageFullName, PackageUserInformation | fl

PackageFullName        : Microsoft.WindowsAppRuntime.1.1_1003.565.600.0_x64__8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-RIDs-1002 [SomeUsername]: Installed,
                        S-1-5-21-RIDs-1001 [SomeUsernameA]: Installed}

PackageFullName        : Microsoft.WindowsAppRuntime.1.1_1003.565.600.0_x86__8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-RIDs-1002 [SomeUsername]: Installed,
                        S-1-5-21-RIDs-1001 [SomeUsernameA]: Installed}

PackageFullName        : MicrosoftCorporationII.WinAppRuntime.Main.1.1_1003.565.600.0_x64__8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-RIDs-1002 [SomeUsername]: Installed,
                        S-1-5-21-RIDs-1001 [SomeUsernameA]: Installed}

PackageFullName        : MicrosoftCorporationII.WinAppRuntime.Singleton_1003.565.600.0_x64__8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-RIDs-1002 [SomeUsername]: Installed,
                        S-1-5-21-RIDs-1001 [SomeUsernameA]: Installed}

PackageFullName        : Microsoft.WinAppRuntime.DDLM.1003.565.600.0-x6_1003.565.600.0_x64__8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-RIDs-1002 [SomeUsername]: Installed,
                        S-1-5-21-RIDs-1001 [SomeUsernameA]: Installed}

PackageFullName        : Microsoft.WinAppRuntime.DDLM.1003.565.600.0-x8_1003.565.600.0_x86__8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-RIDs-1002 [SomeUsername]: Installed,
                        S-1-5-21-RIDs-1001 [SomeUsernameA]: Installed}

CreateLifetimeManagerViaEnumeration make the following call:
https://github.com/microsoft/WindowsAppSDK/blob/097d2209d7bd417a3936978fa6c1f4984901f42a/dev/WindowsAppRuntime_BootstrapDLL/MddBootstrap.cpp#L654
with the following values:
      lifetimeManagerApplicationUserModelId = wchar_t [130] "Microsoft.WinAppRuntime.DDLM.1003.565.600.0-x6_8wekyb3d8bbwe!DDLM"
                          packageFamilyName = "Microsoft.WinAppRuntime.DDLM.1003.565.600.0-x6_8wekyb3d8bbwe"
                            packageFullName = "Microsoft.WinAppRuntime.DDLM.1003.565.600.0-x6_1003.565.600.0_x64__8wekyb3d8bbwe"

The package indeed exists:
PS C:\> Get-AppxPackage | Where-Object -Property "PackageFullName" -EQ "Microsoft.WinAppRuntime.DDLM.1003.565.600.0-x6_1003.565.600.0_x64__8wekyb3d8bbwe" | Select-Object Name, PackageFamilyName, PackageFullName | fl

Name              : Microsoft.WinAppRuntime.DDLM.1003.565.600.0-x6
PackageFamilyName : Microsoft.WinAppRuntime.DDLM.1003.565.600.0-x6_8wekyb3d8bbwe
PackageFullName   : Microsoft.WinAppRuntime.DDLM.1003.565.600.0-x6_1003.565.600.0_x64__8wekyb3d8bbwe

And has the requested AUMID. (I'll skip dumping the manifest here.)
From there the call flow is the following:
Microsoft_WindowsAppRuntime_Bootstrap!CreateLifetimeManagerViaEnumeration;
|-- twinui_appcore!ApplicationActivationManagerProxy::ActivateApplication;
    |-- daxexec!TryActivateDesktopAppXApplication;
        |-- daxexec!EvaluateApplicationLaunch;
            |-- daxexec!GetActivationProperties;
                |-- daxexec!GetTargetUserTokenAndUserContext;
                    |-- daxexec!wil::open_current_access_token;
                    |-- usermgrcli!UMgrQueryUserContext;

daxexec!wil::open_current_access_token simply returns the process token and then usermgrcli!UMgrQueryUserContext does an RPC call that fails with error 0x80070520.
I don't see anything that was done in relation to this, which is why it makes sense that except for the version (the AUMID passed to aam->ActivateApplication) this is exactly the same flow and error as with the previous versions.
Regarding your previous comment:

I doubt Run as another user is performing a full login. If it's just CreateProcessAsUser then results would depend on state of the machine and that user's profile. Will do some digging.

runas.exe uses CreateProcessWithLogonW which does login as full as any other and is enough to run any other program I can think of and have tried.
I don't know if the fault is with Windows or the Windows App SDK, and without source code access I can't debug it any more than point the stack trace mentioned above, but even if the problem is with Windows such that everything in Windows works under such a login except for IApplicationActivationManager::ActivateApplication, maybe the newest application framework shouldn't depend on it?

I don't know if the fault is with Windows or the Windows App SDK

That'll be Windows. From your info it's pretty clear CreateProcessWithLogonW and app activation aren't intersecting in expected/desired ways, and that's Windows and its support for MSIX.
WinAppSDK provides added functionality, in some cases working around Windows to achieve equivalent ends, but only so much you can work around.
Hunting up the activation experts...
+@jsidewhite @brialmsft

daxexec!wil::open_current_access_token simply returns the process token and then usermgrcli!UMgrQueryUserContext does an RPC call that fails with error 0x80070520.

BTW 0x80070520 == ERROR_NO_SUCH_LOGON_SESSION. "A specified logon session does not exist. It may already have been terminated."
Comparing notes with the activation experts

That'll be Windows. From your info it's pretty clear CreateProcessWithLogonW and app activation aren't intersecting in expected/desired ways, and that's Windows and its support for MSIX.

Indeed seems so. The following code fails with the same error when run as a different user (and succeeds as the same user):
...
IApplicationActivationManagerPtr aam{ CLSID_ApplicationActivationManager };
DWORD pid{};
HRESULT hr = aam->ActivateApplication(L"Microsoft.WinDbg_8wekyb3d8bbwe!Microsoft.WinDbg", L"", AO_NOERRORUI | AO_NOSPLASHSCREEN, &pid);

(Same happens with AO_NONE, I used the same flags as you just to make sure.)
But:

WinAppSDK provides added functionality, in some cases working around Windows to achieve equivalent ends, but only so much you can work around.

Why is it so important to lookup and load the framework using the whole AppX/AAM thing?
What's so wrong with distributing the Windows App SDK runtime as a bunch of DLLs, installed in something like %LOCALAPPDATA%\Microsoft\WindowsAppSDKRuntime\_version_\?
Even if there's some reason to distribute as a "package" for packaged apps, why not also additionally distribute as just-a-bunch-of-files?
Is there functionality that is available to unpackaged apps that can't be implemented in a unpackaged adaptation of the framework?

Why is it so important to lookup and load the framework using the whole AppX/AAM thing?

The core problem is the Deployment stack in Windows doesn't know about unpackaged apps (not until Win11 and the new inbox Dynamic Dependencies API). Thus if you install an unpackaged app and use the bootstrapper to give a process access to the framework's content, and Deployment happens to run and decide "hey, this framework is unused because I only know about static dependencies declared in packaged apps' appxmanifest.xml and none do so let's remove the framework package". Even though your unpackaged process is running using it. Aaaand BadMojo™.
To enable unpackaged apps to use packaged goods we need to make it clear to the Deployment stack at both install-time and run-time.
At install-time we need a main package with a declared dependency on the framework package. As long as that main package is installed the framework won't get removed. WinAppSDK's Main + DDLM packages satisfy that.
At run-time we need a running process with package identity and its appxmanifest.xml to declare a <PackageDependency> on the framework package. WinAppSDK's DDLM package solves that by declaring (a) a <PackageDependency> on the framework package and (b) an application. When MddBootstrapInitialize finds a applicable framework package, it activates the app to create a process meeting a+b (pkgidentity + static dependency on the framework) to hang around until MddBootstrapShutdown (or process death). This expresses to the Deployment stack (in ways it understands!) regarding our need for the framework package not to be serviced at this time.
Lacking this 'helper' DDLM process unpackaged apps can't reliably use framework packages.

What's so wrong with distributing the Windows App SDK runtime as a bunch of DLLs

The tradeoffs of MSIX vs redistributables (i.e. SelfContained) are documented but sorry, link eludes my memory at the moment. Servicing, perf and disk footprint are some of the differences.
SelfContained has its merits but it's not without its downsides. Neither option (MSIX vs SelfContained) fully supplants the other which is why we support both :-)

The core problem is the Deployment stack in Windows doesn't know about unpackaged apps (not until Win11 and the new inbox Dynamic Dependencies API). Thus if you install an unpackaged app and use the bootstrapper to give a process access to the framework's content, and Deployment happens to run and decide "hey, this framework is unused because I only know about static dependencies declared in packaged apps' appxmanifest.xml and I see none needing this framework package so let's remove it". Even though your unpackaged process is running using it. Aaaand BadMojo™.

I don't see how that's relevant to unpackaged EXEs loading unpackaged DLLs.
Since the packaging infrastructure isn't aware of unpackaged apps, for an unpackaged app to take a reference of a package it needs to do something special, explicit, like calling TryCreatePackageDependency and AddPackageDependency.
That's great.
But why isn't that enough? Why do you call IAAM->ActivateApplication instead of just LoadLibrary?

To enable unpackaged apps to use packaged goods we need to make it clear to the Deployment stack for both install-time and run-time.
For install-time we need a main package with a declared dependency on the framework package. As long as that main package is installed the framework won't get removed. WinAppSDK's Main + DDLM packages satisfy that.
For run-time we need a running process with package identity and its appxmanifest.xml to declare a <PackageDependency> on the framework package. WinAppSDK's DDLM package solves that by declaring (a) a <PackageDependency> on the framework package and (b) an application. When MddBootstrapInitialize finds a applicable framework package, it activates the app to create a process meeting a+b (pkgidentity + static dependency on the framework) to hang around until MddBootstrapShutdown (or process death). This expresses to the Deployment stack (in ways it understands!) regarding our need for the framework package not to be serviced at this time.
Lacking this 'helper' DDLM process we'd don't get unpackaged apps reliably using framework packages.

Again, this doesn't answer the question and talks about something comepletely different.
To enable unpackaged apps to use packaged goods you need to
But I want unpackaged apps to use unpackaged goods.

The tradeoffs of MSIX vs redistributables (i.e. SelfContained) are documented but sorry, link eludes my memory at the moment. Servicing, perf and disk footprint are some of the differences.
SelfContained has its merits but it's not without its downsides. Neither option (MSIX vs SelfContained) fully supplants the other which is why we support both :-)

Once again - Self-contained distribution is not what I want. That's why I wrote that. I wrote what I meant and I meant what I wrote.
 That way it works when they're CreateProcessWithLogond.
That's possible today, but with a lot of hackery. Self-contained distribution demonstartes that it's possible, but self-contained distribution requires the bunch of DLLs to be located in the same folder as the EXE. WHICH IS NOT WHAT I WANT. I DON'T WANT TO DISTRIBUTE 60MB OF DLLS WITH MY PROGRAMS.
However, if a few calls to LoadLibraryExW are changed to use different paths and/or different LOAD_LIBRARY_XYZ flags, an unpackaged app can run without activating any packages AND without having the DLLs in the same folder as the EXE, but rather load them from a location shared with other programs.
I want the Windows App SDK to support it directly, without having to patch all those calls.
Whether or not this shared location is system-wide or user-specific I leave as an open question.
Whether or not this shared location should be the Windows App Runtime package folder (but still loaded just using LoadLibrary!) or a separate folder I leave an open question.
But regardless of how you answer these questions it is possible for an unpackaged app written using the Windows App SDK to successfully load the Windows App Runtime from a location different than the one in which the EXE is located and without doing any package activation, and then subsequently successfully run.
The problem is that is requires patching the Windows App SDK to not require the DLLs be located in the same folder as the EXE. Please remove this requirement. This solves the runas issue.

You touch on some complex issues.  And you don't need it AND you don't need the Bootstrapper with its related plumbing...if you only run on Win11.
Hmmm. That may not be well documented. I'll follow up on that.
It's actually quite simple (solution #1):

build your app with <WindowsAppSdkBootstrapInitialize>false</WindowsAppSdkBootstrapInitialize>
install the WinAppSDK runtime's MSIX packages
call Windows' Dynamic Dependencies APIs (AddPackageDependency to dynamically use WinAppSDK's framework package in your app

The limitation is Windows' Dynamic Dependencies APIs require Win11. That's a problem if your app runs on Win10.
The alternative (solution #2)...

build your app with <WindowsAppSdkBootstrapInitialize>false</WindowsAppSdkBootstrapInitialize>
In your app, before using any WinAppSDK features, call...
** SetEnvironmentVariable(L"MICROSOFT_WINDOWSAPPRUNTIME_DDLM_ALGORITHM", L"1") ** MddBootstrapInitialize2(...)`

The limitation is this requires Windows >= 20H1 (it requires Windows' behavior not available on RS5 or 19H1).
WinAppSDK's bootstrap solution needs a process running with the identity of a main package that manifests a static dependency on WinAppSDK's framework package. There's a couple of ways to accomplish that:

Packaged COM OOP server in Microsoft.WindowsAppRuntime.Main package
Packaged app in Microsoft.WindowsAppRuntime.Main package

WinAppSDK 1.0 did #1 but Packaged COM isn't supported1 in elevated processes on older systems (<Win11) so WinAppSDK 1.1 added #2. The decision which to use is made in IsLifetimeManagerViaEnumeration() in dev/WindowsAppRuntime_BootstrapDLL/MddBootstrap.cpp line 541. The code refers to these as 'AppExtension' and 'Enumeration'. The decision logic:

Windows <20H1? Use 'Enumeration' (older systems lack features required by 'AppExtension')
MICROSOFT_WINDOWSAPPRUNTIME_DDLM_ALGORITHM environment variable =0 ('Enumeration') or 1 ('AppExtension') Use what it says
Process' is not running in an AppContainer? Use 'Enumeration'
We're in an AppContainer on >=20H1 and the envvar isn't set. Use 'AppExtension'

The limitations are (a) this requires Windows >= 20H1 and (b) doesn't support elevation if the servicing update isn't present.
1 Well, Packaged COM wasn't supported on <Win11. A Windows servicing update released recently (June?) addressed that. If a downlevel system has that update Packaged COM works for elevated processes.
I'll make a separate post regarding the other issues you raised and why this works the way it does.

The problem is that is requires patching the Windows App SDK

It's a little more complicated than that. The problem here is...

an unpackaged app using WinAppSDK as an MSIX package requires something so Deployment knows not to service the package out from under running processes AND not to remove the seemingly unused WinAppSDK package
WinAppSDK's Dynamic Dependencies does that with a helper process so Windows understands not to service the package out from under running processes
there's limited ways to create that helper process with the right properties

I don't see how that's relevant to unpackaged EXEs loading unpackaged DLLs.

It's not. That's why WindowsAppSDKSelfContained=true doesn't involve the Bootstrapper or Dynamic Dependencies, as WinAppSDK isn't in an MSIX package.

it is possible...without doing any package activation, and then subsequently successfully run.

Absolutely. Just use the Windows Dynamic Dependencies APIs instead of the Bootstrapper (which under the covers uses WinAppSDK's Dynamic Dependencies APIs).
We have 2 implementations of Dynamic Dependencies. Windows' implementation makes changes across Windows to support dynamic dependencies. WinAppSDK's implementation uses Windows in perfectly valid (if uncommon) ways to reliably produce the same net effect, without changes in Windows.

 The activation plumbing is an implementation detail, but our options are limited (see previous post)
The (long-standing) limitation was unpackaged apps cannot use packaged goods. Not until Dynamic Dependencies came along i.e. Win11. Technically, yes, a process can LoadLibrary(absolutepath) to a DLL in an MSIX package...but the Deployment stack doesn't know about that relationship. Deployment will think on one's using that package and is free to service it as necessary, up to and including removing the package from the system!
Servicing is the key. WinAppSDK's Dynamic Dependencies is all about giving unpackaged apps access to packaged goods in reliable ways Windows can understand. The Bootstrapper is just a specialized use of Dynamic Dependencies, to enable dynamic use of WinAppSDK (chicken/egg problem: DynDep API's in the framework package, how do you call it to use the framework package when you can't yet access the framework package... The Bootstrap API!).

Whether or not this shared location...

The problem is servicing. How do we get the necessary bits distributed, deployed (install, update etc) and reliably managed? That's not as easy as it sounds (well, assuming it even sounds easy :P). MSIX provides a strong solution here.
It's just <sic> a matter of balancing the requirements with the technical limitations.

But why isn't that enough? Why do you call IAAM->ActivateApplication instead of just LoadLibrary?

TL;DR because changing previously released versions of Windows (aka 'downlevel') isn't viable, so we trick existing Windows to work the way we need.
Deployment only understood 'static' dependencies
The Deployment stack in Windows knows not to service a package in use. HOW it knows is the key.
Deployment determines a package is in use if 1+ running process with package identity has the package in its package graph. For instance, if the calculator app in the Microsoft.WindowsCalculator package has a dependency on VCLibs then when you run the Calculator its package graph is [Calculator, VCLibs]. When running the app's process has a package identity in its process token (e.g. Microsoft.WindowsCalculator_10.2103.8.0_x64__8wekyb3d8bbwe) so the Deployment stack knows to connect the dots to recognize that package and its dependencies are in use and not to do things that would break the running process (don't service the Calculator package, don't remove that VCLibs package, etc).
Deployment knows the process' package graph because it computed the package graph when the package was registered for the user. Calculator's appxmanifest.xml declares
<PackageDependency Name="Microsoft.VCLibs.140.00" MinVersion="14.0.29231.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"/>

When the Calculator package was registered for the user Deployment resolves this dependency to a specific package (version>=minversion, a compatible ProcessorArchitecture, etc) and saves the resolved package graph. During later Deployment operations Deployment checks resolved static package dependencies to determine if we're being asked to service a package that's in use and if so, don't proceed.2
2It's a little more involved (e.g. if the Force option's specified Deployment may terminate processes) but not significant for this discussion.
Notice the word 'static'. The package graph is resolved at install-time based on static manifested dependencies. Deployment had no concept of processes using packages without a static dependency.
Until Win11.
Win11 taught Windows to understand 'dynamic' dependencies
Dynamic Dependencies introduced in Win11 didn't just add some API functions. We also changed Windows - changed the Deployment stack - to know about packages in use dynamically.
That's why AddPackageDependency() has no mention of a 'bootstrapping' or helper processes -- we just changed Windows to understand this behavior.
That's great -- if you write apps that only work on >=Win11.
Lots of developers need to run on older (<Win11) systems. Windows App SDK supports Windows down to RS5. The question is how to accomplish that.
Backport Win11's dynamic dependencies?
One option is to service Windows. We could have backported Windows' Dynamic Dependencies work to older systems. But that's problematic for multiple reasons including

The changes weren't minor and thus risk
Users (especially enterprises) generally dislike feature changes to existing working systems
Many developers dislike patch-dependent features ("My app works on version X, but only if you have patch Y installed...")

Make WinAppSDK work in ways Win10 understands
The alternative is to do things in ways downlevel Windows understands producing equivalent results. And thus, the bootstrapper and helper process. WinAppSDK refers to this as "polyfill" -- leverage Windows functionality where we can, and supplement with our own implementation where necessary. See Version support.
Future?
This leads to the obvious question, "Why not make WinAppSDK's Dynamic Dependencies use Windows' APIs on Win11 and only do the polyfill on Win10?" That's always been the long-term goal1 we just haven't done that (yet). This won't help apps on Win10 so we've been focusing on some higher priority work (e.g. elevation).
1 You may have noticed WinAppSDK's Dynamic Dependencies API is verrrry similar to Win11's, almost as if they were designed that way... ;-) That's not an accident.

 The activation plumbing is an implementation detail, but our options are limited.
The (long-standing) limitation is unpackaged apps cannot use packaged goods. Not until Dynamic Dependencies came long i.e. Win11. Technically, yes, a process can LoadLibrary(absolutepath) to a DLL in an MSIX package...but the Deployment stack doesn't know about that relationship. Deployment will think on one's using that package and is free to service it as necessary, up to and including removing the package.
Servicing is the key. WinAppSDK's Dynamic Dependencies is all about giving unpackaged apps access to packaged goods and doing so reliably in ways Windows can understand (or at least well enough not to break apps). The Bootstrapper is just a specialized (but necessary) use of Dynamic Dependencies to to enable dynamic use of WinAppSDK.

Whether or not this shared location...

The problem is servicing. How do we get the necessary bits distributed, deployed (install, update etc) and reliably managed? That's not as easy as it sounds (well, assuming it even sounds easy :P).
MSIX provides a strong solution here.
'Run as different user' brings some unusual details to the equation. I'm investigating other options but nothing yet. As you may have guessed, navigating Windows behavior to achieve the desired result is a bit tricky.

@DrusTheAxe, I read your post a few times and I've also read a bunch of other issues and discussion under this project that deal with related problems and I couldn't find an answer to my question. Maybe it's my fault for broadening the issue.
So I'll leave this issue for the specific problem of runas and I'll ping once again the people you mentioned earlier (@jsidewhite @brialmsft @dhoehna) to see if they have something to share that would help here.
I may later open a separate issue for the broader matter, but before that I'd like to try one more time here, since this issue already exists and there's some history here.

I am asking that the Windows App SDK (i.e. the VSIX, NuGet package etc.), without modifying the Windows App Runtime in any way, allow completely unpackaged applications (i.e. not even using sparse packages, just "plain old Win32 applications") to use, without using any "package APIs" or relying on any other OS mechanism that doesn't support the runas scenario, the Windows App Runtime that is already present on a system rather than only a copy of the Windows App Runtime that's located in the same folder as the EXE of those applications.
Are you saying this this is impossible or is there any other reason why this feature can't find itself in the next point release of the SDK?

without using any "package APIs" or relying on any other OS mechanism that doesn't support the runas scenario, the Windows App Runtime that is already present on a system rather than only a copy of the Windows App Runtime that's located in the same folder as the EXE of those applications.

So to summarize, you're asking for a solution that (1) enables unpackaged apps to use WinAppSDK (2) that's compatible with runas and (3) doesn't involve any app-local copy (i.e. not WinAppSDK/SelfContained) and (4) doesn't involve MSIX if MSIX doesn't support runas ?
And constraint #4 is no MSIX -if- MSIX doesn't support runas, but MSIX is OK if it does support runas? That runas without the app having its own private copy of WinAppSDK is the goal?
BTW are there Windows version constraints on your runas scenario? If, say, it worked on Win11 but not Win10 would that meet your needs? If it worked down to 20H1? If it worked on Desktop but not Server? If... Please elaborate.

So to summarize, you're asking for a solution that (1) enables unpackaged apps to use WinAppSDK (2) that's compatible with runas and (3) doesn't involve any app-local copy (i.e. not WinAppSDK/SelfContained) and (4) doesn't involve MSIX if MSIX doesn't support runas ?
And constraint #4 is no MSIX -if- MSIX doesn't support runas, but MSIX is OK if it does support runas?

What do you mean by "involve MSIX"?
If you're talking about the application - I think that's precluded by the requirement for the app being unpackaged.
If you mean the runtime - for the purposes of this issue† I don't mind it being distributed as an MSIX. If you think that non-MSIX runtime is the preferred solution I have no objections, but that is not the requirement here. However it is implemented is fine by me and there are ways that work with the current runtime distributions, which is MSIX-based.

That runas without the app having its own private copy of WinAppSDK is the goal?
Yes, exactly. Private copies have obvious disadvantages. The most important two for me are size and updates.

BTW are there Windows version constraints on your runas scenario? If, say, it worked on Win11 but not Win10 would that meet your needs? If it worked down to 20H1? If it worked on Desktop but not Server? If... Please elaborate.

That's a somewhat complicated question to answer but the short answer is:
We need to support Server SKUs and we need to support builds starting with 17763.
Luckily that's the version you were supposed to support in the first place and the website and documentation still say that.
My investigation show that it can work on Windows 10 1809 - I'm sure that it works on 17763.1577 and as far as I recall it works on 17763.107 - and I see no reason why the same shouldn't work on Server SKUs too.
The slightly longer answer is that our customers have 17 times more Server 2019 instances than Server 2022 instances. Obviously it would be better to also support Server 2016, but that ship has sailed. Assuming we can find a way to live with that (e.g. maintain two versions until pre-2019 goes away, use WASDK only for certain elements that would be offered only starting with 2019 etc.) 2019 is the bare minimum. If 2019 isn't supported that means nothing is.
† I think there are advantages to also distributing the runtime in an unpackaged form, but spreading too much here was probably wrong of me. In time I hope to address that in a separate issue or discussion, unless you convince yourself that a non-MSIX runtime is desirable before I get the chance.

So I'll leave this issue for the specific problem of runas

> MSIX - Does Not Support "INSTALL FOR ALL USERS" and by extension "RUN AS ANOTHER USER".
>> Since WindowsAppSDK uses MSIX based runtime, you simply can't leverage WindowsAppSDK features for "ALL USERS on the SAME MACHINE" in your Apps until  MSIX limitations are fixed in the OS. Simple as that.
>>> Any attempt to support "ALL USERS" will essentially result in ditching MSIX in its current form.
>>>> See below
{

https://github.com/microsoft/WindowsAppSDK/issues/13 and
https://techcommunity.microsoft.com/t5/msix-feedback/machine-wide-provisioning-install-for-all-users/idi-p/1781716

No, "Machine Wide Provisioning" does not count as it still registers/installs the app per User basis which is essentially "single user installation".
}

What do you mean by "involve MSIX"? ...I don't mind it being distributed as an MSIX. If you think that non-MSIX runtime is the preferred solution I have no objections, but that is not the requirement here. However it is implemented is fine by me and there are ways that work with the current runtime distributions, which is MSIX-based.

Yes, that's what I meant. Thank you for the detailed response.

That runas without the app having its own private copy of WinAppSDK is the goal?
Yes, exactly. Private copies have obvious disadvantages. The most important two for me are size and updates.

Very true. The MSIX (framework-dependent) solution is recommended in this case.
There are OS limitations in runas+MSIX support causing the problem here. That's the heart of the issue and unfortunately I haven't been able to find a creative workaround.
For the OS limitation, please use FeedbackHub to submit your feedback about the issue to get it on the appropriate OS teams' radar.
+@mikebattista @MikeHillberg @kanismohammed as FYI

My investigation show that it can work on Windows 10 1809 - I'm sure that it works on 17763.1577 and as far as I recall it works on 17763.107 - and I see no reason why the same shouldn't work on Server SKUs too.

Server is similar to Desktop but can have variances due to release schedules, the underlying codebase/builds used for a release, servicing updates, system definition and configuration, conditional code in Windows binaries themselves (e.g. if (IsServer()) {...} or IsDesktop() etc) and other factors. So while you might assume they're equivalent and often be right, that's not always the case. Very much a devil's in the details question.

I think there are advantages to also distributing the runtime in an unpackaged form, but spreading too much here was probably wrong of me. In time I hope to address that in a separate issue or discussion, unless you convince yourself that a non-MSIX runtime is desirable before I get the chance.

Doubtful ;-) Aside from the obvious but surmountable issues (technical and non-technical) the hard nut is servicing. How do you update such a thing -- Distribute how? Apply the update when it's in use? Minimize disk space impact? Among other factors. "Install" something is easy (relatively speaking), it's "Update" that's hard. MSIX solves these issues.
Inventing a new solution is a non-trivial undertaking, and an ongoing tax of splintered redundant efforts (there's only so many devs and hours to go around). If MSIX has issues it's likely more sensible (and justifiable :-)) to address them than invent a new redundant divergent solution.

There are OS limitations in runas+MSIX support causing the problem here. That's the heart of the issue and unfortunately I haven't been able to find a creative workaround.
For the OS limitation, please use FeedbackHub to submit your feedback about the issue to get it on the appropriate OS teams' radar.

An omission on my part, since it was obvious to me and I forgot to specify it explicitly: I am not interested in anything that depends, requires or otherwise entails operating system updates.
Whatever operating system we support, Windows 1w version 2xyz for any w, x, y, z, we need to support it starting from the "RTM" (i.e. for every build the first UBR that was publicly released rather than only as Insider).
"We support Windows 10 20H2, but only if you have the October 11, 2022 update" is just as useless as "we support only Windows 11 build 25xyz" to me.
My machine is always updates but my customers' machine aren't necessarily, and it is on their machines I need to run. Their reasons may be poor but that's irrelevant. Judging their decisions on this issue is not what they're paying me for.
Again I remind that since it was called "Project Reunion" till this very day the Windows App SDK promised and promises "downlevel support" and "not relying on operating system servicing/updates" (paraphrases). If any bug is resolved with an OS update we're back to UWP. Again, one of the main supposed benefits of WASDK over UWP was supposedly its independence of OS updates.

Server is similar to Desktop but can have variances due to release schedules, the underlying codebase/builds used for a release, servicing updates, system definition and configuration, conditional code in Windows binaries themselves (e.g. if (IsServer()) {...} or IsDesktop() etc) and other factors. So while you might assume they're equivalent and often be right, that's not always the case. Very much a devil's in the details question.

In principle, generally, that's true. In practice, regarding the specific workaround I tried, I don't believe there's a dependency on workstation-specific behavior, but that's why I was careful and said that I've tested down to 1809 but haven't tested on Server yet. If any when I will get to operationalizing it from the "less than PoC" state it is now I will of course test it on Servers too.

I can confirm this issue still happens under:

App Sdk 1.4.5 and 1.5.0
Windows 10
.NET 6 and 8

@conioh I believe you can rename the issue to
"MSIX: Support Running As Different Users and also Support 'Over The Shoulder' Elevations."
because that's basically what it is.
those two features needs to get worked on the Windows OS itself because they both are OS level feature.


submodules

wondering if it makes sense to keep external projects like AdminLTE as submodules rather than pulling in the code into our project? not a prio, just capturing the thought for later.

This probably would be a good thing to do. Currently it is not a high priority, so good that you are capturing it for later.


[Segment] "stacked format" and "loading" is not compatible

Steps

Test

Version
2.4.2
Testcase
http://jsfiddle.net/tjnkp3rg/

We added fitted segment to upcoming Fomantic-UI 2.7.5 by https://github.com/fomantic/Fomantic-UI/pull/702
Using that will make it possible to use a workaround by wrapping your stacked segment around a basic fitted loading segment
See https://jsfiddle.net/5Ledzbuw/
Why it is otherwise not possible to do, i explained here


Error when training WMT with multi gpu

Hi!
my setup:

ubuntu 22.04

Python 3.10

Torch 2.3.1

eole 0.0.2
I was trying to follow the wmt17 en-de recipe, in multi-gpu (2 gpus - world size: 2; gpu_ranks:[0,1]):, but I got the following error when running eole train command:

Traceback (most recent call last):
  File "/mnt/nfs/NMT/eole/eole/utils/distributed_workers.py", line 48, in spawned_train
    process_fn(config, device_id=device_id)
  File "/mnt/nfs/NMT/eole/eole/train_single.py", line 242, in main
    trainer.train(
  File "/mnt/nfs/NMT/eole/eole/trainer.py", line 337, in train
    eole.utils.distributed.all_gather_list(normalization)
AttributeError: module 'eole.utils' has no attribute 'distributed'

    self._shutdown_workers()
  File "/mnt/nfs/NMT/venv_eole_gpu4/lib/python3.10/site-packages/torch/utils/data/dataloader.py", line 1443, in _shutdown_workers
    w.join(timeout=_utils.MP_STATUS_CHECK_INTERVAL)
  File "/usr/lib/python3.10/multiprocessing/process.py", line 149, in join
    res = self._popen.wait(timeout)
  File "/usr/lib/python3.10/multiprocessing/popen_fork.py", line 40, in wait
    if not wait([self.sentinel], timeout):
  File "/usr/lib/python3.10/multiprocessing/connection.py", line 931, in wait
    ready = selector.select(timeout)
  File "/usr/lib/python3.10/selectors.py", line 416, in select
    fd_event_list = self._selector.poll(timeout)
KeyboardInterrupt:
Process SpawnProcess-1:
Traceback (most recent call last):
  File "/usr/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap
    self.run()
  File "/usr/lib/python3.10/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)

solved it adding the import (from eole.utils import distributed)
to trainer.py
Hope it helps,
cheers!

Thanks for the report!
It seems this issue was introduced in #116 which removed some explicit imports that hid the wonky behaviour.
Would you mind opening a quick PR with your fix? Thanks!

Will do! thanks for the quick response!


bug: ubuntu 23.04 is not a lts version

Under 'Supported distributions'
it says ubuntu 23.04 is a lts version, but it is not
ref:
https://ubuntu.com/about/release-cycle

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 80707602-f283-e796-d3b8-3287fbc011dc
Version Independent ID: 1d732b15-9e64-633a-000c-ad96d9d3818a
Content: .NET and Ubuntu overview - .NET
Content Source: docs/core/install/linux-ubuntu.md
Product: .net
Technology: dotnet-installation
GitHub Login: @adegeo
Microsoft Alias: adegeo

Thank you for reporting this.


Remove Microsoft Edge Is Not Removing Anything

I tried several times but still nothing was deleted

The maintainer is aware of this and is currently thinking of a solution. This could be fixing it or removing it entirely. Please keep this open and as soon as a release is done to fix this. I will link it here.

@Real-MullaC
Still no updates?

the original creator @AveYo doesnt seem to be active anymore however ive fixed the edge removal script in this pr
https://github.com/AveYo/fox/pull/51

Hi, @zoicware
Thank you a lot, that script works for me.


Maybe too narrow on Firefox

It could be this needs some inquiry but I think on Firefox (68.0.2 MacOS) the fiels are too narrow.
Other browser do work fine.

Thanks for the report! I'll try and have a look this week.

Hi! This should be fixed in c36118e - released as v1.0.6


Data Driven Testing: Fixing arguments for template keywords

I'm running to a situation where I have multiple scenarios which correspond to just 1 workflow. In each scenarios, there are some arguments have fixed value (say a customer have debt, or not), and some arguments varies.
In robotframework, is there anyway we can fixed some input arguments for some test cases, and reuse the same template keyword? In this way we can just use 1 workflow keyword (with all arguments), but in test data, we have to input only a few arguments (instead of key in duplicated data for all fixed arguments in a specific scenario).

is this what you are looking for? http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#default-values-with-user-keywords

Yeah, default values for arguments ought to work in this use case. Notice that robotframework-users mailing list or other similar forums are better places to ask question than this issue tracker.


Add logback configuration files used by Tango java applications

Checklist

[X] Used a personal fork of the feedstock to propose changes
[X] Bumped the build number (if the version is unchanged)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[X] Ensured the license file is being packaged.

I'm looking at packaging atk-panel and atk-tuning and noticed that those applications require a logback.xml configuration file for logging.
I think it makes sense to put those files in the jtango conda package as all java applications will have it as dependency.
I took those files from the TangoSourceDistribution.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

@bourtemb I'd appreciate your input on this.

Maybe @gwen-soleil could confirm that these logback files are suitable for most of the users using JTango?

@conda-forge-admin, please rerender


verbose flag + clean up temp files on S3

Cool little utility!

Could a verbose flag be added so print is only called if verbose=true?
How to delete temp files on S3 used for pandas_to_redshift?  close_up_shop() should delete this temp S3 files

What about removing the s3 files in the 2nd point? Do you think that's something you'd add?


fix player unicode name decoding exception while writing log

Issue:

UnicodeEncodeError exception occurred while writing to log file with CP950 encoding that mentioned in #122 , #128

Fix:

Open log file with utf-8 encoding

No error found in my log file but the dropdown still not showing players

log.txt
Level.zip

No error found in my log file but the dropdown still not showing players  log.txt Level.zip

I managed to see players who's giving conflict in the save file. There are symbols in the name.

should be closed as finished https://github.com/EternalWraith/PalEdit/pull/129/commits/bd2b4ea739b9be05b05028cc98d6e101a564fe69

merge in #129


Upgraded to pixi v8

Upgraded to pixi v8

@davidfig

@davidfig

wait why did it close, i did not mean to

i dont get git

It says you forced pushed from main into your own main branch 3 days ago- this means that your changes got overwritten from main and there's no longer anything to merge, so the PR got closed.
I think what you mean to do here is target your v8 branch into the remote main branch.

If you change this PR from your 'main' branch to your 'v8' branch that should get you what you want.


Display the Hybrid heat pump as one entity in front-end

RIght now the Hybrid heat pump is split up into two pieces. We would like to display it as one technology. The thing is, I know how this would work in the front-end. However, I have no idea what the damages will be during the calculation (I guess, it would be significant).
Current situation
Front-end -> Calculator:
HHP (e) -> HHP (e)
HHP (g) -> HHP (g)

Front-end -> Calculator
HHP -> HHP (e)
    -> HHP (g)

Things that need to be edited:

[x] Import needs to change to a single HHP
[x] Split the HHP when calculating

This would definitely be nice. Perhaps it could be handled similarly to base loads, where a single front-end technology is split into two separate parts before being handed off to the calculation?
The complicating factor in this case is that the two parts use different carriers. This means that technology_component_behavior would likely need to become something more detailed:
behavior: hhp

components:
  electric:
    behavior: hhp_electricity
    carrier: electricity
    position_relative_to_buffer: buffering
  gas:
    behavior: hhp_gas
    carrier: gas
    position_relative_to_buffer: boosting

# etc...

... where each "component" would inherit the attributes of the main technology.

I'm having multiple questions stating from the content that's in the separate parts of the hybrid heat pumps:
Summarized content of the Hybrids that spawn questions (I filterd out all the obvious things):
---
carrier: hybrid
color: "#57A753"
behavior: buffer
visible: false

Content of the electricity part:
---
behavior: hhp_electricity
carrier: electricity
color: "#9ED2A1"
defaults:
  capacity: 4.9
  initial_investment: 3235.0
  om_costs_per_year: 96.7
  performance_coefficient: 4.5
  position_relative_to_buffer: buffering
  technical_lifetime: 15

expandable: false
export_to: households_space_heater_hybrid_heatpump_air_water_electricity_share

Content of the gas part:
---
behavior: hhp_gas
carrier: gas
color: "#80C37D"
defaults:
  capacity: 22.0
  initial_investment: 1500.0
  om_costs_per_year: 156.2
  performance_coefficient: 1.067
  position_relative_to_buffer: boosting
  technical_lifetime: 15

A few things I see missing are the color, export_to. Could we also add those to the components or wouldn't that make any sense?
Also the defaults, what do we need to do with those, if we're going to merge them both? @ChaelKruip or are the defaults based of the things that we extract from the main hybrid heat pump from ETEngine?

What are we going to do with the color attributes, and the export_to for the electricity part. Could we also add those to the components or wouldn't that make any sense?

I suppose we could. I understand your concern, especially with the defaults; costs and lifetime would be shared between both components, but the capacity, performance coefficient, and "position relative to buffer" are different for each component. This does feel a bit inelegant.
I wish I had a better idea to offer. 😧

Couldn't we keep the information concerning defaults in both components and associate the components from the hybrid heat pump.
---
carrier: hybrid
color: "#57A753"
behavior: hhp

components:
  - electric
  - gas

In Technology:
class Technology
  ...
  def components
    attributes[:components].map do |part|
      Technology.find_by_key("#{ key }_#{ part }")
    end
  end
  ...
end

And in Network::Technologies
def self.from_installed(installed, profile, options = {})
    # expand the hybrid heat pump in two technologies?
end

This would take some changes to the calculator I guess but I don't know how hard that'd be. The only issue I see here is that you can't really simply edit the costs of a single component of the Hybrid heat pump or the capacity for that matter.

Couldn't we keep the information concerning defaults in both components and associate the components from the hybrid heat pump.

I like that. But could we do without the magic name, and perhaps just specify the full keys like this?
components:
  - households_water_heater_hybrid_heatpump_air_water_electricity_electricity
  - households_water_heater_hybrid_heatpump_air_water_electricity_gas

The only issue I see here is that you can't really simply edit the costs of a single component of the Hybrid heat pump or the capacity for that matter.

That is also a good point. There would need to a form template specific to the HHPs which would allow you to edit these. I guess each form element would have to specify which component it relates to:
// Pseudo code.

// Sets capacity on the electric component
%input(type="text" name="capacity" data-component="households_..._electricity")

// Sets capacity on the gas component
%input(type="text" name="capacity" data-component="households_..._gas")

// Sets capacity on all components
%input(type="text" name="capacity" data-component="all")

I imagine this is quite a bit of work.

This would take some changes to the calculator I guess but I don't know how hard that'd be.

It would be nice if this could be handled before the calculator, by hooking into something like InstalledTechnology#each_profile_curve. Perhaps the time has come to replace that with something bigger, like InstalledTechnology#network_components. This would return an array of InstalledTechnology instances for use in the calculation. A "normal" technology would just return itself:
def network_components
  [self]
end

A technology with split profiles (base loads) would return two components: one for the inflexible component and one for the flexible:
def network_components
  profile_curve.each_pair.map { ... }
end

While the heat pumps would have to do something else:
def network_components
  components.map do |key|
    attributes = component_attributes(key) # Determines the attributes for the component
    InstalledTechnology.new(attributes.merge(type: key))
  end
end

If that's not possible, we can look into making the calculator do it; but it would be preferable to not have to give it that responsibility.

But could we do without the magic name, and perhaps just specify the full keys like this?

Yes

I imagine this is quite a bit of work.

Well, yes. You'd have to start saving the data like:
{
  name: "HHP",
  components: {
    electricity: { capacity: 1.0 },
    gas: { capacity: 1.0 }
  }
}

So this takes changes in the way the data is parsed. Also this puts extra pressure on the technology_profile field. I haven't seen any LES going out of bounds when it comes to size but this might.
To prevent this we might, Uglify the data before it goes into the database (with the 26 variables for busy developers) and than Beautify when we access the charts again. However, this is a bit of a nice to have.

but it would be preferable to not have to give it that responsibility.

I agree 👍

I guess each form element would have to specify which component it relates to:

Must it be possible to define a capacity for the HHP, the electricity part of the HHP and the gas part of the HHP? Or is it ok, to just do it for the electricity part of the HHP and the gas part of the HHP, considering both pieces as one of a whole. Or am I misunderstanding the behavior of the HHP, this way?

Or is it ok, to just do it for the electricity part of the HHP and the gas part of the HHP, considering both pieces as one of a whole.

Only this. The HHP as a whole does not have a capacity. Only the parts.

The hybrid heat pump looks like this in the front-end. As far as I understood it from @ChaelKruip's input. This is only the front-end, now it's time for the Javacript and the back-end.

The hybrid heat pump looks like this in the front-end.

Very nice! The only thing that worries me a bit is the efficiency of the gas-part. 1.067 is what ETE tells us, but ETM-SA does not take efficiencies/COP into account except for heat pumps. So that value should be 1.0 right @antw?

but ETM-SA does not take efficiencies/COP into account except for heat pumps. So that value should be 1.0 right @antw?

The classes for the HHP components are descendants of Buffer, therefore they support CoP/efficiency.

The classes for the HHP components are descendants of Buffer, therefore they support CoP/efficiency.

Nice! Than we can use 1.067 for the gas-part 👍

I've the feeling that I'm almost there. There's still one thing that needs to be solving and that's the money 💵 . The hybrid part holds all the investment variables but the business case uses the two loose components which in retrospect don't inherit any of the investment variables yet. The simple solution is, give the electricity or gas part all the investment related variables (om_cost_per_year, technical_lifetime, initial_investment etc.). But that can be ugly, also since I don't really know which of the parts would get those investment variables (either gas or electricity). All I know is it can't be both, because than a HHP would cost twice as much as ETEngine says it would be.
As one wise philosopher once said: mo money mo problems.

The hybrid part holds all the investment variables but the business case uses the two loose components...

I think that the business case should take costs of the (total) hybrid thing into account. Is that not the most obvious solution @grdw?

Since the costs are for the combined unit, can't they be assigned to the top-level HHP technology rather than the individual components?

Since the costs are for the combined unit, can't they be assigned to the top-level HHP technology rather than the individual components?

I realise now why that's easier said than done; the costs are taken from the technologies assigned to the networks, whereas the top-level tech isn't assigned to a network (but the individual components are).
Perhaps TechnologyCosts can be changed to use TestingGround#technology_profile instead?

Perhaps TechnologyCosts can be changed to use TestingGround#technology_profile instead?

Was already thinking that 👯

I managed to solve it like this. I think the PR is all good. So if somebody could check it out.


Navbar.html

Please accept my PR. Thanks

Sorry to inform but this repository has been excluded from hacktoberfest. So inorder to make your PR count towards hacktoberfest, request you to make your contribution in this repository -> https://github.com/SR-Sunny-Raj/Hacktoberfest2022-for-all


HTML Issues in Documented Code Snippets

I have encountered some HTML issues within the documented code snippets and wanted to bring them to your attention:

Invalid br Tag:
https://github.com/CasperDash/useWallet/blob/2ad8ca7cc24c53ce2a616e7ff630c204de4180cf/README.md?plain=1#L80
Suggested fix: it should be written as <br />.

Incorrectly Closed button Tag:
https://github.com/CasperDash/useWallet/blob/2ad8ca7cc24c53ce2a616e7ff630c204de4180cf/packages/react/README.md?plain=1#L81
Notice utton typo.
https://github.com/CasperDash/useWallet/blob/2ad8ca7cc24c53ce2a616e7ff630c204de4180cf/docs/pages/react/hooks/useSign.mdx#L28
https://github.com/CasperDash/useWallet/blob/2ad8ca7cc24c53ce2a616e7ff630c204de4180cf/docs/pages/react/hooks/useDisconnect.mdx#L24
https://github.com/CasperDash/useWallet/blob/2ad8ca7cc24c53ce2a616e7ff630c204de4180cf/docs/pages/react/hooks/useSignMessage.mdx#L27
Suggested fix: similar as in commit https://github.com/CasperDash/useWallet/commit/d91aa4051dddda76e8f25b221554953ed7140684.

Please ensure that the code samples are accurate and functioning as expected.

Thanks for your valuable feedback, I resolved it on tag https://github.com/CasperDash/useWallet/tree/docs-0.0.9.
If you do not have any concerns, I will close this ticket.


AWS CLI - GPG Fix

Because the awscli Visual Studio Code feature does a gpg --import, we can't sign our commits when using it.
I've changed the behaviour to load it as a temporary keyring file so that it doesn't interfere with the default gpg keyring on setup. It should allow you to then use the forwarded GPG keyring from the host.

Nope! Nice catch @sktan, I didn't realize that altering the public GPG keyring could cause issues like this; you taught me something new!
@Chuxel Out of curiosity, I did a quick search for other instances of gpg --import across this repo and got the following hits. Should probably apply a similar fix in these scripts:

containers/azure-terraform/.devcontainer/library-scripts/terraform-debian.sh
script-library/terraform-debian.sh
containers/codespaces-linux/.devcontainer/library-scripts/kubectl-helm-debian.sh
containers/kubernetes-helm/.devcontainer/library-scripts/kubectl-helm-debian.sh
containers/kubernetes-helm-minikube/.devcontainer/library-scripts/kubectl-helm-debian.sh
script-library/kubectl-helm-debian.sh
containers/go/.devcontainer/library-scripts/go-debian.sh
containers/codespaces-linux/.devcontainer/library-scripts/go-debian.sh
script-library/go-debian.sh

@Chuxel Out of curiosity, I did a quick search for other instances of gpg --import across this repo and got the following hits.

Generally the way these work is by setting a temp GNUPGHOME and then deleting it afterwards to avoid this problem.  e.g. https://github.com/microsoft/vscode-dev-containers/blob/4a8064f120e1dbe4c3fbc66d9d97ece499e5dbcc/script-library/go-debian.sh#L160

Ah. Would it be better to use the same method here, for consistency? (I kinda like @sktan's method better b/c messing with env variables always feels hacky to me, but I'm indifferent).


[B12] Hoppers and Infusion Altar

If you pipe items into the Arcane Pedestals with a Hopper, it will place more than 1 Item on Pedestal. Was hoping to do a tiny bit of automation with it.
When starting the Infusion, it will craft 1 item, but will consume every item stack on the Pedestals, voiding any extras you had intended for next craft.
I know I'm a version behind, but didn't see it mentioned in the changelog

Issue confirmed in B13


fix #786

Codecov Report

Merging #793 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #793   +/-   ##
=======================================
  Coverage   57.58%   57.58%
=======================================
  Files          71       71
  Lines       11605    11605
  Branches     1815     1815
=======================================
  Hits         6683     6683
  Misses       4320     4320
  Partials      602      602

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 46103c3...2f4c220. Read the comment docs.


Problems in segmentation results

Hi,
Thanks for sharing the great codes~ I run the SourceOnly experiments in FADA, but only get only  mIOU: 0.3709. I wonder if I miss some important issues, or the results should have some fluctuations due to different user training environment?

the training script is:
export NGPUS=4
# train on source data
python -m torch.distributed.launch --nproc_per_node=$NGPUS train_src.py -cfg configs/deeplabv2_r101_src.yaml OUTPUT_DIR results/src_r101_padain_pretrained_0.01_tmp/

Hi @lixiaotong97,
Thanks for your interest in our work!
There can be some fluctuations due to the user environment. You should be able to see a relative improvement regardless so just to be sure you can turn off pAdaIN in the feature extractor here : https://github.com/onuriel/PermutedAdaIN/blob/819cdb9ef4a42655934e5340c1479700be9cd6f3/FADA/core/models/feature_extractor.py#L48
by setting with_permute_adain to False.
Also, If it helps, I can upload the source only model weights that achieved the results posted in the paper. Let me know.
Best of luck!

Thanks for the authors' response! I have run the FADA baseline before (use original code in github: https://github.com/JDAI-CV/FADA) , and got 0.3701 mIOU, meanwhile the pAdaIN result I run is 0.3709. These relative results make me a little confused.

Hi~it seems that I found the question. I run the checkpoint in 14000, 16000, 18000, 20000 epoch and got 0.383, 0.373, 0.361, 0.371 mIOU, which demonstrates the importance to choose the checkpoint. If the sourceonly model uses the 20000(e.g. last) checkpoint? How do the authors do in the paper to choose the right checkpoint?

Hi,
Oh I see, sorry for the confusion. We chose the last checkpoint.
The link to the checkpoint : https://drive.google.com/drive/folders/1z0OcjcLh4oJwEzao8YvBksQ87yw8V5L9?usp=sharing
Best of luck!

Thanks for your kind response！It might be some fluctuations ~ I think I have figured out my problems. Thanks again!
Best of my wishes.


list-cartridges-by-filter command added to CLI

list-cartridges-by-filter command added to CLI

Thanks for the fix @dinithis! I have now merged this pull request to master branch.


Better error message for invalid bigint literals ending with n

Helps with the cases of decimals and exponentials, though not with numbers incorrectly starting with 0.
Fixes #28887.

Thanks!


api: eds.Row and eds.Col do not actually return copies

Since we work with nested slices, copy just copies the references to the inner slices. So a user modifying an eds.Row will actually modify the internal representation - this is not the intended behavior, correct?
https://github.com/celestiaorg/rsmt2d/blob/e3daf260bc77f69ec3a4b7bbd4d1d7b13a6015fd/extendeddatasquare.go#L133-L152

Thanks, good find!


More configuration options for notifications

Time when the daily project summary should be send
Quiet hours
Quiet days (weekend)

It should also be possible to configure the above on organization level, with option to overwrite on selected projects.
Option to get a daily summary on organization level instead for one mail per project.

Currently emails are sent out at 8/9am in your local time zone. The issue is everyones timezone is different on a project and as such you could get them at different times.
How do you see quiet hours working? What should happen to the notifications if you are in quiet time? Most phones / inboxes already keep quiet when receiving email.

You're right. Quiet hours is probably most a luxury that can be handled in other ways.
One way of handelig it could be to send an email with a summary of the events that occurred during the quiet hours. Kind of like the daily summart, but just for that period.

Merging into https://github.com/exceptionless/Exceptionless/issues/69


Feature/nav 94 allow only showing lines for time budget isolines instead of max reachable distance by foot

Tune demo app for demo on Thursday

Perfect, thanks!


fix(l2g_predictions): annotate based on list of features + filter out missing annotation

✨ Context
The feature matrix contains all features we have developed for L2G.
However, that doesn't mean that we want to use all of them during training. Right now, this is true for isProteinCoding.

🛠 What does this PR implement

add_locus_to_gene_features didn't take into account the list of features used for training. Now it does
We were filtering out features with nulls, instead of features equal to 0. Now each prediction only include features that have annotation

🙈 Missing

🚦 Before submitting

[x] Do these changes cover one single feature (one change at a time)?
[x] Did you read the contributor guideline?
[x] Did you make sure to update the documentation with your changes?
[x] Did you make sure there is no commented out code in this PR?
[x] Did you follow conventional commits standards in PR title and commit messages?
[x] Did you make sure the branch is up-to-date with the dev branch?
[ ] Did you write any new necessary tests?
[x] Did you make sure the changes pass local tests (make test)?
[x] Did you make sure the changes pass pre-commit rules (e.g poetry run pre-commit run --all-files)?

@project-defiant One: isProteinCoding, which is true for everyone right now.
Thanks for the review!


fix: Handle incorrect required role casing

Some trainees have the role Dr in Training instead of DR in Training, these profiles are not properly synced. Ignore the casing
when comparing the role to ensure we catch edge cases.
TIS21-1624

Creating as a draft as I'm not sure whether this would just be a data quality issue or something we actually need to account for.
There is a fix to the test class which needs to be merged even if the functionality change is reverted.


true/false missing in ES3_KEYWORDS

http://www.w3schools.com/js/js_reserved.asp
true/false are also ES3 reserved words.
DOM.decl('overlay', {
    onSetMod: {
        visible: {
            'true': function () {
                    // ...
                }
            }
        }
}

disallowQuotedKeysInObjects": "allButReserved" currently doesn't respect true/false object keys in quotes.

cc @6-post

Coverage remained the same at 99.09% when pulling 44b24942c1a5a7e355d6f43963c7c6e5963f962b on 1999:es3-reserved-words-truefalse into c668ff1be0b1cfa058866048944bad3df7ff7cbc on jscs-dev:master.

Thank you, although,  technically speaking , true/false/null are reserved words but not keywords, whereas this list should contain only keywords.
btw, it's generally considered a bad idea to give proof links on http://www.w3schools.com

Okay, so what should we use then to prevent jscs from throwing errors with this code? When we use true without quotes, IE8 doesn't work at all: https://jing.yandex-team.ru/files/dsorin/2015-04-03_1141.png
Btw what's so bad about using w3schools? I could've put a link to MDN but why is it a bad idea?

Situation around the http://www.w3schools.com has improved, but it still has bad reputation, for example this how it was couple years ago -https://web.archive.org/web/20130115033517/http://w3fools.com/
It's usually better to give link on the spec itself.


Fixed typographical error, changed accross to across in README.

@SeriousM, I've corrected a typographical error in the documentation of the WPFLocalizationExtension project. You should be able to merge this pull request automatically. However, if this was intentional or if you enjoy living in linguistic squalor, please let me know and create an issue on my home repository.

Hehe, thanks. That was definitely a typo 😅


Memory profiling tools?

Right now, it's fairly obvious where the majority of our memory usage stems from (ahem PHP objects...), and we have some ideas on how to cut down on that when it comes reducing the cost of the token representation, but as we progress, it would be helpful to have something other than raw arithmetic :wink:.

You can profile PHP applications with XDebug and a profile viewer like QCacheGrind

As far as I know XDebug does not support memory profiling. However, there is https://github.com/arnaud-lb/php-memory-profiler, which added PHP 7 support a couple of days ago.

xDebug 2.6.0 is out, and it supports memory profiling. I haven't looked at the memory profiles before, so I'm not familiar with how well it works
https://xdebug.org/docs/profiler

Since Xdebug 2.6, the profiler also collects information about how much memory is being used, and which functions and methods increased memory usage.


unable to set default friction on static body

when creating a body with options { isStatic:true, friction:0.01 } the friction is set to 1 instead of 0.01
I've traced this down to the setStatic method line 265, part.friction = 1;

yes agree, this should be a bug, static objects still have friction, so I think you couldn't reset friction to 1 in Body.setStatic method? @liabru


Update javadocs

Codecov Report

Merging #135 (12d472c) into master (7a2857d) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #135   +/-   ##
=========================================
  Coverage     55.52%   55.52%
  Complexity      785      785
=========================================
  Files           167      167
  Lines          3276     3276
  Branches        381      381
=========================================
  Hits           1819     1819
  Misses         1355     1355
  Partials        102      102

Impacted Files
Coverage Δ

src/main/java/seedu/address/Main.java
0.00% <ø> (ø)

.../address/logic/commands/AddAppointmentCommand.java
100.00% <ø> (ø)

...du/address/logic/commands/AddInsuranceCommand.java
92.30% <ø> (ø)

...seedu/address/logic/commands/AddPersonCommand.java
92.30% <ø> (ø)

...seedu/address/logic/commands/AddRecordCommand.java
92.30% <ø> (ø)

...ddress/logic/parser/AddInsuranceCommandParser.java
92.30% <ø> (ø)

...u/address/logic/parser/AddPersonCommandParser.java
100.00% <ø> (ø)

...u/address/logic/parser/AddRecordCommandParser.java
0.00% <ø> (ø)

...ess/logic/parser/DeleteInsuranceCommandParser.java
100.00% <ø> (ø)

...ddress/logic/parser/DeletePersonCommandParser.java
100.00% <ø> (ø)

... and 28 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7a2857d...12d472c. Read the comment docs.


Refactor openssl to crypto

Reword expect
Remove ToRtpIv trait for aes_128_cm_sha1_80
Remove ToRtpIv trait for aead_aes_128_gcm
Move KeyingMaterial out of ossl module
Add CI check for --no-default-features
crypto.rs -> crypto/mod.rs
Refactor OpenSSL DTLS into crypto mod
Feature gate openssl
Move things around in crypto
Refactor our SRTP crypto
Feature gate all openssl

Thank you for acting on this so quickly! :tada:

No worries. I want you to get real world usage out of the ICE Agent, so we can start improving that part together! 😍


screenshot should work when attached to already-launched apps

I'm using Ruby bindings, for context. Version 1.0 release of WinAppDriver.
I have to attach to an app with :appTopLevelWindow after it's already running (probably because it's a Ruby GUI app but that's a longer story and shouldn't matter). Most things work fine but save_screenshot apparently isn't implemented.
`@driver.respond_to?(:save_screenshot)`

returns false.
I already handed WinAppDriver the app's top level window handle and it's clearly running on that desktop so presumably it should be able to screenshot the app.
I can save_screenshot when I launch something as :app like notepad.exe, for instance. So it works sometimes. Which leads me to assert that it should work now, too.

Ah. I was wrong. It was using .screenshot instead of .save_screenshot.
Annoying that there is yet another driver signature different but I should shut up and deal with it.


Jersey Validation Improvements

This PR is a few changes we have been using for a while to improve the built-in jersey parameter validation error messages provided by Dropwizard.
Better Enum Validation Messages
Currently dropwizard resources return a 404 if a request is made with an invalid value for a parameter of an Enum type. This PR includes ValidatingEnumParamConverterProvider which provides converters for all enums used in method parameters. The converter then provides better error messages like "query param choice must be one of [OptionA, OptionB, OptionC]" when invalid values are sent.
Parameter Names in Parse Failure Messages
Currently when an invalid value is passed into a *Param parameter dropwizard returns an error message like "Parameter is not a number.".  This PR includes AbstractParamConverterProvider
along with a slight enhancement to the *Param classes that returns messages that include the name of the parameter that failed validation, like "query param user_id is not a number."
Hibernate ParameterNameProvider
Small change to move most of parameter naming logic from ConstraintMessage to JerseyParameterNameProvider. This implements the standard ParameterNameProvider interface that Hibernate uses to resolve parameter names during validation.
New DurationParam
Include a new DurationParam that can parse String input in the format supported by dropwizard's existing Duration class.

Awesome PR, did a quick glance and everything looks top notch.
I'm going to let this PR sit for a little bit as I mull over some of the implementation (like better enum validation messages).

Addressed comments on comments & tests and also fixed test failures related to NonEmptyStringParam.  The new converter for *Param types was not handling NonEmptyStringParam properly. I added support for it and removed NonEmptyStringParamFeature which was no longer needed.

Changes Unknown when pulling 4013644b3bed807e038327dabe48f12f1b2dde64 on cmicali:jersey-validation into ** on dropwizard:master**.

Changes Unknown when pulling b64ef9fbb5a832e433325a333f6f4b4f2d4abb97 on cmicali:jersey-validation into ** on dropwizard:master**.

Changes Unknown when pulling a492f0a533969ad4a50270f87e66e6644876de1f on cmicali:jersey-validation into ** on dropwizard:master**.

Changes Unknown when pulling 435447dd6b37d2c7aab72ac86a6c8332362b571b on cmicali:jersey-validation into ** on dropwizard:master**.

Changes Unknown when pulling 7fa61dc1dceda581393197e4edd9216725c365e2 on cmicali:jersey-validation into ** on dropwizard:master**.

Changes Unknown when pulling 9818fade86e80fb59f6a1aaa36f09ec87ac79857 on cmicali:jersey-validation into ** on dropwizard:master**.

Changes Unknown when pulling 1b179e40cdcb28b53c6b39fad7cc765805ae54a8 on cmicali:jersey-validation into ** on dropwizard:master**.

Changes Unknown when pulling 8b30c5a2bc16d9f062c7474d9d2b2573854b6529 on cmicali:jersey-validation into ** on dropwizard:master**.

Thanks, @cmicali!

Updated release notes in b1c563e2
Thanks for the huge effort, @cmicali 😄

Happy to contribute back, not huge at all. Thanks for all the great detailed review, the result is significantly better for it.


Reduce error summary heading size to match GDS

GDS uses 24px for the error summary heading - see https://design-system.service.gov.uk/components/error-summary/.  At present error summary uses H2 which brings in size LARGE of 36px instead.  This change reduces the size to MEDIUM which matches the GDS design.

[ ] Documentation - N/A
[x] Tests - Snapshot changed
[x] Ready to be merged - Yes

Storybook pre change:

Storybook post change:

GDS Error Summary page:

Note that the font size reduction was originally attempted in https://github.com/govuk-react/govuk-react/pull/634 by switching from H2 to H3, but I have subsequently discovered (thanks @jsrobertson) that a size can be applied to a heading element so have done that instead.

Deploy preview for govuk-react processing.
Building with commit 937297a1cd47c6421d84b991aef34bfcf6743b0c
https://app.netlify.com/sites/govuk-react/deploys/5c989e7016ccc300083feaa1

Apologies @stevesims didn't understand your comment https://github.com/govuk-react/govuk-react/pull/634#discussion_r268140660, but do now.  Please let me know if you would prefer me to change to <H3 as="h2"> instead!

Codecov Report

Merging #640 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #640   +/-   ##
=======================================
  Coverage   99.66%   99.66%
=======================================
  Files         104      104
  Lines         604      604
  Branches       69       69
=======================================
  Hits          602      602
  Misses          2        2

Impacted Files
Coverage Δ

components/error-summary/src/index.js
87.5% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3a271ab...937297a. Read the comment docs.

:grin: no worries.
This is perfect - semantically identical to my earlier suggestion, and on reflection probably slightly easier to grasp when reading the code.


fix(pacer.email): plain text parsing of bankruptcy short description

Because of order of statements, parsing of bankruptcy short description was failing when trying to access the 0 index
of the empty list self.docket_numbers
Also added

a plain text test case for cob
short description parsing case for cob
logger.error calls for when we are not prepared to parse a bankruptcy short description
correct document_url parsing

Solves #729
Solves #866

Alberto, can you please review this one when you have a moment?

@albertisfu  please check again

Lovely. Thank you guys.


Minor indentation issue - javascript_nodejs/03.welcome-users/bots/welcomeBot.js

Sample information

Sample type: [Incorrect indentation]
Sample language: [nodejs]
Sample name: <03.welcome-users>

Describe the bug
We are citing from this sample in this article.
The code snippet (javascript_nodejs/03.welcome-users/bots/welcomebot.js?range=65-88) seems not indent correctly.
Expected behavior
Format the indentation.
Screenshots

Additional context
If the lines of this snippet will be changed, please let us know.
[bug]

Hmm, took a look at the .onMembersAdded() method that you have in question, and its indentation looks fine to me.

Perhaps you're referencing the indentation going on in LN 76 - 79, the 2nd message sent?

It's sending a longer block of text in its message, hence the string concatenation :heavy_check_mark:

Best done this way, instead of 1 long string, to not have 1 line that's excessively long with extreme horizontal scrolling w/o wrap
For example, to compare, in our Python SDK's linting rules, it specifies that 1 line can have a max of 120 characters (max-line-length=120)
LNs 77 - 79 are also properly indented in this string concatenation, to show that it's a continuation of LN 76

As for the indentation sizes themselves, if you compare the eslint rules set in the botbuilder-js repo, it specifies that indentation should be 4 spaces :heavy_check_mark:

.onMembersAdded()'s indentation all follow 4-space indentation rule

Resolving issue as indentation looks good in sample

Thank you! @Zerryth


Sbw imporving bpe

It's not as a big PR as it loooks like!

Changed folders that were called "training" to "train"
Changed directories which were "subword" to "sw" to shorten the dir
Made runV3.1.sh, ignore runV3.sh. I will change it to runV3, I'm keeping versions for quick, but I see now that it makes this PR look scary and will stop that. I changed stage 2 and the beginning of stage 3 to handle multiple subword methods, with one parameter. I only have BPE implemented atm.
Added the files apply_bpe.py and learn_bpe.py to sw_methods/bpe/ the files have not been modified at all.

Scratch that. Need to push some changes


CI: make tarpaulin ignore test code

Description
tarpaulin does not recognize the tests/ folder, async_std::test or tokio::test, so we'll ignore that code manually
also fixes a caching issue with GitHub actions
Checklist

[ ] Formatted code using cargo fmt --all
[ ] Linted code using clippy cargo clippy --all-targets --all-features -- -D warnings
[ ] Updated README.md using cargo readme -r influxdb -t ../README.tpl > README.md
[ ] Reviewed the diff. Did you leave any print statements or unnecessary comments?
[ ] Any unfinished work that warrants a separate issue captured in an issue with a TODO code comment

Looks like I got it fixed for now. Hopefully tarpaulin gets smarter in the future about which code needs to be tested and what code is testing code.

Great change, thanks!


Pin linter version

Proposed changes
Pin linter version
Checklist
Before creating a PR, run through this checklist and mark each as complete.

[ ] I have read the CONTRIBUTING document
[ ] I have run make install-tools and have attached any dependency changes to this pull request
[ ] If applicable, I have added tests that prove my fix is effective or that my feature works
[ ] If applicable, I have checked that any relevant tests pass after adding my changes
[ ] If applicable, I have updated any relevant documentation (README.md)
[ ] If applicable, I have tested my cross-platform changes on Ubuntu 22, Redhat 8, SUSE 15 and FreeBSD 13

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (71ae09c) 66.13% compared to head (68a7cec) 66.15%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #562      +/-   ##
==========================================
+ Coverage   66.13%   66.15%   +0.01%
==========================================
  Files         118      118
  Lines       13461    13461
==========================================
+ Hits         8903     8905       +2
+ Misses       3958     3955       -3
- Partials      600      601       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


TravisCI has been failing

travis has been failing lately.  not sure why.

Fixed, mostly due to the PubSubTest


What are the difference between OpenFace and openface?

Hi:
Just wonder what are the differences between https://github.com/cmusatyalab/openface and https://github.com/TadasBaltrusaitis/OpenFace ?
Cheers

These are two completely different Libraries!
cmusatyalab openface is a face recognition library.
baltrusaitis OpenFace aims at facial landmark detection, head pose estimation, facial action unit recognition, and eye-gaze estimation.