Reset user choice for windows.protocol tel:
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: <RemoveRegistryKey Id="WipeDialerOnInstall" Root="HKCU" Key="SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\tel\UserChoice" Action="removeOnInstall"/> 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!.WapProj build using "unvirtualizedResources" removed entry from manifest
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.I'm not seeing what I expected to see with Windows Application Packaging
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.Encountered 0x80131500 code while using MSIX Packaging Tool
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"> <!--Package created by MSIX Packaging Tool version: 1.2024.405.0--> <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!MSIX .wapproj service
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.
Running windows service that's a part of a Desktop Bridge WFP app blocks update
I have a WPF application that has been packaged using DesktopBridge into MSIX and submitted to the Microsoft Store. This application has a WPF UI component, and it also has a windows service component that runs in the background whenever the PC is turned on. The UI component is used for configuring user settings and credentials for the windows service, and the windows service is actually the main component of this app. It's designed this way because of our client's needs. The problem that I'm running into is that when we publish a newer version to the Microsoft Store, the app fails to update with an error "0x80073D02: The package could not be installed because resources it modifies are currently in use" It looks like this is caused by the running windows service, and the store app update is not able to stop the service before the update replaces the files in the VFS. When the user manually stops the windows service, the update completes just fine and restarts the windows service as expected. When testing the update using different versions of MSIX files, I noticed that appending the flag -ForceApplicationShutdown to the Add-AppPackage command will achieve what I need, but this doesn't seem to be an option in the windows application packaging project, or in the Microsoft Store submission process. I know that including a windows service within an MSIX package is a restricted capability, so is this behavior due to the usage of this restricted capability? Also, is there a fix or workaround that will allow the update process to automatically stop the windows service before trying to replace the files? Thank you for any help or suggestions, and I'm happy to provide any additional information needed.AppCompat with MSIX
Hi, I'm repackaging some (very) old apps in MSIX, and I'm facing a situation where I need to enable some app compatibility shims. I've tried doing this with the `registry.dat` registry hive, but it doesn't seem to work. I think I've heard something about using SDB in a MSIX package once, but I might be imagining things. Right now I've resorted to using an ImportRedirectionTable and a redirection DLL, but this only works for simple cases like Windows version lie. It would be amazing if there was a way to use an SDB inside a MSIX, but if the registry option could work, that'll do too. Did anybody manage to make this work? Thanks!
MSIX product name issue
Hello, Please advise when creating Msix packages, how can I set different product names to be shown in the: Start Menu > Applications < My Product > vs Settings > Apps < My Product Pro > Generally, in which fields these 2 names are set? Thanks for the info, highly appreciated :)Unable to build APPXUPLOAD from .NET 9.0 / C# / WinForms project
Hi! We were advised by Microsoft Visual studio Developer community to create this issue on GitHub. But it was wrong direction. So, you're the third instance where we're trying to solve it. We hope that it is relevant to this section. Please, let us know if not. The corresponding threads can be found https://developercommunity.visualstudio.com/t/Unable-to-build-APPXUPLOAD-from-NET-90/10892325 and https://github.com/dotnet/winforms/issues/13377. --- The essence We’ve met this problem during the project (C#, WinForm) migration from .NET Framework 4.8.1 to .NET 9.0. Steps to see the problem We’ve migrated the project, compiled it and tested its functionality. Here we’ve found out that we are now required to publish the app with the .pubxml profile to make a single and not self-contained .exe instead of .exe-.dll-.json-.json… whatever this supposed to be. Using the publishing profile we’ve obtained the single-file executable that we’ve tested on Win10-x64 and Win7-x86. Both tests have been passed. The installation of .NET 9.0.4 desktop redistributables is not the problem for our aims. It is even better to not to “take” it with the executable. We’ve removed the .NET Framework project and added the .NET 9.0 project to the .wapproj dependencies without other changes. After this we get 3 warnings (fig. 1) about compatibility. After that we can get two results: The builder can create a 100Mb bundle for 450Kb executable or (if single file option is enabled) 100Mb the-entire-OS-in-one-file executable. So, we literally can build package. But it will completely ruin the user (who downloads the app from Microsoft Store) experience. Not to mention that such an installation size is simply inadequate for the goals and objectives of the product. With another project (we've tried it too) the builder can refuse to build the code during to non-existing errors (like missing ‘using’ directive). Exactly the same code has been successfully built during the publishing process 10 seconds ago. Our thoughts: there is some problem in the .wapproj file and/or in the MSIX builder. Because all warnings and errors come from the step before zipping .MSIXs into .appxbundle. --- How to reproduce directly Use this project to build a single-file-exe: https://github.com/user-attachments/files/19913854/TestProject_NET9.zip. This is the partial copy of our actual product without our own sensitive assemblies. It’s free for testing (available on GitHub). Add the new MSIX/APPX packaging project, connect the .NET 9.0 project to it. We can only provide our sample of .wapproj, without certificates and thumbprints, just to check its properties and verify its integrity: https://github.com/user-attachments/files/19913870/ScreenShooter_MSIX.zip. Try to publish the bundle. Tried workarounds Creating new .wapproj: no effect Clearing all building directories and caches: no effect Updating NuGets: no effect Other notes Also when builder tries to do its work we can see about 900 warnings about possible compatibility problems for basic methods from System, System.Windows.Forms and other assemblies. So, now we can still publish Android apps, APKs, Windows MSI packages, EXEs. But we cannot build apps for Microsoft Store. Which is not funny at all. --- So, how can we fix it? We’ve lost 6 hours in search. But found nothing useful. Thank you in advance, RD AAOW FDL
