Introduction

WPF ships with file dialogs, but it does not provide a dedicated folder picker in the same way. In practice, most WPF applications either call the WinForms folder dialog or hide that dependency behind a small service so the rest of the UI stays clean and testable.

Use the Windows Folder Picker from WPF

The most common solution is System.Windows.Forms.FolderBrowserDialog. Even in a WPF application, it is a practical choice because it is built into the .NET desktop stack and works reliably for normal Windows desktop tools.

The simplest version can live in a button click handler:

1using System.Windows;
2using System.Windows.Forms;
3
4namespace FolderPickerDemo;
5
6public partial class MainWindow : Window
7{
8    public MainWindow()
9    {
10        InitializeComponent();
11    }
12
13    private void PickFolder_Click(object sender, RoutedEventArgs e)
14    {
15        using var dialog = new FolderBrowserDialog
16        {
17            Description = "Select an output folder",
18            ShowNewFolderButton = true,
19            UseDescriptionForTitle = true
20        };
21
22        var result = dialog.ShowDialog();
23        if (result == System.Windows.Forms.DialogResult.OK)
24        {
25            SelectedPathTextBlock.Text = dialog.SelectedPath;
26        }
27    }
28}

This approach is enough for a simple internal utility or admin tool. The dialog returns the selected directory through SelectedPath, and the code stays easy to read.

Respect Window Ownership

The first version works, but it can behave poorly if the dialog is not owned by the active WPF window. Unowned dialogs may open behind the main window or lose focus. You can avoid that by passing a lightweight wrapper around the current window handle.

1using System;
2using System.Windows;
3using System.Windows.Forms;
4using System.Windows.Interop;
5
6namespace FolderPickerDemo;
7
8public sealed class WpfWindowWrapper : IWin32Window
9{
10    public WpfWindowWrapper(IntPtr handle)
11    {
12        Handle = handle;
13    }
14
15    public IntPtr Handle { get; }
16}
17
18public partial class MainWindow : Window
19{
20    private void PickFolder_Click(object sender, RoutedEventArgs e)
21    {
22        var handle = new WindowInteropHelper(this).Handle;
23        using var dialog = new FolderBrowserDialog();
24        var owner = new WpfWindowWrapper(handle);
25
26        if (dialog.ShowDialog(owner) == System.Windows.Forms.DialogResult.OK)
27        {
28            SelectedPathTextBlock.Text = dialog.SelectedPath;
29        }
30    }
31}

This small change improves focus behavior and makes the dialog feel like part of the application instead of a separate floating window.

Keep the View Model Free of UI APIs

If the project follows MVVM, the view model should not instantiate dialog classes directly. A better pattern is to move folder selection into a service that the view model can call. The service handles UI concerns, while the view model only asks for a path.

1using System.Windows.Forms;
2
3namespace FolderPickerDemo;
4
5public interface IFolderDialogService
6{
7    string? PickFolder(string description);
8}
9
10public sealed class FolderDialogService : IFolderDialogService
11{
12    public string? PickFolder(string description)
13    {
14        using var dialog = new FolderBrowserDialog
15        {
16            Description = description,
17            ShowNewFolderButton = true
18        };
19
20        return dialog.ShowDialog() == DialogResult.OK
21            ? dialog.SelectedPath
22            : null;
23    }
24}

A view model can then call this service from a command and update a SelectedPath property. That keeps unit tests simpler because the dialog itself can be mocked or replaced.

Validate the Chosen Path

A folder picker only gives you a string path. Your application still needs to check whether the directory exists, whether it is writable, and whether creating files there is actually allowed. That matters for backup tools, export features, and log destinations.

1using System.IO;
2
3namespace FolderPickerDemo;
4
5public static class FolderValidator
6{
7    public static bool CanWriteToFolder(string path)
8    {
9        if (!Directory.Exists(path))
10        {
11            return false;
12        }
13
14        var testFile = Path.Combine(path, "write-test.tmp");
15        try
16        {
17            File.WriteAllText(testFile, "ok");
18            File.Delete(testFile);
19            return true;
20        }
21        catch
22        {
23            return false;
24        }
25    }
26}

This check should happen after selection, not inside the dialog itself. The dialog chooses a location; your application decides whether that location is acceptable.

When to Consider Another Picker

FolderBrowserDialog is widely used, but it is not the only option. Some teams prefer Windows API Code Pack dialogs or other shell wrappers because they look closer to modern Windows dialogs and support more advanced browsing behavior. That is a reasonable upgrade when the application is Windows-only and the extra dependency is acceptable. For many line-of-business WPF apps, though, the built-in WinForms dialog is still the most practical choice.

Common Pitfalls

• Opening the dialog without an owner window and getting awkward focus behavior.
• Constructing dialog objects directly inside a view model and making UI code hard to test.
• Assuming the returned path is valid or writable without checking it.
• Forgetting to add the WinForms reference in a WPF desktop project.
• Running path-dependent work immediately on the UI thread after selection and freezing the window.

Summary

• WPF has no dedicated built-in folder picker, so FolderBrowserDialog is the usual solution.
• Passing the current window handle improves dialog ownership and focus behavior.
• An IFolderDialogService keeps folder selection out of the view model.
• The selected string path still needs application-level validation.
• For most WPF desktop tools, the simple WinForms interop approach is enough.