MSIX topics

MECM MSIX Application Creation Error

Crazylarry — Mon, 13 Apr 2026 09:34:43 GMT

Apologies if this needs to go into the MECM forum.

I receive the following error message when trying to import an MSIX into MECM: 'Error: Part URI is not valid per rules defined in the Open Packaging Conventions specification'. The MSIX is for Adobe InDesign 2026. I have successfully created MSIX packages for other Adobe Creative Suite products and imported them into MECM. I have been through the manifest for the InDesign MSIX I created, the file system, the metadata (such as package name) and can see nothing that would trip it up. I have also looked for any path lengths over 255 and found none. The only thing I found which I think may be a problem is in the content_types.xml - a tilda in the application extension entry:

As usual, there is not much online. I have skimmed through the OPC specification, but can see nothing about limitations. Have anyone else come across this problem?

App installer randomly timing out on version checking.

JohnMcC1983 — Tue, 27 Jan 2026 16:40:14 GMT

I have had my program installing via MSIX for over two years without any issue.

MSIX signing certificate persistent identity

JohnMcC1983 — Tue, 27 Jan 2026 16:22:41 GMT

undefined

Trying to MSIX package LOB application that needs TWAIN access

oconobee — Tue, 09 Dec 2025 13:50:17 GMT

So I think this isn't possible but I just wanted to ask.

I've a LOB application that needs to access TWAIN scanning devices.

How this works in a normal environment is that the TWAINDSM.dll (TWAIN Data source manager) is loaded from c:\windows\system32

This then scans the C:\Windows\twain_32 or C:\Windows\twain_64 depending on if the app is x86 or x64

The scanning manufacturers will have their TWAIN drivers installed to c:\windows\twain_32 (or 64) as subfolders and the TWAIN Data source manager scans these subfolders for available TWAIN devices that can be connected to.

All this breaks down in an MSIX environment because the container doesn't have access to C:\windows\twain_32\ManfactureDriverN folder

It can see the folders and when the TWAINDSM tries to initialize the driver it fails, most likely due to sandbox limitations.

Does anyone know of a solution to this, or apps like this will always need to stick to MSI packaging because of this limiation.

Thanks.

Publish Java application to Microsoft Store

tommerfrancis — Fri, 21 Nov 2025 13:49:05 GMT

Hello everyone, I want to know how to publish a Java application to Microsoft Store. Thank you very much.

Microsoft MSIX Packaging Tool Fails to create package due to AppXManifest (Typelib/Version/LibFlag)

TIMOTHY_MANGAN — Mon, 10 Nov 2025 17:08:51 GMT

The MMPT will fail to save the package after capturing an installation of Altova XmlSpy Enterprise. This is due to the MMPT reading a reading a registry string value for a Com Version and adding it into the AppXManifest in an incorrect form that violates the COM schema extension validation ST_VersionCom.

The error from the MMPT log:

