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.

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:

Constructor injection

Inject services and child ViewModels through the constructor:

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

Resolving in a View

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

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:

Then:

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:

Testing seams

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

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.

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. Use Host.CreateDefaultBuilder() (which sets ValidateScopes and ValidateOnBuild in development) 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.

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