WPF alternative for WinForms FolderBrowserDialog

[Jogge]

I'm missing a proper WPF-way to select a folder with a dialog.

Best answers on the internet says I have to reference WinForms and use the FolderBrowserDialog. I don't want to make a reference to WinForms just to make a dialog to select a folder.

WPF already have SaveFileDialog and OpenFileDialog...

Related links:
https://stackoverflow.com/questions/1922204/open-directory-dialog
https://stackoverflow.com/questions/4547320/using-folderbrowserdialog-in-wpf-application

[JohanLarsson]

There is https://www.nuget.org/packages/Ookii.Dialogs/ but agreed it would be nice with something built-in as the need comes up a lot.

[miloush]

Agree I am missing this often too. It is not even that difficult, since you just need to set PICKFOLDERS option on the already existing FileOpenDialog. There is FileDialog.SetOption method to manipulate the options, however, that is internal. Unfortunately it cannot be set by reflection either, since the options are filtered out when creating the dialog, not sure why.

Moreover, Visual Studio itself is using that dialog for File | Open | Folder...

[clairernovotny]

The WinForms dialog is a thin wrapper around the Win32 OS dialog. What would you expect differently in a WPF version?

Also, there's no harm in the WinForms reference as both WPF and WinForms are in the same shared desktop framework folder on-disk...i.e., it's there anyway.

[miloush]

The WinForms one is wrapper around an outdated, no longer recommended API. WPF uses the suggested IFileDialog instead for all the other dialogs and that is what I would expect it to use for this one too. As I said, it is the same dialog that you see when you do File > Open > Folder in Visual Studio.

[clairernovotny]

The WinForms dialog in .NET Core uses the newer API already, have you tried it?

[miloush]

In that case we agree on the implementation. WPF already has its own implementation of the API, why would you outsource one of the dialogs, break the inheritance chain and introduce a dependency on another assembly? (assuming the surfaced API is compatible with the one WPF already using)

[glyad]

The WinForms dialog in .NET Core uses the newer API already, have you tried it?
Anyway, why to bring sticking dependencies into newly developing framework? It looks like as Microsoft is looking for a reason to prevent porting of WPF to other platforms forever.

[glyad]

The WinForms dialog in .NET Core uses the newer API already, have you tried it?

We are not talking here about what's new in WinForms. We are talking about, what is missing in WPF.
What's worth with to have a customisable WPF control with Control Template, etc.? Probably it's off-topic, but same question I would be asked about MessageBox. Why not to add MessageBoxWindow with corresponding Control Template and PART's defined?
Anyway, IMHO, no framework should rely on dependencies from another non parent framework. The WinForms framework isn't a parent of WPF and even not a sibling.

[johmarjac]

Wow, I am actually shocked that something so essential is still missing.

[ghost]

It's one year and a half from the time that this issue was created and FolderBrowserDialog still haven't been implemented. I'm trying to use as updated technologies as possible in my applications and I think that WinForms are actually already deprecated and not used in modern coding anymore. Please correct me if I'm wrong. What's the issue of they still haven't implemented this to the WPF?

[miloush]

@Chyuae no new API is planned for the 5.0 release. New features are to be added later, see the roadmap. I have the new folder browse dialog implemented but I'm waiting for the codebase to enable testing API changes.

[ghost]

@miloush What do you mean by "new folder browser dialog"? Is there any workaround about ditching the WinForms dependency?

[miloush]

@Chyuae Well it's a shell dialog accessible through Windows API, so you can write your own wrapper, in the same way WinForms does it.

[ghost]

@miloush You mean like use Windows API Code Packs instead of the WinForms version? That still doesn't solve the issue, but is solid (?) workaround, I will try, thanks.

[nsivov]

The point is that most of the time from user perspective best way is to use system dialog that most of the applications are already using. It does not have to be implemented as a WPF component.

[nzain]

@nsivov it has to be implemented in WPF, otherwise you cannot use the system dialog, because WPF doesn't have it yet. The current implementation from Microsoft is in WinForms, not WPF.

[nsivov]

You probably mean that a wrapper has to be WPF, to avoid importing foreign winforms wrappers, in that case I misunderstood. I thought the request was about implementing system dialog completely in a form of WPF control.

[vitidev]

As I said, it is the same dialog that you see when you do File > Open > Folder in Visual Studio.

https://www.codeproject.com/Articles/5255769/Csharp-Select-FolderDialog-for-NET-Core-3-0

I don't know how it is production ready, but it causes a dialog like visual studio. You just need to correct the code and replace the DialogResult with bool? to remove the dependency to System.Windows.Forms

[Symbai]

There are tons of WPF folder picker dialogs ready to use. But what people here are looking for is a "native" implementation without any third party code. Just like Winforms.

[victorgoebel]

Have you seen Ookii Dialogs for WPF? It's a wrapper around the Windows API as far as I can tell, just like what the WPF team would have to do.

[ohaucke]