[11/10/2025 11:17:46 AM] [Debug] MakeAppx : error: Failure at packageWriter2->Close( manifestStream, contentGroupMapStream.Get()) - 0x80080204 - The specified package format is not valid: The package manifest is not valid.
[11/10/2025 11:17:46 AM] [Debug] MakeAppx : error: Error info: /*[local-name()="Package" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/foundation/windows10"]/*[local-name()="Extensions" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/foundation/windows10"][1]/*[local-name()="Extension" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/com/windows10"][1]/*[local-name()="ComInterface" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/com/windows10"][1]/*[local-name()="TypeLib" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/com/windows10"][2]/*[local-name()="Version" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/com/windows10"][1]/@LibraryFlag
[11/10/2025 11:17:46 AM] [Debug] '#0' violates pattern constraint of '[0-9a-fA-F]'.
[11/10/2025 11:17:46 AM] [Debug] The attribute 'LibraryFlag' with value '#0' failed to parse.
[11/10/2025 11:17:46 AM] [Debug] Cleaning up output file "\\?\%UserProfile%\Desktop\Altova-XmlSpy_28.0.0.0_x64__xwfzvwzp69w2e.msix".
[11/10/2025 11:17:46 AM] [Debug] MakeAppx : error: Failure at (CreatePackage( overwrite, hashAlgorithm, fileList, outputPath, manifestStream.Get(), forceCompressionNone, performanceOptions, encryptPackage, encryptionOptions, cgmPath, mainPackagePathForResourceExemption, makepriExeFullPath)) - 0x80080204 - The specified package format is not valid: The package manifest is not valid.
[11/10/2025 11:17:46 AM] [Debug] MakeAppx : error: Package creation failed.
[11/10/2025 11:17:46 AM] [Debug] MakeAppx : error: 0x80080204 - The specified package format is not valid: The package manifest is not valid.
[11/10/2025 11:17:46 AM] [Error] MakeAppx.exe failed, exit code = 1
[11/10/2025 11:17:46 AM] [Error] Error Finalizing Package: Process MakeAppx.exe failed with exit code 1.

The values in the registry placed by the application that were captured:

And the produced AppXManifest file contained:

<com:TypeLib Id="744838d2-7537-47e2-affa-6e0d5fbb61c9">

<com:Version VersionNumber="1.0" LocaleId="0" LibraryFlag="#0">

<com:Win32Path Path="VFS\ProgramFilesX64\Altova\SharedBetweenVersions\AltovaScc32to64Bridge.exe" />

</com:Version>

</com:TypeLib>

As a workaround, it is possible to manually remove the '#' character from the LibraryFlag field in the AppXManifest allows the package to save.

The MMPT should properly read this value as if it were a REG_DWORD of value 0 and generate a valid AppXmanifest. This is a common registry interpretation to make. Alternatively, as the value of 0 is meaningless, the parameter could be dropped, but if the vendor had requested "#1" this should also be handled.

Shortcut icons disappear

WicCaesar — Fri, 31 Oct 2025 21:59:01 GMT

Hello! I wanted to add shortcuts of some applications to my desktop, then I found out it's impossible for a normal user. You have to either attach it to the task bar or the Start menu, and pray Microsoft won't mess up with your Start menu layout in the next update (happened twice already).

I found out this discussion and followed the instructions (going to explorer.exe shell:AppsFolder and creating shortcuts from there), but it only worked for a few minutes. In less than 10 minutes, two of the six shortcuts I've created using this method had their icons replaced by white paper icons. After restarting the computer, only one remained with its original icon (Figma Desktop). And after updating Figma, it completely disappeared (not leaving just a white paper, the shortcut completely vanished from the desktop). When I go to the same folder, they are iconless there as well.

So, how can I make desktop shortcuts that keep their nice icons even after restarting or updating the software? Thanks in advance!

Add Environment Variable to MSIX package using PSF Fixups in Packaging Tool - what am I missing?

Hanessa — Mon, 22 Sep 2025 09:04:12 GMT

Hi everyone,

I am currently testing packaging apps into the MSIX format and have been successful for any simple installers.

Now that I am trying to package more advanced installers I have to utilize PSF Fixups, in which I have issues with the Environment Fixup.
Even though I have read up on previous discussions regarding this, I simply cannot get this fixup to be successfully added and recognized within the MSIX App.
I am judging this based on that the same app will tell in its own app options whether the environment variable is available or not.

Some key info (Tried attaching several screenshots, but it wilI not let me. Hopefully the necessary information comes across):

Using MSIX Packaging Tool version 1.2024.405.0
Using the included PSF Fixup for Environment Variables within MSIX Packaging Tool.
All PSF Fixup files are included in the MSIX Package.
In the manifest file the executable "PsfLauncher64.exe" is pointed at.
Basically, the config.json is formatted in the following way if I were to change out anything referring to the actual app name.

What am I possibly missing out on or have misunderstood here? Any help in leading me into the right direction is very much appreciated, thanks!

Reset user choice for windows.protocol tel:

EDNT — Thu, 28 Aug 2025 09:02:25 GMT

Hi everyone,

we ship an MSIX that registers a full-trust Dialer.exe as a windows.protocol handler for tel: so users can place calls from Outlook etc.

Goal
After installing our MSIX, we’d like Windows to show the “How do you want to open this?” prompt again for tel: so users see the new option. With our old MSI this was easy, we deleted HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\<protocol>\UserChoice via the manifest entry:

Problem
With MSIX there seems to be no manifest option to mimic that. We tried deleting UserChoice on first app start (HKCU, RegDeleteTree/SHDeleteKey), but it did not work.

Questions

Is there any supported or recommended way to trigger the default-app prompt (or clear the choice) for a specific protocol when using MSIX?
Is deleting UserChoice from a full-trust MSIX app considered supported/allowed for Store submissions?

Any guidance or stance appreciated!

Thanks!

I'm not seeing what I expected to see with Windows Application Packaging

Rod-F — Sat, 23 Aug 2025 13:14:44 GMT

I'm following along in a YouTube video I found that covers MSIX. I've created a simple WPF app in .NET 9, which is just a Hello World app. Then I added the Windows Application Packaging project. Or at least that's what I'm trying to do. What I got was two new projects added to my VS solution. Given my app's name is MyApp, one of the new projects is called MyAppInstaller, and the other new app is called "MyAppInstaller (Package)". I was expecting to see only the MyAppInstaller project added. I'm wondering if I've done something wrong.

Why is it impossible to sign a .exe that is included in an msix?

Gregory Goeppel — Sun, 17 Aug 2025 14:19:25 GMT

I have a solution that has two projects. One projects makes a wpf exe. I call signtool in the post build step and it signs the .exe no problem. The other wapproj project publishes this into an msix and signs the msix bundle no problem. The .exe inside the .msix however is never signed. Why? The msix refuses to use the build output from the dependent project. I get the signing the bundle package prevents alteration on distribution, but this does nothing for protection after installation. No matter what I do I can't sign the contents inside the msix. Is this pointless? Why does Visual Studio only support signing the distribution package and not the contents inside the msix?

Issues Editing MSIX Package to Disable LaunchWhenReady

a570585 — Tue, 05 Aug 2025 17:58:53 GMT

We’re trying to disable the LaunchWhenReady setting in our MSIX package by following the guidance provided in Microsoft's documentation.
https://learn.microsoft.com/en-us/windows/msix/app-installer/how-to-create-custom-app-installer-ux
We initially tried using the MSIX Packaging Tool & Advanced installer to make the necessary changes in existing MSIX package, but were unable to get it working as expected.

Removal of an AppX/MSIX package leaving unwanted clutter in the user registry.

TIMOTHY_MANGAN — Sat, 02 Aug 2025 14:43:13 GMT

MSIX is supposed to be a clean uninstall. However, I have some detected some unnecessary garbage left behind when uninstalling under HKCU\Software\Classes.

Take a package and install it. Then Uninstall it.

Repeat that a few times.

Open Regedit. Browse to HKCU\Software\Classes.

Do a find on the package name,.

You will find there is a key starting with AppX (followed by random looking letters) with subkeys Application, DefaultIcon, and possibly Shell. These were added during the installation of the package.

Keep searching (F3). You will find the same information under an AppX... key for each package you originally installed.

This does not appear to be due to delayed removal, as they remain weeks or months later.

Encountered 0x80131500 code while using MSIX Packaging Tool

RookieArcher — Fri, 01 Aug 2025 00:07:56 GMT

Hi Guys,

Recently, when I tried to use MSIX Packaging Tool to convert the exe file to MSIX, I got the 0x80131500 error. Checking the log, I got the following part

[2025-07-31 7:14:04 PM] [Debug] MakeAppx : error: Failure at (packageWriter3->AddPayloadFiles( addedFiles, preparedFiles, performanceOptions.memoryLimit)) - 0x8007007b - The filename, directory name, or volume label syntax is incorrect. [2025-07-31 7:14:04 PM] [Debug] Cleaning up output file "\\?\%UserProfile%\OneDrive\Desktop\My-Package_1.0.0.0_x64__tn3vmbmc1d5kj_1.msix". [2025-07-31 7:14:04 PM] [Debug] MakeAppx : error: Failure at (CreatePackage( overwrite, hashAlgorithm, fileList, outputPath, manifestStream.Get(), forceCompressionNone, performanceOptions, encryptPackage, encryptionOptions, cgmPath, mainPackagePathForResourceExemption, makepriExeFullPath)) - 0x8007007b - The filename, directory name, or volume label syntax is incorrect. [2025-07-31 7:14:04 PM] [Debug] MakeAppx : error: Package creation failed. [2025-07-31 7:14:04 PM] [Debug] MakeAppx : error: 0x8007007b - The filename, directory name, or volume label syntax is incorrect. [2025-07-31 7:14:04 PM] [Error] MakeAppx.exe failed, exit code = 1 [2025-07-31 7:14:04 PM] [Debug] Finalizing the conversion state [2025-07-31 7:14:04 PM] [Debug] Getting environment object from %UserProfile%\AppData\Local\Packages\Microsoft.MSIXPackagingTool_8wekyb3d8bbwe\LocalState\MsixGenerator.ConversionState.xml [2025-07-31 7:14:04 PM] [Warning] Error Occurred: Microsoft.Msix.Utils.ProcessRunner.ProcessRunnerException: Process MakeAppx.exe failed with exit code 1. at Microsoft.Msix.Utils.ProcessRunner.ProcessRunnerBase.ValidateExitCode(Int32[] validCodes) at Microsoft.ApplicationVirtualization.Packaging.Packager.FinalizePackageViaMakeAppx(IPackageFiles packageFiles, String manifestPath, String appvManifestPath, String registryHivePath, Boolean useExistingRegisterHive, String userRegistryHivePath, String userClassesRegistryHivePath, String packagePath, String msixMappingPath, CompressionOption compression, MsixPackageInputProperties msixPackageInputProperties, CancellationTokenSource cancellationTokenSource) at MsixGenerator.MsixPackageEditor.FinalizePackage(CancellationTokenSource cancellationTokenSource, Boolean modifyExistingPackage) at MsixPackagingTool.ViewModel.PackageEditorWorkflow.MasterPackageEditorViewModel.SavePackageEditorChanges_BackgroundWorker(Object sender, DoWorkEventArgs doWorkEventArgs) at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)

So far, it seems that \\?\%UserProfile% is causing the issue. But I am not sure how to solve it.

The following is the manifest file I used.

<?xml version="1.0" encoding="utf-8"?> <Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10" xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10" xmlns:uap10="http://schemas.microsoft.com/appx/manifest/uap/windows10/10" xmlns:desktop7="http://schemas.microsoft.com/appx/manifest/desktop/windows10/7" xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" IgnorableNamespaces="uap uap10 desktop7 rescap">  <Identity Name="My-Package" Publisher="CN=Dummy Publisher" Version="1.0.0.0" ProcessorArchitecture="x64" /> <Properties> <DisplayName>My-Package</DisplayName> <PublisherDisplayName>Dummy Publisher</PublisherDisplayName> <Description>Dummy description.</Description> <Logo>Assets\StoreLogo.png</Logo> <uap10:PackageIntegrity> <uap10:Content Enforcement="on" /> </uap10:PackageIntegrity> </Properties> <Resources> <Resource Language="en-us" /> </Resources> <Dependencies> <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22000.1" /> </Dependencies> <Applications> <Application Id="MyApplication" Executable="VFS\AppVPackageDrive\MyApplication\MyApplication.exe" EntryPoint="Windows.FullTrustApplication"> <uap:VisualElements BackgroundColor="transparent" DisplayName="MyApplication" Square150x150Logo="Assets\MYAPPLICATION-Square150x150Logo.png" Square44x44Logo="Assets\MYAPPLICATION-Square44x44Logo.png" Description="MyApplicatiion"> <uap:DefaultTile Wide310x150Logo="Assets\MYAPPLICATION-Wide310x150Logo.png" Square310x310Logo="Assets\MYAPPLICATION-Square310x310Logo.png" Square71x71Logo="Assets\MYAPPLICATION-Square71x71Logo.png" /> </uap:VisualElements> </Application> </Applications> <Capabilities> <rescap:Capability Name="runFullTrust" /> </Capabilities> </Package>

Could someone help me solve this issue? Thanks!

.WapProj build using "unvirtualizedResources" removed entry from manifest

TIMOTHY_MANGAN — Fri, 04 Jul 2025 21:27:59 GMT

I have a .wapproj that needs to use RegistryWriteVirtualization (aka "Flexible Virtualization) as described in Flexible virtualization - MSIX | Microsoft Learn

This is for an MSIX package that will not be delivered via the Microsoft Store.

The changes are made to the Package.appxmanifest file, and saved.

The build action in Visual Studio removed the Capability declaration line for "unvirtualizedResources" from the Package.appxmaifest file before processing the file, leading to an error complaining that the RegistryWriteVirtualization requires this capability.

Workaround: I can mark the file read-only outside of Visual Studio to keep VS from changing the file as a temporary workaround to prove out that the code depending upon these settings works.

Why workaround is not acceptable: This workaround is not long-term viable, as other developers and automated workflows working on the project will lose the read-only setting (as it will not persist in GitHub) and have a broken build.

It is clear that the VS code looking at this file is aware of both the desktop6 and virtualization schemas and their requirements and restrictions, but seemingly, although aware of other rescap capability extensions is unaware of this one.

Requested action: Please add support for missing capabilities declarations in Visual Studio and/or underlying tools.

MSIX .wapproj service

DataBen — Fri, 27 Jun 2025 15:41:42 GMT

My agency is trying to move their services to MSIX/UWP and we found that the VisualStudio .wapproj .appxmanifest templates $targetnametoken$ and $targetentrypoint$ do not work for the properties 'Executable' and 'Entrypoint' of 'desktop6:Extension' tags with 'Category="windows.service"' despite working as expected on the enclosing 'Application' object.

Can someone who knows how this is intended to work please help?

I'm desperate at this point.

VirtualizationManifestSchema needs correction

TIMOTHY_MANGAN — Thu, 19 Jun 2025 16:12:46 GMT

The version of the VirtualizationManifestSchema.xsd delivered as part of Visual Studio is still incorrect (I reported this about three years ago). It seems like the DesktopAppInstaller either ignores the regex pattern for the ST_ExcludedDirectory element or is using a fixed version for validation anyway. But other toolings depend on the accuracy of the published schema file for XML validation and it needs to be fixed.

As stands, it looks like this:

<xs:simpleType name="ST_ExcludedDirectory">
<xs:restriction base="t:ST_NonEmptyString">
<xs:pattern value="$$[kK][nN][oO][wW][nN][fF][oO][lL][dD][eE][rR]:[A-Za-z0-9]{1,32}$(\\.+)?"/>
</xs:restriction>
</xs:simpleType>

It should be:

<xs:simpleType name="ST_ExcludedDirectory">
<xs:restriction base="t:ST_NonEmptyString">
<xs:pattern value="\$$[kK][nN][oO][wW][nN][fF][oO][lL][dD][eE][rR]:[A-Za-z0-9]{1,32}$(\\.+)?"/>
</xs:restriction>
</xs:simpleType>

This change would support the Syntax section shown in the documentation here: virtualization:ExcludedDirectory - Windows UWP applications | Microsoft Learn

unable to create a windows developer account

Rahmann — Thu, 12 Jun 2025 22:04:25 GMT

it displays like this on both chrome and edge (waht I've tried).
'Accept and continue' button doesn't activate no matter what.
I didn't find a place where I can post this issue except here.

Unable to upload msixupload-file to Microsoft Store

VolkerCgn — Mon, 09 Jun 2025 08:56:00 GMT

Drag & Drop doesn't work. Upload file dialog ist hidden.

Msix packaging tool update

atplsx — Tue, 20 May 2025 17:05:02 GMT

There hasn't been a new version for a long time. Frankly, I think you need to distribute a better structure with better psf integration. Please don't leave this topic idle.