mvvm-dialogs: opening WPF dialogs from a view model without the view reference

The problem the library was born to solve

MVVM Dialogs is a library simplifying the concept of opening dialogs from a view model when using MVVM in WPF, and the stated payoff is that it enables the developer to easily write unit tests for view models in the same manner unit tests are written for other classes.

The history explains why it exists at all. It started out as an article on CodeProject, with its first revision published in May 2009. At that time MVVM was still new and fresh, the now deprecated MVVM Light had not yet been published, and in fact none of the MVVM libraries commonly used today existed back then. The library came about out of necessity to work with dialogs from the view model, as a reaction to the fact that although MVVM was a popular pattern, the support to implement it was rather limited.

That is a nice framing, because it places the library in a specific gap. A view model that wants to ask a question has to reach for something, and if it reaches for the concrete WPF dialog then the view model can no longer be constructed in a test without a window. The library's whole contribution is an interface in between, so the view model depends on an abstraction that a test can substitute.

The library has built-in support for the following dialogs: modal window, non-modal window, message box, open file dialog, save file dialog and folder browser dialog. Six, covering what a desktop application actually needs.

The maintainer's framing of the project's status is unusually blunt and worth reading before you adopt it. The codebase is actively maintained but not actively developed, pull requests with new features will have a very slim chance of getting merged, and in many aspects this codebase is done. Please feel free to use the code, but refrain from having hopes that it has any aspirations of being anything more than it currently is.

That is a feature statement and a warning at once, and the last push was on 2026-10-16, so the maintenance part is real.

Registering the view, then calling the service

The usage pattern has two halves, one on the view side and one on the view model side.

On the view side, you decorate the view with the attached property `DialogServiceViews.IsRegistered`:

<UserControl
    x:Class="DemoApplication.Features.Dialog.Modal.Views.ModalDialogTabContent"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:md="https://github.com/fantasticfiasco/mvvm-dialogs"
    md:DialogServiceViews.IsRegistered="True">

  ...

</UserControl>

With the view registered, the view model is now capable of opening a dialog using the interface `IDialogService`:

public class ModalDialogTabContentViewModel : INotifyPropertyChanged
{
    private readonly IDialogService dialogService;

    public ModalDialogTabContentViewModel(IDialogService dialogService)
    {
        this.dialogService = dialogService;
    }

    ...

    private void ShowDialog()
    {
        var dialogViewModel = new AddTextDialogViewModel();

        bool? success = dialogService.ShowDialog(this, dialogViewModel);
        if (success == true)
        {
            Texts.Add(dialogViewModel.Text);
        }
    }
}

Two details in that code are the design. The service is injected through the constructor, so a test passes a fake and never touches a window. And the return value is a `bool?`, the nullable boolean that WPF dialogs use for their DialogResult, so the view model branches on the user's answer rather than on some separate state.

The first argument to `ShowDialog` is the current view model, which is how the service knows which window to host the dialog on top of, and the second is the view model of the dialog itself. The result is the familiar pattern of a modal dialog returning a value into the caller's state, except the caller is now testable.

The attached property approach to registration is worth noting too. It means the view is marked as dialog-capable in XAML, and the library finds it at runtime, so no code-behind wiring is needed and the view model never has to know what type of window it is hosted in.

Custom windows, custom framework dialogs and the Contrib repository

Two extension points cover the cases where the defaults do not fit.

The first is custom windows. Dialogs in WPF that do not inherit from `Window` are called custom dialogs, and they are supported, but in order for `DialogService` to know how to interact with them you have to implement the `IWindow` interface. That is the cost of supporting them, and it is a reasonable one: the service needs a uniform way to close a dialog and read its result, and a `UserControl` used as a dialog does not provide that on its own.

The second is custom framework dialogs. MVVM Dialogs is by default opening the standard Windows message box or the open file dialog when asked to, and this can be changed by providing your own implementation of `IFrameworkDialogFactory` to `DialogService`. So the file and message box dialogs are routed through a factory you can replace, which is how you would substitute a custom file picker or a themed message box across the whole application at once.

The third extension point is outside the library. MVVM Dialogs takes no claim to solve all issues regarding dialogs, and for the applications deviating from the common path there is MVVM Dialogs Contrib, a repository with features and functionality developed by the open source community for very specific needs. If MVVM Dialogs does not fit your application, the guidance is to raise an issue in that repository. Those features are always implemented by the community but shepherded by the maintainers of MVVM Dialogs, which is a useful division of labour in a library that considers itself finished.

