WPF File Dialog Improvements in .NET 8
We are thrilled to announce a new set of improvements to the common file dialog API in WPF, starting with .NET 8 Preview 7. This includes the top voted API suggestion in the repository to date – the OpenFolderDialog control to allow users to select a folder – as well as several new properties on file dialogs in general, enabling new user scenarios such as separately persisted states, limiting folder navigation etc.
Until now, WPF supported both Common Item Dialog API introduced in Windows Vista and the legacy GetOpenFileName and GetSaveFileName functions when running on older operating systems. As a part of this update, the dialog code was cleaned up and infrastructure for the legacy functions was removed, since all Windows versions supported by .NET use the newer API only. Applications running in compatibility mode continue to work, but they will present common dialogs using the Common Item Dialog API instead.
OpenFolderDialog
One of the most requested feature within the WPF community was a dialog for selecting folders. Example use cases include opening a folder in Visual Studio or Visual Studio Code, saving attachments in Outlook or extracting compressed files into a folder of user’s choice. Until now, developers had to use Windows Forms or rely on third-party libraries to be able to provide this experience, introducing unnecessary dependencies without fitting into the existing model of dialogs.
Starting with .NET 8, we are shipping native support for this dialog in WPF. There has been a lot of discussion in the community on how this feature should be integrated into the existing model of file dialogs, trying to balance compatibility requirements, clean architectural design and underlying API structure. Eventually, we decided to introduce a new base class, CommonItemDialog, into the inheritance chain, where all the common dialog properties got moved:
This allows us to remain backwards compatible with existing applications. More details on the design and discussion can be found in the pull request and API proposal.
Using the OpenFolderDialog is similar to using the existing file dialogs in WPF:
var folderDialog = new OpenFolderDialog
{
Title = "Select Folder",
InitialDirectory = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86)
};
if (folderDialog.ShowDialog() == true)
{
var folderName = folderDialog.FolderName;
MessageBox.Show($"You picked ${folderName}!");
}where the ShowDialog method opens the dialog and waits for user input:
More examples demonstrating the usage of OpenFolderDialog and other file dialogs can be found in the WPF-Samples repository.
New Dialog Properties
We also expanded the number of properties to configure the behavior of file dialogs in WPF, covering as much as currently possible of the underlying API. To highlight some of them:
- ClientGuid identifies the dialog’s persistent state. This allows Windows to remember dialog state such as window size or last used folder separately per dialog, for example for the Save and Save As dialogs.
- Setting AddToRecent to false instructs the dialog to not add the opened or saved file or folder to the most recent items list maintained by Windows for the user. This can be for example used to prevent a configuration file from appearing in the Recommended section of the Start menu.
- Setting CreateTestFile to false prevents SaveFileDialog to verify user has access to the selected location by creating and deleting a dummy file. This can be useful when access to the location is expected to be expensive. However, the application will have to do all the appropriate error handling when creating the file itself.
- RootDirectory limits the folder tree in the dialog to a certain folder and its subfolders. Here is an example of RootDirectory set to user’s Pictures folder:
Check the list of all the new properties in the pull request or API proposal. We would like to invite you to try the new features out and provide us feedback.
What’s Next for File Dialogs
There is still room for improvement regarding the file dialogs, such as supporting virtual files or customizing the dialog by including additional controls in the user interface. We have a pull request from the community proposing an implementation of the file dialog controls and we would like to invite everyone interested to participate in shaping this proposal and help us prioritize features that matter to you and your applications.
Community Highlight
Special thanks to Jan Kučera, our community contributor, for his constant efforts in bringing the dialog updates alive. He explored different design options, prepared the API proposal, and implemented the feature end-to-end. Thanks Jan!
In Jan’s own words:
Hello everyone, I am Jan, a researcher, developer and a huge WPF fan!
It is now 20 years since Microsoft started publicly talking about WPF, at that time under its codename Avalon (knowledge of which made win my first WinFX book), making it one of the longest available application frameworks using .NET. While it inspired many others, none of them seem to have matched it in features and straightforwardness, which is why WPF has always been my first choice. I especially value its layout system, allowing applications to adapt to their content.
The most enjoyable part of programming for me is interacting with the real world. I was involved in .NET Micro Framework (which brought WPF UI model to embedded devices) as a member of Core Team working with community. In Microsoft Research, I worked in the amazing team of James Scott and Steve Hodges on .NET Gadgeteer. Under their guidance, I became a researcher in Human-Computer Interaction.
Most of my free time is spent volunteering for Unicode, where I am vice-chair of the Unicode’s Script Ad Hoc Group and Keyboard Subcommittee. My passion about internationalization, especially text input and output, allowed me to contribute to the DirectWrite text shaping engine and the design of new keyboard layouts. This work enables me to help more and more communities become represented digitally, and I am hoping we can get WPF up to speed with their needs as well.
I am excited to see continued interest in and development of WPF and can recommend to anyone who is considering it to join the welcoming community and shape its future.
Light
Dark
22 comments
Too late. And too small for an improvement. You cannot write a decent WPF application without spending a couple of grands in third-party controls. And MAUI is a big NO. Too sad, also.
We are just getting started 🙂 Stay tuned for many new features to come!
Wait) I needed this window 5 years ago and I used third-party libraries to achieve this
I’ve spent the last 7 years telling the .NET team how thrilling .NET is and how I think it is Microsoft’s best product. Seven years have passed, Windows still ships with .NET Framework 4.8 and PowerShell 5.1, and nobody is adopting .NET 5 or later. The only high-profile products to have adopted it are PowerToys, Paint.NET, and PowerShell. The rest of the world is still on .NET Framework 4.
So, let me be clear. .NET has a last-mile problem. If not solved, .NET will join the other dead-and-buried Microsoft initiatives like JPEG XR, Open XPS, Windows CardSpace, Microsoft Expression, Zune, and Windows Phone.
Most server-side workloads have been migrated to .NET.
It’s odd to mention “server-side workload” in an article titled “WPF File Dialog Improvements.” But speaking of server-side, Windows Server doesn’t bundle .NET 5 or later versions either. (Windows Server SAC did, but it’s dead.) Also, Oracle told me most server-side workloads have been migrated to Java! But since I can’t see most “server-side workloads,” I never know which one of you is right. Who knows? Maybe most server-side workloads are actually on LAMP or WAMP!
Windows Server not “bundling” any version of .NET is I believe on purpose. With modern .NET, you don’t necessarily install a specific version of .NET on the target machine. Instead, you either containerize it, create a standalone with its own runtime or install the specific version you do need, which is likely to be different from anything pre-installed. Having a given version of .NET installed would just be a waste of space.
.NET is no longer tied to a version of the OS, that was the whole point of .NET Core.
Translation: .NET is a waste of space. You said it, not me.
It’s true that having several applications that each embed the 250MB of the .Net 5 runtime is not a waste of space… 🤣
Before : 4 Wpf .Net Framwork apps of 20Mo
After : 4 .Net 6 Wpf app of 260Mo !
Loss of space when you hold us 😅
Server and web apps use .NET Core
Finally! Thank you very much, will update my apps as soon as .NET 8 will go live.
BTW, what’s the key difference from Microsoft.Win32 dialogs? The namespace is available without relying on Winforms or something 3rd-party.
Ours is too a wrapper around Win32 controls. Yes, the control can be used just like other DialogControls (FileDialog, SaveDialog, etc.) .
Happy to see this feature finally comes to WPF. Please put more resources on WPF and make more progress. WPF is not dead and it`s still the best desktop UI technology (IMO).
Good to see that WPF is not dead… But this is a very small update.
Yes. But we are just getting started. Stay tuned for many more features to come! 🙂
Props to Jan Kučera and his work on .NET Gadgeteer. That was an amazing piece of technology and allowed people like me (without background in electrical engineering) to build some amazing devices very quickly.
I was very sad when it was discontinued, along with the entire .NET Micro Framework.
That one made me jiggle.
Great that it arrived, but hell it was about time.
Thank you for giving this technology some attention after years of neglect. Still one of the best choices for windows desktop development. Looking forward to future updates.
Finally, after so many years…