There are tons of WPF folder picker dialogs ready to use. But what people here are looking for is a "native" implementation without any third party code. Just like Winforms.

@victorgoebel Did you even read that comment? Why on earth should developers rely on a third party implementation for something so fundamental like a FolderBrowserDialog?

[victorgoebel]

@ohaucke I read the comments and I'm afraid I don't understand how some of you think and why you are pushing so hard for such a low-priority backlog item:

1. There's nothing wrong with using an opensource project that has been around literally for years (since 2009!), is still active and maintained, has over 300K downloads on nuget gallery, and is used by hundreds (if not thousands) of projects. It's also free and open - it's not like you have to pay $ for a Telerik license... People are literally working for free on something you can benefit from today

2. If Microsoft implements it, it will just be a copy of the code of Ookii Dialogs anyway because its just a little bit of C# that calls into the Windows API... What difference does it make if Microsoft adds the same code you already have?

3. It's 2020 and we don't have to wait for one vendor (Microsoft) to be the single source of our libraries. Are you saying that:

   • You don't use AutoMapper and are waiting Microsoft to provide something as fundamental as object mapping?
   • You don't use Swashbuckle / NSwag and are waiting Microsoft to provide something as fundamental as Open API? Guess what, Microsoft include Swashbuckle by default moving forward starting with .NET 5
   • You don't use FluentValidation to validate your DTOs and are waiting for Microsoft to provide something as fundamental as validation of DTOs?
   • You don't use Polly to retry failed operations until Microsoft provides something as fundamental as retry policies?
   • You're using MSTest to run your unit tests even though xUnit is much better (and even Microsoft uses it to test .NET Core)?
   • (the list goes on and on... You need to drop that old mindset of expecting/waiting Microsoft to provide you with libraries. Look into languages like Rust and Python, and you'll see that they do a bare minimum in-the-box and everything else is community-driven. That's the direction Microsoft is heading too an embrace the OSS ecosystem)

4. Resources are finite. Even Microsoft has limited resources with hundreds of projects to maintain. The WPF/WinForms Dialogs are a solved problem and the API has been added in Windows Vista many years ago... There are already opensource wrappers for these APIs as I suggested above. Why should Microsoft spend any effort on this? This has to be at the very bottom of the priority list. There are much bigger fish to fry...

Microsoft should should pull this project into the .NET Foundation and be done with it...

[nzain]

@victorgoebel you want to reduce dependencies, where you can. Installing and maintaining dependencies (potential conflicts, breaking changes, binding redirect hell) can be a pain in large projects. And you say it is easy to implement and everybody agrees that a folder browser dialog is fundamental. That's why it should be in WPF.

[miloush]