There is also a set of sample applications showing how the library integrates with existing MVVM frameworks: Caliburn.Micro, the MVVM Light Toolkit and the Windows Community Toolkit, each in its own repository. The reasoning given is that creating a new application is daunting, with lots of decisions to make and some mistakes harder to correct, so the samples exist to show how you would integrate MVVM Dialogs into a framework you have already chosen. If your framework is not among the listed, the project asks you to create a pull request and let them know.

How the package is built and where the tests live

The repository layout shows a mature.NET library rather than a weekend project.

There is `MvvmDialogs.sln` with a `SolutionInfo.cs` and a `StrongName.snk`, so the assembly is strong named, and a `Directory.Build.props` for shared build settings. The `MvvmDialogs.nuspec` is the package definition, and the `build/` and `doc/` directories hold the build scripts and the documentation assets, including the icon shown in the README. `appveyor.yml` is the CI configuration, and `renovate.json` shows that dependency updates are automated.

The samples directory is the most revealing part. It is not one sample application but a long list of paired directories, each with a `.Test` counterpart: `Demo.ModalDialog` and `Demo.ModalDialog.Test`, `Demo.NonModalDialog` and `Demo.NonModalDialog.Test`, `Demo.MessageBox` and `Demo.MessageBox.Test`, `Demo.CustomOpenFileDialog`, `Demo.CustomSaveFileDialog`, `Demo.CustomFolderBrowserDialog`, `Demo.CustomMessageBox`, `Demo.ModalCustomDialog`, `Demo.NonModalCustomDialog`, `Demo.ActivateNonModalDialog`, `Demo.CloseNonModalDialog` and `Demo.CustomDialogTypeLocator`.

Each sample has a matching test project, and the naming shows exactly which behaviours are worth proving. There is a sample for activating a non-modal dialog and one for closing one, which are the two things that are easy to get wrong with non-modal windows. There is a sample for a custom dialog type locator, which is the mechanism for resolving a view from a view model type. And the custom dialog samples for the open file, save file, folder browser and message box demonstrate the `IFrameworkDialogFactory` replacement described earlier.

The test/ directory at the root holds the library's own test suite, and there is a `.config/` directory and a `.editorconfig` at the root. The `src/` directory holds the library itself, split from the samples, and the `CHANGELOG.md` and `CONTRIBUTING.md` are present.

Where this sits against the built-in dialogs and against a DI container

The comparison worth making is with the two alternatives in a WPF application: use the framework dialogs directly, or build your own dialog service.

Using the built-in `MessageBox.Show` from the view model is the quick option and it needs no library. The problem it creates is the one the library's history describes: a view model that calls a static framework method cannot be unit tested without a message box appearing, and worse, the test cannot say what the user clicked. The library replaces the static call with an injectable interface, which is the whole trade.

Building your own service is the other option, and it is what most teams end up doing if they need something the library does not offer. It costs a day or two of work for the common cases, and it costs considerably more if you want non-modal support, the type locator behaviour, and the ability to swap out the framework dialogs, because all of that is where the fiddly behaviour lives. The library's value is that it has already been through that.

The dependency injection point deserves a note. The view model takes `IDialogService` in its constructor, so you need some way to register that service. In a WPF application using one of the frameworks the library has samples for, that is a container registration. In a smaller application, you would implement `IDialogService` yourself over the library's `DialogService` and hand it to the view model, which is a small amount of code and keeps the library's own type out of your composition root.

The honest limit of the comparison is that the library does not cover everything. Its own text says it takes no claim to solve all issues regarding dialogs, and the non-modal and custom-window cases require an interface implementation or a type locator that you have to understand. The sample applications exist precisely so that you can see those cases working before you adopt them.

Editorial conclusion

Adopt mvvm-dialogs if you are on WPF and want dialogs behind an interface so view models stay unit testable, since the library has been in use since 2009 and the NuGet package is stable. Do not adopt it expecting new features, because the README says pull requests with new features have a very slim chance of being merged and that in many aspects the codebase is done, and note that the latest listed release is v9.1.2 from 2023-10-07.

Frequently asked questions

Official sources

1. FantasticFiasco/mvvm-dialogs on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases