App crashes when run from cmd-line (as opposed to start)

[ivberg]

Describe the bug
App crashes when run from cmd-line (as opposed to start)

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Create a new C# project using instructions at https://aka.ms/winui (Try WinUI3).
2. Use MSIX packaged app template
3. Launch sample app from Start Menu <- OK
4. Right click sample app in Task Mgr "Open File Location" to find .exe path
5. In cmd-prompt run app .exe - e.g. c:\Path\To\MyApp.exe <- PROBLEM app will crash
6. Dump show crash not in app code but in WinUI code

0d coreclr!RaiseTheExceptionInternalOnly+0x29a
0e coreclr!RealCOMPlusThrowWorker+0x31
0f coreclr!RealCOMPlusThrow+0x8d
10 coreclr!RealCOMPlusThrow+0x99
11 coreclr!TryCallMethod+0x1160f6
12 coreclr!RuntimeTypeHandle::CreateInstance+0x26d
13 System_Private_CoreLib!System.RuntimeType.CreateInstanceDefaultCtorSlow+0x48
14 System_Private_CoreLib!System.RuntimeType.CreateInstanceDefaultCtor+0xd3
15 System_Private_CoreLib!System.Activator.CreateInstance<System.__Canon>+0x3e
16 Microsoft_WinUI!WinRT.WeakLazy<_IApplicationStatics>.get_Value+0xb0
17 Microsoft_WinUI!Microsoft.UI.Xaml.Application._IApplicationStatics.get_Instance+0x38
18 Microsoft_WinUI!Microsoft.UI.Xaml.Application.Start+0x19
19 MyApp!MyApp.Program.Main+0xf2

This blocks automation and GUI Unit Testing say with something like WinAppDriver & Appium to test WinUI3 app

Expected behavior
AppSDK app launched from command prompt does not crash

Version Info
0.5.7

NuGet package version:
0.5.7

Windows app type:

UWP	Win32
	Yes

Windows 11 version	Saw the problem?
Insider Build (22141.1000)	Yes

Device form factor	Saw the problem?
Desktop	Yes

Additional context

[StephenLPeters]

This is currently not supported, the exe generated by the build is not an unpackaged app, which is a requirement for running an exe from the command line. You should be able to use the IApplicationActivationManager interface to launch your apps though.

[StephenLPeters]

This will also work for desktop packaged apps: https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/automate-launching-uwp-apps

[ivberg]

This @StephenLPeters this info definitely helps to work around the issue. I would suggest the framework not crash in this scenario, but instead simply exit. Best would be to show window stating info on how to launch it.

[MikeHillberg]

Transferring to the WindowsAppSDK repo to see about getting a message when trying to directly launch the .exe of a packaged app.

[ivberg]

Also, I wonder if this will be supported in 1.0? The docs / roadmap seem to imply it will.

Here is how I arrived at that conclusion but feel free to correct the docs or me if I am wrong.

1. The roadmap https://github.com/microsoft/WindowsAppSDK/blob/main/docs/roadmap.md lists AppLifeCycle as Experimental for 0.8 and supported for 1.0
2. AppLifeCycle docs - App Lifecycle #111
3. Talk about this scenario and say things like the following

This proposal will allow users to activate any app by double-clicking it in file explorer, or typing in a path in a command window.	Must

5. In the Win32 world, it is normal to activate an app by calling CreateProcess (or ShellExecute), specifying the filesystem path to the executable file. When the user double-clicks an executable file in File Explorer, this uses that same mechanism. When the user types in an executable file name into a command window, the same thing happens

6. We will provide a converged GetActivatedEventArgs which will get all args, regardless of activation kind -- including both traditional command-line activation and also the richer UWP activation objects. This will be available to all apps.

[ivberg]

Interestingly enough I just tried this on 0.8.1 stable - it seems to be halfway there now!

1. Now working in 0.8.1 - Launch from cmd-line - now works! - C:\Program Files\WindowsApps\MyApp_1.0.0.0_x64__ms1afnmeykq8t\MyAppUI\MyAppUI.exe
2. Still not working. Launch in explorer (for the same file path) and you get "Windows cannot access the specified device, path, or file. You may not have appropriate permissions to access the item"

[sylveon]

You can use an app execution alias inside your appx manifest if CLI launch is crucial to your app.

[DrusTheAxe]

AppLifecycle and unpackaged apps are supported as of 1.0

[rcohn]

Hi @DrusTheAxe -

I see that this issue is closed, but could you possibly provide a bit more detail on your final comment "AppLifecycle and unpackaged apps are supported as of 1.0"?

