-
Notifications
You must be signed in to change notification settings - Fork 337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trying to use a FileOpenPicker while running the app as Administrator will crash the app #2504
Comments
I can confirm this bug. Any temporary workground for this? |
@Petrarca181 yes, you can use directly PInvoke with CsWin32, but it's too much overhead if you ask me. |
我在WindowsAppSDK 1.1 Preview 3中使用FolderPicker时遇到了同样的问题,但是我的程序需要提升的权限 |
@Petrarca181 I had to write my own with P/Invoke as well, It's basic and blocking / non-async, but gets the job done. Mostly copied from here.
Then, you can call it like so:
Or, if you must use naitive, you can work around this bug by running the rest of your code as admin, and this not as admin using impersonation. |
@manodasanW - crashes right at the PickSingleFileAsync() call. |
Yes, the problem still exist in WinUI3 with admin right. Please fix this! |
After discussing this with the filesystem team, the recommendation is to use the IFileOpenDialog apis from CSWin32. Here is a recent thread discussing this very topic - FileOpenDialog in CsWin32. |
@AdamBraden thank you for oferring this workaround. Any updates related to fixing the issue? |
What we could consider is creating a WinAppSDK wrapper around IFileDialog apis that provide an equivalent to the Picker apis. There are some opportunities to improve as well - StorageFiles are very heavyweight objects, and so we could consider returning something more optimized. |
FileOpenPicker/FileSavePicker 不支持管理员身份,见 microsoft/WindowsAppSDK#2504 改为使用 IFileDialog
@manodasanW, @MikeHillberg, @AdamBraden, hi! Any progress on this? I would appreciate an update. I'm curious how it goes. |
https://github.com/OpenKneeboard/OpenKneeboard/blob/e45bbfd46d953a562a9aaa59f38607472d9ea830/src/app/app-winui3/FilePicker.h and https://github.com/OpenKneeboard/OpenKneeboard/blob/e45bbfd46d953a562a9aaa59f38607472d9ea830/src/app/app-winui3/FilePicker.cpp are an example of using the |
WinUI3 makes me crazy for even basic stuff is not working. I return back to use electron. |
Indeed, such a simple thing like a FilePicker requires advanced knowledge and years of experience to understand. I'm a C# developer and I need to use unmanaged code with C++ to open a file picker...this is not how developement experience for WASDK should be. |
I just discovered that on Windows 10 it works. The problem is only on Windows 11. |
Same problem on windows 10 here. |
what version do you have? |
Any news? I have same problem |
Thanks to @castorix . I found workaround for me and made interpretation of it https://github.com/PavlikBender/Pickers |
It's 2024 and Windows App SDK has no working file dialog. What an achievement. |
Ah, seeing that new post reminded me that I never did follow up here. I rewrote my music server app in WPF and it runs perfectly on Win 10 & 11 and I can deploy it (copy the files to another PC) with ease! I can also run it 24 hours a day -- and use memory! It's amazing! I think this WPF thing could catch on! Or maybe I'm one of the few remaining developers who still write code they want to run on PCs and have no desire for a "UI framework" that throttles their memory usage and app performance. If I were targeting a mobile device or needed to worry about batteries, I would welcome such features -- and I'd probably have little need for an open file dialog. This could be a simple case of misinformation - I was under the impression that WinUI3 was for writing desktop apps. Honestly, I wish it were, but I don't think a framework that arrests so much control from the developer is going to succeed for serious desktop apps. |
Also, the browse folder picker can't pick the same folder next. To enable the selection button, one should trick the dialog buggy logic by going elsewhere and returning 😁. I went back to Winforms (win32) dialogs in WinUI 3.0 ✌🏻 |
This was reported over 2 years ago, I can't believe there is still no acceptable solution or at least a reliable workaround. After 6 weeks working on a new major project facing issue after issue after issue with this SDK this is the last one, I give up. This framework is certainly a massive load of crap and will spank the architect who decided for it lol. I rather rollback to WPF and lose a few weeks than getting frustrated with nonsense every 3 days for the next few months. |
FWIW, you can use Winforms's OpenFileDialog (or WPF) easily from WinUI3 https://stackoverflow.com/a/78842081/403671 |
YES. This is The Right Solution that should have been provided by Windows App SDK already. @AdamBraden @manodasanW @MikeHillberg |
It's been 2 years and there's still no proper solution to this? Using WinForms OpenFileDialog as a workaround shouldn't be an acceptable solution. |
This implementation works for me, but it's not on NuGet so you have to include it manually.
I feel your pain, I checked this thread again today when the WinUI 3 Gallery proudly announced it added a FilePicker sample, but no, it is still as broken as usual. |
Hit this today in .NET MAUI with unpackaged mode. Frustrating bug. :| |
The picker situation is aweful right now. For a packaged Desktop app there are two options:
So the only option might be to build a custom picker that uses WinRT APIs, I guess? What a mess. |
when you think for an whole hour you are crazy and you doing something wrong and founding then such a huge github issue about a file dialog, what the hell |
Over 2 years and still no fix? This means that the project is ranked low in the dev team meetings and just never makes the cut for release. This means that the framework is targeting mobile apps (that could maybe also run on a desktop). I wish Microsoft would just make that clear. There are a lot of decisions to make in choosing platforms and APIs for a project and letting people know that WinUI is not being developed as a desktop focused solution (but it might work for some scenarios) would be nice. It's sad that developers are wasting time with debugging and investigation of issues that have been known for years -- and for what are clearly basic operations. I mean if you're trying to inject a custom shader into the UI pipeline, you might expect to run into some issues -- but not when trying to open a file! I haven't revisited WinUI since my original post here and it has been on my "todo" list -- but I guess I can just remove it as there is, apparently, little progress in the direction I need for desktop/business apps/utilities. This truly saddens me. If/when I need to write a mobile photo viewer, I might check it out again... |
Is #4945 a fix for this issue? |
@MartyIX Interesting... Do you know if this works in AppContainer? The test app included there has |
No idea. Unfortunately. No response from the PR author. |
@MartyIX #4710 (reply in thread) |
Describe the bug
I am trying to open a File Picker but it works only if I am not using the app in elevation mode.
I'm getting the following error:
System.Runtime.InteropServices.COMException: 'Error HRESULT E_FAIL has been returned from a call to a COM component.'
The error appears when the code tries to execute the following line of code:
var file = await picker.PickSingleFileAsync();
Steps to reproduce the bug
AppWindowExtension.cs
App.xaml.cs
MainWindow.xaml.cs
Expected behavior
I would expect this basic feature of picking a file to work even if I run the app as admin.
My app has a lot of features that require elevation so getting rid of elevation is not an option for me.
Screenshots
No response
NuGet package version
1.4.2
Packaging type
Packaged (MSIX)
Windows version
Insider Build (xxxxx) (only on Windows 11)
IDE
Visual Studio 2022
Additional context
The same for FolderPicker
The text was updated successfully, but these errors were encountered: