SOLVED

Duplication Shortcuts on Win11

MVP

[NOTE: This was submitted via Feedback hub also, making it visible to others]

 

Apps repackaged with the MSIX Packaging Tool (2023.118 and 2023.321) that have shortcuts with arguments now have an additional desktop7:shortcut element. This el is ignored on Win10 but supported on Win11. This is causing an additional copy of the shortcut in the start menu on Win11 (with an incorrect icon).

 

The icon with the correct icon starts the app, however the command line arg is not present (win10/11). The icon with the incorrect icon (Win11) does not result in a launch at all.

 

An example application producing this behavior is Telerik Fiddler (Classic). The native installation produces two shortcuts. I am attaching screen shots of how the start menu looks with the MSIX package on both Windows 10 and Windows 11, a screen shot of the relevant AppXManifest entry for one of the applications, and a completed package. I am also adding a screen-shot from the Task Manager that shows the command line when the Start menu entry for "Fiddler 4" with correct icon is run.

 

It seems that when desktop7 extension is used, it should replace (rather than augment) the entry normally created by the visual elements, but there are clearly issues with the shortcut being generated.  It looks like an AppInstaller issue to me, but possibly in the packaging.

23 Replies
Oh, and while looking at this... When you install the app using appinstaller, all 4 shortcuts appear in the "Recommended" area of the start page. After uninstall, the entries with the correct icons (from visual elements) go away but the other two entries remain. Those should cleanup on uninstall also.

Thanks for the details, @TIMOTHY_MANGAN. We were able to reproduce the issue, and are looking into it.

@Aniket_Banerjee, Is there any update on this issue fix ?
Facing a similar issue here, any workarounds at the moment?

@uvinabeysinghe Remove the desktop9 shortcut from the manifest if you don't need the parameters.  Otherwise TMEditX can detect and repair for you.

 

 

best response confirmed by TIMOTHY_MANGAN (MVP)
Solution
PS: The issue will be resolved using TMEditX 6.5 or above, although Microsoft may have also addressed in in their latest MMPT release which arrived in parellel - I'm not sure.

No, Microsoft didn't fix the issue with the MSIX Packaging Tool. I have exactly the same problem with the application I'm developing.
When installed from the MSIX it creates 2 shortcuts in "Applications", one is broken, another one works fine. But because of this Microsoft wants to take down my app from the store, because from their point of view there is no icon in the Start Menu... However as you said this is the Microsoft's fault.
I will try to fix it somehow by myself (you gave some hints), but if I will not be able to, then I guess I will have to ask you how you fixed it... We'll see.

 

[Edit] I tried to remove the Extension element from the AppxManifest.xml, we'll see if it will work.

Since you are a developer, If you don't need command line parameters, just remove the desktop9:shortcut element of the application extension. If you do need parameters, then do the following: 1) add AppId="None" to the VisualElements element of the application, this removes the "good shortcut". 2) fix the desktop9:shortcut. This involves creating a proper lnk file in the VFS path listed on that element with a proper icon in it.

Removing whole Extensions element worked... Thank you for your thread, it helped a lot.

Hi @TIMOTHY_MANGAN 
This issue has now been fixed with the latest Windows App SDK - 1.4.2 update. 

Thanks,
Fiza 
PM, MSIX Team

@Fiza_Azmi As we are repackaging traditional apps, we are not using the Windows App SDK, so I'm not sure that is related to this. Unless,, that is, that the MSIX Packaging Tool is using the SDK; in which case we'd be waiting for a new release of that tool which is built with the fix?

@TIMOTHY_MANGAN 

This is mainly required to get Win App SDK runtime.
For packages that want to create Shortcuts, you just need to add Win App SDK (Min Version: 1.4.2) to the dependencies list in your Manifest as below:

 

<PackageDependency Name="Microsoft.WindowsAppRuntime.1.4" MinVersion="4000.1010.1349.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />

 

App Installer will download it for you during installation. If you are using Powershell command or other means to install, you can download Win App SDK from here.

 

In the upcoming releases, the MSIX Packaging Tool will automatically add this dependency when it detects shortcuts.

@Fiza_Azmi Thank you for the explanation.

 

Is it necessary to declare the package dependency, or is it sufficient to ensure that the dependency is already deployed? 

 

