Testing AppX execution alias without yao-pkg

[fredrikekelund]

Related issues

• Related to Make Studio CLI available in AppX via AppExecutionAlias #2547

Proposed Changes

I'm not familiar with AppX, but looking at #2547, I wondered whether we've tried an approach like this. In this PR, the Executable parameter points to the node runtime we already bundle, and a uap10:Parameters contains command line parameters passed to Node (in this case, simply the path to cli/main.js).

Testing Instructions

We need to build an AppX installer for the app to test this.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing b06a80f vs trunk

site-editor

Metric	trunk	b06a80f	Diff	Change
load	2704.00 ms	2697.00 ms	-7.00 ms	⚪ 0.0%

site-startup

Metric	trunk	b06a80f	Diff	Change
siteCreation	6075.00 ms	6073.00 ms	-2.00 ms	⚪ 0.0%
siteStartup	3954.00 ms	3943.00 ms	-11.00 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[gcsecsey]

The approach looked good to me on the surface, but when I tried to test it, I couldn't access the studio command from any shell (Command Prompt or PowerShell).

After digging a bit into how Windows execution aliases work, I think this approach won't work because of a limitation of the alias mechanism. Based on this article, the AppExecutionAlias doesn't seem to support receiving parameters. I think the uap10:Parameters attribute is not being applied to the execution alias.

It'd be great to be able to pass a parameter to avoid packaging a standalone exe, but I don't have any better ideas at the moment for how to do that.

[fredrikekelund]

Thanks for digging, @gcsecsey 🙏 I did some more testing with this last week, too, but also couldn't get it to work. I'm actually not even sure this approach had a very big effect on filesize… I'll just close this.