starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-24 16:05:21 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Can't get fragments to work with an MSIX app #13649

New Issue
Closed
opened 2026-01-31 03:48:23 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 03:48:23 +00:00
Owner
Copy Link

Originally created by @davidanthoff on GitHub (Apr 27, 2021).

Originally assigned to: @PankajBhojwani on GitHub.

Windows Terminal version (or Windows build number)

1.8.1032.0, 1.7.1033.0

Other Software

A new MSIX installer for the Julia language that I'm working on (https://github.com/davidanthoff/winjulia). The installer is available for tryout at https://winjulia.david-anthoff.com/. The appx file that has the fragment in it and the JSON in the app manifest is available at https://winjulia.s3-us-west-1.amazonaws.com/JuliaApp-x64-1.0.0.32.appx.

Steps to reproduce

Go to https://winjulia.david-anthoff.com/ and install Julia from the link on that page. That will trigger an MSIX App Installer setup and install Julia.

Expected Behavior

I would have expected a new profile to show up in Windows Terminal for Julia automatically.

Actual Behavior

No profile appears. I think I must be making some mistake in how I am creating the fragment, but I can't figure out what is wrong.

The appx manifest I'm using is https://github.com/davidanthoff/winjulia/blob/master/msix/appxmanifest.xml, the fragment I'm adding is https://github.com/davidanthoff/winjulia/blob/master/msix/Fragments/Julia.json, and that file is put into the folder Public\Fragments via https://github.com/davidanthoff/winjulia/blob/master/msix/PackagingLayout.xml#L8.

Originally created by @davidanthoff on GitHub (Apr 27, 2021). Originally assigned to: @PankajBhojwani on GitHub. ### Windows Terminal version (or Windows build number) 1.8.1032.0, 1.7.1033.0 ### Other Software A new MSIX installer for the Julia language that I'm working on (https://github.com/davidanthoff/winjulia). The installer is available for tryout at https://winjulia.david-anthoff.com/. The appx file that has the fragment in it and the JSON in the app manifest is available at https://winjulia.s3-us-west-1.amazonaws.com/JuliaApp-x64-1.0.0.32.appx. ### Steps to reproduce Go to https://winjulia.david-anthoff.com/ and install Julia from the link on that page. That will trigger an MSIX App Installer setup and install Julia. ### Expected Behavior I would have expected a new profile to show up in Windows Terminal for Julia automatically. ### Actual Behavior No profile appears. I think I must be making some mistake in how I am creating the fragment, but I can't figure out what is wrong. The appx manifest I'm using is https://github.com/davidanthoff/winjulia/blob/master/msix/appxmanifest.xml, the fragment I'm adding is https://github.com/davidanthoff/winjulia/blob/master/msix/Fragments/Julia.json, and that file is put into the folder `Public\Fragments` via https://github.com/davidanthoff/winjulia/blob/master/msix/PackagingLayout.xml#L8.
claunia commented 2026-01-31 03:48:26 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 29, 2021):

@PankajBhojwani can you help @davidanthoff here?

@zadjii-msft commented on GitHub (Apr 29, 2021): @PankajBhojwani can you help @davidanthoff here?
claunia commented 2026-01-31 03:48:26 +00:00
Author
Owner
Copy Link

@PankajBhojwani commented on GitHub (May 4, 2021):

Just an update (so you don't think we've abandoned this!):

It seems that we are detecting Julia as an app extension, but when we probe it for its public folder we get a null response. I am still trying to figure out why this is so - the extension and public folder names seem to be declared properly in the manifest file (the extension name almost certainly is since we are detecting Julia as an extension), so I wonder if it has something to do with the way the public folder/the json file is included.

In the UWP app I use to test fragments with Terminal, I have a
<Content Include="Public\Fragments\fragment.json" /> line in the .csproj file, and it seems that the equivalent here is the
<File DestinationPath="Public\Fragments\Julia.json" SourcePath="Fragments\Julia.json" /> line in the PackagingLayout.xml file, so that should also be working, unless there's some difference there I'm not aware of