Today I built a WinUI3 unpackaged app and, while I'm able to double click on it to start it from File Explorer, I cannot start it up from a cmd prompt or script. I do see the comments above about IApplicationActivationManager, so that's something I intend to try.

But if you have any more info on unpackaged apps deployment for Windows App SDK 1.0, I would be grateful to hear them.

Thanks very much.

[DrusTheAxe]

Today I built a WinUI3 unpackaged app

Using the 1.0 Stable release (not experimental or preview or previous releases)?

Unpackaged apps require Dynamic Dependencies and the Bootstrapper API e.g. MddBootstrapInitialize(), which were introduced in 1.0. Won't work on earlier versions (e.g. 0.8).

while I'm able to double click on it to start it from File Explorer, I cannot start it up from a cmd prompt or script

Is it a normal cmd prompt or did you Run as Administrator (aka elevated)? The latter won't work in 1.0 (elevation support for unpackaged apps is coming in 1.1)

What version of Windows are you running on?

I do see the comments above about IApplicationActivationManager

That's only relevant if you're a packaged app. If you are then your application can be launched via AAM (same as when you clikc on the StartMenu tile for your packaged app, that calls AAM to launch the packaged app).

If you're unpackaged then AAM isn't relevant. It takes as input an ApplicationUserModelID (aka AppUserModelID aka AUMID aka application identity) per your manifested definition in your appxmanifest.xml. But that only exists if you're packaged. Unpackaged apps have no appxmanifest.xml and no package or application identity, thus no AUMID and thus AAM isn't relevant. CreateProcess, ShellExecute, desktop shortcuts (.LNK) and all the other classic Win32 mechanisms apply.

[rcohn]

Hi Howard – I’m using Microsoft.WindowsAppSDK, Latest stable 1.0.0, pub. 11/16/2021 The .exe I’m clicking on is in this release folder of the project: <projectname>\bin\x64\Release\net6.0-windows10.0.19041.0\win10-x64 If I use File Explorer, the app starts up. If I open a cmd prompt as admin, then I get the exception. But (and I didn’t know this before your reply) if I now open a non-admin prompt, then the app starts with no problem. And if run a cmd script, also as non-admin, the app will open there as well. So, you have cleared the mystery, and it seems that the Windows App SDK 1.1 release will support elevated execution. That is good to know. The only other question I have is when we can expect that release. If there is a roadmap you can point me to, that would be most appreciated. Many thanks for your very helpful and quick response! Best regards, Robert Cohn Other pertinent info: Running Windows 10 20H2, OS Build 19042.1526 Using Visual Studio 2019 version 16.11.7 From: Howard Kapustein ***@***.***> Sent: Tuesday, February 22, 2022 11:10 PM To: microsoft/WindowsAppSDK ***@***.***> Cc: Cohn, Robert ***@***.***>; Comment ***@***.***> Subject: Re: [microsoft/WindowsAppSDK] App crashes when run from cmd-line (as opposed to start) (#1062) [EXTERNAL] Today I built a WinUI3 unpackaged app Using the 1.0 Stable release (not experimental or preview or previous releases)? Unpackaged apps require Dynamic Dependencies and the Bootstrapper API e.g. MddBootstrapInitialize()<https://docs.microsoft.com/windows/windows-app-sdk/api/win32/mddbootstrap/nf-mddbootstrap-mddbootstrapinitialize>, which were introduced in 1.0. Won't work on earlier versions (e.g. 0.8). while I'm able to double click on it to start it from File Explorer, I cannot start it up from a cmd prompt or script Is it a normal cmd prompt or did you Run as Administrator (aka elevated)? The latter won't work in 1.0 (elevation support for unpackaged apps is coming in 1.1) What version of Windows are you running on? I do see the comments above about IApplicationActivationManager<https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-iapplicationactivationmanager?redirectedfrom=MSDN> That's only relevant if you're a packaged app. If you are then your application can be launched via AAM (same as when you clikc on the StartMenu tile for your packaged app, that calls AAM to launch the packaged app). If you're unpackaged then AAM isn't relevant. It takes as input an ApplicationUserModelID (aka AppUserModelID aka AUMID aka application identity) per your manifested definition in your appxmanifest.xml. But that only exists if you're packaged. Unpackaged apps have no appxmanifest.xml and no package or application identity, thus no AUMID and thus AAM isn't relevant. CreateProcess, ShellExecute, desktop shortcuts (.LNK) and all the other classic Win32 mechanisms apply. — Reply to this email directly, view it on GitHub<#1062 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AARCGQAAQQYF3VN3DDXQGB3U4SB3LANCNFSM5AMN6YUQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>