Closed ivberg closed 2 years ago
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.
This will also work for desktop packaged apps: https://docs.microsoft.com/en-us/windows/uwp/xbox-apps/automate-launching-uwp-apps
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.
Transferring to the WindowsAppSDK repo to see about getting a message when trying to directly launch the .exe of a packaged app.
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.
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 |
---|
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
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.
Interestingly enough I just tried this on 0.8.1 stable - it seems to be halfway there now!
You can use an app execution alias inside your appx manifest if CLI launch is crucial to your app.
AppLifecycle and unpackaged apps are supported as of 1.0
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.
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.
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:
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 IApplicationActivationManagerhttps://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 GitHubhttps://github.com/microsoft/WindowsAppSDK/issues/1062#issuecomment-1048499935, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AARCGQAAQQYF3VN3DDXQGB3U4SB3LANCNFSM5AMN6YUQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://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: @.***>
Describe the bug App crashes when run from cmd-line (as opposed to start)
Steps to reproduce the bug
Steps to reproduce the behavior:
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+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
Additional context