mvvm-toolkit-di

CommunityToolkit.Mvvm + Microsoft.Extensions.DependencyInjection

The MVVM Toolkit deliberately ships no DI container — it composes with Microsoft.Extensions.DependencyInjection, the same container ASP.NET Core, Worker services, and the .NET Generic Host use.

TL;DR. Build the service provider once at startup (prefer Host.CreateDefaultBuilder()). Register services and ViewModels. Inject through constructors. Avoid Ioc.Default.GetService<T>() in user code.

When to use this skill

• Standing up the composition root for a new XAML app (WPF, WinUI 3, MAUI, Uno, Avalonia)
• Choosing service/VM lifetimes
• Wiring IMessenger once and injecting it into ObservableRecipient ViewModels
• Resolving a page's ViewModel without coupling to a service locator
• Diagnosing "Unable to resolve service for type X while attempting to activate Y"

For source generators and ViewModel patterns see the mvvm-toolkit skill. For Messenger pub/sub see mvvm-toolkit-messenger.

Recommended composition root (Generic Host)

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using CommunityToolkit.Mvvm.Messaging;

public partial class App : Application
{
    public IHost Host { get; }

    public App()
    {
        Host = Microsoft.Extensions.Hosting.Host
            .CreateDefaultBuilder()
            .ConfigureServices((_, services) =>
            {
                services.AddSingleton<IFilesService, FilesService>();
                services.AddSingleton<ISettingsService, SettingsService>();
                services.AddSingleton<IMessenger>(WeakReferenceMessenger.Default);

                services.AddSingleton<ShellViewModel>();
                services.AddTransient<ContactViewModel>();
                services.AddTransient<EditorViewModel>();
            })
            .Build();
    }

    public static T GetService<T>() where T : class =>
        ((App)Current).Host.Services.GetRequiredService<T>();
}

Generic Host benefits:

• appsettings.json binding via Microsoft.Extensions.Configuration
• Logging via Microsoft.Extensions.Logging
• Hosted services (IHostedService) for background work
• Scope validation when the hosting environment is Development (desktop apps run as Production by default, so enable it explicitly)

The default builder also reads environment variables and command line arguments. Keep secrets out of appsettings.json and treat configuration values as untrusted input.

WPF and Windows Forms must integrate the host lifetime with the app lifetime — see Use the .NET Generic Host in a WPF app. Start the host when the app launches so hosted services run, and stop and dispose it when the app exits so disposable services are released.

Without Generic Host

When you only need a service container and want zero extra dependencies:

var services = new ServiceCollection();
services.AddSingleton<IFilesService, FilesService>();
services.AddTransient<ContactViewModel>();
ServiceProvider provider = services.BuildServiceProvider();

Constructor injection

Inject services and child ViewModels through the constructor:

public sealed partial class ContactViewModel(
    IFilesService files,
    IMessenger messenger,
    ILogger<ContactViewModel> logger)
    : ObservableRecipient(messenger)
{
    [ObservableProperty]
    private string? name;

    [RelayCommand]
    private async Task SaveAsync()
    {
        logger.LogInformation("Saving {Name}", Name);
        await files.SaveAsync(Name!);
    }
}

In real apps, log events rather than personal or user entered values.

Why constructor injection beats a service locator:

• Dependencies are explicit and visible at the call site
• Unit tests inject fakes/mocks directly
• The DI container validates the dependency graph at startup when ValidateOnBuild is enabled
• Missing registrations then throw at startup; otherwise the error appears when the type is first resolved

Lifetimes

services.AddSingleton<ShellViewModel>();   // 1 instance for app lifetime
services.AddTransient<NoteViewModel>();    // new instance per resolve
services.AddScoped<DialogService>();       // 1 per scope (rare)

Resolving in a View

Resolve the page's root ViewModel in code-behind, then let it pull its own dependencies:

public sealed partial class ContactPage : Page
{
    public ContactViewModel ViewModel { get; }

    public ContactPage()
    {
        ViewModel = App.GetService<ContactViewModel>();
        InitializeComponent();
    }
}

Bind in XAML with {x:Bind ViewModel.Xxx} (compiled bindings) or {Binding Xxx} against DataContext.