@PankajBhojwani commented on GitHub (May 4, 2021): Just an update (so you don't think we've abandoned this!): It seems that we are detecting Julia as an app extension, but when we probe it for its public folder we get a null response. I am still trying to figure out why this is so - the extension and public folder names seem to be declared properly in the manifest file (the extension name almost certainly is since we are detecting Julia as an extension), so I wonder if it has something to do with the way the public folder/the json file is included. In the UWP app I use to test fragments with Terminal, I have a `<Content Include="Public\Fragments\fragment.json" />` line in the `.csproj` file, and it seems that the equivalent here is the `<File DestinationPath="Public\Fragments\Julia.json" SourcePath="Fragments\Julia.json" />` line in the `PackagingLayout.xml` file, so that _should_ also be working, unless there's some difference there I'm not aware of
claunia commented 2026-01-31 03:48:26 +00:00
Author
Owner
Copy Link

@davidanthoff commented on GitHub (May 4, 2021):

Great, thanks for the update!

Could you maybe just check the actual content of the appx file of your UWP app and the appx file that you can download from my top post, and then unzip both and just see whether the fragment is stored differently?

@davidanthoff commented on GitHub (May 4, 2021): Great, thanks for the update! Could you maybe just check the actual content of the appx file of your UWP app and the appx file that you can download from my top post, and then unzip both and just see whether the fragment is stored differently?
claunia commented 2026-01-31 03:48:26 +00:00
Author
Owner
Copy Link

@PankajBhojwani commented on GitHub (May 4, 2021):

@davidanthoff can you try making this change in your appxmanifest file? (The change is the <uap3:Properties> block)
If that fixes it, then we are going to need to update our docs

Nevermind, ignore that!

@PankajBhojwani commented on GitHub (May 4, 2021): <del>@davidanthoff can you try making this change in your appxmanifest file? (The change is the `<uap3:Properties>` block) If that fixes it, then we are going to need to update our docs</del> Nevermind, ignore that!
claunia commented 2026-01-31 03:48:26 +00:00
Author
Owner
Copy Link

@davidanthoff commented on GitHub (May 4, 2021):

I just tried, and that doesn't seem to help :) Should I remove that again? Probably, right?

@davidanthoff commented on GitHub (May 4, 2021): I just tried, and that doesn't seem to help :) Should I remove that again? Probably, right?
claunia commented 2026-01-31 03:48:26 +00:00
Author
Owner
Copy Link

@PankajBhojwani commented on GitHub (May 4, 2021):

I just tried, and that doesn't seem to help :) Should I remove that again? Probably, right?

Yes, please remove it! I misunderstood its purpose when I told you to try it

@PankajBhojwani commented on GitHub (May 4, 2021): > I just tried, and that doesn't seem to help :) Should I remove that again? Probably, right? Yes, please remove it! I misunderstood its purpose when I told you to try it
claunia commented 2026-01-31 03:48:27 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 4, 2021):

Okay, so we just had a long debugging session. This is going to seem like the ravings of a crazy person . . . but I think there's a difference in how app extensions work¹ when the app is installed as part of a .appinstaller or with optional/dependency packages installed next to it.

I:

  • Accidentally used the 1.0.0.32 .appx directly
    • It worked, baffling @PankajBhojwani and me
  • Pulled down the appinstaller
    • It didn't work!
    • Terminal found the extension, but the platform told us that the folder didn't exist (???)
  • ... registered the contents of the app package separately, elsewhere
    • It went back to working (and then I unregistered it to make sure it wasn't a fluke)
  • ... installed the 1.0.0.34 .appx directly
    • It continued working

¹ which I will be taking up with the App Extensions team here at Microsoft :)

@DHowett commented on GitHub (May 4, 2021): Okay, so we just had a long debugging session. This is going to seem like the ravings of a crazy person . . . but I think there's a difference in how app extensions work¹ when the app is installed as part of a `.appinstaller` or with optional/dependency packages installed next to it. I: * Accidentally used the 1.0.0.32 `.appx` directly * It worked, baffling @PankajBhojwani and me * Pulled down the appinstaller * It didn't work! * Terminal found the extension, but the platform told us that the folder didn't exist (???) * ... registered the contents of the app package separately, elsewhere * It went back to working (and then I unregistered it to make sure it wasn't a fluke) * ... installed the 1.0.0.34 `.appx` directly * It continued working ¹ which I will be taking up with the App Extensions team here at Microsoft :)
claunia commented 2026-01-31 03:48:27 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 5, 2021):

