WinUI application closed by 'X' but remains as dormant proc
See original GitHub issueDescribe the bug
I close the WinUI application by pressing ‘X’ on the window but remains dormant and must kill it in the Task Manager.
Steps to reproduce the bug
Create new app and derive App : PrismApplication
Expected behavior
No response
Screenshots
No response
NuGet package version
WinUI 3 - Windows App SDK 1.1 Preview 3: 1.1.0-preview3
Windows app type
- UWP
- Win32
Device form factor
Desktop
Windows version
Windows 10 (21H2): Build 19044
Additional context
Request the information you need and ll provide.
Issue Analytics
- State:
- Created a year ago
- Comments:18 (10 by maintainers)
Top Results From Across the Web
WinUI3 in Existing Win32 Applications
Create a new project in Visual Studio "Blank App, Packaged, WinUI 3" in Desktop. Close the project and open the .vcxproj with a...
Read more >Keep the UI thread responsive - UWP applications
Users expect an app to remain responsive while it does computation, regardless of the type of machine.
Read more >Building Modern Desktop Apps—Is WinUI 3.0 the Way to Go?
WinUI 3.0 is the hot new framework for desktop application development. In this post we'll try to answer the questions “What is WinUI...
Read more >Application is still running in memory after Application.Exit ...
The application I am building is still running in memory (checked in Task Manager) after it is closed using Application.Exit() . Because of...
Read more >WinUI 3 | XAML Brewer, by Diederik Krols
It provides mapping support for Microsoft's XAML platforms WPF, UWP, and WinUI 3. Here's a screenshot from the small sample app in the...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
That is very interesting, good find! I’m not too concerned about the package size right now since I’m not currently publishing that app in the WinUI 3 version anyway (I’m only publishing the UWP version right now, as it’s noticeably faster, consumes less resources, ships as an AOT binary and also has a much smaller package size), but I might as well leave the workaround in there for now to keep things simpler. I hope this discovery will help the investigation though! 😄
Unfortunately I don’t, no 🥲 Getting a full swap chain sample running from scratch is a fair amount of work, and I’ve had no motivation to try to do that without reusing my library, given those samples are all meant to be a showcase of it. It’s certainly possibly to do so (and the code in the library can also be used as a reference, in part), it’s just not trivial work and it might require some time 😅
@Sergio0694 i have some lead. I have a workaround (you can also continue the workaround you have).
the bug doesn’t appear if your app is self-contained. if you edit csproj of your app and set
<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
, this problem goes away. I am trying it onComputeSharp.SwapChain.WinUI.csproj
in your main repo. This is good news. though switching to self contained will increase your package size as everything will be bundled together.So, the bug only appears if you are using winappsdk as a runtime rather than a self contained binary. This is an interesting lead. Do you have a swap chain winui sample project which doesn’t include compute sharp library ? It will simplify debugging for me.
(@bpulliam / @gabbybilka we should add a swapchain sample winui app in winappsdk samples)