Reduce depencency on WPF

Is your feature request related to a problem? Please describe.

MVVM does not have a dependency on WPF or any other presentation framework. This is true for both MVVM-Light and its successor MVVM Toolkit MVVM Dialogs codebase could be split between core (or base) package, which only relies on .Net Standard and presentation package(s) responsible for the presentation layer implementation.

Describe the solution you’d like

Introduce a new project and NuGet package, which declares framework-agnostic types and interfaces such as IModalDialogViewModel

Draft PR #176 demonstrates the general idea.

Describe alternatives you’ve considered Keeping dialogs away from the presentation layer could be achieved (maybe?) with a wrapper:

Copy and rename the interface

public interface IModalDialogViewModelStandard : INotifyPropertyChanged
{
    bool? DialogResult
    {
        get;
    }
}

Implement dialog VM outside of presentation layer using IModalDialogViewModelStandard

public class MyDialogVM : ViewModelBase, IModalDialogViewModelStandard 
{
    private bool? dialogResult;
    public bool? DialogResult
    {
        get => dialogResult;
        private set => Set(nameof(DialogResult), ref dialogResult, value);
    }
}

Wrap IModalDialogViewModelStandard inside a IModalDialogViewModel

public class ModalDialogViewModelWrapper<T> : ObservableRecipient, IModalDialogViewModel where T : IModalDialogViewModelStandard
{
    readonly T modalDialogViewModel;
    public ModalDialogViewModelWrapper(T modalDialogViewModel)
    {
        this.modalDialogViewModel = modalDialogViewModel;
    }
    public bool? DialogResult => modalDialogViewModel.DialogResult;
}

IDialogTypeLocator needs to associate a ViewModels from non-presentation assembly to Window in the presentation layer. Window could be wrapped in IWindow to override IWindow.DataContext

What’s your opinion @FantasticFiasco ?

[FantasticFiasco]

@FantasticFiasco BTW, there are a few other RPs I wanted to send. If you’d be open to them, they should be done before this abstraction:

• Reduce amount of sample projects by multitargeting sample projects to both .Net Core and .Net Framework
• Remove support for .Net Frameworks before 4.5.2. They reached end of life and are not supported by VS 2022.
• Replace MVVMLight with CommunityToolkit.Mvvm

What do you think?

I’m happy to announce that @virzak made huge impact with these implementations. I’m about to enbark on your path now @mysteryx93. Wish me luck! 😄

[FantasticFiasco]

Of course it can be made in increments. #180 is an increment and I’m sure there will be more increments in your fork.

You can’t really expect that a maintainer will accept a total re-write of a codebase. As maintainer you have to own the codebase and understand every intrinsic detail. You can’t really do that if you receive a total rewrite.