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 in development builds

WPF and Windows Forms must integrate the host lifetime with the app
lifetime — see
Use the .NET Generic Host in a WPF app.

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!);
    }
}

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
• Missing registrations throw immediately, not at first use

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);

Then:

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

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>();

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.

1. Everything Singleton. A "per-document" VM registered as singleton

becomes shared state across all documents — subtle data corruption.
Use AddTransient for per-instance VMs.

1. Multiple BuildServiceProvider() calls. Each call is a fresh

container — singletons aren't shared. Build once at startup.

1. Capturing IServiceProvider in long-lived objects. Indicates a

service-locator pattern. Inject the specific dependencies you need.

1. No scope validation in development. Use Host.CreateDefaultBuilder()

(which sets ValidateScopes and ValidateOnBuild in development) so
registration mistakes fail at startup, not at first use.

1. 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.

References

External:

• DI overview:
• DI usage:
• MVVM Toolkit Ioc page:
• Generic Host: