0

I have a win32 App on microsoft store which has been converted by desktop-bridge and works fine. I thought of adding a feature of being able to launch it by just the exe name.

Found the feature AppExecutionAlias in various articles and used it in my app manifest.

<uap3:AppExecutionAlias>
  <desktop:ExecutionAlias Alias="mysampleapp.exe" />
</uap3:AppExecutionAlias>

The App runs but not perfectly. The problem is that it does not run under the Store Context so it can't find out whether it's licensed or not. This can also be made out from the fact that when run this way, the App writes to the non-virtualized registry that I can see being created if I run this way.

Perhaps, those threads that show the success test cases did not test this aspect of not running under the Store Context. How to properly set AppExecutionAlias so the program could be launched from command line?

I can't find any thread describing this problem or its solution. I hope someone from the Microsoft store-development team notices this question and solves my problem.

Update: Since posting this question, I found that to get the Store Context, the app needs to be started with AUMID. That works with the shell: command. But the question still remains, if APPX feature of ExecutionAlias was given, why doesn't it automatically use the AUMID? It looks like a buggy feature.

user173399
  • 464
  • 5
  • 21
  • IMHO, this can be a security risk. I happened to catch it because my app checks if it is running in store context. All apps may not check and if they use this feature, strange problems may occur as the registry used is different from the one used in the Store Context. I wonder if the same problem exists for Apps started from file association feature of the manifest? I'm not using that feature so I don't know. – user173399 Jan 31 '22 at 05:05
  • It seems that when you launch the .exe file directly, it bypasses the outer app container which should also be launched. Packaging your app with desktop bridge will put your win32 app into an app container that will have the AUMID for your app. So that you are failed to get the StoreContext object because StoreContext requires package identity. Please submit this behavior in the Feedback Hub. – Roy Li - MSFT Jan 31 '22 at 06:51
  • @RoyLi-MSFT Thanks. I have already packaged this app and it is on the store. It's just that using the ExecutionAlias feature does not work correctly and does not use AUMID automatically. Will ty to submit a test case on feedback hub. But I think it's easy to recreate this problem at your end. Just take a Microsoft's own packaged app and try the execution alias feature with it to launch. Then see what registry it accesses or what licensed state it sees. – user173399 Jan 31 '22 at 07:00
  • Yep, I know that you've packaged it and when you launch it normally it works well. It's just about the AppExecutionAlias feature. That's why I'd suggest you submit this to the Feedback Hub. – Roy Li - MSFT Jan 31 '22 at 07:31
  • Sent feedback. Also, I know why it doesn't work. Basically ExectionAlias does nothing but to add the full path of the app to the registry entry for "App Paths" like a regular win32 app. That's why it runs but without a Store Context. – user173399 Jan 31 '22 at 14:43
  • @RoyLi-MSFT I checked back in the Feedback Hub and there is no answer or acknowledgement there. In the past also, I have had poor experience with Feedback Hub. Another thing, the Partner Center dashboard for Apps is seriously lacking in new features for quite some time. In the list of Filters of OS versions for Acquisitions, Windows 11 is still missing although I know there are users with Windows 11 there. Whom to contact in Microsoft to get some attention on such issues? I lost hope in the Feedback Hub. Thanks. – user173399 Feb 09 '22 at 16:03

0 Answers0