For navigation frameworks (WinUI 3 Frame.Navigate, MAUI Shell, Prism, MVVMCross), let the framework resolve the page and the page resolves its ViewModel from DI. Don't new ViewModels manually.

IMessenger registration

Register the messenger you want once, inject IMessenger everywhere:

services.AddSingleton<IMessenger>(WeakReferenceMessenger.Default);
// or
services.AddSingleton<IMessenger>(StrongReferenceMessenger.Default);

The default messengers are shared across the whole process. Recipients of the strong reference messenger stay alive until they unregister or are deactivated. Use a dedicated keyed or scoped messenger instance, or channel tokens, for sensitive or per-window messages.

Then:

public sealed partial class MyViewModel(IMessenger messenger)
    : ObservableRecipient(messenger) { }

An ObservableRecipient receives messages only after it is set active, typically on navigation or load. Setting it inactive on unload unregisters its handlers, which the strong reference messenger needs in order to release recipients.

For per-window messengers, register with keyed services or as scoped instances and inject into per-window ViewModels.

See the mvvm-toolkit-messenger skill for the messenger surface area.

Keyed services (.NET 8+)

Resolve different implementations of the same interface by key:

services.AddKeyedSingleton<IExporter, CsvExporter>("csv");
services.AddKeyedSingleton<IExporter, JsonExporter>("json");

public sealed partial class ExportViewModel(
    [FromKeyedServices("csv")] IExporter csvExporter,
    [FromKeyedServices("json")] IExporter jsonExporter)
    : ObservableObject { /* ... */ }

Testing seams

Constructor-injected dependencies are trivial to swap in tests. With Moq:

[Fact]
public async Task Save_calls_files_service()
{
    var files = new Mock<IFilesService>();
    var messenger = new WeakReferenceMessenger();
    var logger = NullLogger<ContactViewModel>.Instance;

    var vm = new ContactViewModel(files.Object, messenger, logger)
    {
        Name = "Ada"
    };

    await vm.SaveCommand.ExecuteAsync(null);

    files.Verify(f => f.SaveAsync("Ada"), Times.Once);
}

If you're mocking Ioc.Default or static state, the ViewModel is using a service locator — refactor to constructor injection.

Legacy: Ioc.Default

CommunityToolkit.Mvvm.DependencyInjection.Ioc is an escape hatch for cases where constructor injection is impossible — XAML-instantiated VMs for design-time data, ValueConverters, control templates.

Ioc.Default.ConfigureServices(
    new ServiceCollection()
        .AddSingleton<IFilesService, FilesService>()
        .AddTransient<ContactViewModel>()
        .BuildServiceProvider());

var files = Ioc.Default.GetRequiredService<IFilesService>();

When a host is used, configure Ioc.Default with the existing service provider of the host rather than a newly built one, so singletons stay shared.

Treat it as the last resort. Inside ViewModels, services, and any class the DI container can construct, prefer constructor injection.

Common pitfalls

1. Ioc.Default.GetService<T>() inside a VM constructor. Hides the dependency, breaks unit tests, prevents startup graph validation.
2. Everything Singleton. A "per-document" VM registered as singleton becomes shared state across all documents — subtle data corruption. Use AddTransient for per-instance VMs.
3. Multiple BuildServiceProvider() calls. Each call is a fresh container — singletons aren't shared. Build once at startup.
4. Capturing IServiceProvider in long-lived objects. Indicates a service-locator pattern. Inject the specific dependencies you need.
5. No scope validation in development. Host.CreateDefaultBuilder() sets ValidateScopes and ValidateOnBuild only when the hosting environment is Development. Desktop apps run as Production by default, so enable both explicitly through the default service provider options so registration mistakes fail at startup, not at first use.
6. Resolving scoped services from the root provider. They're effectively promoted to singleton lifetime — the warning is silent without scope validation. Either change the lifetime or resolve from an explicit IServiceScope.
7. Disposable transient ViewModels resolved from the root provider. They are kept alive until the app exits. Resolve them from a per-window or per-page IServiceScope, or keep transient ViewModels free of disposable state.

References

External:

• DI overview: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection
• DI usage: https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection-usage
• MVVM Toolkit Ioc page: https://learn.microsoft.com/en-us/dotnet/communitytoolkit/mvvm/ioc
• Generic Host: https://learn.microsoft.com/en-us/dotnet/core/extensions/generic-host