To follow up - the App Extensions team actually found the root cause of this bug. Crazily, the AppInstaller actually does break this - and the underlying bug might date back to 2017.

This is being tracked internally in MSFT:33093453. We'll make sure to post if there are any updates internally. I'm not sure if there is any workaround at the moment.

@zadjii-msft commented on GitHub (May 5, 2021): To follow up - the App Extensions team actually found the root cause of this bug. Crazily, the AppInstaller actually does break this - and the underlying bug might date back to 2017. This is being tracked internally in MSFT:33093453. We'll make sure to post if there are any updates internally. I'm not sure if there is any workaround at the moment.
claunia commented 2026-01-31 03:48:27 +00:00
Author
Owner
Copy Link

@davidanthoff commented on GitHub (May 6, 2021):

Amazing, thanks for digging in!

I have to say, I very often felt like a raving crazy person when I tried to get App Installer to work, it does have... its quirks :) My overall conclusion after fighting with it for more than a year is that it simply is not ready for real world usage, just too many bugs, too little documentation, and if one tries to find out more details over at https://techcommunity.microsoft.com/t5/msix/ct-p/MSIX mostly it is just silence. So at least with the way that App Installer project is currently operating, I don't see us taking a dependency on App Installer in any case, we need something that we a) can rely on and b) where we get the impression that there is a team behind it that we can get in touch with somewhat directly, not via n layers of support tiers ;) Just saying, the way you guys here run the terminal stack: fantastic! Should be a role model for all MS teams.

BUT, my real plan for all of this is to get this MSIX installer into the Windows Store. My assumption is that the store seems to be used by a lot for real world apps (I mean, I have never ever seen any app in the wild use App Installer), hopefully has less bugs and maybe there is a better support story. And so my understanding is also that this bug is app installer specific, so maybe it isn't even there when we deploy via the store? So for now I guess I'll just leave the fragment pieces in as I have them right now. I'll report back once we have managed to get this installer into the store whether things work then.

Thanks again for the prompt response and feedback!

@davidanthoff commented on GitHub (May 6, 2021): Amazing, thanks for digging in! I have to say, I very often felt like a raving crazy person when I tried to get App Installer to work, it does have... its quirks :) My overall conclusion after fighting with it for more than a year is that it simply is not ready for real world usage, just too many bugs, too little documentation, and if one tries to find out more details over at https://techcommunity.microsoft.com/t5/msix/ct-p/MSIX mostly it is just silence. So at least with the way that App Installer project is currently operating, I don't see us taking a dependency on App Installer in any case, we need something that we a) can rely on and b) where we get the impression that there is a team behind it that we can get in touch with somewhat directly, not via n layers of support tiers ;) Just saying, the way you guys here run the terminal stack: fantastic! Should be a role model for all MS teams. BUT, my real plan for all of this is to get this MSIX installer into the Windows Store. My assumption is that the store seems to be used by a lot for real world apps (I mean, I have never ever seen any app in the wild use App Installer), hopefully has less bugs and maybe there is a better support story. And so my understanding is also that this bug is app installer specific, so maybe it isn't even there when we deploy via the store? So for now I guess I'll just leave the fragment pieces in as I have them right now. I'll report back once we have managed to get this installer into the store whether things work then. Thanks again for the prompt response and feedback!
claunia commented 2026-01-31 03:48:27 +00:00
Author
Owner
Copy Link

@davidanthoff commented on GitHub (May 23, 2021):

Alright, I now managed to publish the Julia MSIX in the Windows Store, and the fragment works perfectly there! So, clearly that is a bug in app installer and not related to the terminal. Thanks for helping me figure this out!

@davidanthoff commented on GitHub (May 23, 2021): Alright, I now managed to publish the Julia MSIX in the Windows Store, and the fragment works perfectly there! So, clearly that is a bug in app installer and not related to the terminal. Thanks for helping me figure this out!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Settings Issue-Bug Needs-Tag-Fix Product-Terminal Tracking-External
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#13649
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?