The reason for the ask is that currently, traditional desktops apps repackaged into MSIX do not normally declare dependencies (yes, they could -- but we don't usually need to).  Such dependencies may lead to deployment issues with tooling not expecting them.  For example, MSIX App Attach is believed to ignore explicit dependencies.

 

Thanks!

Tim

@TIMOTHY_MANGAN It's not necessary to have the package dependency if you can ensure that the dependency is already deployed.

@TIMOTHY_MANGAN 

We have repackaged VLC using MSIX Packaging tool 1.2023.807.0 and it creates the desktop7 entries. But they are ignored both of Windows 10 and 11 (even on latest canary insider build). When the package is installed we only get 1 shortcut that is defined in the application section and no other shortcuts are visible in the start menu. 

@Fiza_Azmi we also tried adding the mentioned dependency and it still did not create more than 1 shortcut in the start menu. Are we missing anything?

 

Here is a sample of the desktop7 entries:

            <desktop7:Extension Category="windows.shortcut">
               <desktop7:Shortcut File="[{Common Programs}]\VideoLAN\VLC media player - reset preferences and cache files.lnk" Icon="[{Package}]\VFS\ProgramFilesX86\VideoLAN\VLC\vlc.exe" Arguments="--reset-config --reset-plugins-cache vlc://quit" />
            </desktop7:Extension>
            <desktop7:Extension Category="windows.shortcut">
               <desktop7:Shortcut File="[{Common Programs}]\VideoLAN\VLC media player skinned.lnk" Icon="[{Package}]\VFS\ProgramFilesX86\VideoLAN\VLC\vlc.exe" Arguments="-Iskins" />
            </desktop7:Extension>
            <desktop7:Extension Category="windows.shortcut">
               <desktop7:Shortcut File="[{Common Programs}]\VideoLAN\VLC media player.lnk" Icon="[{Package}]\VFS\ProgramFilesX86\VideoLAN\VLC\vlc.exe" />
            </desktop7:Extension>

 

After installing, did you check the AppX event logs? They might provide a clue. Get-AppXLogs

@TIMOTHY_MANGAN Nothing suspicious in event logs. I have attached a picture from the logs and the start menu and the manifest. This a non-modified manifest produced by MSIX packaging tool. I have never seen desktop7:Shortcut working. We have tried multiple Windows 11 release versions both physical and virtual and even insider builds.

@Edijs_Perkums_MasterPackager Can you confirm the version of Windows App SDK installed in your machine? Run below command in powershell:

Get-AppxPackage *Microsoft.WindowsAppRuntime.1*

@ravishroshan 

 

Name              : Microsoft.WindowsAppRuntime.1.3
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X86
ResourceId        :
Version           : 3000.934.1904.0
PackageFullName   : Microsoft.WindowsAppRuntime.1.3_3000.934.1904.0_x86__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.3_3000.934.1904.0_x86__8wekyb3d8bbwe
IsFramework       : True
PackageFamilyName : Microsoft.WindowsAppRuntime.1.3_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

Name              : Microsoft.WindowsAppRuntime.1.3
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X64
ResourceId        :
Version           : 3000.934.1904.0
PackageFullName   : Microsoft.WindowsAppRuntime.1.3_3000.934.1904.0_x64__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.3_3000.934.1904.0_x64__8wekyb3d8bbwe
IsFramework       : True
PackageFamilyName : Microsoft.WindowsAppRuntime.1.3_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

Name              : Microsoft.WindowsAppRuntime.1.4
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X86
ResourceId        :
Version           : 4000.1010.1349.0
PackageFullName   : Microsoft.WindowsAppRuntime.1.4_4000.1010.1349.0_x86__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.4_4000.1010.1349.0_x86__8wekyb3d8bbwe
IsFramework       : True
PackageFamilyName : Microsoft.WindowsAppRuntime.1.4_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

Name              : Microsoft.WindowsAppRuntime.1.4
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X64
ResourceId        :
Version           : 4000.1010.1349.0
PackageFullName   : Microsoft.WindowsAppRuntime.1.4_4000.1010.1349.0_x64__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.WindowsAppRuntime.1.4_4000.1010.1349.0_x64__8wekyb3d8bbwe
IsFramework       : True
PackageFamilyName : Microsoft.WindowsAppRuntime.1.4_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok
1 best response

Accepted Solutions
best response confirmed by TIMOTHY_MANGAN (MVP)
Solution
PS: The issue will be resolved using TMEditX 6.5 or above, although Microsoft may have also addressed in in their latest MMPT release which arrived in parellel - I'm not sure.

View solution in original post