Wpf: 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.

[FilipFalcon]

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.

[FilipFalcon]

@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.

[FilipFalcon]

@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)).

[ohaucke]

@victorgoebel Because it's such a fundamental thing, that we think should be part of WPF. I don't want to rely on a third party implementation for something like that.

Who knows, maybe the next version will also miss the Textbox/Button/StackPanel/what ever, should we also rely on a third-party for that?

1. True, there is nothing wrong with using opensource projects but sometimes it doesn't make sense and the functionality should be build-in, or would you use something like the npm package is-odd which does nothing more than return (n % 2) === 1? That doesn't make any sense.

2. Who cares if they just copy it? As long as it is build-in, i'm fine with it.

3. Nobody wants that Microsoft is the single source for our libraries but something like that should be part of default implementation.

4. Also true but at the same time not, it is so simple that it would be easy to implement and it wouldn't take that long.

Nobody would complain if they just merge the code from someone other, we just want it to be part of the core functionality.