WindowsAppSDK: Unable to release to the Microsoft Store
Describe the bug
I have a very simple app built with Visual Studio 2022, using the new WinUI 3 Blank Project template. The app works normally when installed via Visual Studio (using the Packaged target), but when published on the Microsoft Store and downloaded on a brand new Windows 10 or 11 system, it crashes on startup with the following error:
CoreCLR Version: 6.0.121.56705
.NET Version: 6.0.1
Description: The process was terminated due to an unhandled exception.
Exception Info: System.DllNotFoundException: Unable to load DLL 'Microsoft.ui.xaml.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)
at MyProgram.Program.Main(String[] args)
}
I found #1762 , which seems to be having the same problem and the proposed solution is to install the VCRedist on the target machine. Doing this, fixes the crash.
As the linked issue is marked as closed, I’m opening this new one because that solution isn’t really feasible for apps distributed via the Microsoft Store. It means that people that download the app from the Store need to be instructed on how to install the aforementioned library, otherwise they’ll never be able to run the app. Also, the only page I could find where there are download links (the one linked above), it’s not very user friendly and seems to be addressed to developers.
Steps to reproduce the bug
- Create a new WinUI 3 Blank Project with Visual Studio 2022.
- Publish the project to the Microsoft Store.
- Install it on a new Windows 10/11 machine without any additional software installed.
Expected behavior
The Microsoft Store should take care of installing the required dependencies, if they aren’t available. In alternative, a NuGet package could be provided to allow apps to embed the VCRedist.
Screenshots
No response
NuGet package version
1.0.0
Packaging type
Packaged (MSIX)
Windows version
Windows 11 version 21H2 (22000), Windows 10 version 21H2 (19044, November 2021 Update), Windows 10 version 21H1 (19043, May 2021 Update), Windows 10 version 20H2 (19042, October 2020 Update)
IDE
Visual Studio 2022
Additional context
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 2
- Comments: 16 (9 by maintainers)
@MrAsterisco - this is a bug in the Single Project MSIX packaging vsix. For 1.0, it should have the vclibs dependency. Note that if you use the Windows Application Packaging Project (*.wapproj) it correctly includes the vclibs dependency. You can manually add the correct version to your package manifest:
o Release -
<PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.30035.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"/>o Debug -<PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.30035.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"/>Docs were updated recently to call this out: https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/deploy-packaged-apps#prerequisites
fyi @Scottj1s
The CRT will no longer be a prerequisite. Technically that ‘goes away’ through a mix of relying on OS APIs for some things and embedding into our binaries for the rest.
The essence of what you’re asking, Yes.
Technically when you hit install an app from the Store there may be multiple transfers over the wire from Store to the PC. So there may be >1 download but the user experience is there’s 1 action - tap the Install button. No additional effort by the user.
Q2 2022, per the roadmap
A more appropriate workaround would be to add a package reference to the UWPDesktop C/C++ libraries. https://docs.microsoft.com/en-us/troubleshoot/developer/visualstudio/cpp/libraries/c-runtime-packages-desktop-bridge
This will install with your package, and avoid the need for customers to separately install the VC redist.
Ben
As a workaround does the problem still occur if you add a VCLibs dependency to your appxmanifest?
Not sure if that’s the right MinVersion but should be enough to see if it satisfies the missing DLL dependency.