WPF Extension to directly inject dependencies in the Window constructor
Constructor injection is indeed preferable, but it's not the only way to inject dependencies - property injection is just as valid, and in the case of a WPF Window, the only dependency that should be injected, is the ViewModel - and Window already has a property exposed for that: DataContext.

Assuming a Model-View-ViewModel architecture, I cannot think of a single valid reason to constructor-inject anything into a View. The role of the View in MVVM is to be nothing more than a simple I/O device presenting data to the user, and exposing means for that user to provide inputs.

That means a View needing dependencies injected is highly suspicious, because it suggests that the View is at least partly doing the ViewModel's job, and this is going to make that logic much more difficult to test than if it were done elsewhere: the idea behind separating the View from the ViewModel isn't just to leverage the powerful XAML data bindings, it's also to get as much of the not-stricly-presentation concerns out of the View so that they can be unit-tested without popping up a UI.

Now, as I said in an earlier comment, maybe I'm doing this wrong, but I've never had issues with this approach: I remove the StartupUri in the App.xaml markup, and then edit App.xaml.cs to override OnStartup as follows:

protected override void OnStartup(StartupEventArgs e)
{
    base.OnStartup();
    // if you're using an IoC container, this is where you set it up:
    // ...

    // if you're using an IoC container, this is where you resolve your VM's dependencies:
    // ...
    // otherwise, just new it up:
    var vm = new MainWindowViewModel(/*ctor-inject dependencies manually here*/);
    var window = new MainWindow { DataContext = vm };
    window.ShowDialog();
}


The IoC configuration code should go into its own method (could be in App.xaml.cs, or in some static helper), of course. But the point remains: the view doesn't have any dependencies, other than its view model.

The MainWindow.xaml.cs code-behind might look like this:

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
        DataContextChanged += MainWindow_DataContextChanged;
    }

    MainWindowViewModel ViewModel =&gt; DataContext as MainWindowViewModel;

    private void MainWindow_DataContextChanged(object sender, DependencyPropertyChangedEventArgs e)
    {
        var vm = ViewModel;
        if (vm != null)
        {
            vm.Close += HandleViewModelCloseCommand;
        }
    }

    private void HandleViewModelCloseCommand(object sender, EventArgs e)
    {
        Close();
    }
}


Everything else belongs in the ViewModel: any ICommand you might want to inject, any service, unit-of-work/repository, "business logic" worker objects - none of these are dependencies of the window itself.

Since a WPF window needs no dependencies, the base premise falls apart, and all that code can be deleted.