@victorgoebel Microsoft should spend effort on this because after SVG support, it is the most upvoted request in this repo. I was under the impression that acting on feedback from the community is part of the OSS ecosystem you are mentioning. (Also Ookii's implementation is definitely not how I expect the WPF wrapper to look like. Whether you use 3rd party libraries, wait for Microsoft or write it yourself is up to each of us (or our employers)).

[McoreD]

I am utterly shocked as well (like many here) to realise such a fundamental method is not available for WPF, for consistency. We are busy finalising .NET 6, and now moving into .NET 7, yet there is no Windows Forms FolderBrowserDialog equivalent for WPF. From .NET 5, were we not supposed to unify all methods and achieve consistency?

I am not interesting in invoking any Windows Forms libraries to browse for folders. We really need cross platform compatible calls which would be ideal.

[cameronbell97]

After updating one of my projects from .NET Framework 4.8 to .NET 5.0, I'm genuinely baffled I still have to deal with the rigmarole of finding new compatible third party packages, just for a standard folder browser dialog. I've needed a folder browser dialog in almost every WPF project I've worked on, and I fail to see how this essential bit of windows functionality still isn't natively supported in WPF.

[Bip901]

Came here after discovering that minimizing an application to tray is also not supported in WPF (we have to use WinForms' NotifyIcon instead). My WPF application is becoming a wrapper around the ancient WinForms!

[tomrus88]

Why is this still not fixed?

[idea-lei]

really sad that now is 2022 and we still got no wpf native implementation even in .Net 6...

[CleanCodeDeveloper]

@victorgoebel Microsoft should spend effort on this because after SVG support, it is the most upvoted request in this repo.

It is the most upvoted feature now... 98 upvotes and counting...

Search query

I understand that you think it is not worth the time to implement something like this. I would still ask you to implemented this basic and minor feature because there are developers out there who think WPF needs its own FolderBrowserDialog. Thanks in advance!

Edit:
Is this supposed to be the official solution??:

[trockefeller-pathway]

I recently started experimenting with .NET 6 and was thinking that maybe there were better options for opening a folder than there was before, and found this instead...

It's nice that the WinForms FolderBrowserDialog has been updated, so I figured that would be good enough, and it's easy enough to add.

But then, I started going down the rabbit trail of how am I going to deploy my shiny new .NET 6 desktop app because even someone with the most up to date Windows 10 won't have .NET 6 preinstalled, so I started looking into deployment options that were self-contained. I eventually got it to work, but my deployment ended up being around 150mb for a very simple application.

I eventually found the Trim option, and that sounded pretty promising. Only ship the parts of the framework that you need seemed like a great thing that was exactly what I was looking for. I turned on that option and this is what I got

Severity Code Description Project File Line Suppression State
Error NETSDK1175 Windows Forms is not supported or recommended with trimming enabled. Please go to https://aka.ms/dotnet-illink/windows-forms for more details. MyApp C:\Program Files\dotnet\sdk\6.0.101\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets 176

🤦‍♂️

The StackOverflow questions about this are over 12 years old.... can this not just be fixed? I would like to think that there is some legitimate complication that is holding things back, but it seems like everything is there, it's just not getting exposed in the APIs that are part of WPF.

[CleanCodeDeveloper]

Lets hope that our new Maintainers (announced here: WPF Responsibility Update) listen more to the community than the previous one. A good start would be to resolve this issue here.

[hotchkj]

I was also astonished to discover this has been so neglected; developers were complaining about this a decade ago; pretty sure I was one of them back then too. A few thoughts as I briefly attempted to come back to WPF (which looks to be short-lived at this rate):

• A number of proponents of 'just use open-source' appear to have waltzed past the legal licensing requirements, which not every company is happy to adopt as a developer or consume as a customer
• Ignoring that, we have components that need to be pure NET Framework with zero non-GAC dependencies
• The NET Framework Windows Forms dialog hasn't been updated to match style with the rest of the UI, and the linked SO discussion rightly points out that it looks awful & inconsistent - which professonal UI needs to get right
• While I know Microsoft would really like everyone aboard the NET 6 train, the rest of us have to live in reality, and reality is shipped NET Framework code that has to keep working
• The community appears to have tried twice to provide this as contributions which languished for months

The linked SO post also references WindowsAPICodePack which appears bobbing around in NuGet mainly because of re-uploads which may or may not be trustworthy; I can't find any reliable source code from Microsoft for this package, nor any reliable licensing information. Maybe that should just be resurrected properly? Perhaps provide the source to the community with a suitable Do-What-I-Like-With-It license and walk away, if that is the underlying intent?

I sometimes wonder if Microsoft appreciates that each time it abandons an incomplete framework for new shiny (Metro, WinUI, MAUI), all of the applications left in its wake have developers asking 'why not skip Microsoft next time...?'.

[CleanCodeDeveloper]

• While I know Microsoft would really like everyone aboard the NET 6 train, the rest of us have to live in reality, and reality is shipped NET Framework code that has to keep working

@hotchkj I hate to break it for you but .NET 6 does not solve this problem. Even with .NET 6 you are forced to use the Winforms FolderBrowserDialog.

[fuzzymannerz]

I have a university project to implement a folder browser system for file comparison and I think it's not designed to help me learn more about the syntax and how to create WPF applications like the previous projects were but rather a test of patience, frustration and how to find workarounds to what I would have otherwise thought to be a basic thing that was already included. This is crazy stuff.

[paulodiogo]

(removing a wrong ref to a package still maintained, sorry @augustoproiete)

Lets rely on a third party code, they said. This was a basic feature back then.

[augustoproiete]

@paulodiogo Don't be silly... The package was just renamed from Ookii.Dialogs to Ookii.Dialogs.Wpf.

https://github.com/ookii-dialogs

[SeriaWei]

Awaiting native support.

[Bip901]

I've been looking into migrating my project to Avalonia UI, which seems more active than WPF (and also offers cross-platform support). Their solution is simply Avalonia.Controls.OpenFolderDialog.

[njannink]

Because of delaying this feature it actually broke in the latest windows update. When do we get an official wpf folder browser?

https://developercommunity.visualstudio.com/t/Net472-Winforms-FolderBrowserDialog-empt/10182362?viewtype=all

[dawnbomb]

its 2023 and we still can't select a folder. As someone new to C#, this is infuriating to be forced to learn about implementing third party libraries when i'm really just trying to still learn the basics.

[pchaurasia14]

@dawnbomb - This is an item that we intend to work on in 2023. Check out the roadmap for other details.

[johnottone]

"Intending to work on" doesnt sound promising. It is supposed to be worked on after the Windows 11 Theming (something that should have been implemented for Light/Dark themes on Windows 10 and Windows 11). But I mean this has been a community request going back forever. I started using WPF in 2007. That's right...15 years and no folder browser. Im not getting my hopes up.

[Alexgoon]

I found this feature in the roadmap and wanted to thank the WPF team for considering implementing it. If you decide to move forward with it, I would like to suggest that you also consider the possibility of adding support for custom theming to the dialog window. Doing so would provide users with a more cohesive and personalized experience, as they would be able to customize the look and feel of the dialog to match the rest of their application.

Probably, supporting custom theming can be achieved without additional investments on your side, however, I wanted to make sure that you are keeping this in mind as you move forward with the implementation.